The OgreOde Thread

A place for users of OGRE to discuss ideas and experiences of utilitising OGRE in their games / demos / applications.
User avatar
houssem_bdioui
Kobold
Posts: 31
Joined: Tue May 11, 2004 8:09 am
Location: Tunisia

Post by houssem_bdioui »

Firegod wrote::?: I think I must be missing something here, I've been using ODE in OGRE already. Isn't it built into Ogre? Whats the difference between whats being used in the collision demo and what monster is working on?
Paul.
AFAIK, what is used by the collision demo is based on the Reference Application layer which is was just given as an example of what can be done. So, it is incomplete and more probably not subject to further maintenance/development.
So monster is now working on something more robust and complete.
Thanks monster :)
User avatar
Firegod
Gnoblar
Posts: 13
Joined: Mon May 17, 2004 10:00 am
Location: Taree, Australia

Post by Firegod »

Where can I get Monsters offering to try?
If in doubt, whip it out!
User avatar
houssem_bdioui
Kobold
Posts: 31
Joined: Tue May 11, 2004 8:09 am
Location: Tunisia

Post by houssem_bdioui »

jacmoe wrote:
monster wrote:I'm planning to utilise this in my entry to the Retro Remakes 2004 competition, which is pencilled in to start in July. So fingers crossed it'll all be complete and tested by then, together with additional wrappers to make it easier to create vehicles and ragdolls.
Wait, patiently, wait ... :)
:lol:
User avatar
bad_camel
Halfling
Posts: 74
Joined: Tue Dec 17, 2002 11:57 am
Location: Somerset, England

Post by bad_camel »

I'm saying that if each part of the heli is a seperate mesh/node/proxy combo, the distances between eah part will have to be trial and error guessing unless monster has a script he can read from to set this for him.

This also assumes compound geom just means different geoms offset from the body origin.
User avatar
monster
OGRE Community Helper
OGRE Community Helper
Posts: 1098
Joined: Mon Sep 22, 2003 2:40 am
Location: Melbourne, Australia

Post by monster »

Hello, I'm not ignoring everyone. I've been moving house this weekend. Boxes everywhere, haven't got a broadband connection, shut my thumb in the car door, etc, etc...

Anyway.
I've been using ODE in OGRE already. Isn't it built into Ogre?
In case it hasn't been mentioned before; Ogre is a graphics engine. It has no collision detection or physics simulation built in. Yes, it comes with the ReferenceApplicationLayer (note the name!), but that's just an example of how to integrate an external library with Ogre. There a quite a few bits of ODE missing from there.

This library attempts to cover every bit of ODE's functionality, and keep it wrapped up nicely in C++.
I'm saying that if each part of the heli is a seperate mesh/node/proxy combo, the distances between eah part will have to be trial and error guessing unless monster has a script he can read from to set this for him.
Indeed. Actually I get the position and location of the different parts from my modeler (AC3D) by highlighting the parts I want to wrap up and reading the values it gives me for the selection bounding box. But, yes, currently they're hardcoded.

At the moment the library is just a complete wrapper around ODE. It adds a bit of extra functionality, but not much. Pretty much whatever you would do in a normal ODE application you do in this wrapper. But there's the wiring there to connect Ogre SceneNodes to ODE bodies, and all the data types (Quaternions, Vector3, etc) are Ogre ones so you don't have to bother converting them yourself.

Eventually you should be able to, for example, give the library a SceneNode and it will create compound geoms from the attached entities and even the sub-meshes that those entities use. But that's in the future. As is the ability to create ragdolls automatically based on skeletons, and vehicles based on SceneNodes with certain fixed naming conventions.

Now, which box was that network router in...
tlaloc
Kobold
Posts: 35
Joined: Mon May 03, 2004 5:03 pm

Post by tlaloc »

Hello! I'm making a simulation using Ogre and ODE and my simulation detects the collsion because the objects (geoms) collide with each others, but when a geom is suposed to stand in top of a plane (or another geom) - the plane is the floor - it stands there for a while, but then "Pufff", the things disapear and the Geoms (or bodys) gets this coordenates:

x = 1.#QNAN00000000000;
Y = 1.#QNAN00000000000;
Z = 1.#QNAN00000000000;

These values appears to in the depth field of the dContactGeom structure.
I can't get these things working perfectly and I don't know why :'(.

