[ODE] Merging multiple geoms into a single trimesh - a few issues

[Jon Watte]

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.

Cheers,

			/ h+


-----Original Message-----
From: ode-bounces at q12.org [mailto:ode-bounces at q12.org]On Behalf Of
Yordan Gyurchev
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
issues


> 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
about
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
happens
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
usually.
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
callback
that enumerates all triangles in a sphere of influence. Then he handles them
in
a more optimised way than we could in the collision system. In general
I've noticed particle systems + general collision detection != good

Thanks,
Yordan


_______________________________________________
ODE mailing list
ODE at q12.org
http://q12.org/mailman/listinfo/ode