The OgreOde Thread
-
- OGRE Community Helper
- Posts: 1098
- Joined: Mon Sep 22, 2003 2:40 am
- Location: Melbourne, Australia
-
- Gnome
- Posts: 351
- Joined: Thu Oct 21, 2004 1:34 pm
- Location: Diepenbeek, Belgium
- x 3
I downloaded CVS HEAD of Ogre, and tried to use OgreOde with it. I had to change the String::BLANK with StringUtil::BLANK (as suggested here), and had to change many of the angular values used in the demos.
Some values seem to be in radians though, and some in degrees (I guess that's exactly the reason why they changed the angle stuff, to avoid confusion). I don't know if I changed the values correctly.
It seems OK though. The only problem I have is the mouse handling. It is way too fast! Any solutions for this (I'm going to work with Ogre in our research group, but I'm not yet familiar with it)?
Greetz,
JeDi
Some values seem to be in radians though, and some in degrees (I guess that's exactly the reason why they changed the angle stuff, to avoid confusion). I don't know if I changed the values correctly.
It seems OK though. The only problem I have is the mouse handling. It is way too fast! Any solutions for this (I'm going to work with Ogre in our research group, but I'm not yet familiar with it)?
Greetz,
JeDi
-
- OGRE Community Helper
- Posts: 1098
- Joined: Mon Sep 22, 2003 2:40 am
- Location: Melbourne, Australia
See 5 or so posts ago...
monster wrote:Ah, could be to do with the fact that the current version uses customised versions of the "Example" includes (and backs up the originals) so that it can callThis could be messing up any changes to the example framework that are in the CVS version of Ogre. I'd suggest replacing your example includes with the ones that OgreOde backed up (or with the originals from the Ogre distribution) and using mMoveSpeed instead, like the Terrain sample.Code: Select all
mFrameListener->setMovementSpeed(5.0);
The new version of OgreOde doesn't muck about with Ogre in this way, it should work straight out of the box.
-
- Gnoblar
- Posts: 18
- Joined: Wed Oct 13, 2004 12:40 pm
Wow thats great.. Thanks to Monster and all who made this available for us poor VC6.0 guys 
One question though: I'm getting a strange error I never saw before (probably my fault has nothing to do with OgreOde):
c:\proggen\ogre\ogrenew\samples\ogreodetest\include\ogreodetest_chain.h(384) : error C2440: '=' : cannot convert from 'const class OgreOde::Joint *' to 'class OgreOde::Joint *' Conversion loses qualifiers
Code:
The error is in the line with dummy =... Can anyone see what I'm doing wrong ?

One question though: I'm getting a strange error I never saw before (probably my fault has nothing to do with OgreOde):
c:\proggen\ogre\ogrenew\samples\ogreodetest\include\ogreodetest_chain.h(384) : error C2440: '=' : cannot convert from 'const class OgreOde::Joint *' to 'class OgreOde::Joint *' Conversion loses qualifiers
Code:
Code: Select all
for(std::vector<OgreOde::Body*>::iterator iBody = _bodies.begin();iBody != _bodies.end();iBody++)
{
for (int j = 0; j < (*iBody)->getJointCount(); j++)
{
OgreOde::Joint * dummy;
dummy = (*iBody)->getJoint(j);
NeuralNet[i] = new SetAxisAINode (dummy); i++;
NeuralNet[i] = new SetAxis2AINode (dummy); i++;
}
}
-
- OGRE Community Helper
- Posts: 1098
- Joined: Mon Sep 22, 2003 2:40 am
- Location: Melbourne, Australia
Just cast it. The getJoint function returns a const pointer when it probably shouldn't, if you just cast it you'll be fine;
(or possibly I should return references!)
Code: Select all
OgreOde::Joint * dummy = (OgreOde::Joint*)((*iBody)->getJoint(j));
(or possibly I should return references!)
-
- Gnoblar
- Posts: 18
- Joined: Wed Oct 13, 2004 12:40 pm
-
- Goblin
- Posts: 215
- Joined: Tue Jul 08, 2003 4:41 pm
- Location: 0,0,0
Hi!
Just want to say OgreOde is fantastic! Got it up and running in no time!
A couple/three questions:
1) I have a sim with several boxes (hundreds, actually) in contact with an infinite plane. When the sim starts, some (but not all) of them are sliding. Is there a way to prevent this? Maybe a "start at rest" flag or something? They are all set to autoDisable (which is great, BTW).
2) When forces start moving my boxes, they slide "infinitely" across the plane. How do I apply some kind of friction? I took a quick look at the code but nothing obvious leapt out at me. In the thread, applying a "reverse force" was mentioned in conjunction with simulating aerodynamic drag, but that seems hacky. Can you not apply frictional properties to surfaces/bodies, so it's applied based on the number of contact points in a collision, something like that?
3) I saw mention that manually setting positions/rotations can cause Havok (pardon the pun) with the sim. I find this quite alarming! What about network correction, teleporting, that sort of thing? Seems to me the sim should really be able to handle that OK (as long as you are careful to set valid/non-intersecting positions).
Just want to say OgreOde is fantastic! Got it up and running in no time!
A couple/three questions:
1) I have a sim with several boxes (hundreds, actually) in contact with an infinite plane. When the sim starts, some (but not all) of them are sliding. Is there a way to prevent this? Maybe a "start at rest" flag or something? They are all set to autoDisable (which is great, BTW).
2) When forces start moving my boxes, they slide "infinitely" across the plane. How do I apply some kind of friction? I took a quick look at the code but nothing obvious leapt out at me. In the thread, applying a "reverse force" was mentioned in conjunction with simulating aerodynamic drag, but that seems hacky. Can you not apply frictional properties to surfaces/bodies, so it's applied based on the number of contact points in a collision, something like that?
3) I saw mention that manually setting positions/rotations can cause Havok (pardon the pun) with the sim. I find this quite alarming! What about network correction, teleporting, that sort of thing? Seems to me the sim should really be able to handle that OK (as long as you are careful to set valid/non-intersecting positions).
-
- OGRE Community Helper
- Posts: 1098
- Joined: Mon Sep 22, 2003 2:40 am
- Location: Melbourne, Australia
Thanks! Glad it works!
1) As soon as you create each box, call Body::disable (or, in the new version Body::sleep) to put the body to sleep manually. It'll be woken up if something else hits it, but not if you manually apply a force to it, in that case you'll have to manually do Body::wake (or, in your case Body::enable).
2) In your collision callback, set some friction on the contact with contact->setCoulombFriction(20.0) or something. You might also want to tweak the linear and angular damping.
3) The other day I built a teleporter out of an old microwave oven, a UHF radio and some bits & pieces I nicked from out the back of the TV. I used it to teleport my guitar into the middle of my cat. Quite alarming!
Yes, if you only move your objects into physically correct positions then everything will be fine. Why most people want to do this is so that they can push stuff around, and by that they mean; move stuff into physically incorrect positions and then get ODE to sort it all out. Which is OK as long as things are only a bit wrong, but goes bonkers if you have big interpenetrations.
If you just move stuff about with forces and torques then ODE will (try to) maintain the "correctness" for you, if you teleport stuff around willy-nilly then you're saying "bugger you ODE, I know what's correct and what's not". Which is fine if (as I suspect you do, based on what you want to do) you actually do know what's what and are careful to avoid any guitar / cat related disasters.
I've said it before and I'll say it again; there's nothing particularly clever about OgreOde, it's really just a pretty thin wrapper over ODE with Ogre types and some C++ style interfaces. In most cases the functions are exactly equivalent between the two, and all the rules that apply to ODE also apply to OgreOde.
1) As soon as you create each box, call Body::disable (or, in the new version Body::sleep) to put the body to sleep manually. It'll be woken up if something else hits it, but not if you manually apply a force to it, in that case you'll have to manually do Body::wake (or, in your case Body::enable).
2) In your collision callback, set some friction on the contact with contact->setCoulombFriction(20.0) or something. You might also want to tweak the linear and angular damping.
3) The other day I built a teleporter out of an old microwave oven, a UHF radio and some bits & pieces I nicked from out the back of the TV. I used it to teleport my guitar into the middle of my cat. Quite alarming!
Yes, if you only move your objects into physically correct positions then everything will be fine. Why most people want to do this is so that they can push stuff around, and by that they mean; move stuff into physically incorrect positions and then get ODE to sort it all out. Which is OK as long as things are only a bit wrong, but goes bonkers if you have big interpenetrations.
If you just move stuff about with forces and torques then ODE will (try to) maintain the "correctness" for you, if you teleport stuff around willy-nilly then you're saying "bugger you ODE, I know what's correct and what's not". Which is fine if (as I suspect you do, based on what you want to do) you actually do know what's what and are careful to avoid any guitar / cat related disasters.
I've said it before and I'll say it again; there's nothing particularly clever about OgreOde, it's really just a pretty thin wrapper over ODE with Ogre types and some C++ style interfaces. In most cases the functions are exactly equivalent between the two, and all the rules that apply to ODE also apply to OgreOde.
Last edited by monster on Fri Oct 22, 2004 7:28 am, edited 1 time in total.
-
- Goblin
- Posts: 220
- Joined: Mon May 31, 2004 5:54 am
- Location: Canada
I love your analogies, hilariousmonster wrote:3) The other day I built a teleporter out of an old microwave oven, a UHF radio and some bits an pieces I nicked from out the back of the TV. I used it to teleport my guitar into the middle of my cat. Quite alarming!
If you just move stuff about with forces and torques then ODE will (try to) maintain the "correctness" for you, if you teleport stuff around willy-nilly then you're saying "bugger you ODE, I know what's correct and what's not". Which is fine if (as I suspect you do, based on what you want to do) you actually do know what's what and are careful to avoid any guitar / cat related disasters.