I have research the internet and I have found that the 1.#QNAN0 and -1.#IND00 are due to a floating point exception. Can anyone tell me why is this happening or how can I avoid this?

You can see a debug file created showing at each time step the values of the two Geoms (o1 and o2) the i value of contact, and the position of the bodys o1 and o2 here

Any suggestions? Thanks!

Miguel
User avatar
houssem_bdioui
Kobold
Posts: 31
Joined: Tue May 11, 2004 8:09 am
Location: Tunisia

Post by houssem_bdioui »

Be sure that your objects are not inter-penetrating when the simulation starts.
This is a possible cause of the explosion of the system (or "Pufff" if you want :) ).

Also check your parameters : objects' masses, gravity, ...
The parameters must be coherent.
tlaloc
Kobold
Posts: 35
Joined: Mon May 03, 2004 5:03 pm

Post by tlaloc »

houssem_bdioui wrote:Be sure that your objects are not inter-penetrating when the simulation starts.
This is a possible cause of the explosion of the system (or "Pufff" if you want :) ).
I've checked and that is not the problem.
houssem_bdioui wrote: Also check your parameters : objects' masses, gravity, ...
The parameters must be coherent.
What do you mean by the parameters coherent? I'm using gravity= (0,-10,0) and the masses of the objects are 3. I've notice that the problem only affects boxes and cylinders and not spheres. I supose it have to do with the contact points, when more than one are generated the thing explodes - puff!
User avatar
houssem_bdioui
Kobold
Posts: 31
Joined: Tue May 11, 2004 8:09 am
Location: Tunisia

Post by houssem_bdioui »

Well, first if you are not using the last ode release (0.5), install it.

The incovenient of ode is that it is very sensible to the parameters : masses, scales, ...

What I can advise you is that you must play with them until you get something more stable. Also it is better to normalize them so that they are around 1.
User avatar
monster
OGRE Community Helper
OGRE Community Helper
Posts: 1098
Joined: Mon Sep 22, 2003 2:40 am
Location: Melbourne, Australia

Post by monster »

Against my better judgement I've stuck up what I've currently got done for OgreOde on the web. You can get it here, but note the caveats below;
Link Removed - This Version is Obsolete [1.57Mb]

Run the installer and point it at your ogrenew (0.14.0) folder, the default is C:\Development\ogrenew, but you can change that. If you've already compiled Ogre go to ogrenew\Samples\Common\bin\Release and run Demo_OgreOdeDemo.exe, brief instructions are in the panel top left of your screen.

Caveats;
1) Hopefully I've included all the necessary DLLs and Media to run the compiled example, which is also included. And hopefully no .NET dependencies have snuck in there.

2) Possibly I've also included everything you need to build the library and the example, but possibly not.

3) You might be able to import the supplied projects (VC7.1 only, sorry) into your Ogre solution and subsequently batch build them, but you might need to check the settings, particularly the Working Directory which doesn't seem to get saved with the projects.

4) This is just a quick dump of my development directories to (if it works) give you something to play around with. It's far from feature complete and bug free. Hopefully both of those issues will be addressed in the next few months as my "plan" (see earlier in the thread) progresses. In particular a number of the features currently implemented in the test application need to be moved into the core library (the world update loop, the creation of TriMeshes from Ogre entities, etc).

5) Be aware that support for this library is likely to be limited over the next few months, but please post any bug reports or enhancement requests here and I'll see what I can do. Just don't expect another release until after the competition!

And finally; Please DO NOT redistribute any of the media provided with this demo. As far as I'm aware, it's all available for free at various places on the web so go off and find it yourself! Proper credits will be in the readme for the "official" release.

Have Fun.
Last edited by monster on Wed Oct 27, 2004 6:51 am, edited 1 time in total.
User avatar
psyclonist
OGRE Expert User
OGRE Expert User
Posts: 286
Joined: Fri Nov 01, 2002 3:54 pm
Location: Berlin & Nuremberg, Germany
x 1

Post by psyclonist »

On a side note:
1) You can easily load VC7.1 projects into VC7 by modifying the version number in the .sln and .vcproj files.
2) The working directory is stored in the <solutionName>.suo file, AFAIK.

Sorry, but I had no time yet to look at the code itself :)

-psy
User avatar
Borundin
Platinum Sponsor
Platinum Sponsor
Posts: 243
Joined: Fri Oct 03, 2003 5:57 am
Location: Sweden
x 2

