Nabble - ODE

Re: Re: Steering using ERP - any better way?

2009-12-09T08:49:49Z

I think setting the target of the tie rods is not a bad way to go.

However, on a game controller, you can switch between full-left and
full-right basically instantly. On a real car, such movement would
take a significant fraction of a second (even if you use proportional
input on the game controller).

Sincerely,

jw

--
Americans might object: there is no way we would sacrifice our living
standards for the benefit of people in the rest of the world.
Nevertheless, whether we get there willingly or not, we shall soon
have lower consumption rates, because our present rates are
unsustainable.

On Wed, Dec 9, 2009 at 8:07 AM, Nicolas Maire <tenseiken@...> wrote:

> Thanks Daniel, now I understand it a lot better. I will try to
> implement it this way.
>
> --
>
> You received this message because you are subscribed to the Google Groups "ode-users" group.
> To post to this group, send email to ode-users@....
> To unsubscribe from this group, send email to ode-users+unsubscribe@....
> For more options, visit this group at http://groups.google.com/group/ode-users?hl=en.
>
>
>

--

You received this message because you are subscribed to the Google Groups "ode-users" group.
To post to this group, send email to ode-users@....
To unsubscribe from this group, send email to ode-users+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/ode-users?hl=en.

Re: Steering using ERP - any better way?

2009-12-09T08:07:49Z

Thanks Daniel, now I understand it a lot better. I will try to
implement it this way.

--

You received this message because you are subscribed to the Google Groups "ode-users" group.
To post to this group, send email to ode-users@....
To unsubscribe from this group, send email to ode-users+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/ode-users?hl=en.

Re: Steering using ERP - any better way?

2009-12-09T07:30:18Z

I use a hinge2 joint for the front wheels (the "steered" wheels). and use
the following code, where steerAngle[i] is the desired steering angle
(which, I suppose, would be equivalent to your steering wheel position).
Depending on your timing parameters, setting the allowance on the high and
low stops and the restoration force, you can vary the response to the
steering.

dReal curAngle = steerAngle[i] - dJointGetHinge2Angle1(wheelHinge[i]);
curAngle *= 10.0; // quasi-error term
dJointSetHinge2Param (wheelHinge[i],dParamVel,curAngle);
dJointSetHinge2Param (wheelHinge[i],dParamFMax,10.0);
dJointSetHinge2Param (wheelHinge[i],dParamLoStop,steerAngle[i]-0.001);
dJointSetHinge2Param (wheelHinge[i],dParamHiStop,steerAngle[i]+0.001);
dJointSetHinge2Param (wheelHinge[i],dParamFudgeFactor,0.1);

Bruce

----- Original Message -----
From: "Szabolcs Deak" <deak@...>
To: <ode-users@...>
Sent: Wednesday, December 09, 2009 6:14 AM
Subject: [ode-users] Steering using ERP - any better way?

> Hi List,
>
> Please bear with me, this is more of a methodological than a programming
> question.
>
> I have a homegrown rally sim (to be announced in a few months) using ODE
> for
> suspension. The fidelity I aim for and the parameters I set are probably
> over
> the top for most ODE-base applications (geometrically accurate suspension,
> timesteps 1 msec and under), but I only model one car, so I can get away
> with
> throwing quite a lot of computing power at it, and it seems to work OK.
>
> That said, I try to spare as many bodies as possible, and use specialized
> constraints, such as a distance constraint for wishbone arms. I use a
> distance
> constraint for the tie rods as well.
>
> Now we come to the problem of steering. At the beginning of the simulation
> loop for the next frame, I read the actual steering position from the game
> controller (wheel). Obviously, my current steering position and the input
> I
> just read will be out of sync, so I need to update my steering in the
> game.
> This is the point where you have to realize that you either have (some)
> inherent lag for the steering (and other similarly controlled settings),
> or
> you break physical plausibility by setting body positions/orientations
> directly.
>
> What I do in this case is so simple as to seem stupid: I move the inner
> anchor
> points of the "tie rods" to the positions determined by the current input,
> thereby introducing an error in the length of the respective distance
> constraints, and then let the error reduction fix the length by moving the
> wheels to match their steered position. This actually works, and I can
> control
> the process by setting a special ERP for the distance constraints
> representing
> the tie rods.
>
> So my question is: can anybody think of a better way to do this, in terms
> of
> accuracy? I believe if I used a separate body for steering rack,
> constraining
> its "position" would basically result in the same type of forces being
> generated with one more body and a joint in the equation.
>
> Best Regards,
> Szabolcs
>
> --
>
> You received this message because you are subscribed to the Google Groups
> "ode-users" group.
> To post to this group, send email to ode-users@....
> To unsubscribe from this group, send email to
> ode-users+unsubscribe@....
> For more options, visit this group at
> http://groups.google.com/group/ode-users?hl=en.
>
>
>

Re: Race game physics

2009-12-09T05:53:53Z

Nicolas Maire escreveu:
> @Daniel : Yes, I realize that ODE does not really allows what I want
> to do, but I would really like to use it for my whole game physics,
> and properly if possible.

Sure, it'll probably be a learning experience for you. I'm just saying,
don't be surprised if ODE doesn't turn to be too helpful for this task.

> @Jon : I was thinking about this system of thrust in function of the
> distance to the ground, but I'm sorry I do not understand what you
> mean by "casting a ray" ? Is it possible to get the vehicle distance
> to the ground with this system ?

Casting a ray means you create a ray geom pointing "down" at the ship's
bottom, and perform a collision detection test to know how far from the
ground you are. The problem with this is (for F-Zero X, at least) is
when you leave a tube or a pipe you might be even upside down. That's
why I used a sphere; the collision test will return the closest
triangle, and I will use its normal to align it to the surface. It's of
course trivial to compute the distance between this triangle and the ship.

--
Daniel K. O.
"The only way to succeed is to build success yourself"

--

You received this message because you are subscribed to the Google Groups "ode-users" group.
To post to this group, send email to ode-users@....
To unsubscribe from this group, send email to ode-users+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/ode-users?hl=en.

Re: Steering using ERP - any better way?

2009-12-09T05:23:35Z

Szabolcs Deak escreveu:

> What I do in this case is so simple as to seem stupid: I move the inner anchor
> points of the "tie rods" to the positions determined by the current input,
> thereby introducing an error in the length of the respective distance
> constraints, and then let the error reduction fix the length by moving the
> wheels to match their steered position. This actually works, and I can control
> the process by setting a special ERP for the distance constraints representing
> the tie rods.
>
> So my question is: can anybody think of a better way to do this, in terms of
> accuracy? I believe if I used a separate body for steering rack, constraining
> its "position" would basically result in the same type of forces being
> generated with one more body and a joint in the equation.

I'm not sure how you steering apparatus is built, but can't you set the
target velocity of your distance constraints? That would be
middle-ground between setting the position and just using forces.

