Irrlicht Engine

Posted: **Tue May 18, 2010 12:55 pm**

I uploaded a new version. I linked the static ODE lib to IrrOdeCar. I remembered that there are some issues with collisions with static trimeshes if you use the DLL, now this all works. I also replaced the CIrrOdeGeomHeightfield by a CIrrOdeGeomTrimesh for the terrain, that's the advice I got from the ODE mailing list. Works a lot better now.

Posted: **Wed May 19, 2010 12:31 pm**

Hey Brainsaw,

as I was mentioning in a different thread, I'm giving a try to your wrapper on Mac OS X. So far I managed to compile it using Code::Blocks (I just had to manually link the various libraries required and pass some flags to the compiler in order to target a 64 bit architecture). I'm including the wrapper in a demo application I'm writing and also within this piece of software everything compile and link fine.

Nonetheless, the example I copied from the tutorial you wrote seems not working. I get 4 error messages, all of them related to the same issue:

/Users/fruini/Desktop/ODE/irrOde_test_Xcode/main.cpp: In function 'int main(int, char**)':
/Users/fruini/Desktop/ODE/irrOde_test_Xcode/main.cpp:50: error: no matching function for call to 'irr::ode::CIrrOdeGeomBox::getSurfaceParameters()'
/usr/local/include/irrOde/geom/CIrrOdeGeom.h:102: note: candidates are: virtual irr::ode::CIrrOdeSurfaceParameters* irr::ode::CIrrOdeGeom::getSurfaceParameters(irr::u32)
/Users/fruini/Desktop/ODE/irrOde_test_Xcode/main.cpp:51: error: no matching function for call to 'irr::ode::CIrrOdeGeomBox::getSurfaceParameters()'
/usr/local/include/irrOde/geom/CIrrOdeGeom.h:102: note: candidates are: virtual irr::ode::CIrrOdeSurfaceParameters* irr::ode::CIrrOdeGeom::getSurfaceParameters(irr::u32)
/Users/fruini/Desktop/ODE/irrOde_test_Xcode/main.cpp:70: error: no matching function for call to 'irr::ode::CIrrOdeGeomSphere::getSurfaceParameters()'
/usr/local/include/irrOde/geom/CIrrOdeGeom.h:102: note: candidates are: virtual irr::ode::CIrrOdeSurfaceParameters* irr::ode::CIrrOdeGeom::getSurfaceParameters(irr::u32)
/Users/fruini/Desktop/ODE/irrOde_test_Xcode/main.cpp:71: error: no matching function for call to 'irr::ode::CIrrOdeGeomSphere::getSurfaceParameters()'
/usr/local/include/irrOde/geom/CIrrOdeGeom.h:102: note: candidates are: virtual irr::ode::CIrrOdeSurfaceParameters* irr::ode::CIrrOdeGeom::getSurfaceParameters(irr::u32)

The lines generating these errors are those below:

Code: Select all

bx->getSurfaceParameters()->setBounce(1.0f);
bx->getSurfaceParameters()->setModeBounce(true);

pSphere->getSurfaceParameters()->setBounce(1.0f);
pSphere->getSurfaceParameters()->setModeBounce(true);

It seems that getSurfaceParameters can't be used without specifying any parameters. So I just declared a u32 variable called a and passed it to all the above functions. The application now compiles, even if it crashes at runtime while loading the texture of the first mesh (although I believe it might be a mistake on my part), with the following GDB output:

run
[Switching to process 8685]
Running…
Irrlicht Engine version 1.7.1
Darwin Kernel Version 10.3.1: Mon Mar 22 15:13:15 PDT 2010; root:xnu-1504.3.52~1/RELEASE_I386
Using renderer: OpenGL 2.1
NVIDIA GeForce GT 330M OpenGL Engine: NVIDIA Corporation
OpenGL driver version is 1.2 or better.
GLSL version: 1.2
Could not load a texture for entry in 3ds file: cube1_au.bmp
Loaded mesh: /Users/fruini/Desktop/ODE/irrOde_test_Xcode/box.3ds
Loaded texture: /Users/fruini/Desktop/ODE/irrOde_test_Xcode/box0.jpg
Could not load a texture for entry in 3ds file: sphere1_.bmp
Loaded mesh: /Users/fruini/Desktop/ODE/irrOde_test_Xcode/sphere.3ds
Loaded texture: /Users/fruini/Desktop/ODE/irrOde_test_Xcode/sphere0.jpg
CIrrOdeGeomBox::initPhysics: getting size from parent node
CIrrOdeGeomBox::initPhysics: size=(30.00, 3.00, 30.00)

ODE INTERNAL ERROR 1: assertion "bNormalizationResult" failed in _dNormalize4() [../../include/ode/odemath.h]
Program received signal: “SIGABRT”.
sharedlibrary apply-load-rules all
Xcode could not locate source file: odemath.h (line: 326)
(gdb)

