Ogre Forums

Posted: **Wed Jun 23, 2004 7:55 pm**

First of all congratulations for your work. Everybody is happy

I'm trying to use Ogre with ODE or ODE with Ogre (as you prefer) and I'm getting a lots of troubles. First of all I was compiled the double precision version of ode and I always get an NaN error in the collision handling. But right now I've compiled the single precision version, and it seems to be working fine (without the NaN problem). Did some of you get the same problems? Could it be cast conflits between Ogre Real and ODE dReal floating points?

And another thing: right now the collisions doesn't seem to be very well since the objects sometimes submerges to the plane. You can see a video file here (it's very small).

I've loked already to your code, and I don't understand what I'm doing wrong in my collision detection scene.
If anybody want to look to my source code it can be found here

Thanks!

Miguel

Posted: **Thu Jun 24, 2004 1:06 am**

For those who want to drive car with a follow cam can replace the actual LookAt code in OgreOdeTestApplication.cpp with this one.

Use M key to fllow Car/LastObject

Code: Select all

// If we're looking at something then adjust the camera
	if(_looking && _test->getLastNode())
	{
		mCamera->lookAt(_test->getLastNode()->getPosition());

		// added by Ahmed --------------
		const Real followFactor = 0.1;
		const Real camHeight = 5.0;
		const Real camDistance = 7.0;
		Quaternion q = _test->getLastNode()->getOrientation();

		Vector3 toCam = _test->getLastNode()->getPosition();

		toCam.y += camHeight;
		toCam.z -= camDistance * q.zAxis().z;
		toCam.x -= camDistance * q.zAxis().x;
		mCamera->move( (toCam - mCamera->getPosition()) * followFactor );
		// --------------------------------
	}

Thanx monster.

Posted: **Thu Jun 24, 2004 2:08 am**

supersuper wrote:I changed _time_step to 0.02 (original was 0.05). I never bothered to measure fps with the original setting. It runs fast now on my 600mhz because I turned the shadows off.

Actually, the original was 0.005 = 200Hz, as I say, this is one of the things that needs to be tunable in the future. And yes, shadows make a heck of a difference even on my 3.2GHz machine.

tlaloc wrote:First of all I was compiled the double precision version of ode and I always get an NaN error in the collision handling...right now the collisions doesn't seem to be very well since the objects sometimes submerges to the plane.

I've never used the double precsion version of ODE, so I wouldn't know. If contacts are spongy it's usually down to the CFM and ERP values being wrong and/or gravity and masses being too high.

ahmedali wrote:For those who want to drive car with a follow cam...

Cool! Thanks, i'll incorporate that (or something similar) into the demo.

Posted: **Thu Jun 24, 2004 10:10 am**

monster wrote:Yeah, I'd love to see some examples.

Here's a very basic example-

It still has a lot of flaws, I know, but it's a start

-psy

Posted: **Thu Jun 24, 2004 6:45 pm**

monster wrote:
supersuper wrote:I changed _time_step to 0.02 (original was 0.05). I never bothered to measure fps with the original setting. It runs fast now on my 600mhz because I turned the shadows off.
Actually, the original was 0.005 = 200Hz, as I say, this is one of the things that needs to be tunable in the future. And yes, shadows make a heck of a difference even on my 3.2GHz machine.
tlaloc wrote:First of all I was compiled the double precision version of ode and I always get an NaN error in the collision handling...right now the collisions doesn't seem to be very well since the objects sometimes submerges to the plane.
I've never used the double precsion version of ODE, so I wouldn't know. If contacts are spongy it's usually down to the CFM and ERP values being wrong and/or gravity and masses being too high.
ahmedali wrote:For those who want to drive car with a follow cam...

Cool! Thanks, i'll incorporate that (or something similar) into the demo.

Yep, that's what I meant

0.005

Posted: **Fri Jun 25, 2004 3:12 pm**

I'm trying to use your classes for the simulation, and I'm getting severall problems. For instance if I use Your Crate.mesh the simulation plays well, but if instead of Crate using the cube.mesh or even the robot.mesh (setting the geomBox using the bounding box) the collision stuff dosn't work.