--
Daniel K. O.
"The only way to succeed is to build success yourself"

--

You received this message because you are subscribed to the Google Groups "ode-users" group.
To post to this group, send email to ode-users@....
To unsubscribe from this group, send email to ode-users+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/ode-users?hl=en.

Steering using ERP - any better way?

2009-12-09T03:12:20Z

Hi List,

Please bear with me, this is more of a methodological than a programming question.

I have a homegrown rally sim (to be announced in a few months) using ODE for
suspension. The fidelity I aim for and the parameters I set are probably over
the top for most ODE-base applications (geometrically accurate suspension,
timesteps 1 msec and under), but I only model one car, so I can get away with
throwing quite a lot of computing power at it, and it seems to work OK.

That said, I try to spare as many bodies as possible, and use specialized
constraints, such as a distance constraint for wishbone arms. I use a distance
constraint for the tie rods as well.

Now we come to the problem of steering. At the beginning of the simulation
loop for the next frame, I read the actual steering position from the game
controller (wheel). Obviously, my current steering position and the input I
just read will be out of sync, so I need to update my steering in the game.
This is the point where you have to realize that you either have (some)
inherent lag for the steering (and other similarly controlled settings), or
you break physical plausibility by setting body positions/orientations directly.

What I do in this case is so simple as to seem stupid: I move the inner anchor
points of the "tie rods" to the positions determined by the current input,
thereby introducing an error in the length of the respective distance
constraints, and then let the error reduction fix the length by moving the
wheels to match their steered position. This actually works, and I can control
the process by setting a special ERP for the distance constraints representing
the tie rods.

So my question is: can anybody think of a better way to do this, in terms of
accuracy? I believe if I used a separate body for steering rack, constraining
its "position" would basically result in the same type of forces being
generated with one more body and a joint in the equation.

Best Regards,
Szabolcs

--

You received this message because you are subscribed to the Google Groups "ode-users" group.
To post to this group, send email to ode-users@....
To unsubscribe from this group, send email to ode-users+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/ode-users?hl=en.

Re: Race game physics

2009-12-08T23:40:47Z

Thank you for your answers :-)
@Daniel : Yes, I realize that ODE does not really allows what I want
to do, but I would really like to use it for my whole game physics,
and properly if possible.
@Jon : I was thinking about this system of thrust in function of the
distance to the ground, but I'm sorry I do not understand what you
mean by "casting a ray" ? Is it possible to get the vehicle distance
to the ground with this system ?

--

You received this message because you are subscribed to the Google Groups "ode-users" group.
To post to this group, send email to ode-users@....
To unsubscribe from this group, send email to ode-users+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/ode-users?hl=en.

Re: Race game physics

2009-12-08T19:56:00Z

Generally, you will want to create hovering behavior by casting a ray
(or more rays) and applying a counter-thrust based on how close to the
surface you are, and what your velocity already is. If you're already
moving away from the surface, no need to apply more force; if you're
moving towards the surface and you're "too close," then add a force
proportional to, for example, the square of the distance error times
the current velocity towards the surface, plus some constant.

Sincerely,

jw

--
Americans might object: there is no way we would sacrifice our living
standards for the benefit of people in the rest of the world.
Nevertheless, whether we get there willingly or not, we shall soon
have lower consumption rates, because our present rates are
unsustainable.

On Tue, Dec 8, 2009 at 2:47 PM, Daniel K. O. <danielko.listas@...> wrote:

> Nicolas Maire escreveu:
>> I'm relatively new to ODE, and I just managed to get it to work with
>> trimeshes. Now, I would like to use it in a race game, but in the F-
>> Zero style, so not with cars, but with little space ships. So I
>> wondered if it was possible to have my space ships affected by
>> gravity, but also "floating" from some distance over the ground (like
>> in F-Zero) ? I see how to achieve this with a constant height, but the
>> problem is that my ground is not a constant plane.
>> If anyone has an idea, some help would be very appreciated :-)
>
> I did this once (a F-Zero X clone, with ships exported from the N64 game
> and all).
>
> I had two spheres attached to each ship; one to detect when "close
> enough" so the ship would be attracted to the nearest surface (using its
> normal to align the ship), and one to detect when "too close", to stop
> attracting the ship.
>
> At first I was using ODE for physics, but it only got in the way when I
> had to tweak the parameters to make it playable. In the end I just used
> ODE for collision detection.
>
> And it makes sense, as ODE is meant for rigid body with stiff
> constraints, not exactly what you would expect from ships traveling at
> more than 1000 KPH floating less than one meter above the ground, where
> aerodynamics dominate over any other phenomenon.
>
> --
> Daniel K. O.
> "The only way to succeed is to build success yourself"
>
> --
>
> You received this message because you are subscribed to the Google Groups "ode-users" group.
> To post to this group, send email to ode-users@....
> To unsubscribe from this group, send email to ode-users+unsubscribe@....
> For more options, visit this group at http://groups.google.com/group/ode-users?hl=en.
>
>
>

"Freezing" bodies

2009-12-08T15:34:12Z

Hello!

I'm optimizing my game for the PSP and I've realized that is quite
stupid to simulate lot of vehicles when you are only driving one. So I
have modified the code so when I use one vehicle the rest of vehicles
are disabled, this means no step occurs with them.
But this approach gives me problems: first is that when the current
vehicle collides the other one this vehicle can result in a undesired
position (for example falling in the air) but as it is disabled it
doesn't fall.

I'm thinking in having to models, one with the wheels and all the
stuff and other more simple and exchange them to accelerate the
process.

Is there any method of doing this faster and without all the coding?

Thanks in advance

David

--

You received this message because you are subscribed to the Google Groups "ode-users" group.
To post to this group, send email to ode-users@....
To unsubscribe from this group, send email to ode-users+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/ode-users?hl=en.

Re: Race game physics

2009-12-08T14:47:39Z

Nicolas Maire escreveu:
> I'm relatively new to ODE, and I just managed to get it to work with
> trimeshes. Now, I would like to use it in a race game, but in the F-
> Zero style, so not with cars, but with little space ships. So I
> wondered if it was possible to have my space ships affected by
> gravity, but also "floating" from some distance over the ground (like
> in F-Zero) ? I see how to achieve this with a constant height, but the
> problem is that my ground is not a constant plane.
> If anyone has an idea, some help would be very appreciated :-)

I did this once (a F-Zero X clone, with ships exported from the N64 game
and all).

I had two spheres attached to each ship; one to detect when "close
enough" so the ship would be attracted to the nearest surface (using its
normal to align the ship), and one to detect when "too close", to stop
attracting the ship.

At first I was using ODE for physics, but it only got in the way when I
had to tweak the parameters to make it playable. In the end I just used
ODE for collision detection.

And it makes sense, as ODE is meant for rigid body with stiff
constraints, not exactly what you would expect from ships traveling at
more than 1000 KPH floating less than one meter above the ground, where
aerodynamics dominate over any other phenomenon.

