[ODE] Merging multiple geoms into a single trimesh - a few issues
hplus-ode at mindcontrol.org
Fri Jan 14 08:51:45 MST 2005
Another reason for wanting triangle rather than material information
is that you might want to sample a texture map based on the impact
point (by mapping triangle U,V values). Material ID can't do that.
However, if we would be so bold as to add TWO 32-bit quantities to
the contact struct, and label them "geomMaterial", then each of the
geoms colliding could provide whatever is convenient. The non-trimesh
geoms could have a dGeomSetMaterial() function which would return a
hard-coded value; the trimesh would by default do that, but perhaps
have an option to store the triangle index, OR store an integer
stored within the triangle data. The quantities need to be 32-bit,
because triangle vertex index values are 32-bit. Maybe we should
make them size_t, so that a pointer could be stored, even.
From: ode-bounces at q12.org [mailto:ode-bounces at q12.org]On Behalf Of
Sent: Friday, January 14, 2005 1:01 AM
To: ode at q12.org
Subject: Re: [ODE] Merging multiple geoms into a single trimesh - a few
> We're probably all going to tailor a solution for our own needs.
> However, if it came to a "common" solution merged into ode, I think
> storing 2 triangle indexes is a more general way to go.
Putting two triangle indices leaves you with no option for putting info
non trimesh geoms. If you want you can put the triangle index as well if
you have trimesh but seems very specifc case. You can still implement
your grouped approach for matrials and provide material index.
In my case trimehses a opaque classes I load them from file (including the
AABB) and set them as static geometry... then unload them.. no processing
is done on them. In fact even if there is a animated physics everythign
with transforms outside the trimesh geoms.
> For example, I have materials, but they are grouped, so I can obtain the
> material index in a manner such as this:
> material 0: index 0 -> 30
> material 1: index 31->100
> This is a different way than a set of stored material ids per triangle,
> and it would be inefficient to make a huge list of ids that were
> practically identical.
This approach trades space for lookup performance. It all matters on the
size of the material list which I admit is not more than 10 materials
Complexity of material lookup O(N) where N i number of materials, while
saving TriCount * integer space.
This also asumes that triangles need to be sorted by material in the trimesh
to avoid worst case scenario material searches. So you trimesh is dependent
on your materials anyway noahter reason to put material derivation in the
trimesh class. But I like your approach might change to that.
Its probably also good to look into some DXT like compression for the
material list that supports fast lookups.
> Also, it may be useful to be able to get our hands on the actual
> triangle, for particle systems, breaking glass, etc.
We already do that in a separate way... the particle guy has a separate
that enumerates all triangles in a sphere of influence. Then he handles them
a more optimised way than we could in the collision system. In general
I've noticed particle systems + general collision detection != good
ODE mailing list
ODE at q12.org
More information about the ODE