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

ulao · Post by **ulao** » Fri Jun 19, 2009 2:18 pm

Yeah speed is going to be a big need for this game. Is it one axis or the other the one that causes problems, Could I leave y ( up ) at 1, and just increase x,z?

Ovidiu · Post by **Ovidiu** » Fri Jun 19, 2009 3:27 pm

guys...when I try to compile an example, it says that I have no "ode_singled.lib"

Where can I find that, or how to make that?

When I compiled ode 0.11.1 it came out only "ode_doubled.lib"

Any Idea?

ulao · Post by **ulao** » Sat Jun 20, 2009 3:00 am

Ovidiu wrote:guys...when I try to compile an example, it says that I have no "ode_singled.lib"

Where can I find that, or how to make that?

When I compiled ode 0.11.1 it came out only "ode_doubled.lib"

Any Idea?

You have to change your set up to single. Look at your config properties. That or download delta3d and use theirs.

Brainsaw · Post by **Brainsaw** » Sat Jun 20, 2009 7:41 am

I think the problem arises from the interpolation that ODE does for the terrain. It only queries the points that are defined by the heightmap and does the interpolaration itself. I think that's the problem. I'm changing the CIrrOdeGeomTrimesh object so that it does accept any MeshSceneNode, no only AnimatedMeshSceneNodes, and we will see if it works that way when I'm finished.

Brainsaw · Post by **Brainsaw** » Sun Jun 21, 2009 9:31 am

Hmpf. I'm just uploading a new version with some changes:

- you can now create a trimesh from a ITerrainSceneNode. Works well with VC++, has *a lot of problems* with gcc (like everything but spheres falling right through). I hope I can find a solution for that. The "IrrOdePlayground" demo app now let's you choose whether or not you want to use the Heightfield or the Trimesh for the terrain. If you use Trimesh you can let the application draw the grid of triangles an top of the terrain by pressing "G". If you use this option it is quite a bit slower than using the Heightfield.

- added a demo game: IrrOdeMarble. currently only available as code::blocks project. I'll update the initial post in a second or two.

ulao · Post by **ulao** » Sun Jun 21, 2009 6:35 pm

Brainsaw, great man! So this is a fix to the sacle issue?

How does this play in to the irrOdeEditor?Just do the normal terrain and then create a trimesh from my handle in the code?

Brainsaw · Post by **Brainsaw** » Mon Jun 22, 2009 7:06 am

Heven't tried it in IrrEdit (yet), but you should attach a Trimesh instead of a Heightfield as geom-child of your terrain. But be aware that fast moving object could fall right through because ODE is time-step-based (I think I wrote that in an earlier post), so you might have to decrease your stepsize.

Brainsaw · Post by **Brainsaw** » Mon Jun 22, 2009 1:55 pm

Hello,

I'm just uploading a new update. The main change is in the IrrOdEdit plugin: if you now clone an IrrOde scene node the whole subtree will be cloned. Saves a lot of work, should have done that earlier.

Apart from that: static trimesh/some object other than sphere collision does still not really work in the gcc compiled versions. I got an answer from the ODE group that it might work with ODE 0.11.1, or maybe with the latest SVN trunk. I'll check that some time in the next days. Visual C++ version is working fine however. This problem occurs in two programs:

- the IrrOdeMarble demo game: here some of the obstacles just fall through a trimesh, they stay where they should be in VC++ however
- IrrOdePlayground: if you use trimesh instead of heightfield for the terrain (can be switched at start) it is mostly useless. VC++ version works fine

ulao · Post by **ulao** » Mon Jun 22, 2009 11:02 pm

Some feed back for you. I know you said you were not sure if it would work from the editor.

I just replaced the terrain with a trimesh and ran it got a crash on this first line.

Code: Select all