--
Daniel K. O.
"The only way to succeed is to build success yourself"

--

You received this message because you are subscribed to the Google Groups "ode-users" group.
To post to this group, send email to ode-users@....
To unsubscribe from this group, send email to ode-users+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/ode-users?hl=en.

Re: Race game physics

2009-12-08T11:24:22Z

don't contact with ground?

this is "air-plane system"?

On 8 dez, 17:13, Nicolas Maire <tensei...@...> wrote:

> Hello,
> I'm relatively new to ODE, and I just managed to get it to work with
> trimeshes. Now, I would like to use it in a race game, but in the F-
> Zero style, so not with cars, but with little space ships. So I
> wondered if it was possible to have my space ships affected by
> gravity, but also "floating" from some distance over the ground (like
> in F-Zero) ? I see how to achieve this with a constant height, but the
> problem is that my ground is not a constant plane.
> If anyone has an idea, some help would be very appreciated :-)
> Thanks in advance, and sorry for my poor English

Race game physics

2009-12-08T11:13:13Z

Hello,
I'm relatively new to ODE, and I just managed to get it to work with
trimeshes. Now, I would like to use it in a race game, but in the F-
Zero style, so not with cars, but with little space ships. So I
wondered if it was possible to have my space ships affected by
gravity, but also "floating" from some distance over the ground (like
in F-Zero) ? I see how to achieve this with a constant height, but the
problem is that my ground is not a constant plane.
If anyone has an idea, some help would be very appreciated :-)
Thanks in advance, and sorry for my poor English

--

You received this message because you are subscribed to the Google Groups "ode-users" group.
To post to this group, send email to ode-users@....
To unsubscribe from this group, send email to ode-users+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/ode-users?hl=en.

Re: Re: what happens to geoms on dBodyDestroy?

2009-12-08T08:06:56Z

Note that the "latest" user guide on the site is for v0.5.

You can find the functions referenced in the ODE manual:
http://opende.sourceforge.net/wiki/index.php/Manual_%28Rigid_Body_Functions%29

or download a PDF of the manual for v0.10:
http://groups.google.com/group/ode-users/files

Bruce

----- Original Message -----
From: "christian" <ch.sc@...>
To: "ode-users" <ode-users@...>
Sent: Tuesday, December 08, 2009 8:24 AM
Subject: [ode-users] Re: what happens to geoms on dBodyDestroy?

> thx, now I found them too. I was always looking at the latest user
> guide, which doesn't contain them.

--

You received this message because you are subscribed to the Google Groups "ode-users" group.
To post to this group, send email to ode-users@....
To unsubscribe from this group, send email to ode-users+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/ode-users?hl=en.

Re: what happens to geoms on dBodyDestroy?

2009-12-08T05:24:40Z

thx, now I found them too. I was always looking at the latest user
guide, which doesn't contain them.

On 7 Dez., 19:28, Klaus Backert <Klaus.Back...@...> wrote:

> On 7 Dec 2009, at 17:05, christian wrote:
>
>
>
> > thx Klaus, but i wanted to know about bodys. Or shall I use an extra
> > space for every body? Doesn't this have influence on the performance?
> > Right now I'm saving both the body and the geom and delete both. it
> > would be nice to have a function that return the geoms of a body, so I
> > don't need to have 2 variables for (in my case) almost the same. Just
> > like dGeomGetBody, but the other way round.
>
> > Greetings
> > Christian
>
> > On 7 Dez., 16:21, Klaus Backert <Klaus.Back...@...> wrote:
> >> Hi, Christian,
>
> >> On 7 Dec 2009, at 15:26, christian wrote:
>
> >>> Hi, what happens to the geoms attached to a Body, when the body is
> >>> destroied? As far as i can see in my simulation, they stay in the
> >>> space. Is there a function to remove these geoms from their space,
> >>> or
> >>> at least, to get the geoms attached to this body, or do i need to
> >>> store them seperately?
>
> >> From the ODE manual:
>
> >> void dSpaceDestroy (dSpaceID);
>
> >> This destroys a space. It functions exactly like dGeomDestroy except
> >> that it takes a dSpaceID argument. When a space is destroyed, if its
> >> cleanup mode is 1 (the default) then all the geoms in that space are
> >> automatically destroyed as well.
>
> >> void dSpaceSetCleanup (dSpaceID space, int mode);
> >> int dSpaceGetCleanup (dSpaceID space);
>
> >> Set and get the clean-up mode of the space. If the clean-up mode is
> >> 1,
> >> then the contained geoms will be destroyed when the space is
> >> destroyed. If the clean-up mode is 0 this does not happen. The
> >> default
> >> clean-up mode for new spaces is 1.
>
> >> Klaus
>
> Again from the ODE manual:
>
> dGeomID dBodyGetFirstGeom(dBodyID b);
> dGeomID dBodyGetNextGeom(dGeomID g);
>
> Give access to all geoms associated with a body. Use
> dBodyGetFirstGeom() to retrieve the first geom,then call
> dBodyGetNextGeom() with the previous geom as argument, to retrieve the
> next.
>
> Klaus

Re: Re: Collision problem with trimesh

2009-12-07T13:20:38Z

You should build ODE from source into your project, so you get full
debug symbols. Specifically, you generally can add most of the .c
files from the ODE source folder straight into a project, set the
include paths to point at the ODE headers, and use autoconf or cmake
or whatever just to generate an ODE config file.
I would recommend memset()-ing the entire Contacts array to 0 before
you call dCollide(), too.

Sincerely,

jw

--
Americans might object: there is no way we would sacrifice our living
standards for the benefit of people in the rest of the world.
Nevertheless, whether we get there willingly or not, we shall soon
have lower consumption rates, because our present rates are
unsustainable.

On Sun, Dec 6, 2009 at 2:07 PM, Daniel K. O. <danielko.listas@...> wrote:

> Regis escreveu:
>> Ans. to "second" : It is a bit hard to answer this question because I
>> am using ODE in a homebrew PSP game => a bit hard to debug.
>
> Does the crash happen when you build the same code to run on a PC?
>
> Isn't it possible to attach a debugger, or at least get a core dump when
> you run it on the PSP?
>
>
> --
> Daniel K. O.
> "The only way to succeed is to build success yourself"
>
> --
>
> You received this message because you are subscribed to the Google Groups "ode-users" group.
> To post to this group, send email to ode-users@....
> To unsubscribe from this group, send email to ode-users+unsubscribe@....
> For more options, visit this group at http://groups.google.com/group/ode-users?hl=en.
>
>
>

Re: Re: what happens to geoms on dBodyDestroy?

2009-12-07T10:28:25Z

On 7 Dec 2009, at 17:05, christian wrote:

