Sent: Friday, November 08, 2002 06:02
Subject: [ODE] new ODE collision
>
> if you're curious, the source files for the new collision infrastructure
> have been checked into CVS (collision_*.h, collision_*.cpp). it has not
> been hooked up to the rest of ODE yet, so the only reason i mention it
> is for the curious. note that there's still a bunch of stuff to do, in
> particular to hook up the ray, trimesh and cylinder classes, and to
> convert the hash table space to use an incremental approach ... but you
> can get an idea of the new layout.
>
> the new collision infrastructure is 99% API compatible with the old, but
> i'll provide an ODE 'legacy' collision option so that existing code is
> guaranteed not to break - but all new collision development will go on
> the new infrastructure.
>
> russ.
>
> --
> Russell Smith
> http://www.q12.org
> _______________________________________________
> ODE mailing list
> ODE@q12.org
> http://q12.org/mailman/listinfo/ode
>
>
From Daniel.Groll at t-online.de Sat Nov 9 07:19:02 2002
From: Daniel.Groll at t-online.de (Daniel.Groll@t-online.de)
Date: Sat Nov 9 07:19:02 2002
Subject: [ODE] rate for fixed timesteps
Message-ID: <1036851471.3dcd190fc0ebf@webmail.t-online.de>
I use fixed timesteps to run my car simulation game. With a rate of 60
Hz the simulation runs smooth and seemed to be stable but now with
further testing I encountered some stability problems when cars or
objects move fast. Sometimes they seem to break through geometry or
"caught" in geometry. Is this the cause of a relatively low rate of
world timesteps? Or are there other reasons for instability? At which
rates run phyiscs simulations in common?
From ps_yumemi at yahoo.com Sat Nov 9 10:35:02 2002
From: ps_yumemi at yahoo.com (pia dalusong)
Date: Sat Nov 9 10:35:02 2002
Subject: [ODE] no rotation
Message-ID: <20021109173403.55406.qmail@web40513.mail.yahoo.com>
hello,
i called a dBodySetRotation and the program doesn't go
through it. all the other functions work but that
particular pair.
i called dRFromEulerAngles before i called
dbodysetrotation before i joined the wheels to my
chassis but the chassis doesn't rotate at all. i even
put different values to check
dRFromEulerAngles (bodyID,0,0,270) and it still
doesn't turn? what could possibly wrong with it?
btw this is the second mobot in the system can that
affect it?
thanks
__________________________________________________
Do you Yahoo!?
U2 on LAUNCH - Exclusive greatest hits videos
http://launch.yahoo.com/u2
From ps_yumemi at yahoo.com Sun Nov 10 10:03:01 2002
From: ps_yumemi at yahoo.com (pia dalusong)
Date: Sun Nov 10 10:03:01 2002
Subject: [ODE] matrix
Message-ID: <20021110170253.68888.qmail@web40508.mail.yahoo.com>
is the rotation matrix unique for ANY combination of
theta, phi and psi? or do they have their drawbacks?
are the linear and angular velocities related to euler angles?
__________________________________________________
Do you Yahoo!?
U2 on LAUNCH - Exclusive greatest hits videos
http://launch.yahoo.com/u2
From thomasharte at lycos.co.uk Sun Nov 10 15:51:02 2002
From: thomasharte at lycos.co.uk (Thomas Harte)
Date: Sun Nov 10 15:51:02 2002
Subject: [ODE] matrix
Message-ID: <1036968557010081@lycos-europe.com>
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
--=_NextPart_Lycos_0100811036968557_ID
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
>is the rotation matrix unique for ANY combination of
>theta, phi and psi? or do they have their drawbacks?
The rotation matrix is unique for any particular orientation. However, the three angle
orientation system has singularities, which more or less just means that not all unique
combinations of theta, phi and psi produce unique orientations. Therefore the rotation
matrix for a unique theta/phi/psi is not necessarily unique.
However, the rotation matrix method of storing orientations has drawbacks in this
sense. It is the three angle description that is limited. In fact, ODE is unlikely to be using
the rotation matrix form internally at all, but intead using quaternions internally then
converting to orientation matrices when requested because that form is more useful for
object display. Were it solely using rotation matrices however, the drawbacks would
include relatively costly rotations (due mostly to having to deal with precision issues) and
larger than necessary data size.
>are the linear and angular velocities related to euler angles?
No. Linear velocity is exactly the same as if an object could not rotation. So, e.g. a
velocity vector of (a, b, c) will always mean a units along the global 'x axis', b along the
global 'y' and c along the global 'z', regardless of object orientation.
Angular velocity has a different meaning again. It is a 3 component vector, which may
therefore be thought of as describing a direction and a magnitude. The rotation it
describes is a rotation around the axis described by its rotation of n radians, where n is
equal to the vector's magnitude. This is a very useful form for calculating how applied
impulses and forces affect rotation.
-Thomas______________________________________________________
The making of Brazillian football
--=_NextPart_Lycos_0100811036968557_ID--
From russ at q12.org Sun Nov 10 18:54:01 2002
From: russ at q12.org (Russ Smith)
Date: Sun Nov 10 18:54:01 2002
Subject: [ODE] ODE's new collision system
Message-ID: <20021110175837.73e010cb.russ@q12.org>
ODE's new collision system has been hooked up to the rest of ODE. here's
the docs for the new API, as well as a porting guide.
http://q12.org/ode/ode-docs.html
note that the user can activate either the old or new collision API when
ODE is compiled, by setting the ODE_OLD_COLLISION variable in
config/user-settings. BUT NOTE, even if the old ODE collision code is
used, spaces must still be created with the new API, using a parent
argument or 0.
work is continuing on adding features to the new collision code.
russ.
--
Russell Smith
http://www.q12.org
From russ at q12.org Sun Nov 10 19:09:02 2002
From: russ at q12.org (Russ Smith)
Date: Sun Nov 10 19:09:02 2002
Subject: [ODE] new ODE collision
In-Reply-To: <000401c287ec$8c862b70$73fefea9@athlon>
References: <20021108000235.5bc25ca1.russ@q12.org>
<000401c287ec$8c862b70$73fefea9@athlon>
Message-ID: <20021110181315.7c8dcc2e.russ@q12.org>
> - Remember to add dGeomMoved() calls inside of all Set functions of a
> geom. Also SetRadius, etc.
yup, i'm on it.
> - I think the destructor of a geom needs to tell the body it might be
> attached to that it wants to remove itself. Otherwise the body will
> use this geom in its linked list after it has been destroyed, which
> crashes.
quite right - i'll do this too.
> - When adding the ray class we should think about what the
> 'penetration depth' should be. Do you have any thoughts on this?
i'm not sure that dRay will ever be attached to a body, in which case
penetration depth does not have much use for the dynamics. perhaps you
can think of a non-dynamics use/definition for the penetration depth?
> - Why do you memcopy inside the dxSpace::computeAABB() function?
no good reason. it may actually be marginally faster because the
g->recomputeAABB() call will cause a reload of the class aabb pointer,
but not the stack aabb buffer. it's an optimization, but i doubt anyone
would notice the extra cycles.
> - Should we add support for a user defined, or infinite AABB on demand
> for spaces? This is really useful for the quadtree space containing
> huge (10.000 for example) amounts of geoms. If i would remove a single
> geom it would need to do a lot of work.
i don't understand this .. ?
russ.
--
Russell Smith
http://www.q12.org
From russ at q12.org Sun Nov 10 20:44:02 2002
From: russ at q12.org (Russ Smith)
Date: Sun Nov 10 20:44:02 2002
Subject: [ODE] new ODE collision
In-Reply-To: <000401c287ec$8c862b70$73fefea9@athlon>
References: <20021108000235.5bc25ca1.russ@q12.org>
<000401c287ec$8c862b70$73fefea9@athlon>
Message-ID: <20021110194819.0b0957de.russ@q12.org>
> - Remember to add dGeomMoved() calls inside of all Set functions of a
> geom. Also SetRadius, etc.
done.
> - I think the destructor of a geom needs to tell the body it might be
> attached to that it wants to remove itself. Otherwise the body will
> use this geom in its linked list after it has been destroyed, which
> crashes.
done. also the previous dGeomSetBody(0) code was completely broken, this
is fixed too (hopefully).
russ.
--
Russell Smith
http://www.q12.org
From mein at cs.umn.edu Sun Nov 10 20:54:01 2002
From: mein at cs.umn.edu (Kent Mein)
Date: Sun Nov 10 20:54:01 2002
Subject: [ODE] another small patch to the ode source
Message-ID: <20021105201649.A4038@cs.umn.edu>
At the end of the build:
My machine is trying to link the following with gcc, it should be g++.
(I'm on a Sparc running SunOS5.8 useing gcc-3.2)
Example:
gcc -o ode/test/test_chain2.exe ode/test/test_chain2.o lib/libode.a lib/libdrawstuff.a -L/usr/X11R6/lib -L/usr/X11/lib -L/usr/lib/X11R6 -L/usr/lib/X11 -lX11 -lGL -lGLU -lm
Kent
--
mein@cs.umn.edu
http://www.cs.umn.edu/~mein
From si at sjbrown.co.uk Sun Nov 10 21:02:35 2002
From: si at sjbrown.co.uk (Si Brown)
Date: Sun Nov 10 21:02:35 2002
Subject: [ODE] bending wheels again?
Message-ID: <200211061355.gA6DtVu11493@hook.org>
Hi,
>I've read something about problems using directx with ODE too, can someone
>tell me more?
The only problem I had was with getting DirectX to preserve the FPU exception behaviour, which can be achieved by creating the device with the D3DCREATE_FPU_PRESERVE flag set. Failing to do so broke some of the ODE internals (in the version I was using).
Ta,
Si
From maddocks at metservice.com Sun Nov 10 21:15:02 2002
From: maddocks at metservice.com (Henry Maddocks)
Date: Sun Nov 10 21:15:02 2002
Subject: [ODE] new ODE collision
In-Reply-To: <20021110194819.0b0957de.russ@q12.org>
Message-ID: <1B6F5262-F52C-11D6-8ACD-00039394FB86@metservice.com>
Does all this mean that tricollider is now part of the core
distribution?
Henry
On Monday, November 11, 2002, at 01:48 PM, Russ Smith wrote:
>
> russ.
>
From russ at q12.org Sun Nov 10 21:38:01 2002
From: russ at q12.org (Russ Smith)
Date: Sun Nov 10 21:38:01 2002
Subject: [ODE] credit
Message-ID: <20021110204247.41e37209.russ@q12.org>
in the spirit of giving credit where it is due, i've created a list of
ODE contributors and their contributions:
http://q12.org/cgi-bin/wiki.pl?ContributorsToODE
if i forgot your name or what you did, can you edit this page
accordingly? (it's a wiki, so everyone can edit it). i'll move this list
to the ODE main page when it's accurate.
russ.
--
Russell Smith
http://www.q12.org
From russ at q12.org Sun Nov 10 21:47:01 2002
From: russ at q12.org (Russ Smith)
Date: Sun Nov 10 21:47:01 2002
Subject: [ODE] new ODE collision
In-Reply-To: <1B6F5262-F52C-11D6-8ACD-00039394FB86@metservice.com>
References: <20021110194819.0b0957de.russ@q12.org>
<1B6F5262-F52C-11D6-8ACD-00039394FB86@metservice.com>
Message-ID: <20021110204313.0f068550.russ@q12.org>
> Does all this mean that tricollider is now part of the core
> distribution?
not quite yet, but it will be.
russ.
--
Russell Smith
http://www.q12.org
From maddocks at metservice.com Sun Nov 10 21:56:02 2002
From: maddocks at metservice.com (Henry Maddocks)
Date: Sun Nov 10 21:56:02 2002
Subject: [ODE] new ODE collision
In-Reply-To: <20021110204313.0f068550.russ@q12.org>
Message-ID:
kewl...I can't wait:)
On Monday, November 11, 2002, at 02:43 PM, Russ Smith wrote:
> not quite yet, but it will be.
From dmcclurg at pandemicstudios.com.au Sun Nov 10 22:04:43 2002
From: dmcclurg at pandemicstudios.com.au (David McClurg)
Date: Sun Nov 10 22:04:43 2002
Subject: [ODE] rate for fixed timesteps
Message-ID:
To avoid breaking through geometry or generating large collision penetration depths, you'll need use a step value which scales to your velocity.
step = 1/60
speed = length(vel)
if (speed * step) > max_depth then
step = max_depth / speed
endif
dWorldStep(world, step)
just make sure max_depth is less than the radius of your moving vehicle. ideally, it would be small enough not to visually notice either (eg. radius * 0.1f)
if you really want to use a fixed time step,
step = max_depth / max_speed
-----Original Message-----
From: Daniel.Groll@t-online.de [mailto:Daniel.Groll@t-online.de]
Sent: Sunday, 10 November 2002 12:18 AM
To: ode@q12.org
Subject: [ODE] rate for fixed timesteps
I use fixed timesteps to run my car simulation game. With a rate of 60
Hz the simulation runs smooth and seemed to be stable but now with
further testing I encountered some stability problems when cars or
objects move fast. Sometimes they seem to break through geometry or
"caught" in geometry. Is this the cause of a relatively low rate of
world timesteps? Or are there other reasons for instability? At which
rates run phyiscs simulations in common?
From chris.campbell at l8tech.com Sun Nov 10 22:38:01 2002
From: chris.campbell at l8tech.com (Chris Campbell)
Date: Sun Nov 10 22:38:01 2002
Subject: [ODE] bang!
Message-ID:
Sometimes having explosions in a physics simulation is a good thing :)
http://oscar.lincmedia.co.jp:58080/bang.zip
Press h to get some instructions - you should really be inside the room to
throw the dynamite properly.
This is from the final (?) tutorial on how to use a game engine I have been
working on which has a small amount of integration with ODE. I'm hoping to
get my website organised and up sometime in the next few weeks.
ChrisC
From coding at natew.com Mon Nov 11 01:44:02 2002
From: coding at natew.com (Nate W)
Date: Mon Nov 11 01:44:02 2002
Subject: [ODE] new ODE collision
In-Reply-To: <20021110181315.7c8dcc2e.russ@q12.org>
Message-ID:
On Sun, 10 Nov 2002, Russ Smith wrote:
> > - When adding the ray class we should think about what the
> > 'penetration depth' should be. Do you have any thoughts on this?
>
> i'm not sure that dRay will ever be attached to a body, in which case
> penetration depth does not have much use for the dynamics. perhaps you
> can think of a non-dynamics use/definition for the penetration depth?
The first thing that came to my mind when I heard about the ray class was
sensors for the critters I'm making in Juice, sort of like IR or
ultrasonic rangefinders in robots, or like whiskers on cats. I'd want to
know the distance from the ray's origin to the first object it collides
with.
Second, I think they might be useful for fast-moving objects - if you
project a ray forward along a missile's direction of travel, you could get
"collision" info in cases where the missile would otherwise teleport
around an object due to its position changing by a distance greater than
its length. In that case, could the ray intersection be used to generate
a contact joint, to stop the missile from penetrating?
--
Nate Waddoups
Redmond WA USA
http://www.natew.com
From Remko at act-3d.com Mon Nov 11 03:33:02 2002
From: Remko at act-3d.com (Remko Jacobs (act-3d.com))
Date: Mon Nov 11 03:33:02 2002
Subject: [ODE] Universal joint
Message-ID: <279631823.2242109102.98@server>
Is it possible to include parameters that limit the rotation of a
universal joint? This way you could create a rag doll with ODE. This is
very useful in games, like Doom 3 where a character drops of the stairs
after dying instead of playing a standard animation.
From ed.jones at oracle.com Mon Nov 11 04:11:02 2002
From: ed.jones at oracle.com (Ed Jones)
Date: Mon Nov 11 04:11:02 2002
Subject: [ODE] need to understand this
References: <20021109092556.77275.qmail@web40507.mail.yahoo.com>
Message-ID: <3DCF9028.4040402@oracle.com>
Hi,
From "common.h"...
typedef dReal dMatrix3[4*3];
and from the top of "rotation.cpp"...
#define _R(i,j) R[(i)*4+(j)]
;-)
Cheers,
Ed.
pia dalusong wrote:
>hello,
>
>after a lot of digging, i saw this
>void dRFromEulerAngles (dMatrix3 R, dReal phi, dReal
>theta, dReal psi)
>{
> dReal sphi,cphi,stheta,ctheta,spsi,cpsi;
> dAASSERT (R);
> sphi = dSin(phi);
> cphi = dCos(phi);
> stheta = dSin(theta);
> ctheta = dCos(theta);
> spsi = dSin(psi);
> cpsi = dCos(psi);
> _R(0,0) = cpsi*ctheta;
> _R(0,1) = spsi*ctheta;
> _R(0,2) =-stheta;
> _R(1,0) = cpsi*stheta*sphi - spsi*cphi;
> _R(1,1) = spsi*stheta*sphi + cpsi*cphi;
> _R(1,2) = ctheta*sphi;
> _R(2,0) = cpsi*stheta*cphi + spsi*sphi;
> _R(2,1) = spsi*stheta*cphi - cpsi*sphi;
> _R(2,2) = ctheta*cphi;
>}
>i'm a little confused as to how you put values into a
>dMatrix and how do you call it?
>if i have a variable
>const dReal *R
>and
>dMatrix3 M
>
>is R[0]=m[0,0] ?
>i'm sorry but i don't understand what happens when you
>write _R(2,1)
>
>is it an 2d array matrix[3][3] or a 1d matrix[12]?
>
>thanks
>
>
>
>__________________________________________________
>Do you Yahoo!?
>U2 on LAUNCH - Exclusive greatest hits videos
>http://launch.yahoo.com/u2
>_______________________________________________
>ODE mailing list
>ODE@q12.org
>http://q12.org/mailman/listinfo/ode
>
>
From dominicmorris2 at yahoo.com Mon Nov 11 07:32:01 2002
From: dominicmorris2 at yahoo.com (Dominic Morris)
Date: Mon Nov 11 07:32:01 2002
Subject: [ODE] Car handling - Overturning too easily
Message-ID: <20021111143146.93605.qmail@web80305.mail.yahoo.com>
Hello all,
I'm sure that there must be a simple solution to this,
so if anybody can advise me I'd be very grateful.
I've got my car driving over my terrain mesh using the
contrib tri-collider, and the one remaining problem I
have is that when I steer the car when it's travelling
quickly, it overturns much too easily.
I've based my code on the buggy example, so the geoms
are four spheres and a box. Is this down to the use of
spheres for the wheels? If so, what is the solution?
Capped Cylinders don't seem any better, as they don't
seem to fit the geometery of wheels any better than
spheres, and I'm not sure of a user tri-collider for
CCylinders.
I've played about with masses, and friction models
etc, and I can tune down the overturning tendancy, at
the expense of the car's grip by using the Slip1 and
Slip2 parameters (not that I fully understand these
either!)
Any help is appreciated,
DM.
__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com
From henri at cs.sun.ac.za Mon Nov 11 08:35:02 2002
From: henri at cs.sun.ac.za (Henri Hakl)
Date: Mon Nov 11 08:35:02 2002
Subject: [ODE] Faster replacement for fastldlt.c
Message-ID: <000d01c28997$fcabf4f0$39d4e892@shrine>
This is a multi-part message in MIME format.
------=_NextPart_000_000A_01C289A8.C02B4F10
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi ODE fans and perpetrators :)
I've been looking into various ways to optimize the LDLT factorization =
which is one of the computationally intensive tasks in ODE. =
Unforetunately I cannot directly test alot of my results due to not =
having a C(++) compiler around. Nonetheless, I've restructured the =
original "fastldlt.c" file which should be functionally equivalent to =
the original but considerably faster. (Russ... the version I send you =
had a bug in it - this version here should be correct.) I hope the =
version I provide is correct, this is difficult to ascertain just by =
inspection though, as the code is heavily interdependent.
Please can somebody that is "in the know" test the replacement file for =
correctness and speed. If it gets the thumbs-up I'd be happy to see it =
integrated into the ODE package. You can find the file at: =
http://www.cs.sun.ac.za/~henri/fastldlt_henri.c
thanks
Henri
------=_NextPart_000_000A_01C289A8.C02B4F10
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi ODE fans and =
perpetrators :)
I've been looking into various ways to optimize =
the LDLT=20
factorization which is one of the computationally intensive =
tasks in ODE.=20
Unforetunately I cannot directly test alot of my results due to not =
having a=20
C(++) compiler around. Nonetheless, I've restructured the original =
"fastldlt.c"=20
file which should be functionally equivalent to the original but=20
considerably faster. (Russ... the version I send you had a bug in it - =
this=20
version here should be correct.) I hope the version I provide is =
correct, this=20
is difficult to ascertain just by inspection though, as the code is =
heavily=20
interdependent.
Please can somebody that is "in the know" test =
the=20
replacement file for correctness and speed. If it gets the thumbs-up I'd =
be=20
happy to see it integrated into the ODE package. You can find the file =
at: http://www.cs.sun.ac.za/~henri/fastldlt_henri.c
thanks
Henri
------=_NextPart_000_000A_01C289A8.C02B4F10--
From anselm at hook.org Mon Nov 11 09:54:02 2002
From: anselm at hook.org (Anselm Hook)
Date: Mon Nov 11 09:54:02 2002
Subject: [ODE] Car handling - Overturning too easily
In-Reply-To: <20021111143146.93605.qmail@web80305.mail.yahoo.com>
Message-ID:
Hi Dominic,
You can put a weight far below the car's chassis - the Monster Mayhem demo
does this.
- a
On Mon, 11 Nov 2002, Dominic Morris wrote:
> Hello all,
>
> I'm sure that there must be a simple solution to this,
> so if anybody can advise me I'd be very grateful.
>
> I've got my car driving over my terrain mesh using the
> contrib tri-collider, and the one remaining problem I
> have is that when I steer the car when it's travelling
> quickly, it overturns much too easily.
>
> I've based my code on the buggy example, so the geoms
> are four spheres and a box. Is this down to the use of
> spheres for the wheels? If so, what is the solution?
> Capped Cylinders don't seem any better, as they don't
> seem to fit the geometery of wheels any better than
> spheres, and I'm not sure of a user tri-collider for
> CCylinders.
>
> I've played about with masses, and friction models
> etc, and I can tune down the overturning tendancy, at
> the expense of the car's grip by using the Slip1 and
> Slip2 parameters (not that I fully understand these
> either!)
>
> Any help is appreciated,
>
> DM.
>
> __________________________________________________
> Do you Yahoo!?
> New DSL Internet Access from SBC & Yahoo!
> http://sbc.yahoo.com
> _______________________________________________
> ODE mailing list
> ODE@q12.org
> http://q12.org/mailman/listinfo/ode
>
From coding at natew.com Mon Nov 11 11:30:02 2002
From: coding at natew.com (Nate W)
Date: Mon Nov 11 11:30:02 2002
Subject: [ODE] Car handling - Overturning too easily
In-Reply-To: <20021111143146.93605.qmail@web80305.mail.yahoo.com>
Message-ID:
On Mon, 11 Nov 2002, Dominic Morris wrote:
> I'm sure that there must be a simple solution to this,
> so if anybody can advise me I'd be very grateful.
>
> I've got my car driving over my terrain mesh using the
> contrib tri-collider, and the one remaining problem I
> have is that when I steer the car when it's travelling
> quickly, it overturns much too easily.
I ran into this as well. I've mostly just been tuning the tire-ground
friction, so it is more likely to slide sideways than flip onto its roof.
You might also want to try lowering the car's center of gravity, either by
changing the chassis' inertial tensor or by reducing the 'ride height' of
the suspension.
I think you have to expect a certain amount of rollover, since it's a
problem with real off-road racing as well.
Also, are you steering with a joystick, or are you using the keyboard?
If the latter, you might want to try slowing down the steering response,
or reducing the steering angle as the car gains speed.
> Capped Cylinders don't seem any better, as they don't
> seem to fit the geometery of wheels any better than
> spheres, and I'm not sure of a user tri-collider for
> CCylinders.
I'm using spheres for driving over terrain, and flat-ended cylinders for
driving over ground planes. I've been wondering if it might be useful to
have a "tire" collision hull - something similar to a cylinder but
simplified. For example, just the ends of a flat-end cylinder, or just
the middle section of a capped cylinder (not the caps). It might be more
trouble than it's worth, but then again it might be possible to save some
clock cycles by using a shape that is correct 99% of the time.
--
Nate Waddoups
Redmond WA USA
http://www.natew.com
From erwin at vo.com Mon Nov 11 12:04:02 2002
From: erwin at vo.com (Erwin de Vries)
Date: Mon Nov 11 12:04:02 2002
Subject: [ODE] new ODE collision
References:
Message-ID: <004401c289b5$109f81d0$73fefea9@athlon>
> On Sun, 10 Nov 2002, Russ Smith wrote:
>
> > > - When adding the ray class we should think about what the
> > > 'penetration depth' should be. Do you have any thoughts on this?
> >
> > i'm not sure that dRay will ever be attached to a body, in which case
> > penetration depth does not have much use for the dynamics. perhaps you
> > can think of a non-dynamics use/definition for the penetration depth?
>
> The first thing that came to my mind when I heard about the ray class was
> sensors for the critters I'm making in Juice, sort of like IR or
> ultrasonic rangefinders in robots, or like whiskers on cats. I'd want to
> know the distance from the ray's origin to the first object it collides
> with.
Thats also what i'm thinking of. Its not what it currently does, but i
believe this would be more useful than the current version.
> Second, I think they might be useful for fast-moving objects - if you
> project a ray forward along a missile's direction of travel, you could get
> "collision" info in cases where the missile would otherwise teleport
> around an object due to its position changing by a distance greater than
> its length. In that case, could the ray intersection be used to generate
> a contact joint, to stop the missile from penetrating?
I'd say it would be more appropriate to use a ccylinder here. Unless you
want it to bounce off of course.
Erwin
From maddocks at metservice.com Mon Nov 11 12:50:02 2002
From: maddocks at metservice.com (Henry Maddocks)
Date: Mon Nov 11 12:50:02 2002
Subject: Fwd: [ODE] Car handling - Overturning too easily
Message-ID:
On Tuesday, November 12, 2002, at 03:31 AM, Dominic Morris wrote:
> I've got my car driving over my terrain mesh using the
> contrib tri-collider, and the one remaining problem I
> have is that when I steer the car when it's travelling
> quickly, it overturns much too easily.
>
I had this problem too.
> I've based my code on the buggy example, so the geoms
> are four spheres and a box.
I didn't base my code on the buggy but I've got a box and four spheres.
>
> I've played about with masses, and friction models
> etc, and I can tune down the overturning tendancy, at
> the expense of the car's grip by using the Slip1 and
> Slip2 parameters (not that I fully understand these
> either!)
>
That's how I fixed it. It took a while to get a good balance between
too much grip (overturning) and not enough (skidding). My car still
over turns sometimes which I think is because my centre of gravity is
too high. And anyway, cars do turn over in real life, I know:)
henry
From Filipe Dias"
Message-ID: <001601c289bd$21d47070$4601a8c0@mind.pt>
I don't know how many turning wheels you guys have (assuming the front 2), but
shifting the center of gravity forward or backwards will also affect the
turning... more weight on the front wheels will turn more (the back slips
easyer), but I like to place more wieght on the back wheels.. But don't
exagerate!!
Fil.
From dmcclurg at pandemicstudios.com.au Mon Nov 11 16:55:02 2002
From: dmcclurg at pandemicstudios.com.au (David McClurg)
Date: Mon Nov 11 16:55:02 2002
Subject: [ODE] new ODE collision
Message-ID:
>>> - When adding the ray class we should think about what the 'penetration depth' should be. Do you have any thoughts on this?
The way a ray works is that you get one contact point where the ray first hits something. Penetration depth doesn't mean anything but it is very convenient to know the distance from the origin of the ray to the contact position. Storing that in the 'depth' field would make alot of sense for rays.
>> i'm not sure that dRay will ever be attached to a body, in which case penetration depth does not have much use for the dynamics. perhaps you can think of a non-dynamics use/definition for the penetration depth?
I'm finding two uses for rays in my game.
1) Ground Height Detection
2) LOS - line of sight
The rays are almost always associated with a moving body!
Perhaps some examples will clarify...
- cameras: i don't want the chase camera going under the ground or perhaps i want to look at the ground point under the puppet so i don't have to head bob when he jumps. two rays are useful here-- one for the target and one for the eye. also the camera will need to cast a LOS ray to determine if there is an obstruction.
- floating prizes: i detect the ground height so that prizes can automatically find a convenient home position where the player can grab them. in this situation, the ray is used for one HIT and then the ray is destroyed.
Hope that helps!
From claytonious at cox.net Mon Nov 11 18:02:02 2002
From: claytonious at cox.net (Clay Fowler)
Date: Mon Nov 11 18:02:02 2002
Subject: [ODE] Weird collision/force problem
Message-ID: <006a01c289e6$fe384860$0500a8c0@angus>
This is a multi-part message in MIME format.
------=_NextPart_000_0067_01C289AC.51C413A0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hello, everyone.
I have a problem with forces being applied to my rigid body. My =
vehicle's "front" is along the positive Y-Axis, its "right" is along the =
positive X-axis and it's "up" is positive-Z. When I call =
dBodyAddForceAtPoint() with a force vector of 0,0,1 ("straight up"), =
specifying the rear-right of the vehicle as the point (so it's, for =
example, an X of 1 and a Y of -1), for some reason the FRONT LEFT of the =
vehicle gets pushed up into the air. This is the opposite corner of the =
point I am specifying! When I swap the coordinates and apply an upward =
force at the point (-1,1), the REAR RIGHT of the vehicle gets pushed up. =
I have verified that ODE and my app both have the same idea of what the =
world coordinate axes are by applying forces to the center of mass to =
move the vehicle along the world's X, Y, and Z axes and these all behave =
exactly as I would expect. But when I apply a force at a point, it seems =
like the point I'm passing is "mirrored" on the axes. I am specifying =
the mass of the vehicle with a simple dMassSetBox() and I have visually =
verified that the box is a very good fit to the vehicle. Any ideas on =
why the axes are "mirrored" this way for applying forces?
The reason this is such a big problem is because I am doing my own =
collision detection with the terrain beneath the vehicle by creating my =
own Contact joints where the vehicle touches the terrain. Of course, the =
vehicle responds incorrectly to these points because of the mirroring =
problem.
Thanks for any help!
- Clay
------=_NextPart_000_0067_01C289AC.51C413A0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hello, everyone.
I have a problem with forces being =
applied to my=20
rigid body. My vehicle's "front" is along the positive Y-Axis, its =
"right" is=20
along the positive X-axis and it's "up" is positive-Z. When I call=20
dBodyAddForceAtPoint() with a force vector of 0,0,1 ("straight up"), =
specifying=20
the rear-right of the vehicle as the point (so it's, for example, an X =
of 1 and=20
a Y of -1), for some reason the FRONT LEFT of the vehicle gets pushed up =
into=20
the air. This is the opposite corner of the point I am specifying! When =
I swap=20
the coordinates and apply an upward force at the point (-1,1), the REAR =
RIGHT of=20
the vehicle gets pushed up. I have verified that ODE and my app both =
have the=20
same idea of what the world coordinate axes are by applying forces to =
the center=20
of mass to move the vehicle along the world's X, Y, and Z axes and these =
all=20
behave exactly as I would expect. But when I apply a force at a point, =
it seems=20
like the point I'm passing is "mirrored" on the axes. I am specifying =
the mass=20
of the vehicle with a simple dMassSetBox() and I have visually verified =
that the=20
box is a very good fit to the vehicle. Any ideas on why the axes are =
"mirrored"=20
this way for applying forces?
The reason this is such a big problem =
is because I=20
am doing my own collision detection with the terrain beneath the vehicle =
by=20
creating my own Contact joints where the vehicle touches the terrain. Of =
course,=20
the vehicle responds incorrectly to these points because of the =
mirroring=20
problem.
Thanks for any help!
- Clay
------=_NextPart_000_0067_01C289AC.51C413A0--
From mal at candomultimedia.com Tue Nov 12 05:54:02 2002
From: mal at candomultimedia.com (Mal)
Date: Tue Nov 12 05:54:02 2002
Subject: [ODE] ODE / Blender news...
In-Reply-To: <006a01c289e6$fe384860$0500a8c0@angus>
Message-ID: <000101c28a4a$7c2f1ab0$b000a8c0@MalLaptop>
Here's some ODE related news regarding Blender...
http://www.blender.org/modules.php?op=modload&name=News&file=article&sid
=15&mode=thread&order=0&thold=0
" No new functionality is added in Blender, with one exception: ODE.
Commits in this part of Blender should be aimed at getting Blender not
crashing, and preferably running (some) of the old demos again.
The current Blender physics system (nicked SUMO) will be entirely
replaced with ODE later. That might give a compatibility problem, but at
least it will provide quite some cool new features."
Sounds like things are flying along!
Norman, do you have any binary beta files with ODE support that we can
test out? :)
I'm just recovering from a pretty bad PC crash, and have lost all my old
eMails, so I don't have your direct eMail anymore!
Mal
From anselm at hook.org Tue Nov 12 12:11:01 2002
From: anselm at hook.org (Anselm Hook)
Date: Tue Nov 12 12:11:01 2002
Subject: [ODE] irc?
In-Reply-To: <000101c28a4a$7c2f1ab0$b000a8c0@MalLaptop>
Message-ID:
Where was that irc channel again for ode? Which server?
- a
From Alan_Gordie at payformance.com Tue Nov 12 12:39:02 2002
From: Alan_Gordie at payformance.com (Alan Gordie)
Date: Tue Nov 12 12:39:02 2002
Subject: [ODE] irc?
Message-ID:
It's #ode on EFNet
Alan
-----Original Message-----
From: Anselm Hook [mailto:anselm@hook.org]
Sent: Tuesday, November 12, 2002 2:11 PM
To: ode@q12.org
Subject: [ODE] irc?
Where was that irc channel again for ode? Which server?
- a
_______________________________________________
ODE mailing list
ODE@q12.org
http://q12.org/mailman/listinfo/ode
From colire02 at noa.nintendo.com Wed Nov 13 11:32:02 2002
From: colire02 at noa.nintendo.com (Colin Reed)
Date: Wed Nov 13 11:32:02 2002
Subject: [ODE] Convex hulls
Message-ID:
How difficult would it be to get convex hulls working as a more general collision type as opposed to box collisions? For me this would be really helpfull, I was just wondering how much work it would be.
Colin
From dmcclurg at pandemicstudios.com.au Wed Nov 13 17:51:02 2002
From: dmcclurg at pandemicstudios.com.au (David McClurg)
Date: Wed Nov 13 17:51:02 2002
Subject: [ODE] Convex hulls
Message-ID:
> if you're curious, the source files for the new collision infrastructure have been checked into CVS (collision_*.h, collision_*.cpp). it has not been hooked up to the rest of ODE yet, so the only reason i mention it is for the curious. note that there's still a bunch of stuff to do, in particular to hook up the ray, trimesh and cylinder classes, and to convert the hash table space to use an incremental approach ... but you can get an idea of the new layout.
i think the trimesh, when completed, should work for you.
-----Original Message-----
From: Colin Reed [mailto:colire02@noa.nintendo.com]
Sent: Wednesday, 13 November 2002 1:53 PM
To: ode@q12.org
Subject: [ODE] Convex hulls
How difficult would it be to get convex hulls working as a more general collision type as opposed to box collisions? For me this would be really helpfull, I was just wondering how much work it would be.
Colin
From claytonious at cox.net Wed Nov 13 18:45:02 2002
From: claytonious at cox.net (Clay Fowler)
Date: Wed Nov 13 18:45:02 2002
Subject: [ODE] Weird collision/force problem
References: <006a01c289e6$fe384860$0500a8c0@angus>
Message-ID: <003d01c28b7f$50820180$0500a8c0@angus>
This is a multi-part message in MIME format.
------=_NextPart_000_003A_01C28B44.A40C1F10
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
In case anyone else runs into this, here is the solution...
The axes seemed inverted because I was incorrectly copying the =
transformation matrix from ODE into OSG. I finally looked at the code in =
the drawstuff lib to see how to fill an OpenGL-style 4x4 matrix with =
values, and I was doing it backwards. Now that I'm filling xform =
matrices properly, everything works wonderfully.
----- Original Message -----=20
From: Clay Fowler=20
To: ode@q12.org=20
Sent: Monday, November 11, 2002 6:01 PM
Subject: [ODE] Weird collision/force problem
Hello, everyone.
I have a problem with forces being applied to my rigid body. My =
vehicle's "front" is along the positive Y-Axis, its "right" is along the =
positive X-axis and it's "up" is positive-Z. When I call =
dBodyAddForceAtPoint() with a force vector of 0,0,1 ("straight up"), =
specifying the rear-right of the vehicle as the point (so it's, for =
example, an X of 1 and a Y of -1), for some reason the FRONT LEFT of the =
vehicle gets pushed up into the air. This is the opposite corner of the =
point I am specifying! When I swap the coordinates and apply an upward =
force at the point (-1,1), the REAR RIGHT of the vehicle gets pushed up. =
I have verified that ODE and my app both have the same idea of what the =
world coordinate axes are by applying forces to the center of mass to =
move the vehicle along the world's X, Y, and Z axes and these all behave =
exactly as I would expect. But when I apply a force at a point, it seems =
like the point I'm passing is "mirrored" on the axes. I am specifying =
the mass of the vehicle with a simple dMassSetBox() and I have visually =
verified that the box is a very good fit to the vehicle. Any ideas on =
why the axes are "mirrored" this way for applying forces?
The reason this is such a big problem is because I am doing my own =
collision detection with the terrain beneath the vehicle by creating my =
own Contact joints where the vehicle touches the terrain. Of course, the =
vehicle responds incorrectly to these points because of the mirroring =
problem.
Thanks for any help!
- Clay
------=_NextPart_000_003A_01C28B44.A40C1F10
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
In case anyone else runs into this, =
here is the=20
solution...
The axes seemed inverted because I was =
incorrectly=20
copying the transformation matrix from ODE into OSG. I finally looked at =
the=20
code in the drawstuff lib to see how to fill an OpenGL-style 4x4 matrix =
with=20
values, and I was doing it backwards. Now that I'm filling xform =
matrices=20
properly, everything works wonderfully.
----- Original Message -----
From:=20
Clay Fowler=20
Sent: Monday, November 11, 2002 =
6:01=20
PM
Subject: [ODE] Weird =
collision/force=20
problem
Hello, everyone.
I have a problem with forces being =
applied to my=20
rigid body. My vehicle's "front" is along the positive Y-Axis, its =
"right" is=20
along the positive X-axis and it's "up" is positive-Z. When I call=20
dBodyAddForceAtPoint() with a force vector of 0,0,1 ("straight up"),=20
specifying the rear-right of the vehicle as the point (so it's, for =
example,=20
an X of 1 and a Y of -1), for some reason the FRONT LEFT of the =
vehicle gets=20
pushed up into the air. This is the opposite corner of the point I am=20
specifying! When I swap the coordinates and apply an upward force at =
the point=20
(-1,1), the REAR RIGHT of the vehicle gets pushed up. I have verified =
that ODE=20
and my app both have the same idea of what the world coordinate axes =
are by=20
applying forces to the center of mass to move the vehicle along the =
world's X,=20
Y, and Z axes and these all behave exactly as I would expect. But when =
I apply=20
a force at a point, it seems like the point I'm passing is "mirrored" =
on the=20
axes. I am specifying the mass of the vehicle with a simple =
dMassSetBox() and=20
I have visually verified that the box is a very good fit to the =
vehicle. Any=20
ideas on why the axes are "mirrored" this way for applying=20
forces?
The reason this is such a big problem =
is because=20
I am doing my own collision detection with the terrain beneath the =
vehicle by=20
creating my own Contact joints where the vehicle touches the terrain. =
Of=20
course, the vehicle responds incorrectly to these points because of =
the=20
mirroring problem.
Thanks for any help!
- Clay
------=_NextPart_000_003A_01C28B44.A40C1F10--
From claytonious at cox.net Wed Nov 13 22:42:01 2002
From: claytonious at cox.net (Clay Fowler)
Date: Wed Nov 13 22:42:01 2002
Subject: [ODE] slip1 and slip2
Message-ID: <000e01c28ba0$7f74e270$0500a8c0@angus>
This is a multi-part message in MIME format.
------=_NextPart_000_000B_01C28B65.D2F478B0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
What do the slip1 and slip2 parameters in a contact structure do?
------=_NextPart_000_000B_01C28B65.D2F478B0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
What do the slip1 and slip2 parameters =
in a contact=20
structure do?
------=_NextPart_000_000B_01C28B65.D2F478B0--
From Tony.Peguero at xtra.co.nz Wed Nov 13 23:53:01 2002
From: Tony.Peguero at xtra.co.nz (Tony Peguero)
Date: Wed Nov 13 23:53:01 2002
Subject: [ODE] more physics
In-Reply-To:
Message-ID:
>Costs in what way? It does say memory usage and how much of
>the cpu per frame the physics system takes. What other costs
>are there?
He he. You must have been working with open source projects for quite a
while to have forgotten that some things cost money. Some physics engines
cost a LOT of money.
>Also is it just me or do the chain and hinge behave strangly?
>If you continue to force it upwards it starts to wobble. Like
>a snake or something. Maybe it's just me and thats how it
>should behave.
I noticed that too. I think it's because of the way the keyboard controls
were written, rather than a problem with the engine. When you press the lift
key, it applies a momentary impulse to the end of the chain. When you hold
the button down it applies repeated impulses, not a constant force, so the
end of the chain is basically being shaken up and down.
-----Original Message-----
From: ode-admin@q12.org [mailto:ode-admin@q12.org]On Behalf Of Joakim
Eriksson
Sent: Friday, 1 November 2002 10:27 a.m.
To: ode@q12.org
Subject: SV: [ODE] more physics
> > looks like another physics engine...
> >
> > www.tokamakphysics.com
>
> interesting. yet another mention of iterative constraint
> solving methods here. the demos are kind of bare bones
>(i.e., like ODE's bare bones demos). no mention of the cost.
Costs in what way? It does say memory usage and how much of
the cpu per frame the physics system takes. What other costs
are there?
> the box stack demo has an interesting flaw: a nudged stack
> will tip over, then freeze part of the way down. this suggests
> that 'stable' box stacking is achieved through simply turning
>off the phisics for a stationary stack
Yes, seems like the objects sleep VERY quickly. After just a few
tries I manage to get it to sleep in a physicly impossible position.
(If the simulation had run for just a few ticks more the boxes
would have fallen over) but they quickly froze in place.
> the collision looks like it allows penetration, like ODE. if
> you collapse the chain on top of itself it will squish into
> itself a bit then expand out.
It does indeed allow penetration. Just move closer to a object
and spawn a sphere or something. You can see that even if the
object is inside another object he can handle it.
Its also a dead give away that he for the moment only handles
primitives vs primitives and primitives vs static triangle meshes.
It seems to be able to handle quite a lot. It does use a bit of
memory 500Kb in some cases but they do contain quite a lot of
objects. Too bad they dont have any more information on thier
method.
Also is it just me or do the chain and hinge behave strangly?
If you continue to force it upwards it starts to wobble. Like
a snake or something. Maybe it's just me and thats how it
should behave.
/Joakim E. - www.planestate.net
_______________________________________________
ODE mailing list
ODE@q12.org
http://q12.org/mailman/listinfo/ode
From Remko at act-3d.com Thu Nov 14 03:54:01 2002
From: Remko at act-3d.com (Remko Jacobs (act-3d.com))
Date: Thu Nov 14 03:54:01 2002
Subject: [ODE] Universal joint
Message-ID: <279892225.2502571807.98@server>
I noticed that two bodies that are connected by a joint do not have
collision with each other. Am I missing something here? The ODE examples
show the same behavior between connected bodies.
-----Original Message-----
From: Martin C. Martin [mailto:martin@metahuman.org]
Sent: Monday, November 11, 2002 8:58 AM
To: Remko Jacobs (act-3d.com)
Subject: Re: [ODE] Universal joint
Hi,
The way I do it is to use collisions with the body to limit the rotation.
That looks pretty natural...
- Martin
"Remko Jacobs (act-3d.com)" wrote:
>
> Is it possible to include parameters that limit the rotation of a
> universal joint? This way you could create a rag doll with ODE. This is
> very useful in games, like Doom 3 where a character drops of the stairs
> after dying instead of playing a standard animation.
>
> _______________________________________________
> ODE mailing list
> ODE@q12.org
> http://q12.org/mailman/listinfo/ode
From Remko at act-3d.com Thu Nov 14 04:00:02 2002
From: Remko at act-3d.com (Remko Jacobs (act-3d.com))
Date: Thu Nov 14 04:00:02 2002
Subject: [ODE] rate for fixed timesteps
Message-ID: <279892645.2502991882.98@server>
Using a fixed time step is the way to go. The problem is that the frame
rate is not constant. We solved this by using a constant update rate (in
Hz) for ODE that is independent of the program updates.
CFM and ERP values work differently with different time steps so you
should avoid using more than one different time step for one project.
Using a constant update frequency means that for some frames there might
be 10 time steps calculated for ODE and other frames ODE does not update
at all.
From: David McClurg [mailto:dmcclurg@pandemicstudios.com.au]
>To avoid breaking through geometry or generating large collision
>penetration depths, you'll need use a step value which scales to your
>velocity.
>
> step = 1/60
> speed = length(vel)
> if (speed * step) > max_depth then
> step = max_depth / speed
> endif
> dWorldStep(world, step)
>
>just make sure max_depth is less than the radius of your moving vehicle.
>ideally, it would be small enough not to visually notice either (eg.
radius * 0.1f)
>if you really want to use a fixed time step,
>
> step = max_depth / max_speed
From martin at metahuman.org Thu Nov 14 06:41:02 2002
From: martin at metahuman.org (Martin C. Martin)
Date: Thu Nov 14 06:41:02 2002
Subject: [ODE] Universal joint
References: <279892225.2502571807.98@server>
Message-ID: <3DD3A7AB.4A2594E9@metahuman.org>
"Remko Jacobs (act-3d.com)" wrote:
>
> I noticed that two bodies that are connected by a joint do not have
> collision with each other.
They do in my application. Does your near callback create collision
constraints for them? Are you sure the size/location/orientation/shape
that you're drawing are the same as ODE is using?
- Martin
From ykhun at singnet.com.sg Thu Nov 14 08:23:02 2002
From: ykhun at singnet.com.sg (ykhun)
Date: Thu Nov 14 08:23:02 2002
Subject: [ODE] Help for beginners
Message-ID: <000a01c28bf2$1cf993a0$889f15a5@dune>
This is a multi-part message in MIME format.
------=_NextPart_000_0007_01C28C35.2ADC9650
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi,
i'm very new to ODE and rigid body physics. I found that there isn't =
much stuff to help newbies like me to kickstart using ODE. Read the docs =
and learn much about how ODE works but not how to use it!
Is there any resource to help beginners up and running with ODE in a =
short time??
Cheers!
ykhun
------=_NextPart_000_0007_01C28C35.2ADC9650
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi,
i'm very new to ODE and rigid body =
physics. I found=20
that there isn't much stuff to help newbies like me to kickstart using =
ODE. Read=20
the docs and learn much about how ODE works but not how to use =
it!
Is there any resource to help beginners =
up and=20
running with ODE in a short time??
Cheers!
ykhun
------=_NextPart_000_0007_01C28C35.2ADC9650--
From martin at metahuman.org Thu Nov 14 08:43:02 2002
From: martin at metahuman.org (Martin C. Martin)
Date: Thu Nov 14 08:43:02 2002
Subject: [ODE] Help for beginners
References: <000a01c28bf2$1cf993a0$889f15a5@dune>
Message-ID: <3DD3C44B.1F9A8A9C@metahuman.org>
You can take a look at the examples included with ODE, especially the
boxstack and buggy demos.
- Martin
> ykhun wrote:
>
> Hi,
> i'm very new to ODE and rigid body physics. I found that there isn't
> much stuff to help newbies like me to kickstart using ODE. Read the docs
> and learn much about how ODE works but not how to use it!
>
> Is there any resource to help beginners up and running with ODE in a
> short time??
> Cheers!
>
> ykhun
From max.lungarella at aist.go.jp Thu Nov 14 08:59:02 2002
From: max.lungarella at aist.go.jp (Max Lungarella)
Date: Thu Nov 14 08:59:02 2002
Subject: [ODE] Help for beginners
In-Reply-To: <000a01c28bf2$1cf993a0$889f15a5@dune>
References: <000a01c28bf2$1cf993a0$889f15a5@dune>
Message-ID: <20021115005725.5ff946cb.max.lungarella@aist.go.jp>
hi,
you can also learn a lot by browsing through the archives of this mailing list.
cheerio,
max
> i'm very new to ODE and rigid body physics. I found that there isn't
> much stuff to help newbies like me to kickstart using ODE. Read the
> docs and learn much about how ODE works but not how to use it!
>
> Is there any resource to help beginners up and running with ODE in a
> short time?? Cheers!
>
> ykhun
From christian.verbeek at ais.fraunhofer.de Thu Nov 14 10:57:01 2002
From: christian.verbeek at ais.fraunhofer.de (Christian Verbeek)
Date: Thu Nov 14 10:57:01 2002
Subject: [ODE] test_buggy with 13 buggys
Message-ID: <3DD3E3E6.C600B51@ais.fraunhofer.de>
dear ode-users,
i am quite new to ode. but it took me half a day to write a program that
will crash. you can find it under
http://ais.gmd.de/~verbeek/ode/
this is the test_buggy example modularised. for the buggy i made a class
RBuggy where i am deriving 13 objects from. when the buggys collide the
program crashes. when i do the same with 12 buggys, everthing is ok.
i tested it with ode-0.03 and the latest cvs-version under cygwin and
windowsXP. dont blame me, but linux does not support the graficsadapter
of my laptop. compiling this with linux works, but execution of the
program is really really slow.
i used gdb to find out, where the program crashes. i think it is
somewhere in the collision detection routines. at least these are called
right before the program crashes.
help needed, c.
--
-__________________________________________
Dr. rer. nat. Dipl.-Phys. C. Verbeek
email: christian.verbeek@ais.fraunhofer.de
room: C2-214
http://www.ais.fraunhofer.de/~verbeek
phone: +49 2241 14 2057
fax : +49 2241 14 2384
From ericc at xenopi.com Thu Nov 14 11:08:02 2002
From: ericc at xenopi.com (Eric Cha)
Date: Thu Nov 14 11:08:02 2002
Subject: [ODE] test_buggy with 13 buggys
In-Reply-To: <3DD3E3E6.C600B51@ais.fraunhofer.de>
Message-ID: <005701c28c09$37a798c0$6401a8c0@donald>
Sounds like stack overflow to me... I could see that happening with 13
buggies rolling around..
> -----Original Message-----
> From: ode-admin@q12.org [mailto:ode-admin@q12.org] On Behalf
> Of Christian Verbeek
> Sent: Thursday, November 14, 2002 9:57 AM
> To: ode@q12.org
> Subject: [ODE] test_buggy with 13 buggys
>
>
> dear ode-users,
>
> i am quite new to ode. but it took me half a day to write a
> program that will crash. you can find it under
>
http://ais.gmd.de/~verbeek/ode/
this is the test_buggy example modularised. for the buggy i made a class
RBuggy where i am deriving 13 objects from. when the buggys collide the
program crashes. when i do the same with 12 buggys, everthing is ok.
i tested it with ode-0.03 and the latest cvs-version under cygwin and
windowsXP. dont blame me, but linux does not support the graficsadapter
of my laptop. compiling this with linux works, but execution of the
program is really really slow.
i used gdb to find out, where the program crashes. i think it is
somewhere in the collision detection routines. at least these are called
right before the program crashes.
help needed, c.
--
-__________________________________________
Dr. rer. nat. Dipl.-Phys. C. Verbeek
email: christian.verbeek@ais.fraunhofer.de
room: C2-214
http://www.ais.fraunhofer.de/~verbeek
phone: +49 2241 14 2057
fax : +49 2241 14 2384
_______________________________________________
ODE mailing list
ODE@q12.org
http://q12.org/mailman/listinfo/ode
---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.410 / Virus Database: 231 - Release Date: 10/31/2002
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.410 / Virus Database: 231 - Release Date: 10/31/2002
From coding at natew.com Thu Nov 14 11:42:02 2002
From: coding at natew.com (Nate W)
Date: Thu Nov 14 11:42:02 2002
Subject: [ODE] test_buggy with 13 buggys
In-Reply-To: <3DD3E3E6.C600B51@ais.fraunhofer.de>
Message-ID:
On Thu, 14 Nov 2002, Christian Verbeek wrote:
> this is the test_buggy example modularised. for the buggy i made a class
> RBuggy where i am deriving 13 objects from. when the buggys collide the
> program crashes. when i do the same with 12 buggys, everthing is ok.
>
> i tested it with ode-0.03 and the latest cvs-version under cygwin and
> windowsXP.
Try doubling the size of the stack. There should be a linker option for
that. Windows doesn't grow the stack automatically, and ODE uses a lot of
stack for complex worlds.
--
Nate Waddoups
Redmond WA USA
http://www.natew.com
From christian.verbeek at ais.fraunhofer.de Fri Nov 15 03:35:02 2002
From: christian.verbeek at ais.fraunhofer.de (Christian Verbeek)
Date: Fri Nov 15 03:35:02 2002
Subject: [ODE] test_buggy with 13 buggys
References:
Message-ID: <3DD4CD9A.4BCA2A58@ais.fraunhofer.de>
i did not find out how to increase the stack size with cygwin. but i compiled
the program on linux and there it works. i tried 100 buggys. no crash, but
simulation goes very slow, when all 100 buggys collide. when are the first THz
processors coming out?
does anyone know how to increase the stack size under cygwin? something like
gcc -Wl,--stack,4096 does not help.
c.
Nate W wrote:
> On Thu, 14 Nov 2002, Christian Verbeek wrote:
>
> > this is the test_buggy example modularised. for the buggy i made a class
> > RBuggy where i am deriving 13 objects from. when the buggys collide the
> > program crashes. when i do the same with 12 buggys, everthing is ok.
> >
> > i tested it with ode-0.03 and the latest cvs-version under cygwin and
> > windowsXP.
>
> Try doubling the size of the stack. There should be a linker option for
> that. Windows doesn't grow the stack automatically, and ODE uses a lot of
> stack for complex worlds.
>
> --
>
> Nate Waddoups
> Redmond WA USA
> http://www.natew.com
>
> _______________________________________________
> ODE mailing list
> ODE@q12.org
> http://q12.org/mailman/listinfo/ode
--
-__________________________________________
Dr. rer. nat. Dipl.-Phys. C. Verbeek
email: christian.verbeek@ais.fraunhofer.de
room: C2-214
http://www.ais.fraunhofer.de/~verbeek
phone: +49 2241 14 2057
fax : +49 2241 14 2384
From hans at tat.physik.uni-tuebingen.de Fri Nov 15 06:30:02 2002
From: hans at tat.physik.uni-tuebingen.de (Torsten Hans)
Date: Fri Nov 15 06:30:02 2002
Subject: [ODE] what integration method is used ?
In-Reply-To: <200211151243.gAFCh2u15455@hook.org>
Message-ID:
hello,
i recently came across ode. its seems like an interesting
project. however i couldn't find out an important information:
what basic integration scheme does ODE use ? is it an
explicit or implicit integration method ? does it use
runge kutta or something else ?
is it possible to use a different integration scheme ?
any information would be appreciated.
kind regards,
torsten hans
From henri at cs.sun.ac.za Fri Nov 15 08:30:02 2002
From: henri at cs.sun.ac.za (Henri Hakl)
Date: Fri Nov 15 08:30:02 2002
Subject: [ODE] Lo/Hi Stops for ball-sockets?
Message-ID: <00ba01c28cbc$227f17d0$45d4e892@temple>
This is a multi-part message in MIME format.
------=_NextPart_000_00B7_01C28CCC.E600BBE0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi :)
I've played with the hinge-joint recently and figured out how to use lo =
and hi stops to limit rotations.
My problem now is to have a similar system for ball-socket joints. The =
idea is to have limited range of motions similar to (for example) the =
joint holding arm and shoulder together. It should have some degree of =
mobility to rotate around an arbitrary axis of motion, and it should be =
able to deviate from the initial axis of rotation to some degree.
Essentially it should be able to move inside a cone-of-freedom (plus it =
is only allowed to twist to a certain extend).
Help please.
Henri
------=_NextPart_000_00B7_01C28CCC.E600BBE0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi :)
I've played with the hinge-joint =
recently and=20
figured out how to use lo and hi stops to limit rotations.
My problem now is to have a similar =
system for=20
ball-socket joints. The idea is to have limited range of motions similar =
to (for=20
example) the joint holding arm and shoulder together. It should have =
some degree=20
of mobility to rotate around an arbitrary axis of motion, and it should =
be able=20
to deviate from the initial axis of rotation to some =
degree.
Essentially it should be able to move =
inside a=20
cone-of-freedom (plus it is only allowed to twist to a certain=20
extend).
Help please.
Henri
------=_NextPart_000_00B7_01C28CCC.E600BBE0--
From pete_graves at hotmail.com Fri Nov 15 14:21:01 2002
From: pete_graves at hotmail.com (Pete Graves)
Date: Fri Nov 15 14:21:01 2002
Subject: [ODE] Problems installing ODE 0.03
Message-ID:
I'm new to ODE, and inexperienced with C++ and the Microsoft Visual C/C++
6.0 IDE, so please bear with me.
I wanted to try out ODE and some of the test programs. I downloaded ODE
0.03, and followed the installation instructions in the User Guide.
I set MSVC's path variables during its installation, downloaded the GNU make
tool from the ODE web site, left the user-settings with PLATFORM=msvc and
PRECISION=DOUBLE, and ran make in the ODE directory.
This is some clips of the results:
...
ctest.c(1) : fatal error C1083: Cannot open include file: 'alloca.h': No
such file or directory
...
ctest.c(2) : error C2143: syntax error : missing ')' before ':'
ctest.c(2) : error C2059: syntax error : ')'
...
*** configurator succeeded ***
...
cl /nologo /DWIN32 /DMSVC /c /GR- /GX- /W3 /GF /Oy /Iinclude /DdNODEBUG /O2
/Fo
ode/src/array.obj ode/src/array.cpp
Command line warning D4002 : ignoring unknown option '/Oy' (this is shown
loads of times}
...
LIB : fatal error LNK1104: cannot open file "lib/ode.lib"
MAKE: *** [lib/ode.lib] Error 1104
I don't appear to have a lib/ directory at all. Am I missing something?
Could anyone suggest what I am doing wrong?
Thanks,
Pete.
_________________________________________________________________
Protect your PC - get McAfee.com VirusScan Online
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
From coding at natew.com Fri Nov 15 21:29:01 2002
From: coding at natew.com (Nate W)
Date: Fri Nov 15 21:29:01 2002
Subject: [ODE] Problems installing ODE 0.03
In-Reply-To:
Message-ID:
On Fri, 15 Nov 2002, Pete Graves wrote:
> ctest.c(1) : fatal error C1083: Cannot open include file: 'alloca.h': No
> such file or directory
Change that to "malloc.h" instead.
I'm not sure about the rest though.
--
Nate Waddoups
Redmond WA USA
http://www.natew.com
From pete_graves at hotmail.com Sat Nov 16 08:49:01 2002
From: pete_graves at hotmail.com (Pete Graves)
Date: Sat Nov 16 08:49:01 2002
Subject: [ODE] Re: Problems installing ODE 0.03
Message-ID:
The only file I can find that contains 'alloca.h' is 'configurator.c':
229: char *header[7] = {"stdio.h", "stdlib.h", "math.h", "string.h",
330: "stdarg.h", "malloc.h", "alloca.h"};
~~~~~~~~
Can I just remove this? 'malloc.h' is already there? Am I looking in the
right place?
_________________________________________________________________
The new MSN 8: smart spam protection and 2 months FREE*
http://join.msn.com/?page=features/junkmail
From martin at metahuman.org Sat Nov 16 09:06:01 2002
From: martin at metahuman.org (Martin C. Martin)
Date: Sat Nov 16 09:06:01 2002
Subject: [ODE] Re: Problems installing ODE 0.03
References:
Message-ID: <3DD66C9A.B8FA8884@metahuman.org>
You don't need to replace alloca with anything. What the configurator
does is see how your computer is set up by compiling a bunch of programs.
So the fact that some of them fail is normal. It said "configurator
succeeded" so you can ignore all messages above that.
Try making an empty "lib" directory. I think that's your only problem.
- Martin
Pete Graves wrote:
>
> The only file I can find that contains 'alloca.h' is 'configurator.c':
>
> 229: char *header[7] = {"stdio.h", "stdlib.h", "math.h", "string.h",
> 330: "stdarg.h", "malloc.h", "alloca.h"};
> ~~~~~~~~
>
> Can I just remove this? 'malloc.h' is already there? Am I looking in the
> right place?
>
> _________________________________________________________________
> The new MSN 8: smart spam protection and 2 months FREE*
> http://join.msn.com/?page=features/junkmail
>
> _______________________________________________
> ODE mailing list
> ODE@q12.org
> http://q12.org/mailman/listinfo/ode
From coding at natew.com Sat Nov 16 11:24:01 2002
From: coding at natew.com (Nate W)
Date: Sat Nov 16 11:24:01 2002
Subject: [ODE] Re: Problems installing ODE 0.03
In-Reply-To:
Message-ID:
On Sat, 16 Nov 2002, Pete Graves wrote:
> The only file I can find that contains 'alloca.h' is 'configurator.c':
>
> 229: char *header[7] = {"stdio.h", "stdlib.h", "math.h", "string.h",
> 330: "stdarg.h", "malloc.h", "alloca.h"};
>
> Can I just remove this? 'malloc.h' is already there? Am I looking in the
> right place?
When configurator gets run, it creates a header file called config.h.
Once I got a working config.h (I may have edited this file by hand, I
don't recall as it was quite a while ago), I took the configurator out of
my build process.
--
Nate Waddoups
Redmond WA USA
http://www.natew.com
From henri at cs.sun.ac.za Sat Nov 16 11:30:01 2002
From: henri at cs.sun.ac.za (Henri Hakl)
Date: Sat Nov 16 11:30:01 2002
Subject: [ODE] Lo/Hi Stops for ball-sockets?
References: <00ba01c28cbc$227f17d0$45d4e892@temple>
Message-ID: <004701c28d9e$70bd7990$45d4e892@temple>
This is a multi-part message in MIME format.
------=_NextPart_000_0044_01C28DAF.34418EA0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Anybody???
----- Original Message -----=20
From: Henri Hakl=20
To: ode@q12.org=20
Sent: Friday, November 15, 2002 5:31 PM
Subject: [ODE] Lo/Hi Stops for ball-sockets?
Hi :)
I've played with the hinge-joint recently and figured out how to use =
lo and hi stops to limit rotations.
My problem now is to have a similar system for ball-socket joints. The =
idea is to have limited range of motions similar to (for example) the =
joint holding arm and shoulder together. It should have some degree of =
mobility to rotate around an arbitrary axis of motion, and it should be =
able to deviate from the initial axis of rotation to some degree.
Essentially it should be able to move inside a cone-of-freedom (plus =
it is only allowed to twist to a certain extend).
Help please.
Henri
------=_NextPart_000_0044_01C28DAF.34418EA0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Anybody???
----- Original Message -----
From:=20
Henri =
Hakl=20
Sent: Friday, November 15, 2002 =
5:31=20
PM
Subject: [ODE] Lo/Hi Stops for=20
ball-sockets?
Hi :)
I've played with the hinge-joint =
recently and=20
figured out how to use lo and hi stops to limit =
rotations.
My problem now is to have a similar =
system for=20
ball-socket joints. The idea is to have limited range of motions =
similar to=20
(for example) the joint holding arm and shoulder together. It should =
have some=20
degree of mobility to rotate around an arbitrary axis of motion, and =
it should=20
be able to deviate from the initial axis of rotation to some=20
degree.
Essentially it should be able to move =
inside a=20
cone-of-freedom (plus it is only allowed to twist to a certain=20
extend).
Help please.
=20
Henri
------=_NextPart_000_0044_01C28DAF.34418EA0--
From coding at natew.com Sat Nov 16 11:46:01 2002
From: coding at natew.com (Nate W)
Date: Sat Nov 16 11:46:01 2002
Subject: [ODE] Lo/Hi Stops for ball-sockets?
In-Reply-To: <004701c28d9e$70bd7990$45d4e892@temple>
Message-ID:
On Sat, 16 Nov 2002, Henri Hakl wrote:
> Essentially it should be able to move inside a cone-of-freedom (plus
> it is only allowed to twist to a certain extend).
>
> Anybody???
Have you tried using an AMotor to set the limits? I haven't tried this
myself, but looking at 7.5.1. of the documentation it seem like it should
be possible to apply an AMotor to the two bodies and set limits using
dParamSetHiStopN where N is empty, 2 or 3 for each of the AMotor's axes.
Especially look at the last part of 7.5.1, below the table of parameters.
Like I said, I haven't tried it, but from a quick look at the docs I think
it might do what you want.
--
Nate Waddoups
Redmond WA USA
http://www.natew.com
From henri at cs.sun.ac.za Sat Nov 16 17:44:01 2002
From: henri at cs.sun.ac.za (Henri Hakl)
Date: Sat Nov 16 17:44:01 2002
Subject: [ODE] Lo/Hi Stops for ball-sockets?
References:
Message-ID: <006901c28dd2$ab7efcf0$45d4e892@temple>
hmmmm... thanks Nate... - it looks like something that might work. :)
It would help to see an example or something that uses the AMotorJoint
(prefably with limits and everything) - can anybody point me to some simple
program that makes use of it? None of the examples seem to make use of it
(I'm using the DelphiODE).
----- Original Message -----
From: "Nate W"
To:
Sent: Saturday, November 16, 2002 8:46 PM
Subject: Re: [ODE] Lo/Hi Stops for ball-sockets?
> On Sat, 16 Nov 2002, Henri Hakl wrote:
>
> > Essentially it should be able to move inside a cone-of-freedom (plus
> > it is only allowed to twist to a certain extend).
> >
> > Anybody???
>
> Have you tried using an AMotor to set the limits? I haven't tried this
> myself, but looking at 7.5.1. of the documentation it seem like it should
> be possible to apply an AMotor to the two bodies and set limits using
> dParamSetHiStopN where N is empty, 2 or 3 for each of the AMotor's axes.
> Especially look at the last part of 7.5.1, below the table of parameters.
>
> Like I said, I haven't tried it, but from a quick look at the docs I think
> it might do what you want.
>
> --
>
> Nate Waddoups
> Redmond WA USA
> http://www.natew.com
>
>
> _______________________________________________
> ODE mailing list
> ODE@q12.org
> http://q12.org/mailman/listinfo/ode
From mattias at cambrianlabs.com Sun Nov 17 03:44:01 2002
From: mattias at cambrianlabs.com (Mattias Fagerlund)
Date: Sun Nov 17 03:44:01 2002
Subject: [ODE] Lo/Hi Stops for ball-sockets?
In-Reply-To: <006901c28dd2$ab7efcf0$45d4e892@temple>
References: <006901c28dd2$ab7efcf0$45d4e892@temple>
Message-ID:
> It would help to see an example or something that uses the AMotorJoint
> (prefably with limits and everything) - can anybody point me to some
> simple
> program that makes use of it? None of the examples seem to make use of
> it (I'm using the DelphiODE).
I was going to say "I have some examples, but they're built using
delphi", but now that's not a problem;
// Create a AMotor
AMotor := dJointCreateAMotor(world, 0);
dJointAttach(AMotor, MainBody, UpperLeg);
BallLimit := pi*0.15;
dJointSetAMotorNumAxes (AMotor,2);
dJointSetAMotorAxis (AMotor, 0, 1, 1,0,0);
dJointSetAMotorAxis (AMotor, 1, 1, 0,0,1); // AUTO AXIS BY EULER MOTOR
dJointSetAMotorAxis (AMotor, 2, 2, 0,1,0);
dJointSetAMotorParam (AMotor, dParamLoStop, -BallLimit);
dJointSetAMotorParam (AMotor, dParamHiStop, BallLimit);
dJointSetAMotorParam (AMotor, dParamFudgeFactor, 0.01);//}
// This axis of the motor isn't used with EULER (?)
dJointSetAMotorParam (AMotor, dParamLoStop2, -0.01);
dJointSetAMotorParam (AMotor, dParamHiStop2, 0.01);
dJointSetAMotorParam (AMotor, dParamFudgeFactor2, 0.01);//}
dJointSetAMotorParam (AMotor, dParamLoStop3, -BallLimit);
dJointSetAMotorParam (AMotor, dParamHiStop3, BallLimit);
dJointSetAMotorParam (AMotor, dParamFudgeFactor3, 0.01);//}
dJointSetAMotorMode (AMotor, dAMotorEuler);
cheers,
m
From laury.michel at free.fr Sun Nov 17 17:42:02 2002
From: laury.michel at free.fr (Laury MICHEL)
Date: Sun Nov 17 17:42:02 2002
Subject: [ODE] Collision problem with geomGroups
Message-ID: <016c01c28e9b$5b79cfe0$9cdc933e@hal9000>
Hello!
I'm quite new to ODE, but I did a little "buggy-like" program that works!
The problem is that when I want to use a geomGroup for my buggy, it does not
collide with the "world geometry" anymore...
My "world geometry" consists of a large box with a smaller rotated box in
the middle playing the role of a ramp...
The buggy geometry is created in space 0 then added to a geomGroup wich is
created in the same space as the world geometry.
But, when running the program the buggy falls through the "world"!
Before, without geomGroups, it worked well beside the fact that I couldn't
put the vehicle wheels too close from the chassis as they collided resulting
in strange behavior as soon as the sim started...
I'm using ode v0.03, I've read the doc and I think I understood the part on
geomGroups so I don't see what I've missed :-(
Please help!
Here is part of the code I use:
void odeBox::InitOde(dWorldID _worldID, dSpaceID _spaceID, dReal _fMass)
{
m_bodyID = dBodyCreate(_worldID);
dBodySetPosition(m_bodyID, 0, 0, 0);
const dReal fDensity = 1.0f;
dMassSetBox(&m_mass, fDensity, m_fLength, m_fWidth, m_fHeight);
dMassAdjust (&m_mass, _fMass);
dBodySetMass(m_bodyID, &m_mass);
m_geomID = dCreateBox(_spaceID, m_fLength, m_fWidth, m_fHeight);
dGeomSetBody(m_geomID, m_bodyID);
}
void odeCar::CreateChassis(float _fWidth, float _fLength, float _fHeight)
{
m_geomGroupID = dCreateGeomGroup (m_spaceID);
m_pChassis = new odeBox;
dReal fMass = 10.0f;
((odeBox*) m_pChassis)->InitBox(_fWidth, _fLength, _fHeight);
m_pChassis->InitOde(m_worldID, 0, fMass); // 0 for space as it is added to a
geomGroup
m_pChassis->SetPosition(5,0,35);
dGeomGroupAdd (m_geomGroupID, m_pChassis->GetGeomID());
}
void odeWheel::InitOde(dWorldID _worldID, dSpaceID _spaceID, dReal _fMass)
{
m_bodyID = dBodyCreate(_worldID);
dBodySetPosition(m_bodyID, 0, 0, 0);
const dReal fDensity = 1.0f;
dMassSetSphere(&m_mass, fDensity, m_fRadius);
dMassAdjust (&m_mass, _fMass);
dBodySetMass(m_bodyID, &m_mass);
m_geomID = dCreateSphere(_spaceID, m_fRadius);
dGeomSetBody(m_geomID, m_bodyID);
}
void odeCar::AddWheel(dReal _posX, dReal _posY, dReal _posZ, float _fRadius,
float _fWidth)
{
// odeWheel
odeWheel* pWheel = new odeWheel;
pWheel->InitWheel(_fRadius, _fWidth);
pWheel->InitOde(m_worldID, 0, m_fDefaultWheelMass); // 0 for space as it is
added to a geomGroup
const dReal *a = dBodyGetPosition(m_pChassis->GetBodyID());
dBodySetPosition(pWheel->GetBodyID(), a[0] + _posX, a[1] + _posY, a[2] +
_posZ);
m_vpWheel.push_back(pWheel);
// Joint
dJointID jointID = dJointCreateHinge2(m_worldID, 0);
dJointAttach(jointID, m_pChassis->GetBodyID(), pWheel->GetBodyID());
dJointSetHinge2Anchor(jointID, a[0] + _posX, a[1] + _posY, a[2] + _posZ);
dJointSetHinge2Axis1(jointID, 0, 0, 1);
dJointSetHinge2Axis2(jointID, 1, 0, 0);
dJointSetHinge2Param(jointID, dParamSuspensionERP, 0.6f);
dJointSetHinge2Param(jointID, dParamSuspensionCFM, 0.08f);
dJointSetHinge2Param(jointID, dParamLoStop, 0);
dJointSetHinge2Param(jointID, dParamHiStop, 0);
m_vJoint.push_back(jointID);
m_vPowered.push_back(false);
m_vSteered.push_back(false);
dGeomGroupAdd (m_geomGroupID, pWheel->GetGeomID());
}
From Nguyen Binh Sun Nov 17 21:23:03 2002
From: Nguyen Binh (Nguyen Binh)
Date: Sun Nov 17 21:23:03 2002
Subject: [ODE] what integration method is used ?
In-Reply-To:
References:
Message-ID: <301716267.20021118105438@glassegg.com>
Hi ,
TH> what basic integration scheme does ODE use ? is it an
TH> explicit or implicit integration method ? does it use
TH> runge kutta or something else ?
Refer to the 0.3 docs, you'll see that ODE curently use basic Euler
integration.
TH> is it possible to use a different integration scheme ?
Sure, But maybe you'll have to do it yourself or waiting for future
ODE release.
--
Best regards,
---------------------------------------------------------------------
Nguyen Binh
Software Engineer
Glass Egg Digital Media
Me Linh Point Tower, 10th Floor
2 Ngo Duc Ke
District 1, Ho Chi Minh City
Vietnam
Fax: (84.8)823-8392
www.glassegg.com
---------------------------------------------------------------------
From franjesus at medtelecom.net Mon Nov 18 02:59:02 2002
From: franjesus at medtelecom.net (Francisco =?iso-8859-15?q?Jes=FAs=20Mart=EDnez=20Serrano?=)
Date: Mon Nov 18 02:59:02 2002
Subject: [ODE] Bug in documentation?
Message-ID: <200211181055.20531.franjesus@medtelecom.net>
In section 3.2 documentation states:
- Position of the center of mass with respect to the point of reference. In
the current implementation the center of mass and the point of reference must
coincide.
But later, in section 8.2:
void dMassTranslate (dMass *, dReal x, dReal y, dReal z);
Given mass parameters for some object, adjust them to represent the object
displaced by (x,y,z) relative to the body frame.
void dMassRotate (dMass *, const dMatrix3 R);
Given mass parameters for some object, adjust them to represent the object
rotated by R relative to the body frame.
So, can the center of mass be displaced wrt. the body frame or I'm missing
something?
--
"Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd
all be running around in darkened rooms, munching magic pills and listening
to repetitive electronic music."
- Kristian Wilson, Nintendo, Inc, 1989
From nlin at nlin.net Mon Nov 18 03:35:02 2002
From: nlin at nlin.net (nlin@nlin.net)
Date: Mon Nov 18 03:35:02 2002
Subject: [ODE] what integration method is used ?
Message-ID: <20021118120342.GA1863@nlin.net>
Nguyen Binh wrote:
> On Fri, Nov 15, 2002 at 02:28:59PM +0100, Torsten Hans wrote:
> TH> what basic integration scheme does ODE use ? is it an
> TH> explicit or implicit integration method ? does it use
> TH> runge kutta or something else ?
>
> Refer to the 0.3 docs, you'll see that ODE curently use basic Euler
> integration.
Not quite. Somewhere in the docs is mentioned that ODE uses a
_time_ _stepping_ Euler integration scheme. This is a bit more hairy
to extend to higher order schemes. For the gory details and some
links to research papers see the thread started in April 2002 at
http://q12.org/pipermail/ode/2002-April/001175.html
> TH> is it possible to use a different integration scheme ?
> Sure, But maybe you'll have to do it yourself or waiting for future
> ODE release.
A discussion on this topic in March 2002:
nlin> The problem with all of this ... is the interplay of all of this
nlin> with the time-stepping scheme.
russ>actually i'm not sure what a higher order time stepping scheme
russ>will look like in this case. i'd have to sit down and read some
russ>papers and write some equations. it's not a problem i have
russ>considered yet.
Don't let this stop you - I'd also be interested in seeing the performance
and accuracy of higher-order integration schemes with ODE - but be aware
that this isn't a completely trivial thing to do because of the time-stepping
(rather than instantaneous) view of the equations to be solved.
-Norman
From Dominique at SavageSoftware.com.au Mon Nov 18 03:49:02 2002
From: Dominique at SavageSoftware.com.au (Dominique Louis)
Date: Mon Nov 18 03:49:02 2002
Subject: [ODE] Rag Doll Demo?
Message-ID: <3DD8C604.8000203@SavageSoftware.com.au>
I was recently playing the Unreal Tournament demo and was impressed by
the rag doll physics they used, though it still did not look 100%
realistic. I beleive they used the MathEngine for their physics. It is
still a very cool game.
I was wondering if anyone has used ODE to create a rag doll type demo,
and also if anyone knows where I can get or find information on the UT
model format.
Thanks,
Dominique.
From mattias at cambrianlabs.com Mon Nov 18 03:56:02 2002
From: mattias at cambrianlabs.com (Mattias Fagerlund)
Date: Mon Nov 18 03:56:02 2002
Subject: [ODE] Rag Doll Demo?
In-Reply-To: <3DD8C604.8000203@SavageSoftware.com.au>
References: <3DD8C604.8000203@SavageSoftware.com.au>
Message-ID:
Have a look at this site; http://taat.fi/taat/porrasturvat/
cheers,
m
-----Original Message-----
From: Dominique Louis
To: ode@q12.org
Date: Mon, 18 Nov 2002 10:50:44 +0000
Subject: [ODE] Rag Doll Demo?
> I was recently playing the Unreal Tournament demo and was impressed by
> the rag doll physics they used, though it still did not look 100%
> realistic. I beleive they used the MathEngine for their physics. It is
> still a very cool game.
>
> I was wondering if anyone has used ODE to create a rag doll type demo,
> and also if anyone knows where I can get or find information on the UT
> model format.
>
> Thanks,
>
>
>
> Dominique.
>
> _______________________________________________
> ODE mailing list
> ODE@q12.org
> http://q12.org/mailman/listinfo/ode
From Dominique at SavageSoftware.com.au Mon Nov 18 05:22:02 2002
From: Dominique at SavageSoftware.com.au (Dominique Louis)
Date: Mon Nov 18 05:22:02 2002
Subject: [ODE] Rag Doll Demo?
References: <3DD8C604.8000203@SavageSoftware.com.au>
Message-ID: <3DD8DBE5.4040506@SavageSoftware.com.au>
That is an excellent demo!
Will a similar type demo be included as part of the "standard" demos
that ship with ODE?
Thanks again,
Dominique.
Mattias Fagerlund wrote:
> Have a look at this site; http://taat.fi/taat/porrasturvat/
>
> cheers,
> m
>
> -----Original Message-----
> From: Dominique Louis
> To: ode@q12.org
> Date: Mon, 18 Nov 2002 10:50:44 +0000
> Subject: [ODE] Rag Doll Demo?
>
>
>>I was recently playing the Unreal Tournament demo and was impressed by
>>the rag doll physics they used, though it still did not look 100%
>>realistic. I beleive they used the MathEngine for their physics. It is
>>still a very cool game.
>>
>>I was wondering if anyone has used ODE to create a rag doll type demo,
>>and also if anyone knows where I can get or find information on the UT
>>model format.
>>
>>Thanks,
>>
>>
>>
>>Dominique.
>>
>>_______________________________________________
>>ODE mailing list
>>ODE@q12.org
>>http://q12.org/mailman/listinfo/ode
>
>
>
From anselm at hook.org Mon Nov 18 12:06:02 2002
From: anselm at hook.org (Anselm Hook)
Date: Mon Nov 18 12:06:02 2002
Subject: [ODE] ode networking code snippet
In-Reply-To: <301716267.20021118105438@glassegg.com>
Message-ID:
Here's a small hack to network a couple of ODE cars together. I had a
couple of hours and I was thinking about a comment somebody asked earlier
- so I threw this together... I'll probably improve it later since it is
really crude right now.
It really just hammers on objects positions and it doesn't network all of
the state of each object so it doesn't look very good - although this
could be improved. The networking layer itself might be useful as a
test-bench for people to explore other more effacious networking
strategies.
The theory is that even if object physics state is hammered on, one will
still get the appearance of reasonably believable physical interaction
simply because of the way each machine will simulate forward the whole
system. But in practice since not all state is networked properly, the
first pass at least looks pretty poor - however I do think the theory is
still sound.
If this theory doesn't pan out then (if I have time) I may modify the code
to try out a variety of other approaches. For example the simplest
approach is simply to integrate everything on the server.
To build it replace the test_buggy.cpp code with the below, and compile
ODE as usual under cygwin. It doesn't build under msvc because I haven't
bothered fully implementing the berkeley sockets for msvc.
To run a server type:
test_buggy
To run a client type:
test_buggy be a client
It networks on 127.0.0.1:8000 so you can run multiple instances on one
machine to fiddle with it...
BTW I *really* like the geomgroups stuff now... way better!
Have fun!
- a
/*
"bangup" - a small testbed for ode networking.
The code is broken up into a number of pieces,
1) NetSocket - a network abstraction layer (runs under cygwin only
- not ported to windows)
2) SimObject - a generic type of simulation object
3) Dynamics - the basic ODE dynamics (world, space, ground )
4) Car - a car
5) Main - handles network traffic and overall event stuff
In general the networking scheme here is:
1) There is a server and a number of clients.
2) A server is similar to a client in that it also has a window
and a pov
3) Each machine is locally authoritative for some objects
4) Other objects on a machine are considered to be driven by some
remote authority
5) In the tests so far the clients are authoritative for the local
participants pov.
6) In the tests so far the server is authoritative for its pov
7) The clients and server echo to each other any state that they
are authoritative for.
8) The server additionally re-echoes out all state so that other
clients can be advised of changes.
9) Rather than publishing a database on new client connections;
clients dynamically create missing objects.
This is extremely crude... and one will see that it does not behave well.
Not much state is networked so things
tend to jump around and misbehave terribly. It may improve over time.
*/
/**************************************************************/
// network stuff
/**************************************************************/
//#if defined( WIN32 ) || defined( __CYGWIN32__ )
//#include
//#else
#include
#include
#include
#include
#define _USE_BSD
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
typedef int SOCKET;
//#endif
#include
class NetSocket {
public:
struct sockaddr_in sa;
struct hostent *hp;
SOCKET sock;
FILE* sockin;
FILE* sockout;
NetSocket* next;
#define MAXHOSTNAME 64
char myname[MAXHOSTNAME+1];
int isserver;
int key;
void error_fail(char* str,...) { puts(str); }
void init() {
isserver = 0;
sock = 0;
next = 0;
sockin = 0;
sockout = 0;
myname[0] = 0;
key = 0;
}
NetSocket() {
init();
}
NetSocket(SOCKET _s) {
init();
attach(_s);
}
~NetSocket() {
disconnect();
// xxx remove from list
}
void attach(SOCKET _s) {
sock = _s;
int opts = fcntl(sock,F_GETFL);
opts = opts | O_NONBLOCK;
fcntl(sock,F_SETFL,opts);
sockin = fdopen(sock,"r");
sockout = fdopen(sock,"w");
}
void disconnect() {
if( sockout ) {
fflush(sockout);
fclose(sockout);
sockout = 0;
}
if( sockin ) {
fclose(sockin);
sockin = 0;
}
if( sock ) {
#ifdef USEWIN32
closesocket(sock);
#else
close(sock);
#endif
sock = 0;
}
}
bool serve(int portnum = 8700 ) {
isserver = 1;
#ifdef USEWIN32
WSAData ws;
if( WSAStartup(0x0101,&ws) < 0 ) {
error_fail("TcpServer: tcp does not seem to be
supported");
return 0;
}
#endif
struct protoent *tcp_prot = getprotobyname("tcp");
if(!tcp_prot) {
error_fail("TcpServer: tcp does not seem to be
supported");
return 0;
}
sock = socket(AF_INET,SOCK_STREAM,tcp_prot->p_proto);
if( sock < 0 ) {
error_fail(" can't make server socket: %s",
strerror(errno));
return 0;
}
int one = 1;
if (setsockopt(sock, SOL_SOCKET, SO_REUSEADDR, (char *)
&one, sizeof(int)) < 0) {
error_fail("failed on setsockopt(): %s",
strerror(errno));
return 0;
}
gethostname(myname, MAXHOSTNAME);
if ((hp= gethostbyname(myname)) == NULL) {
disconnect();
return 0;
}
memset(&sa, 0, sizeof(struct sockaddr_in));
sa.sin_family= hp->h_addrtype;
sa.sin_port= htons(portnum);
sa.sin_family = AF_INET;
sa.sin_addr.s_addr = htonl(INADDR_ANY);
if( bind(sock,(struct sockaddr *)&sa,sizeof(sa)) == -1 ) {
error_fail("server count not bind");
disconnect();
return 0;
}
#ifdef USEWIN32
WSAAsyncSelect(sock,GetForegroundWindow(),WM_USER+1,FD_ACCEPT | FD_CLOSE |
FD_READ | FD_WRITE );
#endif
if( listen(sock,100) < 0 ) {
disconnect();
return 0;
}
return 1;
}
void update() {
if( !isserver ) {
return;
}
if( !sock ) {
return;
}
timeval tv; tv.tv_sec = 0; tv.tv_usec = 10;
fd_set readmask,writemask,exceptmask;
FD_ZERO( &readmask );
FD_ZERO( &writemask );
FD_ZERO( &exceptmask );
FD_SET( sock, &readmask );
int results = select( FD_SETSIZE, &readmask, &writemask,
&exceptmask, &tv );
if( !results ) {
return;
}
int conn;
if( (conn = accept(sock,NULL,NULL)) < 0 ) {
printf("failed conn\n");
return;
}
printf("new conn\n");
NetSocket* cl = new NetSocket( conn );
cl->next = next;
next = cl;
}
void client(const char* hostname = "localhost", unsigned short
portnum = 8700 ) {
isserver = 0;
if ((hp= gethostbyname(hostname)) == NULL) {
return;
}
printf("got localhost\n");
memset(&sa, 0, sizeof(struct sockaddr_in));
memcpy((char *)&sa.sin_addr,hp->h_addr,hp->h_length);
sa.sin_family= hp->h_addrtype;
sa.sin_port= htons((u_short)portnum);
if ((sock= socket(hp->h_addrtype,SOCK_STREAM,0)) < 0) {
return;
}
if (connect(sock,(struct sockaddr *)&sa,sizeof sa) < 0) {
disconnect();
return;
}
attach( sock );
printf("conned %x,%x,%x\n",sock,(int)sockin,(int)sockout);
}
void publish(char* str) {
if( sockout ) {
fputs(str,sockout);
fflush(sockout);
}
}
};
#if 0
/*
// some inactivated code - idea here was to run 2 sims, one at
present moment, and one in past that is synced.
// but i am concerned that ode is not deterministic between
machines; there might be strange rounding errors.
// non deterministic input event structure
class ndi_event {
public:
struct ndi_event* next;
struct ndi_event* prev;
time_t timenow;
int key;
int cmd;
ndi_event( int key, int cmd) {
next = prev = 0;
time(&timenow);
this->key = key;
this->cmd = cmd;
}
};
// data structures
static ndi_event* ndi_head = 0;
static ndi_event* ndi_tail = 0;
// insert event into temporally sorted queue
void ndi_hold_event(ndi_event* event) {
event->next = event->prev = 0;
for( ndi_event* cursor = ndi_tail ; cursor ;
cursor = cursor->prev ) {
if( cursor->time < event->time ) {
event->next = cursor->next;
event->prev = cursor;
if( cursor->next )
cursor->next->prev = event;
cursor->next = event;
return;
}
}
event->next = ndi_head;
ndi_head = event;
}
void system_command( int key, int cmd );
// do all events up to the current time
void ndi_advance(int current_time) {
for( ndi_event* cursor = ndi_head ; cursor ; ) {
if( cursor->time > current_time ) {
return;
}
ndi_head = cursor->next;
system_command(cursor->key, cursor->cmd );
cursor = cursor->next
free cursor->prev;
}
}
void network_publish_event(int key, int cmd) {
// ndi_hold_event( new ndi_event(key,cmd) );
// - send over net now also - except maybe updates
// for updates we want to do this general
bookkeeping
// accept new pending connections and fire
off a copy of my objects once only as well as pending state
// get current time
// ndi_advance( to current time - 1 );
// and do a local command update too... or
heart beated
}
*/
#endif
/**********************************************************************/
// game stuff
/**********************************************************************/
#ifdef USE_WIN32
#define __USE_W32_SOCKETS 1
#include
#include
#ifdef MSVC
#pragma warning(disable:4244 4305) // for VC++, no precision loss
complaints
#endif
#endif
#include
#include
// select correct drawing functions
#ifdef dDOUBLE
#define dsDrawBox dsDrawBoxD
#define dsDrawSphere dsDrawSphereD
#define dsDrawCylinder dsDrawCylinderD
#define dsDrawCappedCylinder dsDrawCappedCylinderD
#endif
/**********************************************************************/
// simobject - game object management
/**********************************************************************/
class SimObject {
public:
SimObject* next;
int key;
static class SimObject* objects;
SimObject() {
next = objects; objects = this;
}
virtual ~SimObject() {
for(SimObject** obj = &objects; *obj; obj =
&((*obj)->next)) {
if( *obj == this ) {
*obj = (*obj)->next;
break;
}
}
}
virtual void draw() {}
virtual void update() {}
virtual void command(char *cmd) {}
};
SimObject* SimObject::objects = 0;
/**********************************************************************/
// a dynamics object
/**********************************************************************/
class Dynamics {
public:
dWorldID world;
dSpaceID space;
dGeomID ground;
dJointGroupID contactgroup;
Dynamics* next;
// this is called by dSpaceCollide when two objects in space are
potentially colliding.
void nearCallback2 (void *data, dGeomID o1, dGeomID o2) {
int i,n;
const int N = 10;
dContact contact[N];
n = dCollide (o1,o2,N,&contact[0].geom,sizeof(dContact));
if (n > 0) {
for (i=0; inearCallback2(0,o1,o2);
}
Dynamics() {
world = dWorldCreate();
space = dHashSpaceCreate();
contactgroup = dJointGroupCreate (0);
dWorldSetGravity (world,0,0,-0.5);
ground = dCreatePlane (space,0,0,1,0);
}
void draw() {}
void update() {
dSpaceCollide (space,this,&nearCallback);
dWorldStep (world,0.05);
dJointGroupEmpty (contactgroup);
}
void command(char* cmd) {}
~Dynamics() {
dJointGroupDestroy (contactgroup);
dSpaceDestroy (space);
dWorldDestroy (world);
}
};
/**********************************************************************/
// a car
/**********************************************************************/
class Car: public SimObject {
public:
// some constants
#define LENGTH 0.7 // chassis length
#define WIDTH 0.5 // chassis width
#define HEIGHT 0.2 // chassis height
#define RADIUS 0.18 // wheel radius
#define STARTZ 0.5 // starting height of chassis
#define CMASS 1 // chassis mass
#define WMASS 0.2 // wheel mass
// dynamics and collision objects (chassis, 3 wheels )
dBodyID body[4];
dJointID joint[3]; // joint[0] is the front wheel
dGeomID geom_group;
dGeomID box[1];
dGeomID sphere[3];
double speed,steer;
Dynamics* parent;
Car(Dynamics* parent, dReal x, dReal y, dReal z);
virtual ~Car();
virtual void update();
virtual void draw();
virtual void command(char *);
};
Car::Car(Dynamics* parent, dReal x, dReal y, dReal z): SimObject() {
this->parent = parent;
int i;
dMass m;
// chassis body
body[0] = dBodyCreate (parent->world);
dBodySetPosition (body[0],x+0,y+0,z+STARTZ);
dMassSetBox (&m,1,LENGTH,WIDTH,HEIGHT);
dMassAdjust (&m,CMASS);
dBodySetMass (body[0],&m);
box[0] = dCreateBox (0,LENGTH,WIDTH,HEIGHT);
dGeomSetBody (box[0],body[0]);
// wheel bodies
for (i=1; i<=3; i++) {
body[i] = dBodyCreate ( parent->world);
dQuaternion q;
dQFromAxisAndAngle (q,1,0,0,M_PI*0.5);
dBodySetQuaternion (body[i],q);
dMassSetSphere (&m,1,RADIUS);
dMassAdjust (&m,WMASS);
dBodySetMass (body[i],&m);
sphere[i-1] = dCreateSphere (0,RADIUS);
dGeomSetBody (sphere[i-1],body[i]);
}
dBodySetPosition (body[1],x+ 0.5*LENGTH,y+ 0,z + STARTZ-HEIGHT*0.5);
dBodySetPosition (body[2],x+ -0.5*LENGTH,y+ WIDTH*0.5,z +
STARTZ-HEIGHT*0.5);
dBodySetPosition (body[3],x+ -0.5*LENGTH,y+ -WIDTH*0.5,z +
STARTZ-HEIGHT*0.5);
// front and back wheel hinges
for (i=0; i<3; i++) {
joint[i] = dJointCreateHinge2 (parent->world,0);
dJointAttach (joint[i],body[0],body[i+1]);
const dReal *a = dBodyGetPosition (body[i+1]);
dJointSetHinge2Anchor (joint[i],a[0],a[1],a[2]);
dJointSetHinge2Axis1 (joint[i],0,0,1);
dJointSetHinge2Axis2 (joint[i],0,1,0);
}
// set joint suspension
for (i=0; i<3; i++) {
dJointSetHinge2Param (joint[i],dParamSuspensionERP,0.4);
dJointSetHinge2Param (joint[i],dParamSuspensionCFM,0.8);
}
// lock back wheels along the steering axis
for (i=1; i<3; i++) {
// set stops to make sure wheels always stay in alignment
dJointSetHinge2Param (joint[i],dParamLoStop,0);
dJointSetHinge2Param (joint[i],dParamHiStop,0);
// the following alternative method is no good as the wheels may get
out
// of alignment:
// dJointSetHinge2Param (joint[i],dParamVel,0);
// dJointSetHinge2Param (joint[i],dParamFMax,dInfinity);
}
// create geometry group and add it to the space
geom_group = dCreateGeomGroup ( parent->space );
dGeomGroupAdd (geom_group,box[0]);
dGeomGroupAdd (geom_group,sphere[0]);
dGeomGroupAdd (geom_group,sphere[1]);
dGeomGroupAdd (geom_group,sphere[2]);
speed = 0;
steer = 0;
}
Car::~Car() {
// destroy body xxx
dGeomDestroy (box[0]);
dGeomDestroy (sphere[0]);
dGeomDestroy (sphere[1]);
dGeomDestroy (sphere[2]);
}
void Car::update() {
// motor
dJointSetHinge2Param (joint[0],dParamVel2,-speed);
dJointSetHinge2Param (joint[0],dParamFMax2,0.1);
// steering
dReal v = steer - dJointGetHinge2Angle1 (joint[0]);
if (v > 0.1) v = 0.1;
if (v < -0.1) v = -0.1;
v *= 10.0;
dJointSetHinge2Param (joint[0],dParamVel,v);
dJointSetHinge2Param (joint[0],dParamFMax,0.2);
dJointSetHinge2Param (joint[0],dParamLoStop,-0.75);
dJointSetHinge2Param (joint[0],dParamHiStop,0.75);
dJointSetHinge2Param (joint[0],dParamFudgeFactor,0.1);
}
void Car::draw() {
dsSetColor (0,1,1);
dsSetTexture (DS_WOOD);
dReal sides[3] = {LENGTH,WIDTH,HEIGHT};
dsDrawBox (dBodyGetPosition(body[0]),dBodyGetRotation(body[0]),sides);
dsSetColor (1,1,1);
int i;
for (i=1; i<=3; i++) dsDrawCylinder
(dBodyGetPosition(body[i]),dBodyGetRotation(body[i]),0.02f,RADIUS);
}
void Car::command(char* command) {
int cmd;
float x,y,z;
sscanf(command,"%d %f %f %f",&cmd,&x,&y,&z);
switch( cmd ) {
case 'a': case 'A':
speed += 0.3;
break;
case 'z': case 'Z':
speed -= 0.3;
break;
case ',':
steer -= 0.5;
break;
case '.':
steer += 0.5;
break;
case ' ':
speed = 0.0;
steer = 0.0;
default:
break;
}
}
/**************************************************************************************/
// main
/**************************************************************************************/
static NetSocket network;
static Dynamics* dynamics;
static int local_sim_key_code = 0x00010000;
static int remote_machine_code = 0x00010000;
static void network_command(NetSocket* s,char* buffer) {
if(!strncmp(buffer,"login",5)) {
// remote has logged into me; accept their login
printf("got login\n");
remote_machine_code += 0x00010000;
if( s ) {
fprintf(s->sockout,"id %x\n",remote_machine_code);
// tell client to make an obj
fprintf(s->sockout,"new %x %d %f %f
%f\n",remote_machine_code + 1, 0, 0.0f,0.0f,0.0f);
fflush(s->sockout);
s->key = remote_machine_code;
}
}
else if(!strncmp(buffer,"id",2)) {
// remote sent us our own unique id
sscanf(buffer+2,"%x",&local_sim_key_code);
printf("local is is now %x\n",local_sim_key_code);
remote_machine_code = local_sim_key_code;
}
else if(!strncmp(buffer,"new",3)) {
// remote has asked us to make something at location xyz
int id,type;
float x,y,z;
sscanf(buffer+3,"%x %d %f %f %f",&id,&type,&x,&y,&z);
printf("got new request:
0x%x,%d,%f,%f,%f\n",id,type,x,y,z);
Car* car = new Car(dynamics,x,y,z);
car->key = id;
}
else if(!strncmp(buffer,"update",3)) {
int key;
float x,y,z;
float rotf[12];
double rot[12];
sscanf(buffer+6,"%x %f %f %f\n",&key,&x,&y,&z);
sscanf(buffer+6,"%x %f %f %f %f %f %f %f %f %f %f %f %f %f
%f %f\n",
&key,&x,&y,&z,
&rotf[0],&rotf[1],&rotf[2],&rotf[3],
&rotf[4],&rotf[5],&rotf[6],&rotf[7],
&rotf[8],&rotf[9],&rotf[10],&rotf[11]
);
rot[0] = rotf[0]; rot[1] = rotf[1];
rot[2] = rotf[2]; rot[3] = rotf[3];
rot[4] = rotf[4]; rot[5] = rotf[5];
rot[6] = rotf[6]; rot[7] = rotf[7];
rot[8] = rotf[8]; rot[9] = rotf[9];
rot[10] = rotf[10]; rot[11] = rotf[11];
for(SimObject* obj = SimObject::objects; obj; obj =
obj->next ) {
if( obj->key == key ) {
Car* car = (Car*)obj;
dBodySetPosition( car->body[0],x,y,z);
dBodySetRotation( car->body[0], rot );
return;
}
}
// if not found then add
Car* car = new Car(dynamics,x,y,z);
car->key = key;
}
}
static void network_input_events() {
// handle incoming traffic from any port
for(NetSocket* s = &network; s ; s = s->next ) {
if(! s->sockin ) continue;
char buffer[2048];
while( fgets(buffer,2040,s->sockin) ) {
network_command(s,buffer);
}
}
}
static void network_output_events() {
// for all machines that have observers here, tell them about all
objects we are responsible for
static int counter = 0;
if( counter++ < 16 ) {
return;
}
counter = 0;
for(NetSocket* s = &network; s ; s = s->next ) {
if( !s->sockout ) continue;
for(SimObject* obj = SimObject::objects; obj; obj =
obj->next ) {
if(network.sockout) {
// if we are a client then emit
information about our objects only - else emit all
if( (obj->key & 0xffff0000) !=
(local_sim_key_code & 0xffff0000) ) {
continue;
}
} else {
// if we are a server - emit all objects
to all machines except real owners
if( (obj->key & 0xffff0000) == ( s->key &
0xffff0000) ) {
continue;
}
}
Car* car = (Car*)obj;
const dReal* pos = dBodyGetPosition( car->body[0]
);
const dReal* rot = dBodyGetRotation( car->body[0]
);
float x = pos[0]; float y = pos[1]; float z =
pos[2];
fprintf(s->sockout,"update %x %f %f %f %f %f %f %f
%f %f %f %f %f %f %f %f\n",
obj->key,x,y,z,
(float)rot[0],(float)rot[1],(float)rot[2],(float)rot[3],
(float)rot[4],(float)rot[5],(float)rot[6],(float)rot[7],
(float)rot[8],(float)rot[9],(float)rot[10],(float)rot[11]
);
fflush(s->sockout);
}
}
}
static void mainLoop (int pause) {
// for server only - look for new socket connections
network.update();
// for servers and clients - deal with any remote commands
network_input_events();
// for servers and clients - emit anything anybody else might be
interested in
network_output_events();
// update... could be done before outputting state
for(SimObject* obj = SimObject::objects; obj; obj = obj->next ) {
obj->update();
}
if( dynamics ) {
dynamics->update();
}
// redraw... best done after updating state
for(SimObject* obj = SimObject::objects; obj; obj = obj->next ) {
obj->draw();
}
}
void key_events(int cmd ) {
switch(cmd) {
default:
int key = ( local_sim_key_code & 0xffff0000 ) + 1;
for(SimObject* obj = SimObject::objects; obj; obj =
obj->next ) {
printf("%x %x\n",obj->key,key);
if( obj->key == key ) {
char buffer[512];
sprintf(buffer,"%d 0 0 0\n",cmd);
obj->command(buffer);
return;
}
}
}
}
void start() {
printf ("Press:\t'a' to increase speed.\n"
"\t'z' to decrease speed.\n"
"\t',' to steer left.\n"
"\t'.' to steer right.\n"
"\t' ' to reset speed and steering.\n");
// move camera somewhere useful
{
//const dReal* pos = dBodyGetPosition(body[0]);
float pos[3] = { 3,-3,2 };
// xxx move viewpoint behind car - xxx wrong - do
dynamically
static float xyz[3] = {0.8317f,-0.9817f,0.8000f};
static float hpr[3] = {121.0000f,-27.5000f,0.0000f};
xyz[0] = pos[0] + 0.8317f;
xyz[1] = pos[1] - 0.9817f;
xyz[2] = pos[2] + 0.8000f;
dsSetViewpoint (xyz,hpr);
}
}
int main (int argc, char **argv) {
dynamics = new Dynamics();
if( argc < 2 ) {
// be a server - server will always start up one dynamics
engine and always add one car to kickstart itself.
printf("server\n");
network.serve();
network_command(0,"id 0x00010000\n");
// server id
network_command(0,"new 0x00010001 0 2.0 0 0\n"); //
server car location
}
else {
// be a client - client explicitly logs in and waits for
reply with an id before doing anything
network.client();
if( network.sockout ) {
network.publish("login joe\n");
printf("client: network up - logging in\n");
} else {
printf("client: no network :-(\n");
}
}
// setup pointers to drawstuff callback functions and run forever
dsFunctions fn;
fn.version = DS_VERSION;
fn.start = &start;
fn.step = &mainLoop;
fn.command = &key_events;
fn.stop = 0;
fn.path_to_textures = "../../drawstuff/textures";
dsSimulationLoop (0,0,352,288,&fn);
// exit...
network.disconnect();
}
From ccos at bigpond.com Tue Nov 19 01:07:01 2002
From: ccos at bigpond.com (ccos)
Date: Tue Nov 19 01:07:01 2002
Subject: [ODE] os x compile probs
Message-ID: <6FC6A94D-FB95-11D6-9679-000393722276@bigpond.com>
hello everybody,
i'm trying to build ode on os x 10.1.5 and this is what i'm doing (from
the docs):
> Step 1: Unpack the ODE archive.
done
> Step 2: Get the GNU make tool. Many Unix platforms come with this,
> although sometimes it is called gmake. I have provided a version of GNU
> make for windows here.
done, ( default os x make )
> Step 3: Edit the settings in the file config/user-settings. The list of
> supported platforms is given in that file.
done, set it to osx
> Step 4: Run make to configure and build ODE and the graphical test
> programs.
> Be sure you are using the correct version of GNU make.
which is the correct version?
> The make targets for building the parts of ODE are:
> * make configure : Create the configuration file include/ode/config.h.
i get: *** configurator succeeded ***
> * make ode-lib : Build the core ODE library.
seems to work
these are all i can make because i don't have X11, but i don't really
need to run
the drawing library, so i should be fine right?
> Step 5: To install the ODE library onto your system you should copy the
> lib/ and include/ directories to a suitable place, e.g. on Unix:
>
> * include/ode/ --> /usr/local/include/ode/
> * lib/libode.a --> /usr/local/lib/libode.a
done
ok, so everything seems alright, but when i try to compile with #include
i get:
/usr/bin/ld: archive: /usr/local/lib/libode.a has no table of contents,
add one with ranlib(1) (can't load from it)
hints very well appreciated.
has anybody here built ode on os x?
thanks much,
c
From nnevatie at welho.com Tue Nov 19 10:31:02 2002
From: nnevatie at welho.com (Niko Nevatie)
Date: Tue Nov 19 10:31:02 2002
Subject: [ODE] Step size vs. frame rate + building ODE
Message-ID: <000b01c28ff1$62b90c60$3abdf3d5@wli>
I read in the ODE documentation that "10*0.1 not the same as 5*0.2". So, my
guestion is, can I use frame processing time to scale the step? E.g.:
dWorldStep(dWorldID, 0.05 * scaler);
where scaler is somehow dependent of the frame processing time
BTW, I was able to build ODE with Borland C++ Builder 6.0 Pro (+ CVS
Tricollider & Opcode 1.2).
One thing is still not clear to me: Which one is the newer version of
tricollider - Erwin's base64 patch ('newstuff.gz') or the version in CVS?
I wasn't able to build the contents of 'newstuff.gz', a function in dRay.cpp
used Matrix3 and caused some access violations by accessing element at [3 *
4 + 2] (Matrix3 seems to have 4x3 elements).
--
Niko
From franjesus at medtelecom.net Tue Nov 19 16:06:01 2002
From: franjesus at medtelecom.net (Francisco =?iso-8859-1?q?Jes=FAs=20Mart=EDnez=20Serrano?=)
Date: Tue Nov 19 16:06:01 2002
Subject: [ODE] os x compile probs
Message-ID: <200211200001.37100.franjesus@medtelecom.net>
El Mar 19 Nov 2002 09:03, ccos escribió:
> hints very well appreciated.
> has anybody here built ode on os x?
try running ldconfig
I believe OSX uses libtool, so you need to run ldconfig each time you add
libraries to your system.
--
Tienes mal la zona, sin embargo te marca bien la hora local, ergo tienes
mal ambas.
.: Bulmailing :.
From coding at natew.com Tue Nov 19 22:48:01 2002
From: coding at natew.com (Nate W)
Date: Tue Nov 19 22:48:01 2002
Subject: [ODE] Step size vs. frame rate + building ODE
In-Reply-To: <000b01c28ff1$62b90c60$3abdf3d5@wli>
Message-ID:
On Tue, 19 Nov 2002, Niko Nevatie wrote:
> Can I use frame processing time to scale the step? E.g.:
>
> dWorldStep(dWorldID, 0.05 * scaler);
>
> where scaler is somehow dependent of the frame processing time
That's what I do in Juice, and I'm happy with the results. I also clamp
the 'frame time' to within a minimum and maximum range, to avoid getting
instabilities with large frame times or divide-by-zero with a zero frame
time. If you check the archives, I wrote something a while back that goes
into more detail.
I like the variable time step approach for my app so far. Theoretically
there are some potential problems with variable time steps, but in
practice I'm happy with the way things work in Juice.
If repeatability or consistency across network machines is important, you
might want to use fixed time steps.
--
Nate Waddoups
Redmond WA USA
http://www.natew.com
From thomas_buehrmann at web.de Wed Nov 20 06:55:02 2002
From: thomas_buehrmann at web.de (Thomas Buehmann)
Date: Wed Nov 20 06:55:02 2002
Subject: [ODE] dRay, c++ interface, khepera model?
Message-ID: <200211201354.gAKDs3X30804@mailgate5.cinetic.de>
hi,
is it possible to get the c++ interface by martin c. martin and the dRay
contribution without having to use cvs or copy and paste?
apart from that, is anyone aware of a good khepera-style two-wheeled
differential-steering model? if i use two wheels in front of my vehicle to drive
and steer and an additional supporting wheel in the back, the latter tends to
bend if the distance between front-wheels and supporting wheel is small (all use
hinge2). is that model too simple or is it just a matter of tweaking cfm etc...?
thanks,
thomas.
sorry if this mail got posted twice. i send it earlier from an unlisted address.
______________________________________________________________________________
Der Anrufbeantworter für Ihre E-Mail-Korrespondenz - WEB.DE FreeMail
http://freemail.web.de/features/?mc=021137
From anselm at hook.org Wed Nov 20 14:12:02 2002
From: anselm at hook.org (Anselm Hook)
Date: Wed Nov 20 14:12:02 2002
Subject: [ODE] dRay, c++ interface, khepera model?
In-Reply-To: <200211201354.gAKDs3X30804@mailgate5.cinetic.de>
Message-ID:
> hi,
> is it possible to get the c++ interface by martin c. martin and the dRay
> contribution without having to use cvs or copy and paste?
http://q12.org/cgi-bin/cvsweb.cgi/ode/
From henri at cs.sun.ac.za Thu Nov 21 02:48:02 2002
From: henri at cs.sun.ac.za (Henri Hakl)
Date: Thu Nov 21 02:48:02 2002
Subject: [ODE] Faster ODE
Message-ID: <021b01c29143$46622a30$45d4e892@temple>
This is a multi-part message in MIME format.
------=_NextPart_000_0218_01C29154.09E63F40
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi ODE :)
Please can somebody look at this and experiment with the file?
LDLT decomposition is one of the primary computational activities in =
ODE's physics engine. LDLT =3D Lower Diagonal Lower Transposed, meaning =
a constraint matrix A (that describes the physics of a world) can be =
decomposed into two matrices (L and D, where L is a lower triangular =
matrix (all entries above the diagonal are zero) and D is a diagonal =
matrix (all entries except the diagonal are zero)). Now A =3D L D L' =
(A equals the lower matrix times the diagonal matrix times the =
transposed lower matrix.) The A matrix varies in size and is typically =
between 10x10 and 500x500 for ODE (depending on
how many constraints/collisions/etc need to be solved for a given =
simulation step).
This LDLT decomposition needs to be solved with every step and is quite =
computationally intensive. I've looked at the stldlt.c file that is part =
of the ODE source and it looks to me like it could be improved upon. =
Unforetunately I use Delphi, so I cannot test my suggested modifications =
directly (though the Delphi version seems fine and considerably faster =
then the original).
The file http://www.cs.sun.ac.za/~henri/fastldlt_henri.c is a =
replacement for fastldlt.c and should (barring errors) work flawlessly =
and faster then the original.
Let me know if it works, thanks :)
Henri
------=_NextPart_000_0218_01C29154.09E63F40
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi ODE :)
Please can somebody look at this and experiment with the =
file?
LDLT decomposition is one of the primary computational activities =
in ODE's=20
physics engine. LDLT =3D Lower Diagonal Lower Transposed, meaning a =
constraint=20
matrix A (that describes the physics of a world) can be decomposed into =
two=20
matrices (L and D, where L is a lower triangular matrix (all entries =
above the=20
diagonal are zero) and D is a diagonal matrix (all entries except =
the=20
diagonal are zero)). Now A =3D L D L' (A equals the lower =
matrix times=20
the diagonal matrix times the transposed lower matrix.) The A matrix =
varies in=20
size and is typically between 10x10 and 500x500 for ODE (depending =
on
how=20
many constraints/collisions/etc need to be solved for a given simulation =
step).
This LDLT decomposition needs to be solved with every step =
and is=20
quite computationally intensive. I've looked at the stldlt.c file that =
is part=20
of the ODE source and it looks to me like it could be improved upon.=20
Unforetunately I use Delphi, so I cannot test my=20
suggested modifications directly (though the Delphi version =
seems fine=20
and considerably faster then the original).
The file
http://www.cs.su=
n.ac.za/~henri/fastldlt_henri.c=20
is a replacement for fastldlt.c and should (barring errors) work =
flawlessly and=20
faster then the original.
Let me know if it works, thanks :)
Henri
------=_NextPart_000_0218_01C29154.09E63F40--
From ruud at marketgraph.nl Thu Nov 21 03:48:01 2002
From: ruud at marketgraph.nl (Ruud van Gaal)
Date: Thu Nov 21 03:48:01 2002
Subject: [ODE] os x compile probs
Message-ID: <20C09F811939D311BA694854E86C778233E42D@raptor>
> El Mar 19 Nov 2002 09:03, ccos escribió:
> > hints very well appreciated.
> > has anybody here built ode on os x?
>
> try running ldconfig
I just took the error's advice and did 'ranlib libode.a' and that worked.
Ruud
From jnilson_99 at yahoo.com Thu Nov 21 11:16:01 2002
From: jnilson_99 at yahoo.com (jnilson_99@yahoo.com)
Date: Thu Nov 21 11:16:01 2002
Subject: [ODE] Faster ODE
In-Reply-To: <021b01c29143$46622a30$45d4e892@temple>
Message-ID: <20021121181503.47334.qmail@web40111.mail.yahoo.com>
Hi,
The mathematics behind what you're talking about
sounds really cool but over my head.
Do you know of any resource (web page or book) that
provides a background on LDLT, Lower Diagonal Lower
Transposed?
thanks,
john
--- Henri Hakl wrote:
> Hi ODE :)
>
> Please can somebody look at this and experiment with
> the file?
>
> LDLT decomposition is one of the primary
> computational activities in ODE's physics engine.
> LDLT = Lower Diagonal Lower Transposed, meaning a
> constraint matrix A (that describes the physics of a
> world) can be decomposed into two matrices (L and D,
> where L is a lower triangular matrix (all entries
> above the diagonal are zero) and D is a diagonal
> matrix (all entries except the diagonal are zero)).
> Now A = L D L' (A equals the lower matrix times
> the diagonal matrix times the transposed lower
> matrix.) The A matrix varies in size and is
> typically between 10x10 and 500x500 for ODE
> (depending on
> how many constraints/collisions/etc need to be
> solved for a given simulation step).
>
> This LDLT decomposition needs to be solved with
> every step and is quite computationally intensive.
> I've looked at the stldlt.c file that is part of the
> ODE source and it looks to me like it could be
> improved upon. Unforetunately I use Delphi, so I
> cannot test my suggested modifications directly
> (though the Delphi version seems fine and
> considerably faster then the original).
>
> The file
> http://www.cs.sun.ac.za/~henri/fastldlt_henri.c is a
> replacement for fastldlt.c and should (barring
> errors) work flawlessly and faster then the
> original.
>
> Let me know if it works, thanks :)
> Henri
>
>
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus – Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
From henri at cs.sun.ac.za Thu Nov 21 11:53:01 2002
From: henri at cs.sun.ac.za (Henri Hakl)
Date: Thu Nov 21 11:53:01 2002
Subject: [ODE] Faster ODE
References: <20021121181503.47334.qmail@web40111.mail.yahoo.com>
Message-ID: <002701c2918f$77a973e0$45d4e892@temple>
hmmm... no website springs to mind, but you can probably find one.
The basic algorithm for factorizing A into LDL' runs as follows:
initialize L and D to zero matrices
for i = 1 to n do
for j = 1 to i - 1 do Vj = LijDjj
Dii = Aii - SUM(from j = 1 to i - 1): LijVj
for j = i + 1 to n do Lji = (Aji - SUM(from k = 1 to i - 1)LjkVk) / Dii
This creates matrices L and D such that:
A = L D L'
holds.
ODE uses a similar approach, it still has the same big-O of n^3, but is
still faster then the vanilla version from above.
The original ODE version is in "fastldlt.c" of the ODE source; I've
maintained the algorithm but modified the code executing it in
"fastldlt_henri.c" (available at:
http://www.cs.sun.ac.za/~henri/fastldlt_henri.c) in theory the replacement
should be faster then the original. I cannot be sure until somebody verifies
that it is correct and indeed faster. In ODE the "A" matrix is infact the
Jacobian matrix that contains the current-step world constraint details.
hope this helps to start off :)
Henri
>Hi,
>
>The mathematics behind what you're talking about
>sounds really cool but over my head.
>
>Do you know of any resource (web page or book) that
>provides a background on LDLT, Lower Diagonal Lower
>Transposed?
>
>thanks,
>
>john
From nnevatie at welho.com Thu Nov 21 12:00:02 2002
From: nnevatie at welho.com (Niko Nevatie)
Date: Thu Nov 21 12:00:02 2002
Subject: [ODE] Faster ODE
References: <021b01c29143$46622a30$45d4e892@temple>
Message-ID: <001001c29190$2c35d9c0$3abdf3d5@wli>
I tried out the code in 'fastldlt_henri.c'. It works as expected. There was
a small typo somewhere in the beginning of one function, but it caused no
probs. I cannot say anything about the speed of the code, as I haven't
benchmarked anything yet. But hey, if you say it's faster than the original,
I'll take your word on it :)
----- Original Message -----
From: Henri Hakl
To: ode@q12.org
Sent: Thursday, November 21, 2002 11:49 AM
Subject: [ODE] Faster ODE
Hi ODE :)
Please can somebody look at this and experiment with the file?
LDLT decomposition is one of the primary computational activities in ODE's
physics engine. LDLT = Lower Diagonal Lower Transposed, meaning a constraint
matrix A (that describes the physics of a world) can be decomposed into two
matrices (L and D, where L is a lower triangular matrix (all entries above
the diagonal are zero) and D is a diagonal matrix (all entries except the
diagonal are zero)). Now A = L D L' (A equals the lower matrix times the
diagonal matrix times the transposed lower matrix.) The A matrix varies in
size and is typically between 10x10 and 500x500 for ODE (depending on
how many constraints/collisions/etc need to be solved for a given simulation
step).
This LDLT decomposition needs to be solved with every step and is quite
computationally intensive. I've looked at the stldlt.c file that is part of
the ODE source and it looks to me like it could be improved upon.
Unforetunately I use Delphi, so I cannot test my suggested modifications
directly (though the Delphi version seems fine and considerably faster then
the original).
The file http://www.cs.sun.ac.za/~henri/fastldlt_henri.c is a replacement
for fastldlt.c and should (barring errors) work flawlessly and faster then
the original.
Let me know if it works, thanks :)
Henri
From henri at cs.sun.ac.za Thu Nov 21 13:24:02 2002
From: henri at cs.sun.ac.za (Henri Hakl)
Date: Thu Nov 21 13:24:02 2002
Subject: [ODE] Faster ODE
References: <021b01c29143$46622a30$45d4e892@temple> <001001c29190$2c35d9c0$3abdf3d5@wli>
Message-ID: <001301c2919c$37c07280$45d4e892@temple>
Hey! :)
you're right... I found the missing comma - the file on the website has been
updated to reflect that as well.
Please check the accuracy and speed using the testsuite provided with ODE.
In the fbuild subdirectory there is a "test_ldlt.cpp" - compile it and run
with parameter f ("test_ldlt f"). This should test both the speed and the
accuracy of the factorizer. Try to compare both the original and the
replacement version... - just because I think it is faster doesn't mean
much - there may be compiler optimizations that I'm not aware of and other
subtle issues that I'm not taking into account.
thanks :)
Henri
----- Original Message -----
From: "Niko Nevatie"
To:
Sent: Thursday, November 21, 2002 8:59 PM
Subject: Re: [ODE] Faster ODE
> I tried out the code in 'fastldlt_henri.c'. It works as expected. There
was
> a small typo somewhere in the beginning of one function, but it caused no
> probs. I cannot say anything about the speed of the code, as I haven't
> benchmarked anything yet. But hey, if you say it's faster than the
original,
> I'll take your word on it :)
>
> ----- Original Message -----
> From: Henri Hakl
> To: ode@q12.org
> Sent: Thursday, November 21, 2002 11:49 AM
> Subject: [ODE] Faster ODE
>
>
> Hi ODE :)
>
> Please can somebody look at this and experiment with the file?
>
> LDLT decomposition is one of the primary computational activities in ODE's
> physics engine. LDLT = Lower Diagonal Lower Transposed, meaning a
constraint
> matrix A (that describes the physics of a world) can be decomposed into
two
> matrices (L and D, where L is a lower triangular matrix (all entries above
> the diagonal are zero) and D is a diagonal matrix (all entries except the
> diagonal are zero)). Now A = L D L' (A equals the lower matrix times the
> diagonal matrix times the transposed lower matrix.) The A matrix varies in
> size and is typically between 10x10 and 500x500 for ODE (depending on
> how many constraints/collisions/etc need to be solved for a given
simulation
> step).
>
> This LDLT decomposition needs to be solved with every step and is quite
> computationally intensive. I've looked at the stldlt.c file that is part
of
> the ODE source and it looks to me like it could be improved upon.
> Unforetunately I use Delphi, so I cannot test my suggested modifications
> directly (though the Delphi version seems fine and considerably faster
then
> the original).
>
> The file http://www.cs.sun.ac.za/~henri/fastldlt_henri.c is a replacement
> for fastldlt.c and should (barring errors) work flawlessly and faster then
> the original.
>
> Let me know if it works, thanks :)
> Henri
>
> _______________________________________________
> ODE mailing list
> ODE@q12.org
> http://q12.org/mailman/listinfo/ode
From mattias at cambrianlabs.com Thu Nov 21 13:36:02 2002
From: mattias at cambrianlabs.com (Mattias Fagerlund)
Date: Thu Nov 21 13:36:02 2002
Subject: [ODE] Faster ODE
In-Reply-To: <001001c29190$2c35d9c0$3abdf3d5@wli>
References: <021b01c29143$46622a30$45d4e892@temple> <001001c29190$2c35d9c0$3abdf3d5@wli>
Message-ID:
> But hey, if you say it's faster than the original,
> I'll take your word on it :)
No chance you could time it? I'd be very interested to see what the
differences are...
cheers,
m
From nnevatie at welho.com Thu Nov 21 14:12:02 2002
From: nnevatie at welho.com (Niko Nevatie)
Date: Thu Nov 21 14:12:02 2002
Subject: [ODE] Faster ODE
References: <021b01c29143$46622a30$45d4e892@temple> <001001c29190$2c35d9c0$3abdf3d5@wli>
Message-ID: <001501c291a2$9f68a500$3abdf3d5@wli>
Ok, why not, as soon as I have some spare hacking time. I'll post the
results here...
----- Original Message -----
From: "Mattias Fagerlund"
To: "Niko Nevatie" ;
Sent: Thursday, November 21, 2002 10:31 PM
Subject: Re: [ODE] Faster ODE
> > But hey, if you say it's faster than the original,
> > I'll take your word on it :)
>
> No chance you could time it? I'd be very interested to see what the
> differences are...
>
> cheers,
> m
>
>
From duhprey at yahoo.com Thu Nov 21 14:13:01 2002
From: duhprey at yahoo.com (Daniel Duhprey)
Date: Thu Nov 21 14:13:01 2002
Subject: [ODE] Faster ODE
In-Reply-To: <001301c2919c$37c07280$45d4e892@temple>
Message-ID:
On Thu, 21 Nov 2002, Henri Hakl wrote:
-->Please check the accuracy and speed using the testsuite provided with ODE.
If I'm using the numbers from the test_ldlt correctly (as a raw time on
some scale) then on my athlon its about 38% faster and on my celeron its
roughly twice as slow :).
--
------------
email: duhprey@tosos.com www: http://paradox.tosos.com/~duhprey icq: 129354442
She's got a whole brood of kids, like Sendmail, and Postfix, and Apache, and
Perl. And some of 'em die young, and some are mentally retarded. Sterling
The European finds intercourse with Americans easy and agreeable. Einstein
Not a shred of evidence exists in favor of the idea that life is serious. Gill
From martin at metahuman.org Thu Nov 21 14:38:01 2002
From: martin at metahuman.org (Martin C. Martin)
Date: Thu Nov 21 14:38:01 2002
Subject: [ODE] dRay, c++ interface, khepera model?
References: <200211201354.gAKDs3X30804@mailgate5.cinetic.de>
Message-ID: <3DDB966D.F1954CFB@metahuman.org>
This is a multi-part message in MIME format.
--------------AE4A85DEE0EE67C92AD2D7AE
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Here's the new C++ interface. It most likely won't compile out of the box
with ODE 0.03, since it uses some of the newer features in the CVS
version. But it shouldn't be hard to port, more or less just comment out
lines that don't compile.
- Martin
Thomas Buehmann wrote:
>
> hi,
> is it possible to get the c++ interface by martin c. martin and the dRay
> contribution without having to use cvs or copy and paste?
> apart from that, is anyone aware of a good khepera-style two-wheeled
> differential-steering model? if i use two wheels in front of my vehicle to drive
> and steer and an additional supporting wheel in the back, the latter tends to
> bend if the distance between front-wheels and supporting wheel is small (all use
> hinge2). is that model too simple or is it just a matter of tweaking cfm etc...?
>
> thanks,
> thomas.
>
> sorry if this mail got posted twice. i send it earlier from an unlisted address.
> ______________________________________________________________________________
> Der Anrufbeantworter für Ihre E-Mail-Korrespondenz - WEB.DE FreeMail
> http://freemail.web.de/features/?mc=021137
>
> _______________________________________________
> ODE mailing list
> ODE@q12.org
> http://q12.org/mailman/listinfo/ode
--------------AE4A85DEE0EE67C92AD2D7AE
Content-Type: application/x-unknown-content-type-hfile;
name="odecpp_new.h"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
filename="odecpp_new.h"
LyoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioNCiAqCQkJCQkJCQkJICoNCiAqIE9wZW4gRHluYW1pY3Mg
RW5naW5lLCBDb3B5cmlnaHQgKEMpIDIwMDEsMjAwMiBSdXNzZWxsIEwuIFNtaXRoLgkgKg0K
ICogQWxsIHJpZ2h0cyByZXNlcnZlZC4gIEVtYWlsOiBydXNzQHExMi5vcmcgICBXZWI6IHd3
dy5xMTIub3JnIAkgKg0KICoJCQkJCQkJCQkgKg0KICogVGhpcyBsaWJyYXJ5IGlzIGZyZWUg
c29mdHdhcmU7IHlvdSBjYW4gcmVkaXN0cmlidXRlIGl0IGFuZC9vcgkgKg0KICogbW9kaWZ5
IGl0IHVuZGVyIHRoZSB0ZXJtcyBvZiBFSVRIRVI6IAkJCQkgKg0KICogICAoMSkgVGhlIEdO
VSBMZXNzZXIgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSBhcyBwdWJsaXNoZWQgYnkgdGhlIEZy
ZWUgICoNCiAqCSBTb2Z0d2FyZSBGb3VuZGF0aW9uOyBlaXRoZXIgdmVyc2lvbiAyLjEgb2Yg
dGhlIExpY2Vuc2UsIG9yIChhdCAgKg0KICoJIHlvdXIgb3B0aW9uKSBhbnkgbGF0ZXIgdmVy
c2lvbi4gVGhlIHRleHQgb2YgdGhlIEdOVSBMZXNzZXIJICoNCiAqCSBHZW5lcmFsIFB1Ymxp
YyBMaWNlbnNlIGlzIGluY2x1ZGVkIHdpdGggdGhpcyBsaWJyYXJ5IGluIHRoZQkgKg0KICoJ
IGZpbGUgTElDRU5TRS5UWFQuCQkJCQkJICoNCiAqICAgKDIpIFRoZSBCU0Qtc3R5bGUgbGlj
ZW5zZSB0aGF0IGlzIGluY2x1ZGVkIHdpdGggdGhpcyBsaWJyYXJ5IGluCSAqDQogKgkgdGhl
IGZpbGUgTElDRU5TRS1CU0QuVFhULgkJCQkJICoNCiAqCQkJCQkJCQkJICoNCiAqIFRoaXMg
bGlicmFyeSBpcyBkaXN0cmlidXRlZCBpbiB0aGUgaG9wZSB0aGF0IGl0IHdpbGwgYmUgdXNl
ZnVsLAkgKg0KICogYnV0IFdJVEhPVVQgQU5ZIFdBUlJBTlRZOyB3aXRob3V0IGV2ZW4gdGhl
IGltcGxpZWQgd2FycmFudHkgb2YJICoNCiAqIE1FUkNIQU5UQUJJTElUWSBvciBGSVRORVNT
IEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4gU2VlIHRoZSBmaWxlcwkgKg0KICogTElDRU5T
RS5UWFQgYW5kIExJQ0VOU0UtQlNELlRYVCBmb3IgbW9yZSBkZXRhaWxzLgkJCSAqDQogKgkJ
CQkJCQkJCSAqDQogKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKi8NCg0KLy8gQysrIGludGVyZmFjZSBm
b3IgZXZlcnl0aGluZw0KDQoNCiNpZm5kZWYgX09ERV9PREVDUFBfSF8NCiNkZWZpbmUgX09E
RV9PREVDUFBfSF8NCiNpZmRlZiBfX2NwbHVzcGx1cw0KDQojaW5jbHVkZSA8b2RlL2Vycm9y
Lmg+DQoNCg0KY2xhc3MgZFdvcmxkIHsNCiAgZFdvcmxkSUQgX2lkOw0KDQogIC8vIGludGVu
dGlvbmFsbHkgdW5kZWZpbmVkLCBkb24ndCB1c2UgdGhlc2UNCiAgZFdvcmxkIChjb25zdCBk
V29ybGQgJik7DQogIHZvaWQgb3BlcmF0b3I9IChjb25zdCBkV29ybGQgJik7DQoNCnB1Ymxp
YzoNCiAgZFdvcmxkKCkNCiAgICB7IF9pZCA9IGRXb3JsZENyZWF0ZSgpOyB9DQogIH5kV29y
bGQoKQ0KICAgIHsgZFdvcmxkRGVzdHJveSAoX2lkKTsgfQ0KDQogIGRXb3JsZElEIGlkKCkg
Y29uc3QNCiAgICB7IHJldHVybiBfaWQ7IH0NCiAgb3BlcmF0b3IgZFdvcmxkSUQoKSBjb25z
dA0KICAgIHsgcmV0dXJuIF9pZDsgfQ0KDQogIHZvaWQgc2V0R3Jhdml0eSAoZFJlYWwgeCwg
ZFJlYWwgeSwgZFJlYWwgeikNCiAgICB7IGRXb3JsZFNldEdyYXZpdHkgKF9pZCx4LHkseik7
IH0NCiAgdm9pZCBnZXRHcmF2aXR5IChkVmVjdG9yMyBnKSBjb25zdA0KICAgIHsgZFdvcmxk
R2V0R3Jhdml0eSAoX2lkLGcpOyB9DQoNCiAgdm9pZCBzZXRFUlAgKGRSZWFsIGVycCkNCiAg
ICB7IGRXb3JsZFNldEVSUChfaWQsIGVycCk7IH0NCiAgZFJlYWwgZ2V0RVJQKCkgY29uc3QN
CiAgICB7IHJldHVybiBkV29ybGRHZXRFUlAoX2lkKTsgfQ0KDQogIHZvaWQgc2V0Q0ZNIChk
UmVhbCBjZm0pDQogICAgeyBkV29ybGRTZXRDRk0oX2lkLCBjZm0pOyB9DQogIGRSZWFsIGdl
dENGTSgpIGNvbnN0DQogICAgeyByZXR1cm4gZFdvcmxkR2V0Q0ZNKF9pZCk7IH0NCg0KICB2
b2lkIHN0ZXAgKGRSZWFsIHN0ZXBzaXplKQ0KICAgIHsgZFdvcmxkU3RlcCAoX2lkLHN0ZXBz
aXplKTsgfQ0KDQogIHZvaWQgaW1wdWxzZVRvRm9yY2UgKGRSZWFsIHN0ZXBzaXplLCBkUmVh
bCBpeCwgZFJlYWwgaXksIGRSZWFsIGl6LA0KCQkgICAgICAgZFZlY3RvcjMgZm9yY2UpDQog
ICAgeyBkV29ybGRJbXB1bHNlVG9Gb3JjZSAoX2lkLHN0ZXBzaXplLGl4LGl5LGl6LGZvcmNl
KTsgfQ0KfTsNCg0KDQpjbGFzcyBkQm9keSB7DQogIGRCb2R5SUQgX2lkOw0KDQogIC8vIGlu
dGVudGlvbmFsbHkgdW5kZWZpbmVkLCBkb24ndCB1c2UgdGhlc2UNCiAgZEJvZHkgKGNvbnN0
IGRCb2R5ICYpOw0KICB2b2lkIG9wZXJhdG9yPSAoY29uc3QgZEJvZHkgJik7DQoNCnB1Ymxp
YzoNCiAgZEJvZHkoKQ0KICAgIHsgX2lkID0gMDsgfQ0KICBkQm9keSAoZFdvcmxkSUQgd29y
bGQpDQogICAgeyBfaWQgPSBkQm9keUNyZWF0ZSAod29ybGQpOyB9DQogIH5kQm9keSgpDQog
ICAgeyBpZiAoX2lkKSBkQm9keURlc3Ryb3kgKF9pZCk7IH0NCg0KICB2b2lkIGNyZWF0ZSAo
ZFdvcmxkSUQgd29ybGQpIHsNCiAgICBpZiAoX2lkKSBkQm9keURlc3Ryb3kgKF9pZCk7DQog
ICAgX2lkID0gZEJvZHlDcmVhdGUgKHdvcmxkKTsNCiAgfQ0KDQogIGRCb2R5SUQgaWQoKSBj
b25zdA0KICAgIHsgcmV0dXJuIF9pZDsgfQ0KICBvcGVyYXRvciBkQm9keUlEKCkgY29uc3QN
CiAgICB7IHJldHVybiBfaWQ7IH0NCg0KICB2b2lkIHNldERhdGEgKHZvaWQgKmRhdGEpDQog
ICAgeyBkQm9keVNldERhdGEgKF9pZCxkYXRhKTsgfQ0KICB2b2lkICpnZXREYXRhKCkgY29u
c3QNCiAgICB7IHJldHVybiBkQm9keUdldERhdGEgKF9pZCk7IH0NCg0KICB2b2lkIHNldFBv
c2l0aW9uIChkUmVhbCB4LCBkUmVhbCB5LCBkUmVhbCB6KQ0KICAgIHsgZEJvZHlTZXRQb3Np
dGlvbiAoX2lkLHgseSx6KTsgfQ0KICB2b2lkIHNldFJvdGF0aW9uIChjb25zdCBkTWF0cml4
MyBSKQ0KICAgIHsgZEJvZHlTZXRSb3RhdGlvbiAoX2lkLFIpOyB9DQogIHZvaWQgc2V0UXVh
dGVybmlvbiAoY29uc3QgZFF1YXRlcm5pb24gcSkNCiAgICB7IGRCb2R5U2V0UXVhdGVybmlv
biAoX2lkLHEpOyB9DQogIHZvaWQgc2V0TGluZWFyVmVsICAoZFJlYWwgeCwgZFJlYWwgeSwg
ZFJlYWwgeikNCiAgICB7IGRCb2R5U2V0TGluZWFyVmVsIChfaWQseCx5LHopOyB9DQogIHZv
aWQgc2V0QW5ndWxhclZlbCAoZFJlYWwgeCwgZFJlYWwgeSwgZFJlYWwgeikNCiAgICB7IGRC
b2R5U2V0QW5ndWxhclZlbCAoX2lkLHgseSx6KTsgfQ0KDQogIGNvbnN0IGRSZWFsICogZ2V0
UG9zaXRpb24oKSBjb25zdA0KICAgIHsgcmV0dXJuIGRCb2R5R2V0UG9zaXRpb24gKF9pZCk7
IH0NCiAgY29uc3QgZFJlYWwgKiBnZXRSb3RhdGlvbigpIGNvbnN0DQogICAgeyByZXR1cm4g
ZEJvZHlHZXRSb3RhdGlvbiAoX2lkKTsgfQ0KICBjb25zdCBkUmVhbCAqIGdldFF1YXRlcm5p
b24oKSBjb25zdA0KICAgIHsgcmV0dXJuIGRCb2R5R2V0UXVhdGVybmlvbiAoX2lkKTsgfQ0K
ICBjb25zdCBkUmVhbCAqIGdldExpbmVhclZlbCgpIGNvbnN0DQogICAgeyByZXR1cm4gZEJv
ZHlHZXRMaW5lYXJWZWwgKF9pZCk7IH0NCiAgY29uc3QgZFJlYWwgKiBnZXRBbmd1bGFyVmVs
KCkgY29uc3QNCiAgICB7IHJldHVybiBkQm9keUdldEFuZ3VsYXJWZWwgKF9pZCk7IH0NCg0K
ICB2b2lkIHNldE1hc3MgKGNvbnN0IGRNYXNzICptYXNzKQ0KICAgIHsgZEJvZHlTZXRNYXNz
IChfaWQsbWFzcyk7IH0NCiAgdm9pZCBnZXRNYXNzIChkTWFzcyAqbWFzcykgY29uc3QNCiAg
ICB7IGRCb2R5R2V0TWFzcyAoX2lkLG1hc3MpOyB9DQoNCiAgdm9pZCBhZGRGb3JjZSAoZFJl
YWwgZngsIGRSZWFsIGZ5LCBkUmVhbCBmeikNCiAgICB7IGRCb2R5QWRkRm9yY2UgKF9pZCwg
ZngsIGZ5LCBmeik7IH0NCiAgdm9pZCBhZGRUb3JxdWUgKGRSZWFsIGZ4LCBkUmVhbCBmeSwg
ZFJlYWwgZnopDQogICAgeyBkQm9keUFkZFRvcnF1ZSAoX2lkLCBmeCwgZnksIGZ6KTsgfQ0K
ICB2b2lkIGFkZFJlbEZvcmNlIChkUmVhbCBmeCwgZFJlYWwgZnksIGRSZWFsIGZ6KQ0KICAg
IHsgZEJvZHlBZGRSZWxGb3JjZSAoX2lkLCBmeCwgZnksIGZ6KTsgfQ0KICB2b2lkIGFkZFJl
bFRvcnF1ZSAoZFJlYWwgZngsIGRSZWFsIGZ5LCBkUmVhbCBmeikNCiAgICB7IGRCb2R5QWRk
UmVsVG9ycXVlIChfaWQsIGZ4LCBmeSwgZnopOyB9DQogIHZvaWQgYWRkRm9yY2VBdFBvcyAo
ZFJlYWwgZngsIGRSZWFsIGZ5LCBkUmVhbCBmeiwNCgkJICAgICAgZFJlYWwgcHgsIGRSZWFs
IHB5LCBkUmVhbCBweikNCiAgICB7IGRCb2R5QWRkRm9yY2VBdFBvcyAoX2lkLCBmeCwgZnks
IGZ6LCBweCwgcHksIHB6KTsgfQ0KICB2b2lkIGFkZEZvcmNlQXRSZWxQb3MgKGRSZWFsIGZ4
LCBkUmVhbCBmeSwgZFJlYWwgZnosDQoJCSAgICAgIGRSZWFsIHB4LCBkUmVhbCBweSwgZFJl
YWwgcHopDQogICAgeyBkQm9keUFkZEZvcmNlQXRSZWxQb3MgKF9pZCwgZngsIGZ5LCBmeiwg
cHgsIHB5LCBweik7IH0NCiAgdm9pZCBhZGRSZWxGb3JjZUF0UG9zIChkUmVhbCBmeCwgZFJl
YWwgZnksIGRSZWFsIGZ6LA0KCQkJIGRSZWFsIHB4LCBkUmVhbCBweSwgZFJlYWwgcHopDQog
ICAgeyBkQm9keUFkZFJlbEZvcmNlQXRQb3MgKF9pZCwgZngsIGZ5LCBmeiwgcHgsIHB5LCBw
eik7IH0NCiAgdm9pZCBhZGRSZWxGb3JjZUF0UmVsUG9zIChkUmVhbCBmeCwgZFJlYWwgZnks
IGRSZWFsIGZ6LA0KCQkJICAgIGRSZWFsIHB4LCBkUmVhbCBweSwgZFJlYWwgcHopDQogICAg
eyBkQm9keUFkZFJlbEZvcmNlQXRSZWxQb3MgKF9pZCwgZngsIGZ5LCBmeiwgcHgsIHB5LCBw
eik7IH0NCg0KICBjb25zdCBkUmVhbCAqIGdldEZvcmNlKCkgY29uc3QNCiAgICB7IHJldHVy
biBkQm9keUdldEZvcmNlKF9pZCk7IH0NCiAgY29uc3QgZFJlYWwgKiBnZXRUb3JxdWUoKSBj
b25zdA0KICAgIHsgcmV0dXJuIGRCb2R5R2V0VG9ycXVlKF9pZCk7IH0NCiAgdm9pZCBzZXRG
b3JjZSAoZFJlYWwgeCwgZFJlYWwgeSwgZFJlYWwgeikNCiAgICB7IGRCb2R5U2V0Rm9yY2Ug
KF9pZCx4LHkseik7IH0NCiAgdm9pZCBzZXRUb3JxdWUgKGRSZWFsIHgsIGRSZWFsIHksIGRS
ZWFsIHopDQogICAgeyBkQm9keVNldFRvcnF1ZSAoX2lkLHgseSx6KTsgfQ0KDQogIHZvaWQg
ZW5hYmxlKCkNCiAgICB7IGRCb2R5RW5hYmxlIChfaWQpOyB9DQogIHZvaWQgZGlzYWJsZSgp
DQogICAgeyBkQm9keURpc2FibGUgKF9pZCk7IH0NCiAgaW50IGlzRW5hYmxlZCgpIGNvbnN0
DQogICAgeyByZXR1cm4gZEJvZHlJc0VuYWJsZWQgKF9pZCk7IH0NCg0KICB2b2lkIGdldFJl
bFBvaW50UG9zIChkUmVhbCBweCwgZFJlYWwgcHksIGRSZWFsIHB6LCBkVmVjdG9yMyByZXN1
bHQpIGNvbnN0DQogICAgeyBkQm9keUdldFJlbFBvaW50UG9zIChfaWQsIHB4LCBweSwgcHos
IHJlc3VsdCk7IH0NCiAgdm9pZCBnZXRSZWxQb2ludFZlbCAoZFJlYWwgcHgsIGRSZWFsIHB5
LCBkUmVhbCBweiwgZFZlY3RvcjMgcmVzdWx0KSBjb25zdA0KICAgIHsgZEJvZHlHZXRSZWxQ
b2ludFZlbCAoX2lkLCBweCwgcHksIHB6LCByZXN1bHQpOyB9DQogIHZvaWQgZ2V0UG9pbnRW
ZWwgKGRSZWFsIHB4LCBkUmVhbCBweSwgZFJlYWwgcHosIGRWZWN0b3IzIHJlc3VsdCkgY29u
c3QNCiAgICB7IGRCb2R5R2V0UG9pbnRWZWwgKF9pZCxweCxweSxweixyZXN1bHQpOyB9DQog
IHZvaWQgZ2V0UG9zUmVsUG9pbnQgKGRSZWFsIHB4LCBkUmVhbCBweSwgZFJlYWwgcHosIGRW
ZWN0b3IzIHJlc3VsdCkgY29uc3QNCiAgICB7IGRCb2R5R2V0UG9zUmVsUG9pbnQgKF9pZCxw
eCxweSxweixyZXN1bHQpOyB9DQogIHZvaWQgdmVjdG9yVG9Xb3JsZCAoZFJlYWwgcHgsIGRS
ZWFsIHB5LCBkUmVhbCBweiwgZFZlY3RvcjMgcmVzdWx0KSBjb25zdA0KICAgIHsgZEJvZHlW
ZWN0b3JUb1dvcmxkIChfaWQscHgscHkscHoscmVzdWx0KTsgfQ0KICB2b2lkIHZlY3RvckZy
b21Xb3JsZCAoZFJlYWwgcHgsIGRSZWFsIHB5LCBkUmVhbCBweiwgZFZlY3RvcjMgcmVzdWx0
KSBjb25zdA0KICAgIHsgZEJvZHlWZWN0b3JGcm9tV29ybGQgKF9pZCxweCxweSxweixyZXN1
bHQpOyB9DQoNCiAgdm9pZCBzZXRGaW5pdGVSb3RhdGlvbk1vZGUgKGludCBtb2RlKQ0KICAg
IHsgZEJvZHlTZXRGaW5pdGVSb3RhdGlvbk1vZGUgKF9pZCwgbW9kZSk7IH0NCiAgdm9pZCBz
ZXRGaW5pdGVSb3RhdGlvbkF4aXMgKGRSZWFsIHgsIGRSZWFsIHksIGRSZWFsIHopDQogICAg
eyBkQm9keVNldEZpbml0ZVJvdGF0aW9uQXhpcyAoX2lkLCB4LCB5LCB6KTsgfQ0KDQogIGlu
dCBnZXRGaW5pdGVSb3RhdGlvbk1vZGUoKSBjb25zdA0KICAgIHsgcmV0dXJuIGRCb2R5R2V0
RmluaXRlUm90YXRpb25Nb2RlIChfaWQpOyB9DQogIHZvaWQgZ2V0RmluaXRlUm90YXRpb25B
eGlzIChkVmVjdG9yMyByZXN1bHQpIGNvbnN0DQogICAgeyBkQm9keUdldEZpbml0ZVJvdGF0
aW9uQXhpcyAoX2lkLCByZXN1bHQpOyB9DQoNCiAgaW50IGdldE51bUpvaW50cygpIGNvbnN0
DQogICAgeyByZXR1cm4gZEJvZHlHZXROdW1Kb2ludHMgKF9pZCk7IH0NCiAgZEpvaW50SUQg
Z2V0Sm9pbnQgKGludCBpbmRleCkgY29uc3QNCiAgICB7IHJldHVybiBkQm9keUdldEpvaW50
IChfaWQsIGluZGV4KTsgfQ0KDQogIHZvaWQgc2V0R3Jhdml0eU1vZGUgKGludCBtb2RlKQ0K
ICAgIHsgZEJvZHlTZXRHcmF2aXR5TW9kZSAoX2lkLG1vZGUpOyB9DQogIGludCBnZXRHcmF2
aXR5TW9kZSgpIGNvbnN0DQogICAgeyByZXR1cm4gZEJvZHlHZXRHcmF2aXR5TW9kZSAoX2lk
KTsgfQ0KDQogIGludCBpc0Nvbm5lY3RlZFRvIChkQm9keUlEIGJvZHkpIGNvbnN0DQogICAg
eyByZXR1cm4gZEFyZUNvbm5lY3RlZCAoX2lkLCBib2R5KTsgfQ0KfTsNCg0KDQpjbGFzcyBk
Sm9pbnRHcm91cCB7DQogIGRKb2ludEdyb3VwSUQgX2lkOw0KDQogIC8vIGludGVudGlvbmFs
bHkgdW5kZWZpbmVkLCBkb24ndCB1c2UgdGhlc2UNCiAgZEpvaW50R3JvdXAgKGNvbnN0IGRK
b2ludEdyb3VwICYpOw0KICB2b2lkIG9wZXJhdG9yPSAoY29uc3QgZEpvaW50R3JvdXAgJik7
DQoNCnB1YmxpYzoNCiAgZEpvaW50R3JvdXAgKGludCBkdW1teV9hcmc9MCkNCiAgICB7IF9p
ZCA9IGRKb2ludEdyb3VwQ3JlYXRlICgwKTsgfQ0KICB+ZEpvaW50R3JvdXAoKQ0KICAgIHsg
ZEpvaW50R3JvdXBEZXN0cm95IChfaWQpOyB9DQogIHZvaWQgY3JlYXRlIChpbnQgZHVtbXlf
YXJnPTApIHsNCiAgICBpZiAoX2lkKSBkSm9pbnRHcm91cERlc3Ryb3kgKF9pZCk7DQogICAg
X2lkID0gZEpvaW50R3JvdXBDcmVhdGUgKDApOw0KICB9DQoNCiAgZEpvaW50R3JvdXBJRCBp
ZCgpIGNvbnN0DQogICAgeyByZXR1cm4gX2lkOyB9DQogIG9wZXJhdG9yIGRKb2ludEdyb3Vw
SUQoKSBjb25zdA0KICAgIHsgcmV0dXJuIF9pZDsgfQ0KDQogIHZvaWQgZW1wdHkoKQ0KICAg
IHsgZEpvaW50R3JvdXBFbXB0eSAoX2lkKTsgfQ0KfTsNCg0KDQpjbGFzcyBkSm9pbnQgew0K
cHJpdmF0ZToNCiAgLy8gaW50ZW50aW9uYWxseSB1bmRlZmluZWQsIGRvbid0IHVzZSB0aGVz
ZQ0KICBkSm9pbnQgKGNvbnN0IGRKb2ludCAmKSA7DQogIHZvaWQgb3BlcmF0b3I9IChjb25z
dCBkSm9pbnQgJik7DQoNCnByb3RlY3RlZDoNCiAgZEpvaW50SUQgX2lkOw0KDQpwdWJsaWM6
DQogIGRKb2ludCgpDQogICAgeyBfaWQgPSAwOyB9DQogIH5kSm9pbnQoKQ0KICAgIHsgaWYg
KF9pZCkgZEpvaW50RGVzdHJveSAoX2lkKTsgfQ0KDQogIGRKb2ludElEIGlkKCkgY29uc3QN
CiAgICB7IHJldHVybiBfaWQ7IH0NCiAgb3BlcmF0b3IgZEpvaW50SUQoKSBjb25zdA0KICAg
IHsgcmV0dXJuIF9pZDsgfQ0KDQogIHZvaWQgYXR0YWNoIChkQm9keUlEIGJvZHkxLCBkQm9k
eUlEIGJvZHkyKQ0KICAgIHsgZEpvaW50QXR0YWNoIChfaWQsIGJvZHkxLCBib2R5Mik7IH0N
Cg0KICB2b2lkIHNldERhdGEgKHZvaWQgKmRhdGEpDQogICAgeyBkSm9pbnRTZXREYXRhIChf
aWQsIGRhdGEpOyB9DQogIHZvaWQgKmdldERhdGEgKHZvaWQgKmRhdGEpIGNvbnN0DQogICAg
eyByZXR1cm4gZEpvaW50R2V0RGF0YSAoX2lkKTsgfQ0KDQogIGludCBnZXRUeXBlKCkgY29u
c3QNCiAgICB7IHJldHVybiBkSm9pbnRHZXRUeXBlIChfaWQpOyB9DQoNCiAgZEJvZHlJRCBn
ZXRCb2R5IChpbnQgaW5kZXgpIGNvbnN0DQogICAgeyByZXR1cm4gZEpvaW50R2V0Qm9keSAo
X2lkLCBpbmRleCk7IH0NCn07DQoNCg0KY2xhc3MgZEJhbGxKb2ludCA6IHB1YmxpYyBkSm9p
bnQgew0KcHJpdmF0ZToNCiAgLy8gaW50ZW50aW9uYWxseSB1bmRlZmluZWQsIGRvbid0IHVz
ZSB0aGVzZQ0KICBkQmFsbEpvaW50IChjb25zdCBkQmFsbEpvaW50ICYpOw0KICB2b2lkIG9w
ZXJhdG9yPSAoY29uc3QgZEJhbGxKb2ludCAmKTsNCg0KcHVibGljOg0KICBkQmFsbEpvaW50
KCkgeyB9DQogIGRCYWxsSm9pbnQgKGRXb3JsZElEIHdvcmxkLCBkSm9pbnRHcm91cElEIGdy
b3VwPTApDQogICAgeyBfaWQgPSBkSm9pbnRDcmVhdGVCYWxsICh3b3JsZCwgZ3JvdXApOyB9
DQoNCiAgdm9pZCBjcmVhdGUgKGRXb3JsZElEIHdvcmxkLCBkSm9pbnRHcm91cElEIGdyb3Vw
PTApIHsNCiAgICBpZiAoX2lkKSBkSm9pbnREZXN0cm95IChfaWQpOw0KICAgIF9pZCA9IGRK
b2ludENyZWF0ZUJhbGwgKHdvcmxkLCBncm91cCk7DQogIH0NCg0KICB2b2lkIHNldEFuY2hv
ciAoZFJlYWwgeCwgZFJlYWwgeSwgZFJlYWwgeikNCiAgICB7IGRKb2ludFNldEJhbGxBbmNo
b3IgKF9pZCwgeCwgeSwgeik7IH0NCiAgdm9pZCBnZXRBbmNob3IgKGRWZWN0b3IzIHJlc3Vs
dCkgY29uc3QNCiAgICB7IGRKb2ludEdldEJhbGxBbmNob3IgKF9pZCwgcmVzdWx0KTsgfQ0K
fSA7DQoNCg0KY2xhc3MgZEhpbmdlSm9pbnQgOiBwdWJsaWMgZEpvaW50IHsNCiAgLy8gaW50
ZW50aW9uYWxseSB1bmRlZmluZWQsIGRvbid0IHVzZSB0aGVzZQ0KICBkSGluZ2VKb2ludCAo
Y29uc3QgZEhpbmdlSm9pbnQgJik7DQogIHZvaWQgb3BlcmF0b3IgPSAoY29uc3QgZEhpbmdl
Sm9pbnQgJik7DQoNCnB1YmxpYzoNCiAgZEhpbmdlSm9pbnQoKSB7IH0NCiAgZEhpbmdlSm9p
bnQgKGRXb3JsZElEIHdvcmxkLCBkSm9pbnRHcm91cElEIGdyb3VwPTApDQogICAgeyBfaWQg
PSBkSm9pbnRDcmVhdGVIaW5nZSAod29ybGQsIGdyb3VwKTsgfQ0KDQogIHZvaWQgY3JlYXRl
IChkV29ybGRJRCB3b3JsZCwgZEpvaW50R3JvdXBJRCBncm91cD0wKSB7DQogICAgaWYgKF9p
ZCkgZEpvaW50RGVzdHJveSAoX2lkKTsNCiAgICBfaWQgPSBkSm9pbnRDcmVhdGVIaW5nZSAo
d29ybGQsIGdyb3VwKTsNCiAgfQ0KDQogIHZvaWQgc2V0QW5jaG9yIChkUmVhbCB4LCBkUmVh
bCB5LCBkUmVhbCB6KQ0KICAgIHsgZEpvaW50U2V0SGluZ2VBbmNob3IgKF9pZCwgeCwgeSwg
eik7IH0NCiAgdm9pZCBnZXRBbmNob3IgKGRWZWN0b3IzIHJlc3VsdCkgY29uc3QNCiAgICB7
IGRKb2ludEdldEhpbmdlQW5jaG9yIChfaWQsIHJlc3VsdCk7IH0NCg0KICB2b2lkIHNldEF4
aXMgKGRSZWFsIHgsIGRSZWFsIHksIGRSZWFsIHopDQogICAgeyBkSm9pbnRTZXRIaW5nZUF4
aXMgKF9pZCwgeCwgeSwgeik7IH0NCiAgdm9pZCBnZXRBeGlzIChkVmVjdG9yMyByZXN1bHQp
IGNvbnN0DQogICAgeyBkSm9pbnRHZXRIaW5nZUF4aXMgKF9pZCwgcmVzdWx0KTsgfQ0KDQog
IGRSZWFsIGdldEFuZ2xlKCkgY29uc3QNCiAgICB7IHJldHVybiBkSm9pbnRHZXRIaW5nZUFu
Z2xlIChfaWQpOyB9DQogIGRSZWFsIGdldEFuZ2xlUmF0ZSgpIGNvbnN0DQogICAgeyByZXR1
cm4gZEpvaW50R2V0SGluZ2VBbmdsZVJhdGUgKF9pZCk7IH0NCg0KICB2b2lkIHNldFBhcmFt
IChpbnQgcGFyYW1ldGVyLCBkUmVhbCB2YWx1ZSkNCiAgICB7IGRKb2ludFNldEhpbmdlUGFy
YW0gKF9pZCwgcGFyYW1ldGVyLCB2YWx1ZSk7IH0NCiAgZFJlYWwgZ2V0UGFyYW0gKGludCBw
YXJhbWV0ZXIpIGNvbnN0DQogICAgeyByZXR1cm4gZEpvaW50R2V0SGluZ2VQYXJhbSAoX2lk
LCBwYXJhbWV0ZXIpOyB9DQp9Ow0KDQoNCmNsYXNzIGRTbGlkZXJKb2ludCA6IHB1YmxpYyBk
Sm9pbnQgew0KICAvLyBpbnRlbnRpb25hbGx5IHVuZGVmaW5lZCwgZG9uJ3QgdXNlIHRoZXNl
DQogIGRTbGlkZXJKb2ludCAoY29uc3QgZFNsaWRlckpvaW50ICYpOw0KICB2b2lkIG9wZXJh
dG9yID0gKGNvbnN0IGRTbGlkZXJKb2ludCAmKTsNCg0KcHVibGljOg0KICBkU2xpZGVySm9p
bnQoKSB7IH0NCiAgZFNsaWRlckpvaW50IChkV29ybGRJRCB3b3JsZCwgZEpvaW50R3JvdXBJ
RCBncm91cD0wKQ0KICAgIHsgX2lkID0gZEpvaW50Q3JlYXRlU2xpZGVyICh3b3JsZCwgZ3Jv
dXApOyB9DQoNCiAgdm9pZCBjcmVhdGUgKGRXb3JsZElEIHdvcmxkLCBkSm9pbnRHcm91cElE
IGdyb3VwPTApIHsNCiAgICBpZiAoX2lkKSBkSm9pbnREZXN0cm95IChfaWQpOw0KICAgIF9p
ZCA9IGRKb2ludENyZWF0ZVNsaWRlciAod29ybGQsIGdyb3VwKTsNCiAgfQ0KDQogIHZvaWQg
c2V0QXhpcyAoZFJlYWwgeCwgZFJlYWwgeSwgZFJlYWwgeikNCiAgICB7IGRKb2ludFNldFNs
aWRlckF4aXMgKF9pZCwgeCwgeSwgeik7IH0NCiAgdm9pZCBnZXRBeGlzIChkVmVjdG9yMyBy
ZXN1bHQpIGNvbnN0DQogICAgeyBkSm9pbnRHZXRTbGlkZXJBeGlzIChfaWQsIHJlc3VsdCk7
IH0NCg0KICBkUmVhbCBnZXRQb3NpdGlvbigpIGNvbnN0DQogICAgeyByZXR1cm4gZEpvaW50
R2V0U2xpZGVyUG9zaXRpb24gKF9pZCk7IH0NCiAgZFJlYWwgZ2V0UG9zaXRpb25SYXRlKCkg
Y29uc3QNCiAgICB7IHJldHVybiBkSm9pbnRHZXRTbGlkZXJQb3NpdGlvblJhdGUgKF9pZCk7
IH0NCg0KICB2b2lkIHNldFBhcmFtIChpbnQgcGFyYW1ldGVyLCBkUmVhbCB2YWx1ZSkNCiAg
ICB7IGRKb2ludFNldFNsaWRlclBhcmFtIChfaWQsIHBhcmFtZXRlciwgdmFsdWUpOyB9DQog
IGRSZWFsIGdldFBhcmFtIChpbnQgcGFyYW1ldGVyKSBjb25zdA0KICAgIHsgcmV0dXJuIGRK
b2ludEdldFNsaWRlclBhcmFtIChfaWQsIHBhcmFtZXRlcik7IH0NCn07DQoNCg0KY2xhc3Mg
ZFVuaXZlcnNhbEpvaW50IDogcHVibGljIGRKb2ludCB7DQogIC8vIGludGVudGlvbmFsbHkg
dW5kZWZpbmVkLCBkb24ndCB1c2UgdGhlc2UNCiAgZFVuaXZlcnNhbEpvaW50IChjb25zdCBk
VW5pdmVyc2FsSm9pbnQgJik7DQogIHZvaWQgb3BlcmF0b3IgPSAoY29uc3QgZFVuaXZlcnNh
bEpvaW50ICYpOw0KDQpwdWJsaWM6DQogIGRVbml2ZXJzYWxKb2ludCgpIHsgfQ0KICBkVW5p
dmVyc2FsSm9pbnQgKGRXb3JsZElEIHdvcmxkLCBkSm9pbnRHcm91cElEIGdyb3VwPTApDQog
ICAgeyBfaWQgPSBkSm9pbnRDcmVhdGVVbml2ZXJzYWwgKHdvcmxkLCBncm91cCk7IH0NCg0K
ICB2b2lkIGNyZWF0ZSAoZFdvcmxkSUQgd29ybGQsIGRKb2ludEdyb3VwSUQgZ3JvdXA9MCkg
ew0KICAgIGlmIChfaWQpIGRKb2ludERlc3Ryb3kgKF9pZCk7DQogICAgX2lkID0gZEpvaW50
Q3JlYXRlVW5pdmVyc2FsICh3b3JsZCwgZ3JvdXApOw0KICB9DQoNCiAgdm9pZCBzZXRBbmNo
b3IgKGRSZWFsIHgsIGRSZWFsIHksIGRSZWFsIHopDQogICAgeyBkSm9pbnRTZXRVbml2ZXJz
YWxBbmNob3IgKF9pZCwgeCwgeSwgeik7IH0NCiAgdm9pZCBzZXRBeGlzMSAoZFJlYWwgeCwg
ZFJlYWwgeSwgZFJlYWwgeikNCiAgICB7IGRKb2ludFNldFVuaXZlcnNhbEF4aXMxIChfaWQs
IHgsIHksIHopOyB9DQogIHZvaWQgc2V0QXhpczIgKGRSZWFsIHgsIGRSZWFsIHksIGRSZWFs
IHopDQogICAgeyBkSm9pbnRTZXRVbml2ZXJzYWxBeGlzMiAoX2lkLCB4LCB5LCB6KTsgfQ0K
DQogIHZvaWQgZ2V0QW5jaG9yIChkVmVjdG9yMyByZXN1bHQpIGNvbnN0DQogICAgeyBkSm9p
bnRHZXRVbml2ZXJzYWxBbmNob3IgKF9pZCwgcmVzdWx0KTsgfQ0KICB2b2lkIGdldEF4aXMx
IChkVmVjdG9yMyByZXN1bHQpIGNvbnN0DQogICAgeyBkSm9pbnRHZXRVbml2ZXJzYWxBeGlz
MSAoX2lkLCByZXN1bHQpOyB9DQogIHZvaWQgZ2V0QXhpczIgKGRWZWN0b3IzIHJlc3VsdCkg
Y29uc3QNCiAgICB7IGRKb2ludEdldFVuaXZlcnNhbEF4aXMyIChfaWQsIHJlc3VsdCk7IH0N
Cn07DQoNCg0KY2xhc3MgZEhpbmdlMkpvaW50IDogcHVibGljIGRKb2ludCB7DQogIC8vIGlu
dGVudGlvbmFsbHkgdW5kZWZpbmVkLCBkb24ndCB1c2UgdGhlc2UNCiAgZEhpbmdlMkpvaW50
IChjb25zdCBkSGluZ2UySm9pbnQgJik7DQogIHZvaWQgb3BlcmF0b3IgPSAoY29uc3QgZEhp
bmdlMkpvaW50ICYpOw0KDQpwdWJsaWM6DQogIGRIaW5nZTJKb2ludCgpIHsgfQ0KICBkSGlu
Z2UySm9pbnQgKGRXb3JsZElEIHdvcmxkLCBkSm9pbnRHcm91cElEIGdyb3VwPTApDQogICAg
eyBfaWQgPSBkSm9pbnRDcmVhdGVIaW5nZTIgKHdvcmxkLCBncm91cCk7IH0NCg0KICB2b2lk
IGNyZWF0ZSAoZFdvcmxkSUQgd29ybGQsIGRKb2ludEdyb3VwSUQgZ3JvdXA9MCkgew0KICAg
IGlmIChfaWQpIGRKb2ludERlc3Ryb3kgKF9pZCk7DQogICAgX2lkID0gZEpvaW50Q3JlYXRl
SGluZ2UyICh3b3JsZCwgZ3JvdXApOw0KICB9DQoNCiAgdm9pZCBzZXRBbmNob3IgKGRSZWFs
IHgsIGRSZWFsIHksIGRSZWFsIHopDQogICAgeyBkSm9pbnRTZXRIaW5nZTJBbmNob3IgKF9p
ZCwgeCwgeSwgeik7IH0NCiAgdm9pZCBzZXRBeGlzMSAoZFJlYWwgeCwgZFJlYWwgeSwgZFJl
YWwgeikNCiAgICB7IGRKb2ludFNldEhpbmdlMkF4aXMxIChfaWQsIHgsIHksIHopOyB9DQog
IHZvaWQgc2V0QXhpczIgKGRSZWFsIHgsIGRSZWFsIHksIGRSZWFsIHopDQogICAgeyBkSm9p
bnRTZXRIaW5nZTJBeGlzMiAoX2lkLCB4LCB5LCB6KTsgfQ0KDQogIHZvaWQgZ2V0QW5jaG9y
IChkVmVjdG9yMyByZXN1bHQpIGNvbnN0DQogICAgeyBkSm9pbnRHZXRIaW5nZTJBbmNob3Ig
KF9pZCwgcmVzdWx0KTsgfQ0KICB2b2lkIGdldEF4aXMxIChkVmVjdG9yMyByZXN1bHQpIGNv
bnN0DQogICAgeyBkSm9pbnRHZXRIaW5nZTJBeGlzMSAoX2lkLCByZXN1bHQpOyB9DQogIHZv
aWQgZ2V0QXhpczIgKGRWZWN0b3IzIHJlc3VsdCkgY29uc3QNCiAgICB7IGRKb2ludEdldEhp
bmdlMkF4aXMyIChfaWQsIHJlc3VsdCk7IH0NCg0KICBkUmVhbCBnZXRBbmdsZTEoKSBjb25z
dA0KICAgIHsgcmV0dXJuIGRKb2ludEdldEhpbmdlMkFuZ2xlMSAoX2lkKTsgfQ0KICBkUmVh
bCBnZXRBbmdsZTFSYXRlKCkgY29uc3QNCiAgICB7IHJldHVybiBkSm9pbnRHZXRIaW5nZTJB
bmdsZTFSYXRlIChfaWQpOyB9DQogIGRSZWFsIGdldEFuZ2xlMlJhdGUoKSBjb25zdA0KICAg
IHsgcmV0dXJuIGRKb2ludEdldEhpbmdlMkFuZ2xlMlJhdGUgKF9pZCk7IH0NCg0KICB2b2lk
IHNldFBhcmFtIChpbnQgcGFyYW1ldGVyLCBkUmVhbCB2YWx1ZSkNCiAgICB7IGRKb2ludFNl
dEhpbmdlMlBhcmFtIChfaWQsIHBhcmFtZXRlciwgdmFsdWUpOyB9DQogIGRSZWFsIGdldFBh
cmFtIChpbnQgcGFyYW1ldGVyKSBjb25zdA0KICAgIHsgcmV0dXJuIGRKb2ludEdldEhpbmdl
MlBhcmFtIChfaWQsIHBhcmFtZXRlcik7IH0NCn07DQoNCg0KY2xhc3MgZEZpeGVkSm9pbnQg
OiBwdWJsaWMgZEpvaW50IHsNCiAgLy8gaW50ZW50aW9uYWxseSB1bmRlZmluZWQsIGRvbid0
IHVzZSB0aGVzZQ0KICBkRml4ZWRKb2ludCAoY29uc3QgZEZpeGVkSm9pbnQgJik7DQogIHZv
aWQgb3BlcmF0b3IgPSAoY29uc3QgZEZpeGVkSm9pbnQgJik7DQoNCnB1YmxpYzoNCiAgZEZp
eGVkSm9pbnQoKSB7IH0NCiAgZEZpeGVkSm9pbnQgKGRXb3JsZElEIHdvcmxkLCBkSm9pbnRH
cm91cElEIGdyb3VwPTApDQogICAgeyBfaWQgPSBkSm9pbnRDcmVhdGVGaXhlZCAod29ybGQs
IGdyb3VwKTsgfQ0KDQogIHZvaWQgY3JlYXRlIChkV29ybGRJRCB3b3JsZCwgZEpvaW50R3Jv
dXBJRCBncm91cD0wKSB7DQogICAgaWYgKF9pZCkgZEpvaW50RGVzdHJveSAoX2lkKTsNCiAg
ICBfaWQgPSBkSm9pbnRDcmVhdGVGaXhlZCAod29ybGQsIGdyb3VwKTsNCiAgfQ0KDQogIHZv
aWQgc2V0KCkNCiAgICB7IGRKb2ludFNldEZpeGVkIChfaWQpOyB9DQp9Ow0KDQoNCmNsYXNz
IGRDb250YWN0Sm9pbnQgOiBwdWJsaWMgZEpvaW50IHsNCiAgLy8gaW50ZW50aW9uYWxseSB1
bmRlZmluZWQsIGRvbid0IHVzZSB0aGVzZQ0KICBkQ29udGFjdEpvaW50IChjb25zdCBkQ29u
dGFjdEpvaW50ICYpOw0KICB2b2lkIG9wZXJhdG9yID0gKGNvbnN0IGRDb250YWN0Sm9pbnQg
Jik7DQoNCnB1YmxpYzoNCiAgZENvbnRhY3RKb2ludCgpIHsgfQ0KICBkQ29udGFjdEpvaW50
IChkV29ybGRJRCB3b3JsZCwgZEpvaW50R3JvdXBJRCBncm91cCwgZENvbnRhY3QgKmNvbnRh
Y3QpDQogICAgeyBfaWQgPSBkSm9pbnRDcmVhdGVDb250YWN0ICh3b3JsZCwgZ3JvdXAsIGNv
bnRhY3QpOyB9DQoNCiAgdm9pZCBjcmVhdGUgKGRXb3JsZElEIHdvcmxkLCBkSm9pbnRHcm91
cElEIGdyb3VwLCBkQ29udGFjdCAqY29udGFjdCkgew0KICAgIGlmIChfaWQpIGRKb2ludERl
c3Ryb3kgKF9pZCk7DQogICAgX2lkID0gZEpvaW50Q3JlYXRlQ29udGFjdCAod29ybGQsIGdy
b3VwLCBjb250YWN0KTsNCiAgfQ0KfTsNCg0KDQpjbGFzcyBkTnVsbEpvaW50IDogcHVibGlj
IGRKb2ludCB7DQogIC8vIGludGVudGlvbmFsbHkgdW5kZWZpbmVkLCBkb24ndCB1c2UgdGhl
c2UNCiAgZE51bGxKb2ludCAoY29uc3QgZE51bGxKb2ludCAmKTsNCiAgdm9pZCBvcGVyYXRv
ciA9IChjb25zdCBkTnVsbEpvaW50ICYpOw0KDQpwdWJsaWM6DQogIGROdWxsSm9pbnQoKSB7
IH0NCiAgZE51bGxKb2ludCAoZFdvcmxkSUQgd29ybGQsIGRKb2ludEdyb3VwSUQgZ3JvdXA9
MCkNCiAgICB7IF9pZCA9IGRKb2ludENyZWF0ZU51bGwgKHdvcmxkLCBncm91cCk7IH0NCg0K
ICB2b2lkIGNyZWF0ZSAoZFdvcmxkSUQgd29ybGQsIGRKb2ludEdyb3VwSUQgZ3JvdXA9MCkg
ew0KICAgIGlmIChfaWQpIGRKb2ludERlc3Ryb3kgKF9pZCk7DQogICAgX2lkID0gZEpvaW50
Q3JlYXRlTnVsbCAod29ybGQsIGdyb3VwKTsNCiAgfQ0KfTsNCg0KDQpjbGFzcyBkQU1vdG9y
Sm9pbnQgOiBwdWJsaWMgZEpvaW50IHsNCiAgLy8gaW50ZW50aW9uYWxseSB1bmRlZmluZWQs
IGRvbid0IHVzZSB0aGVzZQ0KICBkQU1vdG9ySm9pbnQgKGNvbnN0IGRBTW90b3JKb2ludCAm
KTsNCiAgdm9pZCBvcGVyYXRvciA9IChjb25zdCBkQU1vdG9ySm9pbnQgJik7DQoNCnB1Ymxp
YzoNCiAgZEFNb3RvckpvaW50KCkgeyB9DQogIGRBTW90b3JKb2ludCAoZFdvcmxkSUQgd29y
bGQsIGRKb2ludEdyb3VwSUQgZ3JvdXA9MCkNCiAgICB7IF9pZCA9IGRKb2ludENyZWF0ZUFN
b3RvciAod29ybGQsIGdyb3VwKTsgfQ0KDQogIHZvaWQgY3JlYXRlIChkV29ybGRJRCB3b3Js
ZCwgZEpvaW50R3JvdXBJRCBncm91cD0wKSB7DQogICAgaWYgKF9pZCkgZEpvaW50RGVzdHJv
eSAoX2lkKTsNCiAgICBfaWQgPSBkSm9pbnRDcmVhdGVBTW90b3IgKHdvcmxkLCBncm91cCk7
DQogIH0NCg0KICB2b2lkIHNldE1vZGUgKGludCBtb2RlKQ0KICAgIHsgZEpvaW50U2V0QU1v
dG9yTW9kZSAoX2lkLCBtb2RlKTsgfQ0KICBpbnQgZ2V0TW9kZSgpIGNvbnN0DQogICAgeyBy
ZXR1cm4gZEpvaW50R2V0QU1vdG9yTW9kZSAoX2lkKTsgfQ0KDQogIHZvaWQgc2V0TnVtQXhl
cyAoaW50IG51bSkNCiAgICB7IGRKb2ludFNldEFNb3Rvck51bUF4ZXMgKF9pZCwgbnVtKTsg
fQ0KICBpbnQgZ2V0TnVtQXhlcygpIGNvbnN0DQogICAgeyByZXR1cm4gZEpvaW50R2V0QU1v
dG9yTnVtQXhlcyAoX2lkKTsgfQ0KDQogIHZvaWQgc2V0QXhpcyAoaW50IGFudW0sIGludCBy
ZWwsIGRSZWFsIHgsIGRSZWFsIHksIGRSZWFsIHopDQogICAgeyBkSm9pbnRTZXRBTW90b3JB
eGlzIChfaWQsIGFudW0sIHJlbCwgeCwgeSwgeik7IH0NCiAgdm9pZCBnZXRBeGlzIChpbnQg
YW51bSwgZFZlY3RvcjMgcmVzdWx0KSBjb25zdA0KICAgIHsgZEpvaW50R2V0QU1vdG9yQXhp
cyAoX2lkLCBhbnVtLCByZXN1bHQpOyB9DQogIGludCBnZXRBeGlzUmVsIChpbnQgYW51bSkg
Y29uc3QNCiAgICB7IHJldHVybiBkSm9pbnRHZXRBTW90b3JBeGlzUmVsIChfaWQsIGFudW0p
OyB9DQoNCiAgdm9pZCBzZXRBbmdsZSAoaW50IGFudW0sIGRSZWFsIGFuZ2xlKQ0KICAgIHsg
ZEpvaW50U2V0QU1vdG9yQW5nbGUgKF9pZCwgYW51bSwgYW5nbGUpOyB9DQogIGRSZWFsIGdl
dEFuZ2xlIChpbnQgYW51bSkgY29uc3QNCiAgICB7IHJldHVybiBkSm9pbnRHZXRBTW90b3JB
bmdsZSAoX2lkLCBhbnVtKTsgfQ0KICBkUmVhbCBnZXRBbmdsZVJhdGUgKGludCBhbnVtKQ0K
ICAgIHsgcmV0dXJuIGRKb2ludEdldEFNb3RvckFuZ2xlUmF0ZSAoX2lkLGFudW0pOyB9DQoN
CiAgdm9pZCBzZXRQYXJhbSAoaW50IHBhcmFtZXRlciwgZFJlYWwgdmFsdWUpDQogICAgeyBk
Sm9pbnRTZXRBTW90b3JQYXJhbSAoX2lkLCBwYXJhbWV0ZXIsIHZhbHVlKTsgfQ0KICBkUmVh
bCBnZXRQYXJhbSAoaW50IHBhcmFtZXRlcikgY29uc3QNCiAgICB7IHJldHVybiBkSm9pbnRH
ZXRBTW90b3JQYXJhbSAoX2lkLCBwYXJhbWV0ZXIpOyB9DQp9Ow0KDQoNCmNsYXNzIGRHZW9t
IHsNCiAgLy8gaW50ZW50aW9uYWxseSB1bmRlZmluZWQsIGRvbid0IHVzZSB0aGVzZQ0KICBk
R2VvbSAoZEdlb20gJik7DQogIHZvaWQgb3BlcmF0b3I9IChkR2VvbSAmKTsNCg0KcHJvdGVj
dGVkOg0KICBkR2VvbUlEIF9pZDsNCg0KcHVibGljOg0KICBkR2VvbSgpDQogICAgeyBfaWQg
PSAwOyB9DQogIH5kR2VvbSgpDQogICAgeyBpZiAoX2lkKSBkR2VvbURlc3Ryb3kgKF9pZCk7
IH0NCg0KICBkR2VvbUlEIGlkKCkgY29uc3QNCiAgICB7IHJldHVybiBfaWQ7IH0NCiAgb3Bl
cmF0b3IgZEdlb21JRCgpIGNvbnN0DQogICAgeyByZXR1cm4gX2lkOyB9DQoNCiAgdm9pZCBk
ZXN0cm95KCkgew0KICAgIGlmIChfaWQpIGRHZW9tRGVzdHJveSAoX2lkKTsNCiAgICBfaWQg
PSAwOw0KICB9DQoNCiAgaW50IGdldENsYXNzKCkgY29uc3QNCiAgICB7IHJldHVybiBkR2Vv
bUdldENsYXNzIChfaWQpOyB9DQoNCiAgdm9pZCBzZXREYXRhICh2b2lkICpkYXRhKQ0KICAg
IHsgZEdlb21TZXREYXRhIChfaWQsZGF0YSk7IH0NCiAgdm9pZCAqZ2V0RGF0YSgpIGNvbnN0
DQogICAgeyByZXR1cm4gZEdlb21HZXREYXRhIChfaWQpOyB9DQoNCiAgdm9pZCBzZXRCb2R5
IChkQm9keUlEIGIpDQogICAgeyBkR2VvbVNldEJvZHkgKF9pZCxiKTsgfQ0KICBkQm9keUlE
IGdldEJvZHkoKSBjb25zdA0KICAgIHsgcmV0dXJuIGRHZW9tR2V0Qm9keSAoX2lkKTsgfQ0K
DQogIHZvaWQgc2V0UG9zaXRpb24gKGRSZWFsIHgsIGRSZWFsIHksIGRSZWFsIHopDQogICAg
eyBkR2VvbVNldFBvc2l0aW9uIChfaWQseCx5LHopOyB9DQogIGNvbnN0IGRSZWFsICogZ2V0
UG9zaXRpb24oKSBjb25zdA0KICAgIHsgcmV0dXJuIGRHZW9tR2V0UG9zaXRpb24gKF9pZCk7
IH0NCg0KICB2b2lkIHNldFJvdGF0aW9uIChjb25zdCBkTWF0cml4MyBSKQ0KICAgIHsgZEdl
b21TZXRSb3RhdGlvbiAoX2lkLFIpOyB9DQogIGNvbnN0IGRSZWFsICogZ2V0Um90YXRpb24o
KSBjb25zdA0KICAgIHsgcmV0dXJuIGRHZW9tR2V0Um90YXRpb24gKF9pZCk7IH0NCg0KICB2
b2lkIGdldEFBQkIgKGRSZWFsIGFhYmJbNl0pIGNvbnN0DQogICAgeyBkR2VvbUdldEFBQkIg
KF9pZCwgYWFiYik7IH0NCiAgY29uc3QgZFJlYWwgKmdldFNwYWNlQUFCQigpIGNvbnN0DQog
ICAgeyByZXR1cm4gZEdlb21HZXRTcGFjZUFBQkIgKF9pZCk7IH0NCn07DQoNCg0KY2xhc3Mg
ZFNwYWNlIHsNCiAgLy8gaW50ZW50aW9uYWxseSB1bmRlZmluZWQsIGRvbid0IHVzZSB0aGVz
ZQ0KICBkU3BhY2UgKGRTcGFjZSAmKTsNCiAgdm9pZCBvcGVyYXRvcj0gKGRTcGFjZSAmKTsN
Cg0KcHJvdGVjdGVkOg0KICBkU3BhY2VJRCBfaWQ7DQoNCnB1YmxpYzoNCiAgZFNwYWNlICgp
DQogICAgeyBfaWQgPSAwOyB9DQogIH5kU3BhY2UoKQ0KICAgIHsgZFNwYWNlRGVzdHJveSAo
X2lkKTsgfQ0KDQogIGRTcGFjZUlEIGlkKCkgY29uc3QNCiAgICB7IHJldHVybiBfaWQ7IH0N
CiAgb3BlcmF0b3IgZFNwYWNlSUQoKSBjb25zdA0KICAgIHsgcmV0dXJuIF9pZDsgfQ0KDQog
IHZvaWQgYWRkIChkR2VvbUlEIHgpDQogICAgeyBkU3BhY2VBZGQgKF9pZCwgeCk7IH0NCiAg
dm9pZCByZW1vdmUgKGRHZW9tSUQgeCkNCiAgICB7IGRTcGFjZVJlbW92ZSAoX2lkLCB4KTsg
fQ0KICBpbnQgcXVlcnkgKGRHZW9tSUQgeCkNCiAgICB7IHJldHVybiBkU3BhY2VRdWVyeSAo
X2lkLHgpOyB9DQoNCiAgdm9pZCBjb2xsaWRlICh2b2lkICpkYXRhLCBkTmVhckNhbGxiYWNr
ICpjYWxsYmFjaykNCiAgICB7IGRTcGFjZUNvbGxpZGUgKF9pZCxkYXRhLGNhbGxiYWNrKTsg
fQ0KfTsNCg0KDQpjbGFzcyBkU2ltcGxlU3BhY2UgOiBwdWJsaWMgZFNwYWNlIHsNCiAgLy8g
aW50ZW50aW9uYWxseSB1bmRlZmluZWQsIGRvbid0IHVzZSB0aGVzZQ0KICBkU2ltcGxlU3Bh
Y2UgKGRTaW1wbGVTcGFjZSAmKTsNCiAgdm9pZCBvcGVyYXRvcj0gKGRTaW1wbGVTcGFjZSAm
KTsNCg0KcHVibGljOg0KICBkU2ltcGxlU3BhY2UgKCkNCiAgICB7IF9pZCA9IGRTaW1wbGVT
cGFjZUNyZWF0ZSgpOyB9DQp9Ow0KDQoNCmNsYXNzIGRIYXNoU3BhY2UgOiBwdWJsaWMgZFNw
YWNlIHsNCiAgLy8gaW50ZW50aW9uYWxseSB1bmRlZmluZWQsIGRvbid0IHVzZSB0aGVzZQ0K
ICBkSGFzaFNwYWNlIChkSGFzaFNwYWNlICYpOw0KICB2b2lkIG9wZXJhdG9yPSAoZEhhc2hT
cGFjZSAmKTsNCg0KcHVibGljOg0KICBkSGFzaFNwYWNlICgpDQogICAgeyBfaWQgPSBkSGFz
aFNwYWNlQ3JlYXRlKCk7IH0NCiAgdm9pZCBzZXRMZXZlbHMgKGludCBtaW5sZXZlbCwgaW50
IG1heGxldmVsKQ0KICAgIHsgZEhhc2hTcGFjZVNldExldmVscyAoX2lkLG1pbmxldmVsLG1h
eGxldmVsKTsgfQ0KfTsNCg0KDQpjbGFzcyBkU3BoZXJlIDogcHVibGljIGRHZW9tIHsNCiAg
Ly8gaW50ZW50aW9uYWxseSB1bmRlZmluZWQsIGRvbid0IHVzZSB0aGVzZQ0KICBkU3BoZXJl
IChkU3BoZXJlICYpOw0KICB2b2lkIG9wZXJhdG9yPSAoZFNwaGVyZSAmKTsNCg0KcHVibGlj
Og0KICBkU3BoZXJlICgpIHsgfQ0KICBkU3BoZXJlIChkU3BhY2VJRCBzcGFjZSwgZFJlYWwg
cmFkaXVzKQ0KICAgIHsgX2lkID0gZENyZWF0ZVNwaGVyZSAoc3BhY2UsIHJhZGl1cyk7IH0N
Cg0KICB2b2lkIGNyZWF0ZSAoZFNwYWNlSUQgc3BhY2UsIGRSZWFsIHJhZGl1cykgew0KICAg
IGlmIChfaWQpIGRHZW9tRGVzdHJveSAoX2lkKTsNCiAgICBfaWQgPSBkQ3JlYXRlU3BoZXJl
IChzcGFjZSwgcmFkaXVzKTsNCiAgfQ0KDQogIHZvaWQgc2V0UmFkaXVzIChkUmVhbCByYWRp
dXMpDQogICAgeyBkR2VvbVNwaGVyZVNldFJhZGl1cyAoX2lkLCByYWRpdXMpOyB9DQogIGRS
ZWFsIGdldFJhZGl1cygpIGNvbnN0DQogICAgeyByZXR1cm4gZEdlb21TcGhlcmVHZXRSYWRp
dXMgKF9pZCk7IH0NCn07DQoNCg0KY2xhc3MgZEJveCA6IHB1YmxpYyBkR2VvbSB7DQogIC8v
IGludGVudGlvbmFsbHkgdW5kZWZpbmVkLCBkb24ndCB1c2UgdGhlc2UNCiAgZEJveCAoZEJv
eCAmKTsNCiAgdm9pZCBvcGVyYXRvcj0gKGRCb3ggJik7DQoNCnB1YmxpYzoNCiAgZEJveCAo
KSB7IH0NCiAgZEJveCAoZFNwYWNlSUQgc3BhY2UsIGRSZWFsIGx4LCBkUmVhbCBseSwgZFJl
YWwgbHopDQogICAgeyBfaWQgPSBkQ3JlYXRlQm94IChzcGFjZSxseCxseSxseik7IH0NCg0K
ICB2b2lkIGNyZWF0ZSAoZFNwYWNlSUQgc3BhY2UsIGRSZWFsIGx4LCBkUmVhbCBseSwgZFJl
YWwgbHopIHsNCiAgICBpZiAoX2lkKSBkR2VvbURlc3Ryb3kgKF9pZCk7DQogICAgX2lkID0g
ZENyZWF0ZUJveCAoc3BhY2UsbHgsbHksbHopOw0KICB9DQoNCiAgdm9pZCBzZXRMZW5ndGhz
IChkUmVhbCBseCwgZFJlYWwgbHksIGRSZWFsIGx6KQ0KICAgIHsgZEdlb21Cb3hTZXRMZW5n
dGhzIChfaWQsIGx4LCBseSwgbHopOyB9DQogIHZvaWQgZ2V0TGVuZ3RocyAoZFZlY3RvcjMg
cmVzdWx0KSBjb25zdA0KICAgIHsgZEdlb21Cb3hHZXRMZW5ndGhzIChfaWQscmVzdWx0KTsg
fQ0KfTsNCg0KDQpjbGFzcyBkUGxhbmUgOiBwdWJsaWMgZEdlb20gew0KICAvLyBpbnRlbnRp
b25hbGx5IHVuZGVmaW5lZCwgZG9uJ3QgdXNlIHRoZXNlDQogIGRQbGFuZSAoZFBsYW5lICYp
Ow0KICB2b2lkIG9wZXJhdG9yPSAoZFBsYW5lICYpOw0KDQpwdWJsaWM6DQogIGRQbGFuZSgp
IHsgfQ0KICBkUGxhbmUgKGRTcGFjZUlEIHNwYWNlLCBkUmVhbCBhLCBkUmVhbCBiLCBkUmVh
bCBjLCBkUmVhbCBkKQ0KICAgIHsgX2lkID0gZENyZWF0ZVBsYW5lIChzcGFjZSxhLGIsYyxk
KTsgfQ0KDQogIHZvaWQgY3JlYXRlIChkU3BhY2VJRCBzcGFjZSwgZFJlYWwgYSwgZFJlYWwg
YiwgZFJlYWwgYywgZFJlYWwgZCkgew0KICAgIGlmIChfaWQpIGRHZW9tRGVzdHJveSAoX2lk
KTsNCiAgICBfaWQgPSBkQ3JlYXRlUGxhbmUgKHNwYWNlLGEsYixjLGQpOw0KICB9DQoNCiAg
dm9pZCBzZXRQYXJhbXMgKGRSZWFsIGEsIGRSZWFsIGIsIGRSZWFsIGMsIGRSZWFsIGQpDQog
ICAgeyBkR2VvbVBsYW5lU2V0UGFyYW1zIChfaWQsIGEsIGIsIGMsIGQpOyB9DQogIHZvaWQg
Z2V0UGFyYW1zIChkVmVjdG9yNCByZXN1bHQpIGNvbnN0DQogICAgeyBkR2VvbVBsYW5lR2V0
UGFyYW1zIChfaWQscmVzdWx0KTsgfQ0KfTsNCg0KDQpjbGFzcyBkQ0N5bGluZGVyIDogcHVi
bGljIGRHZW9tIHsNCiAgLy8gaW50ZW50aW9uYWxseSB1bmRlZmluZWQsIGRvbid0IHVzZSB0
aGVzZQ0KICBkQ0N5bGluZGVyIChkQ0N5bGluZGVyICYpOw0KICB2b2lkIG9wZXJhdG9yPSAo
ZENDeWxpbmRlciAmKTsNCg0KcHVibGljOg0KICBkQ0N5bGluZGVyKCkgeyB9DQogIGRDQ3ls
aW5kZXIgKGRTcGFjZUlEIHNwYWNlLCBkUmVhbCByYWRpdXMsIGRSZWFsIGxlbmd0aCkNCiAg
ICB7IF9pZCA9IGRDcmVhdGVDQ3lsaW5kZXIgKHNwYWNlLHJhZGl1cyxsZW5ndGgpOyB9DQoN
CiAgdm9pZCBjcmVhdGUgKGRTcGFjZUlEIHNwYWNlLCBkUmVhbCByYWRpdXMsIGRSZWFsIGxl
bmd0aCkgew0KICAgIGlmIChfaWQpIGRHZW9tRGVzdHJveSAoX2lkKTsNCiAgICBfaWQgPSBk
Q3JlYXRlQ0N5bGluZGVyIChzcGFjZSxyYWRpdXMsbGVuZ3RoKTsNCiAgfQ0KDQogIHZvaWQg
c2V0UGFyYW1zIChkUmVhbCByYWRpdXMsIGRSZWFsIGxlbmd0aCkNCiAgICB7IGRHZW9tQ0N5
bGluZGVyU2V0UGFyYW1zIChfaWQsIHJhZGl1cywgbGVuZ3RoKTsgfQ0KICB2b2lkIGdldFBh
cmFtcyAoZFJlYWwgKnJhZGl1cywgZFJlYWwgKmxlbmd0aCkgY29uc3QNCiAgICB7IGRHZW9t
Q0N5bGluZGVyR2V0UGFyYW1zIChfaWQscmFkaXVzLGxlbmd0aCk7IH0NCn07DQoNCg0KY2xh
c3MgZEdlb21Hcm91cCA6IHB1YmxpYyBkR2VvbSB7DQogIC8vIGludGVudGlvbmFsbHkgdW5k
ZWZpbmVkLCBkb24ndCB1c2UgdGhlc2UNCiAgZEdlb21Hcm91cCAoZEdlb21Hcm91cCAmKTsN
CiAgdm9pZCBvcGVyYXRvcj0gKGRHZW9tR3JvdXAgJik7DQoNCnB1YmxpYzoNCiAgZEdlb21H
cm91cCgpIHsgfQ0KICBkR2VvbUdyb3VwIChkU3BhY2VJRCBzcGFjZSkNCiAgICB7IF9pZCA9
IGRDcmVhdGVHZW9tR3JvdXAgKHNwYWNlKTsgfQ0KDQogIHZvaWQgY3JlYXRlIChkU3BhY2VJ
RCBzcGFjZT0wKSB7DQogICAgaWYgKF9pZCkgZEdlb21EZXN0cm95IChfaWQpOw0KICAgIF9p
ZCA9IGRDcmVhdGVHZW9tR3JvdXAgKHNwYWNlKTsNCiAgfQ0KDQogIHZvaWQgYWRkIChkR2Vv
bUlEIHgpDQogICAgeyBkR2VvbUdyb3VwQWRkIChfaWQsIHgpOyB9DQogIHZvaWQgcmVtb3Zl
IChkR2VvbUlEIHgpDQogICAgeyBkR2VvbUdyb3VwUmVtb3ZlIChfaWQsIHgpOyB9DQoNCiAg
aW50IGdldE51bUdlb21zKCkgY29uc3QNCiAgICB7IHJldHVybiBkR2VvbUdyb3VwR2V0TnVt
R2VvbXMgKF9pZCk7IH0NCiAgZEdlb21JRCBnZXRHZW9tIChpbnQgaSkgY29uc3QNCiAgICB7
IHJldHVybiBkR2VvbUdyb3VwR2V0R2VvbSAoX2lkLCBpKTsgfQ0KfTsNCg0KDQpjbGFzcyBk
R2VvbVRyYW5zZm9ybSA6IHB1YmxpYyBkR2VvbSB7DQogIC8vIGludGVudGlvbmFsbHkgdW5k
ZWZpbmVkLCBkb24ndCB1c2UgdGhlc2UNCiAgZEdlb21UcmFuc2Zvcm0gKGRHZW9tVHJhbnNm
b3JtICYpOw0KICB2b2lkIG9wZXJhdG9yPSAoZEdlb21UcmFuc2Zvcm0gJik7DQoNCnB1Ymxp
YzoNCiAgZEdlb21UcmFuc2Zvcm0oKSB7IH0NCiAgZEdlb21UcmFuc2Zvcm0gKGRTcGFjZUlE
IHNwYWNlKQ0KICAgIHsgX2lkID0gZENyZWF0ZUdlb21UcmFuc2Zvcm0gKHNwYWNlKTsgfQ0K
DQogIHZvaWQgY3JlYXRlIChkU3BhY2VJRCBzcGFjZT0wKSB7DQogICAgaWYgKF9pZCkgZEdl
b21EZXN0cm95IChfaWQpOw0KICAgIF9pZCA9IGRDcmVhdGVHZW9tVHJhbnNmb3JtIChzcGFj
ZSk7DQogIH0NCg0KICB2b2lkIHNldEdlb20gKGRHZW9tSUQgZ2VvbSkNCiAgICB7IGRHZW9t
VHJhbnNmb3JtU2V0R2VvbSAoX2lkLCBnZW9tKTsgfQ0KICBkR2VvbUlEIGdldEdlb20oKSBj
b25zdA0KICAgIHsgcmV0dXJuIGRHZW9tVHJhbnNmb3JtR2V0R2VvbSAoX2lkKTsgfQ0KDQog
IHZvaWQgc2V0Q2xlYW51cCAoaW50IG1vZGUpDQogICAgeyBkR2VvbVRyYW5zZm9ybVNldENs
ZWFudXAgKF9pZCxtb2RlKTsgfQ0KICBpbnQgZ2V0Q2xlYW51cCAoZEdlb21JRCBnKQ0KICAg
IHsgcmV0dXJuIGRHZW9tVHJhbnNmb3JtR2V0Q2xlYW51cCAoX2lkKTsgfQ0KfTsNCg0KDQoj
ZW5kaWYNCiNlbmRpZg0K
--------------AE4A85DEE0EE67C92AD2D7AE--
From tetron at interreality.org Thu Nov 21 15:00:02 2002
From: tetron at interreality.org (Peter Amstutz)
Date: Thu Nov 21 15:00:02 2002
Subject: [ODE] Faster ODE
In-Reply-To:
Message-ID:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I haven't looked any of the code involved, but there is one possible
explanation for it being faster on one CPU and slower on another :-) It
sounds like a cache-size issue. If the Athlon has a bigger L1/L2 cache
then the algorithm might be faster overall but if uses more instructions
or space than the current algorithm it could be too big and incur a large
cache-miss penalty on the Celeron (which if I recall correctly was given a
really wimpy L1/L2 cache to keep costs down). Such are the joys of modern
CPU architechtures... There's been some work on "cache-oblivious"
algorithms, which is essentially a technique of designing the algorithm to
work on small, localized and usually recursive subsets of the total
problem (this is especially useful for divide-and-conquor algorithms) so
that once you have a subproblem which fits in cache, solving that
subproblem is efficient without having to know a priori the size of the
processor cache.
Just something to think about -- as I said, I haven't looked at the code
involved so I could completely off base :-)
On Thu, 21 Nov 2002, Daniel Duhprey wrote:
> On Thu, 21 Nov 2002, Henri Hakl wrote:
>
> -->Please check the accuracy and speed using the testsuite provided with ODE.
>
> If I'm using the numbers from the test_ldlt correctly (as a raw time on
> some scale) then on my athlon its about 38% faster and on my celeron its
> roughly twice as slow :).
[ Peter Amstutz ][ amstutz@cs.umass.edu ][ tetron@interreality.org ]
[Lead Programmer][Interreality Project][Virtual Reality for the Internet]
[ VOS: Next Generation Internet Communication][ http://interreality.org ]
[ http://interreality.org/~tetron ][ pgpkey: pgpkeys.mit.edu 18C21DF7 ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
iD8DBQE93VdXaeHUyhjCHfcRAiRMAJ9DdwekLZIYJk0n/fAjtcd3aDG0vACfRze6
mcOSJYkj8/NzQXeW/qoia+k=
=SJZQ
-----END PGP SIGNATURE-----
From martin at metahuman.org Thu Nov 21 17:12:02 2002
From: martin at metahuman.org (Martin C. Martin)
Date: Thu Nov 21 17:12:02 2002
Subject: [ODE] eliminating all state
Message-ID: <3DDD760D.CE7EF366@metahuman.org>
Hey,
So I'm evolving little virtual creatures with ODE, and after the evolution
is done, I take the best ones and "play them back" with graphics and
logging and other fun stuff. What I'd really like is for the simulation
to go through exactly the same calculations with exactly the same roundoff
errors, but at the moment there are small differences that creep up over
time. Russ, you mentioned that ODE uses the correction at one timestep to
estimate the size of the correction at the next timestep. Is there any
way I can reset this between evaluations? Is there anywhere else state is
stored?
For the curious: I'm currently using the debug build with -ffloat-store,
and using exactly the same executable in both cases, so it's guaranteed to
have exactly the same compiler options, etc...
Thanks,
Martin
From russ at q12.org Thu Nov 21 17:25:02 2002
From: russ at q12.org (Russ Smith)
Date: Thu Nov 21 17:25:02 2002
Subject: [ODE] eliminating all state
In-Reply-To: <3DDD760D.CE7EF366@metahuman.org>
Message-ID:
> Russ, you mentioned that ODE uses the correction at one timestep to
> estimate the size of the correction at the next timestep. Is there any
> way I can reset this between evaluations? Is there anywhere else state is
> stored?
i hope i didn't mention this, because its not true. each time step is
completely independent from the last ... the only information that flows
between time steps is the position, orientation and linear/angular
velocity of the bodies. but of course all the ODE parameters will have
effects that spread throughout time precisely because they affect the
positions/velocities.
if you're trying to reproduce exact behavior, there's one thing
to watch out for when saving and restoring state: save and restore the
quaternion, not the rotation matrix, as R is generated from Q not the
other way around. saving and restoring R will result in some
least-significants-bits errors in the restored state.
russ.
--
Russ Smith
http://www.q12.org/
From martin at metahuman.org Thu Nov 21 18:27:02 2002
From: martin at metahuman.org (Martin C. Martin)
Date: Thu Nov 21 18:27:02 2002
Subject: [ODE] eliminating all state
References:
Message-ID: <3DDD87C0.2E18DE49@metahuman.org>
Russ Smith wrote:
>
> > Russ, you mentioned that ODE uses the correction at one timestep to
> > estimate the size of the correction at the next timestep. Is there any
> > way I can reset this between evaluations? Is there anywhere else state is
> > stored?
>
> i hope i didn't mention this, because its not true.
Sorry, I must be confused. But wasn't there some issue with radically
changing the size of the time step? e.g. going from 0.01 sec to 1.0 sec
or vice versa?
- Martin
From nnevatie at welho.com Thu Nov 21 22:16:01 2002
From: nnevatie at welho.com (Niko Nevatie)
Date: Thu Nov 21 22:16:01 2002
Subject: [ODE] Faster ODE
References:
Message-ID: <000f01c291e6$2f741ec0$3abdf3d5@wli>
I benchmarked 'test_ldlt', here are the results.
Configuration:
- AMD Athlon TB 800MHz, 384MB RAM, Windows XP
- ODE 0.03 built with Borland C++ Builder 6.0 (all optimizations on)
Test:
- ODE was built including first the original 'fastldlt.c' and then
'fastldlt_henri.c'
- test_ldlt was on executed using all available parameters (f, s, t)
Results:
with 'fastldlt.c':
----
3449
error = 1.625478e-03, size = 71
error = 2.011657e-04, size = 79
error = 4.785806e-04, size = 83
error = 5.344188e-02, size = 89
error = 3.189385e-03, size = 97
error = 2.305180e-03, size = 101
75
error = 4.673339e-04, size = 71
error = 2.476573e-04, size = 73
error = 1.307763e-03, size = 79
error = 1.248479e-03, size = 83
error = 1.030391e-02, size = 89
error = 1.046956e-03, size = 97
error = 7.226467e-04, size = 101
89
----
with 'fastldlt_henri.c':
----
2046
error = 1.625478e-03, size = 71
error = 2.011657e-04, size = 79
error = 4.785806e-04, size = 83
error = 5.344188e-02, size = 89
error = 3.189385e-03, size = 97
error = 2.305180e-03, size = 101
75
error = 4.673339e-04, size = 71
error = 2.476573e-04, size = 73
error = 1.307763e-03, size = 79
error = 1.248479e-03, size = 83
error = 1.030391e-02, size = 89
error = 1.046956e-03, size = 97
error = 7.226467e-04, size = 101
89
----
Conclusions:
- The outputs of the tests are identical.
- 'fastldlt_henri.c' consumed ~59% of the time taken by 'fastldlt.c', on the
described test configuration.
- As mentioned earlier, the results may vary depending on the CPU and cache
types.
Cheers
----- Original Message -----
From: "Peter Amstutz"
To: "Daniel Duhprey"
Cc:
Sent: Thursday, November 21, 2002 11:59 PM
Subject: Re: [ODE] Faster ODE
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I haven't looked any of the code involved, but there is one possible
> explanation for it being faster on one CPU and slower on another :-) It
> sounds like a cache-size issue. If the Athlon has a bigger L1/L2 cache
> then the algorithm might be faster overall but if uses more instructions
> or space than the current algorithm it could be too big and incur a large
> cache-miss penalty on the Celeron (which if I recall correctly was given a
> really wimpy L1/L2 cache to keep costs down). Such are the joys of modern
> CPU architechtures... There's been some work on "cache-oblivious"
> algorithms, which is essentially a technique of designing the algorithm to
> work on small, localized and usually recursive subsets of the total
> problem (this is especially useful for divide-and-conquor algorithms) so
> that once you have a subproblem which fits in cache, solving that
> subproblem is efficient without having to know a priori the size of the
> processor cache.
>
> Just something to think about -- as I said, I haven't looked at the code
> involved so I could completely off base :-)
>
> On Thu, 21 Nov 2002, Daniel Duhprey wrote:
>
> > On Thu, 21 Nov 2002, Henri Hakl wrote:
> >
> > -->Please check the accuracy and speed using the testsuite provided with
ODE.
> >
> > If I'm using the numbers from the test_ldlt correctly (as a raw time on
> > some scale) then on my athlon its about 38% faster and on my celeron its
> > roughly twice as slow :).
>
> [ Peter Amstutz ][ amstutz@cs.umass.edu ][ tetron@interreality.org ]
> [Lead Programmer][Interreality Project][Virtual Reality for the Internet]
> [ VOS: Next Generation Internet Communication][ http://interreality.org ]
> [ http://interreality.org/~tetron ][ pgpkey: pgpkeys.mit.edu 18C21DF7 ]
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.7 (GNU/Linux)
>
> iD8DBQE93VdXaeHUyhjCHfcRAiRMAJ9DdwekLZIYJk0n/fAjtcd3aDG0vACfRze6
> mcOSJYkj8/NzQXeW/qoia+k=
> =SJZQ
> -----END PGP SIGNATURE-----
>
>
> _______________________________________________
> ODE mailing list
> ODE@q12.org
> http://q12.org/mailman/listinfo/ode
>
From chris.campbell at l8tech.com Thu Nov 21 22:55:02 2002
From: chris.campbell at l8tech.com (Chris Campbell)
Date: Thu Nov 21 22:55:02 2002
Subject: [ODE] eliminating all state
Message-ID:
> is done, I take the best ones and "play them back" with graphics and
> logging and other fun stuff. What I'd really like is for the
> simulation
> to go through exactly the same calculations with exactly the
> same roundoff
> errors, but at the moment there are small differences that
> creep up over
> time. Russ, you mentioned that ODE uses the correction at
Using fixed timestep? I am making a racing game using ODE
for physics which records only keyboard and mouse inputs to
make a replay. That is, to play the replay the entire simulation
is recalculated. Initially I was a little worried that error might
creep in after a while but after a LONG time experimenting
I convinced myself that there was no state held by ODE, and
that the idea should work. It does, but only with fixed timestep.
Also, a recording made with the debug binary will not replay
properly with the release binary and vice versa.
Another thing which seems to be necessary is that the cpu
should conform to IEEE floating point standards in order
for replays to work deterministically on a different computer.
ChrisC
From dmcclurg at pandemicstudios.com.au Thu Nov 21 23:13:02 2002
From: dmcclurg at pandemicstudios.com.au (David McClurg)
Date: Thu Nov 21 23:13:02 2002
Subject: [ODE] is ball and socket joint anchor relative to body1?
Message-ID:
>From the docs...
---
void dJointSetBallAnchor (dJointID, dReal x, dReal y, dReal z);
Set the joint anchor point.
---
it's not clear to me what coordinate frame the anchor point is in...
---
For the parameter getting functions, if the system is out of alignment (i.e. there is some joint error) then the anchor/axis values will be correct with respect to body 1 only (or body 2 if you specified body 1 as zero in the dJointAttach() function).
The default anchor for all joints is (0,0,0). The default axis for all joints is (1,0,0).
---
does this mean the anchor point is relative to body1 ?
From dmcclurg at pandemicstudios.com.au Thu Nov 21 23:53:02 2002
From: dmcclurg at pandemicstudios.com.au (David McClurg)
Date: Thu Nov 21 23:53:02 2002
Subject: [ODE] stress testing and box stacking instability
Message-ID:
This is a multi-part message in MIME format.
------_=_NextPart_001_01C291F3.A8E1CEDE
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
I'm trying to use stacked boxes in my game and I ran into the box =
stacking instability mentioned previously on this list. That got me to =
reading the Gamasutra article "Product Review of Physics Engines, Part =
One: The Stress Tests" and I thought it might be useful to put together =
the stress test suite for ODE.
It was easy to get tests 1-6 coded and the only one that did badly was =
Test 2: "A slightly larger cube is dropped on a smaller cube. This was =
a variation on the first test in that the difference between the cubes' =
sizes was much smaller. This test was meant to be a "gimme" and should =
just work." Expected result: cubes should drop straight on top of each =
other and come to immediate rest.
I attached a modified test_boxstack.cpp which shows what happens. The =
top box dances around for a long time and eventually falls off the top =
box. In Havok, i think they might be freezing/sleeping boxes in this =
situation. Does the solution lie in proper detection of this situation =
or in better contact generation?
<>=20
------_=_NextPart_001_01C291F3.A8E1CEDE
Content-Type: application/octet-stream;
name="test_boxstack.cpp"
Content-Transfer-Encoding: base64
Content-Description: test_boxstack.cpp
Content-Disposition: attachment;
filename="test_boxstack.cpp"
LyoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioNCiogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICoNCiogT3BlbiBEeW5hbWljcyBFbmdp
bmUsIENvcHlyaWdodCAoQykgMjAwMSwyMDAyIFJ1c3NlbGwgTC4gU21pdGguICAgICAgICoNCiog
QWxsIHJpZ2h0cyByZXNlcnZlZC4gIEVtYWlsOiBydXNzQHExMi5vcmcgICBXZWI6IHd3dy5xMTIu
b3JnICAgICAgICAgICoNCiogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICoNCiogVGhpcyBsaWJyYXJ5IGlzIGZyZWUg
c29mdHdhcmU7IHlvdSBjYW4gcmVkaXN0cmlidXRlIGl0IGFuZC9vciAgICAgICAgICoNCiogbW9k
aWZ5IGl0IHVuZGVyIHRoZSB0ZXJtcyBvZiBFSVRIRVI6ICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICoNCiogICAoMSkgVGhlIEdOVSBMZXNzZXIgR2VuZXJhbCBQdWJsaWMgTGljZW5z
ZSBhcyBwdWJsaXNoZWQgYnkgdGhlIEZyZWUgICoNCiogICAgICAgU29mdHdhcmUgRm91bmRhdGlv
bjsgZWl0aGVyIHZlcnNpb24gMi4xIG9mIHRoZSBMaWNlbnNlLCBvciAoYXQgICoNCiogICAgICAg
eW91ciBvcHRpb24pIGFueSBsYXRlciB2ZXJzaW9uLiBUaGUgdGV4dCBvZiB0aGUgR05VIExlc3Nl
ciAgICAgICoNCiogICAgICAgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSBpcyBpbmNsdWRlZCB3aXRo
IHRoaXMgbGlicmFyeSBpbiB0aGUgICAgICoNCiogICAgICAgZmlsZSBMSUNFTlNFLlRYVC4gICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICoNCiogICAoMikgVGhl
IEJTRC1zdHlsZSBsaWNlbnNlIHRoYXQgaXMgaW5jbHVkZWQgd2l0aCB0aGlzIGxpYnJhcnkgaW4g
ICAgICoNCiogICAgICAgdGhlIGZpbGUgTElDRU5TRS1CU0QuVFhULiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICoNCiogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICoNCiogVGhpcyBsaWJyYXJ5
IGlzIGRpc3RyaWJ1dGVkIGluIHRoZSBob3BlIHRoYXQgaXQgd2lsbCBiZSB1c2VmdWwsICAgICAg
ICoNCiogYnV0IFdJVEhPVVQgQU5ZIFdBUlJBTlRZOyB3aXRob3V0IGV2ZW4gdGhlIGltcGxpZWQg
d2FycmFudHkgb2YgICAgICAgICoNCiogTUVSQ0hBTlRBQklMSVRZIG9yIEZJVE5FU1MgRk9SIEEg
UEFSVElDVUxBUiBQVVJQT1NFLiBTZWUgdGhlIGZpbGVzICAgICoNCiogTElDRU5TRS5UWFQgYW5k
IExJQ0VOU0UtQlNELlRYVCBmb3IgbW9yZSBkZXRhaWxzLiAgICAgICAgICAgICAgICAgICAgICoN
CiogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICoNCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKiovDQoNCiNpbmNsdWRlIDxvZGUvb2Rl
Lmg+DQojaW5jbHVkZSA8ZHJhd3N0dWZmL2RyYXdzdHVmZi5oPg0KDQojaWZkZWYgTVNWQw0KI3By
YWdtYSB3YXJuaW5nKGRpc2FibGU6NDI0NCA0MzA1KSAgLy8gZm9yIFZDKyssIG5vIHByZWNpc2lv
biBsb3NzIGNvbXBsYWludHMNCiNlbmRpZg0KDQovLyBzZWxlY3QgY29ycmVjdCBkcmF3aW5nIGZ1
bmN0aW9ucw0KDQojaWZkZWYgZERPVUJMRQ0KI2RlZmluZSBkc0RyYXdCb3ggZHNEcmF3Qm94RA0K
I2RlZmluZSBkc0RyYXdTcGhlcmUgZHNEcmF3U3BoZXJlRA0KI2RlZmluZSBkc0RyYXdDeWxpbmRl
ciBkc0RyYXdDeWxpbmRlckQNCiNkZWZpbmUgZHNEcmF3Q2FwcGVkQ3lsaW5kZXIgZHNEcmF3Q2Fw
cGVkQ3lsaW5kZXJEDQojZW5kaWYNCg0KDQovLyBzb21lIGNvbnN0YW50cw0KDQojZGVmaW5lIE5V
TSAyMAkJCS8vIG1heCBudW1iZXIgb2Ygb2JqZWN0cw0KI2RlZmluZSBERU5TSVRZICg1LjApCQkv
LyBkZW5zaXR5IG9mIGFsbCBvYmplY3RzDQojZGVmaW5lIEdQQiAzCQkJLy8gbWF4aW11bSBudW1i
ZXIgb2YgZ2VvbWV0cmllcyBwZXIgYm9keQ0KDQoNCi8vIGR5bmFtaWNzIGFuZCBjb2xsaXNpb24g
b2JqZWN0cw0KDQpzdHJ1Y3QgTXlPYmplY3Qgew0KICBkQm9keUlEIGJvZHk7CQkJLy8gdGhlIGJv
ZHkNCiAgZEdlb21JRCBnZW9tW0dQQl07CQkvLyBnZW9tZXRyaWVzIHJlcHJlc2VudGluZyB0aGlz
IGJvZHkNCn07DQoNCnN0YXRpYyBkV29ybGRJRCB3b3JsZDsNCnN0YXRpYyBkU3BhY2VJRCBzcGFj
ZTsNCnN0YXRpYyBkSm9pbnRHcm91cElEIGNvbnRhY3Rncm91cDsNCg0Kc3RhdGljIE15T2JqZWN0
IG9ialtOVU1dOw0Kc3RhdGljIGludCBudW09MDsJCS8vIG51bWJlciBvZiBvYmplY3RzIGluIHNp
bXVsYXRpb24NCnN0YXRpYyBpbnQgbmV4dG9iaj0wOwkJLy8gbmV4dCBvYmplY3QgdG8gcmVjeWNs
ZSBpZiBudW09PU5VTQ0Kc3RhdGljIGludCBzZWxlY3RlZCA9IC0xOwkvLyBzZWxlY3RlZCBvYmpl
Y3QNCnN0YXRpYyBpbnQgc2hvd19hYWJiID0gMDsJLy8gc2hvdyBnZW9tIEFBQkJzPw0KDQoNCg0K
Ly8gdGhpcyBpcyBjYWxsZWQgYnkgZFNwYWNlQ29sbGlkZSB3aGVuIHR3byBvYmplY3RzIGluIHNw
YWNlIGFyZQ0KLy8gcG90ZW50aWFsbHkgY29sbGlkaW5nLg0KDQpzdGF0aWMgdm9pZCBuZWFyQ2Fs
bGJhY2sgKHZvaWQgKmRhdGEsIGRHZW9tSUQgbzEsIGRHZW9tSUQgbzIpDQp7DQogIGludCBpOw0K
ICAvLyBpZiAobzEtPmJvZHkgJiYgbzItPmJvZHkpIHJldHVybjsNCg0KICAvLyBleGl0IHdpdGhv
dXQgZG9pbmcgYW55dGhpbmcgaWYgdGhlIHR3byBib2RpZXMgYXJlIGNvbm5lY3RlZCBieSBhIGpv
aW50DQogIGRCb2R5SUQgYjEgPSBkR2VvbUdldEJvZHkobzEpOw0KICBkQm9keUlEIGIyID0gZEdl
b21HZXRCb2R5KG8yKTsNCiAgaWYgKGIxICYmIGIyICYmIGRBcmVDb25uZWN0ZWQgKGIxLGIyKSkg
cmV0dXJuOw0KDQogIGRDb250YWN0IGNvbnRhY3RbM107CQkJLy8gdXAgdG8gMyBjb250YWN0cyBw
ZXIgYm94DQogIGZvciAoaT0wOyBpPDM7IGkrKykgew0KICAgIGNvbnRhY3RbaV0uc3VyZmFjZS5t
b2RlID0gZENvbnRhY3RCb3VuY2U7IC8vZENvbnRhY3RNdTI7DQogICAgY29udGFjdFtpXS5zdXJm
YWNlLm11ID0gZEluZmluaXR5Ow0KICAgIGNvbnRhY3RbaV0uc3VyZmFjZS5tdTIgPSAwOw0KICAg
IGNvbnRhY3RbaV0uc3VyZmFjZS5ib3VuY2UgPSAwLmY7DQogICAgY29udGFjdFtpXS5zdXJmYWNl
LmJvdW5jZV92ZWwgPSAwLjE7DQogIH0NCiAgaWYgKGludCBudW1jID0gZENvbGxpZGUgKG8xLG8y
LDMsJmNvbnRhY3RbMF0uZ2VvbSxzaXplb2YoZENvbnRhY3QpKSkgew0KICAgIC8vIGRNYXRyaXgz
IFJJOw0KICAgIC8vIGRSU2V0SWRlbnRpdHkgKFJJKTsNCiAgICAvLyBjb25zdCBkUmVhbCBzc1sz
XSA9IHswLjAyLDAuMDIsMC4wMn07DQogICAgZm9yIChpPTA7IGk8bnVtYzsgaSsrKSB7DQogICAg
ICBkSm9pbnRJRCBjID0gZEpvaW50Q3JlYXRlQ29udGFjdCAod29ybGQsY29udGFjdGdyb3VwLGNv
bnRhY3QraSk7DQogICAgICBkSm9pbnRBdHRhY2ggKGMsYjEsYjIpOw0KICAgICAgLy8gZHNEcmF3
Qm94IChjb250YWN0W2ldLmdlb20ucG9zLFJJLHNzKTsNCiAgICB9DQogIH0NCn0NCg0KDQovLyBz
dGFydCBzaW11bGF0aW9uIC0gc2V0IHZpZXdwb2ludA0KDQpzdGF0aWMgdm9pZCBzdGFydCgpDQp7
DQogIHN0YXRpYyBmbG9hdCB4eXpbM10gPSB7MC5mLC0xNC5mLDkuZn07DQogIHN0YXRpYyBmbG9h
dCBocHJbM10gPSB7OTAuZiwtMjUuZiwwLmZ9Ow0KICBkc1NldFZpZXdwb2ludCAoeHl6LGhwcik7
DQoNCiAgcHJpbnRmICgiVG8gcmVzZXQgdGhlIHRlc3QsIHByZXNzIHIuXG4iKTsNCiAgcHJpbnRm
ICgiVG8gc2VsZWN0IGFuIG9iamVjdCwgcHJlc3Mgc3BhY2UuXG4iKTsNCiAgcHJpbnRmICgiVG8g
ZGlzYWJsZSB0aGUgc2VsZWN0ZWQgb2JqZWN0LCBwcmVzcyBkLlxuIik7DQogIHByaW50ZiAoIlRv
IGVuYWJsZSB0aGUgc2VsZWN0ZWQgb2JqZWN0LCBwcmVzcyBlLlxuIik7DQogIHByaW50ZiAoIlRv
IHRvZ2dsZSBzaG93aW5nIHRoZSBnZW9tIEFBQkJzLCBwcmVzcyBhLlxuIik7DQp9DQoNCg0KY2hh
ciBsb2Nhc2UgKGNoYXIgYykNCnsNCiAgaWYgKGMgPj0gJ0EnICYmIGMgPD0gJ1onKSByZXR1cm4g
YyAtICgnYSctJ0EnKTsNCiAgZWxzZSByZXR1cm4gYzsNCn0NCg0Kc3RhdGljIHZvaWQgZGVzdHJv
eUFsbE9iamVjdHMgKCkNCnsNCiAgZm9yIChpbnQgaT0wOyBpPG51bTsgaSsrKQ0KICB7DQogICAg
Ly8gZGVzdHJveSB0aGUgYm9keSBhbmQgZ2VvbXMgZm9yIHNsb3QgaQ0KICAgIGlmIChvYmpbaV0u
Ym9keSkgZEJvZHlEZXN0cm95IChvYmpbaV0uYm9keSk7DQogICAgZm9yIChpbnQgaz0wOyBrIDwg
R1BCOyBrKyspDQogICAgew0KICAgICAgaWYgKG9ialtpXS5nZW9tW2tdKSBkR2VvbURlc3Ryb3kg
KG9ialtpXS5nZW9tW2tdKTsNCiAgICB9DQogICAgbWVtc2V0ICgmb2JqW2ldLDAsc2l6ZW9mKG9i
altpXSkpOw0KICB9DQogIG51bSA9IDA7DQogIG5leHRvYmogPSAwOw0KICBzZWxlY3RlZCA9IC0x
Ow0KfQ0KDQovLyBjYWxsZWQgd2hlbiBhIGtleSBwcmVzc2VkDQoNCnN0YXRpYyB2b2lkIGNvbW1h
bmQgKGludCBjbWQpDQp7DQogIGludCBpLGosazsNCiAgZFJlYWwgc2lkZXNbM107DQogIGRNYXNz
IG07DQoNCiAgY21kID0gbG9jYXNlIChjbWQpOw0KDQogIGlmIChjbWQgPT0gJ3InKQ0KICB7DQog
ICAgLy8gVGVzdCAyOiBkcm9wIHNsaWdodGVyIGxhcmdlciBib3ggb24gYSBzbWFsbGVyIGJveA0K
ICAgIC8vIEV4cGVjdGVkIHJlc3VsdHM6IG5vIGJvdW5jZSBhbmQgY29tZSB0byBpbW1lZGlhdGUg
cmVzdA0KICAgIGRlc3Ryb3lBbGxPYmplY3RzKCk7DQoNCiAgICBpPW51bSsrOw0KICAgIG9ialtp
XS5ib2R5ID0gZEJvZHlDcmVhdGUgKHdvcmxkKTsNCiAgICBkQm9keVNldFBvc2l0aW9uIChvYmpb
aV0uYm9keSwgMCwgMCwgOSk7DQogICAgZEJvZHlTZXREYXRhIChvYmpbaV0uYm9keSwodm9pZCop
IGkpOw0KICAgIG9ialtpXS5nZW9tWzBdID0gZENyZWF0ZUJveCAoc3BhY2UsIDUsIDUsIDUpOw0K
ICAgIGRHZW9tU2V0Qm9keSAob2JqW2ldLmdlb21bMF0sb2JqW2ldLmJvZHkpOw0KICAgIGRNYXNz
U2V0Qm94ICgmbSwgNSwgNSwgNSwgNSk7ICAvLyA2MjVrZw0KICAgIGRCb2R5U2V0TWFzcyAob2Jq
W2ldLmJvZHksJm0pOw0KDQogICAgaT1udW0rKzsNCiAgICBvYmpbaV0uYm9keSA9IGRCb2R5Q3Jl
YXRlICh3b3JsZCk7DQogICAgZEJvZHlTZXRQb3NpdGlvbiAob2JqW2ldLmJvZHksIDAsIDAsIDMp
Ow0KICAgIGRCb2R5U2V0RGF0YSAob2JqW2ldLmJvZHksKHZvaWQqKSBpKTsNCiAgICBvYmpbaV0u
Z2VvbVswXSA9IGRDcmVhdGVCb3ggKHNwYWNlLCA0LCA0LCA0KTsNCiAgICBkR2VvbVNldEJvZHkg
KG9ialtpXS5nZW9tWzBdLG9ialtpXS5ib2R5KTsNCiAgICBkTWFzc1NldEJveCAoJm0sIDUsIDQs
IDQsIDQpOyAgLy8gMzIwa2cNCiAgICBkQm9keVNldE1hc3MgKG9ialtpXS5ib2R5LCZtKTsNCiAg
fQ0KDQogIGlmIChjbWQgPT0gJyAnKSB7DQogICAgc2VsZWN0ZWQrKzsNCiAgICBpZiAoc2VsZWN0
ZWQgPj0gbnVtKSBzZWxlY3RlZCA9IDA7DQogICAgaWYgKHNlbGVjdGVkIDwgMCkgc2VsZWN0ZWQg
PSAwOw0KICB9DQogIGVsc2UgaWYgKGNtZCA9PSAnZCcgJiYgc2VsZWN0ZWQgPj0gMCAmJiBzZWxl
Y3RlZCA8IG51bSkgew0KICAgIGRCb2R5RGlzYWJsZSAob2JqW3NlbGVjdGVkXS5ib2R5KTsNCiAg
fQ0KICBlbHNlIGlmIChjbWQgPT0gJ2UnICYmIHNlbGVjdGVkID49IDAgJiYgc2VsZWN0ZWQgPCBu
dW0pIHsNCiAgICBkQm9keUVuYWJsZSAob2JqW3NlbGVjdGVkXS5ib2R5KTsNCiAgfQ0KICBlbHNl
IGlmIChjbWQgPT0gJ2EnKSB7DQogICAgc2hvd19hYWJiIF49IDE7DQogIH0NCn0NCg0KDQovLyBk
cmF3IGEgZ2VvbQ0KDQp2b2lkIGRyYXdHZW9tIChkR2VvbUlEIGcsIGNvbnN0IGRSZWFsICpwb3Ms
IGNvbnN0IGRSZWFsICpSLCBpbnQgc2hvd19hYWJiKQ0Kew0KICBpZiAoIWcpIHJldHVybjsNCiAg
aWYgKCFwb3MpIHBvcyA9IGRHZW9tR2V0UG9zaXRpb24gKGcpOw0KICBpZiAoIVIpIFIgPSBkR2Vv
bUdldFJvdGF0aW9uIChnKTsNCg0KICBpbnQgdHlwZSA9IGRHZW9tR2V0Q2xhc3MgKGcpOw0KICBp
ZiAodHlwZSA9PSBkQm94Q2xhc3MpIHsNCiAgICBkVmVjdG9yMyBzaWRlczsNCiAgICBkR2VvbUJv
eEdldExlbmd0aHMgKGcsc2lkZXMpOw0KICAgIGRzRHJhd0JveCAocG9zLFIsc2lkZXMpOw0KICB9
DQoNCiAgaWYgKHNob3dfYWFiYikgew0KICAgIC8vIGRyYXcgdGhlIGJvdW5kaW5nIGJveCBmb3Ig
dGhpcyBnZW9tDQogICAgZFJlYWwgYWFiYls2XTsNCiAgICBkR2VvbUdldEFBQkIgKGcsYWFiYik7
DQogICAgZFZlY3RvcjMgYmJwb3M7DQogICAgaW50IGk7DQogICAgZm9yIChpPTA7IGk8MzsgaSsr
KSBiYnBvc1tpXSA9IDAuNSooYWFiYltpKjJdICsgYWFiYltpKjIrMV0pOw0KICAgIGRWZWN0b3Iz
IGJic2lkZXM7DQogICAgZm9yIChpPTA7IGk8MzsgaSsrKSBiYnNpZGVzW2ldID0gYWFiYltpKjIr
MV0gLSBhYWJiW2kqMl07DQogICAgZE1hdHJpeDMgUkk7DQogICAgZFJTZXRJZGVudGl0eSAoUkkp
Ow0KICAgIGRzU2V0Q29sb3JBbHBoYSAoMSwwLDAsMC41KTsNCiAgICBkc0RyYXdCb3ggKGJicG9z
LFJJLGJic2lkZXMpOw0KICB9DQp9DQoNCg0KLy8gc2ltdWxhdGlvbiBsb29wDQoNCnN0YXRpYyB2
b2lkIHNpbUxvb3AgKGludCBwYXVzZSkNCnsNCiAgZHNTZXRDb2xvciAoMCwwLDIpOw0KICBkU3Bh
Y2VDb2xsaWRlIChzcGFjZSwwLCZuZWFyQ2FsbGJhY2spOw0KICBpZiAoIXBhdXNlKSBkV29ybGRT
dGVwICh3b3JsZCwwLjA1KTsNCg0KICAvLyByZW1vdmUgYWxsIGNvbnRhY3Qgam9pbnRzDQogIGRK
b2ludEdyb3VwRW1wdHkgKGNvbnRhY3Rncm91cCk7DQoNCiAgZHNTZXRDb2xvciAoMSwxLDApOw0K
ICBkc1NldFRleHR1cmUgKERTX1dPT0QpOw0KICBmb3IgKGludCBpPTA7IGk8bnVtOyBpKyspIHsN
CiAgICBmb3IgKGludCBqPTA7IGogPCBHUEI7IGorKykgew0KICAgICAgaWYgKGk9PXNlbGVjdGVk
KSB7DQogICAgICAgIGRzU2V0Q29sb3IgKDAsMC43LDEpOw0KICAgICAgfQ0KICAgICAgZWxzZSBp
ZiAoISBkQm9keUlzRW5hYmxlZCAob2JqW2ldLmJvZHkpKSB7DQogICAgICAgIGRzU2V0Q29sb3Ig
KDEsMCwwKTsNCiAgICAgIH0NCiAgICAgIGVsc2Ugew0KICAgICAgICBkc1NldENvbG9yICgxLDEs
MCk7DQogICAgICB9DQogICAgICBkcmF3R2VvbSAob2JqW2ldLmdlb21bal0sMCwwLHNob3dfYWFi
Yik7DQogICAgfQ0KICB9DQp9DQoNCg0KaW50IG1haW4gKGludCBhcmdjLCBjaGFyICoqYXJndikN
CnsNCiAgLy8gc2V0dXAgcG9pbnRlcnMgdG8gZHJhd3N0dWZmIGNhbGxiYWNrIGZ1bmN0aW9ucw0K
ICBkc0Z1bmN0aW9ucyBmbjsNCiAgZm4udmVyc2lvbiA9IERTX1ZFUlNJT047DQogIGZuLnN0YXJ0
ID0gJnN0YXJ0Ow0KICBmbi5zdGVwID0gJnNpbUxvb3A7DQogIGZuLmNvbW1hbmQgPSAmY29tbWFu
ZDsNCiAgZm4uc3RvcCA9IDA7DQogIGZuLnBhdGhfdG9fdGV4dHVyZXMgPSAiLi4vLi4vZHJhd3N0
dWZmL3RleHR1cmVzIjsNCg0KICAvLyBjcmVhdGUgd29ybGQNCg0KICB3b3JsZCA9IGRXb3JsZENy
ZWF0ZSgpOw0KICBzcGFjZSA9IGRIYXNoU3BhY2VDcmVhdGUgKDApOw0KICBjb250YWN0Z3JvdXAg
PSBkSm9pbnRHcm91cENyZWF0ZSAoMCk7DQogIGRXb3JsZFNldEdyYXZpdHkgKHdvcmxkLDAsMCwt
OS44Zik7DQogIGRXb3JsZFNldENGTSAod29ybGQsMWUtNSk7DQogIGRDcmVhdGVQbGFuZSAoc3Bh
Y2UsMCwwLDEsMCk7DQogIG1lbXNldCAob2JqLDAsc2l6ZW9mKG9iaikpOw0KDQogIGNvbW1hbmQg
KCdyJyk7DQoNCiAgLy8gcnVuIHNpbXVsYXRpb24NCiAgZHNTaW11bGF0aW9uTG9vcCAoYXJnYyxh
cmd2LDM1MiwyODgsJmZuKTsNCg0KICBkSm9pbnRHcm91cERlc3Ryb3kgKGNvbnRhY3Rncm91cCk7
DQogIGRTcGFjZURlc3Ryb3kgKHNwYWNlKTsNCiAgZFdvcmxkRGVzdHJveSAod29ybGQpOw0KDQog
IHJldHVybiAwOw0KfQ0K
------_=_NextPart_001_01C291F3.A8E1CEDE--
From Nguyen Binh Fri Nov 22 01:23:02 2002
From: Nguyen Binh (Nguyen Binh)
Date: Fri Nov 22 01:23:02 2002
Subject: Re[2]: [ODE] Faster ODE
In-Reply-To: <000f01c291e6$2f741ec0$3abdf3d5@wli>
References:
<000f01c291e6$2f741ec0$3abdf3d5@wli>
Message-ID: <9822448108.20021122151447@glassegg.com>
For me,
P III 550 Mhz , XP SP1 ,VS.NET
Latest CVS source.
Optimize all enable.
---------
Use Henri's code :
23805
error = 1.625478e-003, size = 71
error = 2.011657e-004, size = 79
error = 4.785806e-004, size = 83
error = 5.344188e-002, size = 89
error = 3.189385e-003, size = 97
error = 2.305180e-003, size = 101
485
error = 4.673339e-004, size = 71
error = 2.476573e-004, size = 73
error = 1.307763e-003, size = 79
error = 1.248479e-003, size = 83
error = 1.030391e-002, size = 89
error = 1.046956e-003, size = 97
error = 7.226467e-004, size = 101
707
---------
Original code:
23804
error = 1.625478e-003, size = 71
error = 2.011657e-004, size = 79
error = 4.785806e-004, size = 83
error = 5.344188e-002, size = 89
error = 3.189385e-003, size = 97
error = 2.305180e-003, size = 101
485
error = 4.673339e-004, size = 71
error = 2.476573e-004, size = 73
error = 1.307763e-003, size = 79
error = 1.248479e-003, size = 83
error = 1.030391e-002, size = 89
error = 1.046956e-003, size = 97
error = 7.226467e-004, size = 101
707
-------------
My conclusion :
+ Both exactly the same for my case.
Hey Niko!
Are you sure about your result?
I see your PC run 10 times faster than mine. ( :-( ) .
Nguyen Binh
From nlin at nlin.net Fri Nov 22 03:15:02 2002
From: nlin at nlin.net (nlin@nlin.net)
Date: Fri Nov 22 03:15:02 2002
Subject: ODE Debug behaves differently than ODE release (was Re: [ODE] eliminating all state)
Message-ID: <20021122114259.GA29965@nlin.net>
On Fri, Nov 22, 2002 at 03:02:44PM +0900, Chris Campbell wrote:
> Also, a recording made with the debug binary will not replay
> properly with the release binary and vice versa.
Recently I have been investigating exactly this determinism problem and have
come to the same conclusion as Chris: ODE's behavior can be deterministically
reproduced with a fixed timestep, but the debug and release versions
act differently.
This is somewhat unsettling for me. I am reasonably certain that is is
ODE itself which is behaving differently in debug and release modes,
not my application. I don't have time to investigate this in detail
now, but I wanted to add a second confirmation to Chris's: ODE debug
behaves differently than ODE release.
One more note which may provide a clue as to the source of the
discrepancy. My app access ODE through custom wrapper classes (in
file1.cpp), and I also declared a custom collision space (in file2.cpp).
If I compile my entire app in debug mode, but compile file1.cpp and file2.cpp
in release mode and link the app with the release ODE lib, then behavior
of the entire debug app is identical with the behavior of the release app.
If I compile file1.cpp in debug mode, OR compile file2.cpp in debug
mode, OR link with the ODE debug library, then divergent behavior
results.
That merely recompiling my *interface* class to ODE causes divergent
behavior seems to indicate this may be a data alignment, calling
convention, or other subtle compiler flag issue.
This is on MSVC 6.
If I recall correctly, I believe that even the ODE demos acted differently
in debug and release modes, so anyone wishing to reproduce this divergent
behavior should be able to do so easily.
-Norman
From nlin at nlin.net Fri Nov 22 03:35:02 2002
From: nlin at nlin.net (nlin@nlin.net)
Date: Fri Nov 22 03:35:02 2002
Subject: [ODE] eliminating all state
Message-ID: <20021122120304.GA30898@nlin.net>
On Thu, Nov 21, 2002 at 05:24:02PM -0700, Russ Smith wrote:
> > Russ, you mentioned that ODE uses the correction at one timestep to
> > estimate the size of the correction at the next timestep. Is there any
> > way I can reset this between evaluations? Is there anywhere else state is
> > stored?
>
> i hope i didn't mention this, because its not true. each time step is
> completely independent from the last ... the only information that flows
> between time steps is the position, orientation and linear/angular
> velocity of the bodies. but of course all the ODE parameters will have
> effects that spread throughout time precisely because they affect the
> positions/velocities.
Russ,
The message from which you are being indirectly quoted is:
http://q12.org/pipermail/ode/2002-April/001107.html
The relevant passage:
On Wed, Apr 10, 2002, Russ Smith wrote:
> in the small-large
> timestep case it fails, because the velocity correction is timestep
> dependent (i.e. the small velocity correction calculated during the
> small timestep becomes a much-too-large correction during the large
> timestep). there is a good fix for this problem, which i will
> eventually add to ODE (as time permits). there'll be a dWorld switch
> to turn it on, as there is a slight performance cost.
Has the "fix" mentioned above been implemented? What is the idea behind
the fix?
-Norman
From p.terdiman at wanadoo.fr Fri Nov 22 03:57:01 2002
From: p.terdiman at wanadoo.fr (Pierre Terdiman)
Date: Fri Nov 22 03:57:01 2002
Subject: ODE Debug behaves differently than ODE release (was Re: [ODE] eliminating all state)
References: <20021122114259.GA29965@nlin.net>
Message-ID: <00cb01c29215$84b94ca0$0e00000a@pierre>
> This is somewhat unsettling for me. I am reasonably certain that is is
> ODE itself which is behaving differently in debug and release modes,
> not my application. I don't have time to investigate this in detail
> now, but I wanted to add a second confirmation to Chris's: ODE debug
> behaves differently than ODE release.
Well, that's normal. Due to limited FPU precision,simply reordering some
operations can produce slightly different results (and reordering happens a
lot when the compiler optimizes the code, of course). Also, something like
this :
a = b / 2.0f;
...can be compiled with the divide in Debug mode, but actually be
transformed into :
a = b * 0.5f;
...in Release. Producing different results, that can add up quickly in a
physics engine.
You can try the following compiler option on VC++ :
Project Settings -> C/C++ -> Optimizations ->Improve float consistency
Sometimes it helps. But in some cases it can be very hard to get the exact
same behaviours in Debug & Release. There was a Gamasutra article explaining
related problems, when you try to record an animation and replay it in the
same exact way. That's surprisingly difficult.
Pierre
From chris.campbell at l8tech.com Fri Nov 22 03:57:41 2002
From: chris.campbell at l8tech.com (Chris Campbell)
Date: Fri Nov 22 03:57:41 2002
Subject: [ODE] Debug vs Release floating point (MSVC)
Message-ID:
Hi Norman,
> This is somewhat unsettling for me. I am reasonably certain that is is
> ODE itself which is behaving differently in debug and release modes,
Nah... I'm pretty sure it is to do with the optimizations (for speed) that
occur when building for release. In release build floating point exceptions
are not checked for, internal representation of the number is different
etc - I don't really know the details. If you are using doubles, this might
be relevant too:
http://support.microsoft.com/default.aspx?scid=KB;en-us;q217033
> convention, or other subtle compiler flag issue.
Apparently the /Op switch is supposed to stop optimizations in the
release build as well, but whether you want to do that is the
question isn't it...
ChrisC
From henri at cs.sun.ac.za Fri Nov 22 06:34:02 2002
From: henri at cs.sun.ac.za (Henri Hakl)
Date: Fri Nov 22 06:34:02 2002
Subject: [ODE] Faster ODE
References: <000f01c291e6$2f741ec0$3abdf3d5@wli>
Message-ID: <006b01c2922b$ec499710$45d4e892@temple>
hmmm... the results are quite interesting.
I can understand that in the case of Nguyen Binh there is no difference in
resultant speed. This is likely to be due to the compiler that is in that
case intelligent enough to produce all the optimizations I've set to it. In
essence I just realized that there are alot of code redundancies that aren't
guaranteed to be compiled away with optimal efficiency by most compilers.
VS.NET has a pretty thorough compiler as far as I understand... ;)
I have no idea why the Celeron results should be slower - but the 38-59%
speed improvement by Niko and Daniel are what I expect from average systems.
I'm quite happy with the results upto now then... ;)
Henri
----- Original Message -----
From: "Niko Nevatie"
To:
Sent: Friday, November 22, 2002 7:15 AM
Subject: Re: [ODE] Faster ODE
> I benchmarked 'test_ldlt', here are the results.
>
> Configuration:
> - AMD Athlon TB 800MHz, 384MB RAM, Windows XP
> - ODE 0.03 built with Borland C++ Builder 6.0 (all optimizations on)
>
> Test:
> - ODE was built including first the original 'fastldlt.c' and then
> 'fastldlt_henri.c'
> - test_ldlt was on executed using all available parameters (f, s, t)
>
> Results:
>
> with 'fastldlt.c':
> ----
> 3449
>
> error = 1.625478e-03, size = 71
> error = 2.011657e-04, size = 79
> error = 4.785806e-04, size = 83
> error = 5.344188e-02, size = 89
> error = 3.189385e-03, size = 97
> error = 2.305180e-03, size = 101
> 75
>
> error = 4.673339e-04, size = 71
> error = 2.476573e-04, size = 73
> error = 1.307763e-03, size = 79
> error = 1.248479e-03, size = 83
> error = 1.030391e-02, size = 89
> error = 1.046956e-03, size = 97
> error = 7.226467e-04, size = 101
> 89
> ----
>
>
> with 'fastldlt_henri.c':
> ----
> 2046
>
> error = 1.625478e-03, size = 71
> error = 2.011657e-04, size = 79
> error = 4.785806e-04, size = 83
> error = 5.344188e-02, size = 89
> error = 3.189385e-03, size = 97
> error = 2.305180e-03, size = 101
> 75
>
> error = 4.673339e-04, size = 71
> error = 2.476573e-04, size = 73
> error = 1.307763e-03, size = 79
> error = 1.248479e-03, size = 83
> error = 1.030391e-02, size = 89
> error = 1.046956e-03, size = 97
> error = 7.226467e-04, size = 101
> 89
> ----
>
>
> Conclusions:
> - The outputs of the tests are identical.
> - 'fastldlt_henri.c' consumed ~59% of the time taken by 'fastldlt.c', on
the
> described test configuration.
> - As mentioned earlier, the results may vary depending on the CPU and
cache
> types.
>
>
> Cheers
>
> ----- Original Message -----
> From: "Peter Amstutz"
> To: "Daniel Duhprey"
> Cc:
> Sent: Thursday, November 21, 2002 11:59 PM
> Subject: Re: [ODE] Faster ODE
>
>
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > I haven't looked any of the code involved, but there is one possible
> > explanation for it being faster on one CPU and slower on another :-) It
> > sounds like a cache-size issue. If the Athlon has a bigger L1/L2 cache
> > then the algorithm might be faster overall but if uses more instructions
> > or space than the current algorithm it could be too big and incur a
large
> > cache-miss penalty on the Celeron (which if I recall correctly was given
a
> > really wimpy L1/L2 cache to keep costs down). Such are the joys of
modern
> > CPU architechtures... There's been some work on "cache-oblivious"
> > algorithms, which is essentially a technique of designing the algorithm
to
> > work on small, localized and usually recursive subsets of the total
> > problem (this is especially useful for divide-and-conquor algorithms) so
> > that once you have a subproblem which fits in cache, solving that
> > subproblem is efficient without having to know a priori the size of the
> > processor cache.
> >
> > Just something to think about -- as I said, I haven't looked at the code
> > involved so I could completely off base :-)
> >
> > On Thu, 21 Nov 2002, Daniel Duhprey wrote:
> >
> > > On Thu, 21 Nov 2002, Henri Hakl wrote:
> > >
> > > -->Please check the accuracy and speed using the testsuite provided
with
> ODE.
> > >
> > > If I'm using the numbers from the test_ldlt correctly (as a raw time
on
> > > some scale) then on my athlon its about 38% faster and on my celeron
its
> > > roughly twice as slow :).
> >
> > [ Peter Amstutz ][ amstutz@cs.umass.edu ][
etron@interreality.org ]
> > [Lead Programmer][Interreality Project][Virtual Reality for the
Internet]
> > [ VOS: Next Generation Internet Communication][
http://interreality.org ]
> > [ http://interreality.org/~tetron ][ pgpkey: pgpkeys.mit.edu
18C21DF7 ]
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.0.7 (GNU/Linux)
> >
> > iD8DBQE93VdXaeHUyhjCHfcRAiRMAJ9DdwekLZIYJk0n/fAjtcd3aDG0vACfRze6
> > mcOSJYkj8/NzQXeW/qoia+k=
> > =SJZQ
> > -----END PGP SIGNATURE-----
> >
> >
> > _______________________________________________
> > ODE mailing list
> > ODE@q12.org
> > http://q12.org/mailman/listinfo/ode
> >
>
> _______________________________________________
> ODE mailing list
> ODE@q12.org
> http://q12.org/mailman/listinfo/ode
From martin at metahuman.org Fri Nov 22 09:47:01 2002
From: martin at metahuman.org (Martin C. Martin)
Date: Fri Nov 22 09:47:01 2002
Subject: [ODE] eliminating all state
References: <20021122120304.GA30898@nlin.net>
Message-ID: <3DDE5F39.FFA325DC@metahuman.org>
> The message from which you are being indirectly quoted is:
>
> http://q12.org/pipermail/ode/2002-April/001107.html
Thanks Norman, I see where he says it's only positions and velocities.
For those who are curious, I found the source of the problem: when I was
printing out my doubles, I was only printing DBL_DIG many digits (= 15).
It turns out, I need to print out 17 digits to be sure the values when
read in are exactly the same as before.
Thanks,
Martin
From jeffrey.palmer at acm.org Fri Nov 22 11:07:02 2002
From: jeffrey.palmer at acm.org (Jeffrey Palmer)
Date: Fri Nov 22 11:07:02 2002
Subject: [ODE] Faster ODE
In-Reply-To: <006b01c2922b$ec499710$45d4e892@temple>
References: <000f01c291e6$2f741ec0$3abdf3d5@wli> <006b01c2922b$ec499710$45d4e892@temple>
Message-ID: <200211221206.28464.jeffrey.palmer@acm.org>
Hello all,
I just thought I'd throw out a couple of references I've found useful
while developing highly-efficient C++ code (I apologize if these have
been brought up before):
1) Blitz++ (http://www.oonumerics.org/blitz) - A template-based C++
library for highly-efficient numerical development. Uses
template-metaprogramming to produce code as fast or faster than
FORTRAN, while maintaining an intuitive user model.
2) FFTW - The Fastest Fourier Transform in the West
(http://www.fftw.org) - Although perhaps not directly applicable to
ODE, their approach is a very interesting one if you're *really*
concerned about cranking out performance on whatever platform you're
running on.
I only point these out because we're at a point where it's becoming
increasingly difficult to implement a "correct" solution that is highly
performant on all possible platforms. So, rather than search for the
Holy Grail, these approaches can help to determine an approach that
provides the best performance/platform tradeoff.
Hope this helps/is interesting,
- j
--
The river is moving.
The blackbird must be flying.
From Sergei Eliseev Fri Nov 22 12:30:02 2002
From: Sergei Eliseev (Sergei Eliseev)
Date: Fri Nov 22 12:30:02 2002
Subject: [ODE] Can't compile ODE :(
Message-ID: <2620020157.20021122223434@cea.ru>
Hello,
Just downloaded latest ODE source via WinCVS and make.exe from this
site, created file config/user-settings for msvc, but can't compile
it. I always get the same error:
make (e=2): The system cannot find the file specified.
make.exe: *** [configurator.exe] Error 2
Moreover when I downloaded ready .lib, under VC++ 6.0 I always get
another error during linking:
ode.lib(misc.obj) : error LNK2001: unresolved external symbol __ftol2
How can avoid these nasty errors? Any help really appreciated.
Best regards,
Sergei mailto:sergey_eu@cea.ru
From russ at q12.org Fri Nov 22 13:48:02 2002
From: russ at q12.org (Russ Smith)
Date: Fri Nov 22 13:48:02 2002
Subject: [ODE] eliminating all state
In-Reply-To: <3DDD81EB.9D7E5C55@metahuman.org>
Message-ID:
> Sorry, I must be confused. But wasn't there some issue with radically
> changing the size of the time step? e.g. going from 0.01 sec to 1.0 sec
> or vice versa?
yes ... the issue is that the error correcting velocity would be
artificially magnified when switching from a small to large time step
(e.g. *10). this issue is on the fix-list.
russ.
--
Russ Smith
http://www.q12.org/
From anselm at hook.org Fri Nov 22 14:41:01 2002
From: anselm at hook.org (Anselm Hook)
Date: Fri Nov 22 14:41:01 2002
Subject: [ODE] stress testing and box stacking instability
In-Reply-To:
Message-ID:
Hi Dave,
I thought everybody knew about this defect by now? It's something that
Russ has said he's going to fix for the next big release. If the bug
hasn't changed then basically it is just that not enough contacts are
being generated between two box surfaces - there needs to be at least 3
but there is only 1 right now.
- a
On Fri, 22 Nov 2002, David McClurg wrote:
> I'm trying to use stacked boxes in my game and I ran into the box
> stacking instability mentioned previously on this list. That got me
> to reading the Gamasutra article "Product Review of Physics Engines,
> Part One: The Stress Tests" and I thought it might be useful to put
> together the stress test suite for ODE.
>
> It was easy to get tests 1-6 coded and the only one that did badly was
> Test 2: "A slightly larger cube is dropped on a smaller cube. This
> was a variation on the first test in that the difference between the
> cubes' sizes was much smaller. This test was meant to be a "gimme"
> and should just work." Expected result: cubes should drop straight on
> top of each other and come to immediate rest.
>
> I attached a modified test_boxstack.cpp which shows what happens. The top box dances around for a long time and eventually falls off the top box. In Havok, i think they might be freezing/sleeping boxes in this situation. Does the solution lie in proper detection of this situation or in better contact generation?
> <>
>
From russ at q12.org Fri Nov 22 15:05:02 2002
From: russ at q12.org (Russ Smith)
Date: Fri Nov 22 15:05:02 2002
Subject: [ODE] Faster ODE
In-Reply-To: <200211221206.28464.jeffrey.palmer@acm.org>
Message-ID:
> 1) Blitz++ (http://www.oonumerics.org/blitz)
> 2) FFTW - The Fastest Fourier Transform in the West
i have used blitz and have found their approach to be more clever than it
is productive. the template meta-program idea results in exceptionally
long compile times, and not all compilers have the right optimization
strategies to take advantage of the generated code. gcc, for example, does
not seem to do terribly well at optimizing away the numerous stack-based
parameter-passing temporaries that such code generates. i considered blitz
for ODE but gave up on it in favour of explicitly written for-loops and
hand unrolling because (a) blitz is slower, (b) blitz increases the
compile time hugely, (c) blitz syntax sometimes obscures the actual
numerical operations that are being performed - and i like things to be
obvious and out in the open.
FFTW is new to me, thanks for the pointer.
there's also ATLAS, http://math-atlas.sourceforge.net/
ODE's factorizer is generated using an ATLAS-like parameter-finding
approach (look in the fbuild directory). that's why the fast-ldlt code
looks really complicated when the same thing could be implemented using 3
for-loops in about 20 lines of code. ideally the build process for ODE
should involve running the fbuild code to get the fastest factorizer on
your platform. the 'default' fastldlt etc code is just what happens to
work best on whatever platform i ran fbuild on. note that this default
code should still be significantly faster than the 3 for-loops approach on
all platforms (for matrices of greater than say 5x5 ?).
russ.
--
Russ Smith
http://www.q12.org/
From kale at sagan.usc.edu Fri Nov 22 15:13:02 2002
From: kale at sagan.usc.edu (Kale Harbick)
Date: Fri Nov 22 15:13:02 2002
Subject: [ODE] Vortex vs. ODE
Message-ID:
I started using MathEngine's dynamics toolkit in 2000, and continued with
Vortex when they split up. It's time to renew our academic license but
the price was increased a lot, so we're reluctant. I'm investigating
alternatives and heard about ODE. I was hoping someone here could compare
Vortex and ODE. My application is a simulation of a dynamically-stable
hopping robot. Other people in my group are working on humanoid robot
simulations. Accuracy is more important to me than speed, as it eases the
migration of controllers from simulation to the physical robot.
thanks very much
Kale Harbick
USC Robotics Lab
From russ at q12.org Fri Nov 22 15:39:02 2002
From: russ at q12.org (Russ Smith)
Date: Fri Nov 22 15:39:02 2002
Subject: [ODE] Vortex vs. ODE
In-Reply-To:
Message-ID:
> Accuracy is more important to me than speed, as it eases the
> migration of controllers from simulation to the physical robot.
vortex and ODE both use 1st-order accurate implicit integrators. vortex
may have a more accurate model of single-rigid-body tumbling, but this is
probably not too relevant for robotics work. in my own experience,
robot simulator accuracy is rather difficult to achieve because every
piece must be accurate before the whole thing is ... not only the
integrator but the friction models, the actuator models (hydraulics
anyone? pneumatics?), the sensor models, etc. even getting accurate
inertia tensors is tricky for lab robots that sometimes are sticky-taped
together instead of being bolted. personally, i wouldn't worry about the
numerical accuracy of my simulator unless i had all these other things
sorted out.
russ.
--
Russ Smith
http://www.q12.org/
From vbz at cs.ucr.edu Fri Nov 22 21:18:01 2002
From: vbz at cs.ucr.edu (Victor Zordan)
Date: Fri Nov 22 21:18:01 2002
Subject: [ODE] joint torques
Message-ID: <20021123031114.99CAF25A83@snap.cs.ucr.edu>
Hello.
Comment and a question...
In regards to 11/21 USC comments, I too found vortex to be too expensive.
Plus, I prefer having the code open and available for reading... (thanks
Russ for that.) Also, I've played with Vortex and their contact models
were not to my liking... I asked them if they would let me set up my own
ground constraints and got a negative response, saying that was in a part
of the program that was closed to the users. In a development environment,
like mine or USC's, you want to be able to change as much as possible...
Now, I have looked thru the archives and saw my question asked by Jon
Klein back in June but I didn't find a reply to his question, so I figure
I'll repeat the question. I too am trying to apply torques about joints
and I built a controller that applied both torque at the body center
and a computed force as an equivalent to applying a joint torque. The
joint controller appears to move the body in the correct way, but I
somehow don't think I am computing things properly b/c some unnatural
forces appear at times and cause the body to spin out of control. The
bottom-line question: is there a way in ODE to apply torques relative to
a point on a body (the joint center), just as you would apply a force at
a particular point? Or am I making this too difficult...
Thanks much,
Victor
From russ at q12.org Fri Nov 22 21:25:02 2002
From: russ at q12.org (Russ Smith)
Date: Fri Nov 22 21:25:02 2002
Subject: [ODE] joint torques
In-Reply-To: <20021123031114.99CAF25A83@snap.cs.ucr.edu>
References: <20021123031114.99CAF25A83@snap.cs.ucr.edu>
Message-ID: <20021122202930.3a0a3adc.russ@q12.org>
> is there a way in ODE to apply torques relative to a point on a body
> (the joint center), just as you would apply a force at a particular
> point?
physics fact: any torque applied to a body will have the same effect on
that body's motion regardless of the point at which it is applied, so
there's no reason to specify a position in the dBodyAdd[Rel]Torque()
functions.
russ.
--
Russell Smith
http://www.q12.org
From mama7121 at student.uu.se Sat Nov 23 05:43:02 2002
From: mama7121 at student.uu.se (Martin Magnusson)
Date: Sat Nov 23 05:43:02 2002
Subject: [ODE] Robotics simulation
Message-ID: <3DDF77B8.6080804@student.uu.se>
Hello everybody. I'm new to this list and thought I'd say hi...
Max Lungarella wrote:
> my plan is to simulate a humanoid robot with a reduced number of degrees of
> freedom, let's say 10. the simulation would have to be fairly accurate, since
> i'd like to develop the control architecture in software and use this very
> architecture for the control of a real robot in a second time step.
That sounds very much like my project. I'm doing my master's thesis on
reinforcement learning for balancing a humaoid robot, and I'm looking
for a simulation environment to test my algorithms with. How has it
turned out for you? Are you happy with ODE? Is Dymamechs any better?
/ Martin Magnusson
From marinescuiulian at yahoo.com Sat Nov 23 06:56:02 2002
From: marinescuiulian at yahoo.com (Marinescu Iulian)
Date: Sat Nov 23 06:56:02 2002
Subject: [ODE] Could I simulate a car with ODE ?
Message-ID: <20021123135558.68015.qmail@web13007.mail.yahoo.com>
--0-285632834-1038059758=:67118
Content-Type: text/plain; charset=us-ascii
Hi to everyone!
I am a complete beginner regarding ODE. But I would like to learn. I have to do this project of simulation of a car on different types of road, and different types of weather. I would have to input this:
The dinamics of the car ( for wind simulation)
Type of road ( with holes and stuff)
The type tires
Type of suspension
The vibration of the engine
And many other inputs that I didn't think of, yet. The question is if I could do a program, with ODE, to simulate this.
Thank You !!!
---------------------------------
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now
--0-285632834-1038059758=:67118
Content-Type: text/html; charset=us-ascii
Hi to everyone!
I am a complete beginner regarding ODE. But I would like to learn. I have to do this project of simulation of a car on different types of road, and different types of weather. I would have to input this:
- The dinamics of the car ( for wind simulation)
- Type of road ( with holes and stuff)
- The type tires
- Type of suspension
- The vibration of the engine
And many other inputs that I didn't think of, yet. The question is if I could do a program, with ODE, to simulate this.
Thank You !!!
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now
--0-285632834-1038059758=:67118--
From erwin at vo.com Sat Nov 23 06:59:01 2002
From: erwin at vo.com (Erwin de Vries)
Date: Sat Nov 23 06:59:01 2002
Subject: [ODE] new ODE collision
References: <20021108000235.5bc25ca1.russ@q12.org><000401c287ec$8c862b70$73fefea9@athlon> <20021110181315.7c8dcc2e.russ@q12.org>
Message-ID: <064201c292f8$55791ae0$73fefea9@athlon>
> > - Should we add support for a user defined, or infinite AABB on demand
> > for spaces? This is really useful for the quadtree space containing
> > huge (10.000 for example) amounts of geoms. If i would remove a single
> > geom it would need to do a lot of work.
>
> i don't understand this .. ?
I'll explain my situation. In my app i have a lot of initially static
scenery objects. I place these inside a quadtree space. Once upon a while
the main player hits one (or more) of these objects. At this point i remove
them from the quadtree, give them a body, and add them to my 'main space'.
Now, as this quadtree essentially covers the whole game world i dont _need_
it to have a tight AABB since it is very large anyways. The point where i
_require_ it NOT to have a tight AABB is when i change the structure of the
quadtree (remove a geom). Imagine a 10.000 geom quadtree having to recompute
its bounds. Even if it only involves recomputing the final aabb of 9999
cached and 1 new aabb, it still is a costly process that is essentially
useless. Thats why i would like to add an option to spaces to simply return
an infinite AABB instead of computing it.
Hope this explains. I'm migrating to the new ODE collision detection today.
Perhaps some other suggestions will come to my mind.
Erwin
From p.terdiman at wanadoo.fr Sat Nov 23 08:12:01 2002
From: p.terdiman at wanadoo.fr (Pierre Terdiman)
Date: Sat Nov 23 08:12:01 2002
Subject: [ODE] Box-mesh collision
References: <20021108000235.5bc25ca1.russ@q12.org><000401c287ec$8c862b70$73fefea9@athlon> <20021110181315.7c8dcc2e.russ@q12.org> <064201c292f8$55791ae0$73fefea9@athlon>
Message-ID: <037501c29302$5bde2ce0$0e00000a@pierre>
Hi,
I was (finally) looking at Erwin's box-mesh collision today, when I noticed
something weird :
float DistSq = ColTri.Plane.Normal.DotProduct(BoxCenter -
*ColTri.Vertices[0]);
ColTri.ClosestPoint = BoxCenter - (ColTri.Plane.Normal * ColTri.DistSq);
Unless I'm missing something, the local variable DistSq is never used. On
the other hand, ColTri.DistSq is used while probably not initialized. I
guess the two lines should be :
ColTri.DistSq = ColTri.Plane.Normal.DotProduct(BoxCenter -
*ColTri.Vertices[0]);
ColTri.ClosestPoint = BoxCenter - (ColTri.Plane.Normal * ColTri.DistSq);
...unless, once again, I'm missing something. (I didn't trace it, I'm just
browsing the CVS repository)
There's also another version from Nolan Walker, based on Magic. Is this
better / more recent ? (the question might already have been asked, but I
can't remember the answer...)
Pierre
From facontidavide at hotmail.com Sat Nov 23 12:54:02 2002
From: facontidavide at hotmail.com (Edgard Oscuro)
Date: Sat Nov 23 12:54:02 2002
Subject: [ODE] Robotics simulation
Message-ID:
Hi!! I am Davide
>Max Lungarella wrote:
> > my plan is to simulate a humanoid robot with a reduced number of degrees of
> > freedom, let's say 10. the simulation would have to be fairly accurate, since
> > i'd like to develop the control architecture in software and use this very
> > architecture for the control of a real robot in a second time step.
>
>That sounds very much like my project. I'm doing my master's thesis on
>reinforcement learning for balancing a humaoid robot, and I'm looking
>for a simulation environment to test my algorithms with. How has it
>turned out for you? Are you happy with ODE? Is Dymamechs any better?
It seems that most of us is doing the same!!! As I said before I am going to simulate a humanoid robot as well (that soon we will build in real world). I will be grade to share (pretty soon) my results.
In this moment we are gonna use simulation to understand how strong motors must be (so that we can buy them!)
Davide
Comunica in un ’altra dimensione con MSN Extra Storage! Clicca qui
From grubertm at hotmail.com Sat Nov 23 14:37:02 2002
From: grubertm at hotmail.com (Marco Grubert)
Date: Sat Nov 23 14:37:02 2002
Subject: [ODE] Box-mesh collision
References: <20021108000235.5bc25ca1.russ@q12.org><000401c287ec$8c862b70$73fefea9@athlon> <20021110181315.7c8dcc2e.russ@q12.org> <064201c292f8$55791ae0$73fefea9@athlon> <037501c29302$5bde2ce0$0e00000a@pierre>
Message-ID:
One thing about the Box-Tri collider I noticed is that it assumes the normal
to be that of the triangle. This works fine for a box falling onto a
triangle, but yields wrong results for a triangle falling onto a box. I am
currently working on the tri-tri detection and pick the normal based on
which object is moving and which one is static. This avoids some explosions
but introduces other instabilities..
- Marco Grubert
From coding at natew.com Sat Nov 23 21:26:02 2002
From: coding at natew.com (Nate W)
Date: Sat Nov 23 21:26:02 2002
Subject: [ODE] is ball and socket joint anchor relative to body1?
In-Reply-To:
Message-ID:
On Fri, 22 Nov 2002, David McClurg wrote:
> void dJointSetBallAnchor (dJointID, dReal x, dReal y, dReal z);
> it's not clear to me what coordinate frame the anchor point is in...
World coordinates. Or at least, I assumed world coordinates, and it works
like I'd assumed it would, so I feel pretty good about that assumption. :-)
--
Nate Waddoups
Redmond WA USA
http://www.natew.com
From russ at q12.org Sun Nov 24 16:36:01 2002
From: russ at q12.org (Russ Smith)
Date: Sun Nov 24 16:36:01 2002
Subject: [ODE] multiple box-box contacts
Message-ID: <20021124154047.1ca8d686.russ@q12.org>
i have just finished an update to the box-box contact generation code.
now up to 8 contacts can be generated per box-box collision, although in
practice a limit of 3 or 4 is more useful. the test_boxstack demo has
been updated to show box stacking in action: press 'r' to drop boxes in
a stack, then press b multiple times. press 't' to show the contact
points that are generated. you can play with different numbers of
contacts by changing the 3rd argument to dCollide() - the default is 4.
note that you have to compile ODE *without* ODE_OLD_COLLISION in
user-settings to get the new code.
be careful in your own code to generate as few box-box contacts as you
actually need, as each extra contact point will slow down the simulation
some more.
this new code contains a number of heuristics that should result in good
contact choices - but these algorithms need some more real-world
testing. please report any problems you come across.
russ.
--
Russell Smith
http://www.q12.org
From martin at metahuman.org Sun Nov 24 16:52:01 2002
From: martin at metahuman.org (Martin C. Martin)
Date: Sun Nov 24 16:52:01 2002
Subject: [ODE] multiple box-box contacts
References: <20021124154047.1ca8d686.russ@q12.org>
Message-ID: <3DE165EB.9FC8D9A6@metahuman.org>
Hey Russ,
> i have just finished an update to the box-box contact generation code.
Thanks, that rocks! Better box-box contacts is one of the major
capabilities in the list for 0.035. It's been almost a year since 0.03
was released. Any idea when 0.035 will be out?
Thanks again,
Martin
From dmcclurg at pandemicstudios.com.au Sun Nov 24 19:15:02 2002
From: dmcclurg at pandemicstudios.com.au (David McClurg)
Date: Sun Nov 24 19:15:02 2002
Subject: [ODE] multiple box-box contacts
Message-ID:
very nice Russ! just a minor thing that my VC7 compiler doesn't like...
collision_std.cpp
collision_std.cpp(460) : error C2057: expected constant expression
collision_std.cpp(460) : error C2466: cannot allocate an array of constant size 0
collision_std.cpp(460) : error C2133: 'avail' : unknown size
if you could change
int avail[n];
to
int* avail = (int*)alloca(n*sizeof(int));
that would fix it.
-----Original Message-----
From: Russ Smith [mailto:russ@q12.org]
Sent: Monday, 25 November 2002 6:41 AM
To: ode@q12.org
Subject: [ODE] multiple box-box contacts
i have just finished an update to the box-box contact generation code.
now up to 8 contacts can be generated per box-box collision, although in
practice a limit of 3 or 4 is more useful. the test_boxstack demo has
been updated to show box stacking in action: press 'r' to drop boxes in
a stack, then press b multiple times. press 't' to show the contact
points that are generated. you can play with different numbers of
contacts by changing the 3rd argument to dCollide() - the default is 4.
note that you have to compile ODE *without* ODE_OLD_COLLISION in
user-settings to get the new code.
be careful in your own code to generate as few box-box contacts as you
actually need, as each extra contact point will slow down the simulation
some more.
this new code contains a number of heuristics that should result in good
contact choices - but these algorithms need some more real-world
testing. please report any problems you come across.
russ.
--
Russell Smith
http://www.q12.org
_______________________________________________
ODE mailing list
ODE@q12.org
http://q12.org/mailman/listinfo/ode
From russ at q12.org Sun Nov 24 19:58:02 2002
From: russ at q12.org (Russ Smith)
Date: Sun Nov 24 19:58:02 2002
Subject: [ODE] multiple box-box contacts
In-Reply-To:
References:
Message-ID: <20021124190259.4ef95df8.russ@q12.org>
> if you could change
> int avail[n];
ah yes ... this is now fixed.
russ.
--
Russell Smith
http://www.q12.org
From mal at candomultimedia.com Sun Nov 24 20:11:02 2002
From: mal at candomultimedia.com (Mal)
Date: Sun Nov 24 20:11:02 2002
Subject: [ODE] OT: Physics based game beta...
In-Reply-To: <20021124190259.4ef95df8.russ@q12.org>
Message-ID: <000001c29430$209ac470$7600a8c0@MalLaptop>
If any of you need a break from coding physics, check this out...
http://www.candomultimedia.com/3dStressBall
It's the beta of a new game we're developing in our spare time here at
canDo, but it's quite fun already. It uses Shockwave 3D and Havok, but
the basics could be implemented using any physics engine. You can post
your levels to the new forum. The game will be modified a lot over the
next 10 weeks or so.
Enjoy, and if you like it, check this out too, it's an updated version
of the Balls Up game that also uses Havok ( now 3D Balls Up, has a new
novel mouse control, as well as joystick control, music, easier learning
levels, feature removals ( bug fixes ) etc.
http://www.candomultimedia.com/3dBallsUp
As physics gurus it might be fun to get away from the compiler and get
your hand to eye co-ordination back up to scratch! :)
Mal
From Nguyen Binh Sun Nov 24 23:08:02 2002
From: Nguyen Binh (Nguyen Binh)
Date: Sun Nov 24 23:08:02 2002
Subject: Re[2]: [ODE] Faster ODE
In-Reply-To:
References:
Message-ID: <130756758.20021125101120@glassegg.com>
I think the best way to improve ODE speed is using CPU-
specialized instructions like MMX,SIMD,SSE(2).
The refs can be :
http://LibSimd.sourceforge.net
SML library of Intel. (Very nice!)
--
Best regards,
---------------------------------------------------------------------
Nguyen Binh
Software Engineer
Glass Egg Digital Media
Me Linh Point Tower, 10th Floor
2 Ngo Duc Ke
District 1, Ho Chi Minh City
Vietnam
Fax: (84.8)823-8392
www.glassegg.com
---------------------------------------------------------------------
From Dominique at SavageSoftware.com.au Mon Nov 25 02:43:02 2002
From: Dominique at SavageSoftware.com.au (Dominique Louis)
Date: Mon Nov 25 02:43:02 2002
Subject: [ODE] Silkworm...
Message-ID: <3DE1F12E.6090306@SavageSoftware.com.au>
Just thought others might be interested to know that todays ( 24th of
November ) image of the day on FlipCode ( http://www.flipcode.com/iotd/
) is an ODE demo called SilkWorm ( http://slickworm.sourceforge.net ).
From tetron at interreality.org Mon Nov 25 11:25:02 2002
From: tetron at interreality.org (Peter Amstutz)
Date: Mon Nov 25 11:25:02 2002
Subject: [ODE] multiple box-box contacts
In-Reply-To: <20021124154047.1ca8d686.russ@q12.org>
Message-ID:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Awesome! This is what I've been waiting for -- now I can use ODE for my
VR simulation. Oh, and it's really fun to just play with the box stacking
demo, to make a huge tower and then knock it down...
Great work! Russ, you rule :-) It's amazing to have such excelent code
freely available.
On Sun, 24 Nov 2002, Russ Smith wrote:
>
> i have just finished an update to the box-box contact generation code.
> now up to 8 contacts can be generated per box-box collision, although in
> practice a limit of 3 or 4 is more useful. the test_boxstack demo has
> been updated to show box stacking in action: press 'r' to drop boxes in
> a stack, then press b multiple times. press 't' to show the contact
> points that are generated. you can play with different numbers of
> contacts by changing the 3rd argument to dCollide() - the default is 4.
>
> note that you have to compile ODE *without* ODE_OLD_COLLISION in
> user-settings to get the new code.
>
> be careful in your own code to generate as few box-box contacts as you
> actually need, as each extra contact point will slow down the simulation
> some more.
>
> this new code contains a number of heuristics that should result in good
> contact choices - but these algorithms need some more real-world
> testing. please report any problems you come across.
[ Peter Amstutz ][ amstutz@cs.umass.edu ][ tetron@interreality.org ]
[Lead Programmer][Interreality Project][Virtual Reality for the Internet]
[ VOS: Next Generation Internet Communication][ http://interreality.org ]
[ http://interreality.org/~tetron ][ pgpkey: pgpkeys.mit.edu 18C21DF7 ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
iD8DBQE94mrHaeHUyhjCHfcRApGmAJ0Rd0ssY0jsemvGVVaSDbqEW9YQbQCfTiWm
9pWajiZt1CU/KJjnff+AHk0=
=Blf/
-----END PGP SIGNATURE-----
From henri at cs.sun.ac.za Mon Nov 25 13:46:01 2002
From: henri at cs.sun.ac.za (Henri Hakl)
Date: Mon Nov 25 13:46:01 2002
Subject: Re[2]: [ODE] Faster ODE
Message-ID: <032001c294c3$afa33ec0$45d4e892@temple>
This is a multi-part message in MIME format.
------=_NextPart_000_031D_01C294D4.732027E0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
I've been thinking about SIMD (MMX, 3DNow(!), SSE(2)) instructions for =
ODE -
and it is quite possible that it can bring about harmony and speed. But =
one
thing that is likely going to cause problems is the SSE(2) code.
For optimal performance a number of details need to be implemented. =
Vectors
and matrices need to be of a horizontal size that is a factor of 4 (this =
is
implemented and the reason why, for example, a 3x3 matrix is defined as =
a 12
TReal (3x4) structure.
However, the structures also have to be aligned onto 16-byte boundaries. =
To
allow for optimal SSE(2) access (using movaps) each 128-bit memory =
vector
that is accessed has to be alligned on a 16-byte memory boundary. This =
is a
problem in ODE, as every math structure now is required to be 16-byte
aligned; this is difficult to achieve because ODE calls/uses =
sub-matrices of
matrices, and it may be difficult to guarantee that every sub-matrix is
>also< correctly 16-byte aligned.
Additionally SSE2 primarily adds double-float functionality to the SIMD
instructions. This can help somewhat for speed in the TReal =3D double =
case,
but isn't likely (just my guess) to have as tremendous a speed bonus as =
4
single floats that can be handled simultaneously for TReal =3D single.
Anyway... ;)
Henri
----- Original Message -----
From: "Nguyen Binh"
To: ; "Russ Smith"
Cc: "Jeffrey Palmer" ;
Sent: Monday, November 25, 2002 5:11 AM
Subject: Re[2]: [ODE] Faster ODE
>
> I think the best way to improve ODE speed is using CPU-
> specialized instructions like MMX,SIMD,SSE(2).
>
> The refs can be :
> http://LibSimd.sourceforge.net
> SML library of Intel. (Very nice!)
>
> --
> Best regards,
>
> ---------------------------------------------------------------------
> Nguyen Binh
> Software Engineer
> Glass Egg Digital Media
> Me Linh Point Tower, 10th Floor
> 2 Ngo Duc Ke
> District 1, Ho Chi Minh City
> Vietnam
> Fax: (84.8)823-8392
> www.glassegg.com
> ---------------------------------------------------------------------
>
>
> _______________________________________________
> ODE mailing list
> ODE@q12.org
> http://q12.org/mailman/listinfo/ode
------=_NextPart_000_031D_01C294D4.732027E0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
I've been thinking about SIMD (MMX, 3DNow(!), SSE(2)) instructions =
for ODE=20
-
and it is quite possible that it can bring about harmony and speed. =
But=20
one
thing that is likely going to cause problems is the SSE(2)=20
code.
For optimal performance a number of details need to be =
implemented.=20
Vectors
and matrices need to be of a horizontal size that is a factor =
of 4=20
(this is
implemented and the reason why, for example, a 3x3 matrix is =
defined=20
as a 12
TReal (3x4) structure.
However, the structures also =
have to be=20
aligned onto 16-byte boundaries. To
allow for optimal SSE(2) access =
(using=20
movaps) each 128-bit memory vector
that is accessed has to be =
alligned on a=20
16-byte memory boundary. This is a
problem in ODE, as every math =
structure=20
now is required to be 16-byte
aligned; this is difficult to achieve =
because=20
ODE calls/uses sub-matrices of
matrices, and it may be difficult to =
guarantee=20
that every sub-matrix is
>also< correctly 16-byte=20
aligned.
Additionally SSE2 primarily adds double-float =
functionality to=20
the SIMD
instructions. This can help somewhat for speed in the TReal =
=3D double=20
case,
but isn't likely (just my guess) to have as tremendous a speed =
bonus as=20
4
single floats that can be handled simultaneously for TReal =3D=20
single.
Anyway... ;)
Henri
----- Original =
Message=20
-----
From: "Nguyen Binh" <
ngbinh@glassegg.com>
To: =
<ode-admin@q12.org>; "Russ =
Smith" <russ@q12.org>
Cc: "Jeffrey =
Palmer" <jeffrey.palmer@acm.org>; =
<ode@q12.org>
Sent: Monday, =
November 25, 2002=20
5:11 AM
Subject: Re[2]: [ODE] Faster=20
ODE
>
> &nbs=
p; I=20
think the best way to improve ODE speed is using=20
CPU-
> specialized =
instructions like=20
MMX,SIMD,SSE(2).
>
> =
; =20
The refs can be=20
:
> &nbs=
p; =20
http://LibSimd.sourceforge.net
> &nbs=
p; =20
SML library of Intel. (Very nice!)
>
> --
> Best=20
regards,
>
>=20
---------------------------------------------------------------------
=
> =20
Nguyen Binh
> Software=20
Engineer
> Glass Egg Digital=20
Media
> Me Linh Point Tower, 10th=20
Floor
> 2 Ngo Duc Ke
> =
District=20
1, Ho Chi Minh City
> =
Vietnam
> =20
Fax: (84.8)823-8392
> www.glassegg.com
>=20
---------------------------------------------------------------------
=
>
>
>=20
_______________________________________________
> ODE mailing =
list
>=20
ODE@q12.org
> http://q12.org/mailman/listi=
nfo/ode
Hi.
I am attempting to install the latest CVS version of CS. I have windows XP, and am using MSVC7 (the contrib/msvc7 solution however doesn't appear to be up to date; in any case, it isn't working for me). I downloaded the GNU make binary offered at q12.org, but I get problems when I do make ode-lib. In appears it may be a problem with the source code (or how my compiler treats the code more likely?). Here's what happens:
<prompt at ODE dir>make ode-lib <enter>
cl /nologo /DWIN32 /DMSVC /DSHAREDLIBEXPORT= /DSHAREDLIBIMPORT= /c /GR- /GX- /W3
/GF /Oy /Iinclude /DdNODEBUG /O2 /Foode/src/step.obj ode/src/step.cpp
cl : Command line warning D4029 : optimization is not available in the standard
edition compiler
step.cpp
ode\src\step.cpp(442) : error C2675: unary '-' : 'dInfBytes' does not define thi
s operator or a conversion to a type acceptable to the predefined operator
ode\src\step.cpp(443) : error C2664: 'dSetValue' : cannot convert parameter 3 fr
om 'dInfBytes' to 'dReal'
No user-defined-conversion operator available that can perform this conv
ersion, or the operator cannot be called
ode\src\step.cpp(730) : error C2675: unary '-' : 'dInfBytes' does not define thi
s operator or a conversion to a type acceptable to the predefined operator
ode\src\step.cpp(731) : error C2664: 'dSetValue' : cannot convert parameter 3 fr
om 'dInfBytes' to 'dReal'
No user-defined-conversion operator available that can perform this conv
ersion, or the operator cannot be called
make: *** [ode/src/step.obj] Error 2
Any help would be appreciated. Thanks,
Mark Rawls
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now
--0-1042572177-1038328296=:27505--
From slipch Tue Nov 26 09:48:02 2002
From: slipch (slipch)
Date: Tue Nov 26 09:48:02 2002
Subject: [ODE] using dCreateGeomClass in the last ode version
Message-ID: <15831806395.20021126185038@gsc-game.kiev.ua>
Hello ODE,
Is it a bug?
The problem accrues with setting pointer to a function for self
collision because when calling dCreateGeomClass the integer class
number is not set yet. So, collider function calling by dCreateGeomClass
can not return right function pointer.
--
Best regards,
slipch mailto:slipch@gsc-game.kiev.ua
From russ at q12.org Tue Nov 26 11:57:02 2002
From: russ at q12.org (Russ Smith)
Date: Tue Nov 26 11:57:02 2002
Subject: [ODE] using dCreateGeomClass in the last ode version
In-Reply-To: <15831806395.20021126185038@gsc-game.kiev.ua>
Message-ID:
> The problem accrues with setting pointer to a function for self
> collision because when calling dCreateGeomClass the integer class
> number is not set yet. So, collider function calling by dCreateGeomClass
> can not return right function pointer.
i don't know what problem you are talking about - can you describe it more
precisely? but the new collision system uses constant class numbers, not
variable class numbers, so this should not be a problem (except perhaps
for user defined classes set up through the C API??).
russ.
--
Russ Smith
http://www.q12.org/
From thomasharte at lycos.co.uk Tue Nov 26 12:40:02 2002
From: thomasharte at lycos.co.uk (Thomas Harte)
Date: Tue Nov 26 12:40:02 2002
Subject: [ODE] My Latest Approach to Polyhedron Collision Management
Message-ID: <1038339519025448@lycos-europe.com>
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
--=_NextPart_Lycos_0254481038339519_ID
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
I'm continuing to make progress in my pursuit of the perfect arbitrary polyhedron on arbitrary polyhedron collision management. I am looking for comments or suggestions regarding my current approach, from those on this list who must have worked on, or be working on, the same thing. In particular, I am worried about the efficiently of my constraint generation calculations.
My driving physics engine is fairly typical. It is assumed that at the start of a time step, no objects are inter-penetrating. If, at the end of the time step, there continue to be no objects inter-penetrating, then the time step is complete. If objects do inter-penetrate, then a binary search reveals something very close to the last time before inter-penetration occurred, at which point the relevant constraints are added to prevent that from happening, and the whole process repeats, this time considering only the remaining portion of the time step after the penetration.
Therefore, two discrete binary operations are supported on polyhedron types - an overlap test and a constraint calculation.
All polyhedron's have BSP trees and hierarchical bounding sphere sets for :
- their vertices
- their edges
In my hierarchy, every sphere has (at most) 8 children. Obviously the number of children represents a balance between hierarchy depth and bredth, and all the related factors when it comes to eliminating possible edge on polygon tests. I picked 8 to match up with the natural geographical division that occurs under an octree.
I understand that a sphere probably models the shape of sets of edges and vertices terribly, but on the other hand it is really cheap to test one against a plane.
The overlap test can be achieved using the edge and related bounding sphere information from one object with the BSP tree of another.
For any given BSP node, if a particular sphere is entirely on one particular side of the plane, then its tests head that way down the tree. If it sits on the plane, then its children are considered. If a leaf node is found to be intersecting a plane, then complete edge on polygon tests are done. If any edge intersects a polygon, then the two objects are said to overlap, and no further tests are carried out.
Obviously a first 'quick throwaway' test on distance between the highest level bounding spheres of both objects is performed, but in my simulation there is already a higher order octree related means to calculating which objects are 'near' which other objects, so that test isn't as useful as it might otherwise be.
This BSP approach is a smarter version of testing every polygon of one object against every polygon of the other. It therefore is fooled by the same problems, such as one object being totally enclosed by another object - but these are a result of using a discrete model of time, and things my simulation will simply be built to deal with.
Most tests performed by my engine when two objects begin contact will be overlap tests due to the binary search for collision time, and the constraint calculation will only occur once. When two objects start a time step rubbing up against each other, the focus will be the constraint calculation, but still this should only be required once per time step. Therefore, in my engine where objects will frequently change what they are rubbing against, it is the overlap test that needs be most optimal.
The constraint calculation needs to detect when vertices on one object are very close to polygons on the other, and when edges on one object are very close to edges on the other. My engine attempts to keep all objects seperated by an invisibly small border, negating the need for the binary search for collision time to be desperately accurate, and generally helping smooth numerical accuracy problems.
The edges problem isn't hard. Its more or less like the overlap test, but this time edges which are close to a plane in the BSP are tested in addition to those that cross the plane, and all are tested only against original edges that lie on that plane, not against the edges of the polygons used to construct the BSP tree - the distinction being that I am not interested in the artificial edges generated when splitting polygons for BSP purposes.
Vertices on planes is slightly more difficult. My current solution is to push each object's vertices down the BSP tree of the other object. But this means that I have to do two BSP traversals per constraint calculation - which I am sure could probably be only 1 if it weren't for some gross thickness on my part.
Is there any way to do this more efficiently?
-Thomas
BA flight sale now at http://www.lycos.co.uk Caracas, =A3129 rtn. including tax, Tues, 11am
--=_NextPart_Lycos_0254481038339519_ID--
From jeffrey.palmer at acm.org Tue Nov 26 15:30:02 2002
From: jeffrey.palmer at acm.org (Jeffrey Palmer)
Date: Tue Nov 26 15:30:02 2002
Subject: [ODE] ODE/Tricollider on linux?
Message-ID: <200211261629.14222.jeffrey.palmer@acm.org>
Hello all,
I was wondering if anyone has gotten ODE and the tricollider code (I
tried the stuff in the NewStuff email to no avail) working under Linux?
Alternatively, I understand that the tri code is currently being
integrated with ODE - is that in the CVS version yet? If not, is it
bothersome to ask for an ETA?
I guess I'm just lazy - I'm sort of unwilling to port everything to
linux if it's *about* to be released. ;)
Thanks,
- j
--
The river is moving.
The blackbird must be flying.
From anselm at hook.org Tue Nov 26 15:45:02 2002
From: anselm at hook.org (Anselm Hook)
Date: Tue Nov 26 15:45:02 2002
Subject: [ODE] operator new undefined link cygwin gcc
In-Reply-To: <200211261629.14222.jeffrey.palmer@acm.org>
Message-ID:
For some bizarre reason I had to use g++ instead of gcc with my (very
recent) version of cygwin and todays verson of ode. I was getting an
"operator new undefined" error at the link phase. Anybody else notice the
same thing?
I had to modify the configurator code a bit to build under g++ also.
- a
From mama7121 at student.uu.se Tue Nov 26 16:28:02 2002
From: mama7121 at student.uu.se (Martin Magnusson)
Date: Tue Nov 26 16:28:02 2002
Subject: [ODE] operator new undefined link cygwin gcc
References:
Message-ID: <3DE40356.8010604@student.uu.se>
I'm having trouble compiling under Cygwin as well. Then again, it could
be a Cygwin problem too, since I'm new to Cygwin as well. Anyway, as far
as I can understand I've set the user-settings file correctly, and after
that a simple 'make' should be enough, right? Using g++ didn't seem to
help. My results are posted below. The problem seems to be with
lib/libode.a. I don't have a directory called 'lib', and there's no
'libode.a' anywhere on my HDD. Help, comments or flames are appreciated :)
/ Martin Magnusson
======================================================================
== Contents of ./config/user-settings: ===============================
# ODE user settings: the following variables must be set by the user
# (1) the platform to use. this name should have a corresponding
# makefile.PLATFORM file. currently supported platforms are:
# msvc microsoft visual C/C++
# mingw minimalist GNU for windows
# cygwin cygnus GNU for windows
# unix-gcc GNU gcc on windows
# unix-generic generic unix compiler. you may need to edit the CC
# variable in makefile.unix-generic
# osx Mac OS-X, with the gnu compiler.
PLATFORM=cygwin
# (2) the floating point precision to use (either "SINGLE" or "DOUBLE")
#PRECISION=SINGLE
PRECISION=DOUBLE
# (3) the library type to build (either "debug" if you are doing
development,
# or "release" for the optimized library)
#BUILD=debug
BUILD=release
=====================================================================
== Result of make with gcc: =========================================
/home/martin!/ode-0.03> make
gcc -DdDOUBLE -DdNODEBUG -o configurator.exe configurator.c
./configurator.exe include/ode/config.h "gcc -DdNODEBUG -o " "rm -f" ./
rm -f ctest.exe
gcc -DdNODEBUG -o ctest.exe ctest.c
rm -f ctest.exe
gcc -DdNODEBUG -o ctest.exe ctest.c
rm -f ctest.exe
gcc -DdNODEBUG -o ctest.exe ctest.c
rm -f ctest.exe
gcc -DdNODEBUG -o ctest.exe ctest.c
rm -f ctest.exe
gcc -DdNODEBUG -o ctest.exe ctest.c
rm -f ctest.exe
gcc -DdNODEBUG -o ctest.exe ctest.c
rm -f ctest.exe
gcc -DdNODEBUG -o ctest.exe ctest.c
rm -f ctest.c
rm -f ctest.exe
is this a pentium on a gcc-based platform? ...
rm -f ctest.exe
gcc -DdNODEBUG -o ctest.exe ctest.c
rm -f ctest.c
rm -f ctest.exe
integer types (we assume int >= 32 bits) ...
select the base floating point type ...
the floating point infinity ...
rm -f data
gcc -DdNODEBUG -o ctest.exe ctest.c
ctest.c:5: initializer element is not constant
./ctest.exe
./ctest.exe: not found
rm -f data
gcc -DdNODEBUG -o ctest.exe ctest.c
./ctest.exe
rm -f data
gcc -DdNODEBUG -o ctest.exe ctest.c
./ctest.exe
rm -f ctest.c
rm -f ctest.exe
rm -f data
*** configurator succeeded ***
gcc -c -Wall -fno-exceptions -fno-rtti -DWIN32 -DCYGWIN
-fomit-frame-pointer -ff
ast-math -Iinclude -DdNODEBUG -O2 -o ode/src/array.o ode/src/array.cpp
gcc -c -Wall -fno-exceptions -fno-rtti -DWIN32 -DCYGWIN
-fomit-frame-pointer -ff
ast-math -Iinclude -DdNODEBUG -O2 -o ode/src/error.o ode/src/error.cpp
gcc -c -Wall -fno-exceptions -fno-rtti -DWIN32 -DCYGWIN
-fomit-frame-pointer -ff
ast-math -Iinclude -DdNODEBUG -O2 -o ode/src/memory.o ode/src/memory.cpp
gcc -c -Wall -fno-exceptions -fno-rtti -DWIN32 -DCYGWIN
-fomit-frame-pointer -ff
ast-math -Iinclude -DdNODEBUG -O2 -o ode/src/obstack.o ode/src/obstack.cpp
gcc -c -Wall -fno-exceptions -fno-rtti -DWIN32 -DCYGWIN
-fomit-frame-pointer -ff
ast-math -Iinclude -DdNODEBUG -O2 -o ode/src/odemath.o ode/src/odemath.cpp
gcc -c -Wall -fno-exceptions -fno-rtti -DWIN32 -DCYGWIN
-fomit-frame-pointer -ff
ast-math -Iinclude -DdNODEBUG -O2 -o ode/src/matrix.o ode/src/matrix.cpp
gcc -c -Wall -fno-exceptions -fno-rtti -DWIN32 -DCYGWIN
-fomit-frame-pointer -ff
ast-math -Iinclude -DdNODEBUG -O2 -o ode/src/misc.o ode/src/misc.cpp
gcc -c -Wall -fno-exceptions -fno-rtti -DWIN32 -DCYGWIN
-fomit-frame-pointer -ff
ast-math -Iinclude -DdNODEBUG -O2 -o ode/src/rotation.o
ode/src/rotation.cpp
gcc -c -Wall -fno-exceptions -fno-rtti -DWIN32 -DCYGWIN
-fomit-frame-pointer -ff
ast-math -Iinclude -DdNODEBUG -O2 -o ode/src/mass.o ode/src/mass.cpp
gcc -c -Wall -fno-exceptions -fno-rtti -DWIN32 -DCYGWIN
-fomit-frame-pointer -ff
ast-math -Iinclude -DdNODEBUG -O2 -o ode/src/ode.o ode/src/ode.cpp
ode/src/ode.cpp: In function `void dJointAttach(dxJoint*, dxBody*,
dxBody*)':
ode/src/ode.cpp:922: warning: unused variable `dxWorld*world'
gcc -c -Wall -fno-exceptions -fno-rtti -DWIN32 -DCYGWIN
-fomit-frame-pointer -ff
ast-math -Iinclude -DdNODEBUG -O2 -o ode/src/step.o ode/src/step.cpp
ode/src/step.cpp:701:5: warning: multi-line comment
ode/src/step.cpp:704:5: warning: multi-line comment
gcc -c -Wall -fno-exceptions -fno-rtti -DWIN32 -DCYGWIN
-fomit-frame-pointer -ff
ast-math -Iinclude -DdNODEBUG -O2 -o ode/src/lcp.o ode/src/lcp.cpp
gcc -c -Wall -fno-exceptions -fno-rtti -DWIN32 -DCYGWIN
-fomit-frame-pointer -ff
ast-math -Iinclude -DdNODEBUG -O2 -o ode/src/joint.o ode/src/joint.cpp
gcc -c -Wall -fno-exceptions -fno-rtti -DWIN32 -DCYGWIN
-fomit-frame-pointer -ff
ast-math -Iinclude -DdNODEBUG -O2 -o ode/src/space.o ode/src/space.cpp
gcc -c -Wall -fno-exceptions -fno-rtti -DWIN32 -DCYGWIN
-fomit-frame-pointer -ff
ast-math -Iinclude -DdNODEBUG -O2 -o ode/src/geom.o ode/src/geom.cpp
gcc -c -Wall -fno-exceptions -fno-rtti -DWIN32 -DCYGWIN
-fomit-frame-pointer -ff
ast-math -Iinclude -DdNODEBUG -O2 -o ode/src/timer.o ode/src/timer.cpp
ode/src/timer.cpp:109:17: warning: multi-line string literals are deprecated
ode/src/timer.cpp:119:17: warning: multi-line string literals are deprecated
gcc -c -Wall -fno-exceptions -fno-rtti -DWIN32 -DCYGWIN
-fomit-frame-pointer -ff
ast-math -Iinclude -DdNODEBUG -O2 -o ode/src/mat.o ode/src/mat.cpp
gcc -c -Wall -fno-exceptions -fno-rtti -DWIN32 -DCYGWIN
-fomit-frame-pointer -ff
ast-math -Iinclude -DdNODEBUG -O2 -o ode/src/testing.o ode/src/testing.cpp
gcc -c -Wall -fno-exceptions -fno-rtti -DWIN32 -DCYGWIN
-fomit-frame-pointer -ff
ast-math -Iinclude -DdNODEBUG -O1 -o ode/src/fastldlt.o ode/src/fastldlt.c
gcc -c -Wall -fno-exceptions -fno-rtti -DWIN32 -DCYGWIN
-fomit-frame-pointer -ff
ast-math -Iinclude -DdNODEBUG -O1 -o ode/src/fastlsolve.o
ode/src/fastlsolve.c
gcc -c -Wall -fno-exceptions -fno-rtti -DWIN32 -DCYGWIN
-fomit-frame-pointer -ff
ast-math -Iinclude -DdNODEBUG -O1 -o ode/src/fastltsolve.o
ode/src/fastltsolve.
c
gcc -c -Wall -fno-exceptions -fno-rtti -DWIN32 -DCYGWIN
-fomit-frame-pointer -ff
ast-math -Iinclude -DdNODEBUG -O1 -o ode/src/fastdot.o ode/src/fastdot.c
ar rc lib/libode.a ode/src/array.o ode/src/error.o ode/src/memory.o
ode/src/obst
ack.o ode/src/odemath.o ode/src/matrix.o ode/src/misc.o
ode/src/rotation.o ode/s
rc/mass.o ode/src/ode.o ode/src/step.o ode/src/lcp.o ode/src/joint.o
ode/src/spa
ce.o ode/src/geom.o ode/src/timer.o ode/src/mat.o ode/src/testing.o
ode/src/fast
ldlt.o ode/src/fastlsolve.o ode/src/fastltsolve.o ode/src/fastdot.o
ar: lib/libode.a: No such file or directory
make: *** [lib/libode.a] Error 1
=====================================================================
== Result of make with g++: =========================================
/home/martin!/ode-0.03> make
g++ -DdDOUBLE -DdNODEBUG -o configurator.exe configurator.c
configurator.c: In function `void fatal_error(char*)':
configurator.c:112: `exit' undeclared (first use this function)
configurator.c:112: (Each undeclared identifier is reported only once
for each
function it appears in.)
configurator.c: In function `void delete_file(char*)':
configurator.c:167: `system' undeclared (first use this function)
make: *** [configurator.exe] Error 1
From harleybl at hotmail.com Tue Nov 26 16:53:01 2002
From: harleybl at hotmail.com (Harley Blumenfeld)
Date: Tue Nov 26 16:53:01 2002
Subject: [ODE] Unhandled exception - access violation
Message-ID:
Has anyone else been getting an Unhandled exception - access violation,when calling dGeomDestroy? I got the latest from cvs this morning and have run into this problem when my application closes.
All I did was make a sub folder under test, and created a project which contains a copy of the buggy_test.cpp. The program runs fine, except when the window is closed I get an access violation. It seems to be happening when the box is destroyed in the line dGeomDestroy( box[0] );
When I look up the call stack it is failing at this place in the chain dxGeom::bodyRemove( void ).
Here is my configuration:
msvc version 6.0
Ode from this morning compiled with build=debug
Windows 2000 SP 2
Is there a setting that I am missing in my project? I noticed that there was a warning about a conflicting library and the linker said that I should be using /NODEFAULTLIB: libc.
Which library should I be using instead?
Thanks,
-Harley Blumenfeld
Tired of spam? Get advanced junk mail protection with MSN 8.
From russ at q12.org Tue Nov 26 19:56:02 2002
From: russ at q12.org (Russ Smith)
Date: Tue Nov 26 19:56:02 2002
Subject: [ODE] Unhandled exception - access violation
In-Reply-To:
References:
Message-ID: <20021126190026.00c5f3ed.russ@q12.org>
> It seems to be happening when the box is destroyed in the line
> dGeomDestroy( box[0] );
is the error happening within dGeomDestroy() or within main(). are you
using an unaltered copy of test_buggy?
russ.
--
Russell Smith
http://www.q12.org
From Nguyen Binh Tue Nov 26 20:32:02 2002
From: Nguyen Binh (Nguyen Binh)
Date: Tue Nov 26 20:32:02 2002
Subject: Re[2]: [ODE] Unhandled exception - access violation
In-Reply-To: <20021126190026.00c5f3ed.russ@q12.org>
References:
<20021126190026.00c5f3ed.russ@q12.org>
Message-ID: <931545011.20021127103524@glassegg.com>
>> It seems to be happening when the box is destroyed in the line
>> dGeomDestroy( box[0] );
It's the same for me. I'm using the latest test_buggt.cpp in CVS.
RS> is the error happening within dGeomDestroy() or within main(). are you
RS> using an unaltered copy of test_buggy?
I solved it by bring the dGeomDestroy()... to front like this:
dGeomDestroy (box[0]);
dGeomDestroy (sphere[0]);
dGeomDestroy (sphere[1]);
dGeomDestroy (sphere[2]);
dJointGroupDestroy (contactgroup);
dSpaceDestroy (space);
dWorldDestroy (world);
--
Best regards,
---------------------------------------------------------------------
Nguyen Binh
Software Engineer
Glass Egg Digital Media
E.Town Building
7th Floor, 364 CongHoa Street
Tan Binh District,
HoChiMinh City,
VietNam,
Phone : +84 8 8109018
Fax : +84 8 8109013
www.glassegg.com
---------------------------------------------------------------------
From anselm at hook.org Tue Nov 26 20:43:01 2002
From: anselm at hook.org (Anselm Hook)
Date: Tue Nov 26 20:43:01 2002
Subject: [ODE] operator new undefined link cygwin gcc
In-Reply-To: <3DE40356.8010604@student.uu.se>
Message-ID:
For the default compiler in makefile.cygwin to be g++ you have to wrap
extern "C" { } around your includes in the configurator source. Also just
remove exit() - it isn't important. The configurator could be generalized
to support this overall but I guess it's pretty obvious.
As for your bug with not being able to link - I did see some comment about
that earlier on the list. Try cvs to head revision and see if it is
fixed. Otherwise try see if your cygwin is older...
- a
> =====================================================================
> == Result of make with g++: =========================================
>
> /home/martin!/ode-0.03> make
> g++ -DdDOUBLE -DdNODEBUG -o configurator.exe configurator.c
> configurator.c: In function `void fatal_error(char*)':
> configurator.c:112: `exit' undeclared (first use this function)
> configurator.c:112: (Each undeclared identifier is reported only once
> for each
> function it appears in.)
> configurator.c: In function `void delete_file(char*)':
> configurator.c:167: `system' undeclared (first use this function)
> make: *** [configurator.exe] Error 1
>
> _______________________________________________
> ODE mailing list
> ODE@q12.org
> http://q12.org/mailman/listinfo/ode
>
From g.r.vansickle at worldnet.att.net Tue Nov 26 23:53:02 2002
From: g.r.vansickle at worldnet.att.net (Gary R. Van Sickle)
Date: Tue Nov 26 23:53:02 2002
Subject: [ODE] box-box performance
In-Reply-To: <1038306297.3de34bf91ea73@webmail.t-online.de>
Message-ID: