The OgreOde Thread

A place for users of OGRE to discuss ideas and experiences of utilitising OGRE in their games / demos / applications.
Locked
User avatar
monster
OGRE Community Helper
OGRE Community Helper
Posts: 1098
Joined: Mon Sep 22, 2003 2:40 am
Location: Melbourne, Australia
Contact:

Post by monster »

Yep, use the TransformGeometry.
The Crash (helicopter) demo shows this.
JeDi
Gnome
Posts: 351
Joined: Thu Oct 21, 2004 1:34 pm
Location: Diepenbeek, Belgium
x 3
Contact:

Post by JeDi »

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
User avatar
monster
OGRE Community Helper
OGRE Community Helper
Posts: 1098
Joined: Mon Sep 22, 2003 2:40 am
Location: Melbourne, Australia
Contact:

Post by monster »

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 call

Code: Select all

mFrameListener->setMovementSpeed(5.0);
This 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.

The new version of OgreOde doesn't muck about with Ogre in this way, it should work straight out of the box.
;)
User avatar
Banania
Gremlin
Posts: 150
Joined: Wed Oct 20, 2004 2:35 pm
Location: Paris, France
Contact:

Cool

Post by Banania »

monster wrote:Yep, use the TransformGeometry.
The Crash (helicopter) demo shows this.
Cool !

I was looking for something like that !

Thanks
Banania
Brutha
Gnoblar
Posts: 18
Joined: Wed Oct 13, 2004 12:40 pm

Post by Brutha »

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:

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++;		     
     }
   }
The error is in the line with dummy =... Can anyone see what I'm doing wrong ?
User avatar
monster
OGRE Community Helper
OGRE Community Helper
Posts: 1098
Joined: Mon Sep 22, 2003 2:40 am
Location: Melbourne, Australia
Contact:

Post by monster »

Just cast it. The getJoint function returns a const pointer when it probably shouldn't, if you just cast it you'll be fine;

Code: Select all

OgreOde::Joint * dummy = (OgreOde::Joint*)((*iBody)->getJoint(j));


(or possibly I should return references!)
Brutha
Gnoblar
Posts: 18
Joined: Wed Oct 13, 2004 12:40 pm

Post by Brutha »

Wow that was a fast reply. Thanks, it works now :)
User avatar
Bren
Goblin
Posts: 215
Joined: Tue Jul 08, 2003 4:41 pm
Location: 0,0,0
Contact:

Post by Bren »

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).
User avatar
monster
OGRE Community Helper
OGRE Community Helper
Posts: 1098
Joined: Mon Sep 22, 2003 2:40 am
Location: Melbourne, Australia
Contact:

Post by monster »

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.
Last edited by monster on Fri Oct 22, 2004 7:28 am, edited 1 time in total.
User avatar
IoN_PuLse
Goblin
Posts: 220
Joined: Mon May 31, 2004 5:54 am
Location: Canada
Contact:

Post by IoN_PuLse »

monster 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.
I love your analogies, hilarious :D
User avatar
monster
OGRE Community Helper
OGRE Community Helper
Posts: 1098
Joined: Mon Sep 22, 2003 2:40 am
Location: Melbourne, Australia
Contact:

Post by monster »

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.
Last edited by monster on Tue Dec 21, 2004 5:37 am, edited 2 times in total.
rzhou
Gnoblar
Posts: 1
Joined: Sun May 16, 2004 9:28 am

Post by rzhou »

monster, i love u :D :D :D
User avatar
tuan kuranes
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 2653
Joined: Wed Sep 24, 2003 8:07 am
Location: Haute Garonne, France
x 4
Contact:

Post by tuan kuranes »

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 ?
User avatar
monster
OGRE Community Helper
OGRE Community Helper
Posts: 1098
Joined: Mon Sep 22, 2003 2:40 am
Location: Melbourne, Australia
Contact:

Post by monster »

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?
User avatar
DWORD
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 1365
Joined: Tue Sep 07, 2004 12:43 pm
Location: Aalborg, Denmark
Contact:

Post by DWORD »