> thx Klaus, but i wanted to know about bodys. Or shall I use an extra
> space for every body? Doesn't this have influence on the performance?
> Right now I'm saving both the body and the geom and delete both. it
> would be nice to have a function that return the geoms of a body, so I
> don't need to have 2 variables for (in my case) almost the same. Just
> like dGeomGetBody, but the other way round.
>
> Greetings
> Christian
>
>
> On 7 Dez., 16:21, Klaus Backert <Klaus.Back...@...> wrote:
>> Hi, Christian,
>>
>> On 7 Dec 2009, at 15:26, christian wrote:
>>
>>> Hi, what happens to the geoms attached to a Body, when the body is
>>> destroied? As far as i can see in my simulation, they stay in the
>>> space. Is there a function to remove these geoms from their space,
>>> or
>>> at least, to get the geoms attached to this body, or do i need to
>>> store them seperately?
>>
>> From the ODE manual:
>>
>> void dSpaceDestroy (dSpaceID);
>>
>> This destroys a space. It functions exactly like dGeomDestroy except
>> that it takes a dSpaceID argument. When a space is destroyed, if its
>> cleanup mode is 1 (the default) then all the geoms in that space are
>> automatically destroyed as well.
>>
>> void dSpaceSetCleanup (dSpaceID space, int mode);
>> int dSpaceGetCleanup (dSpaceID space);
>>
>> Set and get the clean-up mode of the space. If the clean-up mode is
>> 1,
>> then the contained geoms will be destroyed when the space is
>> destroyed. If the clean-up mode is 0 this does not happen. The
>> default
>> clean-up mode for new spaces is 1.
>>
>> Klaus

Again from the ODE manual:

dGeomID dBodyGetFirstGeom(dBodyID b);
dGeomID dBodyGetNextGeom(dGeomID g);

Give access to all geoms associated with a body. Use
dBodyGetFirstGeom() to retrieve the first geom,then call
dBodyGetNextGeom() with the previous geom as argument, to retrieve the
next.

Klaus

--

You received this message because you are subscribed to the Google Groups "ode-users" group.
To post to this group, send email to ode-users@....
To unsubscribe from this group, send email to ode-users+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/ode-users?hl=en.

Re: Re: what happens to geoms on dBodyDestroy?

2009-12-07T10:25:37Z

How about dBodyGetFirstGeom(dBodyID b)?

----- Original Message -----
From: "christian" <ch.sc@...>
To: "ode-users" <ode-users@...>
Sent: Monday, December 07, 2009 11:05 AM
Subject: [ode-users] Re: what happens to geoms on dBodyDestroy?

> thx Klaus, but i wanted to know about bodys. Or shall I use an extra
> space for every body? Doesn't this have influence on the performance?
> Right now I'm saving both the body and the geom and delete both. it
> would be nice to have a function that return the geoms of a body, so I
> don't need to have 2 variables for (in my case) almost the same. Just
> like dGeomGetBody, but the other way round.
>
> Greetings
> Christian
>
>
> On 7 Dez., 16:21, Klaus Backert <Klaus.Back...@...> wrote:
>> Hi, Christian,
>>
>> On 7 Dec 2009, at 15:26, christian wrote:
>>
>> > Hi, what happens to the geoms attached to a Body, when the body is
>> > destroied? As far as i can see in my simulation, they stay in the
>> > space. Is there a function to remove these geoms from their space, or
>> > at least, to get the geoms attached to this body, or do i need to
>> > store them seperately?
>>
>> From the ODE manual:
>>
>> void dSpaceDestroy (dSpaceID);
>>
>> This destroys a space. It functions exactly like dGeomDestroy except
>> that it takes a dSpaceID argument. When a space is destroyed, if its
>> cleanup mode is 1 (the default) then all the geoms in that space are
>> automatically destroyed as well.
>>
>> void dSpaceSetCleanup (dSpaceID space, int mode);
>> int dSpaceGetCleanup (dSpaceID space);
>>
>> Set and get the clean-up mode of the space. If the clean-up mode is 1,
>> then the contained geoms will be destroyed when the space is
>> destroyed. If the clean-up mode is 0 this does not happen. The default
>> clean-up mode for new spaces is 1.
>>
>> Klaus
>
> --
>
> You received this message because you are subscribed to the Google Groups
> "ode-users" group.
> To post to this group, send email to ode-users@....
> To unsubscribe from this group, send email to
> ode-users+unsubscribe@....
> For more options, visit this group at
> http://groups.google.com/group/ode-users?hl=en.
>
>
>
>

Re: what happens to geoms on dBodyDestroy?

2009-12-07T08:05:21Z

thx Klaus, but i wanted to know about bodys. Or shall I use an extra
space for every body? Doesn't this have influence on the performance?
Right now I'm saving both the body and the geom and delete both. it
would be nice to have a function that return the geoms of a body, so I
don't need to have 2 variables for (in my case) almost the same. Just
like dGeomGetBody, but the other way round.

Greetings
Christian

On 7 Dez., 16:21, Klaus Backert <Klaus.Back...@...> wrote:

> Hi, Christian,
>
> On 7 Dec 2009, at 15:26, christian wrote:
>
> > Hi, what happens to the geoms attached to a Body, when the body is
> > destroied? As far as i can see in my simulation, they stay in the
> > space. Is there a function to remove these geoms from their space, or
> > at least, to get the geoms attached to this body, or do i need to
> > store them seperately?
>
> From the ODE manual:
>
> void dSpaceDestroy (dSpaceID);
>
> This destroys a space. It functions exactly like dGeomDestroy except
> that it takes a dSpaceID argument. When a space is destroyed, if its
> cleanup mode is 1 (the default) then all the geoms in that space are
> automatically destroyed as well.
>
> void dSpaceSetCleanup (dSpaceID space, int mode);
> int dSpaceGetCleanup (dSpaceID space);
>
> Set and get the clean-up mode of the space. If the clean-up mode is 1,
> then the contained geoms will be destroyed when the space is
> destroyed. If the clean-up mode is 0 this does not happen. The default
> clean-up mode for new spaces is 1.
>
> Klaus

Error while linking to ODE library

2009-12-07T08:03:51Z

Hi all,

I busy building PVLE on Opensuse 11.2 64bit on a Intel 4 core CPU.

When linking PVLE with various libraries I get this error, that I have no idea what it means. Primary writer of PVLE also has no idea what the cause may be.

