[ODE] Trimesh collision: not all triangles are colliding
Pierre Terdiman
pierre.terdiman at novodex.com
Wed Jan 14 10:51:53 MST 2004
> We are using ODE 0.39 and Directx. Can confirm that the OPCODE trimesh
build
> strides is not able to work with the sizeof directx indices. The input to
> directx
> draw primitives requires them to be a short. (2 bytes on win platform).
This
> makes
> a stride for opcode of 6 bytes for the indices. There is an inbuilt check
> that the
> stride for indices is a minimum of 12 bytes. I don't know why Pierre has
> limited
> the strides to 12 bytes. This is not a problem for D3DVERTEX which is much
> bigger.
>
> So use the OPCODE trimesh build using strides you will need to do a pre
> convert your
> indices to a list of 4 byte ints so your stride becomes 12 bytes. You can
> then discard
> the list after the build.
>
> Pierre
> Can you comment. Its a pity we have to do this. Its not a problem for me
> now, I have it
> working like a train, but I bet this bites everyone using directx at
first.
1) The built-in check is this:
if(tri_stride<sizeof(IndexedTriangle)) return
SetIceError("MeshInterface::SetStrides: invalid triangle stride", null);
That's pretty obvious : if I allow both 16-bit & 32-bit indices, it forces
the lib to check the format each time it needs to access indices, or to
duplicate all code paths. None of this is a good idea in my book.
2) Come on, you DO NOT want to read from AGP or video-memory buffers, do you
? Index-buffers are "first class citizens" on modern cards (e.g. even on my
"old" Radeon 9000), so they're not stored in system memory anymore, so
reading from them is slow. If you want to do that anyway, it means you don't
care about speed. If you don't care about speed :
3) Use callbacks instead of pointers (OPC_USE_CALLBACKS). It's actually
almost as fast as direct access, and allows you to use whatever format you
want (e.g. decompressing collision geometry on-the-fly). Speaking of which :
4) You may want to use a dedicated geometry for collision detection anyway,
decoupled from rendering data (e.g. a simplified version, trilists while
render data is stripified, cleaned meshes without duplicate vertices or with
smooth normals, etc, etc, etc, too many reasons to list).
In any case I won't change the way it works because there's already a
solution (callbacks).
Pierre Terdiman
- Novodex AG (www.novodex.com)
- Personal : www.codercorner.com
More information about the ODE
mailing list