Are someone getting the same problems? Do you do the offset correction of the nodes and bodys when updating? I've had some troubles duw to that issue. I have tried with and without the offset correction.

here is the code:

Code: Select all

	
.....
mRobot = mSceneMgr->createEntity("robot","Crate.mesh");
	mRobotNode = mSceneMgr->getRootSceneNode()->createChildSceneNode("robot");
	mRobotNode->attachObject(mRobot);
	mRobot->setNormaliseNormals(true);
	mRobot->setCastShadows(false);

	//mRobotNode->scale(1.8,1.8,1.8);
	mRobotNode->showBoundingBox(true);
	mRobotNode->setPosition(0,100,0); //-20,100,30


	Vector3 pos(0,100,0);
	Vector3 scale(1,1,1);
	//creating the body
	_box = new OgreOde::Body();
	mRobotNode->attachObject(_box);

	Mesh* mesh = mRobot->getMesh();
	size_t indices_needed = 0,vertices_needed = 0;
	bool added_shared = false;

	Vector3 offset;
	Vector3 sides = transformOgreCoords(mRobotNode,"robot",&offset);
	//setting the mass and geometry
	_mass = new OgreOde::BoxMass(1.0,sides);
	_mass->setDensity(5.0, sides);
	_geom = new OgreOde::BoxGeometry(sides, _space);
	_box->setMass(*_mass);
	
	Vector3 position = offset + mRobotNode->getPosition();

	_box->setPosition(position);//mRobotNode->getPosition()
	_box->setOrientation(mRobotNode->getOrientation());
	
	_geom->setBody(_box);
.....

Code: Select all

Vector3 DemoApplication::transformOgreCoords(SceneNode *node, String name, Vector3 *offset){//, Vector3 pos, Real *side){
	Vector3 pos = node->getPosition();
	Vector3 midpoint, side, sides, minBox, maxBox, scale = node->getScale();

	AxisAlignedBox myBox = node->getAttachedObject(name)->getBoundingBox();


    minBox = (node->getOrientation() * myBox.getMinimum() * scale) + pos; 
    maxBox = (node->getOrientation() * myBox.getMaximum() * scale) + pos; 

	
    // do math for offset 
    sides = maxBox + minBox; 
    midpoint = sides / 2; 
    *offset = midpoint - pos; 

    // do math for ODE 
    side.x = (maxBox.x) - (minBox.x); 
    side.y = (maxBox.y) - (minBox.y); 
    side.z = (maxBox.z) - (minBox.z); 
	
    // make all positive; 
	if (side.x < 0)
		side.x = side.x * -1;
	if (side.y < 0)
		side.y = side.y * -1;
	if (side.z < 0)
		side.z = side.z * -1;

	return side;

}

Posted: **Fri Jun 25, 2004 4:00 pm**

I changed the landscape.mesh used in the F4 part of the demo with athene.mesh. Oooo I love your code now Monster

Posted: **Sun Jun 27, 2004 2:12 pm**

hi monster,
i think some models (at least the body of the car and the sphere) have 32bit indexes. IIRC (back in the days of the jeep demo) it's your AC3D exporter. i think it could be usefull a 16bit version for '2-years old laptop' development.

beside that, great stuff. car feeling and overall stability really good.

Posted: **Mon Jun 28, 2004 8:36 am**

Small update;
- Stepper class added that can automatically, or manually step the world.
- Added Ahmed's chase camera, which is really cool, thanks for that!
- Tidied up (hopefully) some of the example code
- Fixed the "static" return variables, thanks Guest
- Added a "solution" to the download that's just got the library and demo in it
- Re-exported the Ball and Crate meshes to 16-bit, sorry about that.

Get it from the same place;
Link Removed - This Version is Obsolete [1.57Mb]

@ekt
Only the Crate and Ball meshes were 32-bit, all the others have always been 16-bit. What problems do you have with the car body?

@tlaloc
I'm not sure I fully understand your code. If the mesh you want to use isn't centered about the origin then you'll have to either;
- Transform the visual representation to match the physical. Do this either in your modeler or via a child node of the node to which you're attaching the OgreOde::Body
- Transform the physical to match the visual; i.e. the corresponding OgreOde::Mass and Geometry.

