feature request .. and code if its wanted

Hi.

I'm aware theres no active maintainer, so if this goes unheard an unanswered thats fine an all,

anyhoo my wish list is.

Make geometry a moveable object so it can be attached to a SceneNode and moved about, easily done and very useful I think.

Create a CollisionCallback class inheriting from CollisionListener specifically for colliding spaces so that inheriting classes can decide if they want to collide with that space or geometry.

In TriangleMeshGeometry have a constructor that takes a sharedPtr to the ode geometry stuff.. and an option to set the sharedPtr. I find I often want to rescale a mesh... and in a forest of a thousand trees its better to have the data once rather than a thousand times.

Let it be noted I'm pretty mediocore with ode and ogreode, so if these are pointless, or theres already a way and I just missed it, I

I've added all of these to my ogreode, and I genuinely fine them useful, if its wanted I could try and put a patch together, not something I've ever done before.

regards cloud.

Make geometry a moveable object so it can be attached to a SceneNode and moved about, easily done and very useful I think.

Can you please be more specific here? Because with the way things are right now - you just do:

SomeBody->setPosition(Vector3(x,y,z));
SomeBody->setOrientation(whatever);
And your Geometry or Geometries just get attached to this body via ->attach

As far Collisions go, yep I guess you are right here. But, to be honest, as I see it, CollisionListener class needs to be given a way more in depth revision.

For the TriangleMesh - well, once again, here we need some more revisions, since the update to ode 0.9 (not sure if Tuan had looked into it), but I've noticed a couple of changes, which I think we could benefit from.

For the coding, then it would be great, if you could submit some changes to the project. I too, like you, have been using ode for a while now, and have several changes to OgreOde, so now I'm trying to make the changes to the CVS version. Would be a good idea to implement as many changes as possible, since OgreOde would only benefit from a facelift

On the first one Geometry->MoveableObject,

I think because a geometry with no body attached is considered to be of infinite mass, maybe theres a way to set the mass of a body to infinitity and turn the gravity off, if there is then I didn't realise it. But I do think its nice to be able to attach to a SceneNode and move a geometry around like it was any other MoveableObject.

Has the cvs code changed much lately? I had a look through it yesterday and it doesn't appear any different at first glace. And when you make a patch... should you always start out from a clean copy of the latest cvs? you hinted yes. But cloud likes things spelled out preferably in big capital letter heh.

I see what you mean about the geometry here. Well, I doubt it would be hard to implement, however, I'm still not too sure as to what is a practical use for it? Maybe I'm just missing something here , so please just give me an example of where do you use such a function.
And, yeah, I think that was possible to do with a body of infinite mass, but need to look again in the context of what you plan to use it for.

As far as patching goes, then
1) CVS indeed has not changed much lately. Some files are still back from 2006... And the official SDK is January 2007, since then, AFAIK, the main change has been Dagon-to-Eihort support change, and that's about it
2) Indeed, if you want to path it, you need to do a checkout of the CVS (try TortoiseCVS, for instane), then copy the files elsewhere (so that files, like .user, or intellisense db or whatever else, do not get pathed afterwards), then copy your modified version of the .h or .cpp files, and click "submit patch". That's about it.

Added code in CVS.

oh wow thanks!

An example of using Geometry as a MoveableObject would be in a level editor for static triangle meshs (perhaps geometries with no bodies) where the meshs need to be moved around and reorientated. I'll agree its not really needed and the same can be achive by setting the geom independently of the SceneNode -- Entity on it independently. I've thought about it since and MoveableObject seems to change alot in the Ogre updates, so it might end up hurting more people than it helped - left it out.

Still wondering if I should submit the SharedPtr, would mean having to add 2 new classes the SharedPtr and a Singleton manager and several functions to create/recreate TriangleMeshGeometry in EntityInformer, and a new constructor to TriangleMeshGeometry. Is it worth it?

Hey, Cloud, may I ask - what exactly was in the last patch you've submitted? Since I accidentally erased the source code just before your patch, and only got libs from that time. However, right after the patch, demos are all fine. But if I put the newly changed version into my app, all I get is no stepping and REALLY wierd random explosions/shakings/random transformations... Looks like something went a bit wrong

Just looked deeper into it, seems to be a problem with a change in OgreOdeStepper.cpp
Sad, I cannot see what exactly was changed to debug it...

-EDIT-

Got it. The problem is with this function:
bool StepHandler::prepareSteppingTime(const Ogre::Real time).

More specifically, it is with the return thing:

return (_total_time - cEpsilon > 0);

When I test this in my app, it just seems to return true only like 1-2 times a second max. So either setting it to always true (like it was before change), or changing the condition solves the problem.
Now, thinking about this, maybe the change was not really worth it?

I honestly never touched OgreOdeStepper.

Thats your turf

It was just all joint related stuff, and the one before that was the collision callback

Files I changed were the joint, utility and collision ones. Think but not sure, that you can download the patches and see, but I'm almost positive that nothing in OgreOdeStepper was added or taken away.

Oh gosh it seems from the code I've got an old stepper!

I shall update!

I honestly never touched OgreOdeStepper.

Well, then it's gotta be something Tuan changed. Just check the lates CVS version, and you can see, that the OgreOdeStepper.cpp was changed. Dunno who did it, but surely it gives some bugs...

Hmm, it seems to work fine over here.

Thats with ForwardFixedStepHandler and QuickStep. Are you using something else?

well, nearly same - ForwardInterpolatedStepHandler and QuickStep. But I use NotAutomatic though.

I don't know if this will help, but from a patch of the new with the old

//------------------------------------------------------------------------------------------------
bool StepHandler::isRunning(const Ogre::Real time)
{
- if (!_paused)
+ if (!_paused
+ && time - cEpsilon > 0
+ )
{
return true;
}
@@ -136,16 +138,9 @@
bool StepHandler::prepareSteppingTime(const Ogre::Real time)
{
// make sure time is not too high (alt-tab, debug)
- if (_max_interval - time < cEpsilon
- )
- {
- _total_time += _max_interval * _time_scale;
- }
- else
- {
- _total_time += time * _time_scale;
- }
- return (_total_time - cEpsilon > 0);
+ const Ogre::Real t = (_max_interval - time < cEpsilon) ? _max_interval : time;
+ _total_time += t * _time_scale;
+ return true;
}
//------------------------------------------------------------------------------------------------
bool StepHandler::step(const Ogre::Real time)
@@ -324,7 +319,7 @@
// last Special Single Step is specific as we save last state prior stepping.
_world->updatePreviousState ();
// compute next Frame physic state
- StepHandler::basicStep(_step_size);
+ StepHandler::basicStep(_step_size)
_world->updateCurrentState ();
}



I've never used this stepper, and when I tried my ragdoll had its limbs all dismembered.