MFC + OgreOde problem

[stoneCold]

Hi,
I try to get OgreOde a MFC/Ogre application, I tried to do this like I do it in standard "exampleapplication based" applications, but it does not work.

The OgreOde objects appear in my Ogre render window but it looks like there is no gravity or collision.

I'm really confused.

Here is my code (excluding unimportant parts):

OgreFramework.cpp

Code: Select all

#include "stdafx.h"
#include "OgreFramework.h"

COgreFramework* COgreFramework::m_Inst = NULL;	// Global instance

COgreFramework::COgreFramework()
{
	m_bIsOgreInit = false;
}

COgreFramework::~COgreFramework()
{
}

void COgreFramework::InitOgre(HWND hwnd)
{
/*
.
.
Add visual objects
.
.
*/

//SETTING OGRE ODE PARAMETERS
		_time_step = 0.005;
		_world = new OgreOde::World(mSceneMgr);
		_world->setCollisionListener(this);
		_space = _world->getDefaultSpace();

		_world->setGravity(Vector3(0,-9.80665,0));
		_world->setCFM(10e-5);
		_world->setERP(0.8);
		_world->setAutoSleep(true);
		_world->setContactCorrectionVelocity(10.0);

/*
.
.
Add OgreOde objects
.
.
*/

//OGRE ODE STEPPER
		_stepper = new OgreOde::ForwardFixedQuickStepper(_time_step);
		_stepper->setAutomatic(OgreOde::Stepper::AutoMode_PostFrame,mRoot);

//DEBUG OGREODE OBJECTS
		_world->setShowDebugObjects(1);
}

OgreFramework.h

Code: Select all

#pragma once

#include "Ogre.h"

#include "ogreode.h"

#include "OgreConfigFile.h"
#include "..\..\RenderSystems\Direct3D9\include\OgreD3D9RenderWindow.h"
#include "..\..\RenderSystems\Direct3D9\include\OgreD3D9RenderSystem.h"
#include "OgreWireBoundingBox.h"
#include <cassert>

using namespace Ogre;

class COgreFramework : public OgreOde::CollisionListener
{
	virtual bool collision(OgreOde::Contact* contact)
	{
		OgreOde::Geometry* g1 = contact->getFirstGeometry();
		OgreOde::Geometry* g2 = contact->getSecondGeometry();

		if(g1 && g2)
		{
			OgreOde::Body* b1 = g1->getBody();
			OgreOde::Body* b2 = g2->getBody();
			
			if(b1 && b2) if(OgreOde::Joint::areConnected(b1,b2)) return false;
		}

		contact->setCoulombFriction(OgreOde::Utility::Infinity);

		return true;
	}

public:

	// Constructors/destructors
	COgreFramework();
	virtual ~COgreFramework();

	// Init OGRE to render to a given HWND
	void InitOgre(HWND hwnd);

/*
.
.
.
.
.*/

private:

/*
.
.
.
.
.*/

protected:
	OgreOde::Space*		_space;
	OgreOde::World*		_world;
	OgreOde::Stepper*	_stepper;
	Real				_time_step;
};

Thanks, stoneCold

[monster]

Err, you might have to do a bit more investigation yourself. Spread some breakpoints about the place.

Is the collisioin callback ever getting called?
Is the automatic stepper (frame listener) getting called?
What happens if you don't use an automatic stepper and step it manually yourself?

[stoneCold]

Is the collisioin callback ever getting called?

It seems like it's not

Must I use an Ogre FrameListener additional to the collisionlistener to get it to work?
I ask this because I'm doing the controls with MFC only, therefore I needed no FrameListener yet.

Thx,
stoneCold

[monster]

If you use the stepper in automatic mode, then that's a frame listener.
I imagine that that's not getting informed of frame events so the world's not getting stepped.

As I say, just create the stepper in non-automatic mode and update it manually whenever you render a new frame.

[stoneCold]

Yeah, it works now, like you said I use the "NotAutomatic" mode now and update the stepper manually.

There's only one further thing I want to know.
What's the difference between the "ExactVariableQuickStepper" and the "ForwardFixedQuickStepper"? (Only in order to know it in future )

Thanks a lot,
stoneCold

[monster]

ExactVariable makes sure that the physical world is always exactly in step with the real time by doing a number of fixed steps and a final micro cleanup step. Although this results in the smoothest display, it needs variable timesteps so ODE can be a bit less stable.

ForwardFixed just uses a completely fixed timestep so the simulation always runs at least up to, and sometimes a bit ahead of, real time. This means that it's more (physically) stable because it uses fixed time steps, but can be (visually) jittery with fast moving objects because the physical world is slightly out of sync with the real time. Which confuses your eyes.

Really these were only intended to be example steppers, you can always write your own, or just call the stepping functions of your world directly.