VMD-L Mailing List

From: John Stone (johns_at_ks.uiuc.edu)
Date: Wed Apr 13 2011 - 12:51:08 CDT

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