VMD-L Mailing List

From: John Stone (johns_at_ks.uiuc.edu)
Date: Wed Mar 01 2000 - 09:30:42 CST

It appears to be working fine, I got both copies...

On Wed, Mar 01, 2000 at 11:30:58AM +0100, Vieri Di Paola wrote:
>
> Sorry if you receive a dupe but I didn't receive my message (fwd) after my
> subscription (majordomo succeeded) to this mailing list. Is everything
> working correctly?

[...]

> Hello vmd-list,
>
> I am a Biology student and wish to make a simple program for viewing pdb
> molecules. I know VMD is the best :-) but, as a small project, I would
> like some information on the following matter. My project consists in
> drawing spheres for each atom. My problem is that I cannot find any help
> anywhere on the Internet that explains an algorithm for efficient >15000
> spheres drawing. I suppose "hidden" spheres (according to a
> certain view angle) shouldn't be drawn, etc... VMD probably uses an
> efficient algorithm for the "spatial" model representation but I realize
> that the source code is quite "loaded" with features that I'm not looking
> for. Can anybody tell me exactly where to look at in the VMD source code?
> Or can anybody tell me where (if) I can find a simple, to-the-point
> tutorial that handles this rendering problem?

VMD uses hardware accelerated OpenGL rendering to draw its spheres...
For best speed on sophisticated hardware, it uses display-listed spheres
which is much more efficient than regenerating them from scratch as they
are drawn. The hidden surface algorithm used is hardware-accelerated
Z-buffering (done for VMD by OpenGL). If you know that you're ONLY going
to draw spheres, there are many other ways of doing it that are much
less general than what VMD does, but that are faster. I know all sorts
of neat tricks for drawing things fast, but since VMD needs to be much
more general-purpose, it can't get away with using very many of these tricks.
I do have a few things up my sleeve for future revs of VMD though :-)

If you really only want to draw spheres, then instead of doing real
geometry like VMD does, I'd recommend using a depth-buffered bitmap
trick.. Make a nice looking bitmap of a shaded sphere. (use a ray tracer
or whatever you like). You'll need both the image itself, as well as a
depth value for each pixel in the bitmap. Now, in order to draw the
"sphere", you just draw (and scale) the bitmap in its position on the
screen. (you only have to do 1 vertex transform per sphere, and one
scale calculation, both are seriously trivial compared to doing it
the way VMD has to do it..) When drawing the bitmap, only replace
pixels that are "closer" to the eye. Pixels that are farther away
don't get drawn. This is just like a normal Z-buffer, but you're doing
it with a bitblt routine for yourself. So, this is actually pretty
easy to write, the main challenge is in the routine for scaling the
bitmap efficiently and doing the depth compares as it is drawn. You can
even use other tricks like cutting the resolution of the depth map by
half on each axis, so that you only store one depth value for every 4
image pixels. There are thousands of little variations you can make on
tricks like this to make it run faster, or look better, or whatever it
is that's most important to you. There may be a way of doing a version
of this using hardware acceleration and OpenGL, but I haven't tried
implementing this trick in OpenGL yet. I wrote some C code that did this
sort of stuff many years ago, before OpenGL, for PC's with MCGA graphics :)

Other tricks to keep in mind: If it isn't important to you to have
perspective in your 3-D display, you can even skip scaling the sphere
bitmaps, just draw them all normal size. This will give you more of an
orthographic looking scene. If you don't care about having the spheres
look correct when they intersect, you can skip doing the Z-buffering, and
sort the sphere vertex list by depth before they are drawn. This may
be a lot faster, esepecially if your sphere bitmaps are being drawn large..

In any case, the first thing you need to be able to do is draw points
on the screen... So my suggestion is for you to write code to draw points
on the screen for yourself. Once you can draw points on the screen,
replace the points with the sphere bitmaps. Its up to you as to whether
or not you want to use OpenGL, Mesa, or your own code to do this...
If you really want it to be fast, you'll either have to find a good
way of implementing this in OpenGL that is easy for most accelerators
to handle, or you'll want to write 100% of it in your own code so you
can implement all of the tricks I mention, which can make a huge difference
in speed. Believe it or not, it is still possible for hand-coded stuff
running on the main CPU to outrun hardware accelerated rendering on most
boards, IF you are doing something very specific like the tricks I've
described above. You could probably render hundreds of thousands of spheres
using this technique at a rate that equals or exceeds that of the best
hardware accelerated OpenGL system out there, given the same required
resulting image quality... The bitmap trick allows you to use a REALLY
nice looking per-pixel shaded sphere, which would require thousands of
equivalent triangles/quads if done the normal way in something like OpenGL.

I hope this makes sense to you, if you have other questions I would be
happy to answer them when time allows. I've been incredibly busy recently.

  John Stone
  vmd_at_ks.uiuc.edu 

-- 
Theoretical Biophysics Group   Email: johns_at_ks.uiuc.edu
Beckman Institute              http://www.ks.uiuc.edu/~johns/
University of Illinois         Phone:  (217) 244-3349
405 N. Mathews  Ave              FAX:  (217) 244-6078 
Urbana, IL 61801, USA          Unix Is Good For You!!!