Collision mesh.

christianclavet · Post by **christianclavet** » Wed Jun 03, 2009 2:24 pm

Hi,

Irrlicht support OCCTREEs right now and terrains for use with the collision system.

Would it be hard to use a replacement mesh that define the collision? I mean another mesh as the visual thing (a simplified version), that will not be visible but that the collision system will use with the collisionsphere?

Occtrees are not that bad, but on some details of a geomety (principally stairs), it tend to get stuck. Creating our own mesh, I think would would fix that (Another advantage of this is that this mesh could also be used as a NAVMESH)

xDan · Post by **xDan** » Thu Jun 04, 2009 10:06 am

isn't it as easy as replacing the first parameter when calling createOctTreeTriangleSelector with a different mesh?

FuzzYspo0N · Post by **FuzzYspo0N** » Thu Jun 04, 2009 2:41 pm

If you are using irrlicht as the collision system it would take a little bit of work, but not too much i dont think. i just think it will be incredibly slow. (havent tested, though)

christianclavet · Post by **christianclavet** » Thu Jun 04, 2009 4:28 pm

The collision mesh would be a very simplified version of the "visual" thing. No sure it would be so slow. The only "work" that this will require is that I must model the collision mesh. (As let IRRlicht define that with the OCCtree algorythm). The OCCtree is very good for beginner that can't model. But since I can...

By the way, a lot of game compagnies ask their level designers to "model the collision". I would simply like to do the same.

xDan can you elaborate more? I could replace the parameter, but then, the mesh collision would be simplyfied by the occtree algorythm (not alway where I need it) and I would have to display it. Do you know of a trick to hide the mesh(occtree), but keep it active in the collision system?

That is one thing I've tried with my level demo in 2007 and the player was falling and not touching anything. (Hide the occtree used for collision)

Here is the command to make an occtree.

virtual ISceneNode * addOctTreeSceneNode (IMesh *mesh, ISceneNode *parent=0, s32 id=-1, s32 minimalPolysPerNode=256, bool alsoAddIfMeshPointerZero=false)=0
Adds a scene node for rendering using a octtree to the scene graph.

The minimalPolysPerNode=256 parameter... If I put a very high value. Would it enable the occtree to be more precise? This would give me a temporary solution.

EDIT
Oupssss! I think guys that you already done the thing for me (never used it before I think)
There is a function like this:

virtual ITriangleSelector * createTriangleSelector (IMesh *mesh, ISceneNode *node)=0
Creates a simple ITriangleSelector, based on a mesh.

Can I use that and hide the mesh once it has been put in the triangle selector? From what I understand about collisions, the mesh would be put *AS IS* in the triangle selector used for collision. I never used that command before.
EDIT2
Tried it, it "collision", but the result is as bad as before. I will have to rethink how I send levels to IRRlicht. It doesnt work. The collision sphere is still blocked everywhere.

CuteAlien · Post by **CuteAlien** » Thu Jun 04, 2009 5:07 pm

The octree of the octreescenenode isn't used for collision (though I hope I find time to patch that someday to at least allow re-using it). You always have to add triangle selector yourself for collisions. And there you have the choice which format to use - createOctTreeTriangleSelector or createTriangleSelector or I suppose you could even use own triangle selector formats.

So yeah, works like you guessed - you can use createTriangleSelector and just hide that mesh.

But I think you also misunderstand what octrees are doing. They are not simplifying the mesh. It is rather a way of referencing the triangles in a way which allows accessing them faster. This can optimize collision speed a lot. In most cases they will be way faster than a normal triangle selector. The octree is a tree so the minimalPolysPerNode does set how many polygons are put in a each node of the tree. The higher this value is the more flat a tree can be - but also the longer searching through each node will take. You can experiment to find the optimal value for each level.

christianclavet · Post by **christianclavet** » Thu Jun 04, 2009 5:52 pm

Thanks CuteAlien.

Yeah. Tweaked the value and found out, that the lower the value, the more nodes are created.

