Re: [pygame] Fun with C modules

[Richard Jones <richardjones@optushome.com.au>]

On Sat, 22 Dec 2001 10:38, Pete Shinners wrote:
> Richard Jones wrote:
> > So anyway, I just _tried_ that approach. All that hard work I'd put into
> > the octree/frustum stuff. *sigh*
> >
> > So I can't _change_ the landscape, and now I understand why that doesn't
> > happen in games. Instead of stuffing my triangles into the octree, I just
> > stuffed them into a display list. Frame rate went up from 42fps to 88fps.
> > Without me converting any of the tris to tristrips.
> >
> > Lesson learnt for today :)
>
> stuff each octree into a display list, and you can still use both. then
> you can just draw all the polys in an octree with a single call.

Had thought of doing that - and might still give it a try. I suspect a more 
optimised landscape structure is in order - since the ground is a regular 
grid, I can do much more optimal checking against it than some arbitrary 
octree.


> or i'd still say use the vertex buffers with Numeric python. then you
> can also have deforming terrain without a speed penalty. the display
> lists may still be a little quicker, but i don't expect it would be
> much. on the other hand, vertex buffers might actually be a win, since
> opengl only needs to transform each vertex once, instead of once for
> each polygon that uses it (four times for grid data).

I will investigate these strange "vertext buffers" you speak of, once I've 
finished sewing together the last batch of christmas presents (just giving my 
poor abused pin-pricked fingers a rest for a moment :)



> although, if your landscape is just heightfield data, it's probably
> really a 'quadtree' instead of an 'octree'. haha </nitpick>

Absolutely - though as I mentioned, I intended to put all the other objects 
from the game into the octree (which I will still do)


    Richard
____________________________________
pygame mailing list
pygame-users@seul.org
http://pygame.seul.org