Re: [cgkit-user] moving a static object?

[Matthias Baas <baas@ir...>]

Ricardo Kirkner wrote:
> errors, I am not quite sure how to avoid this kind of behavior. It
> basically has to do with the computers speed. On my machine (which is
> the slower of all I have tested), the simulation works more or less as
> I expect (probably because I am developing on my machine, and
> therefore tune the simulation to fit it). On other machines (which are
> faster), the simulation behaves rather oddly, by my robot making
> jumps, or spinning at great speed (which I have never seen done on my
> machine). I believe this has to do with the simulation state getting
> updated quickier and therefore more often, and thus building momentum
> (which on my computer is not happening because due to the lower speed,
> the forces applied get enough time to settle down).

Have you modified something in cgkit that manipulates the time step that 
is passed to ODE? If not, then different CPU speeds shouldn't matter. 
The time step that is passed to ODE isn't based on the real time that 
has passed, it is only based on the framerate you have requested. So a 
faster CPU should just provide the simulation results faster than the 
slower CPU but the results shouldn't differ.

What CPUs do your computers have? Maybe one is an Intel and the other an 
AMD which might already be the cause for your problem. Is there some 
DirectX code involved on one machine? (Direct3D changes the FPU state)

Maybe you can set up a simple scene (probably just a box falling on a 
plane) that prints the position/orientation values for a couple of 
frames so that you can compare when they start to diverge...?

- Matthias -

[cgkit-user] moving a static object?

[Ricardo Kirkner <ricardokirkner@gm...>]

Hi:

I have a sphere representing a light in my simulation. I want this
light to be able to float in space (as if it was hanging from the
ceiling). Since using dynamics=False in the constructor inhibts
collisions with this sphere object, I instead defined it as
static=True.

This makes the sphere to stay put in its location, and still be able
to collide with my other objects.
The strange part is, when I change the sphere's pos slot, the visible
sphere gets relocated, but my objects still collide with "something"
at the location where the sphere used to be, and don't collide anymore
with the relocated sphere (where it appears to be).

The only explanation I can find is that when changing the pos value of
a static object, the object itself doesnt change, but the geom does.

However, I cannot quite understand why this is

How can I make my sphere be static, collidable and relocatable (but
only through the user's intention, I dont want collisions to move the
sphere).

I hope I have explained my problem,

With regards,

Ricardo Kirkner

Re: [cgkit-user] moving a static object?

[Matthias Baas <baas@ir...>]

Ricardo Kirkner wrote:
> The strange part is, when I change the sphere's pos slot, the visible
> sphere gets relocated, but my objects still collide with "something"
> at the location where the sphere used to be, and don't collide anymore
> with the relocated sphere (where it appears to be).
> 
> The only explanation I can find is that when changing the pos value of
> a static object, the object itself doesnt change, but the geom does.
> 
> However, I cannot quite understand why this is

Well, when you create a sphere in cgkit and add it to an ODEDynamics 
component there are actually several objects involved. After the 
creation of the sphere you have two objects:

- An object derived from WorldObject which stores the transformation and 
some flags

- The sphere geometry which defines the shape of the object. The 
geometry does not have a transformation associated with it, it is always 
defined in local coordinates and only gets positioned via the WorldObject.

When you add the sphere to the ODEDynamics object there are some more 
objects created:

