gnu3dkit-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gnu3dkit-discuss] Sharing geometry


From: Brent Gulanowski
Subject: [Gnu3dkit-discuss] Sharing geometry
Date: Thu, 4 Jul 2002 12:56:15 -0400

Is it better to have multiple shapes sharing one geometry or multiple groups sharing one shape? It appears the G3DGeometryBackend is designed on a 1:1 between shape and geometry. Can multiple groups reference the same shape easily enough?

What if there was a kind of thing, say a spaceship of a certain type, and instead of the parts being separate shape it had been optimized down into one shape with one geometry mesh (I think its called). Now you want to have fifty of these spaceships. So we have a single geometry object and a single shape to manage it. It is counter-intuitive to then make a group object with a single spaceship shape in it, but it seems like it would work fine. It's just a bit inefficient because then the individual spaceship representations have to talk to the shared shape through the intermediary of an array holding only one object.

I do see problems with shared geometry in a detailed simulation, but I think that the memory savings would be worth the effort to solve them.

For example, frame-based animations: Different world entities may be of the same type and use the same geometry, but they would not all be in synch for their animations. Quake 2 character models are a typical example. Except in Quake games, you might have five or six character entities using the same model, so you may as well not bother sharing. In a simulation of hundreds of entities or more (flocks of birds, fish, an army, cars on a freeway) duplicating the geometry would be unsustainable. A couple hundred sparrows wouldn't flap in unison, but the same flapping motions out of synch would be acceptable.

In my game I might have a couple dozen enemy robots with very simple frame-based animations: spinning antennae, waving pincers, whatever, just for looks. It would be nice to have animated textures, too, in the future. So there would be a small set of fixed meshes, and each robot would worry about when to start a particular animation sequence. Some frequently occurring entities won't have any animations at all. So should I make a new GraphNode for non-animated shared-shape entities, and a new Group object for animated shared-shapes entities?

For speed I'll probably want the various geometry objects that are part of an animated sequence to return the same min/max values and avoid triggering a recalculation of the bounding box every frame for every object -- that would be very expensive.

Thanks,

Brent
--
Brought to you by Mail on Mac OS X. Think Different.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]