From: John Stone (johns_at_ks.uiuc.edu)
Date: Thu Apr 14 2011 - 15:05:00 CDT

Joshua,
  I downloaded the human readable version of the X3DOM source
code from SourceForge today, and had a closer look at how
it renders spheres and other higher level primitives.
  http://sourceforge.net/projects/x3dom/

Aside from the default resolution of the spheres, there
are two other issues with the approach currently implemented
in the X3DOM code. At present, X3DOM makes a completely separate
instance of every sphere object in the scene. Each sphere has its
own triangle mesh, etc. This means that the javascript code has to
generate a new mesh from scratch each time (which slows parsing down
considerably), and it also prevents OpenGL from reusing the same mesh
multiple times and downloading it to the GPU at most once-per-frame,
which would be the ideal way to do things (as VMD does).

Since X3DOM uses WebGL (OpenGL ES), it cannot use advanced OpenGL features
like display lists, but it could get much of same benefit from
proper reuse of vertex buffer objects with 4x4 transformation matrices
to put each sphere/cylinder/cone/torus instance in the correct
location, orientation, and scale.

One last thing that could be done to speed up the sphere rendering
in X3DOM would be to teach X3DOM to take advantage of triangle strips,
which would give us another 3x performance boost over rendering
meshes containing only independent triangles.

So, there are several things that can still be done to make X3DOM
perform much better for rendering spheres, cylinders, and other shapes
that are of key interest to us for molecular visualization.

I've sent an email about this to the developers of X3DOM, hopefully
some of these items will get traction and things will gradually
improve here. I'm tempted to try hacking the X3DOM code and implement
some of the optimizations myself, but I have too much to do for VMD
right now to take on any extra work presently. I'll let people know
as the X3DOM guys make progress though.

Cheers,
  John Stone
  vmd_at_ks.uiuc.edu

