[ODE] Bug or feature?

[Rodrigo Hernandez]

Jon Watte wrote:

>The memory in a VBO is not valid to read after you have un-mapped the 
>VBO, and you cannot draw out of a VBO that's currently mapped. Thus, 
>you HAVE to keep your graphics data in a separate place from your 
>collision data, if you want to use VBO. This is very similar to D3D 
>vertex buffers, which have the same restriction.
>
>Now, it could be that for some drivers, for some situations, doing 
>something like that might work -- but probably only on your machine, 
>and certainly not while you're attempting to demo to someone else, as 
>it's explicitly defined as "not supported behavior" in the GL spec.
>
>  
>
I thought you could read it if you created it with the 
GL_STREAM_DRAW_ARB parameter, in any case, VBO's have the drawback that 
there must only be one tex coord per vertice, so, if you have a vertice 
that has 2 or more UVs, (like a cube with a picture on each face) the 
VBO ends up with quite a bit of redundant data, for that reason I 
decided to keep the raw data around (less redundancy).

Anyway, I have an immediate mode rendering function which uses the raw 
index, uv and vertex buffer of my level, this is the buffer I am passing 
to ODE.

>I would recommend against that. If you need to store your vertices in 
>a custom array, I would just declare that array using my own float[3] 
>type.
>
>  
>
Thats what I am doing, but collision is not working, I believe this is 
due to my data being a dynamic array of struct{float x,y,z} which is 
mapped to a dVector3 (which is really 4) inside 
dGeomTriMeshDataBuildSimple, I saw that v[0][0] is alright, but v[3][0] 
gets garbaje due to the padding.

I think the "bug" is really in dGeomTriMeshDataBuildSimple.

Still I fell there is a "why do they call it love when they mean sex" 
situation regarding dVector3 ;) but thats just me and I am new around here.

>If you have the time, you can make a change and add it to the unstable 
>branch once it's working; I don't think anyone would mind.
>  
>
I am already working in it ;).