void CIrrOdeDevice::geomTrimeshDataBuildSimple(u32 iData, IAnimatedMeshSceneNode *pNode) { 
  IAnimatedMesh *pMesh=pNode->getMesh();
  f32 sx=pNode->getScale().X,sy=pNode->getScale().Y,sz=pNode->getScale().Z;

  u32 i,j,ci,cif,cv;

	IMeshBuffer *pBuffer;
  for(u32 i=0; i<pMesh->getMeshBufferCount(); i++) {
    pBuffer=pMesh->getMeshBuffer(i);
    INDEXCOUNT(iData)+=pBuffer->getIndexCount();
    VERTEXCOUNT(iData)+=pBuffer->getVertexCount();
  }

I think during the irr load is where it crashed.
[/code]

Brainsaw · Post by **Brainsaw** » Tue Jun 23, 2009 5:54 am

@ulao: I know that code (CIrrOdeDevice::geomTrimeshDataBuildSimple), it's from an older version

.

I implemented a switch-case because depending on the type of scenenode obtaining a mesh is different (even though it's a "getMesh" method most of the time). You should backup your old version and do an update.

ulao · Post by **ulao** » Tue Jun 23, 2009 1:48 pm

[Looks to make sure no one was looking ] I knew that... you passed my self QA test, congrats!!

Ok lets try this a gain. So we passed that spot and just before the screen tries to draw I have this data output

Code: Select all


                **** CIrrOdeWorld::initPhysics

add space to world
CIrrOdeWorld::initPhysics: init geom
==> 1
ic: 1572864, vc: 263169, iData: 9
263169 .. 1572864
position: 0.00, 0.00, 0.00

And nothing further no video displayed. Can say I ever saw that happen before?

Too much math?

Brainsaw · Post by **Brainsaw** » Wed Jun 24, 2009 5:36 am

OK, the output you see is some debug traces I forgot to remove. The "ic: 1572864, vc: 263169, iData: 9" shows you how many indices (ic) and vertices (vc) the object has and it's internal ID that you (normally) shouldn't care about. It seems that the initialization was OK, but the object is quite big, so it might be a performance issue. For testing try to downscale your terrain (I think the IrrOdePlayground terrain gets downscaled to something like 64x64). If this a performance issue then maybe it would be a good idea to split your terrain into several ODE nodes, but there is no functionality in to do this automatically. Performance is definetely *way better* when using heightfields.

Oh ... but your program runs, it just doen't display anything? Maybe you could also add some trace in your main routine to see whether or not performance is really so bad.

Edit: I did another IrrOdEdit bugfix yesterday: as you may (or may not) have noticed a new CIrrOdeSpace node is inserted every time you load your scenes in IrrOde. This is not necessary, the space of the world is created automatically, so I moved the space-insert code from the constructor to initPhysics.

ulao · Post by **ulao** » Wed Jun 24, 2009 11:59 am

Code: Select all

Performance is definetely *way better* when using heightfield

- Do you think there is a plan to make the heightfield work right? OR does that seem like a no go for now.

I guess another thing I could try is scaling my terrain at 1 and bring everything else down... May try that.

Brainsaw · Post by **Brainsaw** » Wed Jun 24, 2009 1:20 pm

I don't know if they are going to fix it. I don't follow the ODE usergroup as close as the Irrlicht group

. I think it depends. If you want to use it for your character to run or drive around on top of it it's not good enough, but e.g. for an airplane game where the only thing you would do with direct terrain-contact is crashing it would be OK.

Maybe I should ask the ODE group if they could implement a heightfield callback with floats instead of ints in the parameter list so that ODE would leave all interpolation to the called function, Irrlicht in this case. I don't know if this would slow everything down much, but it could be more precise. Unfortunately I do nor have the time nor the insight into ODE to dig into ODE and implement such a function myself.

Try to scale your terrain down, just to see if this helps.

ulao · Post by **ulao** » Wed Jun 24, 2009 2:04 pm

If you want to use it for your character to run or drive around on top of it it's not good enough

- I may try to scale it, but are you saying its not going to work anyways? This is what I need it for.. If you do ask the SDK Team, let make know.. I would hate to go back to irr-newton, yuck!