[ODE] Difference in collision behavior of Trimesh between LinuxandWIndows

[nospam@hardgeus.com]

The only control I seem to have over the debugging symbols for the ODE
build process in Windows is the variable "BUILD=release" in
user-settings...If I set that to debug, I get the error:

OPCODE/OPC_TreeCollider.h:53: sorry, unimplemented: inlining failed in
call to '
void Opcode::BVTCache::ResetCountDown()': function not considered for
inlining
ode/src/collision_trimesh_trimesh.cpp:35: sorry, unimplemented: called
from here

Regarding your last statement about the bug...I honestly am not following
what you're saying.



> You can debug release mode projects, too; just make sure that you
> generate symbol files (PDB for msvc, -g for MinGW).
>
> You can also just build ODE yourself: Create a new project (or make
> file) and add pretty much all the .c/.cpp files from the ODE library to
> it. Set the include path so that it will compile, and build.
>
> It COULD be that what you're seeing is an effect of the bug that was
> just discovered that would arbitrarily smash the stack if the call chain
> was ever different into the trimesh collider -- I don't know when that
> bug got introduced, but it was probably a while ago.
>
> Cheers,
>
> 			/ h+
>
> nospam at hardgeus.com wrote:
>> Hmm, I loaded a plain old cube and dumped the Irrlicht vertex
>> coordinates,
>> and they're the same in Linux and Windows.  That means that the problem
>> is
>> either a) In some weird nuance of how I'm giving it to ODE or b)
>> Something
>> internal to ODE itself.
>>
>> There's one problem with stepping into the ODE code...I haven't been
>> able
>> to compile ODE as debug in Windows, it'll only compile as release...
>>
>> So I'm brainstorming here as to how to solve this problem...Is there a
>> way
>> at runtime to ask ODE whether it's doing single or double precision math
>> (after digging through the archives, it seems that confusion on this
>> point
>> is a common problem) I mean, my config.h indicates that I'm using
>> regular
>> float, but I just wanted to be extra sure...
>>
>> Is there a "base level" test I could run to test trimesh collisions?  I
>> tried compilingt and running the test_trimesh.cpp example that came with
>> ODE, but when I run it I get "could run load accelerators"
>>
>>> You have the source. Just step into the code. The box is neither
>>> mysterious, nor black :-)
>>>
>>> To answer your question: there is no verbose output you can enable.
>>> Your
>>> config is for float, with trimesh support, so that seems good. Maybe
>>> the
>>> data from Irrlicht is different on Linux and Windows? If it uses
>>> DirectX
>>> on Windows, it may be mirrored and winding swapped, for example.
>>>
>>> Cheers,
>>>
>>>           / h+
>>>
>>> nospam at hardgeus.com wrote:
>>>> Yes, the ODE on Gentoo was emerged with double-precision off. My
>>>> config
>>>> file from the Windows machine is below.  I feel a bit uneasy about
>>>> working
>>>> with something that is such as mysterious black box.  Aside from
>>>> waiting
>>>> for the upgrade or messing with esoteric configuration parameters, how
>>>> would I go about debugging what is going on?  Is there any sort of
>>>> verbose
>>>> output I can enable?
>>>>
>>>>
>>
>>
>>
>