The following code (a modification to OgreOdeTest::createRandomObject) uses the latter method and works fine for the robot mesh. I've hardcoded the offsets and sizes that my modeler gives me for the robot mesh, but obviously you can work them out from the mesh if you like.

Code: Select all

String typeName = (objectClass == OgreOde::Geometry::Class::Box)?"Robot":
...
switch(objectClass)
{
    case OgreOde::Geometry::Class::Box:
    {
        size *= 5;
        
        Vector3 scale(size.x / 28.13,size.y / 97.67,size.z / 45.09);
        Vector3 pos(4.79839 * scale.x,48.5451 * scale.y,-0.660048 * scale.z);

        OgreOde::BoxMass mass(1.0,size);
        mass.setDensity(5.0,size);
        mass.translate(pos);
        body->setMass(mass);
			
        OgreOde::BoxGeometry* box_geom = new OgreOde::BoxGeometry(size); 
        geom = (OgreOde::Geometry*)new OgreOde::TransformGeometry(_space);
        ((OgreOde::TransformGeometry*)(geom))->setEncapsulatedGeometry(box_geom);

        box_geom->setPosition(pos);
        _geoms.push_back(box_geom);

        node->setScale(scale.x,scale.y,scale.z);
}
break;

P.S. I'm not sure the mass transformation is working correctly, but IIRC from the ODE mailing list, that might be an ODE thing.

Posted: **Mon Jun 28, 2004 10:22 am**

Guest it's me (as I wrote).Forgot to login

Posted: **Mon Jun 28, 2004 2:40 pm**

i get an access violation in OgreGLRenderSystem.cpp

Code: Select all

glDrawRangeElements(primType, op.indexData->indexStart, 
    op.indexData->indexStart + op.indexData->indexCount - 1,
    op.indexData->indexCount, indexType, pBufferData);

(indexType = 5123, indexStart = 0, indexCount = 5904)

ok, car body seems 16bit (indexType = 5123, GL_UNSIGNED_SHORT)

but:
- replacing only the body mesh with another one resolved the problem
- dx7 render shouts at me when i hit F3 (not early) saying "Direct3D7 only supports 16-bit index buffers, you should upgrade to a more recent Direct3D RenderSystem if you wish to use 32-bit indexes.."

so remembering the 32bit issues on the jeep, i tought it was the same problem.

DX9 -> BSOD

my card (ATI Radeon IGP 340M) for sure doesn't supports 32bit indexes

Posted: **Mon Jun 28, 2004 3:01 pm**

Hmm, interesting. Can you open those meshes in the meshviewer? That'll tell you whether or not they're 16-bit. I think they all are though.

Just out of interest, and I'm sure it won't make any difference, but what happens if you turn off shadows (hit space) before hitting F3?

Posted: **Mon Jun 28, 2004 3:47 pm**

meshviewer: already tried yesterday and it freezed my laptop (thinking about it, since it's using dx9, i was expencting a blue screen actually). don't know if cTh has a good reason to force dx9, maybe i can hackit a little and see if it's running with gl. but i suspect it wont make any diff

taking out shadows was one of my first attempts but i got the same problem. the landscape scene shows correctly (as all the other demos) and i guess has more indexes than the car.

last thing i can do is try loading the mesh with axiom

Posted: **Mon Jun 28, 2004 3:57 pm**

Bonkers. Doesn't seem to be specific to OgreOde though! Hopefully.

You say it's OK if you replace the car body mesh with something else, presumably something with less verts/tris, what happens if you replace it with something big, like the athena mesh?

Posted: **Mon Jun 28, 2004 4:03 pm**

monster, your pretty codes like crystal! i like it very much.

Posted: **Mon Jun 28, 2004 4:45 pm**

I just forgot in haste, Instead of looking at car.node's position, camera should look at some thing (car.node's position + Vector3( 0,height,0 ))

So you can have a good view of front.

Posted: **Fri Jul 02, 2004 3:06 am**

i have found the needed .dll files around the computer

and im having problems once i click ok in the setup menue. it looks for the example/smoke texture here is the whole ogre.log (the problem is at the bottom)

Code: Select all

21:51:09: Loading library OgrePlatform.dll
21:51:09: ArchiveFactory for archive type Zip registered.
21:51:09: Loading library plugins\RenderSystem_Direct3D9
21:51:09: D3D9 : Direct3D9 Rendering SubSystem created.
21:51:09: D3D9: Driver Detection Starts
21:51:09: D3D9: Driver Detection Ends
21:51:09: Loading library plugins\Plugin_FileSystem.dll
21:51:09: ArchiveFactory for archive type FileSystem registered.
21:51:09: *-*-* OGRE Initialising
21:51:09: *-*-* Version 0.14.0
21:51:09: FileSystem Archive Codec for Media/packs created.
21:51:09: Zip Archive codec for ../../../Media/packs/OgreOdeTest.zip created.
21:51:09: D3D9 : RenderSystem Option: Anti aliasing = None
21:51:09: D3D9 : RenderSystem Option: Full Screen = No
21:51:09: D3D9 : RenderSystem Option: Rendering Device = NVIDIA GeForce FX 5200
21:51:09: D3D9 : RenderSystem Option: VSync = No
21:51:09: D3D9 : RenderSystem Option: Video Mode = 800 x 600 @ 32-bit colour
21:51:10: D3D9 : Subsystem Initialising
21:51:10: D3D9 : Created D3D9 Rendering Window 'OGRE Render Window' : 800x600, 32bpp
21:51:10: RenderSystem capabilities
21:51:10: -------------------------
21:51:10:  * Hardware generation of mipmaps: no
21:51:10:  * Texture blending: yes
21:51:10:  * Anisotropic texture filtering: yes
21:51:10:  * Dot product texture operation: yes
21:51:10:  * Cube mapping: yes
21:51:10:  * Hardware stencil buffer: yes
21:51:10:    - Stencil depth: 8
21:51:10:    - Two sided stencil support: yes
21:51:10:    - Wrap stencil values: yes
21:51:10:  * Hardware vertex / index buffers: yes
21:51:10:  * Vertex programs: yes
21:51:10:    - Max vertex program version: vs_2_0
21:51:10:  * Fragment programs: yes
21:51:10:    - Max fragment program version: ps_2_0
21:51:10:  * Texture Compression: yes
21:51:10:    - DXT: yes
21:51:10:    - VTC: no
21:51:10:  * Scissor Rectangle: yes
21:51:10:  * Hardware Occlusion Query: yes
21:51:10:  * User clip planes: yes
21:51:10: ***************************************
21:51:10: *** D3D9 : Subsystem Initialised OK ***
21:51:10: ***************************************
21:51:10: Parsing material script: apache_body.material
21:51:10: Parsing material script: ball.material
21:51:10: Parsing material script: capsule.material
21:51:10: Parsing material script: crate.material
21:51:10: Parsing material script: kk3d.material
21:51:10: Parsing material script: landscape.material
21:51:10: Parsing material script: main_rotor.material
21:51:10: Parsing material script: plane.material
21:51:10: Parsing material script: scooby_body.material
21:51:10: Parsing material script: scooby_wheel.material
21:51:10: Parsing material script: tail_rotor.material
21:51:10: Parsing particle script ogreodetest.particle
21:51:10: An exception has been thrown!

-----------------------------------
Details:
-----------------------------------
Error #: 7
Function: BillboardSet::setMaterialName
Description: Could not find material Examples/Smoke. 
File: \!prj\d3d\ogre_engine\OgreMain\src\OgreBillboardSet.cpp
Line: 256
Stack unwinding: <<beginning of stack>>

Posted: **Fri Jul 02, 2004 5:45 pm**

The Examples/Smoke material is in the standard Ogre distribution. This demo needs what's listed in the normal resources.cfg file as well as the extra stuff that's supplied in the OgreOdeTest.zip pack.

i have found the needed .dll files around the computer

Meaning what exactly?

If I had to guess, I'd say that you haven't installed this to your "ogrenew" directory as instructed. But I stand to be corrected.

Posted: **Sat Jul 03, 2004 2:46 am**

i think your right, i once had ogre compiled, but the computer crashed

ill have to re compile it. i was just using other needed files from other compiled .14 programs. Thx for your time.

Posted: **Wed Jul 21, 2004 4:34 am**

monster, I've just downloaded OgreOde, installed it, and realised its a VC7+ project

. If I make the neccessary changes to make it work in VC6 as well as VC7 (mostly, DSP files and not declaring i in the for loop) would you be interested in incorporating these changes?

Posted: **Wed Jul 21, 2004 5:00 am**

I think someone's already "fixed" it to work with other versions of MSVC, but I'm certainly interested in any and all changes that people want to make. Having said that, I'm a bit loathed to make changes to the code to support the ancient and flawed VC6 compiler. If anyone's doing serious development then they really should be using a newer version than that. But hey, if someone's willing to supply patches to do this then who am I to argue!

Eventually it'll hopefully go into the Ogre addons CVS area, and so will benefit from all that that entails. But, due to other commitments, that won't happen until at least October. Sorry!

Posted: **Wed Jul 21, 2004 5:50 am**

Heh I can certainly agree with your statements about the VC6 compiler... I'm not sure why we are still using it in fact, I think its another "it aint broke" thing.

I've got it "fixed" to compile in VC6, I even got it fixed to compile with STLPort instead of VC7's STL (although that consisted mostly of commenting out sections, rather then some nice cross-platform detecting).

Just to check, which version of Ogre was it compiled/linked against? I'm getting not-found symbols that is probably due to my Ogre being 0.14, not HEAD. (I'll probably read back through this thread or something before you answer this, though).

