Irrlicht Engine

Okay, built my own ODE binaries with the new opcode trimesh collider but that doesn't change anything. Isn't everything normalized correctly... *getting desperate*... :/

It's all running with double precision now, your snipped gives:
ODE ODE_EXT_trimesh ODE_EXT_opcode ODE_double_precision
I don't have ODE_OPC_new_collider enabled and the code works for you having it.
Might that thing cause my error?
[Seems like I need to compile ODE myself to test that. Would ...

The cylinder direction thing was caused by a change from dSINGLE to dDOUBLE in the Debian ODE binary, got it fixed.

Next issue (-.-, can't this simply "work"?):
My trimesh falls down 2 or 3 meters, hits a cylinder standing upright on the groundplane like a wheel. The cylinder gets pushed aside ...

Okay, it took a while for me to find out that dTriIndex doesn't exist in ODE 0.9 yet, so I had to install 0.11 (which luckily also resides in Debian Sid) - now I'm still getting an error about a bad direction number for dMassSetCylinderTotal which is indeed 3 (for z axis) and therefore NOT bad, but ...

KH: Glad yours works :) - mine doesn't yet though...
randomMesh: Could you give me the lines where the vertices and indices arrays are declared?
corresponding to:
this->vertices = dVector4[vertexcount];
this->indices = new dTriIndex[indexcount];
Unfortunately, I cannot seem to get a proper array ...

Umm... I'm using the default and since gdb complains about the Opcode::AABBCompute function, I seem to be using opcode.

Thanks for your hints :)

Blindside's suggestion is in, but didn't solve the problem.
KH: When I integrate your idea, g++ complains about this:
../src/CGameObject.cpp: In member function ‘void CGameObject::createTrimeshGeom(const char*)’:
../src/CGameObject.cpp:63: error: pointer of type ‘void ...

Hello,

I'm currently trying to get a TriMesh from Irrlicht also into ODE to do collisions with it. For not having it twice in memory I take the mesh data from Irrlicht and pass it on to ODE, but on creating the trimesh data, ODE fails at this point according to gdb:
[...]
Load track chunk.
Load ...

Wow, I have always dreamed of creating a game (and am doing another project right now) in which one can go down from outer space to some landing strip on the surface of a planet, this is simply awesome! Keep it up! :D
I'd love to see this evolve to a lively universe full of fun going down on ...

Sorry if this sounds stupid, but I don't really get further on this:
I have told gdb to look into the irrlicht source directory (gdb ./40tons -d /home/marcel/code/c++/40tons/Irrlicht), but when I tell it to create a breakpoint at CIrrDeviceLinux.h:createWindow, it says this source file doesn't exist ...

After ~20800 steps, I get to this output:
(gdb) step
irr::core::heapsort<irr::CIrrDeviceLinux::SKeyMap> (array_=0x9c70958, size=185)
at ../../include/heapsort.h:58
58 for (i=size-1; i>=0; --i)
(gdb) step
60 T t = array_[0];
(gdb) step
61 array_[0] = array_[i];
(gdb) step
62 array_[i] = t;
(gdb ...

(gdb) run
Starting program: /home/marcel/code/c++/40tons/40tons
[Thread debugging using libthread_db enabled]
Irrlicht Engine version 1.4.1
Linux 2.6.25-9.slh.1-sidux-686 #1 SMP PREEMPT Tue Jun 24 23:26:13 UTC 2008 i686
Creating X window...
XErrorEvent: BadValue (integer parameter out of range for ...

No compiz, but proprietary nvidia-driver for 3d-acceleration.

How do I find out what is getting called in which way? Let gdb have a look at it?

xrandr: http://rafb.net/p/XapzUW42.html
glxinfo: http://rafb.net/p/4QlNDT20.html

Although xrandr output is not representative, normally I have a 17" CRT @ 1024*768 here.

I was just having a look at some code I once wrote (to continue working on it), but once I try to start this thingy, Xorg complains about some wrong window parameters:
Irrlicht Engine version 1.4.1
Linux 2.6.25-9.slh.1-sidux-686 #1 SMP PREEMPT Tue Jun 24 23:26:13 UTC 2008 i686
Creating X window ...