- An ODEBody which serves as an interface between ODE and cgkit.
- A native ODE Body object for doing the simulation (static objects 
won't have such a body)
- One or more ODE geom objects that represent the collision geometry

The position/orientation of the ODE body is taken from the cgkit 
WorldObject at initialization time and can later be changed via an 
ODEBodyManipulator. During simulation the position/orientation of the 
WorldObject is updated from the ODE body.
Now when you change the position/orientation of a dynamics WorldObject 
yourself, this actually has no effect because the transformation is 
controlled by ODE. For non-static objects the transformation will be 
overwritten after the next simulation step and for static objects it 
only affects the cgkit WorldObject but this change is not reflected in 
the ODE geoms. This means, the visual representation of the object has 
moved but the collision geometry is still at its old location.
Unfortunately, you also cannot use a ODEBodyManipulator because a static 
object does not have a body. But I agree that it would be useful to be 
able to move static objects as well. At the moment, the only way to do 
that is to get hold of the ODE geoms and update the position/orientation 
manually.
Of course, it would be more convenient if this would be done 
automatically whenever the transformation is updated by the user. But 
this isn't implemented yet.
Currently, I don't have the time to do that right now, so you might want 
to add this to the SourceForge Feature Request tracker so that it won't 
slip my mind...

- Matthias -

Re: [cgkit-user] moving a static object?

[Ricardo Kirkner <ricardokirkner@gm...>]

Thank you, Matthias for the explanation... for now I will do without
the static object collisioning, maybe I'll need that later again, and
then I will look into how to patch cgkit for it.

Now I have a question that maybe is related to another question I had
made previously (regarding determinism)

I have removed all non-determinism sources I have found so far (mainly
by using worldstep instead of quickstep). As my simulation cares more
about accuracy over speed, that would make sense too.

I am having an issue that would seem like non-determinism, although I
dont really know if it is. When running my simulation in different
machines, I get different behaviours. Although I can cope with small
differences, or with differences in the simulation due to small
errors, I am not quite sure how to avoid this kind of behavior. It
basically has to do with the computers speed. On my machine (which is
the slower of all I have tested), the simulation works more or less as
I expect (probably because I am developing on my machine, and
therefore tune the simulation to fit it). On other machines (which are
faster), the simulation behaves rather oddly, by my robot making
jumps, or spinning at great speed (which I have never seen done on my
machine). I believe this has to do with the simulation state getting
updated quickier and therefore more often, and thus building momentum
(which on my computer is not happening because due to the lower speed,
the forces applied get enough time to settle down).

I am sort of clueless as how to determine the real problem here and
how to solve it, by I guess that I could use some way of slowing the
whole simulation down to counteract the better machines speed.

Can you understand anything of what I tried to explain? If you could,
then congrats (as I am not entirely sure I understand it myself :-)).

I hope you can help me figure this out,

Thank you,

Ricardo Kirkner

Re: [cgkit-user] moving a static object?

[Matthias Baas <baas@ir...>]

Ricardo Kirkner wrote:
> errors, I am not quite sure how to avoid this kind of behavior. It
> basically has to do with the computers speed. On my machine (which is
> the slower of all I have tested), the simulation works more or less as
> I expect (probably because I am developing on my machine, and
> therefore tune the simulation to fit it). On other machines (which are
> faster), the simulation behaves rather oddly, by my robot making
> jumps, or spinning at great speed (which I have never seen done on my
> machine). I believe this has to do with the simulation state getting
> updated quickier and therefore more often, and thus building momentum
> (which on my computer is not happening because due to the lower speed,
> the forces applied get enough time to settle down).

Have you modified something in cgkit that manipulates the time step that 
is passed to ODE? If not, then different CPU speeds shouldn't matter. 
The time step that is passed to ODE isn't based on the real time that 
has passed, it is only based on the framerate you have requested. So a 
faster CPU should just provide the simulation results faster than the 
slower CPU but the results shouldn't differ.

What CPUs do your computers have? Maybe one is an Intel and the other an 
AMD which might already be the cause for your problem. Is there some 
DirectX code involved on one machine? (Direct3D changes the FPU state)

Maybe you can set up a simple scene (probably just a box falling on a 
plane) that prints the position/orientation values for a couple of 
frames so that you can compare when they start to diverge...?

- Matthias -

Re: [cgkit-user] moving a static object?

[Ricardo Kirkner <ricardokirkner@gm...>]

Thank you for your answer, Matthias. Actually yes, my computer is an
AMD Athlon Thunderbird 800Mhz, and the other computers I tried where
Intel (or at least I think so).