Linking CXX shared library ../Lib/libPVLE.so
/usr/lib64/gcc/x86_64-suse-linux/4.4/../../../../x86_64-suse-linux/bin/ld: /usr/local/lib/libode.a(box.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC
/usr/local/lib/libode.a: could not read symbols: Bad value

commands I used to build ODE:
./configure --enable-shared
make
sudo make install

Rizzen

You received this message because you are subscribed to the Google Groups "ode-users" group.
To post to this group, send email to ode-users@....
To unsubscribe from this group, send email to ode-users+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/ode-users?hl=en.

Re: what happens to geoms on dBodyDestroy?

2009-12-07T07:21:10Z

Hi, Christian,

On 7 Dec 2009, at 15:26, christian wrote:

> Hi, what happens to the geoms attached to a Body, when the body is
> destroied? As far as i can see in my simulation, they stay in the
> space. Is there a function to remove these geoms from their space, or
> at least, to get the geoms attached to this body, or do i need to
> store them seperately?

From the ODE manual:

void dSpaceDestroy (dSpaceID);

This destroys a space. It functions exactly like dGeomDestroy except
that it takes a dSpaceID argument. When a space is destroyed, if its
cleanup mode is 1 (the default) then all the geoms in that space are
automatically destroyed as well.

void dSpaceSetCleanup (dSpaceID space, int mode);
int dSpaceGetCleanup (dSpaceID space);

Set and get the clean-up mode of the space. If the clean-up mode is 1,
then the contained geoms will be destroyed when the space is
destroyed. If the clean-up mode is 0 this does not happen. The default
clean-up mode for new spaces is 1.

Klaus

--

You received this message because you are subscribed to the Google Groups "ode-users" group.
To post to this group, send email to ode-users@....
To unsubscribe from this group, send email to ode-users+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/ode-users?hl=en.

what happens to geoms on dBodyDestroy?

2009-12-07T06:26:46Z

Hi, what happens to the geoms attached to a Body, when the body is
destroied? As far as i can see in my simulation, they stay in the
space. Is there a function to remove these geoms from their space, or
at least, to get the geoms attached to this body, or do i need to
store them seperately?

--

You received this message because you are subscribed to the Google Groups "ode-users" group.
To post to this group, send email to ode-users@....
To unsubscribe from this group, send email to ode-users+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/ode-users?hl=en.

Re: Re: Collision problem with trimesh

2009-12-06T14:07:49Z

Regis escreveu:
> Ans. to "second" : It is a bit hard to answer this question because I
> am using ODE in a homebrew PSP game => a bit hard to debug.

Does the crash happen when you build the same code to run on a PC?

Isn't it possible to attach a debugger, or at least get a core dump when
you run it on the PSP?

--
Daniel K. O.
"The only way to succeed is to build success yourself"

--

You received this message because you are subscribed to the Google Groups "ode-users" group.
To post to this group, send email to ode-users@....
To unsubscribe from this group, send email to ode-users+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/ode-users?hl=en.

Re: Collision problem with trimesh

2009-12-06T13:45:06Z

Hello, thanks for answer.

Ans. to "first" : Indeed, this is the last, I always get the freeze,
even with surface.mode defined.

Ans. to "second" : It is a bit hard to answer this question because I
am using ODE in a homebrew PSP game => a bit hard to debug. Anyway, it
seems the app crashes in the "dWorldStep (ODEWorld, 0.05);". No crash
with "dWorldQuickStep (ODEWorld, 0.05);" but wierd behavior ...

What I was wandering is if there is any obvious error in my code ?

--

You received this message because you are subscribed to the Google Groups "ode-users" group.
To post to this group, send email to ode-users@....
To unsubscribe from this group, send email to ode-users+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/ode-users?hl=en.

Re: Collision problem with trimesh

2009-12-05T13:11:14Z

First: per the manual, with regard to the surface parameter mode:" This must always be set ." Do you get the error if you set the surface.mode?

Second: At what line of your code does the error actually occur? "Symptom: Simulation crash after first contact" needs to be amplified a little bit.

Collision problem with trimesh

2009-12-05T07:10:45Z

Hello,

I am new in here and joined the group because I have been unable to resolve my problem. I have been googling and searching the group for similar problems, but, cannot figure where is my mistake. So I am kindly asking for your assistance.

My physics are very simple :
ODEWorld = dWorldCreate (); ODESpace = dHashSpaceCreate(0); ODEContacts = dJointGroupCreate (0);

+ gravity
+ one trimesh rectangle (composed of 2 triangles) supposed to be the static ground => NULL body associated
+ one box moving around, that should collide with the ground trimesh

Symptoms : simulation crash after first contact

Trimesh definition :
void CGroundSegment::InitMassGeometry () { /* Init ground segment */ dTriMeshDataID TriMeshGeom = dGeomTriMeshDataCreate(); m_Body = 0; /* Vertex 0 */ m_Vertices [0][0] = m_start.X; m_Vertices [0][1] = m_start.Y; m_Vertices [0][2] = -10; /* Vertex 1 */ m_Vertices [1][0] = m_start.X; m_Vertices [1][1] = m_start.Y; m_Vertices [1][2] = 10; /* Vertex 2 */ m_Vertices [2][0] = m_end.X; m_Vertices [2][1] = m_end.Y; m_Vertices [2][2] = 10; /* Vertex 3 */ m_Vertices [3][0] = m_end.X; m_Vertices [3][1] = m_end.Y; m_Vertices [3][2] = -10; /* Faces */ m_Indices [0] = 0; m_Indices [1] = 1; m_Indices [2] = 2; m_Indices [3] = 0; m_Indices [4] = 2; m_Indices [5] = 3; /* Define TriMesh ... */ dGeomTriMeshDataBuildSimple (TriMeshGeom, (const dReal*) m_Vertices, 4, m_Indices, 6); m_Geometry = dCreateTriMesh(ODESpace, TriMeshGeom, 0, 0, 0); dGeomSetBody(m_Geometry, m_Body); // 0 = static object dGeomSetPosition (m_Geometry, 0, 0, 0); dGeomTriMeshEnableTC(m_Geometry, dTriMeshClass, 0); } Box definition :
void CPlayerShip::InitMassGeometry () { if (m_Geometry != 0) dGeomDestroy (m_Geometry); if (m_Body != 0) dBodyDestroy (m_Body); m_Geometry = dCreateBox(ODESpace, 2, 2, 2); m_Body = dBodyCreate (ODEWorld); dMassSetBox(&m_Mass,1,1,1,1); dMassAdjust(&m_Mass,0.2f); dBodySetMass(m_Body,&m_Mass); dGeomSetBody(m_Geometry, m_Body); dBodySetPosition(m_Body,m_Position.X,m_Position.Y,0); }Collision detection :
void nearCallback (void *data, dGeomID o1, dGeomID o2) { // Create an array of dContact objects to hold the contact joints dContact Contacts[MAX_CONTACTS]; dBodyID b1 = dGeomGetBody(o1); dBodyID b2 = dGeomGetBody(o2); // No collision between ground segments if ((b1 == 0) && (b2 == 0)) return; if (dAreConnected (b1, b2)) return; int NbContact = dCollide (o1, o2, MAX_CONTACTS, &(Contacts[0].geom), sizeof(dContact)); for (int i = 0; i < NbContact; i++) { Contacts[i].surface.slip1 = 0.7; Contacts[i].surface.slip2 = 0.7; Contacts[i].surface.mode = 0; //dContactSoftERP | dContactSoftCFM | dContactApprox1 | dContactSlip1 | dContactSlip2 | dContactBounce; Contacts[i].surface.bounce = 0.4; Contacts[i].surface.bounce_vel = 0.1; Contacts[i].surface.mu = 2.0; Contacts[i].surface.soft_erp = 0.97; Contacts[i].surface.soft_cfm = 0.2; dJointID c = dJointCreateContact (ODEWorld,ODEContacts,&(Contacts[i])); dJointAttach (c, dGeomGetBody(Contacts[i].geom.g1), dGeomGetBody(Contacts[i].geom.g2)); //If this line is commented out, no crash, but of course also the box does not collide ;) } }
Does anyone have a suggestion, or encountered a similar problem ?

Regis

Re: dWorldStepFast

2009-12-05T01:23:31Z

Yes, I already asked that but I did not get complete answer. Now it's clear
for me. Thank you.

Oleh Derevenko
-- Skype with underscore

----- Original Message -----
From: "Daniel K. O." <danielko.listas@...>
To: <ode-users@...>
Sent: Saturday, December 05, 2009 2:39 AM
Subject: Re: [ode-users] dWorldStepFast

Oleh Derevenko escreveu:
> Just occassionally had a look at the files in Groogle Group and found
> there is an ODE manual (in PDF format) with quite a detailed
> description for dWorldStepFast. So, could anyone tell the history of
> it? How was it added? What for? By whom? Is not it needed by anyone
> indeed? Why?

Didn't you ask that already?
t was an attempt at creating an iterative solver.

Quoting from http://www.ode.org/old_list_archives/2004-May/012819.html :

"the FastStep method is a kind of wierd block-jacobi
method, i am not sure that it would always converge to the correct
answer."

At least since 2004 nobody should be using stepfast anymore.

Another message on the same thread says:

"Theoretically, [quickstep] should be better than StepFast... As Alen
recently pointed out, StepFast isn't "iterative" method at all, it just
subdivides timestep and does serial solving of joints."

--
Daniel K. O.
"The only way to succeed is to build success yourself"

--

You received this message because you are subscribed to the Google Groups
"ode-users" group.
To post to this group, send email to ode-users@....
To unsubscribe from this group, send email to
ode-users+unsubscribe@....
For more options, visit this group at
http://groups.google.com/group/ode-users?hl=en.

--

You received this message because you are subscribed to the Google Groups "ode-users" group.
To post to this group, send email to ode-users@....
To unsubscribe from this group, send email to ode-users+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/ode-users?hl=en.

Re: dWorldStepFast

2009-12-04T17:10:07Z

Forgot to include this link on the last message:

This message states that David Whittaker was the author:
http://www.ode.org/old_list_archives/2003-July/009319.html

--
Daniel K. O.
"The only way to succeed is to build success yourself"

--

You received this message because you are subscribed to the Google Groups "ode-users" group.
To post to this group, send email to ode-users@....
To unsubscribe from this group, send email to ode-users+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/ode-users?hl=en.

Re: dWorldStepFast

2009-12-04T16:39:27Z

Oleh Derevenko escreveu:
> Just occassionally had a look at the files in Groogle Group and found
> there is an ODE manual (in PDF format) with quite a detailed
> description for dWorldStepFast. So, could anyone tell the history of
> it? How was it added? What for? By whom? Is not it needed by anyone
> indeed? Why?

Didn't you ask that already?
t was an attempt at creating an iterative solver.

Quoting from http://www.ode.org/old_list_archives/2004-May/012819.html :

"the FastStep method is a kind of wierd block-jacobi
method, i am not sure that it would always converge to the correct
answer."

At least since 2004 nobody should be using stepfast anymore.

Another message on the same thread says:

"Theoretically, [quickstep] should be better than StepFast... As Alen
recently pointed out, StepFast isn't "iterative" method at all, it just
subdivides timestep and does serial solving of joints."

--
Daniel K. O.
"The only way to succeed is to build success yourself"

--

You received this message because you are subscribed to the Google Groups "ode-users" group.
To post to this group, send email to ode-users@....
To unsubscribe from this group, send email to ode-users+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/ode-users?hl=en.

Re: How many geoms can I add to a space?

2009-12-04T14:16:52Z

Well I figured out just now I had a larger array out of bounds issue that I have resolved and have fixed the problem. Sorry to bother you :)

--------------------------------------------------

Brett Hemes

UMN Center for Distributed Robotics

hemes@...

hemes001@...

On Dec 4, 2009, at 2:48 PM, Brett Hemes wrote:

I am having an issue building a stepfield comprised of 900 boxes of dBoxClass (constructed using dCreateBox() ) . After I add about 480 boxes I get an error from ODE as follows:
ODE INTERNAL ERROR 2: argument not a space in dSpaceAdd()

I have tried to trace back the problem as far as I could and I think inside of dCreateBox() the call to dAlloc() is returning NULL. I believe this would explain the error. If I am correct this raises the question of how may geoms can I put in a space in general? My space was created using a call to dHashSpaceCreate(0). I tried dSimpleSpaceCreate(0) and it fails on the same exact call to dCreateBox().

Thanks,
Brett

--------------------------------------------------
Brett Hemes
UMN Center for Distributed Robotics
hemes@...
hemes001@...

How many geoms can I add to a space?

2009-12-04T12:48:05Z

I am having an issue building a stepfield comprised of 900 boxes of dBoxClass (constructed using dCreateBox() ) . After I add about 480 boxes I get an error from ODE as follows:

ODE INTERNAL ERROR 2: argument not a space in dSpaceAdd()

I have tried to trace back the problem as far as I could and I think inside of dCreateBox() the call to dAlloc() is returning NULL. I believe this would explain the error. If I am correct this raises the question of how may geoms can I put in a space in general? My space was created using a call to dHashSpaceCreate(0). I tried dSimpleSpaceCreate(0) and it fails on the same exact call to dCreateBox().

Thanks,

Brett

--------------------------------------------------

Brett Hemes

UMN Center for Distributed Robotics

hemes@...

hemes001@...

dWorldStepFast

2009-12-04T12:04:58Z

Hi,

Just occassionally had a look at the files in Groogle Group and found there is an ODE manual (in PDF format) with quite a detailed description for dWorldStepFast. So, could anyone tell the history of it? How was it added? What for? By whom? Is not it needed by anyone indeed? Why?

Oleh Derevenko
-- Skype with underscore

smime.p7s (9K) Download Attachment

Re: Re: Update Doxygen Documentation

2009-12-04T11:32:04Z

The only reason to derive from the public C++ classes is if you wanted
to change the behavior of the class. But if that's what you do, then
you have to actually make all the implementation of ODE be virtual,
which we clearly (?) don't want.

If you need to change the C++ classes to the point where you need to
add more member data, then the right thing to do is to write your own
wrappers around the C API. Pretending that the public C++ classes are
derivable just creates more bad than good, IMO.

If you want to derive from the private implementation classes, well,
you're braver than what's healthy :-)

Sincerely,

jw

--
Americans might object: there is no way we would sacrifice our living
standards for the benefit of people in the rest of the world.
Nevertheless, whether we get there willingly or not, we shall soon
have lower consumption rates, because our present rates are
unsustainable.

On Fri, Dec 4, 2009 at 9:08 AM, Danny Price <deepblue842@...> wrote:

> Oh we could go with your suggestion and have an have an empty but
> polymorphic interface of dWorld etc called dWorldDerivable or something in
> the header. If we can't change the destructors for reasons sighted, it seems
> silly creating yet more classes just to wrap these ones for that deficiency.
>
> On Fri, Dec 4, 2009 at 3:31 PM, Oleh Derevenko <Oleh.Derevenko@...>
> wrote:
>>
>> Instead of having this endless discussion with me you could spend the time
>> for making dynamic wrappers over the static base classes in odecpp.h, I
>> would commit that all and everybody would be happy.
>> Oleh Derevenko
>> -- Skype with underscore
>>
>>
>>
>> ----- Original Message -----
>> From: Danny Price
>> To: ode-users@...
>> Sent: Friday, December 04, 2009 5:17 PM
>> Subject: Re: [ode-users] Re: Update Doxygen Documentation
>>
>>
>> On Fri, Dec 4, 2009 at 3:09 PM, Oleh Derevenko <Oleh.Derevenko@...>
>> wrote:
>>>
>>>
>>>
>>>
>>> ----- Original Message -----
>>>
>>>>
>>>> Do you read what I'm trying to tell to you at all??? I told you
>>>> clearly: "USE YOUR DERIVED CLASS EVERYWHERE IN YOUR CODE INSTEAD OF dWorld".
>>>> That means that you SHOULD NOT HAVE any pointers to dWorld at all. In the
>>>> simplest implementation you can just write
>>>>
>>>> #define dWorld MyVirtualWorld
>>>>
>>>> after odecpp.h has been included.
>>>
>>> Right I see what you're getting it. That would work provided, as you say,
>>> there are no references or pointers of type dWorld. But why the
>>> complication? Why not make dWorld polymorphic just as you did with dJoint?
>>>
>>> Because someone else might want to use dWorld without having virtual
>>> methods in it.
>>
>> What is the penalty if dWorld is used as if, but has a virtual destructor?
>> Surely the vtable is empty?
>>
>>
>>>
>>> Someone else might want to use dJoint without having virtual destructor
>>> in it.
>>> Virtual functions can't be inlined, for example.
>>
>> True. But function inlining is compiler and platform specific anyway.
>> There is no guarantee that any function is inlined. This sounds like
>> premature optimization at the cost of basic flexibility.
>>
>>> And if destructor is the only virtual method it also increases size of
>>> object for the sizeof(pointer) for no reason at all.
>>
>> Surely this is insignificant?
>>
>>>
>>> You need the class to be dynamic - make it dymanic for yourself. But do
>>> not force everyone use it the way you like it.
>>
>> Polymorphic behavior is not a personal preference - it's a cornerstone of
>> C++. Like or not, it's the natual way to extend classes and first thing a
>> developer will try when using these classes. I would assume it to be the
>> default.
>>
>>>
>>>
>>>>>
>>>>>
>>>>> The world represented by the dWorld instance may never be removed from
>>>>> the scene.
>>>>>
>>>>> I was just looking at the Doxygen reference and strangely, some of the
>>>>> classes (eg dJoint) do have virtual functions but none have virtual
>>>>> destructors meaning it would be dangerous to derive from them for the same
>>>>> reason.
>>>>>
>>>>> Here are lines 431-433 of odecpp.h with "virtual" word highlighted to
>>>>> be easier to spot.
>>>>> public:
>>>>> virtual ~dJoint() // :( Destructor must be virtual to suppress
>>>>> compiler warning "class XXX has virtual functions but non-virtual
>>>>> destructor"
>>>>> { if (_id) dJointDestroy (_id); }
>>>>> Hope this helps.
>>>>>
>>>>
>>>> Then it must have been changed (for the better!) - it's not in
>>>> http://opende.sourceforge.net/docs/odecpp_8h-source.html
>>>>
>>>> Sure, I fixed that on March 2nd, 2008. Now - God thank you - it's
>>>> already the December 2009.
>>>>
>>>
>>> Thanks. This is what I've been advocating. But you only fixed this one to
>>> surpress a compiler warning. I don't see the benefit of crippling these
>>> classes in this way. As you also pointer out, they are not used by ODE
>>> internally anyway.
>>>
>>> --
>>>
>>> You received this message because you are subscribed to the Google Groups
>>> "ode-users" group.
>>> To post to this group, send email to ode-users@....
>>> To unsubscribe from this group, send email to
>>> ode-users+unsubscribe@....
>>> For more options, visit this group at
>>> http://groups.google.com/group/ode-users?hl=en.
>>>
>>> --
>>>
>>> You received this message because you are subscribed to the Google Groups
>>> "ode-users" group.
>>> To post to this group, send email to ode-users@....
>>> To unsubscribe from this group, send email to
>>> ode-users+unsubscribe@....
>>> For more options, visit this group at
>>> http://groups.google.com/group/ode-users?hl=en.
>>
>> --
>>
>> You received this message because you are subscribed to the Google Groups
>> "ode-users" group.
>> To post to this group, send email to ode-users@....
>> To unsubscribe from this group, send email to
>> ode-users+unsubscribe@....
>> For more options, visit this group at
>> http://groups.google.com/group/ode-users?hl=en.
>>
>> --
>>
>> You received this message because you are subscribed to the Google Groups
>> "ode-users" group.
>> To post to this group, send email to ode-users@....
>> To unsubscribe from this group, send email to
>> ode-users+unsubscribe@....
>> For more options, visit this group at
>> http://groups.google.com/group/ode-users?hl=en.
>
> --
>
> You received this message because you are subscribed to the Google Groups
> "ode-users" group.
> To post to this group, send email to ode-users@....
> To unsubscribe from this group, send email to
> ode-users+unsubscribe@....
> For more options, visit this group at
> http://groups.google.com/group/ode-users?hl=en.
>

Re: Re: Update Doxygen Documentation

2009-12-04T09:34:16Z

No, use commit 1712.

Oleh Derevenko
-- Skype with underscore

----- Original Message -----

From: Oleh.Derevenko@...

To: ode-users@...

Sent: Friday, December 04, 2009 7:16 PM

Subject: Re: [ode-users] Re: Update Doxygen Documentation

Allright, no need to answer.

Changed it to be inheritable, customizable, and anything else able.

Revision 1711.

Enjoy (if you can ;) )!