On Wed, Apr 13, 2011 at 12:51:08PM -0500, John Stone wrote:
>
> Joshua,
> Yeah, that's worth trying just to see how it behaves.
> I would guess that the fact they are processing the scene
> graph in javascript is one reason for having lower performance.
> Another reason may be that they don't take advantage of OpenGL
> display lists. Looking at x3dom.js, I don't immediately see how
> they are rendering the sphere meshes they create. If they aren't
> using display lists, then they would take a big performance hit
> compared with the way we do it in VMD for the non-GLSL code path.
> I'm not sure if display lists are supported by WebGL/OpenGL ES however,
> so that's something I'll have to figure out.
>
> Another possibility would be to teach X3DOM to use a GLSL
> shader or billboarding technique for faster sphere drawing.
> In one sense, the implementation techniques are limited by
> the OpenGL subset that WebGL implements, which if I recall
> correctly is a variation of the OpenGL ES standard used
> on cell phones and other embedded devices. That said, I'm
> sure one could make version of the code that favored the use
> of pixel shaders vs. geometry to make sphere rendering faster.
>
> Cheers,
> John Stone
> vmd_at_ks.uiuc.edu
>
> On Wed, Apr 13, 2011 at 12:34:52PM -0400, Joshua A. Anderson wrote:
> > Thanks for looking into this John, I don't think I would have found that latitude in the .js code!
> >
> > Dropping that resolution down helps quite a bit, but a 4000 sphere test system still renders at less than 4fps. If switched to a point representation, (which vmd exports as a <pointset>) and went all the way to 64000 particles without dropping under 60fps (didn't even try higher). It would appear that there is a high overhead in javascript for processing the nodes in the scene graph. Too bad there isn't a <SphereSet> node. If I find some time to play next week, I might verify that an IndexedTriangleSet encoding of the spheres does indeed run faster than all the individual <sphere> nodes.
> > --------
> > Joshua A. Anderson, Ph.D.
> > Chemical Engineering Department, University of Michigan
> >
> > On Apr 13, 2011, at 11:02 AM, John Stone wrote:
> >
> > > Joshua,
> > > Just a quick addendum:
> > > It looks like the X3DOM team has added a new runtime API for
> > > controlling things like the rendering stats display and other
> > > attributes that are separate from the X3D scene itself:
> > > http://x3dom.org/x3dom/example/x3dom_runtime.html
> > > http://x3dom.org/x3dom/doc/api/files/x3dmain-js.html
> > >
> > > I'm going to ask them to add new APIs to set the triangulated
> > > mesh resolution of the various higher level geometric primitives
> > > by this same mechanism, as I think that it's a close match to
> > > what they are already doing with that API. In the mean time,
> > > one can use this to shut off the statistics display and other
> > > stuff, which is a nice little improvement. I'll grab their
> > > new code and give it a spin soon.
> > >
> > > Cheers,
> > > John Stone
> > > vmd_at_ks.uiuc.edu
> > >
> > > On Wed, Apr 13, 2011 at 09:49:34AM -0500, John Stone wrote:
> > >> Hi Joshua,
> > >> I think that the sphere resolution is something that X3D leaves
> > >> as a decision that is entirely up to the viewer program and is not
> > >> specified by the X3D scene itself.
> > >>
> > >> I suppose the idea behind the approach taken by X3D is that the
> > >> viewer could implement the sphere primitive with GLSL shaders
> > >> like I do in VMD and not draw a triangulated sphere at all.
> > >>
> > >> Here's the X3D spec for the sphere geometry node:
> > >> http://www.web3d.org/x3d/specifications/OLD/ISO-IEC-19775-X3DAbstractSpecification/Part01/components/geometry3D.html#Sphere
> > >>
> > >> In this case the X3DOM viewer itself is picking the sphere resolution.
> > >>
> > >> I just spent a couple of minutes digging into the x3dom.js source code
> > >> and on or about line 721 of the code (search for the string
> > >> "latitudeBands"), you can see this:
> > >>
> > >> var latNumber,longNumber;var latitudeBands=24;var longitudeBands=24;var theta,sinTheta,cosTheta;var phi,sinPhi,cosPhi;var x,y,z,u,v;for(latNumbe r=0;latNumber<=latitudeBands;latNumber++)
> > >> [...]
> > >>
> > >>
> > >> Human-readable version (line 721 of my 3 month old copy of x3dom.js):
> > >> var latNumber,longNumber;
> > >> var latitudeBands=24;
> > >> var longitudeBands=24;
> > >> var theta,sinTheta,cosTheta;
> > >> var phi,sinPhi,cosPhi;
> > >> var x,y,z,u,v;
> > >> for(latNumber=0; latNumber<=latitudeBands; latNumber++)
> > >> [...]
> > >>
> > >> I would suggest changing "latitudeBands" and "longitudeBands"
> > >> values to 6 (very coarse), 8, or maybe 12. Any of those
> > >> should give you a very big boost in sphere rendering speed in X3DOM
> > >> vs. what you see when the loops are set to 24.
> > >> Just use values that match the VdW sphere "resolution" parameter
> > >> you prefer in VMD, and that should give you the same general appearance.
> > >>
> > >> You can see similar for loops for Cylinders, Torii, and other shapes, so
> > >> any geometry you want to fiddle with you can just edit the x3dom.js
> > >> source code to get what you want in the short-term.
> > >>
> > >> I'll contact the authors of X3DOM and suggest that they add some
> > >> special tags to let the user override these default resolution
> > >> parameters without having to modify the code... :-)
> > >>
> > >> Cheers,
> > >> John Stone
> > >> vmd_at_ks.uiuc.edu
> > >>
> > >> On Wed, Apr 13, 2011 at 08:09:37AM -0400, Joshua A. Anderson wrote:
> > >>> Hi list,
> > >>>
> > >>> I'm trying out the new X3DOM export (its pretty cool). Has anyone else run into performance issues with exporting VDW representations? Have you found a solution?
> > >>>
> > >>> VMD sensibly emits a <Sphere> node for each sphere in the representation. But the rendering ( at least in Firefox 4 ) uses a ridiculous number of triangles for each sphere and display performance suffers. The little x3dom status display reports over 2 million triangles in a tiny 1800 particle test model I exported.
> > >>> --------
> > >>> Joshua A. Anderson, Ph.D.
> > >>> Chemical Engineering Department, University of Michigan
> > >>>
> > >>
> > >> --
> > >> NIH Resource for Macromolecular Modeling and Bioinformatics
> > >> Beckman Institute for Advanced Science and Technology
> > >> University of Illinois, 405 N. Mathews Ave, Urbana, IL 61801
> > >> Email: johns_at_ks.uiuc.edu Phone: 217-244-3349
> > >> WWW: http://www.ks.uiuc.edu/~johns/ Fax: 217-244-6078
> > >
> > > --
> > > NIH Resource for Macromolecular Modeling and Bioinformatics
> > > Beckman Institute for Advanced Science and Technology
> > > University of Illinois, 405 N. Mathews Ave, Urbana, IL 61801
> > > Email: johns_at_ks.uiuc.edu Phone: 217-244-3349
> > > WWW: http://www.ks.uiuc.edu/~johns/ Fax: 217-244-6078
> > >
> > >
> >
>
> --
> NIH Resource for Macromolecular Modeling and Bioinformatics
> Beckman Institute for Advanced Science and Technology
> University of Illinois, 405 N. Mathews Ave, Urbana, IL 61801
> Email: johns_at_ks.uiuc.edu Phone: 217-244-3349
> WWW: http://www.ks.uiuc.edu/~johns/ Fax: 217-244-6078

-- 
NIH Resource for Macromolecular Modeling and Bioinformatics
Beckman Institute for Advanced Science and Technology
University of Illinois, 405 N. Mathews Ave, Urbana, IL 61801
Email: johns_at_ks.uiuc.edu                 Phone: 217-244-3349
  WWW: http://www.ks.uiuc.edu/~johns/      Fax: 217-244-6078