One of the other machines had windows, and although I have done
nothing explicitely with DirectX (I actually haven't written a line of
code regarding rendering, I leave all that to the viewer tool :-)),
maybe in the windows machine, it falls back to DirectX when it cannot
work with OpenGL?

What is the matter between Intel and AMD with ode/cgkit?

Again, thanks for the help

ricardo

On 7/7/06, Matthias Baas <baas@...> wrote:
> Ricardo Kirkner wrote:
> > errors, I am not quite sure how to avoid this kind of behavior. It
> > basically has to do with the computers speed. On my machine (which is
> > the slower of all I have tested), the simulation works more or less as
> > I expect (probably because I am developing on my machine, and
> > therefore tune the simulation to fit it). On other machines (which are
> > faster), the simulation behaves rather oddly, by my robot making
> > jumps, or spinning at great speed (which I have never seen done on my
> > machine). I believe this has to do with the simulation state getting
> > updated quickier and therefore more often, and thus building momentum
> > (which on my computer is not happening because due to the lower speed,
> > the forces applied get enough time to settle down).
>
> Have you modified something in cgkit that manipulates the time step that
> is passed to ODE? If not, then different CPU speeds shouldn't matter.
> The time step that is passed to ODE isn't based on the real time that
> has passed, it is only based on the framerate you have requested. So a
> faster CPU should just provide the simulation results faster than the
> slower CPU but the results shouldn't differ.
>
> What CPUs do your computers have? Maybe one is an Intel and the other an
> AMD which might already be the cause for your problem. Is there some
> DirectX code involved on one machine? (Direct3D changes the FPU state)
>
> Maybe you can set up a simple scene (probably just a box falling on a
> plane) that prints the position/orientation values for a couple of
> frames so that you can compare when they start to diverge...?
>
> - Matthias -
>
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> cgkit-user mailing list
> cgkit-user@...
> https://lists.sourceforge.net/lists/listinfo/cgkit-user
>

Re: [cgkit-user] moving a static object?

[Matthias Baas <baas@ir...>]

Ricardo Kirkner wrote:
> Thank you for your answer, Matthias. Actually yes, my computer is an
> AMD Athlon Thunderbird 800Mhz, and the other computers I tried where
> Intel (or at least I think so).
> 
> One of the other machines had windows, and although I have done
> nothing explicitely with DirectX (I actually haven't written a line of
> code regarding rendering, I leave all that to the viewer tool :-)),
> maybe in the windows machine, it falls back to DirectX when it cannot
> work with OpenGL?

No, if you're only using the standard viewer tool then you always get 
OpenGL output. When you would use the Ogre-Viewer (which you have to 
compile yourself) you could choose between OpenGL and Direct3D and then 
we already noticed that simulations run differently because Direct3D 
changes the FPU accuracy.

> What is the matter between Intel and AMD with ode/cgkit?

I cannot say for sure what exactly causes the diffences you were 
experiencing. As far as I know Intel chips use more bits internally for 
doing the computations and these bits are kept as long as the values 
remain inside internal registers. This makes computational results 
rather unpredictable as they depend on the code generated by the 
compiler, i.e. whether intermediate results are stored in registers or 
written back to memory.
I don't know if AMD chips do the same thing or not, but your results 
might indicate that they don't. I also don't know if there are other 
differences between the chips that influence floating point computations.

You could try compiling ODE and PyODE yourself and play around with 
compiler options (I believe there's a flag that forces intermediate 
results to be flushed into memory so that those extra bits are always 
truncated).

By the way, cgkit has an undocumented feature to modify the FPU control 
state under Windows. In cgkit._core there are two functions 
getFPUControlState() and setFPUPrecision() that are wrappers around the 
_controlfp() function. You can call setFPUPrecision() to switch between 
3 different precisions (24 bit, 53 bit and 64 bit):

 >>> setFPUPrecision(0)
 >>> 0.1*0.1
0.0099999997764825821
 >>> setFPUPrecision(1)
 >>> 0.1*0.1
0.010000000000000002
 >>> setFPUPrecision(2)
 >>> 0.1*0.1
0.010000000000000002


- Matthias -