Oleh Derevenko
-- Skype with underscore

----- Original Message -----

From: Oleh.Derevenko@...

To: ode-users@...

Sent: Friday, December 04, 2009 5:46 PM

Subject: Re: [ode-users] Re: Update Doxygen Documentation

Sorry, this is a stupid suggestion. dJoint has to have virtual destructor if you want to derive from its descendants. The only problem is that YOU CAN'T extend the hierarchy of classes without changing its base class as you would have to extend all the leaf classes in the tree (for example, by using multiple inheritance in a quite a tricly way).

So, my question is: imagine I made all the classes having virtual destructor - how would you plan to extend joint classes without using aggregation then?

Oleh Derevenko
-- Skype with underscore

----- Original Message -----

From: Oleh.Derevenko@...

To: ode-users@...

Sent: Friday, December 04, 2009 5:31 PM

Subject: Re: [ode-users] Re: Update Doxygen Documentation

Instead of having this endless discussion with me you could spend the time for making dynamic wrappers over the static base classes in odecpp.h, I would commit that all and everybody would be happy.

Oleh Derevenko
-- Skype with underscore

smime.p7s (9K) Download Attachment

Re: Re: Update Doxygen Documentation

2009-12-04T09:16:17Z

Allright, no need to answer.

Changed it to be inheritable, customizable, and anything else able.