Post by Borundin »

Wow :o

Havent had time to try it out yet Monster, but if it is anything like your other released goodies (AC3D exporter/importer, MyCar Tutorial etc) then its something worth downloading!
Image : Image
User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19269
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 66

Post by sinbad »

@monster: Thanks for doing that - even if it does have problems I'm sure it will be very useful to people.

Do you want to put it in ogreaddons now? At least that way people can prepare patches / get updates more easily so maybe it'll make your life easier...
Mdobele
Halfling
Posts: 55
Joined: Mon Jun 07, 2004 11:01 am

Post by Mdobele »

*Said it in another post but I'll say it here again*

THHHHHHHHHANK YOOOOOOOOOOU :D

I was going nuts trying to get a trimesh to work correctly and thanks to your demo I was able to fix my problem in 2 minutes. Hoorah

Great Work.

Mdobele

Oh it installed and worked no problems on my machine.
using VS.NET2003 ( 7.1.3088 )
supersuper
Greenskin
Posts: 114
Joined: Wed Feb 11, 2004 5:41 pm
Location: England!

Post by supersuper »

Well done - it runs lovely on a high speed processor but less so on a lesser CPU (600mhz). Anyway, it runs superb. :)

I am using VS 2002. So I converted both the OGREODE and the demo scripts to VS2002 and then changed the stdext:: to std:: and it worked.

Monster: are we allowed to use your wrapper code in our own applications starting from now?

Thanks :)
User avatar
monster
OGRE Community Helper
OGRE Community Helper
Posts: 1098
Joined: Mon Sep 22, 2003 2:40 am
Location: Melbourne, Australia

Post by monster »

it runs lovely on a high speed processor but less so on a lesser CPU (600mhz).

Somehow that doesn't surprise me! Currently, in the demo, the physics update is fixed at 200Hz, which probably accounts for quite a lot of the processing time. When the world update loop's moved into the core library that'll be adjustable, and hopefully eventually it'll be possible to interpolate between physics updates.
I converted both the OGREODE and the demo scripts to VS2002 and then changed the stdext:: to std:: and it worked.

Excellent news! Would it be possible for you to mail me the changes you made?
are we allowed to use your wrapper code in our own applications starting from now?
Sure, if you like. Hopefully the current interface won't change much in the future since it's pretty much just an exact wrapper of ODE. There'll just be additional functionality added so that you have to do less manual setup of bodies and geometry, and less "housekeeping" of created objects, frame updates, etc.

I'm thinking that something like a .physics script file might be quite nice, to save the amount of tweak/compile/run cycles. And reading the threads about the Antiarc (et al) editor and it's plugin architecture makes me think that a plugin to create these script files might be quite cool. But maybe I'm getting ahead of myself!
Do you want to put it in ogreaddons now?
I think I'd prefer to wait a little while, if you don't mind, until a few more features are ready.
Guest

Post by Guest »

monster I took a look at your code and I think it's very well written, but when I call (for example) getPosition of OgreOde::Body it returns a ref to a static Vector3 (same as getBoundingBox, getOrientation and so on...), so consider this code:

Code: Select all


OgreOde::Body body1;
OgreOde::Body body2;
//   init bodies...

const Vector3 &pos1 = body1.getPosition();
//   imagine pos1 = 0, 0, 0

const Vector3 &pos2 = body2.getPosition();
//   imagine pos2= 100, 100, 100

bool same = pos1 == pos2;    // true o false?

User avatar
psyclonist
OGRE Expert User
OGRE Expert User
Posts: 286
Joined: Fri Nov 01, 2002 3:54 pm
Location: Berlin & Nuremberg, Germany
x 1

Post by psyclonist »

monster wrote:I'm thinking that something like a .physics script file might be quite nice, to save the amount of tweak/compile/run cycles.
Do you mean a file format for describing physics objects?
Then take a look at XODE (I cannot provide a link right now from here, but there has been a long thread on it on the ODE mailing list).

-psy
User avatar
monster
OGRE Community Helper
OGRE Community Helper
Posts: 1098
Joined: Mon Sep 22, 2003 2:40 am
Location: Melbourne, Australia

Post by monster »