-
- OGRE Community Helper
- Posts: 1098
- Joined: Mon Sep 22, 2003 2:40 am
- Location: Melbourne, Australia
Fanfare please.
You can, if you're feeling brave, download the Preview release of the next version of OgreOde from here;
http://www.green-eyed-monster.com/OgreOde_Preview.zip
Or get it from OgreAddons CVS, which might be a bit more up to date.
It's a source release and currently only contains build scripts for MSVC 7.1, 'cos that's what I use. If anyone would like to point out any problems with it or contribute some other build scripts, I'll be happy to accept them.
You should extract the Zip to your ogrenew (or whatever you've renamed it to) directory, remembering to preserve the directory structure. And that ogrenew directory should contain a reasonably recent CVS snapshot of Ogre, mine's from a couple of days ago.
You will also have to get and build ODE 0.5 yourself, and bugger about with it if you want the Planar joint and the Terrain collision primitive.
There are various readme files scattered around the place that might explain this in more detail, but currently the documentation is a little 'minimalist'.

Hopefully I'll figure out CVS in time to coincide it's appearance in ogreaddons with the release of Ogre 0.15.0
Have fun.
N.B. If you're using the terrain collider in the Landscape demo, don't even bother trying to run it in Debug mode. For some reason the RaySceneQuery is stupidly slow in debug mode, whereas it has virtually no impact at all on the framerate under Release mode. If you have a slow video card you might also want to change the terrain options so that it doesn't use the fancy vertex/fragment shaded terrain.
You can, if you're feeling brave, download the Preview release of the next version of OgreOde from here;
http://www.green-eyed-monster.com/OgreOde_Preview.zip
Or get it from OgreAddons CVS, which might be a bit more up to date.
It's a source release and currently only contains build scripts for MSVC 7.1, 'cos that's what I use. If anyone would like to point out any problems with it or contribute some other build scripts, I'll be happy to accept them.
You should extract the Zip to your ogrenew (or whatever you've renamed it to) directory, remembering to preserve the directory structure. And that ogrenew directory should contain a reasonably recent CVS snapshot of Ogre, mine's from a couple of days ago.
You will also have to get and build ODE 0.5 yourself, and bugger about with it if you want the Planar joint and the Terrain collision primitive.
There are various readme files scattered around the place that might explain this in more detail, but currently the documentation is a little 'minimalist'.

Hopefully I'll figure out CVS in time to coincide it's appearance in ogreaddons with the release of Ogre 0.15.0
Have fun.
N.B. If you're using the terrain collider in the Landscape demo, don't even bother trying to run it in Debug mode. For some reason the RaySceneQuery is stupidly slow in debug mode, whereas it has virtually no impact at all on the framerate under Release mode. If you have a slow video card you might also want to change the terrain options so that it doesn't use the fancy vertex/fragment shaded terrain.
Last edited by monster on Tue Dec 21, 2004 5:37 am, edited 2 times in total.
-
- OGRE Retired Moderator
- Posts: 2653
- Joined: Wed Sep 24, 2003 8:07 am
- Location: Haute Garonne, France
- x 4
vc 7.1 + stlport 4.6.2
SimpleScenes_Crash.h(384) : erase returned value void cannot be converted
stlport and gcc map::erase seems to return void.
http://www.pluralsight.com/blogs/hsutte ... /2620.aspx
near that one there is a suspicious i++; in the else following it.
doesn't the "for" loop already increments it ?
SimpleScenes_Crash.h(384) : erase returned value void cannot be converted
stlport and gcc map::erase seems to return void.
http://www.pluralsight.com/blogs/hsutte ... /2620.aspx
near that one there is a suspicious i++; in the else following it.
doesn't the "for" loop already increments it ?
-
- OGRE Community Helper
- Posts: 1098
- Joined: Mon Sep 22, 2003 2:40 am
- Location: Melbourne, Australia
-
- OGRE Retired Moderator
- Posts: 1365
- Joined: Tue Sep 07, 2004 12:43 pm
- Location: Aalborg, Denmark
http://www.ogre3d.org/phpBB2/viewtopic. ... 4755#44755Anyone care to tell me the answer to this one?

-
- Gnoblar
- Posts: 12
- Joined: Mon Mar 15, 2004 11:46 am
You ask, Effective STL answersmonster wrote:Oh bugger. Yep, that's because MSVC's native map::erase (vector::erase, etc) return an iterator pointing to the next element after you delete one. The "standard" and therefore STLPort and GCC return void.
Anyone care to tell me the answer to this one?

From Effective STL by Scott Meyers, Item 9, page 45:
Code: Select all
Assoc_Container<int> c;
...
for(AssocContainer<int>::iterator i=c.begin(); != c.end(); )
{
if (badValue(*i)) c.erase(i++);
else ++i;
}
Hope that helps
JoSch
PS: monster, I just build your lib with my autotools, it built just fine. I now will integrate the demos and then you can have the files.
Member of Team Pantheon: Maker of Noise and Flashing Lights, Caretaker of Penguins.
-
- OGRE Community Helper
- Posts: 1098
- Joined: Mon Sep 22, 2003 2:40 am
- Location: Melbourne, Australia
Far be it from me to doubt Mr. Meyers, but are you sure about that? Doesn't the erase invalidate the iterator?From Effective STL by Scott Meyers, Item 9, page 45:
Code: Select all
#include <vector>
int main(int argc, char *argv[])
{
std::vector<int> tst;
for(int i = 0;i < 10;i++) tst.push_back(i);
for(std::vector<int>::iterator i=tst.begin();i != tst.end();)
{
if((*i) % 2) tst.erase(i++);
else ++i;
}
}
If I do
Code: Select all
if((*i) % 2)
{
tst.erase(i);
i = tst.begin();
}
There's an updated archive available that uses this 'start again' approach. It's not the most efficient thing in the world, but it's only used in one of the demos and will do until there's a better solution.

-
- Gnoblar
- Posts: 12
- Joined: Mon Mar 15, 2004 11:46 am
And so it should. If you read my sample again, it talks about AssocContainer, which would be map etc. This works because assocative containers ONLY invalidate the iterator used for erase. The other standard container like vector indeed do invalidate ALL iterators, so this approach naturely can't work.monster wrote:Far be it from me to doubt Mr. Meyers, but are you sure about that? Doesn't the erase invalidate the iterator?From Effective STL by Scott Meyers, Item 9, page 45:Compiled with Dev-C++ 4.9.8.7 and it crashes trying to postincrement the iterator!Code: Select all
#include <vector> int main(int argc, char *argv[]) { std::vector<int> tst; for(int i = 0;i < 10;i++) tst.push_back(i); for(std::vector<int>::iterator i=tst.begin();i != tst.end();) { if((*i) % 2) tst.erase(i++); else ++i; } }
IIRC, the problem that spawned this discussion was about maps. But if you need a solution for vectors, well then I will quote here

Bye JoSch
Member of Team Pantheon: Maker of Noise and Flashing Lights, Caretaker of Penguins.
-
- OGRE Community Helper
- Posts: 1098
- Joined: Mon Sep 22, 2003 2:40 am
- Location: Melbourne, Australia
-
- OGRE Retired Moderator
- Posts: 1365
- Joined: Tue Sep 07, 2004 12:43 pm
- Location: Aalborg, Denmark
As this is not used in any time critical sections it maybe isn't that relevant, but if you want it to be effective have you thought about using lists? From http://www.sgi.com/tech/stl/List.html:
...supports both forward and backward traversal, and (amortized) constant time insertion and removal of elements at the beginning or the end, or in the middle. Lists have the important property that insertion and splicing do not invalidate iterators to list elements, and that even removal invalidates only the iterators that point to the elements that are removed.
-
- Gnoblar
- Posts: 12
- Joined: Mon Mar 15, 2004 11:46 am
I'm reading it myself at the moment (Item 9 was - coincedence - the last thing I've read yesterday evening), you should buy it anyway.monster wrote:Ah, fair enough.If you read my sample again, it talks about AssocContainer, which would be map etc.
Please do quote. Save me buying the book!But if you need a solution for vectors, well then I will quote here
Code: Select all
i = c.erase(i)
But again, this works only for the standard contiguous-memory containers (that's how Meyer calls them, i.e. list, vector, deque and string).
Member of Team Pantheon: Maker of Noise and Flashing Lights, Caretaker of Penguins.
-
- OGRE Community Helper
- Posts: 1098
- Joined: Mon Sep 22, 2003 2:40 am
- Location: Melbourne, Australia
Yep, you're probably right, as all this shows!...you should buy it anyway.
So you can do
Code: Select all
i = c.erase(i);
Code: Select all
c.erase(i++);
How bonkers is that!
I'll make the changes and post an updated version shortly.
Thanks for your help guys!
-
- Gnoblar
- Posts: 12
- Joined: Mon Mar 15, 2004 11:46 am
But it stands to reason!monster wrote: How bonkers is that!
On contiguous-memory container (I love that phrase

For associative containers there is no problem like that. The container doesn't copy items around, so only the iterators on the erased item become invalid.
You really should read the book, Meyers does a thorough job in explaining such things.
Member of Team Pantheon: Maker of Noise and Flashing Lights, Caretaker of Penguins.
-
- OGRE Community Helper
- Posts: 1098
- Joined: Mon Sep 22, 2003 2:40 am
- Location: Melbourne, Australia
I think that might be a good idea.You really should read the book...
The download's been updated, and hopefully I've got it right this time!

For those that missed it, get it here;
http://www.green-eyed-monster.com/OgreOde_Preview.zip
It is just a preview version though, so expect bugs!
-
- Gnoblar
- Posts: 23
- Joined: Tue Aug 31, 2004 7:50 am
Hi monster, I have a question for you. How much has changed in this version of OgreOde ? My reason for asking this is coz I am getting real comfy in using OgreOde v1 - and if a lot changes I'll have to rewrite my stuff to be compatible with this.
Anyway great work and thanks for all your effort - I see this thing becoming more than just a wrapper
PS : I'll just wait for you to release the _real_ version
, coz my bandwith sucks and 2 mb for me is like 200 !! 
Anyway great work and thanks for all your effort - I see this thing becoming more than just a wrapper

PS : I'll just wait for you to release the _real_ version


Linux Rocks!!!