Revision 1711.

Enjoy (if you can ;) )!

Oleh Derevenko
-- Skype with underscore

----- Original Message -----

From: Oleh.Derevenko@...

To: ode-users@...

Sent: Friday, December 04, 2009 5:46 PM

Subject: Re: [ode-users] Re: Update Doxygen Documentation

Sorry, this is a stupid suggestion. dJoint has to have virtual destructor if you want to derive from its descendants. The only problem is that YOU CAN'T extend the hierarchy of classes without changing its base class as you would have to extend all the leaf classes in the tree (for example, by using multiple inheritance in a quite a tricly way).

So, my question is: imagine I made all the classes having virtual destructor - how would you plan to extend joint classes without using aggregation then?

Oleh Derevenko
-- Skype with underscore

----- Original Message -----

From: Oleh.Derevenko@...

To: ode-users@...

Sent: Friday, December 04, 2009 5:31 PM

Subject: Re: [ode-users] Re: Update Doxygen Documentation

Instead of having this endless discussion with me you could spend the time for making dynamic wrappers over the static base classes in odecpp.h, I would commit that all and everybody would be happy.

Oleh Derevenko
-- Skype with underscore

smime.p7s (9K) Download Attachment

Re: Re: Update Doxygen Documentation

2009-12-04T09:08:02Z

