Problem with camera "falling through floor"

Tekk · Post by **Tekk** » Sun Dec 16, 2007 4:35 pm

I'm making a "space" demo by putting together little sections of code from tutorials as well as writing some. Right now I'm trying to make it so you can't run through the hills and floor, and instead walk up the hills.

The problem is this: I've loaded my mesh and made a IAnimatedMeshSceneNode for it. I've made a triangle selector and collision response animator. However, whenever I try to move (WASD) it either acts as there's an invisible wall in one direction or falls through the floor and keeps going down indefinately in other directions.

Here's the relevant code snippet: (note that it's mainly taken from the "terrain" tutorial on the forum)

Code: Select all

	//fps cam
	scene::ICameraSceneNode* camera = 0; 
	//camera = smgr->addCameraSceneNodeFPS();
	camera = smgr->addCameraSceneNodeFPS(0,80.0f,300.0f,-1, keyMap, 10, false); //1st value= obligatory 0-2nd value= mouse sensitivity-3rd value handles cam speed
	camera->setPosition(core::vector3df(0,300,0)); 
	camera->setFarValue (  50000.0f  ) ; //sets the distance for the clipping plane, the bigger the farther
	camera->setFOV(1.1f); // a value of 0.5 makes it look alienish
	//camera->setRotation(core::vector3df(0,0,0)); //rotate the camera x,y,z degrees
//-----------------------------------------------------------------------------------------------//		
	// create sky box
	scene::ISceneNode* skyboxNode = smgr->addSkyBoxSceneNode(	
	driver->getTexture("./data/stars.jpg"),
	driver->getTexture("./data/stars.jpg"),
	driver->getTexture("./data/stars.jpg"),
	driver->getTexture("./data/stars.jpg"),
	driver->getTexture("./data/stars.jpg"),
	driver->getTexture("./data/stars.jpg"));
//-----------------------------------------------------------------------------------------------//		
	//add 3d terrain
	scene::IAnimatedMesh* terrain = 0;
	terrain = smgr->getMesh("./data/terrain.x");
	
//-----------------------------------------------------------------------------------------------//	
	//terrain node
	scene::IAnimatedMeshSceneNode* terrainnode = 0;
	terrainnode = smgr->addAnimatedMeshSceneNode(terrain);
	//terrainnode = smgr->addAnimatedMeshSceneNode(terrain, camera, -1);//parents node to camera 
	scene::ITriangleSelector* selector = 0;
	
	if (terrainnode)
	{		

		selector = smgr->createOctTreeTriangleSelector(terrain->getMesh(0), terrainnode, 128);
		terrainnode->setTriangleSelector(selector);
	}

	if (selector)
	{
		const core::aabbox3d<f32>& box = camera->getBoundingBox();
        core::vector3df radius = box.MaxEdge - box.getCenter();
		scene::ISceneNodeAnimator* anim = smgr->createCollisionResponseAnimator(
			selector, camera, vector3df(30,50,30),
			core::vector3df(0,-3,0), 
			core::vector3df(0,50,0));
		selector->drop();
		camera->addAnimator(anim);
		anim->drop();
	}

and a screenshot or 2:

Starting the program:

and when you're falling (this is the bottom of the terrain you see):

Any help is appreciated!

rogerborg · Post by **rogerborg** » Sun Dec 16, 2007 6:55 pm

Hmm... I can't actually see any problems with that. I wonder if terrain->getMesh(0) is definitely returning the right vertex info. I guess we'd need your .x file in order to check that. Do you fancy uploading it somewhere?

Tekk · Post by **Tekk** » Sun Dec 16, 2007 9:33 pm

Here's a rar of the whole program: here

the .x is in the "data" folder in the rar.

The program works fine when the triangle selector and collision animator if blocks are commented out, (but you can go through the floor and walls of course).

rogerborg · Post by **rogerborg** » Sun Dec 16, 2007 11:28 pm

Verdict: ZOMG WTF.

The selector that's getting generated doesn't match the visual mesh, that's for damn skippy.

As to why... phew. The matrices in CTriangleSelector::getTriangles() appear correct. I think the selector (shown as the triangle grid in that snapshot) actually represents the raw vertices in the X file. The X file appears to have a 'joint' that's rotating and scaling the visual mesh, but that transformation isn't being applied to the mesh that's returned from getMesh() (and therefore to the triangle selector created from it).

Hmm, we do know that there's a problem with getMesh() for skinned meshes. I wouldn't have expected it to cause this behaviour, but there it is. This may be one to refer to Luke. I don't want to say the B-word, but if IAnimatedMesh::getMesh() can't be relied on to return a correct mesh (in the sense of matching the visual mesh) any more, then that strikes me as... sub optimal behaviour, to put it politely.

rogerborg · Post by **rogerborg** » Sun Dec 16, 2007 11:31 pm

By the way: providing an exe is about as much use as a chocolate teapot. This is the code that I used (based on your posted snippet) to reproduce this behaviour:

Code: Select all

#include <irrlicht.h>

using namespace irr;
using namespace core;
using namespace scene;
using namespace video;
using namespace io;
using namespace gui;

#ifdef _IRR_WINDOWS_
#pragma comment(lib, "Irrlicht.lib")
#endif

