Collision/Visiblity wackiness

[ElectroDruid]

Hi,

I should probably start by explaining what I'm trying to do with regards to laying levels out in my game. I want to build 3D levels from a selection of "tiles" (kinda prefab sections of geometry which snap together - imagine a 2D tile engine, but using cubes instead of quads to add the 3rd dimension). The levels are specified in an XML file, which basically stores the position and rotation of each tile, along with two indeces into a lookup table for filenames to load - one file for the visual mesh, and another file for the collision mesh. The idea is that a lot of the collision meshes will be reusable under different visual meshes, and I'm will to trade a bit of memory for levels with simple, low poly collision detection but higher-poly visuals. The overall idea is to be able to put levels together quickly from lots of re-usable parts, which will cut down on development time and on downloads if I share my game online (at the expense of risking some of the levels looking a bit same-y if they're badly designed).

So far, so good. When I've parsed the information from the XML file, I go through each tile instance, load the appropriate meshes if they're not loaded already, and then add a scene node for the visual mesh for each tile, and another one for the collision mesh for each tile. I call setVisibility(false) on all the collision scene nodes. Then I set up a triangle selector for each collision tile, and then I have every game object which needs to collide with the level geometry call a function - the function loops through every collision tile, and sets up a collision response animator for each one.

So I guess my first question is does this seem like a reasonable way to do things, or am I being hopelessly naive in some way? It strikes me that keeping all these seperate collision tiles kicking about could turn out to be pretty inefficient for larger levels - what I really want to do is find a way to construct some kind of single octree from all of the collision, and then use that in the same way you might use a BSP map for collision. Is there a way to do that? For that matter, is there also a way to fuse the visual meshes together into a single scene node as well? I'm only dealing with static level geometry here, so once it's in the game and up and running, there's no particular reason to keep it as tiles.

My second question (assuming I haven't made some huge oversight, and what I'm doing sounds reasonable) is whether visibility has an effect on collision. The codebase doesn't look like it should, but I'm seeing some weirdness. If I turn the visibility on for the collision nodes, obviously the level looks terrible and z-fights like crazy, but the collision mostly works. It seems a bit sticky in places, but the camera collides with the collision meshes. But if I turn the visibility off, the whole thing goes to hell. Invisible walls pop up where they shouldn't, and I can fly right through previously solid walls. I haven't yet been able to work out a pattern as to where the collision goes wrong, but it seems to bear no resemblance to either the visual or the collision meshes.

Has anyone else encountered this? I can post some of my code if it will help to explain my problem.

Cheers.

[anandh]

It may be helpful for u

You create metatriangle selector.
In your world add all ur world props for example

Code: Select all

scene::IMetaTriangleSelector* world = smgr->createMetaTriangleSelector();    
//box

scene::ISceneNode* box = 0;    
scene::ITriangleSelector* boxselector = 0; 
box = smgr->addTestSceneNode(); 
boxselector = smgr->createTriangleSelectorFromBoundingBox(box); 
box->setTriangleSelector(fireselector); 
world->addTriangleSelector(boxselector); 
boxselector->drop(); 
//player 
. 
. 
. 
. 
//your collision response animator 
scene::ISceneNodeAnimator* anim; 
anim = smgr->createCollisionResponseAnimator( 
world, player, core::vector3df(10,8,50), 
core::vector3df(0,gravity,0), 
core::vector3df(0,0,0)); 
player->addAnimator(anim); 
anim->drop(); 
world->drop(); 

single Collision response animator is enough.

If u dont want collision u just remove tri selector

Code: Select all

selectedSceneNode->setVisible(false); 
world->removeTriangleSelector (selectedSceneNode>getTriangleSelector ()); 
selectedSceneNode = NULL; 

regards
anandh

[ElectroDruid]

Thanks for the heads-up on the Meta Triangle Selectors, got that running fine now. Out of interest, do you tend to uses one metatriangle selector for everything collidable in your game, or build a few metatriangle selectors, one for each group of objects (so, one for the level mesh, one for static level geometry, one for characters etc)?

I also found the root of the problems I was having with collision after making the nodes invisible. Because they were set to invisible without ever being rendered, the OnPostRender() function was never calling updateAbsolutePosition() - Presumably that's an optimisation of some sort, assuming that invisible things never move). So I just called updateAbsolutePosition() after setting the tile's initial positions and rotations, and it all works fine.

[monkeycracks]

I make a MetaTriangleSelector for Characters, Static Objects, Critters, etc. And then a Master one(just what i name it) that includes all triangle selectors.

Works good for me.

[ElectroDruid]

Cool. Incidentally, are the metatriangle selectors optimised in any way compared to using lots of seperate triangle selectors, or do they just act as a way to simplify the interface? And is there a way to treat the polygon soup of all the level collision tiles as an octree?

Also, is there something similar that can be done to group the scene nodes (some kind of metascenenode) so that I can treat the combined level tiles as a single entity for rendering? Would it make any difference to anything if I did that?

[monkeycracks]

Maybe you could do...


ISceneNode whatever;
whatever->addAnimatedMeshSceneNode(mesh);
//material properties here//

whatever->addAnimatedMeshSceneNode(mesh);
//material properties here//

whatever->addAnimatedMeshSceneNode(mesh);
//material properties here//

whatever->addAnimatedMeshSceneNode(mesh);
//material properties here//

you would just have to make a different triangle selector for each mesh.