Thanks for giving me more details on the OCCTrees. I really help.

I think something is wrong with the triangleselector with my current level. The collision is ok at the beginning of the level. I can even climb a staircase without any problem, but when I'm entering a big room with lots of pillar, I get stuck into "invisible walls". Sometime jumping help me get out so I could move a little before getting stuck again.

Right now, this level is a single mesh exported from Hammer and converted into a B3D mesh. I'm thinking, that I should create multiple part from this level so it create multiple triangle selectors and not only a single one for all the level.

I would separate the element this way:
- part 1: only walls
- Part 2: only staircases (perhaps an object for each staircase)
- Part 3: only pillar (one object per pillar)

I don't have the time to go into all that detail right now just to check. But I could try at least to check with only walls to see if it improve the collisions. Shouldnt get stuck the way it does now. I have to find a proper method to send the mesh to IRRlicht.

CuteAlien · Post by **CuteAlien** » Thu Jun 04, 2009 6:03 pm

I had those stuck-in-the-invisible-wall problems already a few times. Mostly it wasn't walls at all but a too sensitive collision code that had problem with certain polygons on the floor. You might try first if removing the pillars really does fix your trouble.

Mel · Post by **Mel** » Sat Jun 06, 2009 4:12 pm

It would be nice that you could attach some sort of collision mesh to the ISceneNodes you want to colide with.

I mean, this would require 2 meshes, one to be rendered and another to colide with, which wouldn't need to be rendered. The idea is to have a simple collision mesh attached to a mesh which is visually complex. That is the way the Torque game engine works, for example.

Dorth · Post by **Dorth** » Sat Jun 06, 2009 4:42 pm

That's a game engine, not a graphic engine.

CuteAlien · Post by **CuteAlien** » Sat Jun 06, 2009 5:32 pm

Mel wrote:It would be nice that you could attach some sort of collision mesh to the ISceneNodes you want to colide with.

I mean, this would require 2 meshes, one to be rendered and another to colide with, which wouldn't need to be rendered. The idea is to have a simple collision mesh attached to a mesh which is visually complex. That is the way the Torque game engine works, for example.

Hm, either I don't get want you mean or this is exactly what we described above in the thread. All collision happens on collision meshes - most people use the mesh of the scenenode but there is no need to do so - you can use any mesh and it can also be invisible.

dlangdev · Post by **dlangdev** » Sat Jun 06, 2009 5:57 pm

Yeah, that's a good idea. Been trying that on Blender, one for rendering and the other for collision.

For static, two meshes may be needed.

For animated, I think the bones are enough for capsules to fit in.

See for example: http://developer.valvesoftware.com/wiki ... th_Blender

dlangdev · Post by **dlangdev** » Sat Jun 06, 2009 8:29 pm

By the way, for Blender 3D users the best route would be to use readblend.c, add layer feature in that code. At the moment, only meshes and objects are read.

I'm pretty optimistic about that code improving and having the ability of reading sector and portal layer as well.

Nadro · Post by **Nadro** » Sat Jun 06, 2009 9:41 pm

Hmmm.... if You use external physic engine it's possible very easy. If You use Irrlicht You can do this trick:

Node with graphic - visible model [A]
Node with physic - hide model

You do all physic operations only on B node and after it You update A node position, rotation etc from B node.

Mel · Post by **Mel** » Sun Jun 07, 2009 12:25 pm

Dorth wrote:That's a game engine, not a graphic engine.

No, i was speaking about it collision system, not the game engine itself.

@CuteAlien. Well, i was speaking about the ISceneNodes having their own collision meshes, diferent from the meshes they render, but i was forgetting how do the collision meshes work in Irrlicht. My bad. It was what people saw before.

dlangdev · Post by **dlangdev** » Sun Jun 07, 2009 7:33 pm

Looks like the code for setting up the Triangle Selector also builds a new mesh buffer just for collisions. So yeah, you can pass a simplified mesh to the parameter and it will build the Triangles using that mesh.