(slipch)
Date: Mon Oct 7 02:00:02 2002
Subject: [ODE] CCylinder orientation
Message-ID: <256729045.20021007120229@gsc-game.kiev.ua>
Hello ODE,
How does CCylinder oriented?
When I look at collision functions it seems cylinder axis
is along axis Z. But when it created it is along OY.
I fail to find where the orientation changed.
I created cylinder class and with cylinder axis along OY.
When I replace CCylinder with Cylinder in my model everything works
right.
May someone explain how can it happen?
--
Best regards,
slipch mailto:slipch@gsc-game.kiev.ua
From thubba at gmx.net Mon Oct 7 03:04:02 2002
From: thubba at gmx.net (Michael Scharvogel)
Date: Mon Oct 7 03:04:02 2002
Subject: [ODE] Hinge problem
Message-ID: <009301c26de8$a5f2fac0$c36abb84@tig>
hi folks...
I build up a small test robot. As a matter of fact i am far from that and
still trying to build the robot model. Like with an ant the legs shall be
segmented. For a first try I have six legs but only two hinges per leg.
The first part of each leg is connected to the body and its hinge can move
between -45 and 45 degrees (yes I am using rad for the ode stuff :-)
The next part of each leg can move up and down. The corresponding hinge is
limited by 0 degree as low stop and 70 degree as high stop.
I build the whole thing up at a hight of 2 and let it drop down on the
floor.
It's working just fine. But after lying on the floor for a short while, my
bug seems to get bored and stands up...
That would be just fine if only I had told it to do so...
It seems to me, that the up / down hinge try to achiev their hi limit
position...
But why ????
Any comments on that ?
cya&bfn, mike.
From benny at kramekweb.com Mon Oct 7 07:44:01 2002
From: benny at kramekweb.com (Benny Kramek)
Date: Mon Oct 7 07:44:01 2002
Subject: [ODE] Hinge problem
References: <009301c26de8$a5f2fac0$c36abb84@tig>
Message-ID: <3DA1A78C.10808@kramekweb.com>
You probably know this already, but when you anchor the joint, then that
relative orientation of the bodies is considered 0.
Michael Scharvogel wrote:
> hi folks...
>
> I build up a small test robot. As a matter of fact i am far from that and
> still trying to build the robot model. Like with an ant the legs shall be
> segmented. For a first try I have six legs but only two hinges per leg.
> The first part of each leg is connected to the body and its hinge can move
> between -45 and 45 degrees (yes I am using rad for the ode stuff :-)
>
> The next part of each leg can move up and down. The corresponding hinge is
> limited by 0 degree as low stop and 70 degree as high stop.
> I build the whole thing up at a hight of 2 and let it drop down on the
> floor.
> It's working just fine. But after lying on the floor for a short while, my
> bug seems to get bored and stands up...
> That would be just fine if only I had told it to do so...
> It seems to me, that the up / down hinge try to achiev their hi limit
> position...
> But why ????
>
> Any comments on that ?
>
> cya&bfn, mike.
>
>
> _______________________________________________
> ODE mailing list
> ODE@q12.org
> http://q12.org/mailman/listinfo/ode
>
>
From ivan.bolcina at volja.net Mon Oct 7 14:36:02 2002
From: ivan.bolcina at volja.net (Ivan Bolcina)
Date: Mon Oct 7 14:36:02 2002
Subject: [ODE] opcode
Message-ID: <002401c26e49$6ef9fc60$0100a8c0@vectra>
This is a multi-part message in MIME format.
------=_NextPart_000_0021_01C26E5A.2E2D7C00
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Pierre,
I switched from coldet to opcode, and you were right, it is faster, =
specially, if I am colliding two complex objects. Well, thanx for a nice =
library.
Any news about "opcode - ode - triangle collider - mesh to mesh" stuff? =
Any plans? What are alternatives?=20
bye,ivan
------=_NextPart_000_0021_01C26E5A.2E2D7C00
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Pierre,
I switched from coldet to opcode, =
and you were=20
right, it is faster, specially, if I am colliding two complex objects. =
Well,=20
thanx for a nice library.
Any news about "opcode - ode - triangle =
collider -=20
mesh to mesh" stuff? Any plans? What are alternatives? =
bye,ivan
------=_NextPart_000_0021_01C26E5A.2E2D7C00--
From p.terdiman at wanadoo.fr Mon Oct 7 19:22:01 2002
From: p.terdiman at wanadoo.fr (Pierre Terdiman)
Date: Mon Oct 7 19:22:01 2002
Subject: [ODE] opcode
References: <002401c26e49$6ef9fc60$0100a8c0@vectra>
Message-ID: <048501c26e71$305f31a0$0e00000a@pierre>
This is a multi-part message in MIME format.
------=_NextPart_000_03E9_01C26E6E.81B55DC0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Pierre,
I switched from coldet to opcode, and you were right, it is faster, =
specially, if I am colliding two complex objects.
Cool :)
Then it must depend on the app / scenario, since "pro" 's conclusion was =
different.
No real surprise : as often when it comes to optimizing, one has to test =
and see for himself...
Now I'd like to point something out : Opcode's goal was NOT to go faster =
than X or Y, the goal was to use less memory...
So beware : IIRC in ColDet 1.1 the node classes use virtual methods, =
which wastes a lot of ram to begin with.
Any news about "opcode - ode - triangle collider - mesh to mesh" stuff? =
Any plans? What are alternatives?=20
=20
I'd say it's not going to be implemented soon. Penetration depth between =
two arbitrary meshes is very hard to compute - especially if you want =
the result to run in realtime.
Alternatives :
- decompose the mesh in convex parts (SWIFT++)
- then compute penetration depth between convex polytopes (SOLID 3.0 or =
DEEP)
or
- use a composite object approximatively bounding each mesh
- then use standard primitive-primitive collision routines
Second version is easier, probably runs faster, and most games (if not =
all) do that.
BTW it has already been discussed - check the archives.
Pierre
------=_NextPart_000_03E9_01C26E6E.81B55DC0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Pierre,
I switched from coldet to =
opcode, and you=20
were right, it is faster, specially, if I am colliding two complex=20
objects.
Cool :)
Then it must depend on the app / =
scenario, since=20
"pro" 's conclusion was different.
No real surprise : as often when it =
comes to=20
optimizing, one has to test and see for himself...
Now I'd like to point something =
out : Opcode's=20
goal was NOT to go faster than X or Y, the goal was to use less=20
memory...
So beware : IIRC in ColDet 1.1 the node =
classes use=20
virtual methods, which wastes a lot of ram to begin with.
Any news about "opcode - ode - =
triangle=20
collider - mesh to mesh" stuff? Any plans? What are alternatives?=20
I'd say it's not going to be =
implemented soon.=20
Penetration depth between two arbitrary meshes is very hard to compute - =
especially if you want the result to run in realtime.
Alternatives :
- decompose the mesh in convex parts=20
(SWIFT++)
- then compute penetration depth =
between convex=20
polytopes (SOLID 3.0 or DEEP)
or
- use a composite object =
approximatively bounding=20
each mesh
- then use standard primitive-primitive =
collision=20
routines
Second version is easier, probably runs =
faster, and=20
most games (if not all) do that.
BTW it has already been discussed - =
check the=20
archives.
Pierre
------=_NextPart_000_03E9_01C26E6E.81B55DC0--
From p.terdiman at wanadoo.fr Mon Oct 7 19:23:43 2002
From: p.terdiman at wanadoo.fr (Pierre Terdiman)
Date: Mon Oct 7 19:23:43 2002
Subject: Re[2]: [ODE] coldet
References: <003201c26c52$2b3b7470$0100a8c0@vectra> <13557354421.20021006101234@glassegg.com>
Message-ID: <048901c26e71$31d81600$0e00000a@pierre>
>My only problem with Opcode is Pierre write
>code in 1600x1200 screen. :-) .
I plead guilty.
From grubertm at hotmail.com Mon Oct 7 20:22:01 2002
From: grubertm at hotmail.com (Marco Grubert)
Date: Mon Oct 7 20:22:01 2002
Subject: [ODE] Inertia & tumbling objects
Message-ID:
Hello,
maybe someone can explain why the following thing happens:
I create a body which is slightly rotated (1 degree around yaw/z axis) and
set it's inertia tensor: dm.setBox( fMass/(x*y*z), x, y,z ); then apply a
constant torque of 5000 units around the x-axis. after a few seconds of
simulated time the box starts flipping around and a few more seconds later
it comes to a complete stop. This happens when x,y,z are set to 40,20,10 (or
similar). If I make the cube's edges equal, or set the initial orientation
to 0 degrees the cube keeps on spinning indefinitely.
So my questions are: why does the rotation suddenly stop? shouldn't this
rotation lead to a rotation about a stable axis?
Regards,
Marco Grubert
From slipch Tue Oct 8 00:45:02 2002
From: slipch (slipch)
Date: Tue Oct 8 00:45:02 2002
Subject: Re[3]: [ODE] coldet
In-Reply-To: <13557354421.20021006101234@glassegg.com>
References: <003201c26c52$2b3b7470$0100a8c0@vectra>
<13557354421.20021006101234@glassegg.com>
Message-ID: <1612357489.20021008104703@gsc-game.kiev.ua>
Hello Nguyen,
Sunday, October 6, 2002, 6:12:34 AM, you wrote:
NB> I had tried many collision detect package like RAPID, Coldet ,
NB> Opcode (1.1). IMHO , Opcode is faster overall and it's
NB> well-designed . My only problem with Opcode is Pierre write
I just look through coldet site.
Do I understand right - it can detect contact points (and may be
contact normals)?
If it can then it is not like Opcode.
--
Best regards,
slipch mailto:slipch@gsc-game.kiev.ua
From Nguyen Binh Tue Oct 8 05:05:03 2002
From: Nguyen Binh (Nguyen Binh)
Date: Tue Oct 8 05:05:03 2002
Subject: Re[4]: [ODE] coldet
In-Reply-To: <1612357489.20021008104703@gsc-game.kiev.ua>
References: <003201c26c52$2b3b7470$0100a8c0@vectra>
<13557354421.20021006101234@glassegg.com>
<1612357489.20021008104703@gsc-game.kiev.ua>
Message-ID: <17328684015.20021008184833@glassegg.com>
s> I just look through coldet site.
s> Do I understand right - it can detect contact points (and may be
s> contact normals)?
s> If it can then it is not like Opcode.
Yes, sure Coldet can detect contact points (contacts normal is
another case, but I think you can have normals from points on mesh)
Then how is Opcode and coldet different? Sorry , I can't catch you
in this...
--
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 slipch Tue Oct 8 05:47:02 2002
From: slipch (slipch)
Date: Tue Oct 8 05:47:02 2002
Subject: Re[5]: [ODE] coldet
In-Reply-To: <10020202920.20021008154429@gsc-game.kiev.ua>
References: <003201c26c52$2b3b7470$0100a8c0@vectra>
<13557354421.20021006101234@glassegg.com>
<1612357489.20021008104703@gsc-game.kiev.ua>
<17328684015.20021008184833@glassegg.com>
<10020202920.20021008154429@gsc-game.kiev.ua>
Message-ID: <11220506446.20021008154932@gsc-game.kiev.ua>
Hello Nguyen,
Tuesday, October 8, 2002, 2:48:33 PM, you wrote:
NB> Yes, sure Coldet can detect contact points (contacts normal is
NB> another case, but I think you can have normals from points on mesh)
NB> Then how is Opcode and coldet different? Sorry , I can't catch you
NB> in this...
I am sorry. I rather new in it and do not know Opcode properly.
I decided that it can only be used to find intersecting triangles
not contact points.
--
Best regards,
slipch mailto:slipch@gsc-game.kiev.ua
From slipch Tue Oct 8 05:54:01 2002
From: slipch (slipch)
Date: Tue Oct 8 05:54:01 2002
Subject: [ODE] CCylinder
Message-ID: <4520922044.20021008155628@gsc-game.kiev.ua>
Hello ODE,
Can some one tell me along which axis CCylinder aligned when
created axis-Z or axis-Y?
--
Best regards,
slipch mailto:slipch@gsc-game.kiev.ua
From p.terdiman at wanadoo.fr Tue Oct 8 06:10:02 2002
From: p.terdiman at wanadoo.fr (Pierre Terdiman)
Date: Tue Oct 8 06:10:02 2002
Subject: Re[6]: [ODE] coldet
References: <003201c26c52$2b3b7470$0100a8c0@vectra><13557354421.20021006101234@glassegg.com><1612357489.20021008104703@gsc-game.kiev.ua><17328684015.20021008184833@glassegg.com><10020202920.20021008154429@gsc-game.kiev.ua> <11220506446.20021008154932@gsc-game.kiev.ua>
Message-ID: <015801c26ecb$a239ab20$0e00000a@pierre>
> NB> Yes, sure Coldet can detect contact points (contacts normal is
> NB> another case, but I think you can have normals from points on mesh)
>
> NB> Then how is Opcode and coldet different? Sorry , I can't catch you
> NB> in this...
>
> I am sorry. I rather new in it and do not know Opcode properly.
> I decided that it can only be used to find intersecting triangles
> not contact points.
And you would be right : I just report intersecting triangles indeed.
But (I think) the point is, slapping a dedicated triangle-triangle routine
on returned pairs is probably best done in the client code, since many apps
will probably need different ways to drive their collision response.
That's what ColDet does, using two different triangle-triangle overlap
codes, depending on the situation. The fast one is the standard routine from
Tomas Möller. That's also what I'm using. The slow one (that computes a
collision point) is named "MyTriTri.c" in ColDet. It would be unfortunate to
use it in the generic case since it's slower. But you can grab it and use it
as well on Opcode's returned pairs, maybe (modulo license troubles).
Anyway I'm not sure it's really that useful. Returning a single collision
point is dubious, and that's not even the problem - the problem is the
penetration depth, at least for ODE. [Now, right, 100% Baraff-like
simulators don't need this.]
Well, various libs, various strategies, see for your particular needs.
Pierre
From I.Munro at herts.ac.uk Tue Oct 8 06:31:02 2002
From: I.Munro at herts.ac.uk (Ian Munro)
Date: Tue Oct 8 06:31:02 2002
Subject: [ODE] CCylinder
Message-ID:
> Can some one tell me along which axis CCylinder aligned when
> created axis-Z or axis-Y?
z axis.
From orp at uni.de Tue Oct 8 06:42:02 2002
From: orp at uni.de (pro)
Date: Tue Oct 8 06:42:02 2002
Subject: [ODE] commercial SOLID3.0 will use ODE
Message-ID: <000701c26ed0$d2dbac60$7334188d@brainpool>
The upcoming version 4.0 will feature:
a.. Coupling to ODE, a free open source physics engine
........
http://www.libsolid.com
this could be interesting
From bry03redskins at hotmail.com Tue Oct 8 07:52:01 2002
From: bry03redskins at hotmail.com (Bryan Hudock)
Date: Tue Oct 8 07:52:01 2002
Subject: [ODE] display problem
Message-ID:
I have succesfully installed and used Open Dynamics Engine on a linux
machine (Red Hat 7.0). However, once a program using the library is
exited from, all further ODE programs fail to display. The simulation
appears to still be functional, but the display is a black screen.
The only way I currently have to solve the problem is to exit and
rerun X-Windows each time I want to run a program. If you have any
insight into this problem it would be greatly appreciated. Thank you
for your time.
_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com
From slipch Tue Oct 8 07:55:02 2002
From: slipch (slipch)
Date: Tue Oct 8 07:55:02 2002
Subject: Re[2]: [ODE] CCylinder
In-Reply-To:
References:
Message-ID: <4228173581.20021008175719@gsc-game.kiev.ua>
Hello Ian,
Tuesday, October 8, 2002, 4:26:14 PM, you wrote:
>> Can some one tell me along which axis CCylinder aligned when
>> created axis-Z or axis-Y?
IM> z axis.
It is what is written in documentation
Then why when I create CCylinder it appears aligned along Y axis.
--
Best regards,
slipch mailto:slipch@gsc-game.kiev.ua
From rtonge90 at yahoo.co.uk Tue Oct 8 08:09:01 2002
From: rtonge90 at yahoo.co.uk (=?iso-8859-1?q?Richard=20Tonge?=)
Date: Tue Oct 8 08:09:01 2002
Subject: [ODE] Collision with Quake or Skeletal type models...
Message-ID: <20021008150831.4556.qmail@web14913.mail.yahoo.com>
Hi Andy, Dominique
>It can however be very time consuming and error prone
>to attempt to describe any system of even reasonable
>complexity using source code.
Yes, setting up skeletons in source is hard. Using a
physics authoring tool is much easier.
>You may even be able to use something like havok and
>3dsmax to generate your data model but then actually
>drive the system with ODE. This would be an amusing
>hack since your runtime could remain open source.
Yes, using Havok authored data to drive the ODE
runtime is an interesting idea, however I can see a
few problems.
1 3DSmax and the Havok plugin (or the new combined
product) are expensive if you dont already own them.
2 The Havok physics model is quite different from the
ODE physics model, so any tuning parameters you set at
authoring time wont necessarily have the same effect
at run time. Some joints parameters in Havok might not
have equivalents in ODE.
3 The Havok file format is binary, so you would have
to reverse engineer it.
Have any of you guys seen KAT, the physics authoring
tool that comes free with Unreal Tournament 2003?
It is a standalone tool, so you dont need max. It was
specifically designed for authoring physics, so its
interface is much simpler than max's. Its file format
is an XML formatted text file, so you wouldnt need to
reverse engineer it to use it with ODE. It comes with
all the physics data used to make UT2003 in the XML
format which you are free to edit.
Also, it is based on MathEngine Karma, which has
similar ancestry to ODE. This means that many tuning
parameters behave in the same way. For example ERP and
CFM in ODE are exactly the same as gamma and epsilon
in Karma. This means that a skeleton tuned in KAT
should behave similarly in ODE.
Richard Tonge
PS2 Optimisation Engineer
MathEngine
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
From slipch Tue Oct 8 08:13:01 2002
From: slipch (slipch)
Date: Tue Oct 8 08:13:01 2002
Subject: Re[3]: [ODE] CCylinder
In-Reply-To: <4228173581.20021008175719@gsc-game.kiev.ua>
References:
<4228173581.20021008175719@gsc-game.kiev.ua>
Message-ID: <10729212845.20021008181439@gsc-game.kiev.ua>
Hello slipch,
Tuesday, October 8, 2002, 5:57:19 PM, you wrote:
IM>> z axis.
s> It is what is written in documentation
s> Then why when I create CCylinder it appears aligned along Y axis.
I have to apologize.
I am not right it is only drawn aligned along Y-axis.
--
Best regards,
slipch mailto:slipch@gsc-game.kiev.ua
From I.Munro at herts.ac.uk Tue Oct 8 08:27:02 2002
From: I.Munro at herts.ac.uk (Ian Munro)
Date: Tue Oct 8 08:27:02 2002
Subject: Re[2]: [ODE] CCylinder
Message-ID:
>
> IM> z axis.
>
> It is what is written in documentation
> Then why when I create CCylinder it appears aligned along Y axis.
I don't know what it says in the documentation, but when compiled under vc7
all the CCyclinders I generate (and my app only uses CCylinders) are
initially aligned on the z axis.
Sorry, I haven't a clue why yours come out on the Y axis!
Ian
From coding at natew.com Tue Oct 8 11:19:01 2002
From: coding at natew.com (Nate W)
Date: Tue Oct 8 11:19:01 2002
Subject: [ODE] CCylinder
In-Reply-To: <4520922044.20021008155628@gsc-game.kiev.ua>
Message-ID:
On Tue, 8 Oct 2002, slipch wrote:
> Can some one tell me along which axis CCylinder aligned when
> created axis-Z or axis-Y?
I don't know off the top of my head, but have a look at the test_buggy
sample app. It creates capped cylinders for the wheel's collision hulls,
it should be evident from the source code what axis they're on to begin
with.
--
Nate Waddoups
Redmond WA USA
http://www.natew.com
From coding at natew.com Tue Oct 8 11:31:01 2002
From: coding at natew.com (Nate W)
Date: Tue Oct 8 11:31:01 2002
Subject: [ODE] Collision with Quake or Skeletal type models...
In-Reply-To: <20021008150831.4556.qmail@web14913.mail.yahoo.com>
Message-ID:
On Tue, 8 Oct 2002, [iso-8859-1] Richard Tonge wrote:
> Yes, setting up skeletons in source is hard. Using a
> physics authoring tool is much easier.
I happen to have written something like that using ODE:
http://www.natew.com/juice/
The file format is a trivial dialect of XML, and I'll be happy to help if
you have trouble making use of it.
It runs under Windows, I hope that's not a problem. :-)
--
Nate Waddoups
Redmond WA USA
http://www.natew.com
From dmcclurg at pandemicstudios.com.au Tue Oct 8 15:32:02 2002
From: dmcclurg at pandemicstudios.com.au (David McClurg)
Date: Tue Oct 8 15:32:02 2002
Subject: [ODE] geom group patch
Message-ID:
now that i'm using geom groups more, i had to add a query function to see if a geom was in a group
int dGeomGroupQuery (dxGeom *g, dxGeom *x)
{
dUASSERT (g && g->_class->num == dGeomGroupClass,"argument not a geomgroup");
dxGeomGroup *gr = (dxGeomGroup*) CLASSDATA(g);
for (int i=0; i < gr->parts.size(); i++) {
if (gr->parts[i] == x) {
return 1;
}
}
return 0;
}
From slipch Wed Oct 9 00:22:01 2002
From: slipch (slipch)
Date: Wed Oct 9 00:22:01 2002
Subject: Re[2]: [ODE] CCylinder
In-Reply-To:
References:
Message-ID: <1911113781.20021009102331@gsc-game.kiev.ua>
Hello Nate,
NW> I don't know off the top of my head, but have a look at the test_buggy
NW> sample app. It creates capped cylinders for the wheel's collision hulls,
NW> it should be evident from the source code what axis they're on to begin
NW> with.
In my version of test_buggy spheres used for wheels. Meshes
created for cylinders in test_buggy with Open Engine are
orthogonal to Ode cylinders so aligned along axis - Y. That what
misled me.
--
Best regards,
slipch mailto:slipch@gsc-game.kiev.ua
From slipch Wed Oct 9 00:51:01 2002
From: slipch (slipch)
Date: Wed Oct 9 00:51:01 2002
Subject: [ODE] always diabled body
Message-ID: <192913489.20021009105330@gsc-game.kiev.ua>
Hello ODE,
Can I create a Body which do not ever be enabled, even when
connected to an enabled body by a Joint.
--
Best regards,
slipch mailto:slipch@gsc-game.kiev.ua
From erwin at vo.com Wed Oct 9 01:14:01 2002
From: erwin at vo.com (Erwin de Vries)
Date: Wed Oct 9 01:14:01 2002
Subject: [ODE] always diabled body
References: <192913489.20021009105330@gsc-game.kiev.ua>
Message-ID: <001001c26f6b$d601ef30$8800a8c0@erwin>
What is the purpose of that body then?
Erwin
----- Original Message -----
From: "slipch"
To:
Sent: Wednesday, October 09, 2002 9:53 AM
Subject: [ODE] always diabled body
> Hello ODE,
>
> Can I create a Body which do not ever be enabled, even when
> connected to an enabled body by a Joint.
>
> --
> Best regards,
> slipch mailto:slipch@gsc-game.kiev.ua
>
> _______________________________________________
> ODE mailing list
> ODE@q12.org
> http://q12.org/mailman/listinfo/ode
>
>
From slipch Wed Oct 9 02:22:02 2002
From: slipch (slipch)
Date: Wed Oct 9 02:22:02 2002
Subject: Re[2]: [ODE] always diabled body
In-Reply-To: <001001c26f6b$d601ef30$8800a8c0@erwin>
References: <192913489.20021009105330@gsc-game.kiev.ua>
<001001c26f6b$d601ef30$8800a8c0@erwin>
Message-ID: <1428374912.20021009122432@gsc-game.kiev.ua>
Hello Erwin,
Wednesday, October 9, 2002, 11:14:05 AM, you wrote:
>> Can I create a Body which do not ever be enabled, even when
>> connected to an enabled body by a Joint.
>>
EdV> What is the purpose of that body then?
EdV> Erwin
I want to hook enabled body to some point and drag it during
simulation simply setting the point position.
--
Best regards,
slipch mailto:slipch@gsc-game.kiev.ua
From slipch Wed Oct 9 04:32:02 2002
From: slipch (slipch)
Date: Wed Oct 9 04:32:02 2002
Subject: Re[2]: [ODE] always diabled body
In-Reply-To: <3DA417C9.3070109@kramekweb.com>
References: <192913489.20021009105330@gsc-game.kiev.ua>
<001001c26f6b$d601ef30$8800a8c0@erwin>
<1428374912.20021009122432@gsc-game.kiev.ua> <3DA417C9.3070109@kramekweb.com>
Message-ID: <17816151855.20021009143409@gsc-game.kiev.ua>
Hello Benny,
Wednesday, October 9, 2002, 2:49:29 PM, you wrote:
>>
>>>> Can I create a Body which do not ever be enabled, even when
>>>> connected to an enabled body by a Joint.
>>>>
>>>
>>
>> EdV> What is the purpose of that body then?
>>
>> EdV> Erwin
>>
>> I want to hook enabled body to some point and drag it during
>> simulation simply setting the point position.
>>
BK> You can give your body a very large mass and disable gravity on it. Then
BK> it will move very little on it's own, and you can move it around with
BK> dBodySetPos()
Works perfect. Thank you very much.
--
Best regards,
slipch mailto:slipch@gsc-game.kiev.ua
From p.terdiman at wanadoo.fr Wed Oct 9 06:09:02 2002
From: p.terdiman at wanadoo.fr (Pierre Terdiman)
Date: Wed Oct 9 06:09:02 2002
Subject: Re[2]: [ODE] always diabled body
References: <192913489.20021009105330@gsc-game.kiev.ua><001001c26f6b$d601ef30$8800a8c0@erwin><1428374912.20021009122432@gsc-game.kiev.ua> <3DA417C9.3070109@kramekweb.com> <17816151855.20021009143409@gsc-game.kiev.ua>
Message-ID: <00b601c26f94$ac7e5a80$0e00000a@pierre>
> BK> You can give your body a very large mass and disable gravity on it.
Then
> BK> it will move very little on it's own, and you can move it around with
> BK> dBodySetPos()
>
> Works perfect. Thank you very much.
Usually a null mass is used to mark fixed bodies. Does it work in ODE ?
Pierre
From erwin at vo.com Wed Oct 9 06:58:01 2002
From: erwin at vo.com (Erwin de Vries)
Date: Wed Oct 9 06:58:01 2002
Subject: Re[2]: [ODE] always diabled body
References: <192913489.20021009105330@gsc-game.kiev.ua><001001c26f6b$d601ef30$8800a8c0@erwin><1428374912.20021009122432@gsc-game.kiev.ua> <3DA417C9.3070109@kramekweb.com> <17816151855.20021009143409@gsc-game.kiev.ua> <00b601c26f94$ac7e5a80$0e00000a@pierre>
Message-ID: <005f01c26f9b$d761a570$8800a8c0@erwin>
No. But i dont see the point in creating a fixed body anyway. Just DONT use
a body if you dont want dynamics.
Erwin
----- Original Message -----
From: "Pierre Terdiman"
To:
Sent: Wednesday, October 09, 2002 3:06 PM
Subject: Re: Re[2]: [ODE] always diabled body
> > BK> You can give your body a very large mass and disable gravity on it.
> Then
> > BK> it will move very little on it's own, and you can move it around
with
> > BK> dBodySetPos()
> >
> > Works perfect. Thank you very much.
>
> Usually a null mass is used to mark fixed bodies. Does it work in ODE ?
>
> Pierre
>
> _______________________________________________
> ODE mailing list
> ODE@q12.org
> http://q12.org/mailman/listinfo/ode
>
>
From p.terdiman at wanadoo.fr Wed Oct 9 07:17:01 2002
From: p.terdiman at wanadoo.fr (Pierre Terdiman)
Date: Wed Oct 9 07:17:01 2002
Subject: Re[2]: [ODE] always diabled body
References: <192913489.20021009105330@gsc-game.kiev.ua><001001c26f6b$d601ef30$8800a8c0@erwin><1428374912.20021009122432@gsc-game.kiev.ua> <3DA417C9.3070109@kramekweb.com> <17816151855.20021009143409@gsc-game.kiev.ua> <00b601c26f94$ac7e5a80$0e00000a@pierre> <005f01c26f9b$d761a570$8800a8c0@erwin>
Message-ID: <010401c26f9e$24e99940$0e00000a@pierre>
> No. But i dont see the point in creating a fixed body anyway. Just DONT
use
> a body if you dont want dynamics.
That's a common thing nonetheless, say for planes. A ground plane is fixed,
yet you want your bodies to collide with it.
Or for a flag, when the cloth patch is attached to a fixed base.
(etc)
Pierre
From martin at metahuman.org Wed Oct 9 07:25:02 2002
From: martin at metahuman.org (Martin C. Martin)
Date: Wed Oct 9 07:25:02 2002
Subject: [ODE] always diabled body
References: <192913489.20021009105330@gsc-game.kiev.ua><001001c26f6b$d601ef30$8800a8c0@erwin><1428374912.20021009122432@gsc-game.kiev.ua> <3DA417C9.3070109@kramekweb.com> <17816151855.20021009143409@gsc-game.kiev.ua> <00b601c26f94$ac7e5a80$0e00000a@pierre> <005f01c26f9b$d761a570$8800a8c0@erwin>
Message-ID: <3DA43BF9.8D81E460@metahuman.org>
Erwin de Vries wrote:
>
> No. But i dont see the point in creating a fixed body anyway. Just DONT use
> a body if you dont want dynamics.
What the poster is trying to do is to control a body by putting a joint on
it, and moving the location of the half of the joint that's not on the
body. They're doing this by creating a second body, attaching the joint
to it, and moving it.
IIRC, the ODE API seems to treat joints as having a single location,
rather than two locations. Of course, most joints try to keep those two
locations the same, but in practice they'll rarely have exactly the same
location. Perhaps the API could be extended so you could set the location
of each half of a joint independently? Or is there already a way to do
this that I've missed?
- Martin
From slipch Wed Oct 9 07:34:02 2002
From: slipch (slipch)
Date: Wed Oct 9 07:34:02 2002
Subject: Re[4]: [ODE] always diabled body
In-Reply-To: <005f01c26f9b$d761a570$8800a8c0@erwin>
References: <192913489.20021009105330@gsc-game.kiev.ua><001001c26f6b$d601ef30$8800a8c0@erwin><1428374912.20021009122432@gsc-game.kiev.ua>
<3DA417C9.3070109@kramekweb.com> <17816151855.20021009143409@gsc-game.kiev.ua>
<00b601c26f94$ac7e5a80$0e00000a@pierre> <005f01c26f9b$d761a570$8800a8c0@erwin>
Message-ID: <327081641.20021009173618@gsc-game.kiev.ua>
Hello Erwin,
Wednesday, October 9, 2002, 4:57:41 PM, you wrote:
EdV> No. But i dont see the point in creating a fixed body anyway. Just DONT use
EdV> a body if you dont want dynamics.
EdV> Erwin
I need body because I need to attach enabled body to something that
I can move during simulation setting its position.
EdV> ----- Original Message -----
EdV> From: "Pierre Terdiman"
EdV> To:
EdV> Sent: Wednesday, October 09, 2002 3:06 PM
EdV> Subject: Re: Re[2]: [ODE] always diabled body
>> > BK> You can give your body a very large mass and disable gravity on it.
>> Then
>> > BK> it will move very little on it's own, and you can move it around
EdV> with
>> > BK> dBodySetPos()
>> >
>> > Works perfect. Thank you very much.
>>
>> Usually a null mass is used to mark fixed bodies. Does it work in ODE ?
>>
>> Pierre
>>
>> _______________________________________________
>> ODE mailing list
>> ODE@q12.org
>> http://q12.org/mailman/listinfo/ode
>>
>>
--
Best regards,
slipch mailto:slipch@gsc-game.kiev.ua
From erwin at vo.com Wed Oct 9 07:39:01 2002
From: erwin at vo.com (Erwin de Vries)
Date: Wed Oct 9 07:39:01 2002
Subject: Re[2]: [ODE] always diabled body
References: <192913489.20021009105330@gsc-game.kiev.ua><001001c26f6b$d601ef30$8800a8c0@erwin><1428374912.20021009122432@gsc-game.kiev.ua> <3DA417C9.3070109@kramekweb.com> <17816151855.20021009143409@gsc-game.kiev.ua> <00b601c26f94$ac7e5a80$0e00000a@pierre> <005f01c26f9b$d761a570$8800a8c0@erwin> <010401c26f9e$24e99940$0e00000a@pierre>
Message-ID: <006d01c26fa1$94866a50$8800a8c0@erwin>
In those cases you only create a geometry. Without a body.
Erwin
----- Original Message -----
From: "Pierre Terdiman"
To:
Sent: Wednesday, October 09, 2002 4:14 PM
Subject: Re: Re[2]: [ODE] always diabled body
> > No. But i dont see the point in creating a fixed body anyway. Just DONT
> use
> > a body if you dont want dynamics.
>
> That's a common thing nonetheless, say for planes. A ground plane is
fixed,
> yet you want your bodies to collide with it.
>
> Or for a flag, when the cloth patch is attached to a fixed base.
>
> (etc)
>
> Pierre
>
> _______________________________________________
> ODE mailing list
> ODE@q12.org
> http://q12.org/mailman/listinfo/ode
>
>
From p.terdiman at wanadoo.fr Wed Oct 9 07:46:01 2002
From: p.terdiman at wanadoo.fr (Pierre Terdiman)
Date: Wed Oct 9 07:46:01 2002
Subject: Re[2]: [ODE] always diabled body
References: <192913489.20021009105330@gsc-game.kiev.ua><001001c26f6b$d601ef30$8800a8c0@erwin><1428374912.20021009122432@gsc-game.kiev.ua> <3DA417C9.3070109@kramekweb.com> <17816151855.20021009143409@gsc-game.kiev.ua> <00b601c26f94$ac7e5a80$0e00000a@pierre> <005f01c26f9b$d761a570$8800a8c0@erwin> <010401c26f9e$24e99940$0e00000a@pierre> <006d01c26fa1$94866a50$8800a8c0@erwin>
Message-ID: <016601c26fa2$3251c540$0e00000a@pierre>
> In those cases you only create a geometry. Without a body.
Ah, perhaps. Ok. Well, it only shows I'm not actually using ODE :)
I think it works with null masses in Havok nonetheless.
Pierre
PS: let's welcome a new player after Mathengine, Havok, ODE, etc :
www.novodex.com
From slipch Wed Oct 9 09:22:01 2002
From: slipch (slipch)
Date: Wed Oct 9 09:22:01 2002
Subject: [ODE] Cylinder colisions
Message-ID: <17333538595.20021009192355@gsc-game.kiev.ua>
------------FF1101193C4A0652
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Hello ODE,
Hear is cylinder class for ODE.
Cylinder class includes collisions
Cylinder - Box Cylinder-Cylinder Cylinder - Sphere and Cylinder-Plain
I also included Cylinder - Tri-Mesh in my version of Triangle
collider.
I put some more information in readme.txt.
--
Best regards,
Konstantin Slipchenko mailto:slipch@gsc-game.kiev.ua
------------FF1101193C4A0652
Content-Type: application/x-zip-compressed; name="dCylinder.zip"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="dCylinder.zip"
UEsDBBQAAgAIAGxkSS1uoenXMB8AAAuOAAANAAAAZEN5bGluZGVyLmNwcOw9/XPbtpI/KzP5HzC5
mVd9UJYBqm1eHOVqO72bzuQ9107uZm76OjmKom02NMmSVGwnk//99gMAQYr6sOuk7U3TSiaxi8UC
WOwuFkvq8aN/i9MwWS4i8TxbRJMwu7rK0r3LF49bgIsou+ooLrIqqOLOGvC5CqrLDshVdJUVt12A
uAy7KM1/icKq7KoQVEV8Q4DHjyaTJrAswkZVB/4kKIoAOHjSJoh1sKtv47SKijRImo0+WRzfJnG6
iAqqO5mIi/h9lIpA5BnVEP+bfyWqDAoWx1laBWH1n0DNE0VULYtUVJdRAyCCiqjkYiTKd3Eu5rdV
VO5hb8qqWIaVWNyYFsXHHmCG+u7xIyEWZ1GQiCJYxMvSSz4cIFzfiSRKL6pLESRZeiE+iOAmLsVw
8vjRp4MG8df5ZVRE4mOb3EEPiZUM5aKVukfZja743zDGWeGLMl5ExAVeaBZK0b/xbr0PA1MfxknY
YTxOgrIUMzGWBIOhXkTncRqJ45N/vjk8ftPPPRyXgej33XEbYkE/vAyK4QCAI9EnrMGA5eAz/9vS
RBgXYRL9gOJQwsDA6rhfE9UlzNkii0pxniVJdh2nF8+oPHgHZdV1JrilUgSlSLPiKkhKlL08CVIo
TKWXKk+EEcklyWcpwlx6Ya68IF3oaQXMQnqFQsow8otSJDj+WSquL+Pw0rYRm/7UiOfZ0hI+kd6J
EuMaDbot5lF1HUUs9kQVm9VCdR2DeGrmgCvNDfCC9Hv478T3Tqb3J6ksSeobr0BgGkYpEvE5UoA6
MQ5dowlEBjWYL2ElikVcVkEaRtjBMTBEf6bwR/Ed/JlihTgVT2gkngjT0FUUpDw6lulGT/TAEdMl
zB0McmXb+yJSHKc0gvMsS8Sq0PbDLEWOUCsMUZoa9yhIWmG0ICB0LUxlMOHCqArq/QDUB4NCOVu8
PHkjp30knMrBgYWoGqJAoh1IVhJoOu2TrDcgb9UMvofwsaVlnEKpHBPUluZy1g+hUCHuYEJINVAB
UI1D2QKaXiT57GMuh6n8af/nUa6GqYILj0umpmRqSp6akqc/f3KppHhzfHby+rXEvngzr+6PwXl1
LGcfkxzIj2GEsBW4kXwj6UbxjWrSfnWs6nrKrafcesrUo24fekfesXf09hA/b5X30kIq6VXKq3yv
mkLZIY0/cJwir0d8B5zy/XF9D5/BuJDDAtU80JwdTQ75CmYEvofwgfuXMyoZH8N1fN5/+Xx/73yA
Zq/MrqLry6ASYHyC9CISZZYsaRU9ftRDUwVaoqK1HEWLaIFasIwAG6oZDLKAVJ7nQRFUkTWlpca4
vmS9EhciWlygWs3zIgvCS4BXcjYG3kblr0V13h+/xP71KkWFY7cQdJe29aRoEO3T40cRXIKsayq6
AuFrGiOn6JMzlKo1lAqGUsFQqmGhdh5KZzDRYPcqv6sz07t2xl/tzLSrM1YWT4wIj1L4GoIskSzC
nTR3Cu8U3jWk+EQ1a6pGTdWoqdjNqOv6zbp+o67fqOs3W502a04bNaeNmtNWq6/kW2j3xMeFd0Lr
Fa4lXUu6VnTdXq3yLbR5MnVqTZ1a00Ytt55yWlNOa8ppTa20ppzWlNOaclpTtjWjAxLsGssjXHn4
VaveBHtggFMETgcHTl1l6yqsqxp1la2rsK4ydVGARR/bfY70wcvrgUQjredYB++pQHKBTwW9j3pd
Y/EBXZPRgX7O9ve+Ph/2aYRHNGoDF0E6CJIQZBNBOQiKEJRB+ITfeoVw62pd62pb62pb66qrdWy8
NSDTP9iATDcNyHTbgEy3Dci00TorrPUiM+0WmTU8ym08ym08yg4e/1AiM+0Wmd93QL6wyJj9erGM
2IiZ/0qMd4TifRYvaP9xnGSwhaoOtasgjNds/dwAtmDNomXgUUO9NiCfr+LODS6ryGGQ5JdAUt/B
xiKAiWruwvMDvEW7BRvrfI5/x8AH/NUAqQFSA6QBKA1QGqAYwI0tg+UcwKSfoQvL+cAB/ioBZGF5
A6Rwf8+geRO0AIgcI+EhfhEENf1CPJ+J/QFHF4SYTMR3330naD+MDh75cfNIXAUL+MowQpHNl2XF
2DxEQHn/QBfgKAlb8Am/ULoMeeQC+AnjvL8YHLSI9KFnI+r78Fc1GC7aNPsMQqQa/smKjGadHNGy
Wp6fI+tZXsVX8YdI4A4UY0OwC4eJh87ANjLkKIfeOYZBEi4TCrFxWCi6wbiUeHL8RJhACsZhVsRO
WlH6B8XIfHEmWZSczZmJFrlFyYcVIYR9l1vTElQrmBj30cj17oYiE1ZkF1FeXXrE/BD7zNh4exXc
hF4zPDbUo8H4FONZkXYvzz1u45gG3+3MkAFndvK5+Eh6R8o78r0zKeGj4APXCq4VXCu49uHah2vf
93jCTwHzFDBPAfMUME8B8xQwTwHzFDBPAbP0SnBFvRLhJSLAl89CDdzHXpy+j4rqLfNEjg3J9gXs
VN5Tb8R5AZ3mCEYpsnPYmt8ISdIOFwpFBWXhfWSKpLvSlV7psr3SlV7psr3SlV7p0q70f/zXqzc/
/Pjqf8BD8KXow9CC2MCapXAgMprnWLHFyOIWOXG604j/TYRi0CEoCR1eFIeoFZIPw7PvD1/1QRUP
oMiHIg2v5+oy+TBLPkzU3jkVHqGiITFDl9ypfaQsQDYBvgUoF2AZPot/wa3jmfxqiCId70V7FF6y
fTRBbhvHOZMUdjqjfoEMabUIm/czOdoHCRrtQ8MgWKsASQB/FaBY9YAUNmDSUlNqFUDUlL8KMNT8
JjVlqflqFUDUfH8VoMxonXJf/yOYlwBE/FPupC5RVOI7JT4zcqqciooqKqeioorKqahMRd+p6FNF
36noU0Xfqej7hlk9vaCsYdNvQn4cCS8jjgGUVIQriWOHJriPyGVmw/b7ew4tjH1yIB81Ga5SvMmj
NKoKFhMOumOpbieGW2q3X6qBQ4pYguKY+UiC4oKCgES4zGDXXSAPYVYsRFwZJhCVdYhRG9dxkqBB
xJgHLMiulql/BNChRk2M2toDelX0TBhtSSNEpNgK0YFGmCXLqxT7C+IPjZ4p5j/AwIvDWh3LpG5o
Trk3eyLDsOt1XEZuY/u0nLQSr6lpHgLTzVWlAxPl6lSkJc1El/EFcrs6aOVltkwWOF7nSZzn0WLP
PXh48/3rN/3oJi+kh9+KbIsXhgPxLyRV1sJHSAPQn3SFgvgv48AA1gt0YIz8tEEl+DZcBBRRPakD
c1tbLLyyxc1+gt9hmn8u9gcWiywqQoFfXfiJFwMdsix+SKGPcXWrjVKTJFtIQ2K/VpBtWZrZhQL3
YolacDIBH2YhKIQW0IJC2tENTNUyvMRYGgw2SMp5EEZmybhHWTjqaG4w8NAHlQ/u1JEcotaACzVE
ZQEXPlz4A4+U3L4JDaxhEXmgy/fSe6+89z5j1mzaPmCwz/KJ1ZBJxrZnBHjach3ckuepDwdEefpM
oK2fcbhL7p2P4Q6ZhrEHcXVgwDayPoJ+YF8AzvRBIK5BkcQo/BX5tqQFcTVgl3GUzuMC1hK0La7i
i0s8SxDUB2Dk12X8Th+FFNmyolj+ssL7FMOhRA7QuCnoXfgOJRC4ej4DZj0gFWboesboe92KMsEG
klsR3WBNQKGFQfU39aWePzIbso82BpwGr8/GfFjyPMK0mhmVAzJEnjS6Gt2lFfp6LLvoyxZ9ZemT
oCiiLz3l0PctfeJ7M33Vou9b+j4JItFXnrE1oD6WIEvnRGeTLqEzudT/nPqkoVF6rkLZP6hxtLJl
17GPBy62SHKRcooUF/kDh8JuGqlTJ4FWEjRqeovUXr0x6gtNWNszR+MANA/KkrDDIivZeKZRUKDV
qXUPkt6ildjqgreNZmFZdGsnexhUZL94QORH/Btm4O3HKf7F86/SdwOr1eGNB//nuKP9iGxcBe+Q
3cMbfaiKXYgK8BkWMW7vClIrtwmqU+3Z51kZ89Hx40fYsDkEyxWpv8HY3Eu+Jzk8vMHQCG0ExrQN
GJ+hzz9EAgcElgSWBJYE/toFKwIrAisC/92CF/+kCYF9q98/vOHjgWWpu0VOkTPAtptmWrqmEcTT
nMxdpHpjzd/noD778QwENn7uw9doNMC4RKx3LfHPGpts/IwXLgwGjDn5t7xY/l2Qsz+We3DzjG/w
+mBbG6MZEx7ibmMIjs5P8XC6sUn5gE0q2+RIbmxUPWCjft0obQVxcufLOFnUDqSdUbsuXS9Az2/X
KmyI73y7+M43i+98s/jOdxZf8oz0ep6xCm7J0RAM1QjjEx1QCVC1FqoAqo0DGQHcow+pfyP0cYbU
lxHuw4fEt7E1I83PwCNkj/A8RrGHIZNJGt2gnS9gW1PhcBuP4BI8hwRjSUkSlxgzsltWO1c2Z0Qv
2AC2HK050nvOsaNyaNeIbVc8STw/I1I1ozPai+txrniaeIZGpGwQYdpAUIygCEERwtPOmap4qqjP
2TUq1qYIsncE8qe1NvbIlUyOpTgqeEXtIsnkFkExu1KUPtMl7h36Czw4Onau8FAaYzyaBO2arsl5
xE7pjA/kEVrL6tn4qhQFN63zLtgZ5TnCbpscB5gGNCoYLMDxALXbKiZPR0/OGY4sZizgCoCZAex6
YqDoGwucukBFQLlvoU8NlCeAopRkb20SDvQG5ahrFoKyZdZvyN7rPAdeKDOvMkutc4VuXJ6bF+Dm
xessT8F5JG0cVEoDHU8sbXKKMwUE8JsA7Qzj7LCviXVxNOUIkfHqbkoBKA21YsBsFvBANymIr2sF
UQZXEcYWYOjrnT+4+zBZpM3riepa+7K19uXGtS+3rf2vt639bi1t1/4fZxl0S6+8h/Q+kHH5PaT3
s8juN0bNd0ku3BY7Ca5qCa5yHYu23KqWZ9EW229arkVbauX+ZrH9Ywut6hbaeytcFsrN6vj/l8h+
a7RTY+9PG1oOp7KxBBFZYMJ0cBOVNiaDwdowSMzmlLa8Oq6E4UgiQX5H34QMBoiycv6zJXT5sOEG
3OUvXsM4w14/BWnAL8y9ThVeK7728dofuOQSplZHPJWYzERSxza3hjHcmMXWSMYk6YhluIU2mjFJ
Hi6eUQdbJxOa+KjD+SYVZj3vm6iOdLfDl0slbkTfxC4HJkaFIVI89/LlOCfJxRNMs3egQKk/ojAp
RsB86e17Y8R4Wke5LAVlKaiagqwpYIzOV0xBeX/voOBbCn6TgmJWiILPFHxP7q9ZLzQCHAm9MAcY
GCBBJ9oz2t5koJtzlmjPxmHr0L6hlYqLJJtTInBWwBY24IcqWNK0FNnsAr5n8dEwc4BqgdIFTltA
5QKf/ryaZNDDhvskNy++HdSHrPt8yKoPyM+kOcamRBRT3WGvlvSDVb5Q1g9WOUJpP/hkWcIBaAh6
5zCM7U3HMIztTccwjO1NPQx85I/Asj5TMJPXSHfolwNGQDZ5nb0Q3zKL/NCB3lplaXM3lgdiEUU5
boX58K2WBzdVINAc11EnT9gAnnceIJo9VVgTOQl0FEpyFAoxe0hDn5qCabLzyXYLoX4XFBQmgrnZ
bRsGamMyszwSVfd+G8ujGXVVDM1jEUMBboIObHVGmWpOW+EtN9A03hZpCpqRJjzbMS1zfMsc1W5n
3l9l3kSrdJoQiYgOQTp70U7hEG3pmG8NmG0MPprh+sIByLrZLxyErBv+vIFId8ly9hvmXh20Zo8y
0jY0tNTrFr1k8FOc8ezE1tMNnJAaGj+t63Ctzty/HJgIvHwOrHh/Y17/Ril6uywQ4pDzznYZMGJx
qIdiPb7Wr6DK9/Ks1L0yOTDDPrU+IqKGSaeGUdyswTVcO4XSKHitA42Fm82m+FhPr7crN9Q4arDe
ppZ7PafdHqdpCsFtWyHglX/QtCAzJ5Wwrf43DDTT+jKrvm7ri6/8zqa/1OrvbLytAVYzNleMeIcN
32laZT2t60242GzDdzXhBknwXxguffEMT9oPtlv4nQbx9zDxXbO4aubFJivf7sNaS6+FYVfdYunq
+MEmzeboF72NGz7gvzW5u/D/b8vdla3kXXmP7F2HnGqR+x2SeSV81F0zei+x55fILybhsgX40+bc
ytWkW7k267aLAMY+Tab9hoxcHDTKwpWNtFgCcHquchNpafCcVIiuFIjmQ/x/5dI1c+magc9GHm87
kInZZGhKXsAFKGX8fob1ByaIajLmpEmZQ7dWL2IM/XLCEj3VLOqUuckkz5v16Vk/Hb2RdUUyYZqG
TqaSAzvBJFa/Ncj5V9bUvbOmVjKNAk42ssHHldBj+ZWON9YPmtNpgJNJ3nUcsFvgXEvPyNiQtcc7
rO9XgzBO6KVnj+qDLdlSEjFamWBQrBq5U6hD+/oMHjQon71LTkY1GV+DO+z7e/hyCNdVzOtAD4H8
FkhHefTxTk6WYnjGJ1FkBIZn2hT09ClPjTN1cb6xOMrFeeriSLJCvTUZFBQdMaEQDqTlczR5NGqY
oJDT0GFGatHIWcCON7vtHty3vGN7wLRzeOu+ri/Pzrjl9qrGxqnT77UHt/ePa5mma4e3vWvajW+/
g+86B2td1soa8c/nMHg751v1tiRc9bZkXPW2pFxpR7rrZHzVGjrHjN3HgGrdMaB68LwLo8/0IaAa
1QeDXcrNrw2js0Ht1G9QvjVS2wgu764OVbc6lE112KEN1ao27NJyar2WUytajp/OUqzl+MEr1dZy
Bmfq4rS0nMF56uJs0nKdeqo7Em9P3x9MT61TsoGrZDt0650C93L7tr4yB+oPGbaXDxC3lyuB+6a2
CjZkHxltFZC2ohznRvKR0VYBaStKcm7kHhltFZC2oiznRuoRv6ukU1et1VZ/iCwxrZiMtpKOtpKb
00gnE8oepXRDLnGesq5fo1PQgyfaZW08O1PqN+U0Xg72HZ27XGUo/yDq+KwXHWqjmBB1ahSfOMFH
sLIl5qRhwj+/jEr7rSaRWL8lC5fKdcbUdQbrnjhaVuY5F95Y0Bn6+yi5RWpZRauO9hv8jkKu/gNm
ywJCVcThO61Sk6gq6REc7HGWwA7712WwAAQRwQVVFrq2PnkMyqj9GFFMQ+E+WkAdnUdJdg3yj88S
gV4Ol3R6bXgpK3x2D5sG/QtszbMlDls2T6Ir83Iw/cYiegKVn++5FZfB+4iqzXG0iuh9RButxZLy
SbFh+Lvn7BRoIA/YQtnCMPDCOT2M1IyJd8bXWsapG6nlL2t9CMNqJpRsDTKJuQ9Gb/E2dru2Ws/X
NlVVt6Tu39JOPl9jbwYfOrDoeL0a7bxgAsxKpT12ODfL2eM3pDVUn375xTjUL3MwKk+/8wLL5c+O
qtOvusBye07aso/rzaNrHWvTThqKti9jUlvtzYuBT2t4w6Qb+NMazua8o5fzNb2cr+nl/Kf6yLCj
m927FXezwmzKup+q7qfjvsi6o6ruqOO7yLqnqu5p7bjQFrzOxsMaxJl+lqzLDOkX24E/92PhoSvx
IzscW+zSOrO0ziptNUqahVmXsdnAkFrHkFrDkLoLQ6pmqOGr7xzA4E6NmNSmzOpPnRlMu2Ux1Ubz
z5vJ1HuIdCSk8ztlI1FU9u75SI/1WTO/RUqfc/tf6py70epdT9eDB2n16zu2Sjr53g03Du+/Gegc
ur8yue69IfxcqVyfZ0+I9U0yV+AEKtn1rl+iC44uPS6lD+3U42ZK0N0SutZMfbfT0Mh++DJTf99Q
59oskc8Q7fztEc+efSa4kerVW8nz6lRF3Ule3ah1hpeLeue0rk7ia3K6unH/gAldtPyyd8Gth+4M
bTUDeivGGF9kxg/nNN5l3Z9HYYDb6uarZzQl80z/StSSiQ72bJv0mrfoKs+KoLh9Jq6Cd1ErlqaV
wBN6j8yTevdNDpZru/dckuiJvUN1AqriOivelR7tpK8jPqu8WiZVnCctChyxKKtgHidxdes5BKMy
j8I4SJJbwqGhoeCpJrB318Q00nf2BSmckmC6Jp2XqKC+m3TgqL0Ve3jfpCgn1229StyQFKXukBT1
EFlPv0EnPlDa00a9uGPe0zbV2PHewk0yo3aQGflwMvMlE+k+R6bcl3Kh1qTKtd2oHWVmmyf1p06W
Mz8Ugq8yWETHt8lrmyh3w+lkWZ3rZkoU55bBqrgoKRdttwQ0ra1/OHz9+vuzN/xjIuLFDDen1aCM
P0TZeePnR3TMv66QqfGLtyH+lsn4Rbq8QtW+4J9WoR84WUGXq+iNX0TRFczPswz1D1ygNOqy4UAc
vwJ6Lw/fHELzpoL9sZghvk6G8E1Rs4bzMKbzWw25nCFveVYerMLUDLvZCTv7v/aOrreNG/ach/2H
Qx8M+3xOo3NSJHNtwEnRYRgyxMn6tIfgfM7cAalrOCnQJMh/n/gh6uM+nbRbMLQo4ItE6iSK1IkU
RSLa+cj76ElYzkS871r58umenyM/j/XTYFKICEnEYBD6owTq4zWhO7Ejn+oRCKSEgwF4E0B/O+c/
SU1BTotfVrAm6A0JZLbBiLCj/4kz3fN96ZrD0nEAJde9zR5R61U7cRmn//EaCpNUvCSf7c4Wtbm1
+8PnrdrnrcblbTunMBBWWjFJisHzIfLCeJX5rsrCNYWdun8wnSIHuV404bG0G3Sr5FTaDbpVcijt
Bt2qDVqEjILBtNeJLvF5WlbOEhP2kTFhc39pzeLe0TrFfaG1qewkfKfeANfsr9VscgPbf+U5zb/i
UxbY2ISmsLlqcRvn21rYzEvtPZw2hjXbZ8Fn+4rHrJnHA8ShmccKxJZZNUeUn/ZUHfZUnPW0Pepp
x/vgw6xXd8AqEQMl7g+FW+j/zZGK5sziS0745LPiXMXWvKCjlajhHIVLBhPUIsZ4+CJl0o+x16Ww
Xtl6VVaf2vrUq1+qMe48L/Ps5vYt6QvxJOJ9sAVLK8BSDwxUJhEj6W/s8mMILhIm3a8FF+GT0YTg
oQZWojEdfz+NKQpuBDkbb6skYgID2sRGnC8ynpNSop+bNZhG/YVegRqUzYTACkyCGkmSG9UAniC3
AeswCfyeJ/PBBG7G4Mid3U7SoZtNHbzUhMSJOtHvH05PLk+nF78lhixIkZFVskHBoKVZd4oXZxY7
k9DSoP4dI7LD+mXy2IRVLqhNWGUSXIO1hO9zjfjUI6eVyDznj45BAcjGDB0ws3tT7kWws8OoqgWn
eghpHYIELfaZGwkQMLey3K3K2DtPLUCKAD8Y/cUxuiTUPcPIkw+W99a0nXgclS7vBP4EmYB0Qo1X
Mx+eaxJraeOqtaHhEB1o53veNFPON71pXgKzGT21kWiagZgihiIClpR+2YCweu6tCaN4+XZsXu6a
s1wwyIViYaxlyzOqgf5O1jhIB21Sl5AZy8Tb9w17rs3Pt8+BrgYj0tV0G5V1eDKUBeDr9dgA/zk0
zpAmH6sCdVvxzIBW4OoMK1EZMGoe7NVu1FtWn0CTQl1MYgr0RhHfTygPW48x9ky4eoMzEKUC3tOU
GtfmjF1ckXOZwnBw0HAsk2OgIGvveLBe91E5WdHVW6r6/OX2He53qaUBgI7Ix6Vr6igzp1hsvAt+
NC3GXbvlP7JgYsr2fL2WNeP4zC4tM/eQRjQzU5n6lcqrHPqVqVvJMQ1MqH0Vz1R/NoxnnM2lMgaC
YhMt55+Fzpn7/zs7M/XaUdsZBLpIEfnd0qGPOHztuAJFkdm3i72WN+ZipuWdt/WWJYzBWHcpPvfR
TOG+i2sKD4sNDHVxGjYAhW/CBqDQOMW6LaSTPU0yGDRYmH4emKegTRfsQMAOwre4YEcCdkRgP5lD
kUDnQd+uG0OIQMPhSlVSmZpK8xH2tUFYslgYRvyRHONigXJCa8Us7U1OLy9m53+oy7T3QN0Lv8Ya
0XyPzWTjT1+vlLE7hw2IihCVg7jfCjElxNRBPGxEJI3YUGDA41UxNSHbwb+6TW1MYCVhAvb7Ziaj
7SnlMOt2lHIYejtKWaZ/AqmGRKrhtqQSOj069pgtadWtlMve9vTrVkpvq8Z8mnYrZbyxsXIyp0Tm
9OlkFm9pVCPkvMvRJzRoS33iu+7Wd9qoMSs207VRXlZsuGujsqw8sxpvDJAwkegMmIbUfNk378Fc
bPfXtrTLSqRRdNHIybvr489faW9tXtH12utFHdeYNArR3QPuNi1cFFrw9YE2bej/hVYcJaFNEwg+
cgi7ZxnTze4qvZtOj49hb0+aEuyqTPybLJvP9WonRgRHj5jXKBDQhLtp+ko57SGBKshZhAB6Aw88
Fkdzow30oj4xtbj7RXGAoBjh+h6C8QaVqd8ayzB14c50IcDZb+xBiHFQ14U3NV24r6LC4bZUOKrr
gtor7QNOJe5vCJC3OwOenJHAqAJMvwCT+jDoDHAXwAwLMP0CzL4Pg74D9wHMQQGmb2Ho/j1z7uJk
c5XdXgmPdrUEZ/nVr++iG/g1TL0xD5p8hrGnRknfwNlW1OnoSjzlEmH0ZRnkcqBkCV9AB6gi54U5
353fQf5FOOsCY4IrLOK4upuzFGuwTsnqJnBACQ8GZNarvcS7mDYpcL67QEVFCsIBREwu2/VuJxc7
Dok7rwg+cEgLSyMkcy8isk8XCy5JltvZvhlcLNug8pgSPS0Qt8ld3pbud5dWNhwTN31xdXuWbbJP
enxYrtlhmXhmCeEHjB4lPPHB8MQS+GFZYu3xyJC8yjbLL58gSwpcW82i3NgjXvHwLZPRsAyn4Wst
tz2HTNZJSGiFrdeT6JcaEsU+jeKtieRxXZFIAY22G3ssI889DynuJZUjt+jR/wNQSwMEFAACAAgA
plRHLdIUtymqAAAARAEAAAsAAABkQ3lsaW5kZXIuaH3QQQqDMBAF0H0gdxhwU6XgAVxakO5KPUAJ
zqiBGEsSS9rTNylEK4WuMnzmP8JwlsleI/WA9VPJMJnbyFkWEqlpH3JmnVk6B+hTXHFG3pHRILXb
tmslrK1igzP0Dc0TFFgbEo7SChywvYuOziew8T0CXkkoMGlQrzwIj1kiYBRSsSV3EUZMNggxD8Cw
lgXKxa4C6cGN+ecfv07zxyn2ULFJGWmUPZTl12XeUEsDBBQAAgAIANCZSS0CaZK6BQIAANkEAAAK
AAAAcmVhZG1lLnR4dK1Ty27bMBC8C9A/LHJKAjsNcmt7i1IERpHasNNDetuQK4kNRQok5dh/3yX1
iAoE7iEVJAjax8yuZlgctTKSHAiN3oMyQneSPAirtfLKGp9nxVizhFt7gPFzOcVnBbu2JkeARr7V
bTQqk2crQO3tSCHnXfDo1PKBfM1ZaI6wJxe5wZYxg6bSlGdpJK6/yrPZTKhVZRgNtTUV4EF5xnuC
15oMCEcYSF7B+Q8bQKsXggLbluSs/7VWon4f5ddFolqZQK5EQcDR350PEGoCjw2v6WFAfNumRp/a
fnqCsjMixJ840NS4J7CG4Kw441V9IJRxSWm7Z52iqTXYYfQveSbvyTarO5BFikw053LX8kyc8fG9
ALkl1OBQqs6PX5pMFeqLrwOopwAtOmw8A++tkpDQR8wdhU3KMvjAKobUIs/g5PUv9sRfnea//zD/
5d8DXM4n2FLonIkG64uSR/uCJGgajFhqHxWJkUrto4mGEXovSDJBlUpglBVM1zyzFkN9OkK8GWs1
9BQxEvtgxRqDYRcO9geczMG9GKI28fiRCwohkPHWQcnPjB7W7JwGj9CxtYg9GhSbdX33beYz+cCM
LGTvysktDDRm+AhHrMfeDnRAEd7jSyRjz2b6N7F1Sw2lvcXpQxhr+f70/y5G+85bBmQRDOy0agWf
8xcb3bEWwcahPi/g5vr65g9QSwECFAAUAAIACABsZEktbqHp1zAfAAALjgAADQAAAAAAAAAAACAA
AAAAAAAAZEN5bGluZGVyLmNwcFBLAQIUABQAAgAIAKZURy3SFLcpqgAAAEQBAAALAAAAAAAAAAAA
IAAAAFsfAABkQ3lsaW5kZXIuaFBLAQIUABQAAgAIANCZSS0CaZK6BQIAANkEAAAKAAAAAAAAAAAA
IAAAAC4gAAByZWFkbWUudHh0UEsFBgAAAAADAAMArAAAAFsiAAAAAA==
------------FF1101193C4A0652--
From coding at natew.com Wed Oct 9 11:36:02 2002
From: coding at natew.com (Nate W)
Date: Wed Oct 9 11:36:02 2002
Subject: Re[2]: [ODE] CCylinder
In-Reply-To: <1911113781.20021009102331@gsc-game.kiev.ua>
Message-ID:
On Wed, 9 Oct 2002, slipch wrote:
> NW> I don't know off the top of my head, but have a look at the test_buggy
> NW> sample app. It creates capped cylinders for the wheel's collision hulls,
> NW> it should be evident from the source code what axis they're on to begin
> NW> with.
>
> In my version of test_buggy spheres used for wheels.
Oh look, mine too. Sorry about that. :-)
--
Nate Waddoups
Redmond WA USA
http://www.natew.com
From coding at natew.com Wed Oct 9 11:59:02 2002
From: coding at natew.com (Nate W)
Date: Wed Oct 9 11:59:02 2002
Subject: Re[2]: [ODE] always diabled body
In-Reply-To: <1428374912.20021009122432@gsc-game.kiev.ua>
Message-ID:
On Wed, 9 Oct 2002, slipch wrote:
> I want to hook enabled body to some point and drag it during
> simulation simply setting the point position.
I am doing something like that in my application. I create a
"fixed" joint, and use it to attach the body to "the static
environment" (as Russ puts it in the documentation).
// code
m_TackJoint = dJointCreateFixed (m_pWorld->m_WorldID, 0);
if (m_TackJoint)
{
dJointAttach (m_TackJoint, m_BodyID, null);
dJointSetFixed (m_TackJoint);
}
As for moving things around, I'm not sure but I think you could try
dBodySetPosition followed by another call to dJointSetFixed... moving
things around in that way seems to me like it would destabilize the
simulation, but it's worth a try.
Or, don't create that "disabled" body at all... think about whatever other
body it will be connected to, and connect THAT body with a fixed joint,
and move that body around. That might be a little bit simpler.
--
Nate Waddoups
Redmond WA USA
http://www.natew.com
From coding at natew.com Wed Oct 9 12:03:02 2002
From: coding at natew.com (Nate W)
Date: Wed Oct 9 12:03:02 2002
Subject: Re[2]: [ODE] always diabled body
In-Reply-To: <010401c26f9e$24e99940$0e00000a@pierre>
Message-ID:
On Wed, 9 Oct 2002, Pierre Terdiman wrote:
> > No. But i dont see the point in creating a fixed body anyway. Just DONT
> > use a body if you dont want dynamics.
>
> That's a common thing nonetheless, say for planes. A ground plane is fixed,
> yet you want your bodies to collide with it.
>
> Or for a flag, when the cloth patch is attached to a fixed base.
Even for both of those scenarios, you could get away without creating a
rigid body. The ground plane in my application is a Geom object, not a
body; if I wanted a flag, I'd render the pole, but I wouldn't make a body
of it (unless I wanted the pole to sway....) instead, the edge of the
cloth would just be "attached" to a set of fixed coordinates (as described
in 11.1 of the FAQ).
--
Nate Waddoups
Redmond WA USA
http://www.natew.com
From dmcclurg at pandemicstudios.com.au Wed Oct 9 17:29:02 2002
From: dmcclurg at pandemicstudios.com.au (David McClurg)
Date: Wed Oct 9 17:29:02 2002
Subject: [ODE] welcome a new player
Message-ID:
Thanks for the link. It's nice to see the proliferation of rigid body simulators but I thought Si Brown's Freefall buggy demo using ODE was nicer than the NovodexTruckDemo. There seem to be some problems with the novodex wheels. When they hit the walls and objects they turn at a different angle than the inputs which makes it unresponsive very difficult to control. And the frame rate was pretty low (<30) for a small world on a GeForce3 1.6Ghz machine.
Pierre Terdiman wrote:
> PS: let's welcome a new player after Mathengine, Havok, ODE, etc :
> www.novodex.com
From p.terdiman at wanadoo.fr Wed Oct 9 18:13:02 2002
From: p.terdiman at wanadoo.fr (Pierre Terdiman)
Date: Wed Oct 9 18:13:02 2002
Subject: [ODE] welcome a new player
References:
Message-ID: <021b01c26ff9$e5d0c740$0e00000a@pierre>
> Thanks for the link. It's nice to see the proliferation of rigid body
simulators but I thought Si Brown's Freefall buggy demo using ODE was nicer
than the NovodexTruckDemo. There seem to be some problems with the novodex
wheels. When they hit the walls and objects they turn at a different angle
than the inputs which makes it unresponsive very difficult to control. And
the frame rate was pretty low (<30) for a small world on a GeForce3 1.6Ghz
machine.
Maybe you should report those problems to them, then ? After all, it's
off-topic :)
Now, the low framerate probably comes from something else : I don't have a
1.6 Ghz machine (*) and the framerate was always ~85 FPS (that is, the limit
they fixed).
Pierre
(*) On the other hand I have a Quadro4 XGL 900, arh arh arh !
From dmcclurg at pandemicstudios.com.au Wed Oct 9 19:16:01 2002
From: dmcclurg at pandemicstudios.com.au (David McClurg)
Date: Wed Oct 9 19:16:01 2002
Subject: [ODE] conveyor belts and moving platforms
Message-ID:
In my game, I'd like to simulate conveyor belts. Looking at the doc, a contact joint using dContactMotion1/2 seems to be the technqiue required. Does anyone have an example of that? I looked in ode/test but couldn't find anything.
Also, if i want to simulate moving platforms (boxes with bodies) that the player can jump on, should friction keep the player on the platform or will I need a special contact joint?
If my player is a ccylinder or sphere, and I don't want my player to rotate as it moves in the world via SetVel, how do I constrain the body to not rotate?
Much thanks for any help with these questions
From slipch Thu Oct 10 00:32:01 2002
From: slipch (slipch)
Date: Thu Oct 10 00:32:01 2002
Subject: Re[4]: [ODE] always diabled body
In-Reply-To:
References:
Message-ID: <1791950044.20021010103433@gsc-game.kiev.ua>
Hello Nate,
Wednesday, October 9, 2002, 2:06:58 PM, you wrote:
NW> On Wed, 9 Oct 2002, slipch wrote:
>> I want to hook enabled body to some point and drag it during
>> simulation simply setting the point position.
NW> I am doing something like that in my application. I create a
NW> "fixed" joint, and use it to attach the body to "the static
NW> environment" (as Russ puts it in the documentation).
There was a good idea by Benny Kramek:
"
You can give your body a very large mass and disable gravity on it. Then
it will move very little on it's own, and you can move it around with
dBodySetPos()
"
Works fine.
--
Best regards,
slipch mailto:slipch@gsc-game.kiev.ua
From mattias at cambrianlabs.com Thu Oct 10 01:30:02 2002
From: mattias at cambrianlabs.com (Mattias Fagerlund)
Date: Thu Oct 10 01:30:02 2002
Subject: [ODE] Cylinder colisions
In-Reply-To: <17333538595.20021009192355@gsc-game.kiev.ua>
References: <17333538595.20021009192355@gsc-game.kiev.ua>
Message-ID:
> Hear is cylinder class for ODE.
Hey! Nice job, I tried it out and it seems to work the way it should.
I've seen cylinders explode out into space, but only rarely.
If anyone wants a windows demo using the cylinder, check out
http://www.cambrianlabs.com/DelphiODE.zip - the boxstack demo.
cheers,
mattias
From mattias at cambrianlabs.com Thu Oct 10 01:33:11 2002
From: mattias at cambrianlabs.com (Mattias Fagerlund)
Date: Thu Oct 10 01:33:11 2002
Subject: [ODE] Community page
Message-ID:
Hey!
Russel, if you'd like, please add
http://www.cambrianlabs.com/Mattias/DelphiODE/ to the community page?
It's the homepage of the delphi import of ODE.
If anyone wants to see some more evolved life, check out
http://www.cambrianlabs.com/Mattias/Evolved/ , where I use Genetic
Programming to evolve a hopper. Russel, if you want to, you could add
that also.
cheers,
mattias
From slipch Thu Oct 10 02:08:02 2002
From: slipch (slipch)
Date: Thu Oct 10 02:08:02 2002
Subject: Re[2]: [ODE] Cylinder colisions
In-Reply-To:
References: <17333538595.20021009192355@gsc-game.kiev.ua>
Message-ID: <757664571.20021010120947@gsc-game.kiev.ua>
Hello Mattias,
Thursday, October 10, 2002, 11:25:42 AM, you wrote:
>> Hear is cylinder class for ODE.
MF> Hey! Nice job, I tried it out and it seems to work the way it should.
MF> I've seen cylinders explode out into space, but only rarely.
They must not "explode out". One reason it may happen is well known
problem with integration of fast rotating body. Cylinders (as well as
Capped Cylinders) must show this problem more often than other bodies
especially when radius/length ratio is small. It happen because
rotating around an axis with small inertia partly counts as rotating
around an axis with large inertia. But it is not a problem of
colliders.
To resolve it finite rotation axes may be used or simply
do not set inertia tensor with strongly different inertia of its axes.
It is also should depend on integration step.
--
Best regards,
slipch mailto:slipch@gsc-game.kiev.ua
From I.Munro at herts.ac.uk Thu Oct 10 02:32:02 2002
From: I.Munro at herts.ac.uk (Ian Munro)
Date: Thu Oct 10 02:32:02 2002
Subject: [ODE] Community page
Message-ID:
Mattias wrote:
> If anyone wants to see some more evolved life, check out
> http://www.cambrianlabs.com/Mattias/Evolved/ , where I use Genetic
> Programming to evolve a hopper. Russel, if you want to, you could add
> that also.
Pretty interesting stuff.
I'm doing similar things with a two legged runner and using Mathew Wall's
GALIB.
Sorry, I haven't got any details online at the moment, but have a look at
http://www.bunnyburgers.com/tigger.jpg for a picture of the beast in
action.
I'd previously used the sort of control systems described by Railbert, but
am now trying a sort of limit cycle based approach, where just once per a
hop I measure the creatures attitude in space, apply (genetic algorithm
generated) weights to all these values, sum them together and the use the
resulting number to set the leg velocity for flight. For stance I use the
same process but a different set of weights.
My reasoning was that the railbert approach might be producing a control
system that was fighting against the natural dynamics, whilst a
non-prescriptive approach might work in harmony with the dynamics. The
down-side is that the system is so non-prescriptive that a lot of time is
wasted simulating completely unfeasible control weightings.
The creature evolves to hops ok if I use both legs in sync, but I've only
just started on the bipedal running strategies, so it's a bit hit and miss
at the moment.
Cheers
Ian
From mattias at cambrianlabs.com Thu Oct 10 02:50:01 2002
From: mattias at cambrianlabs.com (Mattias Fagerlund)
Date: Thu Oct 10 02:50:01 2002
Subject: [ODE] Community page
In-Reply-To:
References:
Message-ID:
> Pretty interesting stuff.
> I'm doing similar things with a two legged runner and using Mathew
> Wall's GALIB.
My current implementation evolve NNs unsing the NEAT method. Nothing
online yet, though.
My next goal is to evolve a snake like object (four bodies connected by
three hinges) and then something two legged. I'm trying to use Juice to
design the body - great tool Nate!
> Sorry, I haven't got any details online at the moment, but have a look
> at http://www.bunnyburgers.com/tigger.jpg for a picture of the beast
> in action.
That looks incredibly cool! I'd love to see him in action. Let us know
when you have something to look at!
> I'd previously used the sort of control systems described by Railbert,
Railbert? Never heard of him, nor could I find any online papers - any
links you could send?
> My reasoning was that the railbert approach might be producing a
> control
> system that was fighting against the natural dynamics, whilst a
> non-prescriptive approach might work in harmony with the dynamics. The
> down-side is that the system is so non-prescriptive that a lot of time
> is wasted simulating completely unfeasible control weightings.
That's evolution for you. I try very hard to kill the bad systems off as
fast as I can.
> The creature evolves to hops ok if I use both legs in sync, but I've
> only just started on the bipedal running strategies, so it's a bit
> hit and miss at the moment.
Well, if you want to toss ideas around, I'm game!
cheers,
m
From I.Munro at herts.ac.uk Thu Oct 10 04:02:02 2002
From: I.Munro at herts.ac.uk (Ian Munro)
Date: Thu Oct 10 04:02:02 2002
Subject: [ODE] Community page
Message-ID:
Mattias Wrote:
>
> My current implementation evolve NNs unsing the NEAT method. Nothing
> online yet, though.
I've thought about NNs but i'm not really upto speed on them. I should
really investigate the area more.
>
> That looks incredibly cool! I'd love to see him in action.
> Let us know
> when you have something to look at!
Sure. Of course you can't see from a still frame the crash that followed 1
second later ;-)
> > I'd previously used the sort of control systems described
> by Railbert,
>
> Railbert? Never heard of him, nor could I find any online
> papers - any
> links you could send?
Marc Raibert (sorry, mispelt his name) wrote a book called "legged robots
that balance" and was responsible for the major work at the MIT leg lab.
http://www.ai.mit.edu/projects/leglab/
(lots of interesting stuff at the site)
His main contribution was demonstrating that dynamically unstable robots
could be controlled with fairly simple control alogorithms rather than a
complete mathematical analysis of the robots dynamics.
Previous simulations I've done have been using working model 2d, inspired by
the work of John Nagle
http://www.animats.com/papers/leggedrun/leggedrun.html
But working model 2d was incredibly slow to simulate and communicate with.
ODE has been a real eye opener as to how fast simulations can run. It's made
life a lot easier.
My interests actually lie in making physical robots rather than simulations,
but they're a great "what if?" tool.
Cheers
Ian
From p.terdiman at wanadoo.fr Thu Oct 10 04:14:02 2002
From: p.terdiman at wanadoo.fr (Pierre Terdiman)
Date: Thu Oct 10 04:14:02 2002
Subject: [ODE] Community page
References:
Message-ID: <005f01c2704d$c6915080$0e00000a@pierre>
> My next goal is to evolve a snake like object (four bodies connected by
> three hinges) and then something two legged. I'm trying to use Juice to
> design the body - great tool Nate!
Note that NovodeX provides 2 exporters for MilkShape and MAX (others are
planned) that you probably could use for ODE as well.
For example, 4 bodies connected by 3 hinges are a piece of cake to build &
export from MAX. [I can help here if needed, I wrote the exporter].
Note that this KAT tool I still have to play with looks fine as well.
Pierre
From mattias at cambrianlabs.com Thu Oct 10 04:30:02 2002
From: mattias at cambrianlabs.com (Mattias Fagerlund)
Date: Thu Oct 10 04:30:02 2002
Subject: [ODE] Community page
In-Reply-To: <005f01c2704d$c6915080$0e00000a@pierre>
References: <005f01c2704d$c6915080$0e00000a@pierre>
Message-ID:
> > My next goal is to evolve a snake like object (four bodies connected
> by
> > three hinges) and then something two legged. I'm trying to use Juice
> to
> > design the body - great tool Nate!
>
> Note that NovodeX provides 2 exporters for MilkShape and MAX (others
> are planned) that you probably could use for ODE as well.
I couldn't find the exporters att novodex (is that novODEx?) ;)
> For example, 4 bodies connected by 3 hinges are a piece of cake to
> build & export from MAX. [I can help here if needed, I wrote
> the exporter].
Well, MAX isn't exactly cheap, though milkshape is (and I actually have a
license). Any pointers to the exporters?
> Note that this KAT tool I still have to play with looks fine as well.
I'd love to play with it also, but I'm guessing I'd have to buy the game
to download it?
cheers,
mattias
From p.terdiman at wanadoo.fr Thu Oct 10 04:40:02 2002
From: p.terdiman at wanadoo.fr (Pierre Terdiman)
Date: Thu Oct 10 04:40:02 2002
Subject: [ODE] Community page
References: <005f01c2704d$c6915080$0e00000a@pierre>
Message-ID: <00bb01c27051$7f8241a0$0e00000a@pierre>
> Well, MAX isn't exactly cheap, though milkshape is (and I actually have a
> license). Any pointers to the exporters?
Download them freely here:
http://www.novodex.com/sales.html
> I'd love to play with it also, but I'm guessing I'd have to buy the game
> to download it?
No.
http://www.swissquake.ch/chumbalum-soft/files/KAT_1_2_UT2003_Setup.exe
Pierre
From slipch Thu Oct 10 04:59:02 2002
From: slipch (slipch)
Date: Thu Oct 10 04:59:02 2002
Subject: Re[2]: [ODE] Cylinder colisions
In-Reply-To: <757664571.20021010120947@gsc-game.kiev.ua>
References: <17333538595.20021009192355@gsc-game.kiev.ua>
<757664571.20021010120947@gsc-game.kiev.ua>
Message-ID: <16117962618.20021010150125@gsc-game.kiev.ua>
Hello Mattias,
Thursday, October 10, 2002, 11:25:42 AM, you wrote:
It seems my message has not get through. At least I do not see it back in
my Inbox.
I send it again.
MF> Hey! Nice job, I tried it out and it seems to work the way it should.
MF> I've seen cylinders explode out into space, but only rarely.
They must not "explode out". One reason it may happen is well known
problem with integration of fast rotating body. Cylinders (as well as
Capped Cylinders) must show this problem more often than other bodies
especially when radius/length ratio is small. It happen because
rotating around an axis with small inertia partly counts as rotating
around an axis with large inertia. But it is not a problem of
colliders.
To resolve it finite rotation axes may be used or simply
do not set inertia tensor with strongly different inertia of its axes.
It is also should depend on integration step.
--
Best regards,
slipch mailto:slipch@gsc-game.kiev.ua
From mattias at cambrianlabs.com Thu Oct 10 05:13:02 2002
From: mattias at cambrianlabs.com (Mattias Fagerlund)
Date: Thu Oct 10 05:13:02 2002
Subject: Re[2]: [ODE] Cylinder colisions
In-Reply-To: <16117962618.20021010150125@gsc-game.kiev.ua>
References: <17333538595.20021009192355@gsc-game.kiev.ua> <757664571.20021010120947@gsc-game.kiev.ua> <16117962618.20021010150125@gsc-game.kiev.ua>
Message-ID:
> Hello Mattias,
Hey slipch, it came through fine both times - I haven't replied yet,
though.
> They must not "explode out". One reason it may happen is well known
> problem with integration of fast rotating body. Cylinders (as well as
> Capped Cylinders) must show this problem more often than other bodies
> especially when radius/length ratio is small.
Well, dropping many cylinders in the boxstack demo, every once in a while
one will explode. I'm not sure why, but you may be correct.
cheers,
m
From p.terdiman at wanadoo.fr Thu Oct 10 05:19:02 2002
From: p.terdiman at wanadoo.fr (Pierre Terdiman)
Date: Thu Oct 10 05:19:02 2002
Subject: Re[2]: [ODE] Cylinder colisions
References: <17333538595.20021009192355@gsc-game.kiev.ua><757664571.20021010120947@gsc-game.kiev.ua> <16117962618.20021010150125@gsc-game.kiev.ua>
Message-ID: <00f801c27056$f27be760$0e00000a@pierre>
Are your cylinders real cylinders or capsules ? I assume they're "real"
cylinders since you make a difference between them and "capped cylinders".
Then you might want to tell Eric Haines about it, for his intersection page.
Actually providing a free ODE-independent set of cylinder overlap routines
would be very very handy for a lot of people.
> They must not "explode out". One reason it may happen is well known
> problem with integration of fast rotating body. Cylinders (as well as
> Capped Cylinders) must show this problem more often than other bodies
> especially when radius/length ratio is small. It happen because
> rotating around an axis with small inertia partly counts as rotating
> around an axis with large inertia. But it is not a problem of
> colliders.
> To resolve it finite rotation axes may be used or simply
> do not set inertia tensor with strongly different inertia of its axes.
I think it can be solved by :
- using a better integration scheme (RK4 at least)
- clamping angular velocity to a max speed
Unless I'm missing something.... I wouldn't tweak the inertia tensor, that's
a delicate beast.
Seems to work here: www.codercorner.com/Physics.zip
(Press 6 to create some bars, then w to make them spin quickly. I can't make
it explode here.)(and I hope we're talking about the same problem ;)
Pierre
From martin at metahuman.org Thu Oct 10 05:27:01 2002
From: martin at metahuman.org (Martin C. Martin)
Date: Thu Oct 10 05:27:01 2002
Subject: [ODE] Community page
References:
Message-ID: <3DA571D5.329A60E7@metahuman.org>
Ian Munro wrote:
>
> Mattias Wrote:
>
> Marc Raibert (sorry, mispelt his name) wrote a book called "legged robots
> that balance" and was responsible for the major work at the MIT leg lab.
>
> http://www.ai.mit.edu/projects/leglab/
> (lots of interesting stuff at the site)
You might also be interested in:
http://www-2.cs.cmu.edu/~garthz/research/bowleg/bowleg.html
And in particular, the paper "Control of a Bow Leg Hopping Robot." It
works similarly to your description, calculating control parameters only
once during flight. Stance, on the other hand, is completely passive.
- Martin
From mattias at cambrianlabs.com Thu Oct 10 06:04:02 2002
From: mattias at cambrianlabs.com (Mattias Fagerlund)
Date: Thu Oct 10 06:04:02 2002
Subject: Re[2]: [ODE] Cylinder colisions
In-Reply-To: <00f801c27056$f27be760$0e00000a@pierre>
References: <17333538595.20021009192355@gsc-game.kiev.ua><757664571.20021010120947@gsc-game.kiev.ua> <16117962618.20021010150125@gsc-game.kiev.ua> <00f801c27056$f27be760$0e00000a@pierre>
Message-ID:
Since slipch himself hasn't answered (yet), I'll throw in an answer;
> Are your cylinders real cylinders or capsules ? I assume they're "real"
> cylinders since you make a difference between them and "capped
> cylinders".
slipch created real cylinders for ODE, I refer you to the archive;
http://q12.org/pipermail/ode/2002-October/001936.html . If you want the
download (it's in mime format in the pipemail archive), I'm sure he'll
send it to you; slipch@gsc-game.kiev.ua
cheers,
mattias
From Dominique at SavageSoftware.com.au Thu Oct 10 06:20:02 2002
From: Dominique at SavageSoftware.com.au (Dominique Louis)
Date: Thu Oct 10 06:20:02 2002
Subject: [ODE] Silly Question...
Message-ID: <3DA57EF7.1070807@SavageSoftware.com.au>
Hi all,
I have compiled configurator.c manually and would like to know what
parameters it requires in order to create the config.h file.
I have tried...
configurator config\user-settings bcc32 tools\rm.exe
on the command line, but it fails to delete the ctest.c file and does
not seem to generate correct output.
Am I missing something here?
Thanks,
Dominique.
From benny at kramekweb.com Thu Oct 10 06:46:02 2002
From: benny at kramekweb.com (Benny Kramek)
Date: Thu Oct 10 06:46:02 2002
Subject: [ODE] conveyor belts and moving platforms
References:
Message-ID: <3DA58E8C.10401@kramekweb.com>
David McClurg wrote:
> In my game, I'd like to simulate conveyor belts. Looking at the doc, a contact joint using dContactMotion1/2 seems to be the technqiue required. Does anyone have an example of that? I looked in ode/test but couldn't find anything.
It's fairly simple. First make sure that you correctly set the fdir1
vector in the dContact structure. Then make sure that you use the
dContactFDir1 and dContactMotion1 flags on the surface mode. Then set
the correct value for motion1.
> Also, if i want to simulate moving platforms (boxes with bodies) that the player can jump on, should friction keep the player on the platform or will I need a special contact joint?
Friction will keep the players on the platform with no problem. Just
make sure that there is enough friction.
> If my player is a ccylinder or sphere, and I don't want my player to rotate as it moves in the world via SetVel, how do I constrain the body to not rotate?
One way is to put very large values in the inertia matrix. This will
make the body difficult to rotate. Another, maybe better way, is give
your body an inertia of a sphere, and to always have the geom oriented
in a fixed orientation.
From slipch Thu Oct 10 06:49:02 2002
From: slipch (slipch)
Date: Thu Oct 10 06:49:02 2002
Subject: Re[4]: [ODE] Cylinder colisions
In-Reply-To: <00f801c27056$f27be760$0e00000a@pierre>
References: <17333538595.20021009192355@gsc-game.kiev.ua><757664571.20021010120947@gsc-game.kiev.ua>
<16117962618.20021010150125@gsc-game.kiev.ua>
<00f801c27056$f27be760$0e00000a@pierre>
Message-ID: <7724552614.20021010165115@gsc-game.kiev.ua>
Hello Pierre,
Thursday, October 10, 2002, 3:17:04 PM, you wrote:
PT> Are your cylinders real cylinders or capsules ? I assume they're "real"
PT> cylinders since you make a difference between them and "capped cylinders".
PT> Then you might want to tell Eric Haines about it, for his intersection page.
PT> Actually providing a free ODE-independent set of cylinder overlap routines
PT> would be very very handy for a lot of people.
Of course they are "real" cylinders. It is not need to create
colliders for capsules because they already exist in ODE. Functions that
implement collision for cylinders designed to set contact information
to create ODE contact joints. I am not sure that they would be useful in
another application.
PT> Seems to work here: www.codercorner.com/Physics.zip
PT> (Press 6 to create some bars, then w to make them spin quickly. I can't make
PT> it explode here.)(and I hope we're talking about the same problem ;)
I think yes we are talking about the same problem.
Errors may appear anyway due to numeric errors independently of
inertia tensor. But when inertia highly asymmetric they rather lead to
noticeable result. If angular velocity is not limited it may lead to
untwisting to infinite velocity.
Unfortunately I can not get the example right now by technical
reasons. I'll do it later and I belive I manage to make turning body to
explode in any case setting proper parameters and very large velocity.
--
Best regards,
slipch mailto:slipch@gsc-game.kiev.ua
From benny at kramekweb.com Thu Oct 10 06:58:01 2002
From: benny at kramekweb.com (Benny Kramek)
Date: Thu Oct 10 06:58:01 2002
Subject: [ODE] Cylinder colisions
References: <17333538595.20021009192355@gsc-game.kiev.ua><757664571.20021010120947@gsc-game.kiev.ua> <16117962618.20021010150125@gsc-game.kiev.ua> <00f801c27056$f27be760$0e00000a@pierre> <7724552614.20021010165115@gsc-game.kiev.ua>
Message-ID: <3DA59188.4080906@kramekweb.com>
> Of course they are "real" cylinders. It is not need to create
> colliders for capsules because they already exist in ODE. Functions that
> implement collision for cylinders designed to set contact information
> to create ODE contact joints. I am not sure that they would be useful in
> another application.
Why don't we add the "real" cylinder class directly into ode?
From mattias at cambrianlabs.com Thu Oct 10 10:10:02 2002
From: mattias at cambrianlabs.com (Mattias Fagerlund)
Date: Thu Oct 10 10:10:02 2002
Subject: [ODE] Community page
In-Reply-To:
References:
Message-ID:
> > My current implementation evolve NNs unsing the NEAT method. Nothing
> > online yet, though.
>
> I've thought about NNs but i'm not really upto speed on them. I should
> really investigate the area more.
NNs are tricky, if you want to do any kind of "fancy" (backpropagation)
learning. Evolving NNs is almost trivial. Picking the right network
topology is the the tricky part. The method I use, NEAT, evolves
topology AND network weights, that's harder to implement.
Now, if you want to _understand_ NNs, that's another thing completely...
cheers,
m
From Alan_Gordie at payformance.com Thu Oct 10 11:30:02 2002
From: Alan_Gordie at payformance.com (Alan Gordie)
Date: Thu Oct 10 11:30:02 2002
Subject: [ODE] coldet and ode
Message-ID:
I'm still catching up on two weeks of past list messages, but that is
awesome news! Thanks, Pierre!
-----Original Message-----
From: Pierre Terdiman [mailto:p.terdiman@wanadoo.fr]
Sent: Friday, October 04, 2002 5:21 PM
To: ode@q12.org
Subject: Re: [ODE] coldet and ode
> I'd personally give Opcode a shot if it was more portable. (There
> doesn't seem to be an ANSI C/C++ target in the source).
Well, various people ported it to Linux and made it "more portable". On top
of my head : in the F4 engine, in The Nebula Device, in Crystal Space, in
... ODE... Some more people sent me tar.gz files with makefiles and required
changes to build Opcode "elsewhere".
I don't know if they work well since I have a Windows box, period, but I can
upload such an archive if ... Hell, let's just do it, wait 5 mn.
...
Ok, done, uploaded Linux port : www.codercorner.com/Opcode.htm
Words from the author :
"This version is indeed different than those contained in F4 or ODE
because it is only a direct linux port of version 1.2 of OPCODE, it
contains nothing more, nothing less so a user does not have to deal with
F4 or ODE. It is also accompanied with a so called configure script
which automatically creates a makefile for the user's specific platform.
It's just a question of running the configure script and automake and
OPCODE is build for your platform (e.g. linux, solaris, irix etc). This
is the correct way on unix flavoured oss to spread software."
Questions about it ? Ask the author, please. (his mail is in the tar file)
> Opcode looks heavily biased towards Win32 (lots of x86 ASM VC++ stuff
> in the mix) whereas ColDet compiles on just about anything, without
> modification.
Note that there's a #define to discard the ASM, and the only relevant VC++
stuff, as far as Opcode is concerned, is "__forceinline".
Pierre
_______________________________________________
ODE mailing list
ODE@q12.org
http://q12.org/mailman/listinfo/ode
From kaffiene at xtra.co.nz Thu Oct 10 13:33:02 2002
From: kaffiene at xtra.co.nz (Peter)
Date: Thu Oct 10 13:33:02 2002
Subject: [ODE] RE: Wheel rotation problem
In-Reply-To: <108E7D907871D6118B5000306E0189F82005B9@ednex504.dsto.defence.gov.au>
Message-ID: <007101c2709c$243494b0$5c02a8c0@peter>
> -----Original Message-----
> From: ode-admin@q12.org [mailto:ode-admin@q12.org] On Behalf Of
McEvoy,
> Nick
> Sent: Friday, 13 September 2002 11:49 a.m.
> To: 'ode@q12.org'
> Subject: [ODE] RE: Wheel rotation problem
>
> Marco Grubert wrote:
> >My observations is that mass of the connected objects has a huge
impact
> on
> >stability. I started out with a 500kg chassis and 15kg wheels.
Reducing
> this
> >to 1/10th of the original value significantly improved the top speed
when
> >wheel bending occurs. It appears as though the object mass would
increase
> >with higher speed, pushing the wheels into a /\ shape when driving
> straight
> >or a // shape when doing a left turn.
>
> // Chassis
> CLength = 0.7f;
> CWidth = 0.5f;
> CHeight = 0.2f;
> CMass = 1.0f;
>
> // Wheels
> WRadius = 0.15f;
> WMass = 0.2f;
>
> Gravity=-5.0f; // yes a strange value but who said my game is on earth
:)
>
> I'll do some more parameter tweaking. :)
>
>
> >I have not yet tried moving the hinge2
> >anchor points around- does that make any difference?
>
> No I have not tried that idea yet.
>
>
> >I did not notice any difference when setting the finite rotation
mode.
> >However, the documentation suggests setting the axis every timestep
> (which
> >you don´t do in the sample code).
>
> I see that in the doco ... NOW ... missed it before ... so
> dBodySetFiniteRotationAxis() should be call each step !? I'll try
that
> then.
>
>
> >I don´t quite understand how this mode
> >operates or why the axis has to be reset. Why should it change during
> >iterations ?
>
> Yes good question (why call each time step) ... I don't understand it
> either
> ... I'm no physics guru. :-(
>
>
> >How are you adjusting the axes´ angles? I had this problem when only
> >querying one wheel, calculating the difference and then applying the
same
> >value to both joints. Calculating the rate of change independently
for
> each
> >of the two front joints fixed that problem.
>
> Ahhh your right on this one I think ... I was calculating each wheel
> (steering) independently. I'll fix it this weekend.
>
> // Motor
> for (i = 0; i <= 1; i++)
> {
> dJointSetHinge2Param(mODEJoint[i], dParamVel2, -speed);
> dJointSetHinge2Param(mODEJoint[i], dParamFMax2, 0.1);
> }
>
> // Steering - woops this is wrong ... I'll fix it as per your
suggestion
> !!!
> for (i = 0; i <= 1; i++)
> {
> dReal v = steer - dJointGetHinge2Angle1(mODEJoint[i]);
> if (v > 0.1) v = 0.1;
> if (v < -0.1) v = -0.1;
> v *= 10.0;
> dJointSetHinge2Param(mODEJoint[i], dParamVel, v);
> dJointSetHinge2Param(mODEJoint[i], dParamFMax, 0.2);
> dJointSetHinge2Param(mODEJoint[i], dParamLoStop, -0.75);
> dJointSetHinge2Param(mODEJoint[i], dParamHiStop, 0.75);
> dJointSetHinge2Param(mODEJoint[i], dParamFudgeFactor, 0.1);
> }
>
Nick, did any of these experiments work? (i.e. get rid of the
wheel-bending problem)?
Cheers,
Peter.
From coding at natew.com Thu Oct 10 14:07:02 2002
From: coding at natew.com (Nate W)
Date: Thu Oct 10 14:07:02 2002
Subject: [ODE] Community page
In-Reply-To:
Message-ID:
On Thu, 10 Oct 2002, Ian Munro wrote:
> My interests actually lie in making physical robots rather than simulations,
> but they're a great "what if?" tool.
Be careful... That's exactly how I felt when I started planning the
software that became Juice. Now I've lost all interest in making
something I can touch. :-)
I'm really enjoying the discussion of evolved behaviors. In Juice, a
creature's movements are basically just sine waves of different phases and
amplitudes applied to joints, and feedback loops from a body's orientation
to one or more joints. I've been pondering a training feature to try
using a GA to adjust the phases, amplitudes, and gains, but haven't
actually implemented anything yet. I'm hoping it will smooth out gaits
that have been designed by hand.
I've come to the conclusion that this method of programming behavior
creates creatures that tip over too easily though, so most of my time
lately has gone into designing a new behavior programming language.
--
Nate Waddoups
Redmond WA USA
http://www.natew.com
From mattias at cambrianlabs.com Thu Oct 10 14:34:02 2002
From: mattias at cambrianlabs.com (Mattias Fagerlund)
Date: Thu Oct 10 14:34:02 2002
Subject: [ODE] Community page
In-Reply-To:
References:
Message-ID:
> I'm really enjoying the discussion of evolved behaviors. In Juice, a
> creature's movements are basically just sine waves of different phases
> and
> amplitudes applied to joints, and feedback loops from a body's
> orientation
> to one or more joints.
Check out http://www.ventrella.com/GenePool/gene_pool.html, it's a 2d
program that evolves both structure and behaviour - but the behaviour is
basically offset, phase and amplitude.
LimbAngle = offset + sin(Time + Phase) * Amplitude;
Quite similar to what you're describing. Jeffrey's also written several
interesting papers about evolving articulated agents.
> I've been pondering a training feature to try
> using a GA to adjust the phases, amplitudes, and gains, but haven't
> actually implemented anything yet. I'm hoping it will smooth out gaits
> that have been designed by hand.
I'm guessing you could have a GA running in a matter of days. Contact me
off the list if you're interested in some ideas on that ;)
> I've come to the conclusion that this method of programming behavior
> creates creatures that tip over too easily though, so most of my time
> lately has gone into designing a new behavior programming language.
Your creatures are very complex, GAs could probably do a good job there.
cheers,
m
From anselm at hook.org Thu Oct 10 15:31:02 2002
From: anselm at hook.org (Anselm Hook)
Date: Thu Oct 10 15:31:02 2002
Subject: [ODE] Community page
In-Reply-To:
Message-ID:
> > I've come to the conclusion that this method of programming behavior
> > creates creatures that tip over too easily though, so most of my time
> > lately has gone into designing a new behavior programming language.
This sounds interesting - any links up yet? What kinds of features does
your language make it easier to express?
- a
From dmcclurg at pandemicstudios.com.au Thu Oct 10 17:30:02 2002
From: dmcclurg at pandemicstudios.com.au (David McClurg)
Date: Thu Oct 10 17:30:02 2002
Subject: [ODE] conveyor belts and moving platforms
Message-ID:
Benny Kramek wrote:
>> If my player is a ccylinder or sphere, and I don't want my player to rotate as it moves in the world via SetVel, how do I constrain the body to not rotate?
> One way is to put very large values in the inertia matrix. This will make the body difficult to rotate.
you mean like a large mass?
> Another, maybe better way, is give your body an inertia of a sphere,
how is that done?
> and to always have the geom oriented in a fixed orientation.
by setting the rotation every frame in the app? or is there another way to constrain orientation?
thanks for your help on conveyer/platform questions!
From russ at q12.org Thu Oct 10 22:39:01 2002
From: russ at q12.org (Russ Smith)
Date: Thu Oct 10 22:39:01 2002
Subject: [ODE] Cylinder colisions
In-Reply-To: <3DA59188.4080906@kramekweb.com>
References: <17333538595.20021009192355@gsc-game.kiev.ua>
<757664571.20021010120947@gsc-game.kiev.ua>
<16117962618.20021010150125@gsc-game.kiev.ua>
<00f801c27056$f27be760$0e00000a@pierre>
<7724552614.20021010165115@gsc-game.kiev.ua>
<3DA59188.4080906@kramekweb.com>
Message-ID: <20021010224329.65a1dbdd.russ@q12.org>
This is a multi-part message in MIME format.
--Multipart_Thu__10_Oct_2002_22:43:29_-0400_0839c960
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
> Why don't we add the "real" cylinder class directly into ode?
the non-capped cylinder code is a good chunk of work, but i think it's
work-in-progress. there are a few current problems, especially with
cylinder-cylinder contact. the attached image illustrates the problem -
it is possible (in fact rather easy) to put two cylinders into a
configuration where the contact point (the blue box) does not even
intersect one of the cylinders. this is IMO a big error.
having said that, this cylinder work is a great step in the right
direction. even with the errors it can be useful for many people. i'll
add it to the contrib directory for now. thanks konstantin!
to explain why i think this error is a problem:
the ODE scheme of contact points/normals/depths is of course just
an approximate way of representing contact between two objects. to
reduce the approximation error, all the current contact code tries to
put the contacts somewhere inside the intersection volume, in positions
that will (a) preserve non-penetration and (b) not generate unnecessary
body motion (no extra energy allowed!). the cyl-cyl contacts often do
not meet these conditions. if you integrate cylinders into the box
stacking demo and stack them up you'll see that this error causes them
to jitter and pop way more than even the stacked boxes (which themselves
jitter because of another well understood reason). i spent a lot of time
on the current primitive-primitive collision code to prevent exactly
this sort of thing. in some cases, like the capped-cyl-to-box code,
i had to go through quite a few different schemes before i got it
(hopefully) right.
russ.
--
Russell Smith
http://www.q12.org
--Multipart_Thu__10_Oct_2002_22:43:29_-0400_0839c960
Content-Type: application/octet-stream;
name="foo4.jpg"
Content-Disposition: attachment;
filename="foo4.jpg"
Content-Transfer-Encoding: base64
/9j/4AAQSkZJRgABAQAAAQABAAD//gDtQ1JFQVRPUjogWFYgVmVyc2lvbiAzLjEwYSAgUmV2OiAx
Mi8yOS85NApDUkVBVE9SOiBYViBWZXJzaW9uIDMuMTBhICBSZXY6IDEyLzI5Lzk0CkNSRUFUT1I6
IFhWIFZlcnNpb24gMy4xMGEgIFJldjogMTIvMjkvOTQKQ1JFQVRPUjogWFYgVmVyc2lvbiAzLjEw
YSAgUmV2OiAxMi8yOS85NAoKQ1JFQVRPUjogWFYgVmVyc2lvbiAzLjEwYSAgUmV2OiAxMi8yOS85
NCAgUXVhbGl0eSA9IDc1LCBTbW9vdGhpbmcgPSAwCv/bAEMACAYGBwYFCAcHBwkJCAoMFA0MCwsM
GRITDxQdGh8eHRocHCAkLicgIiwjHBwoNyksMDE0NDQfJzk9ODI8LjM0Mv/bAEMBCQkJDAsMGA0N
GDIhHCEyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMv/A
ABEIAIEBNgMBIgACEQEDEQH/xAAfAAABBQEBAQEBAQAAAAAAAAAAAQIDBAUGBwgJCgv/xAC1EAAC
AQMDAgQDBQUEBAAAAX0BAgMABBEFEiExQQYTUWEHInEUMoGRoQgjQrHBFVLR8CQzYnKCCQoWFxgZ
GiUmJygpKjQ1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoOEhYaHiImKkpOU
lZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4eLj5OXm5+jp6vHy8/T1
9vf4+fr/xAAfAQADAQEBAQEBAQEBAAAAAAAAAQIDBAUGBwgJCgv/xAC1EQACAQIEBAMEBwUEBAAB
AncAAQIDEQQFITEGEkFRB2FxEyIygQgUQpGhscEJIzNS8BVictEKFiQ04SXxFxgZGiYnKCkqNTY3
ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqCg4SFhoeIiYqSk5SVlpeYmZqio6Sl
pqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2dri4+Tl5ufo6ery8/T19vf4+fr/2gAMAwEA
AhEDEQA/APZr+51GO8dbc4jGMcD0FV1vNUzh2ZffYpH8qNT1RrXUZY/4RjHPsKptrQYcrkezYr0I
UpOK91Hm1KqU37zLT6hqKHHmg/RRn+VNTVb7eA8hH1Qf4VQ+3CR8LIqe7gcfpSyXkyDG+KX3WtfY
rZxRl7Z78zN+K7mOC8vB7gD/AAqwJHY/LOf++RXJ/wBozx/MNx9tvFXbfX5QBujBx7VlPCy3ijSO
JWzbN5pbgZAIPviqkzakBuS4Cj0Kr/hUSa9Cxw8RB9albVIHUhSufc1kqc4vWJq6kZLSQ2Ce+LYl
uMD2Vf8ACrDzS4wt2d3b5V/wrPaRnO5ZR9KtWUsRPzFd3ueac49bfgTGb2v+JBJJrKthZ1I9dq/4
VG9zrcYySWHqEU/0rXe4jQ4AB+nNK9yiRb3O0fSkqn9xfcVy/wB9/ec8+samhwZCP+AD/CmjXb7O
DN/44v8AhWq99DcuEjdcd89aSb7HAn7yOME/xbQTWylDZw1MWp7qZSi1u5LgPKcf7o/wrSi1XzAA
ASffFc/P9nklzGxb/gOKv2kkcIGFAPqadSlC10ghVnezkbaTzufu4HrTpJZFXhgD6nFVE1KHo0gJ
9FGaiudUSIZFs7ehZSK5fZybtY6PapL4iys0wyWnVvZQKqeKL+70/wALXN5ZybLlBHtbAOMuoPBG
OhNVv7Vu5TiO3bHoBik8Xl28C3JI+cpFkded60qtNxSuXQqczep56fHXiYdb/wD8gx//ABNMl8de
JnhdY9W8tyDtb7PEcH/vmsfy3P3uPypDAp65/MVz2OowZvix49t53hfW8MjEH/RIP/iKZ/wt3xz/
ANBz/wAlIP8A4iq/ijQ/kbULcHIA8xc549a4/vXHNzi7XGdx/wALe8dd9c/8lIP/AIil/wCFu+Of
+g5/5KQf/EVw+c0VHPLuB3H/AAt3x1x/xPPr/okH/wARR/wtzxz/ANBz/wAlIP8A4iuHLYGadS55
dxnbH4u+Of8AoOf+SkH/AMRSf8Ld8df9Bz/yUg/+IriqQij2ku4WO1/4W946/wCg5/5KQf8AxFL/
AMLd8dZ/5DnH/XpB/wDEVxBpetPnl3Edynxe8bpKjPrO9AQWX7LCNw9PuV3tn8QNcvrVbiHUsxuM
j9zHx7fdrwpeRiut8G35Hn2Dnr+8T+v9K4Me6vs+eEmmuzZcbXPRpPHfiNXwNR4/64R//E1WuPiB
4nQApqeM/wDTCL/4mseVcDJqjdHhRXmU8VXb+N/ey3FdjYb4j+LADjVf/JeL/wCJqjP8T/GCZ26x
j/t2h/8AiKwnPUVm3B613061VvWT+8lpH0F8K/EGqeJPDN1eatdfaJ0vXiV/LVMKEQgYUAdWNFZn
wP8A+RLvf+wi/wD6Ljor36Lbppsye52WoGxa7ZZ8BxjJZeOnrVGXS9OmQtFcYPp0q9fuI7uUmQjO
OML6D1NVySI8xz5J9Vb/ANlr0qbairNnm1EnJ3RjS2Eedse52H93n+lFvabpNrJJ9BgH9a0ZZLyM
DayMD/dkf+tNgkvJZP4Vx13EvXV7SXKc3JG5NFEioYy9xs7q5Xj8M1GLO2Ev+jyhn/uyKw/UVOZb
pf3bxQPn0Vh/9amqAh3CKKM/75P+NYJvua2QnkAHM1snHdZetPjWxY7XtXT3YgilE4C/deU/9M52
H6V5V40+KRs9Xm0nS7V/3DmO4mkmbJcHlVBzjHTJ7/TJxrVlSjzSv8v+HNKdNzdo/wBfgel3VxpG
nnLSIzHouST+lVDqUFyQsEMYz6KMmvL9A8T6Zq9x5EjGC7f/AJZytw59m7n8jXTiYQRMoLHPrXyV
biXF0a9nTVuzve3re34Hd9RhKO+p2cJZSAROB6IQTUxvoCfLaSU57Srj+tc3pniIyItpeyqsZOFm
fJ2/Xnp79vpW2+lxLjc4Jzyegr6nAY+hjqftI6PquqOCtSqUXYth7ENlHhVvVstiia7MPW4X2yhI
qOPTbZeTBEw/2XJJ/wDHhSTRRquEjljH90MCD9Rkmuv3G+r+4j3kg/tVQvEsO702EVZguzcLtaS2
X22/40lpDG0Z3xwn224qO4SP+FI1x0AhP9aT5G7JDXMlds0VSKNMCZB/uYFRFElb5SZCO5XiseQy
/dSNMe6gfyqeITovywwkj/nnISfypeytrcPaX0sXxaPJ9+VEA7IAP8areMx5fge7CnO1YgD6/OtK
4upkGY41HcSg/wCFN8WIzeBbhRtz5cPTp99a5cTLkhzSeiOrD2cnZHjrM5//AFUzMv8AeP5CrbpL
DzsVh7UwXLZ5TFedDG4efwzR2OL7EDRSSxlH+ZWGCD3FcDrmjy6Tdcr+5ckxn+lelCViM54rP1az
h1SyaCYtnqjf3T61rNRqR913FqjzA0tS3VrLZ3DQyqQyn86h6c1xlA2ChpynKio3PyGliOUotoBL
RRRUgNIoX0paTFMBehyKuaXeGx1GG5B4VsN7qetVAc0nQ1MoqScWB6i8qzQrIhyrAMD7GqF395fY
VU8NXRudJ8tjzAdn4dRVmZtzn0r5/wBn7Oo49ja9zPl4zWdMM9a0rlwOgrMnfGTXdSuQz3H4IjHg
y9/7CL/+i46KT4Hnd4LvT/1EX/8ARcdFfRUP4aMnuddqEhS/k4QjjqPYVXMwY53Ee3auM8Zarf2v
iu9ihupI418vCg8D5FNYP9vamel9N+dd0a0UkrHJLDybbuenOkMgO4KT67R/hUUUUSE5UH6gV5wN
e1Reftsv4mlHiDVT0vZPyH+FWsTG1tSPqsvI9MHlDoqflQ0mRhQB9DivMz4g1UdbyT8h/hSf8JDq
h/5fX/T/AApfWIj+rT7o9M3HHLLn15J/nXzR4ytZbTxnrEcowxu5JB/uudwP5MK9M/4SDVf+fyT8
h/hXC+NoZbq5TVXbe74jlbAzkfdJx7cfgK5MZNVIadDWhSlB3Zxzn5lJ6g16R4V8WtfbNN1F83OD
5M5P+s/2W/2vfv8AXr50RuXp0NKGaNwyMVYHIIOCD614mKw0MRDllv0fY64yaZ7Jc7kduynmun8G
6+15FLp1wyvLbD93nALR9PrxwPxFeeaPrX9saVG0jZuYBsm9/Rvx/mDVNtTl0nVI7uGUxskhBYf3
Twf0NeflU54TE2l6P+vxCvBVIWPdDHDu37EJPqCf60Mkblc+WAO2yvNj4g1Udb2T8h/hSHxDqgHN
7J+Q/wAK+3+srzPO+qy8j013jwFSNV91+WiN9hyrv+LZrzP+39VxkXkmPoP8KT/hIdU/5/ZPyH+F
L6xHsH1afc9OMu7O4k57lj/SkRzH0cAewH9a8y/4SHVP+f2T8h/hS/8ACQar/wA/sn5D/Cj28Ow/
q0+56aZFIPTPrtFN8YyLF4BuZGOAI4eR/vpXmn/CQar/AM/sn5D/AAr0PXwLv4XqbhifMtbZnPqd
yH+dcePqRlh5+j/I2oUpQldnj73sTkBWdvpT0vkgUhYizHuTVtbC1/hDkfWn/wBnW6jfsJ9sk18I
509rHoWZQbVpQOIk/E1AdVuiOiD8KsS6aruW8oAe54pRaW0RHyKT79K0jKmtUhamBrdu2qQ+Y2PO
QfKVA59q5AqVYqwIPcHtXprFB91Fz9KwNd0c3iG5t4x56j5gP4x/jXo4XF2fJPYiUTjJBhTTYW5I
qaZCqsrAhhwQe1Vl4YGvXWqMy32opoNLUDFopKM0ALRRRigDc8M3Bjup4c/fTI/A/wD1635GrkdI
l8nU4WzgHIP5V1crACvLxcLVb9y47FCd+tZczbs+lXLqQZI/Os/ZLczrDCpeRjgACtqMGJnvfwNO
fBV7/wBhF/8A0XHRWj8JLAad4QlgGM/a2LEdzsTNFe9TjywSM2ct45A/4TK/yP8AnnyR/wBM196w
QqY+8oP1rd8dGNfGeoEqS37vvj/lmtc6rM7cW4A92zXhV82qwqShGK0bX9amigmgnEjYVCrep9Kk
RdseD+h/+tTViYnPf0AzT/LkYY5HvnH6VzSzjEdLfcV7NDN5U88j/PtR5ayDcGx9Km+yx7QWmJ9j
imtaKBkblx/tHP8AOp/tiv3X3B7NEarIp4AYfUqaZcwwXMMlvcbNjrhs4OPxz1p32WLlpFeRv9ok
ij9y67Ps8eD329KuOb1+tn8v+CHIjzXUrF9Nu3gZw6jlJFPDD1qtwy59a9F1HSbfULfy5V4/hZMA
r9K43V9HGkmMJM0quT1XG3HQE/n+VdWHxkK2mzJcbD/D179j1WME4SYeU349P1x+taWskOxUZJY8
AVzMbESKV+8CMEetd5p+kyzTre3MWTnMcRH3fQn3/l9emn1Z1KykvmK+hqR7Fb95LHn/AGmxUrAM
PlKFfbOKsCKTA3CJR7oKhaCMEASBSBxs4FezZkFdZAj4Dp9Ad1S4DDIjc++AB/OmtExJxMWI7EAj
9KYAVblFcd+o/wAaAHsGUZDH6UwSI3Hyhv8Ae/wzU63CqvzW5H0+Y/kKrT6pawrunkEKf3pV2/zI
ppXdkBKF3cDn2x/9avVdZIT4WRb+ALS2z+aV5QhtnhE0MiOrjKvGRgj8K9U1tgvwniYgn/Q7X69Y
658Wv3E15P8AIa3R5kt0oPCMR61N55ddyMMVQIzz+lMVmjzjB9jXxPs0zouWzJuPzHNMZVPIxTkk
Rot20ZNNAB4waFoBE0ZHpTB8h5q0FQ1E6APmqUgMnUNIs7/LvABIerKcE/WufufB8oy1vcK3orjH
612RVs005Bwa66WKq09IslxTOAn0XUbcHfbMwHVk+YfpVLBBIYEEdQa9KchCCOtefao27VbpvWQ1
6WFxMqzakiJRsVe9HSg0dRiu0kWlBzTBS0gJYsmZMZzkdK6e6uAB1rmbU/6SnrmtmOC41G48uBCc
dWPRfrXPVpuc0kNOyIUjlvJxFCpZj+nua6jS7FdNiACqZj96THJ/+tVmy0qGxtwiDcx5Zscsasqu
znaR9a9KhQVNXe5LZ6p8MnL+G7kk5P2xv/QEop/w2JPh24JAH+lt0/3EorpJOO8bxE+Mb9yAAfL5
P/XNawPkTqxPtXQeNg7+Mb9VUnHl9v8Apmtc68Ljg8n06V8Ri/8AeJ3fV/mdMdkOMrNwgwPalRC/
LNk9hninxW7sMttA7CnSJsX735Vy3WyKGBQjDBDOew7VJskfrIqn0AzVmOGGOPAVix5OTmpEZVU/
KF/nWbn2CxAmnBhuYMf0qRbOGP720Z6gCknvgiY3D86zLu/J+RTjPU0RjUmGhJfXsMalIFUDuwHJ
rESBNSgvLebJjkUKxBAPfpmoby6BfANP0XfLJOsZGfl6nA717+VU/ZVoyW//AADKbuiW08O2Vqym
Jds0fHmOdxz9P8MVdknu7UDfG0wHdD2/GtGLTgy5eUAZ4CjH9an+xWkGN2+T3Zsfyr6Zttt9zIx4
tReVwDGoVs45Jzj8qtb49u51GSeOKsXS2cyhfLjOOQyLg/nVKQTR5KIkmOu4YP5jrUR5teYB0kso
OIUJzwCMAVXCXbNl1Rcn15qU6iglMMkbRN3yB+NEksZXJORnOQ2TVALGq5y+W9s8VbW6tFjwIoie
n3cmqO3zMj0PfigR5JwwOOMigCctDtxHFHEvTEYx/KvTtcQD4TRIvygWdqB7cx15asUaY3qxbtzx
Xq2soJfhZEoJANpbfzSsMU/3E35P8hrdHk5YKoz270KjTfdXj1qwLFSwyzH61aWBQuBgV8Q6iWx0
WKLqiAKvamgkVoG3jY809bOMrjFT7VJajsUA/HvSEMx6GtNLGLrt6epp5iijBYgYFT7VdAsY/lse
imopW2jB61buLkbiEGBWdM+Wx6VvC73EV53wCfQVzmp6Bd5N5CvnRyfOQv3l/CtyZ859K1rVh9ji
HAyg617uWU1KTT7GU2eWlgrbSQGHY0Vd8ZxLB4jARVUGJCQox3NUYcySJEB8zMFH419fHh6rWwn1
jD+81a6/Vf5HP7VKVmLS1rv4Z1FELbYyB6NUlroQDKbpif8ApmnH614CpyfQ1K+kaTcajKWiAVF6
u3Qf4mu+sNPWztVhhU7RyST1PrVTTVhtYFhiiREHY8k1fFxKAc7FX2FdNOmoa9QdyysDqAeAKmSB
HzhwfwqmLr5cGRvxpyXGR8pBHf1rYVj1T4doI/D84H/P03/oKUUz4cNv8PXBxj/S2/8AQEooEcl4
zudnjC/jHX93/wCi1rmjJ+9O45rX8dy7PG+oD/rn/wCi1rn3mXy8k89q+KxVP/aJvu3+Z0xeiNIO
xJx0xxVa4mxx19RVVbltuAeaa8ysATnd9Otc8aVmO5d/tEhcCPBxxzVSe8mJ5k2+gHFVHkYHnC+4
qlcXIUFUOSerVtCgr6ITZPLcFxlnLHtzUU10VBOcmqRm53Z+lU7i67ZrshRuTckkmBfH51p+GJyL
i6Yxsy/KuQOM81zivJNKEjBZ2OAB3rrtLs2tbMQrGzsfmYg4+Yjn6jt+Vetg6LU+bsRJm39plfcV
G2PuG5NRbskbVZuce2PxqGGCUbFkKrk9M5OPX+dWDHs+YOTtH5fkP516upAK5Xoihh/DmopGctwz
cYyB1+lTrCvVUBUDJ3//AFsipERlZXwdoxuC4/z6UgM6SFpCwljBBHGeTUH2CUH9zK4brjHTP+fp
WwEjRjmPJ6jP+fc/rTDjKkNk56dBRYDKiLwHbdr8hGMoOD7/AKVZW5R/9SSVHJYjGPzq0FR0x13H
H1NUJbAO+5FK88lSODjrjH9KdhFiOZfMK7wxBxleles6mM/DGAf9Olt/NK8YYXkAUlwVzn5Rz16d
en517Rcfvfhjac/esrY9P9yuXGP/AGap/hf5FR3R50I8U7YT0q6IY1HPJpGZV+6AK/PvaX2OqxFH
bd24qRURcnHSm+YT3qKa4EannpStKTAklmCISfyrIubpn4zxTJrlpMkmqjPxXXSo21YmwZstVKWT
BY9z0qZ5Nqn1qnIfWu2ESGQzHAxWvZhTDCWJGFHB5FYcjbmretEYWseEDDaOe4r2stXvv0IkF7p1
lqJ2XNukg7E9R/Wq0Oh6bA4ZLOMMpyGPUH8auGCXaPLJJPUE05EOPutkdRur3oYitTi4Qm0n0TZn
ZMNm8kEjb/tVBNZwtyTn/dFSlJGx1x3FWY4Au0MOOue9ZDMaaykCbomYgdiarILtXKvMFXrtcZH5
11KpFk8/hjrUM1qsgwYsD2xxQIyopGZAHkPPsMGrsOG+XKj6mqkumMmTEdoP90/0rMu7e7A+SVkz
0cLkflQB7n8MwB4cuQG3YvGyf+AJRVD4OJKnhC6E0/nP9vf5sY/5Zx8UUxHFfEGXb4+1JSf+eX/o
pK5ZrkNIQCSAMVv/ABJJHxA1PBx/qv8A0UlcisiiVm96+Yr006035v8AM2T0NVZtq53YPbmq8t0x
GN3PrVKS4IHDYX0qr5+7OeQO2azjR6juWnuOCNxI9qrNOX4AwKge6xx+lQSXDbcLlmJwAOprphSF
cmnnI46fSs6WfHqSTgYrbsfDl3Ovm3zG3j6iI/6wj8en4+nSuntLC3t7VreKBFXOSpwdx988969T
C4aMZp1VePVXtf562Ik9NCPSNFt9Otkd9s0zkFpQOB32/TH5/wAtgSKzE8AD7vOMevNVY45YpPLy
2FzgAdM+p/rViKAjGSd44OWGSMda7YQsrIhsT5dzBE3tjkLzz9enpT4RIf3gx5fQjkgDGaskCFCE
VW/vbv5+1LE29WkZHU/w46HjHP4VpsSQqgY8sx4JUdQfUCkVWXAJ2hePm6sKtfuyi7idg5BXsf8A
69VndCMyI4Vzgqrcn0xxUjI2DqSGUFQMZ7n9OajaJgV+YbT25zn0P+e1WCGJAfeWXlmIwSPQ9B+N
MZFGZFV1U/xDocf5FIohPDkuoYHs1I8bDdtkOc8MePfqKkZN37xWd4x/eAG3+VJNyzZZX4B5649q
QFXDSqv3d2OjkDP0r168ynw3tgcZFpbj/wBArygbXx99Tn/lmckfUV6pqJx8M4P+vS27Y/uVy4z/
AHap/hf5FLdHBvJ71Ez00tTGcKCSa+BUTpHNIEUknmsuaYyMeaWe53KVHfvVfdtX3NdVOnbVktiO
cCq8j4FPkbt3/lVRzz1rphEQM245qvM+AeelOZsVWlbOBXRCOpLGr95fzNdNZS/6DDvVcFeCa5ct
hWPrwK39Pb/RYFwQCvoDmvWy7436ET2LUu6OYTbvlPBzT57qAKuAz/yFRCXfKUUDb64yKGVGwQv4
+tewZ2BZpFbCqGB7Cp2uG2YRtp75GDUIm3PnBOB93rTHz5hODgjpigCSOXJJlzgdMDrVmOSNgc7s
/WqYEgXaqcH14pDImSP3cZHcmkMtNJFtIH3h7VAfLc4wATxjFMR1kQnzGY9DsBNPEdwwIjt2IHdy
BUjseqfDKNY/DlyqjA+2Mf8AxxKKk+G8M8PhyYTqFY3TEAHPGxKKtEnk3xPm2fELVR6eV/6KSuF+
09STzXe/Ezw/r1/8QdVnstE1G5t5PK2Sw2rujYiQHDAY65H4VzUPw78WzjLaNdwj/ppE3P5A15Ms
O5VJO3U0voYMt315ptvJPcv5UETyN6KM49zXb2fw1vIVLXml6nO/ZRbuF68cAZ/Wtm38OatBC0UG
iXqKDkKLRlHvj5a3hhNNRcxxVp4Xup/nu5Vt16lR8zY/l+tb2m6RY2Tq9vuabP3pOWH0PH6VvxaD
rhQB9KvVZjzi2fr25xTk0TVt2To+ojaMELbNz9OK6oUYQ2JuUtoDsyrl8YNR2+Gl2hSWA7HOD/hW
sNA1VXDnS74ccYtmJ/lU8GgajECr6Zfk9QRC2P5VqhMzRGr2/mkEjPVD9MjNTReXhvLkbfnoMAHj
rV0aHqodG/su7IPY27cH8qemi6ohbOm3gYE7f9HYjH5VdybFErINrHaChJJAPX/OaGHy5QEEH7qY
IY+lW5dD1cx4i0+9Cg5wYXxx+H5VVGk61G+xtIvmBwVZbZ+D69KVxkRAk3A7kLgFl3VSNyCqpE+c
cAdjg9DxzV19J1+RxNLpWoOAMbVtXH9AfSpItC1UbyNKvtrYLA2rjt6Y/wA/zTBFFmm8tSpRgTuw
RwPY4qRYBASwkKoRzDwR64HtWgNG1ckmLSb5QQSwMDjcfypraLq8MQK6ZfyOvKgQSf4Uhmc52qGj
crg8qeRj3qAzwo/lEshJxlhlQfatC48P6rdskzaTqCsBkILd8A/iKcuiausQQaXqOVOF/wBFc55/
3ehpDMmbeHAdhjIwAvzH6c9K9Z1MkfDCDPX7JbfzSvNp/D2tXZJfSr3jgA20gHt2r0vUrO6/4VpD
ZpbStcraW6GFEJYEFMjHXjB/KsMXG+Hml2f5DW6PM2mxwKoT3BbIB4rQl0XXMYXR9QP/AG7P/hVV
vD2uEf8AIG1D/wABX/wr46GGmtXFm7aKGcnihjgdeavjw9rgHGjah/4Cv/hTH8Pa7sONF1En/r1f
/CtlRn2YroyJWJBwaq5IPNbD+HNfxgaHqX/gJJ/hVd/DfiHoNC1T/wAA5P8ACt4Up9hXMt27k1C5
71rnwx4hY/8AIC1TA/6c5P8ACo38L+ISR/xIdU/8A5P8K2VOXYVzHY9B6V0FkxWwhYhjgfw81SPh
XxGWJ/sDVf8AwDk/wrfsvCWqyWkQn0rUwcfca3cAfpXoYGLjN3XQmRnG5hjw2W3E4AYipRO82BEH
YegjJ/8ArVuQeFdQhmGNGvFC8grA3+FXRoWrKRt0y8x/1wb/AAr1CDnYobhyuIGTPdyB/jVk6Zcs
u4yj8AW4roF0nU1R8aRd/jC+T+lOGi6lkEafer7eQ3+FMDnV0xSw3yzP6ruwD+FacWmwQxkQ28XH
UsBmr50XVCw2adeKR0Pkt1/KpxpmoqmW0q8Yj0hb/CiwrmcluNpZEXA6rinx7EOG2qP7oq02l6tj
CaddgH+9A3+FVzoWpuSzaZdg+ohf+WKLDud74JKnRptrbh9obn/gK0UeCbSey0WaK4gkhc3DNtkQ
qSNq84NFMR0lFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAF
FFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQB//2Q==
--Multipart_Thu__10_Oct_2002_22:43:29_-0400_0839c960--
From russ at q12.org Thu Oct 10 23:08:02 2002
From: russ at q12.org (Russ Smith)
Date: Thu Oct 10 23:08:02 2002
Subject: [ODE] Community page
In-Reply-To:
References:
Message-ID: <20021010231205.1f8bd682.russ@q12.org>
> Russel, if you'd like, please add
> http://www.cambrianlabs.com/Mattias/DelphiODE/ to the community page?
done.
russ.
--
Russell Smith
http://www.q12.org
From dmcclurg at pandemicstudios.com.au Thu Oct 10 23:36:02 2002
From: dmcclurg at pandemicstudios.com.au (David McClurg)
Date: Thu Oct 10 23:36:02 2002
Subject: [ODE] conveyor belts and moving platforms
Message-ID:
Benny Kramek wrote:
>> Also, if i want to simulate moving platforms (boxes with bodies) that the player can jump on, should friction keep the player on the platform or will I need a special contact joint?
> Friction will keep the players on the platform with no problem. Just make sure that there is enough friction.
I created a box geom with a body and dropped a sphere geom with a body on it. There sphere comes to rest on the box while the box moves back and forth (on a sine wave with SetVel) underneath it. But the sphere doesn't move back and forth with the box!!
Friction doesn't seem to give the sphere any motion. I tried infinite and 1.0 friction with the same results.
contacts[i].surface.mode = dContactBounce;
contacts[i].surface.mu = 1.f; //dInfinity;
contacts[i].surface.mu2 = 0.f;
contacts[i].surface.bounce = 0.5f;
contacts[i].surface.bounce_vel = 0.01f;
dJointID c = dJointCreateContact(world, contactGroup, &contacts[i]);
dJointAttach(c, b1Contact, b2Contact);
Any idea why this isn't working?
From bongard at ifi.unizh.ch Fri Oct 11 01:18:02 2002
From: bongard at ifi.unizh.ch (Joshua Bongard)
Date: Fri Oct 11 01:18:02 2002
Subject: [ODE] Evolved behaviours
In-Reply-To:
Message-ID:
As there seems to be quite a bit of discussion about NNs and evolved
behaviours on the mailing list these days, I'd like to direct your
attention to a physical simulation overlay I developed called MorphEngine
(www.ifi.unizh.ch/ailab/people/bongard/MorphEngine/). For those of you in
the know, and before you start throwing rotten fruit at me, this overlay
uses MathEngine, not ODE, but I've almost finished porting it to ODE, and
will post it up when I do. The program runs as an .exe standalone on
Windows, but my documentation includes a brief introduction to NNs, GAs
and evolved behaviours, and how they relate to the physical simulation of
robots.
Cheers,
Josh
On Thu, 10 Oct 2002, Nate W wrote:
> On Thu, 10 Oct 2002, Ian Munro wrote:
>
> > My interests actually lie in making physical robots rather than simulations,
> > but they're a great "what if?" tool.
>
> Be careful... That's exactly how I felt when I started planning the
> software that became Juice. Now I've lost all interest in making
> something I can touch. :-)
>
> I'm really enjoying the discussion of evolved behaviors. In Juice, a
> creature's movements are basically just sine waves of different phases and
> amplitudes applied to joints, and feedback loops from a body's orientation
> to one or more joints. I've been pondering a training feature to try
> using a GA to adjust the phases, amplitudes, and gains, but haven't
> actually implemented anything yet. I'm hoping it will smooth out gaits
> that have been designed by hand.
>
> I've come to the conclusion that this method of programming behavior
> creates creatures that tip over too easily though, so most of my time
> lately has gone into designing a new behavior programming language.
>
>
--
__________________________________________________________
Josh C. Bongard
Doctoral candidate, Artificial Intelligence Laboratory
Department of Information Technology, University of Zurich
Winterthurerstrasse 190, CH-8057 Zurich, Switzerland
Phone: +41 01 635 43 47
Fax: +41 01 635 68 09
www.ifi.unizh.ch/ailab/people/bongard/
__________________________________________________________
From slipch Fri Oct 11 06:15:02 2002
From: slipch (slipch)
Date: Fri Oct 11 06:15:02 2002
Subject: Re[2]: [ODE] Cylinder colisions
In-Reply-To: <20021010224329.65a1dbdd.russ@q12.org>
References: <17333538595.20021009192355@gsc-game.kiev.ua>
<757664571.20021010120947@gsc-game.kiev.ua>
<16117962618.20021010150125@gsc-game.kiev.ua>
<00f801c27056$f27be760$0e00000a@pierre>
<7724552614.20021010165115@gsc-game.kiev.ua> <3DA59188.4080906@kramekweb.com>
<20021010224329.65a1dbdd.russ@q12.org>
Message-ID: <1279165509.20021011161705@gsc-game.kiev.ua>
Hello Russ,
Friday, October 11, 2002, 5:43:29 AM, you wrote:
I know about this error. It happens when cylinders' edges touches.
There is still a warranty that the contact point is near the place
where it should be. It was not an error in my eyes I only wanted to
reduce calculations. I'll think how to fix it.
--
Best regards,
Konstantin mailto:slipch@gsc-game.kiev.ua
From benny at kramekweb.com Fri Oct 11 06:42:02 2002
From: benny at kramekweb.com (Benny Kramek)
Date: Fri Oct 11 06:42:02 2002
Subject: [ODE] conveyor belts and moving platforms
References:
Message-ID: <3DA6DF4A.60903@kramekweb.com>
>
>>>Also, if i want to simulate moving platforms (boxes with bodies) that the player can jump on, should friction keep the player on the platform or will I need a special contact joint?
>>>
>
>>Friction will keep the players on the platform with no problem. Just make sure that there is enough friction.
>>
>
> I created a box geom with a body and dropped a sphere geom with a body on it. There sphere comes to rest on the box while the box moves back and forth (on a sine wave with SetVel) underneath it. But the sphere doesn't move back and forth with the box!!
>
> Friction doesn't seem to give the sphere any motion. I tried infinite and 1.0 friction with the same results.
>
This is a known thing with ode. A ball that is rolling on the ground
will never slow down, even if there is friction. Try replacing the
sphere with a box.
Also, you shouldn't change the velocity of the platform with
dBodySetVel(). This is not the correct way to do things. You should only
apply forces. If you want to give a body a certain velocity you should
use a motor.
From p.terdiman at wanadoo.fr Fri Oct 11 06:49:02 2002
From: p.terdiman at wanadoo.fr (Pierre Terdiman)
Date: Fri Oct 11 06:49:02 2002
Subject: [ODE] Community page
References: <005f01c2704d$c6915080$0e00000a@pierre> <00bb01c27051$7f8241a0$0e00000a@pierre>
Message-ID: <007201c2712c$89469840$0e00000a@pierre>
> > I'd love to play with it also, but I'm guessing I'd have to buy the game
> > to download it?
>
> No.
> http://www.swissquake.ch/chumbalum-soft/files/KAT_1_2_UT2003_Setup.exe
Argh !
I was just told that KAT was *not* free. You were right, you actually have
to buy the game indeed, to be able to use it.
Sorry.... I thought it was a public link. Needless to say, the file has been
removed.
You're lucky anyway : UT2003 is a good game so there shouldn't be any reason
not to buy it :) (Hey, I'm kidding)
Pierre
From max.lungarella at aist.go.jp Fri Oct 11 10:46:01 2002
From: max.lungarella at aist.go.jp (Max Lungarella)
Date: Fri Oct 11 10:46:01 2002
Subject: [ODE] robotic simulation
Message-ID: <3DA70D4E.725824C6@aist.go.jp>
hi there,
"dynamechs" is a dynamics engine, mainly intended for robotics
simulation (http://dynamechs.sourceforge.net/). recently i've given it a
try, and although i appreciate very much it's speed, i have the
impression, that it's rather hard to construct complex structures - like
robots.
is there anything that would prevent the use of ODE for the same
purpose? i.e., robotic simulation? is there anybody that has tried to do
a quantitative comparison between different physics engines, in terms of
accuracy, which is kind of important in this case? or does anybody have
interesting pointers to relevant literature?
thank you very much in advance!!
cheers,
max
--
Max Lungarella
Neuroscience Research Institute
Tsukuba AIST Central 2
Umezono 1-1-1, Tsukuba 305-8568
Japan
Tel +81-298-615369
Fax +81-298-615841
http://www.lungarella.com/max/
From wristy_j at yahoo.com Fri Oct 11 12:06:01 2002
From: wristy_j at yahoo.com (Jason Gott)
Date: Fri Oct 11 12:06:01 2002
Subject: [ODE] Old Cholesky factorization code
Message-ID: <20021011190523.22176.qmail@web40810.mail.yahoo.com>
Greetings,
In the code where the Dantzig LCP solver takes over
(after the A matrix and rhs vector have been
determined), I noticed that there is a commented call
to a Cholesky factorizor and solver. In block-matrix
form (where each entry is a matrix of the form
J*InvM*Jt), I realize that the A matrix is
block-symmetric, BUT, I was wondering... Are the
diagonal entries of the block A matrix themselves
actually symmetric (J*InvM*Jt) even after the body has
undergone rotations, making the inverse inertia tensor
non-symmetric? If not, the Cholesky decomp wouldn't
work, correct?
In other words, did the Cholesky decomp ever work
properly for A? Or was it just ditched to incorporate
LCP constrains (contacts with friction)?
Thanks!
J
__________________________________________________
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos & More
http://faith.yahoo.com
From mfdubois at club-internet.fr Fri Oct 11 12:25:02 2002
From: mfdubois at club-internet.fr (Michel DUBOIS)
Date: Fri Oct 11 12:25:02 2002
Subject: [ODE] Problem with AngularMortor and BallAndSocket
Message-ID: <84CB8473VQPNRP42MH96PO43QOECWSI.3da7258c@MD_PC_02>
Hello,
I am a newbie in ODE and C++. First I developed a simulator in Java3d with threads and now I am porting it in ODE/Drawstuff to
have physics.
My project is to simulate a mobile robot named an atom who can be composed with identical robot to become a molecul. An atom is
mainly a body (a square box) with 6 legs (left, right, top,bottom, front and rear).A leg can rotate with 2 axis. A leg can be
attached with the leg of an other atom. A molecul is one atom or more than one atom.
In ODE, an atom is a box with 6 legs. A leg is 2 boxes (or cylinders ..) with a slider.
I think, a BallAndSocket joint with angular motor joint can attach the body with a leg.
But I afraid, I don't understand the angular motor in user mode.
First the stop limit seems not to be effective.
And the axis seems to be relative to the gobal frame not to the body. When the body rotate, the legs seems to rotate with a
strange maner. I think i have the same problem than Tim Schmidt in july. The rotations behave as if the axes are anchored to
the global frame, whatever the orientation of the first body looks like.
May be someone have a solution to my problems ?
Michel DUBOIS
From Sean at Blackscreen.org Fri Oct 11 12:31:02 2002
From: Sean at Blackscreen.org (Sean S Cullen)
Date: Fri Oct 11 12:31:02 2002
Subject: [ODE] Box Box Algorithm
Message-ID: <45177.24.91.219.122.1034364764.squirrel@mail.blackscreen.org>
I thought I remembered someone implementing a version of dBoxBox that will
compute more than a single collision point. Is there any chance of
getting that put into CVS?
From coding at natew.com Fri Oct 11 13:21:02 2002
From: coding at natew.com (Nate W)
Date: Fri Oct 11 13:21:02 2002
Subject: [ODE] robotic simulation
In-Reply-To: <3DA70D4E.725824C6@aist.go.jp>
Message-ID:
On Sat, 12 Oct 2002, Max Lungarella wrote:
> "dynamechs" is a dynamics engine, mainly intended for robotics
> simulation (http://dynamechs.sourceforge.net/). recently i've given it
> a try, and although i appreciate very much it's speed, i have the
> impression, that it's rather hard to construct complex structures -
> like robots.
When I set out to write a robot simulator (see
http://www.natew.com/juice), I looked at both Dynamechs and ODE, and chose
ODE for the reason you describe above. In retrospect, I think that
Dynamechs would probably only be slightly more difficult to work with.
Using ODE, you can created bodies and joints and connect them arbitrarily
and everything just works. With Dynamechs, my understanding is that any
closed loops need to be handled as special cases. In retrospect, I think
that would probably be almost trivial to deal with. If you think of the
structure as a graph, where bodies are nodes and joints are edges, you
would just create the Dynamechs objects by traversing the graph, and when
you find a cycle in the graph (easily detectable), you create one of
Dynamechs' "secondary" joints.
>From an application-development point of view, ODE allows you to create
ODE's joints objects without worrying about closed loops; Dynamechs would
require you to examine the topology of the structure you're creating
before you create the joints objects.
> is there anything that would prevent the use of ODE for the same
> purpose? i.e., robotic simulation?
How detailed do you want the simulation to be? I was looking for a
high-level sort of simulation, treating motors and drivetrains as black
boxes and just looking at the overall structure of the robot and its
control system, and I'm very happy with ODE's performance in this case.
--
Nate Waddoups
Redmond WA USA
http://www.natew.com
From russ at q12.org Sat Oct 12 12:16:01 2002
From: russ at q12.org (Russ Smith)
Date: Sat Oct 12 12:16:01 2002
Subject: [ODE] Old Cholesky factorization code
In-Reply-To: <20021011190523.22176.qmail@web40810.mail.yahoo.com>
References: <20021011190523.22176.qmail@web40810.mail.yahoo.com>
Message-ID: <20021012121947.20fed8dc.russ@q12.org>
> In block-matrix
> form (where each entry is a matrix of the form
> J*InvM*Jt), I realize that the A matrix is
> block-symmetric, BUT, I was wondering... Are the
> diagonal entries of the block A matrix themselves
> actually symmetric
yes:
A = J*inv(M)*J'
A' = (J*inv(M)*J')'
= (J')' * inv(M)' * J'
= J*inv(M)'*J'
each 6x6 block of M contains a diagonal 3x3 matrix (the mass) and a 3x3
transformed inertia tensor I*.
I* = R*I*R'
I*' = R*I'*R'
I (the inertia tensor) is symmetric, so I* is symmetric, so M is
symmetric, so A is symmetric.
> In other words, did the Cholesky decomp ever work
> properly for A? Or was it just ditched to incorporate
> LCP constrains (contacts with friction)?
cholesky is not used, i use the L*D*L' factorization instead - but this
also needs a symmetric matrix. the LDLT factorization is used on the
sub-matrix of A that does not have LCP constraints, then LCP is used
incrementally on the rest.
russ.
--
Russell Smith
http://www.q12.org
From nathan at whatever.net Sat Oct 12 19:10:02 2002
From: nathan at whatever.net (Nate Waddoups)
Date: Sat Oct 12 19:10:02 2002
Subject: [ODE] Community page
In-Reply-To:
Message-ID:
On Thu, 10 Oct 2002, Anselm Hook wrote:
> > > I've come to the conclusion that this method of programming behavior
> > > creates creatures that tip over too easily though, so most of my time
> > > lately has gone into designing a new behavior programming language.
>
> This sounds interesting - any links up yet? What kinds of features does
> your language make it easier to express?
No links yet, just some sketches on paper right now.
The main problem with the current language is that it allows you to design
one behavior, and it will behave according to that "script" no matter
what. If the critter falls over, it thrashes about like a fallen wind-up
toy (only worse because wind-up toys don't usually have attitude sensors
that suffer from gimbal lock).
I put script in quotes because the behavior is specified as a directed
graph, but it gets compiled down to a script-like sequence of
instructions. Anyhow, there's two main features I have in mind for the
next version:
The main thing is that each behavior will be paired with a "context"
function, yielding a value from 0 to 1. The context for a walking
behavior might be a relatively upright torso, the hips higher than the
feet, and so on. The outputs of the script will be multiplied by the
context value. Under the appropriate conditions, the behavior script runs
as usual; if the critter is standing on its head, the "walk" script has no
effect; if it's leaning heavily to one side, it will only try to take
small steps forward (meanwhile, the context is right for a "stand up
straight" behavior to take effect...).
Second, I want to be able to coordinate a whole bunch of behaviors. This
is the part I'm still thinking through. The "context idea addresses part
of the problem, particularly at the scale of motor control. But big
decisions like "walk, run or crawl?" or "chase or flee?" have me looking
for ways to create a hierarchy of behaviors, or fuzzy cognitive maps, or a
subsumption approach. I have a bunch of ideas here... part of the problem
is I'm not sure which to try first and I'm trying to think of a grand
scheme that uses all of them - and yet, is still easy to work with.
Mostly I think I need to do more reading.
Meanwhile I want to revise my document object model a bit so I can
implement undo/redo more easily, and integrate Novodex physics and CD, and
create a network interface to Juice so I can implement the new behavior
(and editor) as a separate application... and, and, and. So many ideas,
so little time. :-)
--
Nate Waddoups
Redmond WA USA
http://www.natew.com
From max.lungarella at aist.go.jp Sat Oct 12 21:03:01 2002
From: max.lungarella at aist.go.jp (Max Lungarella)
Date: Sat Oct 12 21:03:01 2002
Subject: [ODE] robotic simulation
References:
Message-ID: <3DA8EF87.778199E3@aist.go.jp>
hi there,
thanks for replying.
> When I set out to write a robot simulator (see
> http://www.natew.com/juice),
i tried "juice", it's pretty cool, and well designed. the only problem that i
have with it, is that i cannot export the models i realize. in other words, it
would be neat if i could construct something using juice, and be able to
import this something in one of my own programs. do you have plans do add
similar feature?
> Using ODE, you can created bodies and joints and connect them arbitrarily
> and everything just works. With Dynamechs, my understanding is that any
> closed loops need to be handled as special cases. In retrospect, I think
> that would probably be almost trivial to deal with. If you think of the
> structure as a graph, where bodies are nodes and joints are edges, you
> would just create the Dynamechs objects by traversing the graph, and when
> you find a cycle in the graph (easily detectable), you create one of
> Dynamechs' "secondary" joints.
yep. the only problem, that i have with this approach, is that almost the
whole body is some sort of special case - read "hack" - and therefore less
intuitive to design. i tried to use dynamechs and i still don't grasp it
completely. ode is so easy to use and also aesthetically more pleasant ;)
> How detailed do you want the simulation to be?
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. the
modeling of the motors does not worry me as much as the modeling of the ground
reaction forces, since the feet of my biped robot are not hard, but kind of
soft and deformable.
cheers,
max
--
Max Lungarella
Neuroscience Research Institute
Tsukuba AIST Central 2
Umezono 1-1-1, Tsukuba 305-8568
Japan
Tel +81-298-615369
Fax +81-298-615841
http://www.lungarella.com/max/
From johnb003 at hotmail.com Sun Oct 13 00:19:02 2002
From: johnb003 at hotmail.com (John Butterfield)
Date: Sun Oct 13 00:19:02 2002
Subject: [ODE] Slightly More Complex Car Shocks Simulation
Message-ID:
I am working on a racing game and to start with I made a hovercraft to avoid
using joints and figuring out what works and what doesn't, but now I am
working on my rc10 and I've got some problems. Here is the page for my game,
I've got a picture of the vehicle on the 'home page':
http://web.csuchico.edu/~jb393/urgent
Ok so my problem is that I have a few more moving parts than the standard
buggy problem. The top red axel thing I am treating as the same body as the
carbody, the moving parts are, the wheel, the spring/shock, and the lower
axel. So it's really just a puzzle of how to put it together.
Let me ask this first, there will likely be a lot of torque and quick
movements since the masses are so small, being an remote controlled car, so
would it be better to use fewest joints (like one hinge2 joint) and set the
other positions manually and rotations manually based on the position of the
wheel and body, or maybe add extra joints to add support. For example, with
a large mass ratio like that of my lower axel and the carbody, if I use a
regular hinge with some axis and apply a force along the same axis but
translated out to add leverage, would that hinge want to break. An analogy
would be hanging on a cupboard cabinet with all of your weight. Instead of
using a hinge then, you could construct a seemingly more stable structure by
making a triangle with ball joints, like this where F is the force and y is
the vertical axis:
|O
| \
| \
y O
| / ^
| / |F
|O |
Something I didn't mention, since I was trying to keep things simple is that
I made a scripting interface to the physics that corresponds to a 3ds file.
This means any kind of hack like setting the position of the shock based on
the wheel, I would like to avoid so the scripts can correspond to the
existing physics. If it truly is the best solution, I could add my own
special kind of joints, I suppose, and make them available for the scripts.
The method of connecting the bodies I've been experimenting is as follows:
wheel->hinge2joint->shock,
shock->sliderjoint(vertical axis)->carbody
just this has a lot of error; the shock->sliderjoint->carbody doesn't
maintain it's orientation with the carbody (it falls off it's axis)
then for the bottom axel I needed a joint that only restricts 2 positional
degrees of freedom, it's a combo of a balljoint and a slider... looks like
this X====|----O it's kind of a "look at" joint.
I would just make fake bodies, and by that I just mean bodies that don't
have any corresponding model to draw, or no physical matter but I was scared
to use 0 for a mass so they just have very small masses.
Ok this post is getting long, I'll leave it at that.
_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail.
http://www.hotmail.com
From johnb003 at hotmail.com Sun Oct 13 07:53:01 2002
From: johnb003 at hotmail.com (John Butterfield)
Date: Sun Oct 13 07:53:01 2002
Subject: [ODE] Springs
Message-ID:
If I want a shock between two bodies, would it be more efficient to use
calculate the simple spring physics and apply direct forces to the bodies,
or create some kind of joint and use CFM and ERP to make it soft?
Also can someone clarify for me a bit more about ERP and CFM. What values
make them behave which way and what purpose do they serve for ode exactly?
Thanks,
John Butterfield
_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com
From jeffreyweber at hotmail.com Sun Oct 13 12:45:02 2002
From: jeffreyweber at hotmail.com (Jeff Weber)
Date: Sun Oct 13 12:45:02 2002
Subject: [ODE] Springs
Message-ID:
I believe all that info is in the ode document. somewhere it explains how
to use cfm and erp to mimick spring.
----Original Messa
ge Follows----
From: "John Butterfield"
To: ode@q12.org
Subject: [ODE] Springs
Date: Sun, 13 Oct 2002 07:52:48 -0700
If I want a shock between two bodies, would it be more efficient to use
calculate the simple spring physics and apply direct forces to the bodies,
or create some kind of joint and use CFM and ERP to make it soft?
Also can someone clarify for me a bit more about ERP and CFM. What values
make them behave which way and what purpose do they serve for ode exactly?
Thanks,
John Butterfield
_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com
_______________________________________________
ODE mailing list
ODE@q12.org
http://q12.org/mailman/listinfo/od
_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com
From martin at metahuman.org Sun Oct 13 13:17:02 2002
From: martin at metahuman.org (Martin C. Martin)
Date: Sun Oct 13 13:17:02 2002
Subject: [ODE] Springs
References:
Message-ID: <3DA9D499.726503D7@metahuman.org>
Hey John,
I think the best test is, will the spring force change significantly in
one time step? If so, you'd probably be better off with a constraint
(i.e. a joint). If not, applying a force/torque using simple spring
physics is probably better.
John Butterfield wrote:
>
> Also can someone clarify for me a bit more about ERP and CFM. What values
> make them behave which way and what purpose do they serve for ode exactly?
That's answered in the ODE docs. It even tells you how to convert ERP and
CFM values to spring parameters and back.
- Martin
From johnb003 at hotmail.com Sun Oct 13 20:42:02 2002
From: johnb003 at hotmail.com (John Butterfield)
Date: Sun Oct 13 20:42:02 2002
Subject: [ODE] Hinge Forces
Message-ID:
I drew a picture to help illustrate my problem:
http://web.csuchico.edu/~jb393/urgent/images/hingeforce.gif
If I apply force F to body m2, and it has one hinge joint to m1, will there
be a much larger error than if I make another joint like in the picture?
Is it better to represent the dynamics as simple as I can, or with a more
structurally sound design?
_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail.
http://www.hotmail.com
From russ at q12.org Sun Oct 13 21:18:01 2002
From: russ at q12.org (Russ Smith)
Date: Sun Oct 13 21:18:01 2002
Subject: [ODE] Hinge Forces
In-Reply-To:
References:
Message-ID: <20021013212244.21c5a8f6.russ@q12.org>
> If I apply force F to body m2, and it has one hinge joint to m1, will
> there be a much larger error than if I make another joint like in the
> picture?
the answer is that the configuration on the left is the correct one. one
hinge joint is all you need to resist *any* amount of force that tries
to push the hinge out of alignment. ODE does not model the breakable
hinges that you buy from the hardware store, it models ones that are
infinitely strong. having said this, from time to time you may see
joints come slightly out of alignment, but this error usually has
nothing to do with the forces that are applied to them. reasons for
error might be:
* the rotation of the joined bodies per timestep is large.
* CFM is too high (this will give you "spongy" joints).
* there is numerical error caused by redundant constraints.
the configuration on the right side of your picture falls into this last
category - you have two joints trying to do the same job (i.e. trying to
limit the same degree of freedom) so this can cause numerical error
(especially if CFM is small) and totally ruin the simulation.
> Is it better to represent the dynamics as simple as I can, or with...
as in most things, keeping it simple is best. but, as in most things,
figuring out what the simple solution is can by tricky.
russ.
--
Russell Smith
http://www.q12.org
From johnb003 at hotmail.com Mon Oct 14 00:17:02 2002
From: johnb003 at hotmail.com (John Butterfield)
Date: Mon Oct 14 00:17:02 2002
Subject: [ODE] timestep
Message-ID:
Is there any harm in using variable times for the worldstep?
I'd like to make things based on time not framerate and if I must use a
constant time interval it seems like I'd have to use mutliple threads which
would then cause the need for symaphores and it gets ugly from there. If I
do a loop each frame for the amount of time that has passed, then I have
large errors since the time passed could be like 1.5 times the time step. I
just thought of an idea of truncating and adding the remainder to the next
frame. But then I can imagine it being jerky. The best solution I can
think of would be if I could just use variable time steps.
_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com
From Tomas.Sakalauskas at axel-group.com Mon Oct 14 02:50:02 2002
From: Tomas.Sakalauskas at axel-group.com (Tomas Sakalauskas)
Date: Mon Oct 14 02:50:02 2002
Subject: [ODE] timestep
Message-ID:
Each frame I tried to make as much complete steps as possible and then in
the end perfom step equal to remaining time. I got problems when very small
time steps were remaining. Then I added the time to next frame and used
fixed timesteps, but either precision was not good enough or I had to use
small timesteps, but then it consumed too much CPU. Variable timesteps seem
to be ok if the variation is relatively small (or actually if minimal
timesteps do not get close to 0).
For this I have two timesteps defined - normal and minimal. Each frame I try
to make as much normal steps as possible, if remaining time is more than
minimal, I perform timestep equal to remaining time, otherwise I add the
remainder to next frame.
This way I can control both CPU consumption and precision of simulation -
time error gets no bigger than minimal step.
Writing this message, came up with the following strategy:
- let T be the time needed to simulate.
- calculate how many full steps you can perform this frame - N,
- perform N timesteps lasting T/N, if N=0 and T is too small, just add it to
next frame.
This way timestep varies a little (but gets no more than DESIRED_STEP*2),
and you get small time error only in the case that framerate is faster than
minimal timestep you allow. If you' make N+1 steps lasting T/(N+1) instead,
you will get range (DESIRED_STEP/2, DESIRED_STEP].
Hope that helps,
Tomas
-----Original Message-----
From: John Butterfield [mailto:johnb003@hotmail.com]
Sent: Monday, October 14, 2002 9:17 AM
To: ode@q12.org
Subject: [ODE] timestep
Is there any harm in using variable times for the worldstep?
I'd like to make things based on time not framerate and if I must use a
constant time interval it seems like I'd have to use mutliple threads which
would then cause the need for symaphores and it gets ugly from there. If I
do a loop each frame for the amount of time that has passed, then I have
large errors since the time passed could be like 1.5 times the time step. I
just thought of an idea of truncating and adding the remainder to the next
frame. But then I can imagine it being jerky. The best solution I can
think of would be if I could just use variable time steps.
_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com
_______________________________________________
ODE mailing list
ODE@q12.org
http://q12.org/mailman/listinfo/ode
From coding at natew.com Mon Oct 14 09:54:01 2002
From: coding at natew.com (Nate W)
Date: Mon Oct 14 09:54:01 2002
Subject: [ODE] timestep
In-Reply-To:
Message-ID:
On Mon, 14 Oct 2002, John Butterfield wrote:
> Is there any harm in using variable times for the worldstep?
I use variable timesteps in Juice, and it works fine. The interval
between calls to dWorldStep depends on the time it took to call dWorldStep
and re-draw the scene.
Simple scenes get fast frame rates, complex structures with lots of joints
get lower frame rates, and really really complex situations get really low
frame rates and they start to act funny. I'm not aware of a really
graceful way to handle running out of CPU power though. :-)
--
Nate Waddoups
Redmond WA USA
http://www.natew.com
From russ at q12.org Mon Oct 14 10:54:02 2002
From: russ at q12.org (Russ Smith)
Date: Mon Oct 14 10:54:02 2002
Subject: [ODE] timestep
In-Reply-To:
Message-ID:
> Is there any harm in using variable times for the worldstep?
in theory there shouldn't be, in practice there is one small problem. if
you take a small step then follow it by a much larger step then then any
error-correcting velocity that was applied to the bodies in the first step
will be extrapolated into a much larger velocity in the second step,
potentially causing bodies to 'pop' away from each other. this problem has
been on my list of things to fix for a while - i have a fix that should
work well but will take time to implement (the underlying cause of the
problem is rather subtle).
russ.
--
Russ Smith
http://www.q12.org/
From ps_yumemi at yahoo.com Mon Oct 14 11:21:02 2002
From: ps_yumemi at yahoo.com (pia dalusong)
Date: Mon Oct 14 11:21:02 2002
Subject: [ODE] networking
Message-ID: <20021014182023.92351.qmail@web40508.mail.yahoo.com>
hello,
i have a problem networking my ode robot simulator
program. the program shows robots from different
computers but they do not collide with each other.
instead they go through each other. i created both of
them using the same functions but they don't seem see
each other. what could be wrong with my program? is
it nearcallback or some other function?
thanks
pia
__________________________________________________
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos & More
http://faith.yahoo.com
From coding at natew.com Mon Oct 14 15:47:02 2002
From: coding at natew.com (Nate W)
Date: Mon Oct 14 15:47:02 2002
Subject: [ODE] networking
In-Reply-To: <20021014182023.92351.qmail@web40508.mail.yahoo.com>
Message-ID:
On Mon, 14 Oct 2002, pia dalusong wrote:
> i have a problem networking my ode robot simulator
> program. the program shows robots from different
> computers but they do not collide with each other.
Are geom objects being created and sized and positioned correctly for all
of the bodies? Are all of the geom objects in the same space?
When I was having trouble with collisions, I found it helpful to dump the
names of each object at the very start of my collision callback. If
you're not using the user-data pointer, set it to a char pointer with the
object's name. If you are using the user-data pointer to point to an
object of a class that you've defined, add a 'name' member to that
class. This makes all kinds of debugging easier, IME.
Also, out of curiousity, how are you doing the networking? Does all of
the simulation take place on a server, or do the clients do some of the
simulation math? I've been pondering a networked application using ODE
for a while and I'm looking for ideas. I also thought it might be cool to
create a simple networking 'contrib' for ODE, since interactive networked
simulations could be used to do all kinds of fun stuff. It's an
interesting distributed-computing problem, though. :-)
--
Nate Waddoups
Redmond WA USA
http://www.natew.com
From johnb003 at hotmail.com Mon Oct 14 19:35:02 2002
From: johnb003 at hotmail.com (John Butterfield)
Date: Mon Oct 14 19:35:02 2002
Subject: [ODE] networking
Message-ID:
>Also, out of curiousity, how are you doing the networking? Does all of
>the simulation take place on a server, or do the clients do some of the
>simulation math? I've been pondering a networked application using ODE
>for a while and I'm looking for ideas.
I have not actually implemented my netcode but I thoroughly thought about it
and decided on how I'm going to do it. There are several trades offs I
could see from server-side to client-side and who tells who what collisions
happen. Thought the implementation you use is dependent on what your program
is modeling. I am doing a remote-controlled racing game, but not like
revolt... if you're curious just check out my page:
http://web.csuchico.edu/~jb393/urgent
I started thinking about client-side physics, but being a racing game it
could be really weird. Here is an example: Your actual position is about a
car's distance behind the other player... Through lag though, the other
player seems right next to you. If you were to ram that car, then tell the
server hey I hit him, and then the sever relay that to the the other player
and bounce him away from you, you'd think it was perfectly legitimate. Now
from the prospective of the car in front of you. That player sees you even
further back than you really are, (like 2 car distances) so then he sees you
move to the side and out of no where he gets bumped off course... Ok so this
method obviously has it's flaws for a racing game but for a first person
shooter or something, it would be necessary so that you could shoot AT the
player... not in front of them.
The other main method is to do things server side, the question then becomes
how much to do on the server and how much to do on the client-side. Lets
say you did everything server-side... this would be the absolute most
accurate if you told the server I am turning left and it turned you left and
then sent back the positions of you and the other players but then you have
lagged controls and no one likes that. If you only plan on playing this on a
lan, maybe the lag is not an issue for you and this method is best.
The method I plan on using for my racing game is a hybrid of the two. I
will keep track of the vehicles on the server and do collision detection (I
have more to say about this... possibly in my next post) there between the
vehicles. I however do the controls for my vehicle on the client and send
the server information about my position rotation etc... depending on how
accurate you might just send the information about the vehicle or model
whatever in whole and have the server guess what orientation the bodies
have. For example the rotation of the wheels and the locations of the
shocks and all that or just the vehicle altogether... Anyway with this
method, one might have to predict a bit or aim in front of the other car
slightly to make the collision on the server happen... I'll attempt to fix
this by trying to show how the car might look after this much time and then
use some kind of frame to frame dampening to move the car from where I
projected it to be to where the next packet says it is.
I hope this was thought provoking,
-John Butterfield
_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail.
http://www.hotmail.com
From jeffreyweber at hotmail.com Mon Oct 14 20:23:01 2002
From: jeffreyweber at hotmail.com (Jeff Weber)
Date: Mon Oct 14 20:23:01 2002
Subject: [ODE] fastcar vs. ode
Message-ID:
I apologize if this has been asked previously, but I'm currently researching
different physics engines for simulating vehicles. Does anyone have any
experience with "fastcar" http://www.oxforddynamics.co.uk/
How does it compare to ode?
_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com
From nick.mcevoy at dsto.defence.gov.au Mon Oct 14 21:17:02 2002
From: nick.mcevoy at dsto.defence.gov.au (McEvoy, Nick)
Date: Mon Oct 14 21:17:02 2002
Subject: [ODE] RE: Wheel rotation problem
Message-ID: <108E7D907871D6118B5000306E0189F82005EA@ednex504.dsto.defence.gov.au>
Peter wrote:
>Nick, did any of these experiments work? (i.e. get rid of the
>wheel-bending problem)?
No I have not yet been able to rid myself of the wheel-bending problem as you turn corners at high speed (I noticed the buggy_demo has the same 'subtle feature').
I tried (each sim step)...
- dBodySetFiniteRotationMode()
- dBodySetFiniteRotationAxis()
It reduced the problem but did not remove it completely.
I tried different combinations of contact values ERP, CFM & slip, also gravity, I have not yet try different wheel/body mass & geoms. All my changes either increased or reduced bendy wheels but did not remove it.
The problem is that bendy wheels make my 'car' impossible to control ... it looks like someone attached the wheels with a rubber band ... hilarious fun if thats the sort of game I was trying to write ! :)
(russ/ode_users?) Why is it not possible to totally stop the hinge2 'axles' becoming 'bent' ?
Nick
From p.terdiman at wanadoo.fr Mon Oct 14 21:29:01 2002
From: p.terdiman at wanadoo.fr (Pierre Terdiman)
Date: Mon Oct 14 21:29:01 2002
Subject: [ODE] fastcar vs. ode
References:
Message-ID: <03cf01c27403$1f2d94c0$0e00000a@pierre>
> I apologize if this has been asked previously, but I'm currently
researching
> different physics engines for simulating vehicles. Does anyone have any
> experience with "fastcar" http://www.oxforddynamics.co.uk/
>
> How does it compare to ode?
FastCar uses penalty methods, so I'd say it's faster, but not as stable.
(No, I've never used it.)
Pierre
From Nguyen Binh Mon Oct 14 22:05:01 2002
From: Nguyen Binh (Nguyen Binh)
Date: Mon Oct 14 22:05:01 2002
Subject: [ODE] fastcar vs. ode
In-Reply-To:
References:
Message-ID: <1102252288.20021015120049@glassegg.com>
JW> I apologize if this has been asked previously, but I'm currently researching
JW> different physics engines for simulating vehicles. Does anyone have any
JW> experience with "fastcar" http://www.oxforddynamics.co.uk/
JW> How does it compare to ode?
FastCar is specialized for vehicle. ODE is generic physics
package. So say, for vehicle physics FastCar "maybe" better.
But we shouldn't compare a 20.000 bulks package with a free open
source one...
And more, technically ,as far as I know , Fastcar use penalty method
so it may be fast but not stable.
--
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 johnb003 at hotmail.com Mon Oct 14 22:35:02 2002
From: johnb003 at hotmail.com (John Butterfield)
Date: Mon Oct 14 22:35:02 2002
Subject: [ODE] Collision Detection - Quick Question About ODE Internals
Message-ID:
struct dContactGeom {
dVector3 pos; // contact position
dVector3 normal; // normal vector
dReal depth; // penetration depth
dGeomID g1,g2; // the colliding geoms
};
Does ODE need the dGeomID's when doing the dynamics? For example, if I use
alternate collision detection, do I have to use geoms?
_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com
From ps_yumemi at yahoo.com Mon Oct 14 22:50:01 2002
From: ps_yumemi at yahoo.com (pia dalusong)
Date: Mon Oct 14 22:50:01 2002
Subject: [ODE] networking
In-Reply-To:
Message-ID: <20021015054936.58434.qmail@web40512.mail.yahoo.com>
Someone pointed out to me that my question was a
little vague so i'll try to make my program clearer.
I have a robot simulator program that can connect to
other simulations using directx8 directplay using a
peer to peer connection. I connect through a LAN
connection and I'm doing this so I can simulate two
robots at the same time in the same environment even
if the specs for the two robots are not in the same
computer. It's my thesis project so I can graduate in
college.
I just send the speed and direction of the robot in my
pc to the other computer and vice versa.
i created both mobots so they all have corresponding
dBodyIDs and dGeomIDs.
I guess I'm just worried coz the only things i
considered in the nearcallback function are the
sensors.
and yes we were planning to distribute this program as
an open source program after i finish it.
any comments or suggesions are welcome.
thanks
>
__________________________________________________
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos & More
http://faith.yahoo.com
From russ at q12.org Mon Oct 14 23:19:02 2002
From: russ at q12.org (Russ Smith)
Date: Mon Oct 14 23:19:02 2002
Subject: [ODE] Collision Detection - Quick Question About ODE Internals
In-Reply-To:
References:
Message-ID: <20021014232322.0ea0ba61.russ@q12.org>
> Does ODE need the dGeomID's when doing the dynamics? For example, if I
> use alternate collision detection, do I have to use geoms?
the geom IDs (g1 and g2) are in the contact structure because you may
pass groups to dCollide and then get returned a list of contacts between
(potentially) many different bodies. in this case your code would
have to examine each g1,g2 and e.g. figure out which body it's for,
create the contact joint on that body, etc. if you're using another
collision package that doesn't have this feature, you just set g1,g2 to
0 (or don't set them at all) and remember not to use them in your code.
russ.
--
Russell Smith
http://www.q12.org
From kaffiene at xtra.co.nz Tue Oct 15 14:33:02 2002
From: kaffiene at xtra.co.nz (Peter)
Date: Tue Oct 15 14:33:02 2002
Subject: [ODE] RE: Wheel rotation problem
In-Reply-To: <108E7D907871D6118B5000306E0189F82005EA@ednex504.dsto.defence.gov.au>
Message-ID: <008601c27492$2ed71510$5c02a8c0@peter>
> Peter wrote:
>
> >Nick, did any of these experiments work? (i.e. get rid of the
> >wheel-bending problem)?
>
> No I have not yet been able to rid myself of the wheel-bending problem
as
> you turn corners at high speed (I noticed the buggy_demo has the same
> 'subtle feature').
>
> I tried (each sim step)...
> - dBodySetFiniteRotationMode()
> - dBodySetFiniteRotationAxis()
>
> It reduced the problem but did not remove it completely.
>
> I tried different combinations of contact values ERP, CFM & slip, also
> gravity, I have not yet try different wheel/body mass & geoms. All my
> changes either increased or reduced bendy wheels but did not remove
it.
>
> The problem is that bendy wheels make my 'car' impossible to control
...
> it looks like someone attached the wheels with a rubber band ...
hilarious
> fun if thats the sort of game I was trying to write ! :)
That was pretty much exactly the results I got - this problem has
completely killed my ODE project.
> (russ/ode_users?) Why is it not possible to totally stop the hinge2
> 'axles' becoming 'bent' ?
The question has been asked a lot of times, but it seems the only people
who ever discuss it are people (like me) who want to use ODE, but don't
know enough physics to fix it (sheesh! I find comprehending ODE hard
enough for my little brain!)
But it *would* be nice if Russ or someone else equally en-clued could
chime in?
Cheers,
Peter.
From Brad at fie.us Tue Oct 15 16:10:02 2002
From: Brad at fie.us (Brad Friedman)
Date: Tue Oct 15 16:10:02 2002
Subject: [ODE] VStudioNet
Message-ID: <3DACA09A.50505@fie.us>
Hello. I just joined this list just now. So if this has already been
gone over, please excuse my ignorance.
I grabbed the release of ODE 0.3 and went about trying to get it to load
in Visual Studio .net. I found the project files in the contrib
directory of the web-based CVS useful. However, I did encounter a
problem, and I did solve it. It might be worth updating the project files.
When I changed the preprocessor directive from dDOUBLE to dSINGLE, it
stopped compiling correctly. A little work brought me to a section of
code regarding HUGE_VAL and HUGE_VALF. I then relized the project file
did not have a "MSVC" preprocessor directive and therefore was trying to
compile incorrectly.
I realize the VS projects were in the contrib directory for a reason.
However, its probably worth updating them to have the "MSVC"
preprocessor directive by default.
Thanks.
-Brad Friedman
From russ at q12.org Tue Oct 15 16:32:02 2002
From: russ at q12.org (Russ Smith)
Date: Tue Oct 15 16:32:02 2002
Subject: [ODE] RE: Wheel rotation problem
In-Reply-To: <008601c27492$2ed71510$5c02a8c0@peter>
Message-ID:
> > (russ/ode_users?) Why is it not possible to totally stop the hinge2
> > 'axles' becoming 'bent' ?
well, anything is possible :) the question is, why does it happen in the
first place. here's the answer:
ODE stores the position and orientation of each body independently. if
there is any error in the integration step then it is possible for the
bodies to be in positions/orientations where the joints do not line up
properly (i call this 'joint error', it is the same thing as the wheels
getting bent in hinge2). there are many sources of joint error, but the
surest way to introduce error is to have two or more jointed bodies that
are rotating very fast with respect to each other. this is because the
physics model and the integrator use certain linear assumptions about the
way that bodies will move during a time step - if the bodies are rotating
so fast that the new configuration at the end of the step is completely
different, then these linear assumptions are just plain wrong (and the
bodies will not be moved to the correct places).
this is a problem that afflicts all 'cartesian coordinate' or 'lagrange
multiplier based' simulators. reduced coordinate simulators like dynamecth
dont have this problem (for the bodies along the main tree), because the
coordinate system they use simply doesn't allow for the possibility that
the bodies will not be aligned correctly (the same problem will occurr
when you close any loops however).
ODE has a partial fix for this problem, which
is the dBodySetFiniteRotationAxis() function and friends. but note that
this is an exercise in error reduction, not error elimination - it will
increase the speed at which a vechicle can be reliably made to move.
for *very* fast moving vehicles where the wheels rotate a large proportion
of one cycle per timestep, completely eliminating the error is going to
require a lot of fiddling.
another approach for simulating wheels is to 'fake them' or 'raycast them'
- these approaches are effective for computer games, because the
difference between 'perfect physics' and 'physics that is completely
wrong' is not generally noticeable to the player (or even to an
experienced physicist). the only caveat here is that with increasing
physical realism comes the chance for better emergent (and/or synergistic)
behavior coming out of the simulation. you have to be careful that you
are not faking so much that your resulting behavior is little better than
hard-coded animation.
will ODE support these methods in the future? it's possible.
russ.
--
Russ Smith
http://www.q12.org/
From coding at natew.com Tue Oct 15 19:18:02 2002
From: coding at natew.com (Nate W)
Date: Tue Oct 15 19:18:02 2002
Subject: [ODE] VStudioNet
In-Reply-To: <3DACA09A.50505@fie.us>
Message-ID:
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
Send mail to mime@docserver.cac.washington.edu for more info.
--1363170581-1485151701-1034706356=:21665
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Tue, 15 Oct 2002, Brad Friedman wrote:
> When I changed the preprocessor directive from dDOUBLE to dSINGLE, it
> stopped compiling correctly. A little work brought me to a section of
> code regarding HUGE_VAL and HUGE_VALF. I then relized the project file
> did not have a "MSVC" preprocessor directive and therefore was trying to
> compile incorrectly.
That would be my mistake. I was using dDOUBLE until I started using the
tri-collider extension, and after I found the MSVC problem with the TC
project, I neglected to also fix it in the non-TC project file.
I've attached a .vcproj file that takes care of this. Russ, could you
add it to the CVS, under contrib/MSVC7/ode_default, replacing the existing
file?
Thanks, guys.
--
Nate Waddoups
Redmond WA USA
http://www.natew.com
--1363170581-1485151701-1034706356=:21665
Content-Type: TEXT/PLAIN; charset=US-ASCII; name="default.vcproj"
Content-Transfer-Encoding: BASE64
Content-ID:
Content-Description:
Content-Disposition: attachment; filename="default.vcproj"
PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZyA9ICJXaW5kb3dzLTEyNTIi
Pz4NDQo8VmlzdWFsU3R1ZGlvUHJvamVjdA0NCglQcm9qZWN0VHlwZT0iVmlz
dWFsIEMrKyINDQoJVmVyc2lvbj0iNy4wMCINDQoJTmFtZT0ib2RlX2RlZmF1
bHQiDQ0KCVByb2plY3RHVUlEPSJ7MUJGNzVGRUItODdERC00ODZDLTg4MEIt
MjI3OTg3RDE5MUMyfSINDQoJS2V5d29yZD0iQXRsUHJvaiI+DQ0KCTxQbGF0
Zm9ybXM+DQ0KCQk8UGxhdGZvcm0NDQoJCQlOYW1lPSJXaW4zMiIvPg0NCgk8
L1BsYXRmb3Jtcz4NDQoJPENvbmZpZ3VyYXRpb25zPg0NCgkJPENvbmZpZ3Vy
YXRpb24NDQoJCQlOYW1lPSJEZWJ1Z3xXaW4zMiINDQoJCQlPdXRwdXREaXJl
Y3Rvcnk9IkRlYnVnIg0NCgkJCUludGVybWVkaWF0ZURpcmVjdG9yeT0iRGVi
dWciDQ0KCQkJQ29uZmlndXJhdGlvblR5cGU9IjIiDQ0KCQkJVXNlT2ZBVEw9
IjEiDQ0KCQkJQVRMTWluaW1pemVzQ1J1blRpbWVMaWJyYXJ5VXNhZ2U9IkZB
TFNFIg0NCgkJCUNoYXJhY3RlclNldD0iMiI+DQ0KCQkJPFRvb2wNDQoJCQkJ
TmFtZT0iVkNDTENvbXBpbGVyVG9vbCINDQoJCQkJT3B0aW1pemF0aW9uPSIw
Ig0NCgkJCQlBZGRpdGlvbmFsSW5jbHVkZURpcmVjdG9yaWVzPSIuLi8uLi8u
Li9pbmNsdWRlIg0NCgkJCQlQcmVwcm9jZXNzb3JEZWZpbml0aW9ucz0iV0lO
MzI7X1dJTkRPV1M7X0RFQlVHO19VU1JETEw7ZERPVUJMRTtNU1ZDIg0NCgkJ
CQlNaW5pbWFsUmVidWlsZD0iVFJVRSINDQoJCQkJQmFzaWNSdW50aW1lQ2hl
Y2tzPSIzIg0NCgkJCQlSdW50aW1lTGlicmFyeT0iMyINDQoJCQkJVXNlUHJl
Y29tcGlsZWRIZWFkZXI9IjAiDQ0KCQkJCVdhcm5pbmdMZXZlbD0iMyINDQoJ
CQkJRGV0ZWN0NjRCaXRQb3J0YWJpbGl0eVByb2JsZW1zPSJGQUxTRSINDQoJ
CQkJRGVidWdJbmZvcm1hdGlvbkZvcm1hdD0iNCIvPg0NCgkJCTxUb29sDQ0K
CQkJCU5hbWU9IlZDQ3VzdG9tQnVpbGRUb29sIi8+DQ0KCQkJPFRvb2wNDQoJ
CQkJTmFtZT0iVkNMaW5rZXJUb29sIg0NCgkJCQlJZ25vcmVJbXBvcnRMaWJy
YXJ5PSJUUlVFIg0NCgkJCQlPdXRwdXRGaWxlPSIkKE91dERpcikvb2RlLmRs
bCINDQoJCQkJTGlua0luY3JlbWVudGFsPSIyIg0NCgkJCQlNb2R1bGVEZWZp
bml0aW9uRmlsZT0iLi5cLi5cLi5cY29uZmlnXG1zdmNkZWZzLmRlZiINDQoJ
CQkJR2VuZXJhdGVEZWJ1Z0luZm9ybWF0aW9uPSJUUlVFIg0NCgkJCQlTdWJT
eXN0ZW09IjIiDQ0KCQkJCUltcG9ydExpYnJhcnk9IiQoT3V0RGlyKS9vZGUu
bGliIg0NCgkJCQlUYXJnZXRNYWNoaW5lPSIxIi8+DQ0KCQkJPFRvb2wNDQoJ
CQkJTmFtZT0iVkNNSURMVG9vbCINDQoJCQkJUHJlcHJvY2Vzc29yRGVmaW5p
dGlvbnM9Il9ERUJVRyINDQoJCQkJTWtUeXBMaWJDb21wYXRpYmxlPSJGQUxT
RSINDQoJCQkJVGFyZ2V0RW52aXJvbm1lbnQ9IjEiDQ0KCQkJCUdlbmVyYXRl
U3R1Ymxlc3NQcm94aWVzPSJUUlVFIg0NCgkJCQlUeXBlTGlicmFyeU5hbWU9
IiQoSW50RGlyKS9kZWZhdWx0LnRsYiINDQoJCQkJSGVhZGVyRmlsZU5hbWU9
ImRlZmF1bHQuaCINDQoJCQkJRExMRGF0YUZpbGVOYW1lPSIiDQ0KCQkJCUlu
dGVyZmFjZUlkZW50aWZpZXJGaWxlTmFtZT0iZGVmYXVsdF9pLmMiDQ0KCQkJ
CVByb3h5RmlsZU5hbWU9ImRlZmF1bHRfcC5jIi8+DQ0KCQkJPFRvb2wNDQoJ
CQkJTmFtZT0iVkNQb3N0QnVpbGRFdmVudFRvb2wiDQ0KCQkJCURlc2NyaXB0
aW9uPSJQZXJmb3JtaW5nIHJlZ2lzdHJhdGlvbiINDQoJCQkJQ29tbWFuZExp
bmU9InJlZ3N2cjMyIC9zIC9jICZxdW90OyQoVGFyZ2V0UGF0aCkmcXVvdDsi
DQ0KCQkJCUV4Y2x1ZGVkRnJvbUJ1aWxkPSJUUlVFIi8+DQ0KCQkJPFRvb2wN
DQoJCQkJTmFtZT0iVkNQcmVCdWlsZEV2ZW50VG9vbCIvPg0NCgkJCTxUb29s
DQ0KCQkJCU5hbWU9IlZDUHJlTGlua0V2ZW50VG9vbCIvPg0NCgkJCTxUb29s
DQ0KCQkJCU5hbWU9IlZDUmVzb3VyY2VDb21waWxlclRvb2wiDQ0KCQkJCVBy
ZXByb2Nlc3NvckRlZmluaXRpb25zPSJfREVCVUciDQ0KCQkJCUN1bHR1cmU9
IjEwMzMiDQ0KCQkJCUFkZGl0aW9uYWxJbmNsdWRlRGlyZWN0b3JpZXM9IiQo
SW50RGlyKSIvPg0NCgkJCTxUb29sDQ0KCQkJCU5hbWU9IlZDV2ViU2Vydmlj
ZVByb3h5R2VuZXJhdG9yVG9vbCIvPg0NCgkJCTxUb29sDQ0KCQkJCU5hbWU9
IlZDV2ViRGVwbG95bWVudFRvb2wiLz4NDQoJCTwvQ29uZmlndXJhdGlvbj4N
DQoJCTxDb25maWd1cmF0aW9uDQ0KCQkJTmFtZT0iUmVsZWFzZXxXaW4zMiIN
DQoJCQlPdXRwdXREaXJlY3Rvcnk9IlJlbGVhc2UiDQ0KCQkJSW50ZXJtZWRp
YXRlRGlyZWN0b3J5PSJSZWxlYXNlIg0NCgkJCUNvbmZpZ3VyYXRpb25UeXBl
PSIyIg0NCgkJCVVzZU9mQVRMPSIxIg0NCgkJCUFUTE1pbmltaXplc0NSdW5U
aW1lTGlicmFyeVVzYWdlPSJGQUxTRSINDQoJCQlDaGFyYWN0ZXJTZXQ9IjIi
Pg0NCgkJCTxUb29sDQ0KCQkJCU5hbWU9IlZDQ0xDb21waWxlclRvb2wiDQ0K
CQkJCUlubGluZUZ1bmN0aW9uRXhwYW5zaW9uPSIxIg0NCgkJCQlBZGRpdGlv
bmFsSW5jbHVkZURpcmVjdG9yaWVzPSIuLi8uLi8uLi9pbmNsdWRlIg0NCgkJ
CQlQcmVwcm9jZXNzb3JEZWZpbml0aW9ucz0iV0lOMzI7X1dJTkRPV1M7TkRF
QlVHO19VU1JETEw7ZFNJTkdMRTtNU1ZDIg0NCgkJCQlTdHJpbmdQb29saW5n
PSJUUlVFIg0NCgkJCQlSdW50aW1lTGlicmFyeT0iMiINDQoJCQkJRW5hYmxl
RnVuY3Rpb25MZXZlbExpbmtpbmc9IlRSVUUiDQ0KCQkJCVVzZVByZWNvbXBp
bGVkSGVhZGVyPSIwIg0NCgkJCQlXYXJuaW5nTGV2ZWw9IjMiDQ0KCQkJCURl
dGVjdDY0Qml0UG9ydGFiaWxpdHlQcm9ibGVtcz0iRkFMU0UiDQ0KCQkJCURl
YnVnSW5mb3JtYXRpb25Gb3JtYXQ9IjMiLz4NDQoJCQk8VG9vbA0NCgkJCQlO
YW1lPSJWQ0N1c3RvbUJ1aWxkVG9vbCIvPg0NCgkJCTxUb29sDQ0KCQkJCU5h
bWU9IlZDTGlua2VyVG9vbCINDQoJCQkJSWdub3JlSW1wb3J0TGlicmFyeT0i
VFJVRSINDQoJCQkJT3V0cHV0RmlsZT0iJChPdXREaXIpL29kZS5kbGwiDQ0K
CQkJCUxpbmtJbmNyZW1lbnRhbD0iMSINDQoJCQkJTW9kdWxlRGVmaW5pdGlv
bkZpbGU9Ii4uXC4uXC4uXGNvbmZpZ1xtc3ZjZGVmcy5kZWYiDQ0KCQkJCUdl
bmVyYXRlRGVidWdJbmZvcm1hdGlvbj0iRkFMU0UiDQ0KCQkJCVN1YlN5c3Rl
bT0iMiINDQoJCQkJSW1wb3J0TGlicmFyeT0iJChPdXREaXIpL29kZS5saWIi
DQ0KCQkJCVRhcmdldE1hY2hpbmU9IjEiLz4NDQoJCQk8VG9vbA0NCgkJCQlO
YW1lPSJWQ01JRExUb29sIg0NCgkJCQlQcmVwcm9jZXNzb3JEZWZpbml0aW9u
cz0iTkRFQlVHIg0NCgkJCQlNa1R5cExpYkNvbXBhdGlibGU9IkZBTFNFIg0N
CgkJCQlUYXJnZXRFbnZpcm9ubWVudD0iMSINDQoJCQkJR2VuZXJhdGVTdHVi
bGVzc1Byb3hpZXM9IlRSVUUiDQ0KCQkJCVR5cGVMaWJyYXJ5TmFtZT0iJChJ
bnREaXIpL2RlZmF1bHQudGxiIg0NCgkJCQlIZWFkZXJGaWxlTmFtZT0iZGVm
YXVsdC5oIg0NCgkJCQlETExEYXRhRmlsZU5hbWU9IiINDQoJCQkJSW50ZXJm
YWNlSWRlbnRpZmllckZpbGVOYW1lPSJkZWZhdWx0X2kuYyINDQoJCQkJUHJv
eHlGaWxlTmFtZT0iZGVmYXVsdF9wLmMiLz4NDQoJCQk8VG9vbA0NCgkJCQlO
YW1lPSJWQ1Bvc3RCdWlsZEV2ZW50VG9vbCINDQoJCQkJRGVzY3JpcHRpb249
IlBlcmZvcm1pbmcgcmVnaXN0cmF0aW9uIg0NCgkJCQlDb21tYW5kTGluZT0i
cmVnc3ZyMzIgL3MgL2MgJnF1b3Q7JChUYXJnZXRQYXRoKSZxdW90OyINDQoJ
CQkJRXhjbHVkZWRGcm9tQnVpbGQ9IlRSVUUiLz4NDQoJCQk8VG9vbA0NCgkJ
CQlOYW1lPSJWQ1ByZUJ1aWxkRXZlbnRUb29sIi8+DQ0KCQkJPFRvb2wNDQoJ
CQkJTmFtZT0iVkNQcmVMaW5rRXZlbnRUb29sIi8+DQ0KCQkJPFRvb2wNDQoJ
CQkJTmFtZT0iVkNSZXNvdXJjZUNvbXBpbGVyVG9vbCINDQoJCQkJUHJlcHJv
Y2Vzc29yRGVmaW5pdGlvbnM9Ik5ERUJVRyINDQoJCQkJQ3VsdHVyZT0iMTAz
MyINDQoJCQkJQWRkaXRpb25hbEluY2x1ZGVEaXJlY3Rvcmllcz0iJChJbnRE
aXIpIi8+DQ0KCQkJPFRvb2wNDQoJCQkJTmFtZT0iVkNXZWJTZXJ2aWNlUHJv
eHlHZW5lcmF0b3JUb29sIi8+DQ0KCQkJPFRvb2wNDQoJCQkJTmFtZT0iVkNX
ZWJEZXBsb3ltZW50VG9vbCIvPg0NCgkJPC9Db25maWd1cmF0aW9uPg0NCgk8
L0NvbmZpZ3VyYXRpb25zPg0NCgk8RmlsZXM+DQ0KCQk8RmlsdGVyDQ0KCQkJ
TmFtZT0iU291cmNlIEZpbGVzIg0NCgkJCUZpbHRlcj0iY3BwO2M7Y3h4O2Rl
ZjtvZGw7aWRsO2hwajtiYXQ7YXNtIj4NDQoJCQk8RmlsZQ0NCgkJCQlSZWxh
dGl2ZVBhdGg9Ii4uXC4uXC4uXG9kZVxzcmNcV2luMzIuY3BwIj4NDQoJCQk8
L0ZpbGU+DQ0KCQkJPEZpbGUNDQoJCQkJUmVsYXRpdmVQYXRoPSIuLlwuLlwu
LlxvZGVcc3JjXGFycmF5LmNwcCI+DQ0KCQkJPC9GaWxlPg0NCgkJCTxGaWxl
DQ0KCQkJCVJlbGF0aXZlUGF0aD0iLi5cLi5cLi5cb2RlXHNyY1xlcnJvci5j
cHAiPg0NCgkJCTwvRmlsZT4NDQoJCQk8RmlsZQ0NCgkJCQlSZWxhdGl2ZVBh
dGg9Ii4uXC4uXC4uXG9kZVxzcmNcZmFzdGRvdC5jIj4NDQoJCQk8L0ZpbGU+
DQ0KCQkJPEZpbGUNDQoJCQkJUmVsYXRpdmVQYXRoPSIuLlwuLlwuLlxvZGVc
c3JjXGZhc3RsZGx0LmMiPg0NCgkJCTwvRmlsZT4NDQoJCQk8RmlsZQ0NCgkJ
CQlSZWxhdGl2ZVBhdGg9Ii4uXC4uXC4uXG9kZVxzcmNcZmFzdGxzb2x2ZS5j
Ij4NDQoJCQk8L0ZpbGU+DQ0KCQkJPEZpbGUNDQoJCQkJUmVsYXRpdmVQYXRo
PSIuLlwuLlwuLlxvZGVcc3JjXGZhc3RsdHNvbHZlLmMiPg0NCgkJCTwvRmls
ZT4NDQoJCQk8RmlsZQ0NCgkJCQlSZWxhdGl2ZVBhdGg9Ii4uXC4uXC4uXG9k
ZVxzcmNcZ2VvbS5jcHAiPg0NCgkJCTwvRmlsZT4NDQoJCQk8RmlsZQ0NCgkJ
CQlSZWxhdGl2ZVBhdGg9Ii4uXC4uXC4uXG9kZVxzcmNcam9pbnQuY3BwIj4N
DQoJCQk8L0ZpbGU+DQ0KCQkJPEZpbGUNDQoJCQkJUmVsYXRpdmVQYXRoPSIu
LlwuLlwuLlxvZGVcc3JjXGxjcC5jcHAiPg0NCgkJCTwvRmlsZT4NDQoJCQk8
RmlsZQ0NCgkJCQlSZWxhdGl2ZVBhdGg9Ii4uXC4uXC4uXG9kZVxzcmNcbWFz
cy5jcHAiPg0NCgkJCTwvRmlsZT4NDQoJCQk8RmlsZQ0NCgkJCQlSZWxhdGl2
ZVBhdGg9Ii4uXC4uXC4uXG9kZVxzcmNcbWF0LmNwcCI+DQ0KCQkJPC9GaWxl
Pg0NCgkJCTxGaWxlDQ0KCQkJCVJlbGF0aXZlUGF0aD0iLi5cLi5cLi5cb2Rl
XHNyY1xtYXRyaXguY3BwIj4NDQoJCQk8L0ZpbGU+DQ0KCQkJPEZpbGUNDQoJ
CQkJUmVsYXRpdmVQYXRoPSIuLlwuLlwuLlxvZGVcc3JjXG1lbW9yeS5jcHAi
Pg0NCgkJCTwvRmlsZT4NDQoJCQk8RmlsZQ0NCgkJCQlSZWxhdGl2ZVBhdGg9
Ii4uXC4uXC4uXG9kZVxzcmNcbWlzYy5jcHAiPg0NCgkJCTwvRmlsZT4NDQoJ
CQk8RmlsZQ0NCgkJCQlSZWxhdGl2ZVBhdGg9Ii4uXC4uXC4uXGNvbmZpZ1xt
c3ZjZGVmcy5kZWYiPg0NCgkJCTwvRmlsZT4NDQoJCQk8RmlsZQ0NCgkJCQlS
ZWxhdGl2ZVBhdGg9Ii4uXC4uXC4uXG9kZVxzcmNcb2JzdGFjay5jcHAiPg0N
CgkJCTwvRmlsZT4NDQoJCQk8RmlsZQ0NCgkJCQlSZWxhdGl2ZVBhdGg9Ii4u
XC4uXC4uXG9kZVxzcmNcb2RlLmNwcCI+DQ0KCQkJPC9GaWxlPg0NCgkJCTxG
aWxlDQ0KCQkJCVJlbGF0aXZlUGF0aD0iLi5cLi5cLi5cb2RlXHNyY1xvZGVt
YXRoLmNwcCI+DQ0KCQkJPC9GaWxlPg0NCgkJCTxGaWxlDQ0KCQkJCVJlbGF0
aXZlUGF0aD0iLi5cLi5cLi5cb2RlXHNyY1xyb3RhdGlvbi5jcHAiPg0NCgkJ
CTwvRmlsZT4NDQoJCQk8RmlsZQ0NCgkJCQlSZWxhdGl2ZVBhdGg9Ii4uXC4u
XC4uXG9kZVxzcmNcc3BhY2UuY3BwIj4NDQoJCQk8L0ZpbGU+DQ0KCQkJPEZp
bGUNDQoJCQkJUmVsYXRpdmVQYXRoPSIuLlwuLlwuLlxvZGVcc3JjXHN0ZXAu
Y3BwIj4NDQoJCQk8L0ZpbGU+DQ0KCQkJPEZpbGUNDQoJCQkJUmVsYXRpdmVQ
YXRoPSIuLlwuLlwuLlxvZGVcc3JjXHRlc3RpbmcuY3BwIj4NDQoJCQk8L0Zp
bGU+DQ0KCQkJPEZpbGUNDQoJCQkJUmVsYXRpdmVQYXRoPSIuLlwuLlwuLlxv
ZGVcc3JjXHRpbWVyLmNwcCI+DQ0KCQkJPC9GaWxlPg0NCgkJPC9GaWx0ZXI+
DQ0KCQk8RmlsdGVyDQ0KCQkJTmFtZT0iSGVhZGVyIEZpbGVzIg0NCgkJCUZp
bHRlcj0iaDtocHA7aHh4O2htO2lubDtpbmMiPg0NCgkJCTxGaWxlDQ0KCQkJ
CVJlbGF0aXZlUGF0aD0iLi5cLi5cLi5cb2RlXHNyY1xhcnJheS5oIj4NDQoJ
CQk8L0ZpbGU+DQ0KCQkJPEZpbGUNDQoJCQkJUmVsYXRpdmVQYXRoPSIuLlwu
LlwuLlxvZGVcc3JjXGdlb21faW50ZXJuYWwuaCI+DQ0KCQkJPC9GaWxlPg0N
CgkJCTxGaWxlDQ0KCQkJCVJlbGF0aXZlUGF0aD0iLi5cLi5cLi5cb2RlXHNy
Y1xqb2ludC5oIj4NDQoJCQk8L0ZpbGU+DQ0KCQkJPEZpbGUNDQoJCQkJUmVs
YXRpdmVQYXRoPSIuLlwuLlwuLlxvZGVcc3JjXGxjcC5oIj4NDQoJCQk8L0Zp
bGU+DQ0KCQkJPEZpbGUNDQoJCQkJUmVsYXRpdmVQYXRoPSIuLlwuLlwuLlxv
ZGVcc3JjXG1hdC5oIj4NDQoJCQk8L0ZpbGU+DQ0KCQkJPEZpbGUNDQoJCQkJ
UmVsYXRpdmVQYXRoPSIuLlwuLlwuLlxvZGVcc3JjXG9iamVjdHMuaCI+DQ0K
CQkJPC9GaWxlPg0NCgkJCTxGaWxlDQ0KCQkJCVJlbGF0aXZlUGF0aD0iLi5c
Li5cLi5cb2RlXHNyY1xvYnN0YWNrLmgiPg0NCgkJCTwvRmlsZT4NDQoJCQk8
RmlsZQ0NCgkJCQlSZWxhdGl2ZVBhdGg9Ii4uXC4uXC4uXG9kZVxzcmNcc3Rh
Y2suaCI+DQ0KCQkJPC9GaWxlPg0NCgkJCTxGaWxlDQ0KCQkJCVJlbGF0aXZl
UGF0aD0iLi5cLi5cLi5cb2RlXHNyY1xzdGVwLmgiPg0NCgkJCTwvRmlsZT4N
DQoJCQk8RmlsZQ0NCgkJCQlSZWxhdGl2ZVBhdGg9Ii4uXC4uXC4uXG9kZVxz
cmNcdGVzdGluZy5oIj4NDQoJCQk8L0ZpbGU+DQ0KCQk8L0ZpbHRlcj4NDQoJ
CTxGaWx0ZXINDQoJCQlOYW1lPSJTaGFyZWQgSGVhZGVyIEZpbGVzIg0NCgkJ
CUZpbHRlcj0iIj4NDQoJCQk8RmlsZQ0NCgkJCQlSZWxhdGl2ZVBhdGg9Ii4u
XC4uXC4uXGluY2x1ZGVcb2RlXGNvbW1vbi5oIj4NDQoJCQk8L0ZpbGU+DQ0K
CQkJPEZpbGUNDQoJCQkJUmVsYXRpdmVQYXRoPSIuLlwuLlwuLlxpbmNsdWRl
XG9kZVxjb25maWcuaCI+DQ0KCQkJPC9GaWxlPg0NCgkJCTxGaWxlDQ0KCQkJ
CVJlbGF0aXZlUGF0aD0iLi5cLi5cLi5caW5jbHVkZVxvZGVcY29udGFjdC5o
Ij4NDQoJCQk8L0ZpbGU+DQ0KCQkJPEZpbGUNDQoJCQkJUmVsYXRpdmVQYXRo
PSIuLlwuLlwuLlxpbmNsdWRlXG9kZVxlcnJvci5oIj4NDQoJCQk8L0ZpbGU+
DQ0KCQkJPEZpbGUNDQoJCQkJUmVsYXRpdmVQYXRoPSIuLlwuLlwuLlxpbmNs
dWRlXG9kZVxnZW9tLmgiPg0NCgkJCTwvRmlsZT4NDQoJCQk8RmlsZQ0NCgkJ
CQlSZWxhdGl2ZVBhdGg9Ii4uXC4uXC4uXGluY2x1ZGVcb2RlXG1hc3MuaCI+
DQ0KCQkJPC9GaWxlPg0NCgkJCTxGaWxlDQ0KCQkJCVJlbGF0aXZlUGF0aD0i
Li5cLi5cLi5caW5jbHVkZVxvZGVcbWF0cml4LmgiPg0NCgkJCTwvRmlsZT4N
DQoJCQk8RmlsZQ0NCgkJCQlSZWxhdGl2ZVBhdGg9Ii4uXC4uXC4uXGluY2x1
ZGVcb2RlXG1lbW9yeS5oIj4NDQoJCQk8L0ZpbGU+DQ0KCQkJPEZpbGUNDQoJ
CQkJUmVsYXRpdmVQYXRoPSIuLlwuLlwuLlxpbmNsdWRlXG9kZVxtaXNjLmgi
Pg0NCgkJCTwvRmlsZT4NDQoJCQk8RmlsZQ0NCgkJCQlSZWxhdGl2ZVBhdGg9
Ii4uXC4uXC4uXGluY2x1ZGVcb2RlXG9iamVjdHMuaCI+DQ0KCQkJPC9GaWxl
Pg0NCgkJCTxGaWxlDQ0KCQkJCVJlbGF0aXZlUGF0aD0iLi5cLi5cLi5caW5j
bHVkZVxvZGVcb2RlLmgiPg0NCgkJCTwvRmlsZT4NDQoJCQk8RmlsZQ0NCgkJ
CQlSZWxhdGl2ZVBhdGg9Ii4uXC4uXC4uXGluY2x1ZGVcb2RlXG9kZWNwcC5o
Ij4NDQoJCQk8L0ZpbGU+DQ0KCQkJPEZpbGUNDQoJCQkJUmVsYXRpdmVQYXRo
PSIuLlwuLlwuLlxpbmNsdWRlXG9kZVxvZGVtYXRoLmgiPg0NCgkJCTwvRmls
ZT4NDQoJCQk8RmlsZQ0NCgkJCQlSZWxhdGl2ZVBhdGg9Ii4uXC4uXC4uXGlu
Y2x1ZGVcb2RlXHJvdGF0aW9uLmgiPg0NCgkJCTwvRmlsZT4NDQoJCQk8Rmls
ZQ0NCgkJCQlSZWxhdGl2ZVBhdGg9Ii4uXC4uXC4uXGluY2x1ZGVcb2RlXHNw
YWNlLmgiPg0NCgkJCTwvRmlsZT4NDQoJCQk8RmlsZQ0NCgkJCQlSZWxhdGl2
ZVBhdGg9Ii4uXC4uXC4uXGluY2x1ZGVcb2RlXHRpbWVyLmgiPg0NCgkJCTwv
RmlsZT4NDQoJCTwvRmlsdGVyPg0NCgkJPEZpbGUNDQoJCQlSZWxhdGl2ZVBh
dGg9IlJlYWRNZS50eHQiPg0NCgkJPC9GaWxlPg0NCgk8L0ZpbGVzPg0NCgk8
R2xvYmFscz4NDQoJPC9HbG9iYWxzPg0NCjwvVmlzdWFsU3R1ZGlvUHJvamVj
dD4NDQo=
--1363170581-1485151701-1034706356=:21665--
From coding at natew.com Tue Oct 15 19:28:02 2002
From: coding at natew.com (Nate W)
Date: Tue Oct 15 19:28:02 2002
Subject: [ODE] VStudioNet
In-Reply-To:
Message-ID:
This thread has reminded me of something I've been meaning to ask... is
anyone else out there using VS.net and ODE+tri-collider? In my case, the
compiler warning messages often have the wrong line numbers, and debugging
induces big headaches fast because the debugger usually goes to the wrong
line in the source file. Is anyone else seeing this?
--
Nate Waddoups
Redmond WA USA
http://www.natew.com
From russ at q12.org Tue Oct 15 19:40:02 2002
From: russ at q12.org (Russ Smith)
Date: Tue Oct 15 19:40:02 2002
Subject: [ODE] VStudioNet
In-Reply-To:
References: <3DACA09A.50505@fie.us>
Message-ID: <20021015194355.1e9eeb85.russ@q12.org>
> I've attached a .vcproj file that takes care of this. Russ, could you
> add it to the CVS, under contrib/MSVC7/ode_default, replacing the existing
> file?
done.
russ.
--
Russell Smith
http://www.q12.org
From Tomas.Sakalauskas at axel-group.com Wed Oct 16 00:13:02 2002
From: Tomas.Sakalauskas at axel-group.com (Tomas Sakalauskas)
Date: Wed Oct 16 00:13:02 2002
Subject: [ODE] VStudioNet
Message-ID:
Yes. You have to replace CRCRLF in files with CRLF, this confuses VS.NET.
Tomas
-----Original Message-----
From: Nate W [mailto:coding@natew.com]
Sent: Tuesday, October 15, 2002 8:36 PM
To: ode@q12.org
Subject: Re: [ODE] VStudioNet
This thread has reminded me of something I've been meaning to ask... is
anyone else out there using VS.net and ODE+tri-collider? In my case, the
compiler warning messages often have the wrong line numbers, and debugging
induces big headaches fast because the debugger usually goes to the wrong
line in the source file. Is anyone else seeing this?
--
Nate Waddoups
Redmond WA USA
http://www.natew.com
_______________________________________________
ODE mailing list
ODE@q12.org
http://q12.org/mailman/listinfo/ode
From ps_yumemi at yahoo.com Wed Oct 16 00:44:02 2002
From: ps_yumemi at yahoo.com (pia dalusong)
Date: Wed Oct 16 00:44:02 2002
Subject: [ODE] networking
Message-ID: <20021016074301.19079.qmail@web40514.mail.yahoo.com>
hello
first of all thanks for replying.
I'm not using a client/server type of connection. I'm
using a peer to peer connection. This means that I
only have one program and though it may act as a
server at times it doesn't. The movements of the a
robot is calculated by the local computer and it just
sends a message containing the speed and orientation
of the mobot to the other computers. Any computer
sends a message to all the other computers connected
to the same simulation like a broadcast message.
I use ODE for practically everything even the
positioning. and yes, all the geoms and bodies are
created properly.
although yes I do have problems concerning the lag.
and i'm still working on that. any suggestions are
welcome. and all the robots exist in the same space
and world.
thanks
pia
__________________________________________________
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos & More
http://faith.yahoo.com
From johnb003 at hotmail.com Wed Oct 16 01:10:02 2002
From: johnb003 at hotmail.com (John Butterfield)
Date: Wed Oct 16 01:10:02 2002
Subject: [ODE] IRC Community
Message-ID:
If anyone is interested, I started a channel on efnet for ode... as you
might have guessed it's #ode. I encourage anyone to go there that is
interested in ode, can contribute to the community, has questions, or just
wants to say hi. I'll be hanging around there as Return0.
Thanks
-John Butterfield
If people start to show up maybe russ can mention it on his page or
something.
_________________________________________________________________
Protect your PC - get McAfee.com VirusScan Online
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
From I.Munro at herts.ac.uk Wed Oct 16 01:38:13 2002
From: I.Munro at herts.ac.uk (Ian Munro)
Date: Wed Oct 16 01:38:13 2002
Subject: [ODE] VStudioNet
Message-ID:
Nate wrote:
> This thread has reminded me of something I've been meaning to
> ask... is
> anyone else out there using VS.net and ODE+tri-collider? In
> my case, the
> compiler warning messages often have the wrong line numbers,
> and debugging
> induces big headaches fast because the debugger usually goes
> to the wrong
> line in the source file. Is anyone else seeing this?
I'm using vs.net and ode (but not tri-collider).
I've come across similar problems when debugging, but only when I've
accidentally switched on compiler optimisation. And the lines I'm trying to
debug have been optimised out of existence.
Ian
From Remko at act-3d.com Wed Oct 16 06:26:02 2002
From: Remko at act-3d.com (Remko Jacobs (act-3d.com))
Date: Wed Oct 16 06:26:02 2002
Subject: [ODE] RE: Wheel rotation problem
Message-ID: <277399354.5556039.98@server>
You can fix the viual appearance of the wheel easily though. Just use the
position from ODE, get the wheel rotation angle and create your own
rotation matrix from this angle and the matrix of the vehicle body. This
will not improve the handling of the car but at least the image looks
right :)
Note: you need to calculate the pitch rotation of the wheel yourself
because Ode can not provide this info (hint.. hint.. Russ :) ).
-Remko
From ericc at xenopi.com Wed Oct 16 10:02:02 2002
From: ericc at xenopi.com (Eric Cha)
Date: Wed Oct 16 10:02:02 2002
Subject: [ODE] networking
In-Reply-To: <20021016074301.19079.qmail@web40514.mail.yahoo.com>
Message-ID: <000001c27536$37d05880$6401a8c0@donald>
Pia,
Your problem is a bit tricky to pin down, but here is my theory:
Since you are controlling each robot separately (via different
computers), any collisions detected by a given computer have to be
transmitted (propagated) to the other computers. You didn't mention
whether or not you are transmitting collision information in your
program, but I am going to assume that you are..
So, assuming you are propagating collision info properly (although in a
peer-to-peer topology this is going to be tricky..), the other problem
may be (depending on how your network code functions) one of "lag
induced information negation".. What I mean is, computer "A" determines
a collision has occurred and transmits the info to computer "B".
However, because of lag, computer "B" transmits a new position to "A"
before receiving the collision info from "A". The new position info
from "B" then OVERRIDES the collision that "A" detected, and forces "A"
to put it's representation of "B" into the new spot. Computer "B"
finally receives the collision info, but disregards it because it
happened at a position which is not current..
This scenario assumes MANY things about your network code, so it is not
a definite answer.
A better way (for physics) to do things would be to designate one
computer as "the physics simulator". Do the entire scene simulation on
that computer, and then just transmit position/orientation/velocity
updates to other computers. Of course, other computers would transmit
user inputs (or even impulse/velocity/acceleration changes) to the
simulator computer to control their respective robot.
Don't know if that helped you or not, but that's my .02. =)
Eric
> -----Original Message-----
> From: ode-admin@q12.org [mailto:ode-admin@q12.org] On Behalf
> Of pia dalusong
> Sent: Wednesday, October 16, 2002 12:43 AM
> To: ode@q12.org
> Subject: [ODE] networking
>
>
> hello
>
> first of all thanks for replying.
> I'm not using a client/server type of connection. I'm
> using a peer to peer connection. This means that I
> only have one program and though it may act as a
> server at times it doesn't. The movements of the a
> robot is calculated by the local computer and it just
> sends a message containing the speed and orientation
> of the mobot to the other computers. Any computer
> sends a message to all the other computers connected
> to the same simulation like a broadcast message.
> I use ODE for practically everything even the
> positioning. and yes, all the geoms and bodies are
> created properly.
>
> although yes I do have problems concerning the lag.
> and i'm still working on that. any suggestions are
> welcome. and all the robots exist in the same space
> and world.
>
> thanks
>
> pia
>
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.394 / Virus Database: 224 - Release Date: 10/3/2002
From anselm at hook.org Wed Oct 16 12:10:02 2002
From: anselm at hook.org (Anselm Hook)
Date: Wed Oct 16 12:10:02 2002
Subject: [ODE] networking
In-Reply-To: <000001c27536$37d05880$6401a8c0@donald>
Message-ID:
Hi,
Eric probably has the best solution (do all the dynamics on one machine);
networking physics is a bit of an oxymoron - you have high frequency
events being propagated over a sluggish pipe.
The naive scheme is to use a heartbeat to syncronize state between
machines. Presumably if all machines are always in the same state then
any new inputs delivered to all machines simultaneously will have the same
effect. This would result in unacceptable delays however. If you are 70
ms from a server then your sim is at least 140ms delayed. Humans start to
notice delay at around 20ms and ordinary inter-continental phone
conversations become difficult with >70ms delays. Modems typically incur
a 30ms delay and even tcp packet building and buffering can incur a 10ms
delay... obviously you need a carefully chosen hack.
If you look on the net there were once a number of companies that
specialized in fast networking for games (I think most of them are
bankrupt now).
One scheme that I liked was a dual simulation scheme: There were two
instances of the simulation running - one that was current and speculative
(allowing gratifying instant feedback) and the other was an authoritative
simulation that used an ordinary heartbeat but suffered from the full
latency of the network. The current simulation was periodically (once
every tenth of a second or so) re-computed forward from the correct but
temporally old simulation. So most of the time things would work, but
every so often the actors would pop around a bit. This is probably the
best possible scheme one can hope to achieve although it does put a large
load on the client machines.
Also there is quite a bit of research at Darpa and in some of the game dev
journals about various robust networking schemes.
Another scheme (Russ once mentioned) is the idea of a networked
constraint; that maintains the force interaction between objects over a
network (hmm, sounds like quantum physics). He'd have to explain that.
Here is a trivial scheme I've used for non-dynamics networking. Your
mileage may vary - it is highly inaccurate - it simply creates a
reasonably believable 'fiction' without forcing all machines to be
syncronized or forcing the load to be computed on the server. But note
that it is a hack.
1) First one designates one instance of an object as the "authoritative
instance" and the other instances of that same object (as exist on each
separate machine) as the "ghosts" or non-authoritative instances.
2) Requests to interact with any object (in state changing ways) have to
be routed to the authoritative instance. The authoritative instance then
echoes a second message indicating result states that all ghosts should
seek to be in. (A vanilla client server network like say 'Quake'
therefore is emulated by simply having all authoritative instances reside
on the server rather than on the client leaf nodes of the network. A peer
to peer network is designed by marking non-server objects as authoritative
and forcing requests to be re-routed to that instance (often involving
network traffic)).
3) It is ok for a ghost to locally speculate about what it should do when
it receives an impact - but throw away that information when more
authoritative feedback arrives. This often results in a ghost being
translated part way into another object - this inter-penetration can
however help the simulation as will be discussed below.
So for example:
Lets pretend you have p2p network of two machines and two robots. Each
machine is going to have an instance of each robot. I like to draw out
these instance graphs using a simple c like notation - in this case it
might look like this:
network {
machine1 {
robot1 {
is_authoritative { yes }
request_impact{}
}
robot2 {
is_authoritative { no }
where_is_authority { machine2:robot2 }
request_impact{}
}
}
machine2 {
robot1 {
is_authoritative { no }
where_is_authority { machine1:robot1 }
request_impact{}
}
robot2 {
is_authoritative { yes }
request_impact{}
}
}
}
Any requests to apply forces to an object get sent to the authority first
and the authority echoes out a real force to apply. A ghost is treated
like a statue; it simply doesn't move right away when you hit it.
An elaboration of this would be to allow ghosts to be simulated normally
but for the authority to transmit all authoritative state (position,
current forces) to all ghosts after each new force. This would result in
inter-penetration as ghosts were popped to new locations... but has worked
ok for me in the past. I would even propagate extremely high level events
such as "cross bridge" and allow each ghost to fulfill the event as it
wished - creating often quite different but plausibly believable fictions.
Anyway, as I said, your mileage may vary - it really depends on what
you're trying to do. If you simply can't afford to compute the simulation
twice, and if all you care about is some reasonably believable
non-diverging physics then this might be acceptable - it is certainly good
enough for most games. Today I'd probably use something more robust
myself though.
Hmmm, I wonder what a networked version of 'Juice' would be like. Robot
wars anybody? :-).
- a
On Wed, 16 Oct 2002, Eric Cha wrote:
> Pia,
>
> Your problem is a bit tricky to pin down, but here is my theory:
>
> Since you are controlling each robot separately (via different
> computers), any collisions detected by a given computer have to be
> transmitted (propagated) to the other computers. You didn't mention
> whether or not you are transmitting collision information in your
> program, but I am going to assume that you are..
>
> So, assuming you are propagating collision info properly (although in a
> peer-to-peer topology this is going to be tricky..), the other problem
> may be (depending on how your network code functions) one of "lag
> induced information negation".. What I mean is, computer "A" determines
> a collision has occurred and transmits the info to computer "B".
> However, because of lag, computer "B" transmits a new position to "A"
> before receiving the collision info from "A". The new position info
> from "B" then OVERRIDES the collision that "A" detected, and forces "A"
> to put it's representation of "B" into the new spot. Computer "B"
> finally receives the collision info, but disregards it because it
> happened at a position which is not current..
>
> This scenario assumes MANY things about your network code, so it is not
> a definite answer.
>
> A better way (for physics) to do things would be to designate one
> computer as "the physics simulator". Do the entire scene simulation on
> that computer, and then just transmit position/orientation/velocity
> updates to other computers. Of course, other computers would transmit
> user inputs (or even impulse/velocity/acceleration changes) to the
> simulator computer to control their respective robot.
>
> Don't know if that helped you or not, but that's my .02. =)
>
> Eric
>
> > -----Original Message-----
> > From: ode-admin@q12.org [mailto:ode-admin@q12.org] On Behalf
> > Of pia dalusong
> > Sent: Wednesday, October 16, 2002 12:43 AM
> > To: ode@q12.org
> > Subject: [ODE] networking
> >
> >
> > hello
> >
> > first of all thanks for replying.
> > I'm not using a client/server type of connection. I'm
> > using a peer to peer connection. This means that I
> > only have one program and though it may act as a
> > server at times it doesn't. The movements of the a
> > robot is calculated by the local computer and it just
> > sends a message containing the speed and orientation
> > of the mobot to the other computers. Any computer
> > sends a message to all the other computers connected
> > to the same simulation like a broadcast message.
> > I use ODE for practically everything even the
> > positioning. and yes, all the geoms and bodies are
> > created properly.
> >
> > although yes I do have problems concerning the lag.
> > and i'm still working on that. any suggestions are
> > welcome. and all the robots exist in the same space
> > and world.
> >
> > thanks
> >
> > pia
> >
>
>
>
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.394 / Virus Database: 224 - Release Date: 10/3/2002
>
>
> _______________________________________________
> ODE mailing list
> ODE@q12.org
> http://q12.org/mailman/listinfo/ode
>
From Brad at fie.us Wed Oct 16 13:28:02 2002
From: Brad at fie.us (Brad Friedman)
Date: Wed Oct 16 13:28:02 2002
Subject: [ODE] networking
References:
Message-ID: <3DADCC02.5050409@fie.us>
I highly recommend hopping onto www.GameDev.net and looking up articles
on dead reckoning.
In particular, I recomend this one as a start:
http://www.gamedev.net/reference/programming/features/targeting/
You can then dive down to other articles for actual code.
You'll also want to think in terms of TCP, UDP and half TCP solutions in
your networking. Half TCP solutions will likely want to guarontee order
but not receipt of packts. Or alternatively, you could guarontee
receipt but not order.
Generally speaking, you need to design a simulation from the ground up
to work with physics over the network. Its not something to add in
later. And you need to get used to the idea that the client will always
be in error. The server's representation will not be 100% accurate. It
will likely be making spontaneous changes. The clients smooth out the
changes at the user's end.
If you're designing your program for a LAN with less than 10ms lag,
thats a different story of course. But you do also need to factor in
the processing time. Its not just netoworking lag.
-Brad
From nick.mcevoy at dsto.defence.gov.au Wed Oct 16 18:03:01 2002
From: nick.mcevoy at dsto.defence.gov.au (McEvoy, Nick)
Date: Wed Oct 16 18:03:01 2002
Subject: [ODE] RE: Wheel rotation problem
Message-ID: <108E7D907871D6118B5000306E0189F82005F6@ednex504.dsto.defence.gov.au>
> Peter wrote:
>That was pretty much exactly the results I got - this problem has
>completely killed my ODE project.
That is the way I'm heading too !!! It's a damn shame cause ODE is great stuff generally ! But I'm not one to give up easily.
> Russ wrote:
>well, anything is possible :) the question is, why does it happen in the
>first place. here's the answer:
>
Thanks Russ for the nice long answer (in physics terms) but no real (good) solution (in the short term at least). :(
Any other hints on the best setup of chassis & wheel mass and dimensions (including contact params) to reduce the problem. eg. should I have heavy/light chassis, heavy/light wheels, large/small diam wheels ... I suppose it should be obvious if I think about it for a moment ... thats my problem sometimes I type (incl. my code) then think later. I'll also check my timestep size as well.
> Remko wrote:
>You can fix the viual appearance of the wheel easily though.
Yes I suppose I could fix the visual appearance ... but I don't want to do too many fake-hacks (I've already got enough) ... I like something to look and feel realistic as possible.
I'll follow what Russ said '[its an] exercise in error reduction, not error elimination' ... and keep fiddling and let you all know if I find the optimal values.
Nick
From coding at natew.com Wed Oct 16 19:40:02 2002
From: coding at natew.com (Nate W)
Date: Wed Oct 16 19:40:02 2002
Subject: [ODE] RE: Wheel rotation problem
In-Reply-To: <108E7D907871D6118B5000306E0189F82005F6@ednex504.dsto.defence.gov.au>
Message-ID:
On Thu, 17 Oct 2002, McEvoy, Nick wrote:
> Thanks Russ for the nice long answer (in physics terms) but no real
> (good) solution (in the short term at least). :(
I must admit I have very little experience using ODE to simulate a car,
but I thought he did offer a good solution... or at least he said
something that sounded to me like the beginnings of a solution to the
wheel problem: fake them.
When ODE generates contacts for the wheel-ground intersection, treat it as
a frictionless contact, so ODE just keeps things from interpenetrating
(you'll also get sideways forces if you're on a slope, which is probably
good). Then, use your own code to compute the forces that *should* be
there. ODE's friction model is pretty simple (as it should be, IMO), so if
you want a really good model of tire forces for your project, you'll end
up calculating those forces outside of ODE anyhow.
Maybe you could apply the forces directly to the wheel body - but don't
use an axle joint, instead have the wheel attached in such a way that it
moves for suspension and steering but not for rotation. You could then
apply a force at the contact point (or at the center of the contact patch,
if you wanna get sophisticated), and apply a torque where the axle would
be.
--
Nate Waddoups
Redmond WA USA
http://www.natew.com
From tetron at interreality.org Wed Oct 16 20:05:02 2002
From: tetron at interreality.org (Peter Amstutz)
Date: Wed Oct 16 20:05:02 2002
Subject: [ODE] exploding boxes
Message-ID:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
This may be a known bug -- box stacking is extremely unstable.
Specifically, I'm looking at the "phystut" program that comes with the
Crystal Space 3D engine. It uses large, flat boxes for the walls of a
room[1], and the user is able to drop boxes and spheres into the room and
watch them bounce and roll around. There are several problems:
[1] I expect the answer may be "don't do that" and while that would work
for the outer surfaces of a convex hull, it's useless for building other
things within a space.
The first one is that despite the fact that both the walls and objects
have a bounciness of zero (perfectly inelastic collisions) when an object
is dropped it tends to bounce and roll around a LOT before coming to a
stop...
... almost coming to a stop, that it. Once the object has almost settled
down, often it will suddenly pop up with a lot of force. This is clearly
an instability in the integrator, and makes it basically impossible to
stack objects on one another, which should otherwise work fine.
I'd like to see this fixed, and if no one is working on it I would be
willing to give it a shot if someone will point me in the right direction
of where to start in the code.
[ 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)
iD8DBQE9riifaeHUyhjCHfcRAlbVAKCxOv91JfnjQVdCbZ7agC/WU1UCqwCfcZ9Z
3+yvx1qbhQwLuaY05A6VqUc=
=ThXO
-----END PGP SIGNATURE-----
From russ at q12.org Wed Oct 16 21:42:02 2002
From: russ at q12.org (Russ Smith)
Date: Wed Oct 16 21:42:02 2002
Subject: [ODE] exploding boxes
In-Reply-To:
References:
Message-ID: <20021016214610.27fc7f46.russ@q12.org>
> The first one is that despite the fact that both the walls and objects
> have a bounciness of zero (perfectly inelastic collisions) when an
> object is dropped it tends to bounce and roll around a LOT before
> coming to a stop...
if you're talking about the box-stack demo, this bouncyness is
intentional. if you want no bounce, set contact[i].surface.bounce=0
in the demo.
> ... almost coming to a stop, that it. Once the object has almost
> settled down, often it will suddenly pop up with a lot of force.
are you using the latest CVS version? 0.03 is prone to popping. there
will hopefully be a new 'official' ODE release sometime soonish. if you
are experiencing popping with the CVS version, i would appreciate a test
case that illustrates this.
note that there is a box-stacking problem caused by insufficient contact
points being generated, i am also hoping to fix this up soon.
russ.
--
Russell Smith
http://www.q12.org
From ericc at xenopi.com Wed Oct 16 22:48:01 2002
From: ericc at xenopi.com (Eric Cha)
Date: Wed Oct 16 22:48:01 2002
Subject: [ODE] networking
In-Reply-To: <3DADCC02.5050409@fie.us>
Message-ID: <000601c275a1$3aeed3f0$6401a8c0@donald>
Umm, not bad advice, but the original poster did specify that he/she
purposely chose peer-to-peer, so Client-Server paradigm might not be an
option (for him)...
> -----Original Message-----
> From: ode-admin@q12.org [mailto:ode-admin@q12.org] On Behalf
> Of Brad Friedman
> Sent: Wednesday, October 16, 2002 1:29 PM
> To: ode@q12.org
> Subject: Re: [ODE] networking
>
>
> I highly recommend hopping onto www.GameDev.net and looking
> up articles
> on dead reckoning.
>
> In particular, I recomend this one as a start:
> http://www.gamedev.net/reference/programming/features/targetin
g/
You can then dive down to other articles for actual code.
You'll also want to think in terms of TCP, UDP and half TCP solutions in
your networking. Half TCP solutions will likely want to guarontee order
but not receipt of packts. Or alternatively, you could guarontee
receipt but not order.
Generally speaking, you need to design a simulation from the ground up
to work with physics over the network. Its not something to add in
later. And you need to get used to the idea that the client will always
be in error. The server's representation will not be 100% accurate. It
will likely be making spontaneous changes. The clients smooth out the
changes at the user's end.
If you're designing your program for a LAN with less than 10ms lag,
thats a different story of course. But you do also need to factor in
the processing time. Its not just netoworking lag.
-Brad
_______________________________________________
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.394 / Virus Database: 224 - Release Date: 10/3/2002
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoftick ).
Version: 6.0.394 / Virus Database: 224 - Release Date: 10/3/2002
From tetron at interreality.org Wed Oct 16 22:50:02 2002
From: tetron at interreality.org (Peter Amstutz)
Date: Wed Oct 16 22:50:02 2002
Subject: [ODE] exploding boxes
In-Reply-To: <20021016214610.27fc7f46.russ@q12.org>
Message-ID:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wed, 16 Oct 2002, Russ Smith wrote:
> if you're talking about the box-stack demo, this bouncyness is
> intentional. if you want no bounce, set contact[i].surface.bounce=0
> in the demo.
No, this is in the "phystut" program in Crystal Space. As I said, this is
a box landing on another box and not a box hitting a plane.
> are you using the latest CVS version? 0.03 is prone to popping. there
> will hopefully be a new 'official' ODE release sometime soonish. if you
> are experiencing popping with the CVS version, i would appreciate a test
> case that illustrates this.
Yes, I'm using the CVS version. Providing a simple test case is rather
complicated by the fact that it uses the Crystal Space infrastructure so
perhaps you would be best off downloading Crystal Space... I suppose I
could try to reproduce it in the box stacking test.
> note that there is a box-stacking problem caused by insufficient contact
> points being generated, i am also hoping to fix this up soon.
Hmm, okay.
[ 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)
iD8DBQE9rk9TaeHUyhjCHfcRAg2wAJ43RxDQqhzIsEzWqjd2At2nwB04ZQCeMV+l
Ft/PY6NEi9EqgpNwMHGpRg4=
=ChTm
-----END PGP SIGNATURE-----
From coding at natew.com Wed Oct 16 23:16:02 2002
From: coding at natew.com (Nate W)
Date: Wed Oct 16 23:16:02 2002
Subject: [ODE] robotic simulation
In-Reply-To: <3DA8EF87.778199E3@aist.go.jp>
Message-ID:
On Sun, 13 Oct 2002, Max Lungarella wrote:
> i tried "juice", it's pretty cool, and well designed. the only problem that i
> have with it, is that i cannot export the models i realize. in other words, it
> would be neat if i could construct something using juice, and be able to
> import this something in one of my own programs. do you have plans do add
> similar feature?
I have no such plans, but I do plan to document the file format to help
anyone interested in writing a translator or importer. I'm also looking
at the Novodex file format as a possible replacement for the XML-based
format that Juice uses now.
> ode is so easy to use and also aesthetically more pleasant ;)
I feel the same way!
--
Nate Waddoups
Redmond WA USA
http://www.natew.com
From coding at natew.com Wed Oct 16 23:20:02 2002
From: coding at natew.com (Nate W)
Date: Wed Oct 16 23:20:02 2002
Subject: [ODE] networking
In-Reply-To: <000001c27536$37d05880$6401a8c0@donald>
Message-ID:
On Wed, 16 Oct 2002, Eric Cha wrote:
> A better way (for physics) to do things would be to designate one
> computer as "the physics simulator". Do the entire scene simulation on
> that computer, and then just transmit position/orientation/velocity
> updates to other computers. Of course, other computers would transmit
> user inputs (or even impulse/velocity/acceleration changes) to the
> simulator computer to control their respective robot.
I hope you all don't mind too much my attempt to hijack this thread and
turn it into a discussion of networked physics in general. :-)
Having a single computer be "the" simulator solves a lot of problems, and
in many cases would be the best solution. A co-worker and I did a
multi-user simulation this way a few years ago and it worked well. (We
didn't have physics to worry about, but we did have related issues with
maintaining coherent world states on all of the 'client' machines.)
The thing that makes me want to avoid that model today is that physics
takes a lot of CPU power. Every client brings a fast CPU to the party...
if there's a way to make use of that power, many clients together could be
able to do much more complex simulations than a single server (or rather,
"more complex that the server *I* can afford"). Ideally, it gets a lot
cheaper to scale the system to support more users, becase each user brings
enough CPU power to do their share of the computation. Practically it
will never be quite that scalable, but I still like the idea.
If you can have each client simulate the parts of the player's body or
vehicle, then broadcast the positions and orientations, the server's CPU
requirements go down quite a bit. Note that I'm assuming a game sort of
paradigm here, but other scenarios could use other methods of assigning
objects to CPUs.
I'd elaborate, but I see that Anselm has already described something like
what I had in mind, only better. :-)
--
Nate Waddoups
Redmond WA USA
http://www.natew.com
From amoravanszky at dplanet.ch Thu Oct 17 02:14:02 2002
From: amoravanszky at dplanet.ch (amoravanszky@dplanet.ch)
Date: Thu Oct 17 02:14:02 2002
Subject: [ODE] robotic simulation
Message-ID: <200210170913.g9H9DQx22252@dubb05h07-0.dplanet.ch>
Nate W wrote:
> I have no such plans, but I do plan to document the file format to help
> anyone interested in writing a translator or importer. I'm also looking
> at the Novodex file format as a possible replacement for the XML-based
> format that Juice uses now.
Nate,
just in case you are wondering, you are welcome to use our file format not
only for NovodeX related functionality, but also as a generic physics scene
description format also used in conjunction with ODE. We at NovodeX think
the entire community, regardless of which physics SDK is used, would benefit
from a file format that is an open standard. In particular we are open to file format extensions as required by Juice -- though of course we should debate
them first.
BTW: The file format description is available as part of the NovodeX Steel
SDK download here:
http://www.novodex.com/downloads/steel-personal.exe
Note that you don't have to buy the SDK to be able to read the documentation
or use the viewer/exporters.
-- Adam Moravanszky
/*================*\
|Chief Software Architect
|NovodeX AG
|physics middleware
|www.novodex.com
\*================*/
From Remko at act-3d.com Thu Oct 17 02:41:01 2002
From: Remko at act-3d.com (Remko Jacobs (act-3d.com))
Date: Thu Oct 17 02:41:01 2002
Subject: [ODE] Another strange wheel rotation bug
Message-ID: <277472262.78464215.98@server>
I fixed the 'bending wheels' problem using the following methods. The
problem still exists but at least you can reduce it to acceptable levels:
- Decrease the step size (update of 200-300Hz)
- Different CFM and ERP values
- Different masses
- Bigger wheels (The bigger the wheels, the slower they have to turn for
the same speed)
I'm experimenting with a driving simulation and the results are stunning!
However, after some experimentation, the car started to bounce and the
handling was completely gone.
It turned out that the wheel is not rotating around it's axis but around
a point slightly above that. Gravity was causing this offset. Gravity
pulls the wheel down so the rotation axis of the hinge is too high. What
really surprised me, is the solution I found:
When I set the gravity to zero the problem does not occur (as expected).
When I crank up the gravity while the simulation is running, the bug does
not come back but the wheel rotates around the correct point. Does anyone
has an explanation for this? Why the rotation screws up when I initialize
with gravity?
-Remko
From johnb003 at hotmail.com Thu Oct 17 04:32:02 2002
From: johnb003 at hotmail.com (John Butterfield)
Date: Thu Oct 17 04:32:02 2002
Subject: [ODE] Wheel Rotation Problem
Message-ID:
Actually to be honest, I've been struggling with the wheel rotation problem
the last few days as well. I did notice a much better behaving system with
a smaller timestep as I tested out my buggy on a big open plane. Although
to get my timestep small enough I had to call update world a bunch of times,
more than I could feasibly when I have other factors in the game that slow
it down, like terrain. I have not yet thought of a solution that would work
in my case.
_________________________________________________________________
Choose an Internet access plan right for you -- try MSN!
http://resourcecenter.msn.com/access/plans/default.asp
From ericc at xenopi.com Thu Oct 17 07:41:01 2002
From: ericc at xenopi.com (Eric Cha)
Date: Thu Oct 17 07:41:01 2002
Subject: [ODE] networking
In-Reply-To:
Message-ID: <000d01c275eb$9e070620$6401a8c0@donald>
Anselm's solution is what I call the "classic" solution. It's "classic"
in the sense that I know of several games which actually use that system
(or something very similar). Just as a point of discussion, there are
several other ways to approach the problem... For example, here is what
we did with Dreadnoughts (a game which we were working on using Havok):
Dreadnoughts had/has pretty extreme physics engine requirements. It's a
first person shooter with HUGE vehicles (ever seen Stargate the movie?
Think of the flying pyramids..) We had to simulate moving structures
which were large enough so that entire Quake-style levels would fit
INSIDE of them. The player could run around inside these ships and then
go outside and run around a huge outdoor world. At the same time, the
ships themselves were moving and could battle it out with each other and
interact with full physics with the environment. All this had to take
place seamlessly. If a player was inside the ship looking out, he/she
could see the other players running/flying around the terrain and could
interact with those players..
Anyway, we found that because of memory constraints, we could not do the
"master heartbeat physics server" method (the levels were so large that
we were paging them in and out of memory as you moved around..)
Instead, we chopped the world up into regions (pretty easy as the world
was already partitioned into regions for our paging system) and
dynamically assigned client computers as the physics master simulators.
It was/is very tricky to implement, and not without problems in
implementation. However, the end result was full physics simulation of
a HUGE environment with the load being (relatively) evenly distributed
amongst participant's computers...
Eric
> -----Original Message-----
> From: ode-admin@q12.org [mailto:ode-admin@q12.org] On Behalf Of Nate W
> Sent: Wednesday, October 16, 2002 3:28 PM
> To: ode@q12.org
> Subject: RE: [ODE] networking
>
>
> On Wed, 16 Oct 2002, Eric Cha wrote:
>
> > A better way (for physics) to do things would be to designate one
> > computer as "the physics simulator". Do the entire scene
> simulation
> > on that computer, and then just transmit
> position/orientation/velocity
> > updates to other computers. Of course, other computers
> would transmit
> > user inputs (or even impulse/velocity/acceleration changes) to the
> > simulator computer to control their respective robot.
>
> I hope you all don't mind too much my attempt to hijack this
> thread and turn it into a discussion of networked physics in
> general. :-)
>
> Having a single computer be "the" simulator solves a lot of
> problems, and in many cases would be the best solution. A
> co-worker and I did a multi-user simulation this way a few
> years ago and it worked well. (We didn't have physics to
> worry about, but we did have related issues with maintaining
> coherent world states on all of the 'client' machines.)
>
> The thing that makes me want to avoid that model today is
> that physics takes a lot of CPU power. Every client brings a
> fast CPU to the party... if there's a way to make use of that
> power, many clients together could be able to do much more
> complex simulations than a single server (or rather, "more
> complex that the server *I* can afford"). Ideally, it gets a
> lot cheaper to scale the system to support more users, becase
> each user brings enough CPU power to do their share of the
> computation. Practically it will never be quite that
> scalable, but I still like the idea.
>
> If you can have each client simulate the parts of the
> player's body or vehicle, then broadcast the positions and
> orientations, the server's CPU requirements go down quite a
> bit. Note that I'm assuming a game sort of paradigm here,
> but other scenarios could use other methods of assigning
> objects to CPUs.
>
> I'd elaborate, but I see that Anselm has already described
> something like what I had in mind, only better. :-)
>
> --
>
> Nate Waddoups
> Redmond WA USA
> http://www.natew.com
>
>
>
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.394 / Virus Database: 224 - Release Date: 10/3/2002
From shaul_kedem at yahoo.com Thu Oct 17 10:22:02 2002
From: shaul_kedem at yahoo.com (Shaul Kedem)
Date: Thu Oct 17 10:22:02 2002
Subject: [ODE] High level graphics languages
Message-ID: <20021017172136.34012.qmail@web40020.mail.yahoo.com>
Hi all,
Recently there is a lot of talk about high level
languages for graphical use.
John Carmack, known for it's Doom and Quake engines,
said on the last quakecon keynote speech that his next
game will be written on a high level language, stating
that he sees such languages as the future trend.
Can anyone give me pointers / links / recommendations
about such languages?
The reason I am posting it here is that I want
(obviously) to implement ODE in such a language.
Thanks,
Shaul.
__________________________________________________
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos & More
http://faith.yahoo.com
From ericc at xenopi.com Thu Oct 17 10:39:02 2002
From: ericc at xenopi.com (Eric Cha)
Date: Thu Oct 17 10:39:02 2002
Subject: [ODE] High level graphics languages
In-Reply-To: <20021017172136.34012.qmail@web40020.mail.yahoo.com>
Message-ID: <001c01c27604$856969a0$6401a8c0@donald>
There are numerous HLSL's (High Level Shader Languages) out there.
Probably the two that are garnering the most attention (right now) are
OpenGL 2.0 and nVidia's Cg (which, if you believe nVidia, will be cross
compatible with DX9 HLSL)..
Eric
> -----Original Message-----
> From: ode-admin@q12.org [mailto:ode-admin@q12.org] On Behalf
> Of Shaul Kedem
> Sent: Thursday, October 17, 2002 10:22 AM
> To: ode@q12.org
> Subject: [ODE] High level graphics languages
>
>
> Hi all,
> Recently there is a lot of talk about high level
> languages for graphical use.
>
> John Carmack, known for it's Doom and Quake engines,
> said on the last quakecon keynote speech that his next
> game will be written on a high level language, stating
> that he sees such languages as the future trend.
>
> Can anyone give me pointers / links / recommendations
> about such languages?
>
> The reason I am posting it here is that I want
> (obviously) to implement ODE in such a language.
>
> Thanks,
> Shaul.
>
> __________________________________________________
> Do you Yahoo!?
> Faith Hill - Exclusive Performances, Videos & More
http://faith.yahoo.com _______________________________________________
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.394 / Virus Database: 224 - Release Date: 10/3/2002
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.394 / Virus Database: 224 - Release Date: 10/3/2002
From jason at 379.com Thu Oct 17 10:52:01 2002
From: jason at 379.com (J. Perkins)
Date: Thu Oct 17 10:52:01 2002
Subject: [ODE] High level graphics languages
In-Reply-To: <20021017172136.34012.qmail@web40020.mail.yahoo.com>
References: <20021017172136.34012.qmail@web40020.mail.yahoo.com>
Message-ID: <1034876397.2181.28.camel@imperius.um.us.sbphrd.com>
I think you misunderstood the interview. I believe he said that his next
game would use a high level *shader* language. I would be very surprised
indeed if iD were to release Quake4 in Python! ;)
Jason
379
On Thu, 2002-10-17 at 13:21, Shaul Kedem wrote:
> John Carmack, known for it's Doom and Quake engines,
> said on the last quakecon keynote speech that his next
> game will be written on a high level language, stating
> that he sees such languages as the future trend.
From ivan.bolcina at volja.net Thu Oct 17 12:40:02 2002
From: ivan.bolcina at volja.net (Ivan Bolcina)
Date: Thu Oct 17 12:40:02 2002
Subject: [ODE] 3d world an directx
Message-ID: <013401c27614$d4c0bde0$0100a8c0@vectra>
This is a multi-part message in MIME format.
------=_NextPart_000_0131_01C27625.97E1A450
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Problems.
Is ode 3d world different from DirectXs? It seems to me that y and z =
axes are swapt.
bye,ivan
------=_NextPart_000_0131_01C27625.97E1A450
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
=
Problems.
Is ode 3d world different from =
DirectXs? It seems=20
to me that y and z axes are swapt.
bye,ivan
------=_NextPart_000_0131_01C27625.97E1A450--
From russ at q12.org Thu Oct 17 15:23:02 2002
From: russ at q12.org (Russ Smith)
Date: Thu Oct 17 15:23:02 2002
Subject: [ODE] i will speak at IndieGamesCon'02
Message-ID:
FYI,
i will be speaking about ODE at IndieGamesCon'02 (www.indiegamescon.com),
on saturday november 2nd in eugene, oregon. i'll be talking about the
following topics:
* ODE's application to the game industry - particularly its relevance to
the indie game developer.
* the technology behind ODE.
* how/where ODE has been used.
* pros and cons of using ODE (and other dynamics toolkits) for
various kinds of games and VR environments. i will talk about vehicles
at length.
* alternatives to ODE - free and commercial.
* the future of dynamics/simulation.
* challenges for the [indie] game industry.
* other interesting topics that occur to me, or that are suggested.
my presentation will be up on q12.org sometime before or after the
conference.
russ.
--
Russ Smith
http://www.q12.org/
From coding at natew.com Thu Oct 17 20:30:02 2002
From: coding at natew.com (Nate W)
Date: Thu Oct 17 20:30:02 2002
Subject: [ODE] VStudioNet
In-Reply-To:
Message-ID:
On Wed, 16 Oct 2002, Tomas Sakalauskas wrote:
> > [...] debugging induces big headaches fast because the debugger
> > usually goes to the wrong line in the source file. Is anyone else
> > seeing this?
>
> Yes. You have to replace CRCRLF in files with CRLF, this confuses VS.NET.
That fixes it. I thank you a thousand times. :-)
--
Nate Waddoups
Redmond WA USA
http://www.natew.com
From tetron at interreality.org Thu Oct 17 22:52:02 2002
From: tetron at interreality.org (Peter Amstutz)
Date: Thu Oct 17 22:52:02 2002
Subject: [ODE] box stacking instability
Message-ID:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I've noticed that the "boxstack" test is unstable as well, although not to
the degree that the test program I'm using does. If one box comes to rest
on another, while it doesn't pop up (as in this other demo) it does appear
to vibrate and will move about -- I presume this is due to impulses
correcting for penetration of the top box into the lower box.
I'm talked to a professor who knows something about dynamics systems, and
his understanding is that the impulse-based method in inherently unstable
in this configuration -- using this algorithm it is almost impossible for
the system to come to equilibrium. This seems to be an enormous problem,
and one which makes ODE rather useless for my purposes. It looks like I
shall have to just use collision detection with some basic physics hacked
on... I need for it to be possible for objects to be supported by others,
such as platforms on which other objects rest. It seems that ODE handles
the case of stability on a plane quite well, but that is rather limited
use compared to the general case :-(
On a side note, the same professor mentioned the Arachi dynamics engine
(www.arachi.com). It's commercial and exceedingly expensive ($30,000) but
he speaks very highly of it. It would be interesting to potentially adopt
some of their techniques...
[ 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)
iD8DBQE9r6FUaeHUyhjCHfcRAkJvAJsHkWstAZ1s9//kp6XfUEizoDzidgCggLVp
jxxJXvtNwBkgQGNxF+ESZwk=
=B4Ld
-----END PGP SIGNATURE-----
From coding at natew.com Thu Oct 17 23:25:02 2002
From: coding at natew.com (Nate W)
Date: Thu Oct 17 23:25:02 2002
Subject: [ODE] box stacking instability
In-Reply-To:
Message-ID:
On Fri, 18 Oct 2002, Peter Amstutz wrote:
> If one box comes to rest on another, while it doesn't pop up (as in
> this other demo) it does appear to vibrate and will move about -- I
> presume this is due to impulses correcting for penetration of the top
> box into the lower box.
> I'm talked to a professor who knows something about dynamics systems, and
> his understanding is that the impulse-based method in inherently
> unstable in this configuration [...]
As Russ said, the real problem is that the box-box collision detection
code is not yet finished.
If you search the mailing list archives, you'll find that this is a known
problem, it is a solvable problem, and it will be fixed.
> It seems that ODE handles the case of stability on a plane quite well,
> but that is rather limited use compared to the general case :-(
Yes, boxes can rest on planes in a perfectly stable manner. When a box
lies flat on a plane, the box-plane collision code generates three contact
constraints, so the box is held in place.
In my own application, I had the same problem with box-plane contact - not
because of a problem with ODE, but because of a mistake on my part. My
code was only keeping the first of up to three contact constraints that
would be generated when a box contacted a plane. The result was identical
to the behavior that you see now with box-box collision detection. When I
fixed my code to use all three contacts, the 'boiling' effect went away
completely.
I have no doubt that boxes will rest on other boxes when the box-box
collision code returns three contact constraints when boxes are touching
in a face-to-face configuration. It works for boxes on planes now, it
will work for boxes on boxes eventually.
--
Nate Waddoups
Redmond WA USA
http://www.natew.com
From p.terdiman at wanadoo.fr Thu Oct 17 23:36:02 2002
From: p.terdiman at wanadoo.fr (Pierre Terdiman)
Date: Thu Oct 17 23:36:02 2002
Subject: [ODE] box stacking instability
References:
Message-ID: <046e01c27670$422f3540$0e00000a@pierre>
> I've noticed that the "boxstack" test is unstable as well, although not to
> the degree that the test program I'm using does. If one box comes to rest
> on another, while it doesn't pop up (as in this other demo) it does appear
> to vibrate and will move about -- I presume this is due to impulses
> correcting for penetration of the top box into the lower box.
>
> I'm talked to a professor who knows something about dynamics systems, and
> his understanding is that the impulse-based method in inherently unstable
> in this configuration -- using this algorithm it is almost impossible for
> the system to come to equilibrium. This seems to be an enormous problem,
> and one which makes ODE rather useless for my purposes. It looks like I
> shall have to just use collision detection with some basic physics hacked
> on... I need for it to be possible for objects to be supported by others,
> such as platforms on which other objects rest. It seems that ODE handles
> the case of stability on a plane quite well, but that is rather limited
> use compared to the general case :-(
The boxstack test is unstable because the collision detection routine
reports a single contact point, period.
Pierre
From russ at q12.org Fri Oct 18 00:03:02 2002
From: russ at q12.org (Russ Smith)
Date: Fri Oct 18 00:03:02 2002
Subject: [ODE] box stacking instability
In-Reply-To:
References:
Message-ID: <20021018000754.21ea5baa.russ@q12.org>
> I presume this is due to impulses
> correcting for penetration of the top box into the lower box.
actually, ODE does not use impulse based methods.
> On a side note, the same professor mentioned the Arachi dynamics
> engine(www.arachi.com). It's commercial and exceedingly expensive
> ($30,000) but he speaks very highly of it. It would be interesting to
> potentially adopt some of their techniques...
hmmm ... the web site gives no clues about the techniques (or about
anything, really). does anyone know what arachi is doing?
russ.
--
Russell Smith
http://www.q12.org
From mimodene at yahoo.com Fri Oct 18 01:14:01 2002
From: mimodene at yahoo.com (mica modenese)
Date: Fri Oct 18 01:14:01 2002
Subject: [ODE] beginnersproblem with ode: stack overflow
Message-ID: <20021018081342.89297.qmail@web10903.mail.yahoo.com>
hi all.
i am kind of new to this and so my question might be
rather silly. I've been using ODE for 1 week for a
biped robot simulation. now my biped consists of 52
bodies 27 hinge joints, 14 prismatic joints and 28
balljoints and 4 contactmodels. now it keeps crashing,
telling something about stack overflow and increasing
the stacksize (/F in VC++) doesn't seem to work, ODE
is allready allocating maxsize for the stack ? before
i fry my brain: am i asking to much ?? do i have to
reduce bodies and joints ??
thx mike
__________________________________________________
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos & More
http://faith.yahoo.com
From coding at natew.com Fri Oct 18 02:13:02 2002
From: coding at natew.com (Nate W)
Date: Fri Oct 18 02:13:02 2002
Subject: [ODE] beginnersproblem with ode: stack overflow
In-Reply-To: <20021018081342.89297.qmail@web10903.mail.yahoo.com>
Message-ID:
With that many joints, you'll need LOTS of stack. Juice has about 8
megabytes of stack, and I suspect that the structure you're building would
overflow Juice's stack.
With VS.Net, the linker option I'm using is /STACK:8000000 but maybe it's
/F with earlier versions? I dunno.
Anyhow, try or 10 megs or so, then double it if your app still crashes
with a stack overflow. Then double it again if need be, and so on until
it stops crashing. Expect a rather slow frame rate, too... it's going to
take a lot of number crunching to make all those joints work.
If you can generate a picture of your biped, I hope you will share it.
It sounds pretty interesting. :-)
On Fri, 18 Oct 2002, mica modenese wrote:
> i am kind of new to this and so my question might be
> rather silly. I've been using ODE for 1 week for a
> biped robot simulation. now my biped consists of 52
> bodies 27 hinge joints, 14 prismatic joints and 28
> balljoints and 4 contactmodels. now it keeps crashing,
> telling something about stack overflow and increasing
> the stacksize (/F in VC++) doesn't seem to work, ODE
> is allready allocating maxsize for the stack ? before
> i fry my brain: am i asking to much ?? do i have to
> reduce bodies and joints ??
From thubba at gmx.net Fri Oct 18 02:52:02 2002
From: thubba at gmx.net (Michael Scharvogel)
Date: Fri Oct 18 02:52:02 2002
Subject: [ODE] a newbies question on hinge and robot legs...
Message-ID: <020c01c2768b$d87d7eb0$c36abb84@tig>
This is a multi-part message in MIME format.
------=_NextPart_000_0209_01C2769C.9BB0DBB0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi folks...
I started working with ODE some time ago. But I encounter some problems =
on understanding the manual and all the "how to model my stuff witrh =
ode" subject.
Thus I will briefly describe my problem. Maybe someone can comment on =
that:
I want to model some kind of bug robot.For the start, it shall have the =
follwoing structure:
H : hinge
T : Thorax (CCylinder)
L : Leg (Box)
L H L H TTT H L H L
TTT
TTT
L H L H TTT H L H L
TTT
TTT
L H L H TTT H L H L
(One Body, six legs, each leg consisting of two parts and connected by =
two hinges)
In the final state I'd like to say something like:
Hinge 1 bow 10 degrees.
So do I have to attach Motors to the hinges to achiev this (I did not =
quiet figure out how this could work) or do I have to use these =
Transform geometries and rotate them (I I understood them right they can =
be used to rotate for example a leg around one of its ends)
Well, you see, I not quiet used to the subject. But maybe someone could =
help me getting it :-)
Perhaps someone has done something liek that, or someone could provide =
me some example code...
Thanx a lot,=20
mike.
------=_NextPart_000_0209_01C2769C.9BB0DBB0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi folks...
I started working =
with ODE some=20
time ago. But I encounter some problems on understanding the manual and =
all the=20
"how to model my stuff witrh ode" subject.
Thus I will briefly =
describe my=20
problem. Maybe someone can comment on that:
I want to model some =
kind of=20
bug robot.For the start, it shall have the follwoing structure:
H :=20
hinge
T : Thorax (CCylinder)
L : Leg (Box)
L H L H TTT H L H L
=20
TTT
=20
TTT
L H L H TTT H L H L
=20
TTT
=20
TTT
L H L H TTT H L H L
(One Body, six legs, each leg consisting of two =
parts and=20
connected by two hinges)
In the final state I'd like to say something=20
like:
Hinge 1 bow 10 degrees.
So do I have to attach Motors to the hinges to =
achiev this=20
(I did not quiet figure out how this could work) or do I have to use =
these=20
Transform geometries and rotate them (I I understood them right they can =
be used=20
to rotate for example a leg around one of its ends)
Well, you see, I not quiet used to the subject. =
But maybe=20
someone could help me getting it :-)
Perhaps someone has done something liek that, or =
someone=20
could provide me some example code...
Thanx a lot,
mike.
------=_NextPart_000_0209_01C2769C.9BB0DBB0--
From mal at candomultimedia.com Fri Oct 18 06:50:02 2002
From: mal at candomultimedia.com (Malachy Duffin)
Date: Fri Oct 18 06:50:02 2002
Subject: [ODE] Introduction / Suggestions etc
Message-ID: <001801c276ad$38345a10$d834fe3e@MalLaptop>
Hello all,
Mal here from canDo Multimedia, an Irish 3D interactive development
company. We are using a lot of Shockwave 3D at the moment ( along with
the online Havok engine ) for some web games, which you can see at...
http://www.candomultimedia.com/games/demos.htm
Firstly, I don't know if many of you on the list know, but ODE will soon
be integrated as a physics option into the realtime 3D engine of the now
open sourced version of Blender ( www.blender.org ).
This is great for a number of reasons...
- It will raise the awareness of open source game related projects like
Blender and ODE.
- More developers will be keen to work on these projects
- Because Blender is cross platform, a lot of work will be carried out
to ensure that ODE is deployed on platforms that it wasn't available on
before
- ODE developers will be able to show what the engine can do online (
Blender has a web plugin )
Blender has a fairly high learning curve, but is a great prototyping
tool ( imagine designing a car, defining it's wheels / suspension / mass
etc and clicking a button to immediately let you drive it around a 3D
world for testing purposes / to let the artists play with parameters etc
).
I am looking forward to seeing a lot more content created this way! It
makes it more accessible for artists to know how to design content for
physics based games ( using proxies, compound convex objects etc for
optimisations )
One quick suggestion, from the http://q12.org/ode/ode.html website there
doesn't seem to be any updates on news, or any easy way to see examples
of content created with ODE.
A quick revamp with a gallery of examples and links to downloadable
demos would be great, as a lot more people should be checking it out
over the coming months.
Thanks for taking the time to read the post, and I look forward to
reading future postings on this mailing list.
Mal
From martin at metahuman.org Fri Oct 18 07:26:02 2002
From: martin at metahuman.org (Martin C. Martin)
Date: Fri Oct 18 07:26:02 2002
Subject: [ODE] a newbies question on hinge and robot legs...
References: <020c01c2768b$d87d7eb0$c36abb84@tig>
Message-ID: <3DB019E0.3970D42D@metahuman.org>
> Michael Scharvogel wrote:
>
> (One Body, six legs, each leg consisting of two parts and connected by
> two hinges)
>
> In the final state I'd like to say something like:
> Hinge 1 bow 10 degrees.
>
> So do I have to attach Motors to the hinges to achiev this (I did not
> quiet figure out how this could work) or do I have to use these
> Transform geometries and rotate them (I I understood them right they can
> be used to rotate for example a leg around one of its ends)
You need a motor. Transform geometries are for fixed relationships.
However, hinges come with a motor built in. The motor controls velocity,
not position, so the easiest thing is probably to set the velocity
proportional to how far off the position is. Once you've figured out your
desired velocity, call:
dJointSetHingeParam (joint, dParamVel, desired_velocity);
- Martin
From ivan.bolcina at volja.net Fri Oct 18 08:04:02 2002
From: ivan.bolcina at volja.net (Ivan Bolcina)
Date: Fri Oct 18 08:04:02 2002
Subject: [ODE] 3d world directx
Message-ID: <004801c276b7$88d9c0e0$0100a8c0@vectra>
This is a multi-part message in MIME format.
------=_NextPart_000_0045_01C276C8.4C3936F0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Yes, but every time i get/set position,direction from ode to directx =
structs, and vice versa, I have to swap y and z.
------=_NextPart_000_0045_01C276C8.4C3936F0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Yes, but every time i get/set =
position,direction=20
from ode to directx structs, and vice versa, I have to swap y and=20
z.
------=_NextPart_000_0045_01C276C8.4C3936F0--
From ericc at xenopi.com Fri Oct 18 09:46:01 2002
From: ericc at xenopi.com (Eric Cha)
Date: Fri Oct 18 09:46:01 2002
Subject: [ODE] box stacking instability
In-Reply-To: <20021018000754.21ea5baa.russ@q12.org>
Message-ID: <001c01c276c6$28703680$6401a8c0@donald>
Funny that you mention Arachi. I know the founder (Kyong Sok Chang) -
he's an old friend of mine from college. We went to Umich (go Blue!)
together (and actually got the same degree in Aerospace Engineering) I
haven't talked to K.C. in quite a while, but did run into him at the GDC
2 years back when he had just started Arachi.
I believe K.C. did his graduate (PhD) work at Stanford on computer
physics simulation, and I believe founded the company based on his
research. I haven't read over his research, but you might want to do a
search of academic papers using his name to see what you might come up
with.
I *would* drop K.C. a line, but as I said, I haven't talked to him in
quite a while, and to be honest, I would feel quite awkward asking him
about his technology when I have no interest in it whatsoever (because
we have our own solution which is working at a satisfactory level).
Eric
> > On a side note, the same professor mentioned the Arachi dynamics
> > engine(www.arachi.com). It's commercial and exceedingly expensive
> > ($30,000) but he speaks very highly of it. It would be
> interesting to
> > potentially adopt some of their techniques...
>
> hmmm ... the web site gives no clues about the techniques (or
> about anything, really). does anyone know what arachi is doing?
>
> russ.
>
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.394 / Virus Database: 224 - Release Date: 10/3/2002
From russ at q12.org Fri Oct 18 10:06:01 2002
From: russ at q12.org (Russ Smith)
Date: Fri Oct 18 10:06:01 2002
Subject: [ODE] Introduction / Suggestions etc
In-Reply-To: <001801c276ad$38345a10$d834fe3e@MalLaptop>
References: <001801c276ad$38345a10$d834fe3e@MalLaptop>
Message-ID: <20021018100957.7ff31ceb.russ@q12.org>
> One quick suggestion, from the http://q12.org/ode/ode.html website
> there doesn't seem to be any updates on news, or any easy way to see
> examples of content created with ODE.
the 'community' section has links to some downloadable demos. as far as
'news' goes - various incremental improvements have been reported only
on the mailing list in the past months, not on the web site. i'm
gradually working towards a new release that will fix a number of
long-outstanding issues and also finally integrate some of the 'contrib'
code that has been contributed.
russ.
--
Russell Smith
http://www.q12.org
From ivan.bolcina at volja.net Fri Oct 18 10:19:02 2002
From: ivan.bolcina at volja.net (Ivan Bolcina)
Date: Fri Oct 18 10:19:02 2002
Subject: [ODE] 3d world directx -- slipch, please help
Message-ID: <002301c276ca$52d446b0$0100a8c0@vectra>
This is a multi-part message in MIME format.
------=_NextPart_000_0020_01C276DB.162787C0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi,look at this code:
//get orientation from ode and put it in my d3d Quatrernion
const dReal *qx=3D dBodyGetQuaternion (PhyBody);
D3DXQUATERNION qxx;
qxx.x=3D(float)qx[0];
qxx.y=3D(float)qx[2];
qxx.z=3D(float)qx[1];
qxx.w=3D(float)qx[3];
setOrientation(qxx); //to directx
//get positionfrom ode and put it in my D3DXVECTOR3
const dReal * p=3DdBodyGetPosition(PhyBody);
//to directx
m_Position.x=3D(float)p[0];
m_Position.y=3D(float)p[2];
m_Position.z=3D(float)p[1];
//same for velocity
const dReal * p1=3DdBodyGetLinearVel(PhyBody);=20
move.x=3D(float)p1[0];
move.y=3D(float)p1[2];
move.z=3D(float)p1[1];
//end test
//I dont understand ..... :-((( I wish to get angular rotation around =
x,y,z
//then I wish to find differece between wished angular rotation(from =
joystick) and current angular rotation
//then I wish to apply torque so they eventually mach.
const dReal * rotx=3DdBodyGetAngularVel (PhyBody);
dVector3 result;
dBodyVectorFromWorld(PhyBody, rotx[0],rotx[1],rotx[2],result);
rotate.x=3Dresult[0];
rotate.y=3Dresult[1];
rotate.z=3Dresult[2];
D3DXVECTOR3 =
rotVec=3DMaxRotate*D3DXVECTOR3(controls.axis_lr*1.0f,-controls.axis_ro*1.=
0f,-controls.axis_ud*1.0f);
rotVec-=3Drotate;
if (rotVec.x>0) rotVec.x=3DRotMax;
if (rotVec.x<0) rotVec.x=3D-RotMax;
if (rotVec.y>0) rotVec.y=3DRotMax;
if (rotVec.y<0) rotVec.y=3D-RotMax;
if (rotVec.z>0) rotVec.z=3DRotMax;
if (rotVec.z<0) rotVec.z=3D-RotMax;
dBodyAddRelTorque(PhyBody,70000.0f*rotVec.x,70000.0f*rotVec.y,70000.0f*ro=
tVec.z);
//force which heads me forward, move is current movement, posp is wished =
movement(from joystick)
float facsped=3D1.0f;
if (controls.burner) facsped=3D2.0f;
D3DXVECTOR3 posp;
//m_vz is vector forward
if (controls.burner)
posp=3Dm_vz*1.0f*SpeedMax*facsped;
else
posp=3Dm_vz*controls.axis_throttle*SpeedMax*facsped;
//v razliko
posp-=3Dmove;
float len=3DD3DXVec3Length(&posp);
if (len!=3D0.0f)
{
posp/=3Dlen;
D3DXVECTOR3 ForceApplied=3Dposp*MaxEngine;=20
dBodyAddForce(PhyBody,ForceApplied.x,ForceApplied.z,ForceApplied.y); =
//SEE HERE
}
------=_NextPart_000_0020_01C276DB.162787C0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi,look at this code:
//get orientation from ode and put it in my d3d=20
Quatrernion
const =
dReal *qx=3D=20
dBodyGetQuaternion (PhyBody);
D3DXQUATERNION qxx;
qxx.x=3D(
float)qx[0];
qxx.y=3D(
float)qx[2];
qxx.z=3D(
float)qx[1];
qxx.w=3D(
float)qx[3];
setOrientation(qxx); &n=
bsp; =20
//to directx
//get positionfrom ode and put it in my=20
D3DXVECTOR3
const =
dReal *=20
p=3DdBodyGetPosition(PhyBody);
//to directx
m_Position.x=3D(float)p[0];
m_Position.y=3D(float)p[2];
m_Position.z=3D(float)p[1];
//same for velocity
const =
dReal *=20
p1=3DdBodyGetLinearVel(PhyBody);
move.x=3D(float)p1[0];
move.y=3D(float)p1[2];
move.z=3D(float)p1[1];
//end test
//I dont understand ..... =
:-((( I wish=20
to get angular rotation around x,y,z
//then I wish to find differece =
between wished=20
angular rotation(from joystick) and current angular rotation
//then I wish to apply torque so =
they=20
eventually mach.
const =
dReal *=20
rotx=3DdBodyGetAngularVel (PhyBody);
dVector3 result;
dBodyVectorFromWorld(PhyBody, rotx[0],rotx[1],rotx[2],result);
rotate.x=3Dresult[0];
rotate.y=3Dresult[1];
rotate.z=3Dresult[2];
D3DXVECTOR3=20
rotVec=3DMaxRotate*D3DXVECTOR3(controls.axis_lr*1.0f,-controls.axis_ro*1.=
0f,-controls.axis_ud*1.0f);
rotVec-=3Drotate;
if =
(rotVec.x>0)=20
rotVec.x=3DRotMax;
if =
(rotVec.x<0)=20
rotVec.x=3D-RotMax;
if =
(rotVec.y>0)=20
rotVec.y=3DRotMax;
if =
(rotVec.y<0)=20
rotVec.y=3D-RotMax;
if =
(rotVec.z>0)=20
rotVec.z=3DRotMax;
if =
(rotVec.z<0)=20
rotVec.z=3D-RotMax;
dBodyAddRelTorque(PhyBody,70000.0f*rotVec.x,70000.0f*rotVec.y,70000.0f=
*rotVec.z);
//force which heads me forward, move =
is current=20
movement, posp is wished movement(from joystick)
float =
facsped=3D1.0f;
if =
(controls.burner)=20
facsped=3D2.0f;
D3DXVECTOR3 posp;
//m_vz is vector forward
if=20
(controls.burner)
posp=3Dm_vz*1.0f*SpeedMax*facsped;
else
=
posp=3Dm_vz*controls.axis_throttle*SpeedMax*facsped;
//v razliko
posp-=3Dmove;
float=20
len=3DD3DXVec3Length(&posp);
if =
(len!=3D0.0f)
{
posp/=3Dlen;
D3DXVECTOR3 ForceApplied=3Dposp*MaxEngine;
=20
dBodyAddForce(PhyBody,ForceApplied.x,ForceApplied.z,ForceApplied.y); =
; =20
//SEE HERE
}
------=_NextPart_000_0020_01C276DB.162787C0--
From coding at natew.com Fri Oct 18 10:39:01 2002
From: coding at natew.com (Nate W)
Date: Fri Oct 18 10:39:01 2002
Subject: [ODE] a newbies question on hinge and robot legs...
In-Reply-To: <020c01c2768b$d87d7eb0$c36abb84@tig>
Message-ID:
On Fri, 18 Oct 2002, Michael Scharvogel wrote:
> In the final state I'd like to say something like:
> Hinge 1 bow 10 degrees.
>
> So do I have to attach Motors to the hinges to achiev this (I did not
> quiet figure out how this could work) or do I have to use these
> Transform geometries and rotate them (I I understood them right they
> can be used to rotate for example a leg around one of its ends)
What you're talking about is a job for motors. You don't have to
"attach" motors to joints though, in ODE joints have motorization built
into them.
The motor API does not allow command like "move 10 degrees" though.
Instead, you ask it something like "Hinge 1 move at 5 degrees per
second" until the hinge is at the angle you desire. This means checking
the hinge angle every frame, comparing it to the desired hinge angle, and
asking it to move at a speed proportional to the difference.
If you search the mailing list archives you'll probably find some messagse
from me on this subject. The most recent of those messages are the most
correct - I was trying to do it the wrong way at first. :-)
--
Nate Waddoups
Redmond WA USA
http://www.natew.com
From coding at natew.com Fri Oct 18 10:51:02 2002
From: coding at natew.com (Nate W)
Date: Fri Oct 18 10:51:02 2002
Subject: [ODE] Introduction / Suggestions etc
In-Reply-To: <001801c276ad$38345a10$d834fe3e@MalLaptop>
Message-ID:
On Fri, 18 Oct 2002, Malachy Duffin wrote:
> imagine designing a car, defining it's wheels / suspension / mass
> etc and clicking a button to immediately let you drive it around a 3D
> world for testing purposes
"Imagine?" :-)
http://www.natew.com/juice/frames.cgi/general/html.ScreenShots
http://www.natew.com/juice/frames.cgi/general/html.Pix
> One quick suggestion, from the http://q12.org/ode/ode.html website there
> doesn't seem to be any updates on news, or any easy way to see examples
> of content created with ODE.
>
> A quick revamp with a gallery of examples and links to downloadable
> demos would be great, as a lot more people should be checking it out
> over the coming months.
Check the community page for examples of content. There are a few
projects with screenshots and downloadable movies, not just mine.
--
Nate Waddoups
Redmond WA USA
http://www.natew.com
From Alan_Gordie at payformance.com Fri Oct 18 11:11:01 2002
From: Alan_Gordie at payformance.com (Alan Gordie)
Date: Fri Oct 18 11:11:01 2002
Subject: [ODE] Introduction / Suggestions etc
Message-ID:
Hi Mal!
Well, perhaps it's time for me to de-lurk... (due to the mention of ODE
integration with Blender)
My name is Alan Gordie and I've been steadily building a robust, spring-mass
simulation engine (http://gordie.go.dyndns.org/) for simulating vehicles and
structures for fun. Contemplating the GPL release of Blender, I'd been
toying with the idea of grafting my sim code into/onto Blender, but that
would be pointless if ODE were to be integrated with Blender.
At any rate, I've been following ODE (and the mailing list) for awhile now
and find myself continually more impressed with its' progress as time goes
on. (Thanks to Russ and the rest of you!) It seems to me that ODE has
reached 'escape velocity' in terms of project growth and community support.
Don't get me wrong, I think there is huge potential, but it seems like it
has enough momentum now to easily move to the next level.
And the point is: Now, after the release of the Blender source, I've
decided to contribute in any ways that I can in terms of adding my
spring-mass modeling primitives to ODE, as well as offering development
assistance for the "ODE Plugin" for Blender.
As Mal mentioned, there are many compelling reasons to add support this
effort, but there is one that stands out for me. It will ensure that there
is a open-sourced, freely-available tool suite for rigid body simulation.
So, who else is interested in devoting some time to the ODE/Blender effort?
I've been hanging around in #ode on EFNET since it was announced a few days
ago, but there hasn't been much activity. If there are enough interested
parties, I'd like to propose that we hook up on irc to start drawing up a
set of plans. Any takers?
Alan
alan_gordie@payformance.com
alangordie@attbi.com
-----Original Message-----
From: Malachy Duffin [mailto:mal@candomultimedia.com]
Sent: Friday, October 18, 2002 9:50 AM
To: ode@q12.org
Subject: [ODE] Introduction / Suggestions etc
Hello all,
Mal here from canDo Multimedia, an Irish 3D interactive development
company. We are using a lot of Shockwave 3D at the moment ( along with
the online Havok engine ) for some web games, which you can see at...
http://www.candomultimedia.com/games/demos.htm
Firstly, I don't know if many of you on the list know, but ODE will soon
be integrated as a physics option into the realtime 3D engine of the now
open sourced version of Blender ( www.blender.org ).
This is great for a number of reasons...
- It will raise the awareness of open source game related projects like
Blender and ODE.
- More developers will be keen to work on these projects
- Because Blender is cross platform, a lot of work will be carried out
to ensure that ODE is deployed on platforms that it wasn't available on
before
- ODE developers will be able to show what the engine can do online (
Blender has a web plugin )
Blender has a fairly high learning curve, but is a great prototyping
tool ( imagine designing a car, defining it's wheels / suspension / mass
etc and clicking a button to immediately let you drive it around a 3D
world for testing purposes / to let the artists play with parameters etc
).
I am looking forward to seeing a lot more content created this way! It
makes it more accessible for artists to know how to design content for
physics based games ( using proxies, compound convex objects etc for
optimisations )
One quick suggestion, from the http://q12.org/ode/ode.html website there
doesn't seem to be any updates on news, or any easy way to see examples
of content created with ODE.
A quick revamp with a gallery of examples and links to downloadable
demos would be great, as a lot more people should be checking it out
over the coming months.
Thanks for taking the time to read the post, and I look forward to
reading future postings on this mailing list.
Mal
_______________________________________________
ODE mailing list
ODE@q12.org
http://q12.org/mailman/listinfo/ode
From nlin at nlin.net Fri Oct 18 11:44:02 2002
From: nlin at nlin.net (nlin@nlin.net)
Date: Fri Oct 18 11:44:02 2002
Subject: [ODE] ODE and the Blender real-time 3d modeling/gaming environment
Message-ID: <20021018202815.GA32125@nlin.net>
Hello,
I have checked in a version of Blender with preliminary support for
ODE. Set your CVSROOT to :pserver:anonymous@217.77.141.135:/cvs01 and
do a CVS co of module "blender" to obtain the source code.
For those who don't know, Blender is a powerful 3D modeling package
which just became free software under the GPL license. It has a built-in
real-time 3D game engine whose physics are now being replaced with ODE.
Blender is very interesting for the ODE community because it can be a
very powerful tool for quickly creating real-time games; now, coupled
with ODE, it can be used for quickly creating ODE simulations - similar
to Nate W's "juice" application, but with the full power of a general-
purpose 3D modeler and game engine. For instance, using Blender's game
engine, you can have ODE-controlled dynamic objects interact with
other game objects controlled via scripts or paths.
This is preliminary work. There is still a lot left to do. I only tested
it on Debian GNU/Linux. See the todo list in OdePhysicsController.cpp for
an idea of what still needs to be done. Anyone interested in contributing
please discuss via the mailing list or private e-mail.
Thanks,
-Norman
From Brad at fie.us Fri Oct 18 12:31:01 2002
From: Brad at fie.us (Brad Friedman)
Date: Fri Oct 18 12:31:01 2002
Subject: [ODE] ODE and the Blender real-time 3d modeling/gaming environment
References: <20021018202815.GA32125@nlin.net>
Message-ID: <3DB06199.4020407@fie.us>
From tetron at interreality.org Fri Oct 18 13:22:02 2002
From: tetron at interreality.org (Peter Amstutz)
Date: Fri Oct 18 13:22:02 2002
Subject: [ODE] networking
In-Reply-To:
Message-ID:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I'll jump in here. I really want to use ODE for my distributed multiuser
virtual reality system (http://interreality.org), hence the interest in
stable box stacking -- a virtual world would naturally allow you to stack
stuff on top of other stuff just like in the real world (and then knock it
down :-)
The system is peer-to-peer and designed such that each object in the
system has an authoratative instance, and the world is described by
hyperlinking objects together (which usually includes linking across
hosts) (lots more information about how this all fits together on the web
page). For dynamics simulation, I intend to have a policy that the
authoratative instance is entirely responsible for the dynamic movement of
its objects, and nonlocal objects are considered more or less static. So
the dynamics simulation is more or less consistant from the perspective of
each user (even if globally it's way off, as long as it looks okay)
without violating trust bounderies between hosts by manipulating objects
you don't control.
The problem with distributed simulation in the game paradigm is, of
course, users may cheat -- however the VR stuff I'm interested in is
intended to be social and not competetive, so there isn't really the same
notion of "cheating".
On Wed, 16 Oct 2002, Nate W wrote:
> The thing that makes me want to avoid that model today is that physics
> takes a lot of CPU power. Every client brings a fast CPU to the party...
> if there's a way to make use of that power, many clients together could be
> able to do much more complex simulations than a single server (or rather,
> "more complex that the server *I* can afford"). Ideally, it gets a lot
> cheaper to scale the system to support more users, becase each user brings
> enough CPU power to do their share of the computation. Practically it
> will never be quite that scalable, but I still like the idea.
>
> If you can have each client simulate the parts of the player's body or
> vehicle, then broadcast the positions and orientations, the server's CPU
> requirements go down quite a bit. Note that I'm assuming a game sort of
> paradigm here, but other scenarios could use other methods of assigning
> objects to CPUs.
>
> I'd elaborate, but I see that Anselm has already described something like
> what I had in mind, only better. :-)
[ 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)
iD8DBQE9sG0vaeHUyhjCHfcRAlWcAJ4sCItHR5nYGP8MpA77B4uWQyaiqQCgr55D
/GkkJGsj8Vvj1hnVHp/YifA=
=ertj
-----END PGP SIGNATURE-----
From tetron at interreality.org Fri Oct 18 13:27:01 2002
From: tetron at interreality.org (Peter Amstutz)
Date: Fri Oct 18 13:27:01 2002
Subject: [ODE] box stacking instability
In-Reply-To:
Message-ID:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Thu, 17 Oct 2002, Nate W wrote:
> I have no doubt that boxes will rest on other boxes when the box-box
> collision code returns three contact constraints when boxes are touching
> in a face-to-face configuration. It works for boxes on planes now, it
> will work for boxes on boxes eventually.
This is very encouraging -- I quite want to see this happen as it is a
prerequisite for ODE being useful for me. If someone can give me some
pointers on where to look and what needs to be done, I'll happily roll my
sleves up and look into fixing this. Any suggestions?
[ 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)
iD8DBQE9sG5jaeHUyhjCHfcRAjNhAKCqgzG0epl2qZy59mhDb608prVZ5gCgj0ap
H8wDr1BK9N3wjcXrqtSwtJA=
=jfiA
-----END PGP SIGNATURE-----
From russ at q12.org Fri Oct 18 13:50:02 2002
From: russ at q12.org (Russ Smith)
Date: Fri Oct 18 13:50:02 2002
Subject: [ODE] Introduction / Suggestions etc
In-Reply-To:
Message-ID:
cool!
i'm in full support of ODE/blender integration - i think this is quite
an exciting prospect. in fact i took some very preliminary steps in this
direction as soon as the blender sources were released - but as norman
is far in advance of my own pitiful attempt i will abandon what i am doing
and help out the existing effort.
i have a question: the commercial dynamics providers (ME, havok etc) have
their own plugins for 3DSMax, maya, and other expensive tools. i am
wondering what functionality, if any, would be lost by an artist switching
from e.g. 3DSMax/Havok to Blender/ODE ? (i'm a 3DSMax novice and a
blender dummy.)
about the suggestion to use IRC - it would be perhaps more useful to
discuss this on the mailing list - so that at least we have an archived,
google-searchable record.
this discussion ties in with the file format discussion. i am guessing
that the initial blender integration will be to run ODE simulations
within blender to produce animation data, and that the saved dynamics
information will be tied in with blenders own file format(s). it would
also be nice if it blender could export a file format describing just the
dynamical attributes that have been given to the geometry objects, so
that in my game/simulation/whatever i could load this data, construct the
ODE objects, then attach the objects to my scene data.
it's important to have a file format that can separates dynamics
attributes from the geometry data. this is because, e.g., i might design
my dynamical system in blender but then use some non-blender-created
graphics in my application. we dont want to tie the data to the
application after all.
nate and others - is there any useful level of concensus on what the "one
true file format" should be? (disclaimer: i've not looked at the juice
file format or any others). if there is no convergence yet, i have a pile
of my own ideas i would like to contribute here.
russ.
--
Russ Smith
http://www.q12.org/
From russ at q12.org Fri Oct 18 14:00:03 2002
From: russ at q12.org (Russ Smith)
Date: Fri Oct 18 14:00:03 2002
Subject: [ODE] Introduction / Suggestions etc
In-Reply-To:
Message-ID:
> i have a question: the commercial dynamics providers (ME, havok etc) have
> their own plugins for 3DSMax, maya, and other expensive tools. i am
> wondering what functionality, if any, would be lost by an artist switching
> from e.g. 3DSMax/Havok to Blender/ODE ? (i'm a 3DSMax novice and a
> blender dummy.)
oh ... and i know that 3DSMax/Havok supports cloth and squishy bodies (ODE
doesn't yet) ... my question is more to do with the capabilities of
blender itself vs 3DS etc.
russ.
--
Russ Smith
http://www.q12.org/
From nathan at whatever.net Fri Oct 18 14:45:02 2002
From: nathan at whatever.net (Nate Waddoups)
Date: Fri Oct 18 14:45:02 2002
Subject: [ODE] Introduction / Suggestions etc
In-Reply-To:
Message-ID:
On Fri, 18 Oct 2002, Russ Smith wrote:
> nate and others - is there any useful level of concensus on what the "one
> true file format" should be? (disclaimer: i've not looked at the juice
> file format or any others). if there is no convergence yet, i have a pile
> of my own ideas i would like to contribute here.
I went with an XML sort of format merely for the sake of experience
with SAX and putting XML on my resume. It was also nice to have a
pre-existing parser and a standard parser API (MSXML and SAX). I pretty
much made it up as a went along, so I'm not terribly attached to the
format.
Novodex uses a format that looks friendly to C/C++ people (using { and }
and familiar indenting, for example), and if I understand correctly they
would be happy to see it used as a common open standard. It's definitely
worth a look. Speaking of which, I'm reminded of a message from Adam @
Novodex that I didn't get around to replying to the other day...
Anyhow, once a good file format gets agreed upon, I think a second key
ingredient to standardization would be to have some open and shared
"deserialization" code available. The less work it takes for application
developers to import such files, quicker they (we?) will support it.
Serialization and deserialization are useful for sharing data over a
network as well as persisting stuff to disk, so I kinda like the idea of
designing the file format and accompanying code with that in mind as well.
It could be possible to load objects (and even synchronize them) over a
network using the same format and much of the same deserialization code.
That aspect would be helped quite a bit if the application objects had a
common API to use when moving data from disk (or from the network) and
into the application.
--
Nate Waddoups
Redmond WA USA
http://www.natew.com
From coding at natew.com Fri Oct 18 14:50:02 2002
From: coding at natew.com (Nate W)
Date: Fri Oct 18 14:50:02 2002
Subject: [ODE] file formats
In-Reply-To: <200210170913.g9H9DQx22252@dubb05h07-0.dplanet.ch>
Message-ID:
On Thu, 17 Oct 2002 amoravanszky@dplanet.ch wrote:
> We at NovodeX think the entire community, regardless of which physics
> SDK is used, would benefit from a file format that is an open
> standard. In particular we are open to file format extensions as
> required by Juice -- though of course we should debate them first.
I haven't looked too deeply into the Novodex docs yet, but as far as I can
tell, the only stuff the Juice files contain that doesn't fit right into
the Novodex for format is stuff that pertains to motion control.
I don't think that really should be part of a common file format, because
(as far as I'm aware) control systems themselves are not yet standardized.
I came up with a couple of them for Juice, but chances are no other
application would support them or even want them.
The main thing, I think, would be to have a syntax that allows for
application-specific additions, and some sort of namespace control (even
if it's just the honor system) so that each application can easily ignore
any sections of the file that it doesn't support.
--
Nate Waddoups
Redmond WA USA
http://www.natew.com
From amoravanszky at dplanet.ch Fri Oct 18 15:49:01 2002
From: amoravanszky at dplanet.ch (Adam Moravanszky)
Date: Fri Oct 18 15:49:01 2002
Subject: [ODE] Introduction / Suggestions etc
References:
Message-ID: <001c01c276f8$da7e1c20$c912da50@powerhouse>
This is a multi-part message in MIME format.
------=_NextPart_000_0019_01C27709.9D4F8300
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
> worth a look. Speaking of which, I'm reminded of a message from Adam @
> Novodex that I didn't get around to replying to the other day...
>
> Anyhow, once a good file format gets agreed upon, I think a second key
> ingredient to standardization would be to have some open and shared
> "deserialization" code available. The less work it takes for application
> developers to import such files, quicker they (we?) will support it.
Hi Nate,
I attached some simple parser code (only 7K, I guess that is OK). It can
create the ODS data structure from a C++ stream, or write a structure to a
stream. This stuff only works on the ODS syntax level, and is not physics
specific. All the higher (physics) level serialization code is part of the
free viewer code in the SDK download, but of course on that level things are
less portable -- as you know for example our joint limits are specified
quite differently than those in ODE, for example. Still, standardization
even on this level would not hurt.
-- Adam Moravanszky
/*================*\
|Chief Software Architect
|NovodeX AG
|physics middleware
|www.novodex.com
\*================*/
------=_NextPart_000_0019_01C27709.9D4F8300
Content-Type: application/x-zip-compressed;
name="odblock.zip"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="odblock.zip"
UEsDBBQAAgAIAMYEUy2gRuF8ngYAAAYRAAAJAAAAT0RCbG9jay5opVjrbxo5EP8MEv/DSJEaQBT6
uDup0ERqCVGjJqEtqa4fKiGza8CXXXtre5PSNPe334ztfUCStqfShLDj8Tx+86R7YiljvoT5fHr0
+nQ6fjt/M5+3mntIE5Lvkgfdx7/z6n5uNb83dl7fiYZaEhVdQpQwY+AxqMU/PLIQcxNpkVmhJPhP
1ZV7xMBYZRstVmsL7XEHnr548QJexSyFM6XZFZPm2+WmrvU+Eb/3QhGffxOjAcHcak4dAkc1AGbu
k2k1H76M1448GxyAQ7TVnFlmecplSYLvcMF1KiRLWk1POQCBWYAs+zf7cFPeuIX9232AVrPgJ0bP
N9pvNVvNsUqJzwxbzcYeHiaUM5EnImnQBejCAA/SPLGiftoHuFhzPIvWTLPIcg0Rk1JZWHDIDY/R
Iq9LLAXXpk/q3LOBlG2Ii8soUYHzS64sNz1gMgazVnkSOzlSfMk5WAVLFqF68gsMZzpaC7lyIk8k
MLCbTEToHcuyBD8Q2j3ItFppzJ1rJy1R6hKWSsOlVNfSAxn0ac5iULkFgbah6RpVWLABsrbpoKJ3
TFsR5QnTjsNAqC/DU4YuRoQghurNybvjk9MJIt64wd/ZWmSSpRw/uufGOBEe2fDsOM5UzBP3FIiN
M27WxyLh4B8LcoNoJG8UnhMVJ/yKJ6Yg3Pq/F/yrzTVa+HMR4Yb/M0ZQMmHvGtTv9+t87n3G9RXX
NV8KJndKb/hL1YDdSGCo85jDy1mKQPbXh62m7xShb4y2ua6wcpQ+hDpNKGMxUukhlelgEJ5CdF02
qXy17sECA7mKIlAy2cCaGSguOhUhbNOj+dmrTydH8PxJ0TwGg5R9rWUsIE4ruw4wlUyYapz67akw
9mWw/rBwg4joSsFjbDwcel8KVujuMtO/LSx+2KWpAcOv1XzVJQwwjakq0gwh4Wlmsfxc/iOT+/n8
w27mwluYONtIy75OtMZSKtM6yxdYd9REGlzmKfjjG2KfzD+eTz7N33+cXkx6NcL09YdX4y3K+A7l
9ORi8uHVaa+iTKbH/mlyPkbK2/Pp3+dw63I50+IKIXBGeP1c69GOdVv2twNbB26QFfHkIy+KWhr2
PWZmVmOfaXcc1Z2FoypNiJhLI1aSGhmRZ+IbH5X5YvAJ1BLYQl1xjINmG6qShVIJLIoAkZBaVoDJ
F75B0cH22XAosDMxTCnfofBt5DWVdOpy1NPQ9LKLGUozZHItAUcSSxETuUKawcQREZQ+RHqTWZdN
o+rUuR1zd9Z2D1GvuvKodqmzewu7/P+7daVEvH2rS/dcMRVV/+gHcpynVcyD1LL+EsViP2LbTqQo
RHZGiA+dGl8dsNQqDVtLFQNMhlo3iPAqjiQGkl9jx6FG/2/FWLu1rarnwh987HlkDp44yQ+a0APf
CimqmB8LX78Nh5ZhV7zuUw0mn2jvabyGh6CW9GF64k0Ddi0KjThrTUT7B2UKDnkahf46HByA1TiO
xRI2KodrHHzEnjKaxhwypg2nOZrltn+PZW4wdmGZ9Wo2FWhiYyUb8Ieyd6HVJZdwNsOoJ3C95ti+
Cp9ixY3ct9j49eWWGppsu+7Xvd91vijQctvADSLh9AlN4HXLO2SCxMFP2AcJuGL0Q02FWvPJRg3D
9wGfAE6rMEWlV+lD9xBc47Yboanqy0VPcxzfErHAwnV402bCymKmSEiFmxi2MkEl8Dp084az51oL
S/Y0CnS8Od62CvDaqMP+ZHGZW/jx4y+xOC5nSruonke+wPA27mVacDOEYGxIDVzz8yjixlS5jzFf
cVuUQYWPUx0i9IFHuTYCEXfL3YFz3BVkAYXPzmth17BCvvpu2QNMmfOPp6c+IM56h22tVgeDTHPM
UO7wRnsC5iWkKAKrKqhBPNAeTaEImDif8ZrdaqrDIsApZkw5bdsVxoX1Rd0QX3XdjWX8XiMStkh4
lT4S17fdhKlkMciUkLRwoycUNmIHgVt5LKgZlS5hWWJi7/qyb+pLjtfYp33hF1ycFXPpZy6WUBpo
V22rFNq543mVK+RNoedXnS/VVY7AWqzALcfUoDTWWC4jixt/PV1Vma5DaFP5u+6D312L2qIy6hQI
FFl8UhaTR5I6s4Uu2eqbgSl8R+xRYDpsNBzjDTx99nx0uysvbBnbIv3gC0IrOYUktohww7wr6xin
x651S6LBg6LQpv4ff/71gCxzv7Da/AXc+BzV0EDZ8vfps/7zEdTf8TuC29dcjDjtX6a2LyiJJRlG
Pu6b1i1o1EVvw1zf4zLGHBsMdv5f4z9QSwMEFAACAAgA6gRTLWYKGQ+zEwAAZEAAAAsAAABPREJs
b2NrLmNwcM1be3PTSLb/21TxHTqZ2omdOLH1svwg3GJ4VFHLkF1gaqYKKEqR5USDLflKMiGTzX72
Pa/ulmwngYG5e0M5sVunu8/zd87pNr39w2/52X93/96/Wms//8Kxkyc/zfP4o4rnUVmqQ5Wf/p7E
lZomZVykyyrNM8Xv7JQty6jH+fKySM/OK9V+3FHOaDRSj6bRQv2cF9GnKCv/+HhZ33XbEt/2A0u8
+0Yd9e7f6+0fvko+pSWIvZ0I9ageVWPl9HteD6QMxoEz9kL1j5/hCWniPMrOkqn6BGrMCxXnWRWl
WVKoWZEvFFKUMJ5mZ+pTNFdVropklhRZnByBBN+VxaDnDHv9vhqN3dHY95hFFQt/ZRVVaazK9A/4
kGbTJKvSWZoUJRIBW1FxmlZFVFyq6WUWLYA0tTRHJOz3ZXfQc0a9vksqiqZT4GqxmlfpHJQHWlws
YHPZ9wu3vn/vhzSL56tpoh6Imx+dP6yPlhUaggaZfDZNZuofH05ef/jt9cmLR6+ev4ZRGEMe0rz8
cBqV9MaOXqBW2snnZUfBLxhP5mWy9XFaHtlPSJhN0xlvvCrRH0DLSbmM4gRsM53gODhPWaHFCrWv
RITxGCK1eloU4FzH6uUvL14A6Sor07MMVGaI4uJyWb0GGydA1afVxOK03CJavh0F798G7+Hx1f17
V86gq1yvq0bw8rsqGF13YXTowojTBW+HUfzr03AABMOu8oDWBQrP4VEgGIQ0HZ+EPIrTYe3hCEZw
eRocwHouvEa4LtAPXRoOYdEBTMXHPv4dMDUMhzDfhXU8fDEXQ4eHhgEyhgwyG7LAEGYN8W+fh5Fp
hxnHWbzjEN6h6AOfGXKFkYBlwNU9XIqJgQh5CUAQouBRfAdTA3h5oA2fVRe4TISrIqdhQMNOwJTC
DQsY+kwzQmXCBj7v57ioApiKS+BfZs6H7b2Q56N2h6wOf8QyI78wMRABUcs+q9VHjYiSBmK6IRt3
wEyjHLCMh9x5+JRN2Je5vpiSaQM2EgoKc3xW84Asz77ko61CZg5FGbEZceKAqd0ApQJqHB6hcVjw
ERs68NmUDjONvLps1AFuyhI6HhM6LivQZ0WjJw5DnMvaGvEa+DHkTVF9zAZqAU2H+yIrgTCNfuex
knGHkKnDkOaiZTBaRKFICyNoKhSTKTFAHJbFB1F5FCehy4ZE7bILeL6Y3mElDZgF9B707ZA5GYhs
6K1DtjM6RyjEI1oR2UBn8JhddGB8guZG7/PExTlw0PUCCiLmzSUHQrv4qGa2B4Vzn50f2fbZ85Ei
FNWh/OyHjtAgLb54YWQKDY+mQK7F8VE8jwMFEWIgRgrZKyky0dN5P4w71+eXT+ZisT22MsqMzujz
2q6FF3Rrl0XBj6IIFJIH0ZSID7goKmQkkvjsURgKGLMhD6MfuyG/fPrL1Bj/Drs5suMwG4Ewi/ZC
u3liwoDjKRhxvAQCD+g8odgcVcuLYARjfCAK0Ewx+IDN5AuUurwIuhqhqseLucK3w/x6sq0jzj9g
odG/SMMC/UNewGELBbwGwXDAlh1R0DHxiD0XlYhqGbLB+oIBffE1MWNf7BSwVjwJFodZczmUXXYF
DB9UG/KAmh0IBg7YhrQ8TuKlUUeOYAmGuC/QyFpDXaCFQoHzUEw7YNCUZINeyMiGPutIBISsM2SH
3E8MMGQM0IjnMRu4NcYmLkTAK0yLkyIvlNN41BNICwWABBpFQwNJAmxaQinRvUuRxsMOE+JfNFwg
puWoQqOjZRzRvzgSZhzmkAV3KXUPOTdJDPnsE0N5BWKUkFFO5wTW8ohVOeK47V9fb1QdafZpo/Ag
M3kMDGi2kc1m6Jloc4QfCQTK4uKw6EfiwyTlgJMtuqhIigwieHuEi5JVXd4HeaTsOTB5UpIICi3B
60sdQJYzmZaypOQFcgwbpFRC+Rwjkj0H4u4OQ7AAuydZCw1K1dDIxL8nQBLalIMfA4dxEjUiKTiQ
hIE+NtSZCAVDz0U1IQpIPdJnVKJs7ZsETHEoAeOHBlhowZBBn+qKvkkwoSDIMDC4TJHP8YhbSCqh
CmnIbkZr+abiIt+WUHcMSvalnLPpwYCvJ946MFEXCrYEA5sVA/ZKzh1eLdmOajhrC1tfIpSALzCx
6Ety9XyT/yjD+AwplCc8A5G60kRXcw2s4FxKgL7FoFC8Syo0m0F9jn20WWiqInRu3BZDTbIiQgYV
SiykhC3qBWFDl5+1esLvS9YPDUCi9RBOKS0MDSQjr4RKAqmSSDC4UWm4kKOTJXPEuECGsWUwZdQ+
FYkCkGQeya6BKVRwhApaj6WRBoI04LIm3IHJOc6IFTQUM0oJi9UEQfGoAYVUb/scXL5nWhbcCiMD
LYJhIyW9J4WGBgTXFOmhlEGBbyBZ6lfqIDxTYaMuMD5dXdqOTDlAjYIjpY1rYB3jDxeiktA2Lejt
lOaGpsWRasmRAty19fhQEB8V09dN2YhUT8VeaIvgPidynBXYnozyuyRn6U1Q5wNWJk8wpXsooY2y
jmy6sAnAdl8hJyhPTDwwacsTzHBNrxCyvIQ7vqnbAimvBn1poFzTXfqyOLIkdRRGj0YNyoC25pUO
lcqpoa3zJflSoe2acpOGAvFq23450qchn1LJUqCF7FzDvs21A8Zh6mEHJucP2HIIQ/zU1L26guyb
JokUL93kSHcLUnKj9ahodXSRPfSksOzr4gCRi2qkAUONdODkU5LXqGEZmerWF8i0bZPj8F5Uc9U6
mRGjy0heg1opzNwOh6Ya1C7vs+6k/KRagmFgEJhSySdkQaNQ3Waru0AEx9CSToYqYJcSBXVUthdy
bLqC3o0LD6o4zHlIktGJSJtG464yJyY/KntU0rl/rwU1SYuIKlillc5UO1YP1R78+xFI1YNjkDJE
QqJsxerwWLXh8YHTwQktPCg9pvOV+P1bu/Sh854e185loAByDtptO3IQH1SdvwW8TgyPK3l30Nyi
14vKMilAGPWAuKHRa/hVJNWqyFSMA9ebSpgm/6dKkHLvL9PDVok/5en0BrPvo8xlNR2P87IqkmgB
cpfqDjVcnKfzRLX3YytuqR48UHrl/RhWqE1jVg8ODIfXfMYntqid4508eX2ZVdFnOssbj6PyNR1H
tvXO9cp5lSWfnbdYM+/+c5WD0nBgmcRVMj3anWwhdpn4ZJlkeLZ4WuC54l2TPJ70eJ6XXz7J50kv
0iopornKC1UmizTO53l259yA5/5iyECtU5XP1AyVPstX2ZaJoPlVpid+zPKLTBsDbyui+Vmu4nya
yMSLtIrPVTspipq/4jEuqP/ph19ePv3twz9/OXnzdIwPtDuRuidbSE9+evXo8Satu4328XZabxvt
i+dvnr569GKD2N9G/PTk2QZhsEb49OVjIP77y5NfXzZoSXlEO01m0WpeNZ7KcXLDcfUN0b49gM6j
6Wu6FGqnOpDSkty214vhc5VoL+dbD7QmPDUrqXyiASYmrG5VxaUi06TlUZlUs7Y+bR+Py4/p8qLs
TFoIfPhBQUhWclLOU9TDh4wAAlXHx2pvZ4/szQY3NLBEdZ6QH0Xgb4WKZvgbx3YUEEXkOuB5PLbu
V6sSPFmpXxOVZ/NLVa6Wy7yo1KekwAsO5aioonmLHK8rjnhrYmkHWHKEpVZ1XuQXKksuVAMD2muI
sG5IxpYW3zC0jGytxlk/u22rlcN73oGUDpbqVsVK8IkNLL/NelumzCJ42I0t3sYRhVODUwRWG1z1
64n48KGFNVpjm6PJWG4wvAaRmhPjZt3TPJ9rw3TZh+IOOQf6ZalOrd/xzWVX8YUPQlq5Oj2FxyUr
ASfROmj6PlkdYomXTqZQf9BQmYDR60kx7sarosA7s89yudIipk4Zmo8VaW0iG4D9L5K9IgEuyhR8
K1LLKC0Q5P4XyZEVe7Nmr3R48HX6R2L2eJMUizQDjIWMCKbEsQqHqvo8GEyy1UJd/fro+ZsPz588
ffmmy79p4KcXJ4//3qXf13QHiMtsv/gC3s/iWCVky4u8+BgVCMhjVeZFcdlVWQ56WyznCfp6AuNp
llZpNAeWzb1nCQotkjg/y+ieEayYUITZGzLLpurbUR5w1siIbeXaUR7w7G1aS3IFKs2uPGEkA4H6
HQWONFXLvCzT07m9WURdFBW6CCSMc/UDXoFKLsIbSJrsyOR8VdQuQ4/U4eFD8JOzpBKLktdAXjqi
TamAaO8AsM2idN7u2EghZEDfhYKOU1t1DgCyoHv08+hTok6TJNN7VsgLgovEwuklMRJH8zno+/BQ
LYs8TspSpRW6WkWzZgrYIrEiCu08SxiVsKyKoRyK42NyLosCTcA0ECZhIQiG00012V0vfxhXYJYG
490mGMNyYqRjNmGngWd1R+dQ4vFoOqVN0GDt/fYaVBlI6HSaILeBl0pZDnbqfoLVrRmmkY4SpFDq
a0DblhWaFYMNO/xOhpERHhAVYAKEenR7CmQSK88t2ZIJdCjoKLgJ+a1dGsyIvqTbMCZjzdQksHD4
8FgZ3NISXWlma4Dm7ts5B8qXtVpSIoOSU8lFNPLWTD2Q9kE2tlGoNwORi3h5ic6RdmuP9axymsyT
KmlvedRAYZyvH1yLpOb5W8M8VqHx5ObnwK+GbxTPDB/c7qG6ao3XdUgF3t4Pe2MtLngA9C55kbT7
n5/BT5e/Y7D3LtszYQDeB4jxcdJYo3fLGvDw1rlXe2NlJm+EEoPyzaH0dfVPrezuYPlWs1IcZYCQ
gLbzeX4B2QUQkZP/RS+vF4lpdppUFwCl1kc4LIjT2wS9rimpLieD1jcI9FgE0itwCaQ/NkpzKiKq
5HNlPzUT0P9ssriGqzUHuhld/wzA2uBowFJ9u6+H2j+jT+mfanw1lGG25HQ02euwUkURkOiTqd29
aYxNFG3scTv2NVTxJQj4lSB4Mw7eDYW3o+FtgFg3+52w+EXIuBUca9tcb+SuayrJEqhwIijTOO6n
6TTbq1Q8z8kVv9qLoLHuTDY6X9uG6JMZ0+Umi2UloPOdy/i1RujfmyzMsJamZhZKbSxhbYf9Avql
8ZgOZPA7iGQ3rEnb6FDYAxFVeXSanKUZNGYqxSi04xAPOHpwkJI7aS9p76cc+bXNl3kKu+O3Blt2
fjxPooIaPhze7mNfpqwtR3olFMbPsKS2h3i5dIVUfndVvUPU+lovYSkqczrJ291xdtfPJHUfjZvJ
UUfODXSti0YX1KjXJBRGCF61R21KYejX5eAirCbI2pEgqFxVEbQvn5K5ZhXHfmfj4NrcKdAGQK7K
CDanQzVVnuer+RQTJ++7syPq2dE7sXLIYX6H7kD9/kBvdujAp4ODjmLN7b2r9iZKtzJSOupnu3vm
RGYdnpjCjjYbELHKhyzHb0TuTu5ef8fEVL3NkHXeZbzEVoE2xTHzrsxEo2qNTLeEWetbAq3VwhA7
fNh0JpF7jZfDwz8l1bWRynQAqq6tiX5ed+5asOhjb1D/Rtu3zdSa3o530c3Xpxrja3pj/q3kX8bL
bW5h5l5tzv2v2LfLgT7ZxuP13g0ttjXfVtkmN82rHe/eCEvPnr94CmXIbFnHpL8ciG5DHUKlJRQJ
0PECW7vvqt0OwU8dHRoEu7sdfYG15pg1srXEpF2xvpB2RrPaXbutud7VBusZ094Wvuxt6/K21pe6
Mmut49RtbvwtXrzhxOgjNZBax6ivlnFdxGsjokYltU4y0STi1uDKdOxsXZvMvPVyjY3LN0r1rLPF
beSoupm6tMfIQ16hxgvFj+Wj1K5hmJGJxmdqc1UzPlkII1xaL292Ujyf1K2LudTEwATyeZK1086B
0xCMSq0HquakN3UE670Aae7tXLci9cJtbiwlDUgN+9O6jZqiNZpPfVX046mWcGvban10uSrPP5xG
UCHDlBsqxyIpE/AA3cL0essiWUYwioe9eHw7S4sSz7QXyTTFKtA0iPF5OqfTVGxSgD9T8l81i/fN
WNKcNH1gkReJlqfUHPV6bL2S2gI8o0Qyw0SpgFUVfYrSOcaQ6QPoSizKLtHvDK29uFZtw99mUHew
J95p72sSCOsmcB0c6EcT66fqlhUnNUGMHHhTwNdpU3WZVFonmzGaJZ8rGx3WUFoxke430GK4Ik6w
ZpL/z6OUKMdsoEowTkPMZgQ3xPwKdCjroFDejQWbXvBaq+8OLwA1s9Ntd4Pvahl7T9swjGZVOL3L
KoZjaw+78ClmnppBNoxgMHGy5Sba8gVRyzxZSETDSsnyKoF4LVPIU9CPxuedOtNyUoiXPWdAUcf0
Ln6JAVvSo02+N/MCn2QVWbxYNpCO+Dh58uHnR789f9LBc6d+3Vuq87ThMOZGyAag2no1v3Zo/9fV
qsTMugrXz/SRhmILSwJjDRaeOmV7rFe3aO1Mp3ZuWF+VV9yu5vVnNyu7ti9Oam69rllbG7e00/V6
6jw9U1zOLKK4yNVslcVV2VX1SML/JbuK8fZtvB7kWifPM/MtJOaWiuf9pTilubku6esvebEYS1a9
Uo7rTa43XBEy5VJ7I74HKzT1X7tpxOeHDyX/2Y6dh9eSUafF3sV2K8s4ymZC2YTn7u7fprvdpazX
qulDRq7XLvhN2r6+SUnyVQHRk1aU/A9IGGBtWQVpFUWn8TSZ/deUtI/rblPR5Ltp5tk8j6p1xcxw
UPvQplbAb478YPD/1Hdm39l3SEPlTSqqfcsvWy1otOz0eo1Ac9wjb6Lqv4+OjhR+m/S7qc+2XhD8
GbZE2QPDD3yQLvc2Dd+p1R/by7fZ+44cvzZ0e4tS79/7D1BLAQIUABQAAgAIAMYEUy2gRuF8ngYA
AAYRAAAJAAAAAAAAAAEAIAC2gQAAAABPREJsb2NrLmhQSwECFAAUAAIACADqBFMtZgoZD7MTAABk
QAAACwAAAAAAAAABACAAtoHFBgAAT0RCbG9jay5jcHBQSwUGAAAAAAIAAgBwAAAAoRoAAAAA
------=_NextPart_000_0019_01C27709.9D4F8300--
From nlin at nlin.net Fri Oct 18 17:59:02 2002
From: nlin at nlin.net (nlin@nlin.net)
Date: Fri Oct 18 17:59:02 2002
Subject: [ODE] ODE/Blender
Message-ID: <20021019024242.GA32509@nlin.net>
Russ Smith wrote:
>
>i'm in full support of ODE/blender integration - i think this is quite
>an exciting prospect. in fact i took some very preliminary steps in this
>direction as soon as the blender sources were released - but as norman
>is far in advance of my own pitiful attempt i will abandon what i am doing
>and help out the existing effort.
Not so fast - we may be doing different types of ODE/Blender integration
so I wouldn't throw out your work just yet...
>i have a question: the commercial dynamics providers (ME, havok etc) have
>their own plugins for 3DSMax, maya, and other expensive tools. i am
>wondering what functionality, if any, would be lost by an artist switching
>from e.g. 3DSMax/Havok to Blender/ODE ? (i'm a 3DSMax novice and a
>blender dummy.)
Something important to understand about Blender is that it has a built-in
real-time interactive 3D game engine. This means you can model a 3D scene in
Blender, press the "P" key, and Blender instantly (typically less than 1 second)
starts the game engine, which then controls all objects on-screen. This is
a reasonably complete (Turing-complete, anyway) game engine; you can animate
objects along paths, read keyboard input, move the camera and players around,
create/destroy objects, set variables, send messages between objects, run
scripts, and have objects controlled by the physics subsystem.
This physics subsystem in the real-time game engine is what I am working
on, so that Blender real-time games can have dynamic objects controlled
by ODE. (The previous Blender game physics were impulse-based.)
>i am guessing
>that the initial blender integration will be to run ODE simulations
>within blender to produce animation data, and that the saved dynamics
>information will be tied in with blenders own file format(s).
This is not the ODE/Blender integration I am working on right now, but
it is very important as well, so that artists creating non-interactive animations
(more traditional animations and movies) can also use ODE to create realistic
dynamic motions. As I am not an expert in creating these kinds of animations,
I don't know how such tools typically work or how they could be integrated
into the modeling/animation workflow of Blender (as opposed to the game engine
integration, which appears to me to be of a different nature). The way it is
now integrated, physical properties of objects are specified either in the
Blender material for the object (button DYN in the MaterialButtons) and/or in
the Blender Game Attributes for the object (in the GameButtons). These buttons
allow the user to enter properties like mass, friction, bounding volume, etc.
The Blender game engine reads these fields on game startup, then creates the
ODE objects. A rendering/animation tool should probably use these same
buttons to read out physically relevant information, but would start an ODE world
and simulate one timestep forward for each frame of the animation rendered.
>From what you write above it sounds like you are talking about the possibility
of running the simulation just once then "baking in" the ODE-computed animation
to save the animation data somewhere. This would also be possible. Again, I don't
know how such tools usually work.
>it would
>also be nice if it blender could export a file format describing just the
>dynamical attributes that have been given to the geometry objects, so
>that in my game/simulation/whatever i could load this data, construct the
>ODE objects, then attach the objects to my scene data.
Blender has a python scripting interface, and many good python scripts have
been written, especially for exporting/importing data. The python integration
is kind of shaky right now, since the project just went GPL, but I expect it
to stabilize. At that point, it should then be fairly easy to add python
access to the new dynamical attributes (friction, restitution, bounding
volumes, mass, etc) associated with each object. Then a python script could
simply iterate over all objects in the scene, iterate over all attributes for
each object, and write it out in any format desired.
-Norman
From russ at q12.org Fri Oct 18 20:36:02 2002
From: russ at q12.org (Russ Smith)
Date: Fri Oct 18 20:36:02 2002
Subject: [ODE] Re: ODE/Blender
In-Reply-To: <20021019024242.GA32509@nlin.net>
References: <20021019024242.GA32509@nlin.net>
Message-ID: <20021018204011.2905d6de.russ@q12.org>
> This physics subsystem in the real-time game engine is what I am
> working on, so that Blender real-time games can have dynamic objects
> controlled by ODE. (The previous Blender game physics were
> impulse-based.)
ah ... how are the dynamical properties of objects set in blender? i
have in mind something where you select two objects, add a joint at a
specific position, drag the low/high limits (some kind of draggable
widgets that surround the joint), pop up a dialog box for the
joint/body/surface properties, etc etc.
of course i should just try out your work in blender - but i have found
it (blender) even more difficult to use for the ininitiated than 3DSMax,
which is saying something.
russ.
--
Russell Smith
http://www.q12.org
From coding at natew.com Fri Oct 18 21:12:02 2002
From: coding at natew.com (Nate W)
Date: Fri Oct 18 21:12:02 2002
Subject: [ODE] Re: ODE/Blender
In-Reply-To: <20021018204011.2905d6de.russ@q12.org>
Message-ID:
On Fri, 18 Oct 2002, Russ Smith wrote:
> of course i should just try out your work in blender - but i have found
> it (blender) even more difficult to use for the ininitiated than 3DSMax,
> which is saying something.
That's good to hear, I was afraid it was just me. :-)
--
Nate Waddoups
Redmond WA USA
http://www.natew.com
From nlin at nlin.net Sat Oct 19 07:19:02 2002
From: nlin at nlin.net (nlin@nlin.net)
Date: Sat Oct 19 07:19:02 2002
Subject: [ODE] Re: ODE/Blender
Message-ID: <20021019155757.GA4938@nlin.net>
On Fri, Oct 18, 2002 at 08:40:11PM -0400, Russ Smith wrote:
[reordering a bit...]
> of course i should just try out your work in blender - but i have found
> it (blender) even more difficult to use for the ininitiated than 3DSMax,
> which is saying something.
The Blender UI is about as intuitive as that of vi or emacs. Hard to learn,
but very fast and powerful once you do know it.
See http://www.cse.cuhk.edu.hk/~wmpang1/blender/blen_ui/blen_ui.html
for a good introduction. It's somewhat old, but still relevant for the
basics.
> > This physics subsystem in the real-time game engine is what I am
> > working on, so that Blender real-time games can have dynamic objects
> > controlled by ODE. (The previous Blender game physics were
> > impulse-based.)
>
> ah ... how are the dynamical properties of objects set in blender? i
> have in mind something where you select two objects, add a joint at a
> specific position, drag the low/high limits (some kind of draggable
> widgets that surround the joint), pop up a dialog box for the
> joint/body/surface properties, etc etc.
After reading the above tutorial, add a mesh, add a new material to the
mesh, and in the MaterialButtons look for a small button "DYN". This
controls dynamic properties of the material connected with the mesh.
E.g. friction, restitution, or some special Fh force on slopes (for
the old physics, currently unused I think).
Another place to enter material properties is by the GameButtons. Select
a mesh, press F8 to go to the GameButtons, then click on the small "Actor"
button, at which point some more buttons will appear, then click on
"Dynamic" and "Rigid Body" (the old physics system had both "fake" dynamics
and rigid-body dynamics, which is why you had to explicitly select "rigid
body"; currently there is no longer any distinction between "Dynamic" and
"Rigid Body" that I am aware of). At this point you can set the mass of
the rigid body object, some damping properties, and some other properties
which are probably outdated and were for the old physics system (like the
"form factor").
To select the bounding volume for an object, select the object, go to the
EditButtons (press F9), and at the left activate the button "Bounds" then
select either "Box" or "Sphere". This controls whether the physics system will
use a sphere or a box for the rigid body. "Polyheder" is also an option, which
will eventually cause a tri-mesh to be generated using Erwin de Vries's
triangle collider. There are currently some bugs with the bounding volume
selection (see the ToDo list in OdePhysicsController.cpp)
As for joints or constraints, Blender already has a constraints window
designed for animation. You can constraint two objects to have the same
location. By creating "empty" or "dummy" objects, and using these as
parents of "real" objects, you can get point-to-point constraints in
the modeler. The game engine could use this information for generating
a ODE p2p constraint. There are some other simple constraints like
"track to" or "copy orientation". The current constraint types are designed for
animation/modeling help, but we could add new constraint types for physics,
which would then be used in the game engine. Again see OdePhysicsController.cpp
for notes on how this might work.
Blender may be a bit confusing at first, but it a very powerful program and
is worth learning.
-Norman
From nlin at nlin.net Sat Oct 19 07:21:02 2002
From: nlin at nlin.net (nlin@nlin.net)
Date: Sat Oct 19 07:21:02 2002
Subject: [ODE] Re: ODE/Blender
In-Reply-To: <20021018204011.2905d6de.russ@q12.org>
References: <20021019024242.GA32509@nlin.net> <20021018204011.2905d6de.russ@q12.org>
Message-ID: <20021019155926.GB4938@nlin.net>
By the way, some sample files illustrating the current ODE/Blender integration
are at http://www.xype.net/~nlin . These files will only work with the
CVS version of blender at CVSROOT=:pserver:anonymous@217.77.141.135:/cvs01 .
-Norman
From Benny Sat Oct 19 08:32:02 2002
From: Benny (Benny)
Date: Sat Oct 19 08:32:02 2002
Subject: [ODE] 3d world an directx
Message-ID: <200210191531.g9JFV8u16679@hook.org>
------- Original Message --------
From: ivan.bolcina@volja.net
To: "ode@q12.org"
CC:
Subject: [ODE] 3d world an directx
Date: 17/10/02 07:10
Problems.
Is ode 3d world different from DirectXs? It seems
to me that y and z axes are swapt.
bye,ivan
From don_reid at attbi.com Sat Oct 19 09:04:02 2002
From: don_reid at attbi.com (don)
Date: Sat Oct 19 09:04:02 2002
Subject: [ODE] Re: File formats
In-Reply-To: <200210190101.g9J119u04892@hook.org>
References: <200210190101.g9J119u04892@hook.org>
Message-ID: <20021019160048.GA9649@reid.corvallis.or.us>
An important thing to have in any file format, esp. a new one, is
extensability. You want to be able to add new construts easily, and
without changing old code. XML gives you this automatically.
Of course the parser must then be written to skip over things it
doesn't understand (with a warning if desired).
Don Reid
From ivan.bolcina at volja.net Sat Oct 19 13:17:01 2002
From: ivan.bolcina at volja.net (Ivan Bolcina)
Date: Sat Oct 19 13:17:01 2002
Subject: [ODE] 3d world on directx
Message-ID: <007401c277ac$57b1de30$0100a8c0@vectra>
This is a multi-part message in MIME format.
------=_NextPart_000_0071_01C277BD.1A8E1A80
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi!
I assure you that if I swap y and z axis, stuff works ok, otherwise =
doesnt.
Please look at my original code and see how are they swapt. I believe =
that
DirectX uses left-handed system.
I pass only quaternions from ode to directx to determine current
orientation. I have to swap axis in this case too.
thanx,
ivan
------=_NextPart_000_0071_01C277BD.1A8E1A80
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi!
I=20
assure you that if I swap y and z axis, stuff works ok, otherwise=20
doesnt.
Please look at my original code and see how are they swapt. I =
believe=20
that
DirectX uses left-handed system.
I pass only quaternions =
from ode=20
to directx to determine current
orientation. I have to swap axis in =
this case=20
too.
thanx,
ivan
------=_NextPart_000_0071_01C277BD.1A8E1A80--
From airsona at bestweb.net Sat Oct 19 22:35:02 2002
From: airsona at bestweb.net (Sasha H)
Date: Sat Oct 19 22:35:02 2002
Subject: [ODE] Flight Simulation
Message-ID: <001601c27795$5a7a6b80$4001b3d8@airsona>
This is a multi-part message in MIME format.
------=_NextPart_000_0013_01C27773.D27DCF40
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hey guys, I've few questions!
Okey, I'm planning to use ODE to make my airplane fly...
Would it be possible to simulate aerodynamics on each element of the =
airplane (body, right wing, left wing, tail, etc...)? What is the best =
approach, even if it's not "super realistic".=20
And also, if I have a mesh and a terrain, does ODE support such =
collisions?=20
Cool......thanks!
------=_NextPart_000_0013_01C27773.D27DCF40
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hey guys, I've few =
questions!
Okey, I'm planning to use ODE to make =
my airplane fly...
Would it be possible to simulate =
aerodynamics on=20
each element of the airplane (body, right wing, left wing, tail, =
etc...)? What=20
is the best approach, even if it's not "super realistic".
And also, if I have a mesh and a =
terrain, does ODE=20
support such collisions?
Cool......thanks!
------=_NextPart_000_0013_01C27773.D27DCF40--
From grubertm at hotmail.com Sat Oct 19 22:57:01 2002
From: grubertm at hotmail.com (Marco Grubert)
Date: Sat Oct 19 22:57:01 2002
Subject: [ODE] Flight Simulation
References: <001601c27795$5a7a6b80$4001b3d8@airsona>
Message-ID:
>Okey, I'm planning to use ODE to make my airplane fly...
>Would it be possible to simulate aerodynamics on each element of the
airplane (body, right wing, left wing, >tail, etc...)? What is the best
approach, even if it's not "super realistic".
As I have never done a flightsim, I can only refer you to a book such as
"Physics for Game Developers" which has a chapter on airplanes.
>And also, if I have a mesh and a terrain, does ODE support such collisions?
AFAIK no. Only one of the objects can be a mesh (trilist) the other one has
to be a box or sphere (not sure about the current capped/cylinder status).
I.e. you would use the bounding box of the fuselage & wings and a trilist
for the terrain.
- Marco Grubert
From coding at natew.com Sat Oct 19 23:06:02 2002
From: coding at natew.com (Nate W)
Date: Sat Oct 19 23:06:02 2002
Subject: [ODE] Flight Simulation
In-Reply-To:
Message-ID:
On Sat, 19 Oct 2002, Marco Grubert wrote:
> >And also, if I have a mesh and a terrain, does ODE support such collisions?
>
> AFAIK no. Only one of the objects can be a mesh (trilist) the other one has
> to be a box or sphere (not sure about the current capped/cylinder status).
> I.e. you would use the bounding box of the fuselage & wings and a trilist
> for the terrain.
That's a better answer than what I wrote just a minute ago. I think I
misunderstood the question.
--
Nate Waddoups
Redmond WA USA
http://www.natew.com
From coding at natew.com Sat Oct 19 23:09:02 2002
From: coding at natew.com (Nate W)
Date: Sat Oct 19 23:09:02 2002
Subject: [ODE] Flight Simulation
In-Reply-To: <001601c27795$5a7a6b80$4001b3d8@airsona>
Message-ID:
On Sat, 19 Oct 2002, Sasha H wrote:
> Okey, I'm planning to use ODE to make my airplane fly...
>
> Would it be possible to simulate aerodynamics on each element of the
> airplane (body, right wing, left wing, tail, etc...)? What is the best
> approach, even if it's not "super realistic".
$0.02 from a guy with a moderate understanding of aerodynamics and flying
things:
How about applying a force to each flying surface, in proportion to what
the aerodynamic force on said surface should be? You could calculate the
lift and drag for the wings, for example, and a force for the deflection
of each control surface, etc.
I bet you'd get fun, if not realistic, results. Make the force
computations as accurate and sophisticated as your understanding of
aerodynamics, learn all you can, and polish them up as you learn.
> And also, if I have a mesh and a terrain, does ODE support such
> collisions?
If you mix in the "tri-collider" contribution, you can do collision
detection between height-mapped terrain and boxes or spheres. A few of us
have been doing this in our ODE projects for a while now. I'm using it
with the Demeter terrain engine and I'm pretty happy with the results.
--
Nate Waddoups
Redmond WA USA
http://www.natew.com
From John Lagerquist Sun Oct 20 02:57:02 2002
From: John Lagerquist (John Lagerquist)
Date: Sun Oct 20 02:57:02 2002
Subject: [ODE] Quaternion Integration
Message-ID: <00a801c2781e$c6941260$6401a8c0@singularity>
It appears that NASA has a quaternion integration method that does not
require normalization between integration steps. Does anyone have any
information on this technique? Their webpage
(http://ettc.usc.edu/dryden/tos/closedform.html) states:
"NASA's technology represents a substantial improvement over traditional
methods of integrating 4-D kinematics equations. Those methods solve the
quaternion kinematic equations in a way that does not automatically preserve
the unit normalization of the quaternion. These methods are therefore
inherently prone to error and difficult to correct. Such traditional methods
are computation-intensive because of the substantial amount of error
correction needed to compensate for analytical drift. NASA's integration
method preserves the mathematics of the quaternion space that it creates and
therefore introduces no error associated specifically with non-preservation
of the quaternion norm. As a result, error correction associated with
normalization is not needed in the NASA method"
John
From rtonge90 at yahoo.co.uk Sun Oct 20 04:14:01 2002
From: rtonge90 at yahoo.co.uk (=?iso-8859-1?q?Richard=20Tonge?=)
Date: Sun Oct 20 04:14:01 2002
Subject: [ODE] Quaternion Integration
Message-ID: <20021020111339.28128.qmail@web14909.mail.yahoo.com>
Hello
>Does anyone have any information on this technique?
Here is the full text of the patent:
http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=/netahtml/search-bool.html&r=1&f=G&l=50&co1=AND&d=ft00&s1=6,061,611.WKU.&OS=PN/6,061,611&RS=PN/6,061,611
Richard Tonge
PS2 Optimisation Engineer
MathEngine
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
From Remko at act-3d.com Sun Oct 20 08:42:01 2002
From: Remko at act-3d.com (Remko Jacobs (act-3d.com))
Date: Sun Oct 20 08:42:01 2002
Subject: [ODE] Another strange wheel rotation
Message-ID: <277753125.359388433.98@server>
Ok, it was a stupid mistake. The hinges where initialized AFTER the first
simulation step. The wheels moved down because of the gravity and the
rotation point was shifted. Changing the order fixed this.
-Remko
-----Original Message-----
From: Remko Jacobs (act-3d.com)
Sent: Thursday, October 17, 2002 11:40 AM
To: ode@q12.org; Remko Jacobs (act-3d.com)
Subject: [ODE] Another strange wheel rotation bug
I fixed the 'bending wheels' problem using the following methods. The
problem still exists but at least you can reduce it to acceptable levels:
- Decrease the step size (update of 200-300Hz)
- Different CFM and ERP values
- Different masses
- Bigger wheels (The bigger the wheels, the slower they have to turn for
the same speed)
I'm experimenting with a driving simulation and the results are stunning!
However, after some experimentation, the car started to bounce and the
handling was completely gone.
It turned out that the wheel is not rotating around it's axis but around
a point slightly above that. Gravity was causing this offset. Gravity
pulls the wheel down so the rotation axis of the hinge is too high. What
really surprised me, is the solution I found:
When I set the gravity to zero the problem does not occur (as expected).
When I crank up the gravity while the simulation is running, the bug does
not come back but the wheel rotates around the correct point. Does anyone
has an explanation for this? Why the rotation screws up when I initialize
with gravity?
-Remko
_______________________________________________
ODE mailing list
ODE@q12.org
http://q12.org/mailman/listinfo/ode
From kjmac at freenet.co.uk Sun Oct 20 12:11:02 2002
From: kjmac at freenet.co.uk (Ken MacLeod)
Date: Sun Oct 20 12:11:02 2002
Subject: [ODE] Compiling OPCODE 1.0 as a static lib for use with tri-collider
Message-ID: <000301c2786c$4cf17990$0401a8c0@xperemental>
(Apologies if this message is posted twice, I initially sent it using
the incorrect email account)
Hi,
I’m developing a car simulation API for my MSc degree. I would like to
be able to use ODE with the tri-collider contribution (ode/contrib) so
that I can do sphere (wheel) triangle (terrain) collisions. Unfortunatly
I have cannot for the life of me get opcode to compile as a static
library. I printed off and followed the guide on the Wiki pages, but got
only the following error output:
--------------------Configuration: OPCODE 1_0 - Win32
Debug--------------------
Compiling...
OPC_Container.cpp
C:\MSc\opcode 1.0\opcode\OPC_Container.cpp(41) : warning C4273:
'private: static unsigned int Opcode::Container::mNbContainers' :
inconsistent dll linkage. dllexport assumed.
C:\MSc\opcode 1.0\opcode\OPC_Container.cpp(41) : error C2491:
'Container::mNbContainers' : definition of dllimport static data member
not allowed
C:\MSc\opcode 1.0\opcode\OPC_Container.cpp(42) : warning C4273:
'private: static unsigned int Opcode::Container::mUsedRam' :
inconsistent dll linkage. dllexport assumed.
C:\MSc\opcode 1.0\opcode\OPC_Container.cpp(42) : error C2491:
'Container::mUsedRam' : definition of dllimport static data member not
allowed
C:\MSc\opcode 1.0\opcode\OPC_Container.cpp(50) : warning C4273:
'Container::Container' : inconsistent dll linkage. dllexport assumed.
C:\MSc\opcode 1.0\opcode\OPC_Container.cpp(64) : warning C4273:
'Container::~Container' : inconsistent dll linkage. dllexport assumed.
C:\MSc\opcode 1.0\opcode\OPC_Container.cpp(79) : warning C4273: 'Resize'
: inconsistent dll linkage. dllexport assumed.
C:\MSc\opcode 1.0\opcode\OPC_Container.cpp(121) : warning C4273:
'Contains' : inconsistent dll linkage. dllexport assumed.
C:\MSc\opcode 1.0\opcode\OPC_Container.cpp(143) : warning C4273:
'Delete' : inconsistent dll linkage. dllexport assumed.
C:\MSc\opcode 1.0\opcode\OPC_Container.cpp(166) : warning C4273:
'FindNext' : inconsistent dll linkage. dllexport assumed.
C:\MSc\opcode 1.0\opcode\OPC_Container.cpp(186) : warning C4273:
'FindPrev' : inconsistent dll linkage. dllexport assumed.
C:\MSc\opcode 1.0\opcode\OPC_Container.cpp(204) : warning C4273:
'GetUsedRam' : inconsistent dll linkage. dllexport assumed.
OPC_Matrix4x4.cpp
C:\MSc\opcode 1.0\opcode\OPC_Matrix4x4.cpp(65) : error C2491:
'InvertPRMatrix' : definition of dllimport function not allowed
Error executing cl.exe.
OPCODE 1_0.lib - 3 error(s), 10 warning(s)
Looking through the archives for this mailing list someone named Norman
had the same problem. He posted a message saying the he to could not
compile opcode 1.0 as a static lib, unfortunately I could not see any
reply to his request in the archives. Norman’s next post just thanked
the author for helping him get it compiling! Here’s a snippit:
------------
Hi,
Thanks to the author's help I was able to compile the tri-collider -
I needed to modify opcode to compile it as a static library, then
compile the files in the tri-collider directory as a static library,
then link my test app against both libraries.
…
----------
All help with this is greatly appreciated! Thanks,
- Ken MacLeod
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.394 / Virus Database: 224 - Release Date: 03/10/2002
From amoravanszky at dplanet.ch Sun Oct 20 13:12:01 2002
From: amoravanszky at dplanet.ch (Adam Moravanszky)
Date: Sun Oct 20 13:12:01 2002
Subject: [ODE] Compiling OPCODE 1.0 as a static lib for use with
tri-collider
In-Reply-To: <000301c2786c$4cf17990$0401a8c0@xperemental>
Message-ID: <5.1.0.14.0.20021020221049.009edb30@pop.dplanet.ch>
Ken,
You just have to get rid of the #defines that prefix all the functions /
classes with __dllexport or __dllimport. It is not rocket science.
--Adam
At 08:10 PM 10/20/02 +0100, Ken MacLeod wrote:
>(Apologies if this message is posted twice, I initially sent it using
>the incorrect email account)
>
>Hi,
>I'm developing a car simulation API for my MSc degree. I would like to
>be able to use ODE with the tri-collider contribution (ode/contrib) so
>that I can do sphere (wheel) triangle (terrain) collisions. Unfortunatly
>I have cannot for the life of me get opcode to compile as a static
>library. I printed off and followed the guide on the Wiki pages, but got
>only the following error output:
>
>--------------------Configuration: OPCODE 1_0 - Win32
>Debug--------------------
>Compiling...
>OPC_Container.cpp
From Nguyen Binh Sun Oct 20 21:29:03 2002
From: Nguyen Binh (Nguyen Binh)
Date: Sun Oct 20 21:29:03 2002
Subject: Re[2]: [ODE] Introduction / Suggestions etc
In-Reply-To: <001c01c276f8$da7e1c20$c912da50@powerhouse>
References:
<001c01c276f8$da7e1c20$c912da50@powerhouse>
Message-ID: <731305116.20021021111343@glassegg.com>
As far as I know, Blender currently support Python. Then why do we
need to re-implement a small descriptive language? Why we don't use
the powerful Python? I didn't use Python but I use Lua
(www.lua.org) and it does help alot.(I've heard that Python is much
more powerful).
>> worth a look. Speaking of which, I'm reminded of a message from Adam @
>> Novodex that I didn't get around to replying to the other day...
>>
>> Anyhow, once a good file format gets agreed upon, I think a second key
>> ingredient to standardization would be to have some open and shared
>> "deserialization" code available. The less work it takes for application
>> developers to import such files, quicker they (we?) will support it.
AM> Hi Nate,
--
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 ivan.bolcina at volja.net Mon Oct 21 12:15:02 2002
From: ivan.bolcina at volja.net (Ivan Bolcina)
Date: Mon Oct 21 12:15:02 2002
Subject: [ODE] ode to directx coordinates and orientation
Message-ID: <000e01c27935$f510c620$0100a8c0@vectra>
This is a multi-part message in MIME format.
------=_NextPart_000_000B_01C27946.B83F8F40
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi.
Sorry cant speak Russian. I am from Slovenia, so we have slavic language =
in common.
I have this problem. Mapping 3-d coordinats from ode to directx. It is =
not one to one. I have come to conclusion that positions, velocities are =
mapped one to one, but orientation is like this function:
//from ode to directx
D3DXVECTOR3 convertVector(const dReal *in)
{
D3DXVECTOR3 out;
out.x=3Din[0];
out.y=3Din[1];
out.z=3Din[2];
return out;
}
//from ode to directx
D3DXQUATERNION convertQuaternion(const dReal *in)
{
D3DXQUATERNION out;
out.x=3D(float)in[0];
out.y=3D(float)in[1];
out.z=3D(float)in[2];
out.w=3D-(float)in[3];
return out;
}
So ODE is doing steps on objects and then I need to display it with =
directx in corrent position and orientation. Position seem to be ok, but =
orientation.....
btw, I see you are professional game developer. How does it feel like?
Lep pozdrav in dobro se imej tam v mrzli Rusiji. :-)
------=_NextPart_000_000B_01C27946.B83F8F40
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi.
Sorry cant speak Russian. I am from =
Slovenia, so we=20
have slavic language in common.
I have this problem. Mapping 3-d =
coordinats from=20
ode to directx. It is not one to one. I have come to conclusion that =
positions,=20
velocities are mapped one to one, but orientation is like this=20
function:
//from ode to directx
D3DXVECTOR3 convertVector(
const dReal *in)
{
D3DXVECTOR3=20
out;
out.x=3Din[0];
out.y=3Din[1];
out.z=3Din[2];
return =
out;
}
//from ode to directx
D3DXQUATERNION convertQuaternion(const dReal *in)
{
D3DXQUATERNION=20
out;
out.x=3D(float)in[0];
out.y=3D(float)in[1];
out.z=3D(float)in[2];
out.w=3D-(float)in[3];
return=20
out;
}
So ODE is doing steps on objects and =
then I need to=20
display it with directx in corrent position and orientation. Position =
seem to be=20
ok, but orientation.....
btw, I see you are professional game =
developer. How=20
does it feel like?
Lep pozdrav in dobro se imej tam v =
mrzli=20
Rusiji. :-)
------=_NextPart_000_000B_01C27946.B83F8F40--
From ivan.bolcina at volja.net Tue Oct 22 02:03:01 2002
From: ivan.bolcina at volja.net (Ivan Bolcina)
Date: Tue Oct 22 02:03:01 2002
Subject: [ODE] Re: ode to directx coordinates and orientation
References: <000e01c27935$f510c620$0100a8c0@vectra> <642235524.20021022104030@gsc-game.kiev.ua>
Message-ID: <001101c279a9$8fddd8f0$0100a8c0@vectra>
Hi,slipch.
Thank you VERY much. It works great.
So for anyone interested, here is transformation from ODE quaternion to
DirectX's.
D3DXQUATERNION convertQuaternion(const dReal *in)
{
D3DXQUATERNION out;
out.x=(float)in[1];
out.y=(float)in[2];
out.z=(float)in[3];
out.w=(float)in[0];
return out;
}
Ukraine is actually very near slovenia. Slovenia, Hungary, Ukraine.
Najlepsa hvala se enkrat in uzivaj se naprej. Lep pozdrav,ivan.
----- Original Message -----
From: "slipch"
To: "Ivan Bolcina"
Sent: Tuesday, October 22, 2002 9:40 AM
Subject: Re: ode to directx coordinates and orientation
> Hello Ivan,
>
> Monday, October 21, 2002, 10:13:36 PM, you wrote:
>
> IB> //from ode to directx
> IB> D3DXVECTOR3 convertVector(const dReal *in)
> IB> {
> IB> D3DXVECTOR3 out;
> IB> out.x=in[0];
> IB> out.y=in[1];
> IB> out.z=in[2];
> IB> return out;
> IB> }
>
> IB> //from ode to directx
>
> IB> D3DXQUATERNION convertQuaternion(const dReal *in)
> IB> {
> IB> D3DXQUATERNION out;
> IB> out.x=(float)in[0];
> IB> out.y=(float)in[1];
> IB> out.z=(float)in[2];
> IB> out.w=-(float)in[3];
> IB> return out;
> IB> }
>
>
> IB> So ODE is doing steps on objects and then I need to display it with
directx in corrent position and orientation. Position seem to be ok, but
orientation.....
>
> IB> btw, I see you are professional game developer. How does it feel like?
> I am doing my best to be it but I am only in the start :).
> I translate DirectX transforms to ode and vise versa and
> everything works right (As I already tell you it need to transpose
DirectX matrix before
> set it as ODE rotation matrix.). But I have never translate
> Quaternion.
> Following DirectX doc quaternion is
>
> q.x = sin(theta/2) * axis.x
> q.y = sin(theta/2) * axis.y
> q.z = sin(theta/2) * axis.z
> q.w = cos(theta/2)
>
> From ODE doc:
>
> A quaternion is four numbers [cos(theta/2) sin(theta/2)*u]
> where theta is a rotation angle and `u' is a unit length rotation
axis.
>
> May be the problem in sequence cos(theta/2) - last in DIrectX and
> first in ODE. Then
>
> D3DXQUATERNION convertQuaternion(const dReal *in)
> {
> D3DXQUATERNION out;
> out.x=(float)in[1];
> out.y=(float)in[2];
> out.z=(float)in[3];
> out.w=(float)in[0];
> return out;
> }
>
> IB> Lep pozdrav in dobro se imej tam v mrzli Rusiji. :-)
> It is nearly understandable.
> I am from Ukraine indeed.
>
> Nashi najkrashi pobazsannya! :)
>
>
> --
> Best regards,
> slipch mailto:slipch@gsc-game.kiev.ua
>
From ivan.bolcina at volja.net Tue Oct 22 02:06:01 2002
From: ivan.bolcina at volja.net (Ivan Bolcina)
Date: Tue Oct 22 02:06:01 2002
Subject: [ODE] Re: ode to directx coordinates and orientation
References: <000e01c27935$f510c620$0100a8c0@vectra> <642235524.20021022104030@gsc-game.kiev.ua>
Message-ID: <001a01c279a9$9e142730$0100a8c0@vectra>
Hi,slipch.
Thank you VERY much. It works great.
So for anyone interested, here is transformation from ODE quaternion to
DirectX's.
D3DXQUATERNION convertQuaternion(const dReal *in)
{
D3DXQUATERNION out;
out.x=(float)in[1];
out.y=(float)in[2];
out.z=(float)in[3];
out.w=(float)in[0];
return out;
}
Ukraine is actually very near slovenia. Slovenia, Hungary, Ukraine.
Najlepsa hvala se enkrat in uzivaj se naprej. Lep pozdrav,ivan.
----- Original Message -----
From: "slipch"
To: "Ivan Bolcina"
Sent: Tuesday, October 22, 2002 9:40 AM
Subject: Re: ode to directx coordinates and orientation
> Hello Ivan,
>
> Monday, October 21, 2002, 10:13:36 PM, you wrote:
>
> IB> //from ode to directx
> IB> D3DXVECTOR3 convertVector(const dReal *in)
> IB> {
> IB> D3DXVECTOR3 out;
> IB> out.x=in[0];
> IB> out.y=in[1];
> IB> out.z=in[2];
> IB> return out;
> IB> }
>
> IB> //from ode to directx
>
> IB> D3DXQUATERNION convertQuaternion(const dReal *in)
> IB> {
> IB> D3DXQUATERNION out;
> IB> out.x=(float)in[0];
> IB> out.y=(float)in[1];
> IB> out.z=(float)in[2];
> IB> out.w=-(float)in[3];
> IB> return out;
> IB> }
>
>
> IB> So ODE is doing steps on objects and then I need to display it with
directx in corrent position and orientation. Position seem to be ok, but
orientation.....
>
> IB> btw, I see you are professional game developer. How does it feel like?
> I am doing my best to be it but I am only in the start :).
> I translate DirectX transforms to ode and vise versa and
> everything works right (As I already tell you it need to transpose
DirectX matrix before
> set it as ODE rotation matrix.). But I have never translate
> Quaternion.
> Following DirectX doc quaternion is
>
> q.x = sin(theta/2) * axis.x
> q.y = sin(theta/2) * axis.y
> q.z = sin(theta/2) * axis.z
> q.w = cos(theta/2)
>
> From ODE doc:
>
> A quaternion is four numbers [cos(theta/2) sin(theta/2)*u]
> where theta is a rotation angle and `u' is a unit length rotation
axis.
>
> May be the problem in sequence cos(theta/2) - last in DIrectX and
> first in ODE. Then
>
> D3DXQUATERNION convertQuaternion(const dReal *in)
> {
> D3DXQUATERNION out;
> out.x=(float)in[1];
> out.y=(float)in[2];
> out.z=(float)in[3];
> out.w=(float)in[0];
> return out;
> }
>
> IB> Lep pozdrav in dobro se imej tam v mrzli Rusiji. :-)
> It is nearly understandable.
> I am from Ukraine indeed.
>
> Nashi najkrashi pobazsannya! :)
>
>
> --
> Best regards,
> slipch mailto:slipch@gsc-game.kiev.ua
>
From facontidavide at hotmail.com Tue Oct 22 08:25:02 2002
From: facontidavide at hotmail.com (Edgard Oscuro)
Date: Tue Oct 22 08:25:02 2002
Subject: [ODE] Get the motor torque
Message-ID:
Hi everyone.
I am using ODE to simulate a humanoid robot (and it seems I am not the only
one!).
Usually we use the motors making them give a fixed velocity.
I need to know the TORQUE genereted by the motor to have that velocity.
Someone can suggest me how?
I suppose I have to modify the code to create my how function, but where can
I take this value?
Thanks,
Davide
_________________________________________________________________
Chiacchiera con gli amici online, prova MSN Messenger!
http://messenger.msn.it
From ivan.bolcina at volja.net Tue Oct 22 11:50:02 2002
From: ivan.bolcina at volja.net (Ivan Bolcina)
Date: Tue Oct 22 11:50:02 2002
Subject: [ODE] This is corect, I hope?
Message-ID: <001201c279fb$b4114ca0$0100a8c0@vectra>
This is a multi-part message in MIME format.
------=_NextPart_000_000F_01C27A0C.73C51FD0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi.=20
Is this function, which converts ODE vector to DirectX's, correct? It =
appears so, exept for the mass to body assignment.
bye,ivan
D3DXVECTOR3 convertVector(const dReal *in)
{
D3DXVECTOR3 out;
out.x=3Din[0];
out.y=3Din[1];
out.z=3Din[2];
return out;
}
------=_NextPart_000_000F_01C27A0C.73C51FD0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi.
Is this function, which converts ODE =
vector to=20
DirectX's, correct? It appears so, exept for the mass to body=20
assignment.
bye,ivan
D3DXVECTOR3 convertVector(const dReal *in)
{