[GEM-dev] sphere

[chris clepper]

I was playing around with some of Cyrille's pmpd patches and noticed 
that he commented on several of them needing lots of CPU to run.  I 
quickly figured out that it was the sphere object that ate most of the 
CPU, and I had already made a note to fix this after Johannes rewrote 
the object.  The big problem is that sphere calculates each and every 
vertex each and every pass even though most of the time the geometry is 
static.  The quick fix I just committed to CVS only calculates the 
geometry when a parameter changes (slices, drawing style, etc).  The 
result is at least a 3X improvement in performance, and most of the 
pmpd stuff runs ok now on my Powerbook.

Now, this is all fine and well, but the object is still in immediate 
mode and thus quite inefficient.  I thought about creating a display 
list inside the sphere object, but that has two drawbacks.  FIrst, 
there is considerable overhead compiling a list and uploading it.  
Second, it would waste a lot of VRAM for something like Cyrille's 
patches.  The idea I have is to try and move as much stuff out of 
immediate (or idiot) mode as possible and try and create a system that 
really scales well for GEM.  I think we could have a type of client and 
server using display lists that would function like this:

[GemCreateList name geo arg1 arg2]

[GemCallList name]

The first object would create a display list with a given name, and 
build a list with the desired geo inside the list.  The second object 
would issue a glCallList() with that given name wherever the user needs 
that geo.  This should be very fast and extremely efficient for large 
scale patches.  It might even help GEM gain a bit of dynamism that it 
currently lacks.

cgc