webgl
William Stein
Is anybody interested in creating a webGL [1] renderer for 3d graphics
for the Sage notebook? We have JMOL, Tachyon, Java3d and x3d renderers
for 3d graphics. Webgl support would be very forward looking. It's
also *3d accelerated* unlike Jmol, so could provide amazingly good
performance.
William
[1] If you're using Chrome, check out http://www.chromeexperiments.com/webgl
--
William Stein
Professor of Mathematics
University of Washington
http://wstein.org
Volker Braun
[1] If you're using Chrome, check out http://www.chromeexperiments.com/webgl
Jason Grout
> Hi,
>
> Is anybody interested in creating a webGL [1] renderer for 3d graphics
> for the Sage notebook? We have JMOL, Tachyon, Java3d and x3d renderers
> for 3d graphics. Webgl support would be very forward looking. It's
> also *3d accelerated* unlike Jmol, so could provide amazingly good
> performance.
>
> William
>
> [1] If you're using Chrome, check out http://www.chromeexperiments.com/webgl
Remember that Carl Witty already has some progress towards this from a
long time ago:
http://groups.google.com/group/sage-notebook/browse_thread/thread/4f11203d36d7f8a1/d287be6a6908b9d3
At that time, he worked on using sceneJS. SceneJS still looks very
promising.
I also looked at using x3dom and our current x3d generation:
http://groups.google.com/group/sage-devel/msg/c73977efaff86cfb. I
wasn't extremely impressed with the results at the time, but it was
something.
I would love to see a webgl renderer.
Thanks,
Jason
Robert Bradshaw
:(. I'm pretty sure that's "doesn't support webgl yet" or without
hacks (e.g. http://www.borfast.com/blog/how-enable-webgl-google-chrome-linux-blacklisted-graphics-card
) Still, I think it's the way forward, even if it's a while before we
could completely deprecate the other options.
- Robert
kcrisman
On Jan 26, 7:19 pm, Robert Bradshaw <rober...@math.washington.edu>
wrote:
> > On Thursday, January 26, 2012 2:14:36 PM UTC-8, William wrote:
>
> >> [1] If you're using Chrome, check out
> >>http://www.chromeexperiments.com/webgl
>
> > Unless you use Linux, where chrome doesn't support webgl despite what the
> > documentation says.
>
> :(. I'm pretty sure that's "doesn't support webgl yet" or without
> could completely deprecate the other options.
optional...
mmarco
on both (but i have the impression that performance is better in
chromium). Strangely, it does work on the version of firefox that i
have compiled in my computer, but it doesn't in the binary version
from the firefox site. I guess that there is some compile option that
is disabled in the binary package.
William Stein
> I have just tested on chromium and firefor under linux. It does work
> on both (but i have the impression that performance is better in
> chromium). Strangely, it does work on the version of firefox that i
> have compiled in my computer, but it doesn't in the binary version
> from the firefox site. I guess that there is some compile option that
> is disabled in the binary package.
Hi,
I just looked at WebGL and other options for a while, and though WebGL
is neat and "the future", etc., it is almost the farthest thing
possible from "just working". It's the exact opposite of what I
think the Sage notebook desperately needs (and which JMOL does *not*
provide despite its promise), which is rock solid 3d graphics that
just work everywhere (except Internet Explorer, where Sage barely
works anyways). Of course, having WebGL support will be amazing
for high-performance applications, e.g, as an alternative to VTK.
But it doesn't work on my cell phone.
I had hoped that Bill Cauchois's canvas3d rendered (that is in Sage)
would fill this void, but it is still a very basic wireframe renderer,
and isn't very useful in practice. At least it works on everything
that supports HTML5 canvas 2d.
I found another newer 3d library called Pre3d [1]. This is a 3d
javascript library that uses HTML5 canvas 2d, which is the same thing
that Rado's graph editor uses (and Cauchois's library), and works on
iphones, android tablets, firefox, chrome, safari, etc. It does
hidden surface removal and transparency. Having looked through the
code, I think a library based on Pre3d could be the best *default* for
3d graphics for Sage. It obviously doesn't look as good as jmol, but
it is very lightweight, uses little memory, loads quickly, doesn't
crash, works on my phone, etc. It will have to be extended to do
what we want, e.g., it does not currently support text, but that
should be easy given that canvas2d has excellent text support.
[1] http://deanm.github.com/pre3d/
Any thoughts?
We would also have to write javascript code that could parse a 3d
scene described using some JSON representation, draw the scene, etc.
It would also be critical to add some sort of selector support to
pre3d (which has none). At least manipulating the scene is
straightforward javascript, so it should be easier to integrate more
tightly with Sage than JMOL is.
-- William
> On 27 ene, 00:41, Volker Braun <vbraun.n...@gmail.com> wrote:
>> On Thursday, January 26, 2012 2:14:36 PM UTC-8, William wrote:
>>
>> > [1] If you're using Chrome, check out
>> >http://www.chromeexperiments.com/webgl
>>
>> Unless you use Linux, where chrome doesn't support webgl despite what the
>> documentation says. Works in Firefox, though.
>>
>>
>
> --
> To post to this group, send an email to sage-...@googlegroups.com
> To unsubscribe from this group, send an email to sage-devel+...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/sage-devel
> URL: http://www.sagemath.org
William Stein
Right after looking at pre3d and sending this, I found via google
search another library called three.js [1]. This simultaneously
supports *both* HTML5 canvas2d and webgl (if available), so it is
blazingly fast on my laptop (say), but at least works on my iphone and
Android tablet, and anything else with HTML5 canvas. It also
supports selecting individual objects in a 3d scene and moving them
around, e.g., [2] (uses webgl). Canvas for complicated scenes is of
course slow, but at least it works on nearly anything.
Switching from jmol to three.js as our main engine for 3d graphics
should be high on the roadmap for this year.
[1] http://mrdoob.github.com/three.js/
[2] http://mrdoob.github.com/three.js/examples/webgl_interactive_draggablecubes.html
Jason Grout
> Canvas for complicated scenes is of
> course slow, but at least it works on nearly anything.
>
> Switching from jmol to three.js as our main engine for 3d graphics
> should be high on the roadmap for this year.
These two statements taken together are concerning. We don't want to
penalize the performance for the majority of people (i.e., those with
not up-to-date browsers or computers, but can run java).
But testing out three.js certainly sounds like a great idea, and at
least providing it as an option!
Jason
Dima Pasechnik
On Sunday, 29 January 2012 01:54:00 UTC+8, jason wrote:
On 1/28/12 10:03 AM, William Stein wrote:
> Canvas for complicated scenes is of
> course slow, but at least it works on nearly anything.
>
> Switching from jmol to three.js as our main engine for 3d graphics
> should be high on the roadmap for this year.These two statements taken together are concerning. We don't want to
penalize the performance for the majority of people (i.e., those with
not up-to-date browsers or computers, but can run java).
William Stein
On Saturday, January 28, 2012, Jason Grout <jason...@creativetrax.com> wrote:
> On 1/28/12 10:03 AM, William Stein wrote:
>>
>> Canvas for complicated scenes is of
>> course slow, but at least it works on nearly anything.
>>
>> Switching from jmol to three.js as our main engine for 3d graphics
>> should be high on the roadmap for this year.
>
> These two statements taken together are concerning. We don't want to penalize the performance for the majority of people (i.e., those with not up-to-date browsers or computers, but can run java).
>
> But testing out three.js certainly sounds like a great idea, and at least providing it as an option!
>
> Jason
Jason Grout
>
>
> On Sunday, 29 January 2012 01:54:00 UTC+8, jason wrote:
>
> On 1/28/12 10:03 AM, William Stein wrote:
> > Canvas for complicated scenes is of
> > course slow, but at least it works on nearly anything.
> >
> > Switching from jmol to three.js as our main engine for 3d graphics
> > should be high on the roadmap for this year.
>
> These two statements taken together are concerning. We don't want to
> penalize the performance for the majority of people (i.e., those with
> not up-to-date browsers or computers, but can run java).
>
> Well, is it really a majority?
>
I suppose it's hard to tell.
http://www.khronos.org/webgl/wiki/Main_Page indicates that IE doesn't
have WebGL, for example. According to the google analytics, about 12.5%
of our visits to sagenb.org over the last 6 months have been with IE,
and about 2-3% or so have used an older version of Firefox that doesn't
support WebGL.
> Anyhow, it would be really great to see something less flaky and heavy
> than jmol
> for teaching purposes (when you can make sure that the right browsers
> are used).
I agree (but I would put the blame on java applets, not necesarily jmol
particularly). Testing will show how webgl/canvas support compares to jmol.
Jason
Jason Grout
> > These two statements taken together are concerning. We don't want to
> penalize the performance for the majority of people (i.e., those with
> not up-to-date browsers or computers, but can run java).
> >
>
> Sorry to trouble you, but I think it is time to move past jmol. We
> could keep jmol as an option indefinitely... but i do not think it
> should be the default for 3d. It is not robust enough, and it is very,
> very frusratingly non-interactive: despite many attempts i have never
> seen a compelling demo of genuine sage <----> jmol interaction.
> Three.js will make this possible; it will make it easier for prople take
> 3d images from sage and put them in their own web pages (much more
> lightweight), supports ios and android -- which is *hugely important* - etc.
>
> > But testing out three.js certainly sounds like a great idea, and at
> least providing it as an option!
> >
>
> I plan to seriously "concern you".
All I'm saying is that we should test it to make sure it is better and
as widely supported as we need first before making deciding to make it
the default.
But the first step in either case is an implementation...
Jason
Jason Grout
> I suppose it's hard to tell. http://www.khronos.org/webgl/wiki/Main_Page
> indicates that IE doesn't have WebGL, for example. According to the
> google analytics, about 12.5% of our visits to sagenb.org over the last
> 6 months have been with IE, and about 2-3% or so have used an older
> version of Firefox that doesn't support WebGL.
So, in particular, it seems that the majority of sagenb.org visits do in
fact come from browsers that support webgl. Whether or not their
computers support webgl is something that I suppose is harder to tell.
Surely there an easy 1-line test that can determine if a computer itself
supports webgl. It would make sense to add to that to the sagenb.org
headers to log that information to google analytics. Then we can get a
much better idea about how widely-supported it is for our users.
Jason
Volker Braun
Jonathan
I guess I would like to know which of the problems you refer to still
are a problem in the updates to Jmol that are awaiting review?
The things left that I know about are:
1) The way Jmol functions in interacts is a problem, but this has
nothing to do with Jmol. It is the way the interact code is written.
The interact code insists on reloading the whole applet every time the
server does a recalculation, rather than just send the applet a
command to load the recalculated graphics file (this would get you a
factor of 10 - 100 in response time).
2) Jmol will not work on iOS. There is a way to get it to work on
Android, but we cannot look at that until Sage upgrades to a much more
recent Jmol (also awaiting review). A temporary fix is to generate
static 3D images and not load the applet unless the user wishes to
make them interactive (also in the updates awaiting review).
I also agree that you should be looking at supporting other rendering
methods as the world of web interfaces is constantly shifting.
Jonathan
On Jan 28, 12:15 pm, William Stein <wst...@gmail.com> wrote:
> Sorry to trouble you, but I think it is time to move past jmol. We could
> keep jmol as an option indefinitely... but i do not think it should be the
> default for 3d. It is not robust enough, and it is very, very
> frusratingly non-interactive: despite many attempts i have never seen a
> compelling demo of genuine sage <----> jmol interaction. Three.js will
> make this possible; it will make it easier for prople take 3d images from
> sage and put them in their own web pages (much more lightweight), supports
> ios and android -- which is *hugely important* - etc.
>
Keshav Kini
-Keshav
----
Join us in #sagemath on irc.freenode.net !
Dima Pasechnik
On Monday, 30 January 2012 03:49:45 UTC+8, Keshav Kini wrote:
Well, I wonder if we shouldn't ask around a bit more. If a day later you found something better than pre3d, maybe soon you will find something even better than three.js? :P As to who would be a good community to ask about this stuff, though, I have no idea.
-Keshav
Jason Grout
I looked on stackoverflow, and one post gave an interesting way to
measure project success---look at the number of watchers and forks on
github. By that measure, three.js is by far the most popular project
among several competing projects, with something like 10 times the
number of forks/watchers.
http://stackoverflow.com/questions/6762726/scenejs-vs-three-js-vs-others
(The scenejs author also there pretty much tells us that we should use
something different for our use-case.)
Thanks,
Jason
Jason Grout
> Well, I wonder if we shouldn't ask around a bit more. If a day later you
> found something better than pre3d, maybe soon you will find something
> even better than three.js? :P As to who would be a good community to ask
> about this stuff, though, I have no idea.
I sat down the other day and tried to write a simple three.js viewer.
The biggest frustration I had was the lack of documentation (for
example, apparently there is a way to specify a scene using json---what
is the format? I used the obj->json converter; but of course we don't
want to do that all the time. So I guess it's a matter of reading the
source for the JSON loader or reverse engineering the converter or the
converter output.)
Anyways, I or a student will likely look at this again in the next few
weeks, so if someone is working making a three.js backend, please ping
me (and certainly don't wait for me either!)
Thanks,
Jason
Jason Grout
William Stein
Thanks!! I really want to work on this as soon as I get time, and
your initial work is massively appreciated.
- William
>
> Thanks,
>
> Jason
Jason Grout
> On Tue, Jan 31, 2012 at 6:27 AM, Jason Grout
> <jason...@creativetrax.com> wrote:
>> On 1/30/12 5:11 PM, Jason Grout wrote:
>>>
>>> On 1/29/12 1:49 PM, Keshav Kini wrote:
>>>>
>>>> Well, I wonder if we shouldn't ask around a bit more. If a day later you
>>>> found something better than pre3d, maybe soon you will find something
>>>> even better than three.js? :P As to who would be a good community to ask
>>>> about this stuff, though, I have no idea.
>>>
>>>
>>> I sat down the other day and tried to write a simple three.js viewer.
>>> The biggest frustration I had was the lack of documentation (for
>>> example, apparently there is a way to specify a scene using json---what
>>> is the format? I used the obj->json converter; but of course we don't
>>> want to do that all the time. So I guess it's a matter of reading the
>>> source for the JSON loader or reverse engineering the converter or the
>>> converter output.)
>>>
>>> Anyways, I or a student will likely look at this again in the next few
>>> weeks, so if someone is working making a three.js backend, please ping
>>> me (and certainly don't wait for me either!)
>>
>>
>> A three.js backend is now http://trac.sagemath.org/sage_trac/ticket/12402
>
> Thanks!! I really want to work on this as soon as I get time, and
> your initial work is massively appreciated.
No problem. Here is the demo that I'm basing my work on:
http://sage.math.washington.edu/home/jason/threejsboilerplate/
You can get a screenshot by doing 'p' and can go fullscreen too. It's
pretty cool. This was from the learningthreejs.com site.
Jason
Jonathan
Jonathan