int main()
{
	IrrlichtDevice *device =
		createDevice( EDT_OPENGL, dimension2d<s32>(640, 480), 32);

	IVideoDriver* driver = device->getVideoDriver();
	ISceneManager* smgr = device->getSceneManager();

    scene::ICameraSceneNode* camera = 0;
    camera = smgr->addCameraSceneNodeFPS(0,80.0f,100.0f);
    camera->setPosition(core::vector3df(0,10,0));
    camera->setFarValue (  50000.0f  ) ; //sets the distance for the clipping plane, the bigger the farther
    camera->setFOV(1.1f); // a value of 0.5 makes it look alienish

    scene::IAnimatedMesh* terrain = 0;
    terrain = smgr->getMesh("terrain.x");

    scene::IAnimatedMeshSceneNode* terrainnode = 0;
    terrainnode = smgr->addAnimatedMeshSceneNode(terrain);
    scene::ITriangleSelector* selector = 0;

    if (terrainnode)
    {      
        selector = smgr->createOctTreeTriangleSelector(terrain->getMesh(0), terrainnode, 128);
        terrainnode->setTriangleSelector(selector);
        terrainnode->setMaterialFlag(video::EMF_LIGHTING, false);
    }

    if (selector)
    {
        scene::ISceneNodeAnimator* anim = smgr->createCollisionResponseAnimator(
            selector, camera, vector3df(3,5,3),
            core::vector3df(0,0,0),
            core::vector3df(0,0,0));
        selector->drop();
        camera->addAnimator(anim);
        anim->drop();
    }

    s32 triangleCount = selector->getTriangleCount();
    triangle3df * triangles = new triangle3df[triangleCount];
    selector->getTriangles(triangles, triangleCount, triangleCount);

	while(device->run())
	{
		driver->beginScene(true, true, SColor(255,100,101,140));
		smgr->drawAll();
        
        for(s32 tri = 0; tri < triangleCount; ++tri)
            driver->draw3DTriangle(triangles[tri], SColor(255, 255, 0, 0));

		driver->endScene();
	}

    device->drop();

	return 0;
}

hybrid · Post by **hybrid** » Mon Dec 17, 2007 8:45 am

Yeah, let's call it a bug

Luke kept much "extra" functionality out of the implementation to avoid any slow-downs. This also includes the bbox stuff. We need to improve these things, so let's use this post as a reminder in the bug thread.

rogerborg · Post by **rogerborg** » Mon Dec 17, 2007 10:47 am

Oh, a bug? I was going to say that the new behaviour is bullsh-... er... OK, let's call it a bug.

Tekk · Post by **Tekk** » Mon Dec 17, 2007 12:27 pm

Are there any workarounds I could use until it's fixed?

Tekk · Post by **Tekk** » Mon Dec 17, 2007 1:06 pm

Wait. Couldn't I just:

1. Not texture the X file.
2. Rotate the mesh 90 or 270 degrees (can't tell which by looking)
3. use the appropriate function in Irr to apply the texture in code?

hybrid · Post by **hybrid** » Mon Dec 17, 2007 2:18 pm

I guess exporting into another format or avoiding joints at all would be easier. And why not texture

Tekk · Post by **Tekk** » Mon Dec 17, 2007 10:08 pm

OK, I think I'll just export as 3ds or something and see how it goes.

Thanks guys for your help, and I'll keep you posted.

Tekk · Post by **Tekk** » Tue Dec 18, 2007 1:55 am

I exported it as both 3ds and obj, and they worked.

Thanks again.

rogerborg · Post by **rogerborg** » Tue Dec 18, 2007 10:58 am

Great, I'm glad to hear that got you going again. Out of interest, what modelling package did you use to create that X file? It seems a bit peculiar that it would create it with a joint in it rather than actually transforming the vertices before saving it out.

Tekk · Post by **Tekk** » Tue Dec 18, 2007 12:21 pm

I used Blender 2,41 to fix it, but the original model was from a tutorial where the author of the tutorial used Blender 2.41 also.

bitplane · Post by **bitplane** » Wed Dec 19, 2007 5:12 pm

rogerborg wrote:Great, I'm glad to hear that got you going again. Out of interest, what modelling package did you use to create that X file? It seems a bit peculiar that it would create it with a joint in it rather than actually transforming the vertices before saving it out.

I think frames are also classed as joints. If a chunk of mesh is inside a single frame or attached to just one bone with all weights = 1.0, then it makes more sense to transform the entire buffer to the position of the bone at draw time, rather than to transform each vertex in getMesh.
The problem is that ISkinnedMesh holds these transformations but IMesh/IMeshBuffer has no way of accessing them, so the triangle selectors can't see the local transformations and hold the wrong data.

IIRC the options we discussed for this include-

A) Inverse transform the vertices once at load time if it contains no animation frames.
Pros: Most users don't notice the difference, as getMesh() works fine
Cons: Difficult to move named parts of a static mesh round with bone control - ie doors, elevators, etc.

B) Add transformations to IMesh
Pro: Everything can access the transformations
Cons: Everything has to be re-written to use it, complicating the api. Also transformations shouldn't be part of IMesh as its there to hold mesh data, not context specific stuff like transformations.

C) Mesh loading flags which default to loading a non-animated mesh as a static mesh (SAnimatedMesh containing SMesh). Flags can be set before loading when the user wishes to use bone/frame control.
Pros: Nothing much changes apart from your (rogerborg's) animated mesh triangle selector patch. Most static meshes won't need an animated triangle selector, can be used as normal with octrees etc
Cons: Still needs a special case or disclaimer on ISkinnedMesh::getMesh, or getStaticMesh added or something similar.

D) Remove the optimization and transform all vertices all the time.
Pros: Simple
Cons: Slow, sucks.

Any more ideas? This is a reasonably good place to continue this discussion.