VMD-L Mailing List

From: Vieri Di Paola (dipaola_at_cli.di.unipi.it)
Date: Wed Mar 01 2000 - 10:41:41 CST

On Wed, 1 Mar 2000, John Stone wrote:

First of all, thank you very much for your incredibly long and interesting
message. (Please scroll down...)

> 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.

Please consider that I have absolutely no documentation. I don't know what
a Z-buffer is although I can imagine... I asked my professor for some help
but he just told me to search the Internet. Books here cost a fortune and
I don't know anybody who can seriously advise me. Is there any way I can
get a tutorial off the WWW on Z-buffering?

OK, let's see if I got it right. I have to imagine that I'm looking down
the Z axis. I can then consider that, for a given atom, I need to draw a
sphere bitmap. Each pixel of this bitmap must have a Z depth value (hence
an int or something, right?). So I guess that the first step is to sort
the atom coordinates taken from the PDB file according to the Z axis? The
atom with the highest Z will come first, and so on... After sorting I
could obtain a struct like so:

struct atom {
 bitmapData including depth value;
 pointer to next atom according to Z;
}

By the way, the depth values are strictly correlated to the Wan Der Waals
radius of each atom, right? In other words, the pixel at the center of the
bitmap will have the radius value, the pixels that make the edge of the
sphere will have value 0 (?) and the intermediate pixels will have, well,
intermediate values. So I'm actually taking care of a hemisphere not a
full sphere. (Please scroll down...)

> 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 :)
>

You wouldn't happen to have that code lying around somewhere, would you?
That would certainly help me out, at least in the basic algorithm...
(Please scroll down...)

> 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.

I need to sort this list each time the user rotates, right?

Well, I'll try to do something at home. I think I got the picture of how
to do it without Z-buffering... :-)

Thanks again, REALLY,

Vieri Di Paola

P.S. If you don't have your C code anymore, do you know of a place on
Internet where I can download a simple demo?

  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!!!
>