when I call (for example) getPosition of OgreOde::Body it returns a ref to a static Vector3 (same as getBoundingBox, getOrientation and so on...)
Bugger. Yes, good point. That'll teach me to blindly cut'n'paste and find'n'replace!

Thanks.
Do you mean a file format for describing physics objects?

Kind of. But more Ogre centric. Specifically; a big decision during the specification of XODE was to NOT have any references to the visual objects that would be representing your physical things. Obviously the .physics format would have to have this so you could specify what your scene looks like with (for example) a .scene file, then make it physical with a .physics script. Maybe the physics script could contain references to XODE files, so it would effectively be the link between the Ogre (.scene) and the ODE (.xode) worlds.

Also, at this stage I'm thinking that the .physics script would probably be a bit simpler than the XODE specification, and it would be in pseudo-C++ for consistency with the other scripts.
User avatar
Berserker
Kobold
Posts: 25
Joined: Sat May 01, 2004 3:41 pm

Post by Berserker »

Ops forgot to login, "Guest" was me :lol:
supersuper
Greenskin
Posts: 114
Joined: Wed Feb 11, 2004 5:41 pm
Location: England!

Post by supersuper »

Monster, am emailing you as I type.
User avatar
psyclonist
OGRE Expert User
OGRE Expert User
Posts: 286
Joined: Fri Nov 01, 2002 3:54 pm
Location: Berlin & Nuremberg, Germany
x 1

Post by psyclonist »

I'm interested in the physics format as I have something similar in the pipeline and maybe we can up with something useful and even pseudo-standard, as we did with the .scene format (if anyone still remembers the early beginnings)?
monster wrote:Maybe the physics script could contain references to XODE files, so it would effectively be the link between the Ogre (.scene) and the ODE (.xode) worlds.
That's what I've planned to do. We already have (pseudo-)standard formats for visual (.scene) and physical (.xode) representation. I think it would be perfect to create the link inbetween. Also tool chains can benefit from it as you can still continue to work with tools that create .scene or .xode files and then link them up using another format (like .link ;) ).

I like the idea of a few "standard" formats which can be used with OGRE as it encourages tool writers to support them and reduces the amount of work to write parsers, converters, etc. After all we want to create content fast & easy :)
monster wrote:Also, at this stage I'm thinking that the .physics script would probably be a bit simpler than the XODE specification, and it would be in pseudo-C++ for consistency with the other scripts.
We (@yake) use an abstract parser similar to what came up in a recent discussion about the Axiom World Editor. Basically it's a simple to use abstract DOM interface which allows different implementations to be used with the same interface (binary, XML, "pseudo-c++ style" a la OGRE ...).
In short, a simple pseudo-C++ syntax would be perfect :)

In case you are interested, I can show some example files to demonstrate what it could look like in actual use...

Tell me what you think.

-psy
User avatar
monster
OGRE Community Helper
OGRE Community Helper
Posts: 1098
Joined: Mon Sep 22, 2003 2:40 am
Location: Melbourne, Australia

Post by monster »

Monster, am emailing you as I type.
Cool, got it. Thanks a lot.
In case you are interested, I can show some example files to demonstrate what it could look like in actual use...


Yeah, I'd love to see some examples.

The more I think about it, the more I like the "linking" idea so that a .physics script could be nice and simple, all the complex stuff lives in the .scene (or whatever) and .xode files. The .physics script could then just reference the visual and physical objects respectively. Additionally you could have visual nodes that don't have xode definitions, and the .physics script could allow you to auto-create the geometries based on the entities and meshes, or you might be able to import an xode object and automatically create SceneNodes to visually represent it.

But really I'm just thinking aloud! And this'll be a fair way down the track probably.

Still, any ideas are welcome.
User avatar
psyclonist
OGRE Expert User
OGRE Expert User
Posts: 286
Joined: Fri Nov 01, 2002 3:54 pm
Location: Berlin & Nuremberg, Germany
x 1

Post by psyclonist »

That pretty much sums up what I think about it, too :)
Basically it would allow us to use tools which are specialized to use one of the existing formats (.scene, .xode) without having to reinvent the wheel. And from a design point of view I like the idea of linking visual, physical, audible etc representations (as this reflects the concepts behind the engine I use).

I'll upload something later. I can't do that from here.

-psy
supersuper
Greenskin
Posts: 114
Joined: Wed Feb 11, 2004 5:41 pm
Location: England!

Post by supersuper »

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. :)