Oh we could go with your suggestion and have an have an empty but polymorphic interface of dWorld etc called dWorldDerivable or something in the header. If we can't change the destructors for reasons sighted, it seems silly creating yet more classes just to wrap these ones for that deficiency.

On Fri, Dec 4, 2009 at 3:31 PM, Oleh Derevenko <Oleh.Derevenko@...> wrote:

Instead of having this endless discussion with me you could spend the time for making dynamic wrappers over the static base classes in odecpp.h, I would commit that all and everybody would be happy.

Oleh Derevenko
-- Skype with underscore

----- Original Message -----

From: deepblue842@...

To: ode-users@...

Sent: Friday, December 04, 2009 5:17 PM

Subject: Re: [ode-users] Re: Update Doxygen Documentation

On Fri, Dec 4, 2009 at 3:09 PM, Oleh Derevenko <Oleh.Derevenko@...> wrote:

----- Original Message -----

Do you read what I'm trying to tell to you at all??? I told you clearly: "USE YOUR DERIVED CLASS EVERYWHERE IN YOUR CODE INSTEAD OF dWorld". That means that you SHOULD NOT HAVE any pointers to dWorld at all. In the simplest implementation you can just write

#define dWorld MyVirtualWorld

after odecpp.h has been included.

Right I see what you're getting it. That would work provided, as you say, there are no references or pointers of type dWorld. But why the complication? Why not make dWorld polymorphic just as you did with dJoint?

Because someone else might want to use dWorld without having virtual methods in it.

What is the penalty if dWorld is used as if, but has a virtual destructor? Surely the vtable is empty?

Someone else might want to use dJoint without having virtual destructor in it.

Virtual functions can't be inlined, for example.

True. But function inlining is compiler and platform specific anyway. There is no guarantee that any function is inlined. This sounds like premature optimization at the cost of basic flexibility.

And if destructor is the only virtual method it also increases size of object for the sizeof(pointer) for no reason at all.

Surely this is insignificant?

You need the class to be dynamic - make it dymanic for yourself. But do not force everyone use it the way you like it.

Polymorphic behavior is not a personal preference - it's a cornerstone of C++. Like or not, it's the natual way to extend classes and first thing a developer will try when using these classes. I would assume it to be the default.

The world represented by the dWorld instance may never be removed from the scene.

I was just looking at the Doxygen reference and strangely, some of the classes (eg dJoint) do have virtual functions but none have virtual destructors meaning it would be dangerous to derive from them for the same reason.

Here are lines 431-433 of odecpp.h with "virtual" word highlighted to be easier to spot.

public:
virtual ~dJoint() // :( Destructor must be virtual to suppress compiler warning "class XXX has virtual functions but non-virtual destructor"
{ if (_id) dJointDestroy (_id); }

Hope this helps.

Then it must have been changed (for the better!) - it's not in http://opende.sourceforge.net/docs/odecpp_8h-source.html

Sure, I fixed that on March 2nd, 2008. Now - God thank you - it's already the December 2009.

Thanks. This is what I've been advocating. But you only fixed this one to surpress a compiler warning. I don't see the benefit of crippling these classes in this way. As you also pointer out, they are not used by ODE internally anyway.

--
You received this message because you are subscribed to the Google Groups "ode-users" group.
To post to this group, send email to ode-users@....
To unsubscribe from this group, send email to ode-users%2Bunsubscribe@....
For more options, visit this group at http://groups.google.com/group/ode-users?hl=en.

--
You received this message because you are subscribed to the Google Groups "ode-users" group.
To post to this group, send email to ode-users@....
To unsubscribe from this group, send email to ode-users%2Bunsubscribe@....
For more options, visit this group at http://groups.google.com/group/ode-users?hl=en.

--
You received this message because you are subscribed to the Google Groups "ode-users" group.
To post to this group, send email to ode-users@....
To unsubscribe from this group, send email to ode-users%2Bunsubscribe@....
For more options, visit this group at http://groups.google.com/group/ode-users?hl=en.

--
You received this message because you are subscribed to the Google Groups "ode-users" group.
To post to this group, send email to ode-users@....
To unsubscribe from this group, send email to ode-users%2Bunsubscribe@....
For more options, visit this group at http://groups.google.com/group/ode-users?hl=en.