That's about it. Have you got any comments to made?

Posted: **Wed May 19, 2010 2:24 pm**

@fabietto: Damnit. The "getSurfaceParameters" method signature changed a while back. The CIrrOdeGeomTrimesh does now have several sets of surface parameters, one for each material of the node it represents. It should work if you pass "0" as paremeter. Try it again this way, maybe the normaliation failure is also fixed this way. Which ODE version are you using? The wrapper is currently made for 0.11.1, the latest stable release.

@Darkcoder: I just uploaded a new version. If you use the car of the IrrOdeCar demo you can press "R" and one of the ramps is removed. Unfortunately I don't know a way to detect if a complete subtree of the scene graph is removed. Is there a way? Seems that the "remove" method is only called for the scene node that is actually removed, not for it's children. But I added a new method called "removeTreeFromPhysics" which removes a complete subtree from physics. It iterates all children of the passed node, and if it is a descendant of "CIrrOdeSceneNode" it's physics will be removed. It's just a workaround, it would (of course) be better if I detected the removal from the scene graph and removed the ODE stuff as well. It's a static method, you can call it with any node of the scenegraph (check the IrrOdeCar example for details, it's around line 130 in CCar.cpp).

edit: I forgot to compile the latest lib with VC-2008, but I'm going to upload a new version within the next days that does also include VC-2008.

Posted: **Wed May 19, 2010 2:38 pm**

Brainsaw wrote:@fabietto: Damnit. The "getSurfaceParameters" method signature changed a while back. The CIrrOdeGeomTrimesh does now have several sets of surface parameters, one for each material of the node it represents. It should work if you pass "0" as paremeter. Try it again this way, maybe the normaliation failure is also fixed this way. Which ODE version are you using? The wrapper is currently made for 0.11.1, the latest stable release.

Thanks for the prompt reply, mate!

I replaced the a variable with a simple 0 value and the application indeed compiles. Still, I get the same error as before. At a closer look, it's not generated when loading the texture (that would have been quite idiotic), but rather when the worldNode->initPhysics() instruction is called.

I'm using ODE 0.11.1, compiled with double precision on a x86_64 architecture, under Mac OS X 10.6.3. By the way, since I'm a complete ODE newbie, I can't be sure that my installation works alright. That's why I'm looking for some simple examples to run in order to check if everything is ok (unfortunately drawstuff doesn't compile on Mac, so I can't test the examples included in the ODE distribution).

Posted: **Thu May 20, 2010 2:31 am**

Brainsaw wrote:@Darkcoder: I just uploaded a new version. If you use the car of the IrrOdeCar demo you can press "R" and one of the ramps is removed. Unfortunately I don't know a way to detect if a complete subtree of the scene graph is removed. Is there a way? Seems that the "remove" method is only called for the scene node that is actually removed, not for it's children. But I added a new method called "removeTreeFromPhysics" which removes a complete subtree from physics. It iterates all children of the passed node, and if it is a descendant of "CIrrOdeSceneNode" it's physics will be removed. It's just a workaround, it would (of course) be better if I detected the removal from the scene graph and removed the ODE stuff as well. It's a static method, you can call it with any node of the scenegraph (check the IrrOdeCar example for details, it's around line 130 in CCar.cpp).

edit: I forgot to compile the latest lib with VC-2008, but I'm going to upload a new version within the next days that does also include VC-2008.

I wasn't able to test the car demo as it seems to load stuff then just go in an endless cycle of resetting the D3D Device, but I compiled the library and tried it in my game using the new static function and I don't see any difference?

My code is now the following:

Code: Select all

blockNode:setParent( phyWorld )
	blockColNode = scene:addSceneNode( "CIrrOdeGeomTrimesh", blockNode )
	blockColNode:initPhysics()
	
	irr.ode.CIrrOdeSceneNode.removeTreeFromPhysics( blockNode ) -- Still does nothing

I also tried changing the parent back to the root scene node before and after that call, I also tried calling this before I remove the node itself like with the ramp code, but the collision mesh still remains.

Posted: **Thu May 20, 2010 12:20 pm**

@fabietto: Hmm ... got no idea where this comes from. I do also see some of these messages, but if you compile ODE with dNODEBUG defined it will just output the warning but not stop the program. It does (normally) run fine with these messages as well.

@Darkcoder: I modified the IrrOdeCar example. It does now also feature the graphics setup dialog from IrrOdeMarble. Maybe it runs with OpenGL on your system. This might give you a better idea of how it should look like (drive the car on the first ramp and press "R" while on the ramp - Woop - the ramp disappears and the car falls down).

Posted: **Thu May 20, 2010 3:53 pm**

When I run in OGL I get the error: 'Assertion "bNormalizationResult" failed in blah\ode\odemath.h:326'.