[Edit:] I only found that you said 0.14, so I'm guessing my problem may lie elsewhere. Or at least, I'll widen my search. [/Edit]

[Edit, again] Hmm, um, how about I try compiling the OgreODE dll first, eh? Opps.

[/edit]

Posted: **Wed Jul 21, 2004 6:07 am**

the VC6 compiler... I'm not sure why we are still using it in fact, I think its another "it aint broke" thing.

But it is broke. Quite badly!

which version of Ogre was it compiled/linked against?

It was originally developed against 0.14.0, and I think the current download was compiled against that too, but I've recently compiled it with no problems against a CVS snapshot.

What not-found symbols do you get?

Posted: **Wed Jul 21, 2004 6:11 am**

You replied as I was editing my previous post.

The not-broke I think was actually because of some code we inherited that only worked on VC6. Actually I think we have since dropped that, so I may be able to "sneak" VC7 onto my machine. I'll look into it. But...

The missing symbols are in OgreODE.DLL. It links against OgreMain.Dll and wants (that don't exist):
Ogre::String::String(class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &)
class Ogre::HardwareVertexBuffer * Ogre::SharedPtr<class Ogre::HardwareVertexBuffer>::operator->(void)
void Ogre::ShadowCaster::generateShadowVolume(class Ogre::EdgeData *,class Ogre::HardwareIndexBufferSharedPtr,class Ogre::Light const *,class std::vector<class Ogre::ShadowRenderable *,class std::allocator<class Ogre::ShadowRenderable *> > &,unsigned long)
class std::vector<class Ogre::Plane,class std::allocator<class Ogre::Plane> > const & Ogre::Renderable::getClipPlanes(void)
class std::vector<class Ogre::Light *,class std::allocator<class Ogre::Light *> > const & Ogre::SimpleRenderable::getLights(void)
class Ogre::VectorIterator<class std::vector<class Ogre::ShadowRenderable *,class std::allocator<class Ogre::ShadowRenderable *> > > Ogre::MovableObject::getShadowVolumeRenderableIterator(enum Ogre::ShadowTechnique,class Ogre::Light const *,class Ogre::HardwareIndexBufferSharedPtr *,bool,float,unsigned long)

As I edited my post to say, I'll try compiling OgreODE.DLL myself rather then using your supplied one.

Posted: **Wed Jul 21, 2004 6:22 am**

As I edited my post to say, I'll try compiling OgreODE.DLL myself rather then using your supplied one.

Ah, fair enough! Yeah, probably that's to do with mismatches of STL. Or something.

Ogre Forums

The OgreOde Thread

Follow Cam

hum

ok