Anyone care to tell me the answer to this one?
http://www.ogre3d.org/phpBB2/viewtopic. ... 4755#44755 ;)
JoSch
Gnoblar
Posts: 12
Joined: Mon Mar 15, 2004 11:46 am

Post by JoSch »

monster 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?
You ask, Effective STL answers ;-)

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;
}
The important stuff here is that you don't increment in the for statement, you do it in the erase as a postincrement (!). The badValue function is a predicate, which selects, whether to erase the element or not.

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.
User avatar
monster
OGRE Community Helper
OGRE Community Helper
Posts: 1098
Joined: Mon Sep 22, 2003 2:40 am
Location: Melbourne, Australia
Contact:

Post by monster »

From Effective STL by Scott Meyers, Item 9, page 45:
Far be it from me to doubt Mr. Meyers, but are you sure about that? Doesn't the erase invalidate 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;
    }
}
Compiled with Dev-C++ 4.9.8.7 and it crashes trying to postincrement the iterator!

If I do

Code: Select all

if((*i) % 2)
{
    tst.erase(i);
    i = tst.begin();
}
It works, but obviously it's slow since it has to recalculate the iterator (and hence start again) every time it erases something.

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.
;)
JoSch
Gnoblar
Posts: 12
Joined: Mon Mar 15, 2004 11:46 am

Post by JoSch »

monster wrote:
From Effective STL by Scott Meyers, Item 9, page 45:
Far be it from me to doubt Mr. Meyers, but are you sure about that? Doesn't the erase invalidate 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;
    }
}
Compiled with Dev-C++ 4.9.8.7 and it crashes trying to postincrement the iterator!
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.

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.
User avatar
monster
OGRE Community Helper
OGRE Community Helper
Posts: 1098
Joined: Mon Sep 22, 2003 2:40 am
Location: Melbourne, Australia
Contact:

Post by monster »

If you read my sample again, it talks about AssocContainer, which would be map etc.
Ah, fair enough.
But if you need a solution for vectors, well then I will quote here
Please do quote. Save me buying the book!
User avatar
DWORD
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 1365
Joined: Tue Sep 07, 2004 12:43 pm
Location: Aalborg, Denmark
Contact:

Post by DWORD »

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.
JoSch
Gnoblar
Posts: 12
Joined: Mon Mar 15, 2004 11:46 am

Post by JoSch »

monster wrote:
If you read my sample again, it talks about AssocContainer, which would be map etc.
Ah, fair enough.
But if you need a solution for vectors, well then I will quote here
Please do quote. Save me buying the book!
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.

Code: Select all

i = c.erase(i)
is the soultion, so you did it correctly, anyway.
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.
User avatar
monster
OGRE Community Helper
OGRE Community Helper
Posts: 1098
Joined: Mon Sep 22, 2003 2:40 am
Location: Melbourne, Australia
Contact:

Post by monster »

...you should buy it anyway.
Yep, you're probably right, as all this shows!

So you can do

Code: Select all

i = c.erase(i);
On vectors but not on maps, and you can do

Code: Select all

c.erase(i++);
On maps, but not on vectors.

How bonkers is that!

I'll make the changes and post an updated version shortly.
Thanks for your help guys!
JoSch
Gnoblar
Posts: 12
Joined: Mon Mar 15, 2004 11:46 am

Post by JoSch »

monster wrote: How bonkers is that!
But it stands to reason!

On contiguous-memory container (I love that phrase ;-)), you have to copy the whole vector after the erased item to the place where the erased item was, so all iterators after iterator i point to the wrong element. The standard now says, to be safe all iterators are now invalid.
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.
User avatar
monster
OGRE Community Helper
OGRE Community Helper
Posts: 1098
Joined: Mon Sep 22, 2003 2:40 am
Location: Melbourne, Australia
Contact:

Post by monster »

You really should read the book...
I think that might be a good idea.

The download's been updated, and hopefully I've got it right this time!
:D

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!
User avatar
thegame
Gnoblar
Posts: 23
Joined: Tue Aug 31, 2004 7:50 am

Post by thegame »

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 :wink:

PS : I'll just wait for you to release the _real_ version :D, coz my bandwith sucks and 2 mb for me is like 200 !! :(
Linux Rocks!!!
Locked