Either way, I assume your scene is setup through a script/config file as I don't see any mention of "ramp2" anywhere else, so is the code I posted previously any different to what's going on in the car example? Other than me not dropping the visible mesh(this shouldn't really matter?, though I tried it anyway), maybe the way the object is setup differs to the ramp in some way? But you can see the code I use for that so you should be able to see.

Posted: **Thu May 20, 2010 5:18 pm**

Brainsaw wrote:@fabietto: Hmm ... got no idea where this comes from. I do also see some of these messages, but if you compile ODE with dNODEBUG defined it will just output the warning but not stop the program. It does (normally) run fine with these messages as well.

I gave your idea of recompiling with that variable defined a try. Now it's getting a little bit better. Sometimes a get segmentation faults, sometimes alternative errors, but sometimes I can also see the window and the box appearing (nothing happening though...).

Posted: **Thu May 20, 2010 7:18 pm**

@Darkcoder: the scene of IrrOdeCar is stored in an IrrEdit file (data/IrrOdeCar.xml), and there is an animated mesh scenenode called "ramp2" that gets removed. It works this way and I honestly don't see a reason why it doesn't work with your code. Do you have the possibility to debug into the C++ code?

@fabietto: are you using a variable or a #define? dNODEBUG is a compiler switch, most IDEs give you an option to define these in some dialog. Which IDE are you using, maybe I can tell you where (if you don't know of course).

Posted: **Fri May 21, 2010 10:22 am**

Brainsaw wrote:@fabietto: are you using a variable or a #define? dNODEBUG is a compiler switch, most IDEs give you an option to define these in some dialog. Which IDE are you using, maybe I can tell you where (if you don't know of course).

Thanks again for your attention, Brainsaw. For compiling ODE I'm just following the standard procedure via autotools (configure/make/make install). In order to follow your suggestion, I simply modified the common.h header file, adding #define dNODEBUG at about line #60 (right before the #ifndef dNODEBUG block of instructions).

PS: don't you have, by any chance, a simple ODE application (maybe with no graphics or whatsoever) that I can try to see whether my installation works fine?

Posted: **Fri May 21, 2010 11:45 am**

OK, that should work ... I guess. I use the "Project -> build options -> Compiler settings -> defines" tab of Code::Blocks to define dNODEBUG so that it's definately defined everywhere, and assertions won't stop the program.

I don't have any simple application, at least none without the complete wrapper. Maybe you could try to compile the Irrlicht/ODE tutorial (http://irrlicht.sourceforge.net/tut_ode.html) to see if everything works.

Posted: **Sat May 22, 2010 1:27 am**

Brainsaw wrote:@Darkcoder: the scene of IrrOdeCar is stored in an IrrEdit file (data/IrrOdeCar.xml), and there is an animated mesh scenenode called "ramp2" that gets removed. It works this way and I honestly don't see a reason why it doesn't work with your code. Do you have the possibility to debug into the C++ code?

Wow that's a big XML file, I looked at the ramp2 nodes and unless I'm reading this wrong, it uses box collision?

Code: Select all

<node type="CIrrOdeGeomBox">

	<attributes>
		<string name="Name" value="geomRamp2" />

Whereas in my game I'm trying to get this to work using the triangle mesh; as I can't run the example properly, could you try the ramp using the same?

Posted: **Sat May 22, 2010 9:03 am**

OK, seems you're right. I changed the ramp from box to trimesh and the removal doesn't work any more. I'll check this asap.

Posted: **Sat May 22, 2010 9:55 am**

@Darkcoder: I fixed the bug. The problem was located in CIrrOdeGeomHeightfield::removeFromPhysics. Normally one CIrrOdeGeom represents one ODE geom, but a static trimesh does (normally) have more than one ODE geom, i.e. one for each material so that it's possible to have varying surface parameters in one static CIrrOdeGeomTrimesh. I had to implement the removeFromPhysics method in CIrrOdeGeomTrimesh to take care of that. Thanks for reporting and helping me with the solution.

P.S.: the ramp in the IrrOdeCar demo that can be removed does now use a trimesh instead of a box.

Posted: **Sat May 22, 2010 4:17 pm**

Brainsaw wrote:@Darkcoder: I fixed the bug. The problem was located in CIrrOdeGeomHeightfield::removeFromPhysics. Normally one CIrrOdeGeom represents one ODE geom, but a static trimesh does (normally) have more than one ODE geom, i.e. one for each material so that it's possible to have varying surface parameters in one static CIrrOdeGeomTrimesh. I had to implement the removeFromPhysics method in CIrrOdeGeomTrimesh to take care of that. Thanks for reporting and helping me with the solution.

P.S.: the ramp in the IrrOdeCar demo that can be removed does now use a trimesh instead of a box.

Awesome, my game now works perfectly! So I no longer have any excuses to procrastinate

, I'll let you know when I release my game. I've rewritten this so many times and gone through so many physics engines, so it's a huge relief to know there are no issues that stand in my way(until I find them)!

Irrlicht Engine

IrrODE - an Irrlicht - ODE wrapper (now with SVN)