Hi folks...
We are (still - just) trying to build a simple 3D-platform-like game [just for fun - a group of three people]. We use ODE and it's Reference for Collision Detection and Ogre's [v0.15] FrameListener for handling the game's main character.
We have enabled the Collision Detection for our main character (hero), and we have disable the Dynamics.
/*CODE*/
ApplicationObject *hero; //just a Box
/*
* Code - Code -Code
*
*/
hero->setCollisionEnabled(true);
hero->setDynamicsEnabled(false);
/*
* Code - Code - Code
*/
.:::OUR PROBLEM...
In case a moving object [using the addForce() function] contacts our character, Collision Detection works fine.... BUT, while we are moving our character (Keyboard control) the Collision Detection with other objects (movable -balls- or not -walls- ) does not work.
Could anyone suggest us another way for handling our character, while enabling the Collision Detection for every case.
Thanks - in advance - for your time......
Keyboard Handling and Collision Detection
-
- Gnoblar
- Posts: 3
- Joined: Wed Mar 09, 2005 4:21 pm
-
- OGRE Retired Moderator
- Posts: 4823
- Joined: Fri Jun 18, 2004 1:40 pm
- Location: Berlin, Germany
- x 7
I am not familiar with the reference layer, but use OgreOde. Our character is just a geometry and has no body. We test collisions of the character manually (that is mHeroGeom->collide()) when he hits something static we move him accordingly out of it. When he hits something dynamic we apply a force to it dependend on the penetration depth.
-
- Gnoblar
- Posts: 3
- Joined: Wed Mar 09, 2005 4:21 pm
Thanks for your idea about using OgreOde, tanis. I am almost sure that that's what I was looking for...
But another problem showed up…
I have made the changes to Ogre in order to build the OgrODE v1.0.1
1)He suggests us to comment out line 87 of OgreTerrainSceneManager.cpp. BUT that’s a file from version 0.15 not final version 1.0 {DO THOSE CHANGES -ALL OF THEM- WORK WELL IN Ogre v1.0????}
2)He also requires to overload the addEntity method. [ public: virtual void addEntity(Entity* entity); at OgreSceneManager.h etc….]. When I overload the method none of my projects or the Ogre’s Samples work(!!!), because of a RunTime Error!!! {BUT the OgreODE compiles fine. Also, the OgreOde Demos have the same error}
MICROSOFT DEVELOPMENT ENVIROMENT
Run-Time Check Failure #0 - The value of ESP was not properly saved across a function call. This is usually a result of calling a function declared with one calling convention with a function pointer declared with a different calling convention.
[ogrescenemanagerenumerator.cpp – line 124]
What am I doing Wrong!?!?! Please…. Any ideas…
But another problem showed up…
I have made the changes to Ogre in order to build the OgrODE v1.0.1
1)He suggests us to comment out line 87 of OgreTerrainSceneManager.cpp. BUT that’s a file from version 0.15 not final version 1.0 {DO THOSE CHANGES -ALL OF THEM- WORK WELL IN Ogre v1.0????}
2)He also requires to overload the addEntity method. [ public: virtual void addEntity(Entity* entity); at OgreSceneManager.h etc….]. When I overload the method none of my projects or the Ogre’s Samples work(!!!), because of a RunTime Error!!! {BUT the OgreODE compiles fine. Also, the OgreOde Demos have the same error}
MICROSOFT DEVELOPMENT ENVIROMENT
Run-Time Check Failure #0 - The value of ESP was not properly saved across a function call. This is usually a result of calling a function declared with one calling convention with a function pointer declared with a different calling convention.
[ogrescenemanagerenumerator.cpp – line 124]
What am I doing Wrong!?!?! Please…. Any ideas…
-
- OGRE Retired Moderator
- Posts: 4823
- Joined: Fri Jun 18, 2004 1:40 pm
- Location: Berlin, Germany
- x 7
You don't need to apply the changes to Ogre as long as you don't use the ragdoll and vehicle feature (which we don't) so I can't say anything about problems that could arise here. Best you double check your changes.
The not recoverable stack pointer problem is usually, as the message suggests, a calling convention problem. You call a method with one convention (say register saved arguments) but the called method tries to pop them from the stack.
This can happen when you the lib you linked against doesn't match the DLL you are trying to run it with, so maybe you tried to run with an old OgreMain.dll or so?
The not recoverable stack pointer problem is usually, as the message suggests, a calling convention problem. You call a method with one convention (say register saved arguments) but the called method tries to pop them from the stack.
This can happen when you the lib you linked against doesn't match the DLL you are trying to run it with, so maybe you tried to run with an old OgreMain.dll or so?
-
- OGRE Community Helper
- Posts: 1098
- Joined: Mon Sep 22, 2003 2:40 am
- Location: Melbourne, Australia
1)He suggests...
Who's "he"? The cat's mother?

I don't understand what you mean. That file's in both 0.15 and 1.0.0 of Ogre. Are you saying that you don't have this file in your 1.0.0 Ogre release?...us to comment out line 87 of OgreTerrainSceneManager.cpp. BUT that’s a file from version 0.15 not final version 1.0
{DO THOSE CHANGES -ALL OF THEM- WORK WELL IN Ogre v1.0????}
YES THEY DO. THAT'S WHAT I Compile AGAINST!!!!!
No, you're not overloading addEntity because there's no such method. You're simply adding a new method so that you can add pre-created Entities (or subclasses thereof) to your scene.2)He also requires to overload the addEntity method...
Then I'm afraid you've done something wrong!!! Once you've made these changes to Ogre you will need to rebuild it completely so you don't have any old libraries or DLLs lying around!!! Hit Batch Build Clean, then Batch Build Rebuild!!!When I overload the method none of my projects or the Ogre’s Samples work(!!!), because of a RunTime Error!!!
But yeah, if you don't need the prefabs (Vehicle and Ragdoll) then you don't need to build them, so you don't need to change Ogre at all.
-
- Gnoblar
- Posts: 3
- Joined: Wed Mar 09, 2005 4:21 pm
-
- Halfling
- Posts: 61
- Joined: Sun Feb 22, 2004 3:41 pm
- Location: Martigny, Switzerland
Hi Tanis, I have a little question for you!
I'm actually doing the same kind of things as you it seems (the character as only a geometry, its position and orientation is manually updated, and I'm reacting to the collisions myself).
The only thing that wonders me actually is what happens when the frame-rate goes low: the character can be placed at the other side of the obstacle and then the collision is noticed if the character didn't make a too big step (since it's not OgreODE that is moving the character).
Are you moving your character's geometry with a different system? Or dealing with that problem? Or not running your game on a low-end computer? ^^
I'm actually doing the same kind of things as you it seems (the character as only a geometry, its position and orientation is manually updated, and I'm reacting to the collisions myself).
The only thing that wonders me actually is what happens when the frame-rate goes low: the character can be placed at the other side of the obstacle and then the collision is noticed if the character didn't make a too big step (since it's not OgreODE that is moving the character).
Are you moving your character's geometry with a different system? Or dealing with that problem? Or not running your game on a low-end computer? ^^
-
- OGRE Retired Moderator
- Posts: 4823
- Joined: Fri Jun 18, 2004 1:40 pm
- Location: Berlin, Germany
- x 7
This problem is very real. I'm not currently working on this part atm. But will be soon. So I can't tell you a known working solution yet . I guess one could use rays for this. I plan to apply a ray / rays on the character and change their length according to the step. then collide to see if it hit something and shorten the movement step accordingly.
-
- Halfling
- Posts: 61
- Joined: Sun Feb 22, 2004 3:41 pm
- Location: Martigny, Switzerland