, 0, 0, 1) = (it's a hinge2 joint with z and y axis, but I'm pretty sure that the z = axis is *not* the one the wheel rotates about). Neither of those = approaches fixes the original problem, but I can at least steer =3D) Help! =3D) Thanks in advance for any ideas. Peter. ------=_NextPart_000_006C_01C20A80.3525B330 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi - I posted this and got no replies, = so I'm=20 asking again =3D)

p.s. should the axis passed=20 into dBodySetFiniteRotationAxis be the swiftly rotating axis in = model space=20 or word space? (I was using model space)

Cheers,

Peter.

----- Original Message -----
From:=20 kaffiene=20
To: ODE List

Sent: Friday, May 31, 2002 8:59 = PM

Subject: [ODE] Wheels bending = ;-)

Hi All,

I've come across a problem which = seems to be=20 mentioned in the docs (section 11.9) - the problem of wheels on a car = moving=20 out of alignment under fast rotations.

I've applied the recommended fix=20 (dBodySetFiniteRotationMode(<each wheel body.>, 1) when bodies = are=20 created, and dBodySetFiniteRotationAxis(<each wheel body>, 0, 1, = 0)=20 before or after each time step of the simulation) but it doesn't seem = to=20 work. When I use the setFiniteRotationAxis with axis y as above, = I=20 cannot steer my car at all!

Anyone come accross this = before? Any=20 ideas?

p.s. I have tried using=20 dBodySetFiniteRotationAxis(<each wheel body>, 0, 0, 0) and=20 dBodySetFiniteRotationAxis(<each wheel body>, 0, 0, 1) (it's a = hinge2=20 joint with z and y axis, but I'm pretty sure that the z axis is *not* = the one=20 the wheel rotates about). Neither of those approaches fixes the = original=20 problem, but I can at least steer =3D)

Help! =3D)

Thanks in advance for any = ideas.

Peter.

------=_NextPart_000_006C_01C20A80.3525B330-- From Daniel.Groll at t-online.de Sun Jun 2 08:30:02 2002 From: Daniel.Groll at t-online.de (Daniel.Groll@t-online.de) Date: Sun Jun 2 08:30:02 2002 Subject: [ODE] Wheels bending ;-) Message-ID: <1023029211.3cfa2fdb850d2@webmail.t-online.de> Hi! I have posted a similar question a few days ago. I can't provide a solution to the problem, but I discovered some tips: 1. For your steering axis use Hinge parameters "dParamLoStop", "dParamHiStop" instead of "dParamVel2" (as mentioned in the source of the buggy sample) 2. Take a hinge (not hinge2) joint for the non-steering axis. 3. Don't put additional velocity on the steering axis. Use the non-steering for the impellent. 4. Check the speed of rotation frequently (I do this every time step) with "dJointGetHingeAngleRate", and if the wheel rotates too fast, break it down (e.g. dJointSetHingeParam(wheeljoint, dParamVel, 0)). The reason is, if the car turns at higher speed, often a wheel gets off the ground and begins to rotate very fast almost immediately (or is there a parameter to limit the rotation in advance??). Hope this helps, Daniel From kaffiene at xtra.co.nz Mon Jun 3 15:19:02 2002 From: kaffiene at xtra.co.nz (kaffiene) Date: Mon Jun 3 15:19:02 2002 Subject: [ODE] Wheels bending ;-) References: <1023029211.3cfa2fdb850d2@webmail.t-online.de> Message-ID: <000001c20b4c$1976a0a0$8a4136d2@growltiger> Hi Thanks for the ideas. I'm using (1) already since my code is based on the test buggy code - but I'm using four steering/driving wheels using hinge2s. I tried tip (4) - but using the hinge2 equivallents - and it's still broken. Can anybody else help? I'm a graphics guy, not a physics guy so I'm kinda stuck =) Cheers, Peter. ----- Original Message ----- From: To: Sent: Monday, June 03, 2002 3:28 AM Subject: Re: [ODE] Wheels bending ;-) > Hi! > > I have posted a similar question a few days ago. I can't provide a > solution to the problem, but I discovered some tips: > > 1. For your steering axis use Hinge parameters "dParamLoStop", > "dParamHiStop" instead of "dParamVel2" (as mentioned in the source of > the buggy sample) > 2. Take a hinge (not hinge2) joint for the non-steering axis. > 3. Don't put additional velocity on the steering axis. Use the > non-steering for the impellent. > 4. Check the speed of rotation frequently (I do this every time step) > with "dJointGetHingeAngleRate", and if the wheel rotates too fast, > break it down (e.g. dJointSetHingeParam(wheeljoint, dParamVel, 0)). The > reason is, if the car turns at higher speed, often a wheel gets off the > ground and begins to rotate very fast almost immediately (or is there a > parameter to limit the rotation in advance??). > > Hope this helps, > > Daniel > _______________________________________________ > ODE mailing list > ODE@q12.org > http://q12.org/mailman/listinfo/ode From Filipe Dias" <000001c20b4c$1976a0a0$8a4136d2@growltiger> Message-ID: <004401c20bdb$4f3657a0$4601a8c0@intranet.mind.pt> Ok, I have to admit I haven´t yet really dug into the use of ODE (lack of time, no spare time, no time extension, and smashed my car (the real one))... but, I can suggest something I would try in that case. I would try to bypass the mystery part, and do it my own way: instead of letting ODE solve the angle of the weels, I would impose one. I would probably have four joints of rotation over a single axis, and each time a simulation step is taken, I would readjust the angle to have the disired value. Hey, this isn't the solution to the problem, and it has disadvantages... This is only a shortcut to see something working.. This way there is no interference from the wheelspin in the speed you turn the steeringwheel.. there may be outher aspacts, but discard them for my needs... See if this works, or if it is adequate to do (as I mentioned before, I haven't learned ODE enough) I don't rememer if there is drawback in starting a new simulation with some values of the previous one but with a new angl value... Fil. From anders.olofsson at licentiaten.umea.hsb.se Tue Jun 4 09:16:02 2002 From: anders.olofsson at licentiaten.umea.hsb.se (Anders Olofsson) Date: Tue Jun 4 09:16:02 2002 Subject: [ODE] ODE and msvc Message-ID: <3CFCE78E.7209132B@licentiaten.umea.hsb.se> Ok, I'm a msvc weenie.. Is it possible to set up my own ode lib workspace from the ide, instead of using makefiles and stuff? Or to download some prebuild .lib file. From Filipe Dias" Message-ID: <006801c20be5$2d1e1e00$4601a8c0@intranet.mind.pt> Just a question: isn't a prebuild .lib the same thing we get when we "make.exe" the ODE? what is the problem of executing make.exe? (provided the \Program Files\Microsoft Visual Studio\VC98\Bin\VCVARS32.bat is executed before) Well it is inconvenient if we keep altering the ODE source and compiling it, but I don't do that often :-) Fil. ----- Original Message ----- From: "Anders Olofsson" To: Sent: Tuesday, June 04, 2002 5:15 PM Subject: [ODE] ODE and msvc > Ok, I'm a msvc weenie.. Is it possible to set up my own ode lib > workspace from the ide, instead of using makefiles and stuff? > > Or to download some prebuild .lib file. > _______________________________________________ > ODE mailing list > ODE@q12.org > http://q12.org/mailman/listinfo/ode > > From jason at 379.com Tue Jun 4 10:19:01 2002 From: jason at 379.com (J. Perkins) Date: Tue Jun 4 10:19:01 2002 Subject: [ODE] ODE and msvc References: <3CFCE78E.7209132B@licentiaten.umea.hsb.se> Message-ID: <3CFCF423.1000802@379.com> Anders Olofsson wrote: > Ok, I'm a msvc weenie.. Is it possible to set up my own ode lib > workspace from the ide, instead of using makefiles and stuff? Yes, it's easy. Just create a .LIB project in MSVC and put in all of the source files (except for drawstuff and the examples, obviously). Jason 379 From anders.olofsson at licentiaten.umea.hsb.se Tue Jun 4 10:44:02 2002 From: anders.olofsson at licentiaten.umea.hsb.se (Anders Olofsson) Date: Tue Jun 4 10:44:02 2002 Subject: [ODE] ODE and msvc References: <3CFCE78E.7209132B@licentiaten.umea.hsb.se> <006801c20be5$2d1e1e00$4601a8c0@intranet.mind.pt> Message-ID: <3CFCFC2C.BE3127BC@licentiaten.umea.hsb.se> Oups.. It was a combination of a missing .dll and not running that .bat file that stoped me. Thanks! Filipe Dias wrote: > > Just a question: isn't a prebuild .lib the same thing we get when we "make.exe" > the ODE? what is the problem of executing make.exe? (provided the \Program > Files\Microsoft Visual Studio\VC98\Bin\VCVARS32.bat is executed before) > > Well it is inconvenient if we keep altering the ODE source and compiling it, but > I don't do that often :-) > > Fil. From anders.olofsson at licentiaten.umea.hsb.se Tue Jun 4 10:51:02 2002 From: anders.olofsson at licentiaten.umea.hsb.se (Anders Olofsson) Date: Tue Jun 4 10:51:02 2002 Subject: [ODE] ODE and msvc References: <3CFCE78E.7209132B@licentiaten.umea.hsb.se> <3CFCF423.1000802@379.com> Message-ID: <3CFCFDD1.F880EAC7@licentiaten.umea.hsb.se> Ok. Got the makefile stuff working now though. There were duplicate headerfiles (objects.h I think) and config.h missing.. And then some directory structure is used in the #include statements.. Made it difficult just copying the files into a project. > Yes, it's easy. Just create a .LIB project in MSVC and put > in all of the source files (except for drawstuff and the > examples, obviously). > From ashok at globalsoft.co.in Thu Jun 6 01:33:09 2002 From: ashok at globalsoft.co.in (Ashokkumar) Date: Thu Jun 6 01:33:09 2002 Subject: [ODE] ODE.lib linkage errrors(2) Message-ID: <000a01c20d34$969ae7f0$5a00a8c0@ashok> This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C20D62.ACE46300 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, i have downloaded carterrain source and trying to compile it. i have downloaded allegro,allegrogl and ode latest. all are compiled fine,but i'm getting the following linkage errors of = ode, ode.lib(space.obj) : error LNK2001: unresolved external symbol __ftol2 ode.lib(misc.obj) : error LNK2001: unresolved external symbol __ftol2 ode.lib(error.obj) : error LNK2001: unresolved external symbol = __imp__MessageBoxA@16 can u help to sove this problem please reply me asap. thanks & regards ashokkumar ------=_NextPart_000_0007_01C20D62.ACE46300 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

i have downloaded carterrain source and = trying to=20 compile it.

i have downloaded allegro,allegrogl and = ode=20 latest.

all are compiled fine,but i'm getting = the following=20 linkage errors of ode,

ode.lib(space.obj) : error LNK2001: = unresolved=20 external symbol __ftol2
ode.lib(misc.obj) : error LNK2001: unresolved = external symbol __ftol2
ode.lib(error.obj) : error LNK2001: = unresolved=20 external symbol __imp__MessageBoxA@16

can u help to sove this = problem

please reply me asap.

thanks & regards

ashokkumar

------=_NextPart_000_0007_01C20D62.ACE46300-- From dylan.banarse at creaturelabs.com Thu Jun 6 05:17:02 2002 From: dylan.banarse at creaturelabs.com (Dylan Banarse) Date: Thu Jun 6 05:17:02 2002 Subject: [ODE] Job Offered: Physics Simulation Programmer Message-ID: <408CF8163395D411B8B4006097D902DA012ECA2C@phoenix.cyberlife.co.uk> Position available to work on a groundbreaking artificial-life, cross-media entertainment project for Creature Labs in Cambridge, England. Based on Artificial-life the project involves evolution, distributed artificial worlds and mass audiences. The candidate will work within a team of developers and will be responsible for customising and optimising 3D real-time physics engines for particular applications. The primary requirement of the candidate is a strong background in applied mathematics and numerical algorithm optimisation. Experience working with 3D real-time physics engines is essential. The candidate will be working in C++ and C, experience in processor optimisation would be a bonus. Must work well within a team and be capable of working to tight deadlines in a dynamic environment. An interest in Artificial-Life is required, particular interest in evolutionary systems, neural networks and control theory would be beneficial. The position is due to open summer/autumn 2002 and Creature Labs will be interviewing for the best candidate in the preceding period. Competitive salaries for the right candidate! Contact sarah.reardon@creaturelabs.com with CV, references and details. www.creaturelabs.com From peanutt at iprimus.com.au Fri Jun 7 03:31:02 2002 From: peanutt at iprimus.com.au (Adam Robinson) Date: Fri Jun 7 03:31:02 2002 Subject: [ODE] Expieranced ODE User Message-ID: <002001c20e0e$a82f5340$a0d832d2@peanutt> This is a multi-part message in MIME format. ------=_NextPart_000_001D_01C20E62.78CED540 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Heyas, Im looking for someone with expierance with ODE to help port into a game = engine we are using to create a story driven car racing game. We have a pending deal = with a large scaled Australian muscle car magazine to help proived funding and assistance. = We are looking to present a demo to Codemasters who have said to provide them with a = working demo.=20 At the moment it would be a non paid job to help complete a working demo = of the game. We have a full art team and only one programmer tho ( the lead guy = decided hed quit) that would handle the 3d engine side of the game. Any help or assistance would be appreciated. Cheers Adam ------=_NextPart_000_001D_01C20E62.78CED540 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Heyas,

Im looking for someone with expierance = with ODE to=20 help port into a game engine we are

using to create a story driven car = racing game. We=20 have a pending deal with a large scaled

Australian muscle car magazine to help = proived=20 funding and assistance. We are looking to

present a demo to Codemasters who have = said to=20 provide them with a working demo.

At the moment it would be a non paid = job to help=20 complete a working demo of the game.

We have a full art team and only one = programmer tho=20 ( the lead guy decided hed quit) that would

handle the 3d engine side of the = game.

Any help or assistance would be=20 appreciated.

Cheers

Adam

------=_NextPart_000_001D_01C20E62.78CED540-- From martin at metahuman.org Fri Jun 7 06:21:02 2002 From: martin at metahuman.org (Martin C. Martin) Date: Fri Jun 7 06:21:02 2002 Subject: [ODE] Expieranced ODE User References: <002001c20e0e$a82f5340$a0d832d2@peanutt> Message-ID: <3D00B31C.1CE23E95@metahuman.org> > Im looking for someone with expierance with ODE to help port into a > game engine we are > using to create a story driven car racing game. You realize ODE is distributed under the LGPL right? And that means you need to provide the source to the lib, and a way for anyone who hacks it to link their changes into the game? So people will be able to reduce gravity, change friction, or even completely replace the physics engine if they want? If so, that'll be a lot of fun. :) Does the company providing the funding know that? Does the deal you're about to sign allow that? Note: I'm not a lawyer, but that's my understanding of the LGPL. I suggest you show both the deal you're signing and ODE's LICENSE.TXT file to your lawyer. Thought you'd want to know now rather than later, Martin From francis.irving at creaturelabs.com Fri Jun 7 06:35:01 2002 From: francis.irving at creaturelabs.com (Francis Irving) Date: Fri Jun 7 06:35:01 2002 Subject: [ODE] Expieranced ODE User In-Reply-To: <3D00B31C.1CE23E95@metahuman.org> References: <002001c20e0e$a82f5340$a0d832d2@peanutt> <3D00B31C.1CE23E95@metahuman.org> Message-ID: On Fri, 07 Jun 2002 09:20:28 -0400, "Martin C. Martin" wrote: >You realize ODE is distributed under the LGPL right? And that means you >need to provide the source to the lib, and a way for anyone who hacks it >to link their changes into the game? So people will be able to reduce >gravity, change friction, or even completely replace the physics engine >if they want? If so, that'll be a lot of fun. :) > >Does the company providing the funding know that? Does the deal you're >about to sign allow that? In practice it isn't a problem. If they link ODE into a separate "ode.dll", and provide their source code changes somewhere, then that's fine. Publishers, and most customers, won't even know or understand this subtle distinction, and their contracts almost certainly won't mention it. It's really no different from dynamically linking to DirectX, or even user32.dll. As professional programmers, we set the agenda as to what level of open source code reuse is acceptable in a commercial application (before the whole thing is effectively open source). There's no need to fear that power. Francis From anselm at hook.org Fri Jun 7 10:20:02 2002 From: anselm at hook.org (Anselm Hook) Date: Fri Jun 7 10:20:02 2002 Subject: [ODE] Expieranced ODE User In-Reply-To: Message-ID: I can already see that debating this here isn't going to go far without some kind of action! I looked at the LGPL just now and there certainly seems to be some ambiguity, such as clause 5 about what constitutes a derivative work or not. Honestly I think the LGPL is a pernicious license and complex enough that it would scare investors - it certainly scares me. May I suggest that the best action to do is ask Russ to liberalize the license more for you (even if you are confident that you have no liability under the LGPL). Your investors (who may not be schooled in the LGPL) would appreciate the clarity anyway. Basically I just don't see any resolution here at a discussion level without consulting Russ. -a On Fri, 7 Jun 2002, Francis Irving wrote: > On Fri, 07 Jun 2002 09:20:28 -0400, "Martin C. Martin" > wrote: > > >You realize ODE is distributed under the LGPL right? And that means you > >need to provide the source to the lib, and a way for anyone who hacks it > >to link their changes into the game? So people will be able to reduce > >gravity, change friction, or even completely replace the physics engine > >if they want? If so, that'll be a lot of fun. :) > > > >Does the company providing the funding know that? Does the deal you're > >about to sign allow that? > > In practice it isn't a problem. If they link ODE into a separate > "ode.dll", and provide their source code changes somewhere, then > that's fine. Publishers, and most customers, won't even know or > understand this subtle distinction, and their contracts almost > certainly won't mention it. > > It's really no different from dynamically linking to DirectX, or even > user32.dll. As professional programmers, we set the agenda as to what > level of open source code reuse is acceptable in a commercial > application (before the whole thing is effectively open source). > There's no need to fear that power. > > Francis > _______________________________________________ > ODE mailing list > ODE@q12.org > http://q12.org/mailman/listinfo/ode > From ericc at xenopi.com Sat Jun 8 00:29:01 2002 From: ericc at xenopi.com (Eric Cha) Date: Sat Jun 8 00:29:01 2002 Subject: [ODE] Newbie question Message-ID: <004301c20ebe$190f1870$6401a8c0@donald> Hi, I'm playing around with ODE (very cool and a whole lot more stable than my crude and amateur physics code). One question I have is, what/where is the file "dcCore.h"? I am trying to integrate the Tri-list collider code (in the "contrib" directory) and it is trying to include this file, but I can't find it anywhere in ODE, Contrib, or Opcode. Can someone illuminate this poor unfortunate soul? Thanks, Eric --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.365 / Virus Database: 202 - Release Date: 5/24/2002 From erwin at vo.com Sat Jun 8 03:30:02 2002 From: erwin at vo.com (Erwin de Vries) Date: Sat Jun 8 03:30:02 2002 Subject: [ODE] Newbie question References: <004301c20ebe$190f1870$6401a8c0@donald> Message-ID: <004c01c20ed7$5c669760$0101a8c0@athlon> You should get a more recent version .The first version wasnt compilable. The current (2nd) version is. Erwin ----- Original Message ----- From: "Eric Cha" To: Sent: Saturday, June 08, 2002 09:28 Subject: [ODE] Newbie question > Hi, > > I'm playing around with ODE (very cool and a whole lot more stable than > my crude and amateur physics code). One question I have is, what/where > is the file "dcCore.h"? I am trying to integrate the Tri-list collider > code (in the "contrib" directory) and it is trying to include this file, > but I can't find it anywhere in ODE, Contrib, or Opcode. Can someone > illuminate this poor unfortunate soul? > > Thanks, > > Eric > > --- > Outgoing mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.365 / Virus Database: 202 - Release Date: 5/24/2002 > > > _______________________________________________ > ODE mailing list > ODE@q12.org > http://q12.org/mailman/listinfo/ode > > From SkeedaddIer at aol.com Sun Jun 9 08:57:01 2002 From: SkeedaddIer at aol.com (SkeedaddIer@aol.com) Date: Sun Jun 9 08:57:01 2002 Subject: [ODE] collision detection/response without using ODE's collision engine Message-ID: <63.cb4af31.2a34d491@aol.com> Hi, I am confused as to how to do collision detection/response of SPHERE objects against PLANES, without using ODE's internal collision engine. For example, I am trying to hack the test_boxstack.cpp file to handle bouncing of spheres against the ground plane when the user presses 's'. What i did: 1) i removed the nearCallback function and the dSpaceCollide function that calls it 2) i defined a groundplane struct containing a dBodyID/dGeomID with a position of 0,0,0 and normal of 0,0,1 groundplane.body = dBodyCreate(world); dBodySetPosition(groundplane.body, 0, 0, 0); groundplane.geom[0] = dCreatePlane (space,0,0,1,0); 3) during simLoop, i coded a simple test where: const dReal *p = dBodyGetPosition(obj[i].body); const dReal *v = dBodyGetLinearVel(obj[i].body); //vector3 is a personal vector lib I use, not part of ODE & also well tested vector3 position = vector3(p[0], p[1], p[2]); vector3 velocity = vector3(v[0], v[1], v[2]); vector3 newposition = position + velocity; if((newposition.z - sphere.radius) <= 0.0f) { //..filled in dContact struct here - see 4) below... dJointID c = dJointCreateContact (world, contactgroup, &contact); dJointAttach(c, obj[i].body, groundplane.body); } 4) this is how I filled my dContact struct: dVector3 contactposition = {newposition.x, newposition.y, (newposition.z - sphere.radius)}; dVector3 contactnormal = {0.0, 0.0, 1.0}; dContact contact; contact.surface.mode = dContactBounce; //dContactMu2; contact.surface.mu = dInfinity; contact.surface.mu2 = 0; contact.surface.bounce = 1.0; contact.surface.bounce_vel = 0.1; contact.geom.pos = contactposition; contact.geom.normal = contactnormal; contact.geom.depth = 0; contact.geom.g1 = obj[i].geom[0]; contact.geom.g2 = groundplane.geom[0]; 5) lastly i called dWorldStep as shown in the source. The spheres are not bouncing as they are expected to. Anyone have ideas what i may be doing wrong? Thanks in advance. From Ken M" Message-ID: <003301c20fd0$30762ae0$4502a8c0@samson> Your contact depth is 0, which I think will never result in a bounce, as there is no interpenetration to recover from. Ken ----- Original Message ----- From: To: Sent: Sunday, June 09, 2002 11:56 AM Subject: [ODE] collision detection/response without using ODE's collision engine > Hi, > > I am confused as to how to do collision detection/response of SPHERE > objects against PLANES, without using ODE's internal collision engine. > > For example, I am trying to hack the test_boxstack.cpp file to handle > bouncing of spheres against the ground plane when the user presses 's'. > > What i did: > > 1) i removed the nearCallback function and the dSpaceCollide function > that calls it > > 2) i defined a groundplane struct containing a dBodyID/dGeomID with a > position of 0,0,0 and normal of 0,0,1 > > groundplane.body = dBodyCreate(world); > dBodySetPosition(groundplane.body, 0, 0, 0); > groundplane.geom[0] = dCreatePlane (space,0,0,1,0); > > 3) during simLoop, i coded a simple test where: > > const dReal *p = dBodyGetPosition(obj[i].body); > const dReal *v = dBodyGetLinearVel(obj[i].body); > > //vector3 is a personal vector lib I use, not part of ODE & also > well tested > vector3 position = vector3(p[0], p[1], p[2]); > vector3 velocity = vector3(v[0], v[1], v[2]); > vector3 newposition = position + velocity; > > if((newposition.z - sphere.radius) <= 0.0f) { > //..filled in dContact struct here - see 4) below... > dJointID c = dJointCreateContact (world, contactgroup, &contact); > dJointAttach(c, obj[i].body, groundplane.body); > } > > > 4) this is how I filled my dContact struct: > > dVector3 contactposition = {newposition.x, > newposition.y, > (newposition.z - > sphere.radius)}; > > dVector3 contactnormal = {0.0, 0.0, 1.0}; > > dContact contact; > > contact.surface.mode = dContactBounce; //dContactMu2; > contact.surface.mu = dInfinity; > contact.surface.mu2 = 0; > contact.surface.bounce = 1.0; > contact.surface.bounce_vel = 0.1; > > contact.geom.pos = contactposition; > contact.geom.normal = contactnormal; > contact.geom.depth = 0; > contact.geom.g1 = obj[i].geom[0]; > contact.geom.g2 = groundplane.geom[0]; > > 5) lastly i called dWorldStep as shown in the source. > > The spheres are not bouncing as they are expected to. Anyone have > ideas what i may be doing wrong? Thanks in advance. > _______________________________________________ > ODE mailing list > ODE@q12.org > http://q12.org/mailman/listinfo/ode From eli at nuprometheus.com Mon Jun 10 13:47:02 2002 From: eli at nuprometheus.com (Eli Curtz) Date: Mon Jun 10 13:47:02 2002 Subject: [ODE] Optimizing for SIMD Message-ID: Hi all, This may be insane, but I just got the PS2 Linux kit and was idly considering porting ODE to it. Doing this "right" would involve implementing portions on the vector unit of the PS2. Has anybody out there thought about trying to optimize ODE for Altivec, SSE, or anything similar? I'm a little bit scared of the LCP solver, but it's only a few hundred lines of code, how hard could it be? - eli -- Eli Curtz Sycophant to the Stars eli@nuprometheus.com From stjaerna at mac.com Tue Jun 11 11:46:02 2002 From: stjaerna at mac.com (jon klein) Date: Tue Jun 11 11:46:02 2002 Subject: [ODE] Setting torque imparted by a hinge joint Message-ID: <4B286284-7D6B-11D6-A1F9-0003936A7C02@mac.com> Hi folks, in my application, I'd like to be able to set the torque applied to hinge joints. I see that the preferred way to use a hinge joint is to set the preferred speed of the joint, but I need to be able to set the torque explicitly for compatibility with my current physical simulator. First of all, is it possible that a future version of ODE might allow the joint torque to be a parameter that can be set in the joint? Secondly, in trying to do this manually, I seem to be getting the wrong results. Simulating hinge torque would impart both a torque and center of mass force on the body, but I suspect that the force I'm applying is somehow wrong, since the whole articulated body is picking up angular velocity in a way that it shouldn't be. Here are the forces I'm applying: For a hinge joint (with normal n) applying a torque T on a body (with center C relative to the hinge), the body's center of mass torque should be nT and the instantaneous center of mass force should be the cross product nT x C. Both of these forces are relative to the body's frame. Is this not correct? Any help is greatly appreciated! Thanks! - Jon From coding at natew.com Tue Jun 11 12:04:01 2002 From: coding at natew.com (Nate W) Date: Tue Jun 11 12:04:01 2002 Subject: [ODE] GETting torque imparted by a hinge joint In-Reply-To: <4B286284-7D6B-11D6-A1F9-0003936A7C02@mac.com> Message-ID: On Tue, 11 Jun 2002, jon klein wrote: > First of all, is it possible that a future version of ODE might > allow the joint torque to be a parameter that can be set in the > joint? On a related note, I'd like to be able to do the reverse - to *get* the force applied to a joint during the previous timestep, e.g.: dReal force = dJointGetXxxxxParam (dJointID, dParamFActual); One of the next things I want to add to my app is a seismograph-style readout of joint positions, but joint torques would probably be even more useful. Thanks, Nate Waddoups Redmond WA USA http://www.natew.com From duhprey at tosos.com Tue Jun 11 12:56:01 2002 From: duhprey at tosos.com (Daniel Duhprey) Date: Tue Jun 11 12:56:01 2002 Subject: [ODE] Enabling/Disabling bodies In-Reply-To: Message-ID: In an attempt to optimize over static bodies, I have some code to set the geometry of a body to zero and then set the Disable that body (also removing any joints, so that it should be in a disabled island) ... Except that when I do this the geometry, which I'd still like to collide with, no longer collides. Everything is fine if the geometry is set to 0 initially. But if its set to a body and then later reset to body 0, it stops colliding. Any ideas? -- ------------ email: duhprey@tosos.com www: http://paradox.tosos.com/~duhprey icq: 129354442 The European finds intercourse with Americans easy and agreeable. Einstein Not a shred of evidence exists in favor of the idea that life is serious. Gill From grubertm at hotmail.com Wed Jun 12 19:02:02 2002 From: grubertm at hotmail.com (Marco Grubert) Date: Wed Jun 12 19:02:02 2002 Subject: [ODE] Collision detection for arbitrary polytopes ? Message-ID: Hello, While reading through the manual I was surprised by the lack of triangle / poly collision detection. So how do you simulate arbitrary 3d models? By duplicating them based on the collision primitives available to ODE or by using a different collision detection system ? Or did I just miss something in the docs ? Thanks, Marco Grubert From Nguyen Binh Wed Jun 12 19:51:02 2002 From: Nguyen Binh (Nguyen Binh) Date: Wed Jun 12 19:51:02 2002 Subject: [ODE] Collision detection for arbitrary polytopes ? In-Reply-To: References: Message-ID: <116920493.20020613093723@glassegg.com> Hi Marco, You can use Opcode to do that and fortunately ODE had incoporated with Opcode (ver 1.0 though not the latest version). Let see the contribs\Tri-collider in ODE dir. Opcode is http://www.codercorner.com/Opcode.htm A great col-det lib IMHO. -- 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 coding at natew.com Wed Jun 12 20:09:01 2002 From: coding at natew.com (Nate W) Date: Wed Jun 12 20:09:01 2002 Subject: [ODE] Collision detection for arbitrary polytopes ? In-Reply-To: Message-ID: On Wed, 12 Jun 2002, Marco Grubert wrote: > While reading through the manual I was surprised by the lack of triangle / > poly collision detection. So how do you simulate arbitrary 3d models? ODE itself only includes support for a handful of primitive objects, but it can be extended - and fortunately for us, it has been extended. Check out the 'triangle collider' code in the /ode/contrib/ CVS directory: http://q12.org/cgi-bin/cvsweb.cgi/ode/contrib/tri-collider/ I am using it to do collision detection against height-mapped terrain, and it's working nicely. > Or did I just miss something in the docs ? Documentation for this stuff is sparse, but that's what the mailing list is for. :-) -- Nate Waddoups Redmond WA USA http://www.natew.com From grubertm at hotmail.com Wed Jun 12 20:41:01 2002 From: grubertm at hotmail.com (Marco Grubert) Date: Wed Jun 12 20:41:01 2002 Subject: [ODE] Collision detection for arbitrary polytopes ? References: <116920493.20020613093723@glassegg.com> Message-ID: Dear Nguyen, Hey that´s great news- I have been using Opcode for the past few months already, that should make things easy. But how do you deal with Opcode not supplying penetration depth ? Ah well, I am gonna take a look at Tri-collider and figure it out. Thanks a lot, Marco Grubert > From a_mark_as3 at bk.ru Thu Jun 13 05:43:01 2002 From: a_mark_as3 at bk.ru (Andrey) Date: Thu Jun 13 05:43:01 2002 Subject: [ODE] (no subject) Message-ID: <000a01c212d8$8e04a460$1c5c83c3@wplus.net> This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C212FA.0DEAA280 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable Is received quite good and even competitive (and furthermore - = charge-free) engine. From joints there are no springs, and from geometry = - convex hulls. All remaining looks not bad. On my sight it is not necessary to give the special attention additional = features, and it is necessary to achieve the greatest stability of work. As a whole engine is almost completed and can be used in the serious = projects without the special modifications. Andrey Markovich - Russia - Programmer ------=_NextPart_000_0007_01C212FA.0DEAA280 Content-Type: text/html; charset="koi8-r" Content-Transfer-Encoding: quoted-printable

Is received quite good and even competitive (and furthermore - = charge-free)=20 engine. From joints there are no springs, and from geometry - convex = hulls. All=20 remaining looks not bad.

On my sight it is not necessary to give the special attention = additional=20 features, and it is necessary to achieve the greatest stability of = work.

As a whole engine is almost completed and can be used in the serious = projects=20 without the special modifications.

Andrey Markovich - Russia -=20 Programmer

Hi - I posted this and got no replies, = so I'm=20 asking again =3D)

p.s. should the axis passed=20 into dBodySetFiniteRotationAxis be the swiftly rotating axis in = model space=20 or word space? (I was using model space)

Cheers,

Peter.

----- Original Message -----
From:=20 kaffiene=20

To: ODE List

Sent: Friday, May 31, 2002 8:59 = PM

Subject: [ODE] Wheels bending = ;-)

Hi All,

I've come across a problem which = seems to be=20 mentioned in the docs (section 11.9) - the problem of wheels on a car = moving=20 out of alignment under fast rotations.

I've applied the recommended fix=20 (dBodySetFiniteRotationMode(<each wheel body.>, 1) when bodies = are=20 created, and dBodySetFiniteRotationAxis(<each wheel body>, 0, 1, = 0)=20 before or after each time step of the simulation) but it doesn't seem = to=20 work. When I use the setFiniteRotationAxis with axis y as above, = I=20 cannot steer my car at all!

Anyone come accross this = before? Any=20 ideas?

p.s. I have tried using=20 dBodySetFiniteRotationAxis(<each wheel body>, 0, 0, 0) and=20 dBodySetFiniteRotationAxis(<each wheel body>, 0, 0, 1) (it's a = hinge2=20 joint with z and y axis, but I'm pretty sure that the z axis is *not* = the one=20 the wheel rotates about). Neither of those approaches fixes the = original=20 problem, but I can at least steer =3D)

Help! =3D)

Thanks in advance for any = ideas.

Peter.

Hi,

i have downloaded carterrain source and = trying to=20 compile it.

i have downloaded allegro,allegrogl and = ode=20 latest.

all are compiled fine,but i'm getting = the following=20 linkage errors of ode,

can u help to sove this = problem

please reply me asap.

thanks & regards

ashokkumar

Heyas,

Im looking for someone with expierance = with ODE to=20 help port into a game engine we are

using to create a story driven car = racing game. We=20 have a pending deal with a large scaled

Australian muscle car magazine to help = proived=20 funding and assistance. We are looking to

present a demo to Codemasters who have = said to=20 provide them with a working demo.

At the moment it would be a non paid = job to help=20 complete a working demo of the game.

We have a full art team and only one = programmer tho=20 ( the lead guy decided hed quit) that would

handle the 3d engine side of the = game.

Any help or assistance would be=20 appreciated.

Cheers

Adam

Is received quite good and even competitive (and furthermore - = charge-free)=20 engine. From joints there are no springs, and from geometry - convex = hulls. All=20 remaining looks not bad.

On my sight it is not necessary to give the special attention = additional=20 features, and it is necessary to achieve the greatest stability of = work.

As a whole engine is almost completed and can be used in the serious = projects=20 without the special modifications.

Andrey Markovich - Russia -=20 Programmer

Hi - I posted this and got no replies, = so I'm=20 asking again =3D)

p.s. should the axis passed=20 into dBodySetFiniteRotationAxis be the swiftly rotating axis in = model space=20 or word space? (I was using model space)

Cheers,

Peter.

----- Original Message -----
From:=20 kaffiene=20

To: ODE List

Sent: Friday, May 31, 2002 8:59 = PM

Subject: [ODE] Wheels bending = ;-)

Hi All,

I've come across a problem which = seems to be=20 mentioned in the docs (section 11.9) - the problem of wheels on a car = moving=20 out of alignment under fast rotations.

Anyone come accross this = before? Any=20 ideas?

Help! =3D)

Thanks in advance for any = ideas.

Peter.

Hi,

i have downloaded carterrain source and = trying to=20 compile it.

i have downloaded allegro,allegrogl and = ode=20 latest.

all are compiled fine,but i'm getting = the following=20 linkage errors of ode,

can u help to sove this = problem

please reply me asap.

thanks & regards

ashokkumar

Heyas,

Im looking for someone with expierance = with ODE to=20 help port into a game engine we are

using to create a story driven car = racing game. We=20 have a pending deal with a large scaled

Australian muscle car magazine to help = proived=20 funding and assistance. We are looking to

present a demo to Codemasters who have = said to=20 provide them with a working demo.

At the moment it would be a non paid = job to help=20 complete a working demo of the game.

We have a full art team and only one = programmer tho=20 ( the lead guy decided hed quit) that would

handle the 3d engine side of the = game.

Any help or assistance would be=20 appreciated.

Cheers

Adam

Is received quite good and even competitive (and furthermore - = charge-free)=20 engine. From joints there are no springs, and from geometry - convex = hulls. All=20 remaining looks not bad.

On my sight it is not necessary to give the special attention = additional=20 features, and it is necessary to achieve the greatest stability of = work.

As a whole engine is almost completed and can be used in the serious = projects=20 without the special modifications.

Andrey Markovich - Russia -=20 Programmer

------=_NextPart_000_0007_01C212FA.0DEAA280-- From jason at 379.com Thu Jun 13 07:06:02 2002 From: jason at 379.com (J. Perkins) Date: Thu Jun 13 07:06:02 2002 Subject: [ODE] Collision detection for arbitrary polytopes ? References: Message-ID: <3D08A453.8080307@379.com> Nate W wrote: > http://q12.org/cgi-bin/cvsweb.cgi/ode/contrib/tri-collider/ > > I am using it to do collision detection against height-mapped terrain, and > it's working nicely. I'll take this opportunity to say that OPCODE 1.1 makes this integration with ODE a lot easier. I had no trouble getting a sphere-mesh test working within a day. If I ever get the chance to add tests for the other primitives I will package it up as a contrib, but for now you can get the source from my project at: http://www.379.com/f4/ Look here: F4/Services/Collider/Src/mesh.cpp (Thanks to Pierre for the lib and his help getting it working). Jason From jason at 379.com Thu Jun 13 07:10:02 2002 From: jason at 379.com (J. Perkins) Date: Thu Jun 13 07:10:02 2002 Subject: [ODE] Collision detection for arbitrary polytopes ? References: <116920493.20020613093723@glassegg.com> Message-ID: <3D08A56A.70809@379.com> Marco Grubert wrote: > Hey that´s great news- I have been using Opcode for the past few months > already, that should make things easy. But how do you deal with Opcode not > supplying penetration depth ? Opcode 1.1 does provide a penetration depth, at least for spheres, I haven't looked at the other shapes yet. But the workaround is to use Opcode to generate a list of colliding faces, then use a more sophisticated test on those faces to determine the depth. Jason 379 From p.terdiman at wanadoo.fr Thu Jun 13 07:23:01 2002 From: p.terdiman at wanadoo.fr (Pierre Terdiman) Date: Thu Jun 13 07:23:01 2002 Subject: [ODE] Collision detection for arbitrary polytopes ? References: <3D08A453.8080307@379.com> Message-ID: <006701c212e5$ec80a5e0$7401a8c0@nwpc1> And I'll take this opportunity to say that Opcode 1.2 has faster sphere-mesh tests (but still unreleased, no time - old song, I know). Two things provided huge speedups (in case someone can't wait and want to implement them) : - sphere-mesh queries can early exit as soon as the sphere totally contains a box of a node (hence we know it also contains all boxes of all children and we can directly dump the list of related triangles) - temporal coherence can help by using a slightly larger sphere for the query, and keeping track of touched triangles. Next frame, if the previously used larger sphere still contains current sphere, no need to do the query, we can reuse the list of triangles from the previous frame to compute the collision response. We'll get more triangles than strictly necessary, but overall it runs faster. It also works for other volumes of course, not only spheres. Pierre ----- Original Message ----- From: "J. Perkins" Cc: Sent: Thursday 13 June 2002 15:55 Subject: Re: [ODE] Collision detection for arbitrary polytopes ? > Nate W wrote: > > http://q12.org/cgi-bin/cvsweb.cgi/ode/contrib/tri-collider/ > > > > I am using it to do collision detection against height-mapped terrain, and > > it's working nicely. > > I'll take this opportunity to say that OPCODE 1.1 makes this > integration with ODE a lot easier. I had no trouble getting > a sphere-mesh test working within a day. If I ever get the > chance to add tests for the other primitives I will package > it up as a contrib, but for now you can get the source from > my project at: > > http://www.379.com/f4/ > > Look here: > > F4/Services/Collider/Src/mesh.cpp > > (Thanks to Pierre for the lib and his help getting it working). > > Jason > > > > _______________________________________________ > ODE mailing list > ODE@q12.org > http://q12.org/mailman/listinfo/ode From dmcclurg at pandemicstudios.com.au Thu Jun 13 21:20:02 2002 From: dmcclurg at pandemicstudios.com.au (David McClurg) Date: Thu Jun 13 21:20:02 2002 Subject: [ODE] are force accumulators zeroed if body is disabled? Message-ID: i'm lazy. does anyone know off hand about this? dBodyDisable (bodyID); dBodyAddForce (bodyID, fx, fy, fz); dWorldStep (worldID, stepsize); // should the force accumulators be set to zero after this integrator step for bodyID? dBodyEnable (bodyID); From dmcclurg at pandemicstudios.com.au Fri Jun 14 00:25:02 2002 From: dmcclurg at pandemicstudios.com.au (David McClurg) Date: Fri Jun 14 00:25:02 2002 Subject: [ODE] are force accumulators zeroed if body is disabled? Message-ID: I found that dBodyDisable() allows large force accumulators to build up. I suppose this is just a user error and not a bug but perhaps it could be documented. also, i have some memory leaks. for example, dSphereClass never gets freed. i don't see anywhere in ode that takes care of freeing dSphereClass. Am I missing something? thanks for a great lib in ode (opcode too) -----Original Message----- From: David McClurg Sent: Friday, 14 June 2002 2:21 PM To: ode@q12.org Subject: [ODE] are force accumulators zeroed if body is disabled? i'm lazy. does anyone know off hand about this? dBodyDisable (bodyID); dBodyAddForce (bodyID, fx, fy, fz); dWorldStep (worldID, stepsize); // should the force accumulators be set to zero after this integrator step for bodyID? dBodyEnable (bodyID); From Nguyen Binh Fri Jun 14 00:39:01 2002 From: Nguyen Binh (Nguyen Binh) Date: Fri Jun 14 00:39:01 2002 Subject: Re[2]: [ODE] Collision detection for arbitrary polytopes ? In-Reply-To: <3D08A56A.70809@379.com> References: <116920493.20020613093723@glassegg.com> <3D08A56A.70809@379.com> Message-ID: <18721443434.20020614143708@glassegg.com> Yes, Opcode does provide penetration depth in Sphere and Ray collides with a poly soup! But I can't see any in poly-poly (TreeCollider) test. But would we need to get penetration depth of two arbitrary poly soup? I think we won't, or at least won't need to "compute" things like that (Maybe a little cheat here by a fake value???). Maybe the art of GAME physics is not (or not yet) making something ACT real just LOOK real. -- 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 p.terdiman at wanadoo.fr Fri Jun 14 01:32:08 2002 From: p.terdiman at wanadoo.fr (Pierre Terdiman) Date: Fri Jun 14 01:32:08 2002 Subject: Re[2]: [ODE] Collision detection for arbitrary polytopes ? References: <116920493.20020613093723@glassegg.com> <3D08A56A.70809@379.com> <18721443434.20020614143708@glassegg.com> Message-ID: <000f01c2137e$04b0ae10$7401a8c0@nwpc1> > Yes, Opcode does provide penetration depth in Sphere and Ray collides > with a poly soup! But I can't see any in poly-poly (TreeCollider) > test. Because that's very hard to do for arbitrary meshes. I don't think a good, convincing solution exists, and the ones I've seen are too slow for realtime anyway. If I had to implement it for next week, I would probably decompose the mesh into convex parts using SWIFT++, use the hierarchy of convex hulls as a BV-tree, then use SOLID 3.0 on top of this to compute penetration depth between 2 hulls. Would work, for a very high price. Pierre From SkeedaddIer at aol.com Fri Jun 14 04:07:02 2002 From: SkeedaddIer at aol.com (SkeedaddIer@aol.com) Date: Fri Jun 14 04:07:02 2002 Subject: [ODE] collision detection/response without using ODE's collision engine Message-ID: <195.83dd588.2a3b2845@aol.com> Hi, Ken - I tried to setting depth to (sphere.z-sphere.radius) since it would equal the penetration depth of the sphere against the plane at 0.0f. The spheres still pass right thru the plane, no bouncy collision response. Figured it would help if you or anyone could look over the code and figure out why i'm not getting the right results, so I posted it at: www.qlink.org/test_boxstack.txt Hope someone can fix this, i'm at wits end trying to figure out the basics so I can build on from there. Thanks in advance! From si at sjbrown.co.uk Fri Jun 14 04:12:01 2002 From: si at sjbrown.co.uk (Si Brown) Date: Fri Jun 14 04:12:01 2002 Subject: [ODE] are force accumulators zeroed if body is disabled? Message-ID: Hi David, >also, i have some memory leaks. for example, dSphereClass never gets >freed. i don't see anywhere in ode that takes care of freeing >dSphereClass. Am I missing something? > >[snip] dGeomDestroy destroys any geometry class in a generic manner. It does so by removing it from the space, calling the class destructor (null for dSphereClass) and freeing the memory used by the class. Also, destroying a space using dSpaceDestroy automatically calls dGeomDestroy on every geometry object in that space. Hope that helps, Simon _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. From coding at natew.com Fri Jun 14 11:09:01 2002 From: coding at natew.com (Nate W) Date: Fri Jun 14 11:09:01 2002 Subject: [ODE] apparent memory leaks In-Reply-To: Message-ID: On Fri, 14 Jun 2002, Si Brown wrote: > >also, i have some memory leaks. for example, dSphereClass never gets > >freed. i don't see anywhere in ode that takes care of freeing > >dSphereClass. Am I missing something? I ran into the same thing, using MSVC's _CrtDumpMemoryLeaks to detect leakage. Are you using VC.Net? Anyhow... In ODE .025, the geometry class singletons were not freed, but it's not a problem because they're singletons (only one of each will ever be allocated) and the OS wipes the entire heap when the process terminates. So it's nothing to worry about. I still prefer a clean memory leak dump when my app closes, though. It beats having to scan a list of a half-dozen "leaks" and make sure there isn't an extra leak or two due to something wrong in my application code. So I wrote some code to explicitly free the singletons. My recall is pretty fuzzy here, as I haven't dealt with this since upgrading to .030, but... I think Russ put some cleanup code in .030 but now there's a timing issue - your app is probably calling _CrtDumpMemoryLeaks before ODE cleans up the singletons. I couldn't find a way to resolve that timing issue because MFC calls _CrtDumpMemoryLeaks from deep inside itself... so, I put the explicit-cleanup function back into my ODE DLL and now I'm getting perfect memory leak reports again. Here's the function, just invoke it somewhere in your app's shutdown code. In my case it's called during CMyApp::~CMyApp, and that works fine: void __declspec (dllexport) dCloseODE () { if (colliders) { dFree (colliders->_data, sizeof (dColliderEntry) * classes->_anum); dFree (colliders, sizeof(dArrayBase)); colliders = 0; } if (classes) { for (int i = 0; i < classes->size (); i++) { dFree ((*classes)[i], sizeof (dxGeomClass)); } dFree (classes->_data, sizeof (dxGeomClass*) * classes->_anum); dFree (classes, sizeof(dArrayBase)); classes = 0; } } Nate Waddoups Redmond WA USA http://www.natew.com From gene at erachampion.com Fri Jun 14 11:15:02 2002 From: gene at erachampion.com (Gene Ruebsamen) Date: Fri Jun 14 11:15:02 2002 Subject: [ODE] Optimizing for SIMD In-Reply-To: Message-ID: Hello, I wonder how much SIMD operations will help speed up ODE. Unless I am mistaken, 3DNow! and SSE only support single-precision floating point operations. Thus, unless you are willing to take a hit in accuracy, your performance may not benefit too much; although, I am sure there are some areas of ODE where the SIMD instructions would benefit greatly.. Check out http://libsimd.sourceforge.net/ . Looks like someone is working on a portable SIMD library. Maybe we could use this in ODE... Any thoughts? Gene Ruebsamen > -----Original Message----- > From: ode-admin@q12.org [mailto:ode-admin@q12.org]On Behalf Of Eli Curtz > Sent: Monday, June 10, 2002 1:46 PM > To: ODE group > Subject: [ODE] Optimizing for SIMD > > > Hi all, > > This may be insane, but I just got the PS2 Linux kit and was idly > considering porting ODE to it. Doing this "right" would involve > implementing portions on the vector unit of the PS2. Has anybody out > there thought about trying to optimize ODE for Altivec, SSE, or > anything similar? I'm a little bit scared of the LCP solver, last words> but it's only a few hundred lines of code, how hard could > it be? > > - eli > > -- > Eli Curtz > Sycophant to the Stars > eli@nuprometheus.com > _______________________________________________ > ODE mailing list > ODE@q12.org > http://q12.org/mailman/listinfo/ode > From si at sjbrown.co.uk Fri Jun 14 11:33:02 2002 From: si at sjbrown.co.uk (Si Brown) Date: Fri Jun 14 11:33:02 2002 Subject: [ODE] apparent memory leaks Message-ID: Oops I should make sure I'm talking about the right thing before hitting the send button (i.e. geometry class objects vs geometry objects). It's worth mentioning though that the singletons still aren't freed by ODE when the app exits, and in a debug build are just flagged by the debug allocator so that the used memory is not reported by ODE when the app exits. Ta, Si (hopefully talking on-topic now) >From: Nate W >To: ode@q12.org >Subject: RE: [ODE] apparent memory leaks >Date: Fri, 14 Jun 2002 03:11:11 -0700 (PDT) > >On Fri, 14 Jun 2002, Si Brown wrote: > > > >also, i have some memory leaks. for example, dSphereClass never gets > > >freed. i don't see anywhere in ode that takes care of freeing > > >dSphereClass. Am I missing something? > >I ran into the same thing, using MSVC's _CrtDumpMemoryLeaks to detect >leakage. Are you using VC.Net? > >Anyhow... In ODE .025, the geometry class singletons were not freed, but >it's not a problem because they're singletons (only one of each will ever >be allocated) and the OS wipes the entire heap when the process >terminates. So it's nothing to worry about. I still prefer a clean >memory leak dump when my app closes, though. It beats having to scan a >list of a half-dozen "leaks" and make sure there isn't an extra leak or >two due to something wrong in my application code. So I wrote some code >to explicitly free the singletons. > >My recall is pretty fuzzy here, as I haven't dealt with this since >upgrading to .030, but... I think Russ put some cleanup code in .030 but >now there's a timing issue - your app is probably calling >_CrtDumpMemoryLeaks before ODE cleans up the singletons. I couldn't find >a way to resolve that timing issue because MFC calls _CrtDumpMemoryLeaks >from deep inside itself... so, I put the explicit-cleanup function back >into my ODE DLL and now I'm getting perfect memory leak reports again. > >Here's the function, just invoke it somewhere in your app's shutdown code. >In my case it's called during CMyApp::~CMyApp, and that works fine: > >void __declspec (dllexport) dCloseODE () >{ > if (colliders) > { > dFree (colliders->_data, sizeof (dColliderEntry) * classes->_anum); > dFree (colliders, sizeof(dArrayBase)); > colliders = 0; > } > if (classes) > { > for (int i = 0; i < classes->size (); i++) > { > dFree ((*classes)[i], sizeof (dxGeomClass)); > } > dFree (classes->_data, sizeof (dxGeomClass*) * classes->_anum); > dFree (classes, sizeof(dArrayBase)); > classes = 0; > } >} > > >Nate Waddoups >Redmond WA USA >http://www.natew.com > > >_______________________________________________ >ODE mailing list >ODE@q12.org >http://q12.org/mailman/listinfo/ode _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com From jvanwingen at piglet.toward.com Fri Jun 14 12:24:01 2002 From: jvanwingen at piglet.toward.com (Jacob Van Wingen) Date: Fri Jun 14 12:24:01 2002 Subject: [ODE] problem with 3 contact joints Message-ID: <200206141523.AA49480200@mail.toward.com> I'm new to ODE - attracted by the Freefall buggy demo. I've run into a problem while setting up a simple test program. In the test there is a bounding box defined using 6 planes, with no body attached and 2 spheres of equal mass thrown randomly into the box. The spheres roll and collide with each other nicely in the box, however when a sphere rolls into a corner of the box it begins to sink into the ground plane and then shoots straight up at a very high velocity. This also occurs if a sphere is touching the other sphere and two walls. It always appears to sink into the ground plane. my dSpaceCollide callback seems to allow for more enough collision points. the world ERP is set at 1.0 and the problem occurs even with very small time-steps. has anyone else encountered this problem, or know what's going on? thanks, Jacob From coding at natew.com Fri Jun 14 12:24:33 2002 From: coding at natew.com (Nate W) Date: Fri Jun 14 12:24:33 2002 Subject: [ODE] apparent memory leaks In-Reply-To: Message-ID: On Fri, 14 Jun 2002, Si Brown wrote: > It's worth mentioning though that the singletons still aren't freed by ODE > when the app exits, and in a debug build are just flagged by the debug > allocator so that the used memory is not reported by ODE when the app exits. OK, thanks for the clarification. _CrtDumpMemoryLeaks doesn't grok ODE's debug flag though, so if you use that to dump memory leaks for your whole application, ODE's singletons still show up (unless I use dCloseODE). -- Nate Waddoups Redmond WA USA http://www.natew.com From coding at natew.com Fri Jun 14 12:35:02 2002 From: coding at natew.com (Nate W) Date: Fri Jun 14 12:35:02 2002 Subject: [ODE] problem with 3 contact joints In-Reply-To: <200206141523.AA49480200@mail.toward.com> Message-ID: On Fri, 14 Jun 2002, Jacob Van Wingen wrote: > my dSpaceCollide callback seems to allow for more enough collision points. My guess, based on the behavior you've described, is that not all of those collision points are being processed correctly (read as: contact joints aren't being created properly for all of the collisions). Have you tried setting a breakpoint on dJointCreateContact and manually inspecting all of the parameters to that (and to dJointAttach) to make sure they're all reasonable? Since it behaves properly most of the time, you could try doing something like this inside your contact-processing loop: int iCount = dCollide (o1, o2, iMaxContacts, &contact[0].geom, sizeof (dContact)); if (iCount) { for (int iContact = 0; iContact < iMax; iContact++) { if (iContact > 0) Breakpoint (); Where "Breakpoint()" is a platform-specific function that causes the debugger to break. In Win32, it's DebugBreak (); That way your app should run freely until you get into the multiple-contact situation. And if that breakpoint never gets hit, that tells you something too. -- Nate Waddoups Redmond WA USA http://www.natew.com From jimfing at yahoo.com Sun Jun 16 15:25:02 2002 From: jimfing at yahoo.com (James Fingleton) Date: Sun Jun 16 15:25:02 2002 Subject: [ODE] Another lame newbie question Message-ID: <20020616222412.58613.qmail@web9502.mail.yahoo.com> Hi everyone, just discouvered ODE today...it looks pretty cool. Been trying to make the config.h file, but can't get make to work. I'm using VC++ 6 and have run the VCVARS43.bat file to set stuff up. When I type: make configure I get the following message: make: *** No rule to make target `configure'. Stop. What the hell??? I noticed someone else on this list had the same problem but no one replied. Oh yeah, I'm using the make.exe supplied by the link in the help docs. Thanks for any help James Fingleton __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com From anselm at hook.org Sun Jun 16 18:53:02 2002 From: anselm at hook.org (Anselm Hook) Date: Sun Jun 16 18:53:02 2002 Subject: [ODE] Another lame newbie question In-Reply-To: <20020616222412.58613.qmail@web9502.mail.yahoo.com> Message-ID: from cygwin: lynx http://www.q12.org/ode/release/ode-0.03.tgz[return][return][q][y] tar zxvf ode[esc][return] cd ode[esc][return] vi config/user-settings - changed to cygwin - [return] lynx http://www.q12.org/ode/bin/make.exe[return][return][q][y] mv make.exe gmake.exe [return] gmake [return] Don't make configure - just 'make'. And make sure that your path doesn't refer to the wrong make. Also make sure to set your config/user-settings. If you still have problems, what OS? -a On Sun, 16 Jun 2002, James Fingleton wrote: > Hi everyone, just discouvered ODE today...it looks > pretty cool. > > Been trying to make the config.h file, but can't get > make to work. I'm using VC++ 6 and have run the > VCVARS43.bat file to set stuff up. When I type: > > make configure > > I get the following message: > > make: *** No rule to make target `configure'. Stop. > > What the hell??? I noticed someone else on this list > had the same problem but no one replied. > > Oh yeah, I'm using the make.exe supplied by the link > in the help docs. > > Thanks for any help > > James Fingleton > > __________________________________________________ > Do You Yahoo!? > Yahoo! - Official partner of 2002 FIFA World Cup > http://fifaworldcup.yahoo.com > _______________________________________________ > ODE mailing list > ODE@q12.org > http://q12.org/mailman/listinfo/ode > From Nguyen Binh Sun Jun 16 19:19:02 2002 From: Nguyen Binh (Nguyen Binh) Date: Sun Jun 16 19:19:02 2002 Subject: Re[2]: [ODE] Optimizing for SIMD In-Reply-To: References: Message-ID: <1412763974.20020617092204@glassegg.com> Hi , Yeah, I share the thoughts that SIMD code will improve ODE speed (thus stability) much. For example, on big part of ODE, the LCP solver can be rewritten in SIMD .Base on some docs at Intel it will improve speed about 5 times(Oh lah). And Intel has SML (Small Matrix Library) written in SIMD, MMX. I think we can use it to solve LCP problem in ODE. SML is http://www.intel.com/design/pentiumiii/sml/src.zip -- 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 dmcclurg at pandemicstudios.com.au Sun Jun 16 20:04:01 2002 From: dmcclurg at pandemicstudios.com.au (David McClurg) Date: Sun Jun 16 20:04:01 2002 Subject: [ODE] Optimizing for SIMD Message-ID: How portable? From the libsimd website: > Most modern processors possess Single Instruction Multiple Data (SIMD) instructions hmmm. For myself, I'm using single-precision ODE on game consoles where I might not have an intel chip. Could this be a contrib or an #ifdef thing? -----Original Message----- From: Gene Ruebsamen [mailto:gene@erachampion.com] Sent: Saturday, 15 June 2002 4:20 AM To: ODE group Subject: RE: [ODE] Optimizing for SIMD Hello, I wonder how much SIMD operations will help speed up ODE. Unless I am mistaken, 3DNow! and SSE only support single-precision floating point operations. Thus, unless you are willing to take a hit in accuracy, your performance may not benefit too much; although, I am sure there are some areas of ODE where the SIMD instructions would benefit greatly.. Check out http://libsimd.sourceforge.net/ . Looks like someone is working on a portable SIMD library. Maybe we could use this in ODE... Any thoughts? Gene Ruebsamen From anselm at hook.org Sun Jun 16 20:31:01 2002 From: anselm at hook.org (Anselm Hook) Date: Sun Jun 16 20:31:01 2002 Subject: [ODE] Another lame newbie question In-Reply-To: Message-ID: Oh, VC6.0. Can't help you there unfortunately. -a > > If you still have problems, what OS? > > -a From dmcclurg at pandemicstudios.com.au Sun Jun 16 20:31:09 2002 From: dmcclurg at pandemicstudios.com.au (David McClurg) Date: Sun Jun 16 20:31:09 2002 Subject: [ODE] apparent memory leaks Message-ID: Nate's patch worked for me. No more leaks. If you use CVS, put this function at the bottom of geom.cpp and call it before exit. void dCloseODE() { if (colliders) { delete colliders; colliders = 0; } if (classes) { for (int i = 0; i < classes->size (); i++) { dFree ((*classes)[i], sizeof (dxGeomClass)); } delete classes; classes = 0; } } -----Original Message----- From: Si Brown [mailto:si_br0wn@hotmail.com] Sent: Saturday, 15 June 2002 4:31 AM To: ode@q12.org Subject: RE: [ODE] apparent memory leaks Oops I should make sure I'm talking about the right thing before hitting the send button (i.e. geometry class objects vs geometry objects). It's worth mentioning though that the singletons still aren't freed by ODE when the app exits, and in a debug build are just flagged by the debug allocator so that the used memory is not reported by ODE when the app exits. Ta, Si (hopefully talking on-topic now) >From: Nate W >To: ode@q12.org >Subject: RE: [ODE] apparent memory leaks >Date: Fri, 14 Jun 2002 03:11:11 -0700 (PDT) > >On Fri, 14 Jun 2002, Si Brown wrote: > > > >also, i have some memory leaks. for example, dSphereClass never gets > > >freed. i don't see anywhere in ode that takes care of freeing > > >dSphereClass. Am I missing something? > >I ran into the same thing, using MSVC's _CrtDumpMemoryLeaks to detect >leakage. Are you using VC.Net? > >Anyhow... In ODE .025, the geometry class singletons were not freed, but >it's not a problem because they're singletons (only one of each will ever >be allocated) and the OS wipes the entire heap when the process >terminates. So it's nothing to worry about. I still prefer a clean >memory leak dump when my app closes, though. It beats having to scan a >list of a half-dozen "leaks" and make sure there isn't an extra leak or >two due to something wrong in my application code. So I wrote some code >to explicitly free the singletons. > >My recall is pretty fuzzy here, as I haven't dealt with this since >upgrading to .030, but... I think Russ put some cleanup code in .030 but >now there's a timing issue - your app is probably calling >_CrtDumpMemoryLeaks before ODE cleans up the singletons. I couldn't find >a way to resolve that timing issue because MFC calls _CrtDumpMemoryLeaks >from deep inside itself... so, I put the explicit-cleanup function back >into my ODE DLL and now I'm getting perfect memory leak reports again. > >Here's the function, just invoke it somewhere in your app's shutdown code. >In my case it's called during CMyApp::~CMyApp, and that works fine: > >void __declspec (dllexport) dCloseODE () >{ > if (colliders) > { > dFree (colliders->_data, sizeof (dColliderEntry) * classes->_anum); > dFree (colliders, sizeof(dArrayBase)); > colliders = 0; > } > if (classes) > { > for (int i = 0; i < classes->size (); i++) > { > dFree ((*classes)[i], sizeof (dxGeomClass)); > } > dFree (classes->_data, sizeof (dxGeomClass*) * classes->_anum); > dFree (classes, sizeof(dArrayBase)); > classes = 0; > } >} > > >Nate Waddoups >Redmond WA USA >http://www.natew.com > From ps_yumemi at yahoo.com Sun Jun 16 21:47:01 2002 From: ps_yumemi at yahoo.com (pia dalusong) Date: Sun Jun 16 21:47:01 2002 Subject: [ODE] optimizing ode Message-ID: <20020617044613.12121.qmail@web9304.mail.yahoo.com> My friend developed a robot simulator in ode using a 1.4GHz p4. The problem is, am just using 550 MHz computer with winxp and everything is so slow. What can I do to make the program faster? can i use all the primitive shapes to create a robot and the collision detection will still work fine or do i have to take note of the capped cylinder? thanx __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com From dmcclurg at pandemicstudios.com.au Sun Jun 16 23:15:01 2002 From: dmcclurg at pandemicstudios.com.au (David McClurg) Date: Sun Jun 16 23:15:01 2002 Subject: [ODE] memory trashing bug in dcTriListCollider.cpp? Message-ID: In dcTriListCollider::CollideBox(), I'm getting a memory overwrite around Line 158. I think the OutContact reference is past the end of the Contacts list. My Box is a "big" box if that matters at all. I think there is a missing test somewhere. Could someone who understand this code better shed any light on this? if (Index == OutTriCount){ dContactGeom& OutContact = *CONTACT(Contacts, OutTriCount * Stride); From dmcclurg at pandemicstudios.com.au Sun Jun 16 23:31:02 2002 From: dmcclurg at pandemicstudios.com.au (David McClurg) Date: Sun Jun 16 23:31:02 2002 Subject: [ODE] RE: memory trashing bug in dcTriListCollider.cpp? Message-ID: When I increased my contact array size from 6 to 20, the crash went away (or moved :p). I'm hoping there is a incorrect/missing test somewhere since I'm passing in the size (N) of the contact array to dCollide(). static void NearCallback(void* data, dGeomID o1, dGeomID o2) { const U32 N = 20; // changed from 6 -> 20 and crash went away dContact contacts[N]; // get the contacts up to a maximum of N contacts const U32 n = dCollide(o1, o2, N, &contacts[0].geom, sizeof(dContact)); -----Original Message----- From: David McClurg [mailto:dpm@efn.org]On Behalf Of David McClurg Sent: Monday, 17 June 2002 4:16 PM To: ode@q12.org Subject: memory trashing bug in dcTriListCollider.cpp? In dcTriListCollider::CollideBox(), I'm getting a memory overwrite around Line 158. I think the OutContact reference is past the end of the Contacts list. My Box is a "big" box if that matters at all. I think there is a missing test somewhere. Could someone who understand this code better shed any light on this? if (Index == OutTriCount){ dContactGeom& OutContact = *CONTACT(Contacts, OutTriCount * Stride); From coding at natew.com Mon Jun 17 00:24:01 2002 From: coding at natew.com (Nate W) Date: Mon Jun 17 00:24:01 2002 Subject: [ODE] RE: memory trashing bug in dcTriListCollider.cpp? In-Reply-To: Message-ID: FWIW, I ran into the same thing. I don't remember what value of N I was using at first, but I'm now using 50. I didn't investigate any further though, so I can't shed any light on what's going on. But, if it makes you feel any better, you're not alone. :-) On Mon, 17 Jun 2002, David McClurg wrote: > When I increased my contact array size from 6 to 20, the crash went > away (or moved :p). I'm hoping there is a incorrect/missing test > somewhere since I'm passing in the size (N) of the contact array to > dCollide(). > > static void NearCallback(void* data, dGeomID o1, dGeomID o2) > { > const U32 N = 20; // changed from 6 -> 20 and crash went away > dContact contacts[N]; > > // get the contacts up to a maximum of N contacts > const U32 n = dCollide(o1, o2, N, &contacts[0].geom, sizeof(dContact)); -- Nate Waddoups Redmond WA USA http://www.natew.com From dmcclurg at pandemicstudios.com.au Mon Jun 17 00:25:02 2002 From: dmcclurg at pandemicstudios.com.au (David McClurg) Date: Mon Jun 17 00:25:02 2002 Subject: [ODE] GeomGroups Message-ID: I'm using a GeomGroup so that my static geometry (triangle lists) will not self-collide. The problem I'm having is that the NearCallback gets a pointer to the Group instead of the Geoms in it. Is that intended? From 9.2.5 in the 0.3 docs: --- At each time step, the dSpaceCollide() function does a single intersection test between the GeomGroups. If there is an intersection, the contents of the GeomGroup will be individually tested against each other. --- I would expect to get the individual Geoms. Otherwise, I need to figure that out somehow. Can anyone please shed light on this? From jimfing at yahoo.com Mon Jun 17 03:36:02 2002 From: jimfing at yahoo.com (James Fingleton) Date: Mon Jun 17 03:36:02 2002 Subject: [ODE] Another lame newbie question In-Reply-To: Message-ID: <20020617103501.69370.qmail@web9505.mail.yahoo.com> Yeah, I'm using Windows XP. All I need to do is to create config.h. Then I can just use the IDE to compile everything else. Jim --- Anselm Hook wrote: > > Oh, VC6.0. Can't help you there unfortunately. > > -a > > > > > If you still have problems, what OS? > > > > -a > > _______________________________________________ > ODE mailing list > ODE@q12.org > http://q12.org/mailman/listinfo/ode __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com From erwin at vo.com Mon Jun 17 11:27:02 2002 From: erwin at vo.com (Erwin de Vries) Date: Mon Jun 17 11:27:02 2002 Subject: [ODE] RE: memory trashing bug in dcTriListCollider.cpp? References: Message-ID: <00d601c2162c$75737c30$0101a8c0@athlon> This is indeed a problem with the current tri-collider. The problem is finding the N contacts that affect the simulation the most. I didnt bother with this, and simply assumed an infinite amount. Erwin ----- Original Message ----- From: "Nate W" To: Sent: Monday, June 17, 2002 01:25 Subject: Re: [ODE] RE: memory trashing bug in dcTriListCollider.cpp? > > FWIW, I ran into the same thing. I don't remember what value of N I was > using at first, but I'm now using 50. I didn't investigate any further > though, so I can't shed any light on what's going on. But, if it makes > you feel any better, you're not alone. :-) > > > On Mon, 17 Jun 2002, David McClurg wrote: > > > When I increased my contact array size from 6 to 20, the crash went > > away (or moved :p). I'm hoping there is a incorrect/missing test > > somewhere since I'm passing in the size (N) of the contact array to > > dCollide(). > > > > static void NearCallback(void* data, dGeomID o1, dGeomID o2) > > { > > const U32 N = 20; // changed from 6 -> 20 and crash went away > > dContact contacts[N]; > > > > // get the contacts up to a maximum of N contacts > > const U32 n = dCollide(o1, o2, N, &contacts[0].geom, sizeof(dContact)); > > -- > > Nate Waddoups > Redmond WA USA > http://www.natew.com > > > _______________________________________________ > ODE mailing list > ODE@q12.org > http://q12.org/mailman/listinfo/ode > > From dmcclurg at pandemicstudios.com.au Mon Jun 17 16:44:02 2002 From: dmcclurg at pandemicstudios.com.au (David McClurg) Date: Mon Jun 17 16:44:02 2002 Subject: [ODE] RE: memory trashing bug in dcTriListCollider.cpp? Message-ID: Perhaps this will do the index checking correctly... if (Index == OutTriCount){ dIASSERT(OutTriCount < Flags); dContactGeom* Contact = CONTACT(Contacts, OutTriCount * Stride); -----Original Message----- From: Erwin de Vries [mailto:erwin@vo.com] Sent: Tuesday, 18 June 2002 4:24 AM To: ode@q12.org Subject: Re: [ODE] RE: memory trashing bug in dcTriListCollider.cpp? This is indeed a problem with the current tri-collider. The problem is finding the N contacts that affect the simulation the most. I didnt bother with this, and simply assumed an infinite amount. Erwin ----- Original Message ----- From: "Nate W" To: Sent: Monday, June 17, 2002 01:25 Subject: Re: [ODE] RE: memory trashing bug in dcTriListCollider.cpp? > > FWIW, I ran into the same thing. I don't remember what value of N I was > using at first, but I'm now using 50. I didn't investigate any further > though, so I can't shed any light on what's going on. But, if it makes > you feel any better, you're not alone. :-) > > > On Mon, 17 Jun 2002, David McClurg wrote: > > > When I increased my contact array size from 6 to 20, the crash went > > away (or moved :p). I'm hoping there is a incorrect/missing test > > somewhere since I'm passing in the size (N) of the contact array to > > dCollide(). > > > > static void NearCallback(void* data, dGeomID o1, dGeomID o2) > > { > > const U32 N = 20; // changed from 6 -> 20 and crash went away > > dContact contacts[N]; > > > > // get the contacts up to a maximum of N contacts > > const U32 n = dCollide(o1, o2, N, &contacts[0].geom, sizeof(dContact)); > From erwin at vo.com Tue Jun 18 12:30:02 2002 From: erwin at vo.com (Erwin de Vries) Date: Tue Jun 18 12:30:02 2002 Subject: [ODE] RE: memory trashing bug in dcTriListCollider.cpp? References: Message-ID: <00b201c216fe$78461bc0$0101a8c0@athlon> Yea that probably works. Make sure to use Flags & 0xffff for future compatibility. Erwin ----- Original Message ----- From: "David McClurg" To: Sent: Tuesday, June 18, 2002 01:45 Subject: RE: [ODE] RE: memory trashing bug in dcTriListCollider.cpp? > Perhaps this will do the index checking correctly... > > if (Index == OutTriCount){ > dIASSERT(OutTriCount < Flags); > dContactGeom* Contact = CONTACT(Contacts, OutTriCount * Stride); > > -----Original Message----- > From: Erwin de Vries [mailto:erwin@vo.com] > Sent: Tuesday, 18 June 2002 4:24 AM > To: ode@q12.org > Subject: Re: [ODE] RE: memory trashing bug in dcTriListCollider.cpp? > > > This is indeed a problem with the current tri-collider. The problem is > finding the N contacts that affect the simulation the most. I didnt bother > with this, and simply assumed an infinite amount. > > Erwin > > ----- Original Message ----- > From: "Nate W" > To: > Sent: Monday, June 17, 2002 01:25 > Subject: Re: [ODE] RE: memory trashing bug in dcTriListCollider.cpp? > > > > > > FWIW, I ran into the same thing. I don't remember what value of N I was > > using at first, but I'm now using 50. I didn't investigate any further > > though, so I can't shed any light on what's going on. But, if it makes > > you feel any better, you're not alone. :-) > > > > > > On Mon, 17 Jun 2002, David McClurg wrote: > > > > > When I increased my contact array size from 6 to 20, the crash went > > > away (or moved :p). I'm hoping there is a incorrect/missing test > > > somewhere since I'm passing in the size (N) of the contact array to > > > dCollide(). > > > > > > static void NearCallback(void* data, dGeomID o1, dGeomID o2) > > > { > > > const U32 N = 20; // changed from 6 -> 20 and crash went away > > > dContact contacts[N]; > > > > > > // get the contacts up to a maximum of N contacts > > > const U32 n = dCollide(o1, o2, N, &contacts[0].geom, > sizeof(dContact)); > > > _______________________________________________ > ODE mailing list > ODE@q12.org > http://q12.org/mailman/listinfo/ode > > From G.J.A.v.d.Bergen at cebra.tue.nl Wed Jun 19 04:12:02 2002 From: G.J.A.v.d.Bergen at cebra.tue.nl (Bergen, G.J.A. van den) Date: Wed Jun 19 04:12:02 2002 Subject: Re[2]: [ODE] Collision detection for arbitrary polytopes ? Message-ID: <81E5F727841DD211A5FD0008C728DB7B06E94BD0@campusx1.tue.nl> Even for a concave solid decomposed into convex subpart, finding the penetration depth is not trivial. Imagine a rod standing on the floor and leaning against a wall. Decomposing the static scene into a convex floor and a convex wall part, would result in two penetration depth vectors. The wall vector would be horizontal while the floor vector would be vertical. The actual penetration depth vector would point diagonally away from the floor and the wall. The problem is that in general you cannot combine the different penetration depth vectors to a single penetration depth vector for all subparts. You'd have to find the actual penetration depth vector on the level of the Minkowski sum of the rod and the floor-wall object. However, this Minkowski sum is concave and thus finding the point on the boundary closest to the origin is not that simple. Of course, you can treat the floor and the wall as separate objects and impose a glue constraint between them if the floor-wall object is dynamic as well. But if the number of supparts are large, the large number of glue constraint would impose quite a load on the simulator (torus tossed on a cone). -----Original Message----- From: Pierre Terdiman To: ode@q12.org Sent: 6/14/02 10:32 AM Subject: Re: Re[2]: [ODE] Collision detection for arbitrary polytopes ? > Yes, Opcode does provide penetration depth in Sphere and Ray collides > with a poly soup! But I can't see any in poly-poly (TreeCollider) > test. Because that's very hard to do for arbitrary meshes. I don't think a good, convincing solution exists, and the ones I've seen are too slow for realtime anyway. If I had to implement it for next week, I would probably decompose the mesh into convex parts using SWIFT++, use the hierarchy of convex hulls as a BV-tree, then use SOLID 3.0 on top of this to compute penetration depth between 2 hulls. Would work, for a very high price. Pierre _______________________________________________ ODE mailing list ODE@q12.org http://q12.org/mailman/listinfo/ode From ericc at xenopi.com Wed Jun 19 10:29:02 2002 From: ericc at xenopi.com (Eric Cha) Date: Wed Jun 19 10:29:02 2002 Subject: [ODE] Recommendations? In-Reply-To: <81E5F727841DD211A5FD0008C728DB7B06E94BD0@campusx1.tue.nl> Message-ID: <001601c217b6$c04306a0$6401a8c0@donald> Hi Everyone, I have been playing with ODE now for about a month, and while it is very impressive at what it does and what it is designed for, it's not quite what I am in need of. I was wondering if anyone could give me some direction here or at least some suggestions, since I've been searching for quite some time... I'm looking for a physics simulator which has the following features: 1) Does simple non-articulated rigid body simulation (collision detection/response) using the micro-collision (Mirtich et al.) method. 3) Handles triangle soups (incl. collision between two triangulated bodies). Collision with other primitives is helpful, but not really required... 3) Source Code freely available - I am trying to learn and stabilize my own simulator. As you can see, while ODE is very cool, it doesn't really address my needs (and wasn't meant to...) Can anyone point me in a good direction? (BTW, I've purchased the O'Reilly book "Physics for Game Developers" and while it was quite good for explaining the core theories of the microcollision method, it came up quite short on implementation, IMHO..) Thanks, Eric --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.370 / Virus Database: 205 - Release Date: 6/5/2002 From amoravanszky at dplanet.ch Wed Jun 19 11:08:02 2002 From: amoravanszky at dplanet.ch (Adam Moravanszky) Date: Wed Jun 19 11:08:02 2002 Subject: Re[2]: [ODE] Collision detection for arbitrary polytopes ? References: <81E5F727841DD211A5FD0008C728DB7B06E94BD0@campusx1.tue.nl> Message-ID: <003701c217bc$49462720$8911da50@powerhouse> Hi Gino, your post doesn't make sense to me. Surely in your example, you would have two contact points, each with its own (one horizontal, the other vertical) relatively well defined penetration depth. I think that is what the original poster was talking about. -- -- Adam Moravanszky http://n.ethz.ch/student/adammo/ From p.terdiman at wanadoo.fr Wed Jun 19 11:16:01 2002 From: p.terdiman at wanadoo.fr (Pierre Terdiman) Date: Wed Jun 19 11:16:01 2002 Subject: Re[2]: [ODE] Collision detection for arbitrary polytopes ? References: <81E5F727841DD211A5FD0008C728DB7B06E94BD0@campusx1.tue.nl> Message-ID: <007b01c217bc$fd539900$0e00000a@pierre> > The problem is that in general you cannot combine the different penetration > depth vectors to a single penetration depth vector for all subparts. Well, I wouldn't have done that. I would have recorded 2 (or more) contacts, and let the simulator deal with it. Unless I'm missing something, it looks like composite objects to me... Sure, it can stress the simulator a bit :) Pierre From stjaerna at mac.com Thu Jun 20 06:30:02 2002 From: stjaerna at mac.com (jon klein) Date: Thu Jun 20 06:30:02 2002 Subject: [ODE] alloc vs. malloc again Message-ID: <9E236B3C-8451-11D6-9E31-0003936A7C02@mac.com> I've seen that the issue of allocating memory on the stack has come up a few times on this list, and that a lot of people have had problems with crashes due to stack overflows. While these can generally be fixed by increasing the stack size, I think there's a strong argument to be made for giving the option of not using the stack for this temporary memory allocation. The main issue is that for applications with an arbitrary number of objects and contacts, it's impossible to come up with a stack size at compile time which will be guaranteed to be big enough. The specific problem that I'm having is that the OS X AppKit threading code (NSThread) does not allow the stack size to be changed for threads, meaning that I can't even fix the stack overflow in the normal way. This is clearly not ODE's fault, but the only fix for me is to modify the LCP solver to use malloc/free. Obviously allocating on the stack has a large speed advantage over malloc/free, but for people who are more concerned about stability and runtime scalability, I think that malloc/free would do the trick. Another solution, which would fix the speed issue, would be to have static pointers to buffers which grow when necessary and don't get freed at all until the program terminates. This would be even faster than allocating memory on the stack, but is considerably more work. Is there anybody else who would like to see either of these options available (via a #define statement)? Thanks, - jon klein From martin at metahuman.org Thu Jun 20 19:49:02 2002 From: martin at metahuman.org (Martin C. Martin) Date: Thu Jun 20 19:49:02 2002 Subject: [ODE] alloc vs. malloc again References: <9E236B3C-8451-11D6-9E31-0003936A7C02@mac.com> Message-ID: <3D1293F5.B3145D71@metahuman.org> jon klein wrote: > > Obviously allocating on the stack has a large speed advantage > over malloc/free, but for people who are more concerned about > stability and runtime scalability, I think that malloc/free > would do the trick. > > Another solution, which would fix the speed issue, would be to > have static pointers to buffers which grow when necessary and > don't get freed at all until the program terminates. This would > be even faster than allocating memory on the stack, but is > considerably more work. Actually, a good memory manager should do something like this for you, behind the scenes. > Is there anybody else who would like to see either of these > options available (via a #define statement)? I certainly would. - Martin From nathan at whatever.net Thu Jun 20 22:38:02 2002 From: nathan at whatever.net (Nate Waddoups) Date: Thu Jun 20 22:38:02 2002 Subject: [ODE] alloc vs. malloc again In-Reply-To: <3D1293F5.B3145D71@metahuman.org> Message-ID: > > Is there anybody else who would like to see either of these > > options available (via a #define statement)? > > I certainly would. As would I. It just occurred to me that heap-based allocation could probably be made to work as quickly as stack-based allocation (or close to it), if the memory manager treats the pool like a stack. In other words, have the assumption that allocations and frees will be invoked in stack order like push and pop operations. Anyone know of an existing memory manager that works that way? -- Nate Waddoups Redmond WA USA http://www.natew.com From amoravanszky at dplanet.ch Fri Jun 21 02:14:02 2002 From: amoravanszky at dplanet.ch (Adam Moravanszky) Date: Fri Jun 21 02:14:02 2002 Subject: [ODE] alloc vs. malloc again References: Message-ID: <001b01c21904$00f8bca0$e412da50@powerhouse> > memory manager treats the pool like a stack. In other words, have the > assumption that allocations and frees will be invoked in stack order like > push and pop operations. Anyone know of an existing memory manager that > works that way? > Hi, Such a manager is absolutely trivial to write: just an array of objects with a 'last' pointer, you can even use an STL vector -- no need to look for 3rd party code. I have been doing this for my contacts (and all other often allocated/freed objects) from day one. The advantage of this approach is that you can even reallocate the whole thing if you run out of space, so there is no fixed max # of objects -- the STL vector will just grow automatically. I always thought it is quite foolish to think that ODE contacts are so special that they require using some weird nonstandard and dangerous allocator. -- -- Adam Moravanszky From amoravanszky at dplanet.ch Fri Jun 21 02:14:24 2002 From: amoravanszky at dplanet.ch (Adam Moravanszky) Date: Fri Jun 21 02:14:24 2002 Subject: [ODE] alloc vs. malloc again References: Message-ID: <001c01c21904$02444f70$e412da50@powerhouse> > memory manager treats the pool like a stack. In other words, have the > assumption that allocations and frees will be invoked in stack order like > push and pop operations. Anyone know of an existing memory manager that > works that way? > Hi, Such a manager is absolutely trivial to write: just an array of objects with a 'last' pointer, you can even use an STL vector -- no need to look for 3rd party code. I have been doing this for my contacts (and all other often allocated/freed objects) from day one. The advantage of this approach is that you can even reallocate the whole thing if you run out of space, so there is no fixed max # of objects -- the STL vector will just grow automatically. I always thought it is quite foolish to think that ODE contacts are so special that they require using some weird nonstandard and dangerous allocator. -- -- Adam Moravanszky From amoravanszky at dplanet.ch Fri Jun 21 02:14:27 2002 From: amoravanszky at dplanet.ch (Adam Moravanszky) Date: Fri Jun 21 02:14:27 2002 Subject: [ODE] alloc vs. malloc again References: Message-ID: <001e01c21904$09b5d3f0$e412da50@powerhouse> > memory manager treats the pool like a stack. In other words, have the > assumption that allocations and frees will be invoked in stack order like > push and pop operations. Anyone know of an existing memory manager that > works that way? > Hi, Such a manager is absolutely trivial to write: just an array of objects with a 'last' pointer, you can even use an STL vector -- no need to look for 3rd party code. I have been doing this for my contacts (and all other often allocated/freed objects) from day one. The advantage of this approach is that you can even reallocate the whole thing if you run out of space, so there is no fixed max # of objects -- the STL vector will just grow automatically. I always thought it is quite foolish to think that ODE contacts are so special that they require using some weird nonstandard and dangerous allocator. -- -- Adam Moravanszky From amoravanszky at dplanet.ch Fri Jun 21 02:14:30 2002 From: amoravanszky at dplanet.ch (Adam Moravanszky) Date: Fri Jun 21 02:14:30 2002 Subject: [ODE] alloc vs. malloc again References: Message-ID: <001d01c21904$099a5cb0$e412da50@powerhouse> > memory manager treats the pool like a stack. In other words, have the > assumption that allocations and frees will be invoked in stack order like > push and pop operations. Anyone know of an existing memory manager that > works that way? > Hi, Such a manager is absolutely trivial to write: just an array of objects with a 'last' pointer, you can even use an STL vector -- no need to look for 3rd party code. I have been doing this for my contacts (and all other often allocated/freed objects) from day one. The advantage of this approach is that you can even reallocate the whole thing if you run out of space, so there is no fixed max # of objects -- the STL vector will just grow automatically. I always thought it is quite foolish to think that ODE contacts are so special that they require using some weird nonstandard and dangerous allocator. -- -- Adam Moravanszky From amoravanszky at dplanet.ch Fri Jun 21 02:16:02 2002 From: amoravanszky at dplanet.ch (Adam Moravanszky) Date: Fri Jun 21 02:16:02 2002 Subject: [ODE] Sorry! References: Message-ID: <004601c21904$5f888020$e412da50@powerhouse> Sorry about the multiple posts, the stupid mailer kept reporting an error but apparently sent the message anyway. -- -- Adam Moravanszky From coding at natew.com Fri Jun 21 10:00:02 2002 From: coding at natew.com (Nate W) Date: Fri Jun 21 10:00:02 2002 Subject: [ODE] alloc vs. malloc again In-Reply-To: <001e01c21904$09b5d3f0$e412da50@powerhouse> Message-ID: On Fri, 21 Jun 2002, Adam Moravanszky wrote: > > memory manager treats the pool like a stack. In other words, have the > > assumption that allocations and frees will be invoked in stack order like > > push and pop operations. > > Such a manager is absolutely trivial to write: just an array of objects with > a 'last' pointer, you can even use an STL vector -- no need to look for 3rd > party code. That's a good point. Given that all objects are the same size, the problem gets even easier... I hadn't thought of that. -- Nate Waddoups Redmond WA USA http://www.natew.com From nlin at nlin.net Sat Jun 22 12:49:01 2002 From: nlin at nlin.net (nlin@nlin.net) Date: Sat Jun 22 12:49:01 2002 Subject: [ODE] How to compile Triangle Collider? Message-ID: Hi, I've wrestled all day with MSVC trying to get the triangle collider to work, but am constantly confounded with those wonderful "Microsoft-specific extensions to the C and C++ languages", namely, compiler warning C4273 dealing with dllexport linkage specifications. After reading through the MSDN docs about these "Microsoft-specific extensions to the C and C++ languages" (to use MSDN's terminology) I'm still none the wiser and I can't get Opcode 1.0, the triangle collider, and ODE to work together. The README for the triangle collider is a bit terse - where do I compile the CPP files? As part of the ODE static library? As part of the ODE DLL? As part of my project? None of the above worked for me; I always got bizarre linkage errors regarding DLL export conventions. I tried adding entries for the triangle collider cpp files to the ODE static library makefile, the ODE DLL makefile, and to a totally statically linked MSVC project workspace, but none worked. Can anyone point me to a simple set of instructions to get this to work, or provide me with a compilable example? Also, does the triangle collider + opcode work under Linux? I started a port attempt of opcode but again ran up against too many "Microsoft-specific extensions to the C and C++ languages", so I was wondering if anyone else had studied this issue in more detail. Thanks, -Norman From nlin at nlin.net Sun Jun 23 14:55:02 2002 From: nlin at nlin.net (nlin@nlin.net) Date: Sun Jun 23 14:55:02 2002 Subject: [ODE] More tri-collider questions Message-ID: 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. Now that it's compiling, there's the small problem of getting it to run :-) My problem is that no contacts seem to be generated for my simple test of colliding a sphere with a 2-triangle terrain. My test program is a modified test_boxstack where I drop spheres at 0,0,0 onto a test triangle mesh consisting of points created with the following code: trilist = dCreateTriList(space, NULL,NULL); dcVector3 vertices[10]; int vertexcount; int indices[10]; int indexcount; vertexcount=0; vertices[vertexcount].x = 0.0; vertices[vertexcount].y = 0.0; vertices[vertexcount].z = 0.0; vertexcount++; vertices[vertexcount].x = 1.0; vertices[vertexcount].y = 0.0; vertices[vertexcount].z = 1.0; vertexcount++; vertices[vertexcount].x = 0.0; vertices[vertexcount].y = 1.0; vertices[vertexcount].z = 1.0; vertexcount++; vertices[vertexcount].x = 1.0; vertices[vertexcount].y = 1.0; vertices[vertexcount].z = 0.0; vertexcount++; indexcount=0; indices[indexcount++] = 0; indices[indexcount++] = 1; indices[indexcount++] = 2; indices[indexcount++] = 3; indices[indexcount++] = 2; indices[indexcount++] = 1; dGeomTriListBuild(trilist, vertices, vertexcount, indices, indexcount); Then when I run my program, the spheres do collide with the mesh, but no contacts are getting generated. I put a debug message in dcTriListCollider::CollideSphere to print out the "TriangleIDCount" variable right after it is computed. It is always zero. Any idea what I am doing wrong? I really would like to get this working! Thanks, -Norman From erwin at vo.com Sun Jun 23 16:55:02 2002 From: erwin at vo.com (Erwin de Vries) Date: Sun Jun 23 16:55:02 2002 Subject: [ODE] More tri-collider questions References: Message-ID: <001001c21b11$3573a300$0101a8c0@athlon> > Then when I run my program, the spheres do collide with the mesh, > but no contacts are getting generated. I put a debug message in > dcTriListCollider::CollideSphere to print out the "TriangleIDCount" > variable right after it is computed. It is always zero. > > Any idea what I am doing wrong? I really would like to get this working! Have you perhaps moved the tri-list geom? The matrix of the trianglelist should be an identity one. I did this for speed purposes. The best implementation would have both versions, and determine at runtime which to use by doing a simple matrix identity check. (Or rather a position and quaternion check since it is quicker) Erwin From ericc at xenopi.com Sun Jun 23 22:28:02 2002 From: ericc at xenopi.com (Eric Cha) Date: Sun Jun 23 22:28:02 2002 Subject: [ODE] More tri-collider questions In-Reply-To: Message-ID: <000601c21b3f$edb6b960$6401a8c0@donald> Ummm, I ran into the same difficulties (w/regards to compiling) -> perhaps it would be helpful to post the steps necessary to get tri-collider and Opcode to compile to a static library? I know *I* would appreciate it... =) Eric > -----Original Message----- > From: ode-admin@q12.org [mailto:ode-admin@q12.org] On Behalf > Of nlin@nlin.net > Sent: Sunday, June 23, 2002 4:54 PM > To: ode@q12.org > Subject: [ODE] More tri-collider questions > > > 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. > > Now that it's compiling, there's the small problem of getting > it to run :-) > > My problem is that no contacts seem to be generated for my > simple test of colliding a sphere with a 2-triangle terrain. > My test program is a modified test_boxstack where I drop > spheres at 0,0,0 onto a test triangle mesh consisting of > points created with the following code: > > trilist = dCreateTriList(space, NULL,NULL); > > dcVector3 vertices[10]; > int vertexcount; > int indices[10]; > int indexcount; > > vertexcount=0; > vertices[vertexcount].x = 0.0; > vertices[vertexcount].y = 0.0; > vertices[vertexcount].z = 0.0; > vertexcount++; > vertices[vertexcount].x = 1.0; > vertices[vertexcount].y = 0.0; > vertices[vertexcount].z = 1.0; > vertexcount++; > vertices[vertexcount].x = 0.0; > vertices[vertexcount].y = 1.0; > vertices[vertexcount].z = 1.0; > vertexcount++; > vertices[vertexcount].x = 1.0; > vertices[vertexcount].y = 1.0; > vertices[vertexcount].z = 0.0; > vertexcount++; > > indexcount=0; > indices[indexcount++] = 0; > indices[indexcount++] = 1; > indices[indexcount++] = 2; > indices[indexcount++] = 3; > indices[indexcount++] = 2; > indices[indexcount++] = 1; > dGeomTriListBuild(trilist, vertices, vertexcount, indices, > indexcount); > > Then when I run my program, the spheres do collide with the > mesh, but no contacts are getting generated. I put a debug > message in dcTriListCollider::CollideSphere to print out the > "TriangleIDCount" variable right after it is computed. It is > always zero. > > Any idea what I am doing wrong? I really would like to get > this working! > > Thanks, > -Norman > _______________________________________________ > 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.372 / Virus Database: 207 - Release Date: 6/20/2002 > > --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.372 / Virus Database: 207 - Release Date: 6/20/2002 From nlin at nlin.net Mon Jun 24 02:54:02 2002 From: nlin at nlin.net (nlin@nlin.net) Date: Mon Jun 24 02:54:02 2002 Subject: [ODE] More tri-collider questions Message-ID: Erwin de Vries wrote: > Have you perhaps moved the tri-list geom? The matrix of the trianglelist > should be an identity one. Nope, I didn't move the tri-list geom. To make sure I explicitly set its position with dGeomSetPosition and dGeomSetRotation and checked it with dGeomGetPosition and dGeomSetRotation. Position is 0,0,0, rotation is identity. The tri-list creation code is exactly as shown in my previous e-mail. Help? -Norman From nlin at nlin.net Mon Jun 24 05:04:01 2002 From: nlin at nlin.net (nlin@nlin.net) Date: Mon Jun 24 05:04:01 2002 Subject: [ODE] collision detection/response without using ODE's collision engine In-Reply-To: <200206141901.g5EJ13202282@hook.org> Message-ID: SkeedaddIer@aol.com wrote: > Ken - I tried to setting depth to (sphere.z-sphere.radius) since it would > equal the penetration depth of the sphere against the plane at 0.0f. The > spheres still pass right thru the plane, no bouncy collision response. > > Figured it would help if you or anyone could look over the code and > figure out why i'm not getting the right results, so I posted it at: > > www.qlink.org/test_boxstack.txt > > Hope someone can fix this, i'm at wits end trying to figure out the > basics so I can build on from there. Thanks in advance! I got your code to work. You should: 0) Copy your contact.geom.pos and contact.geom.normal arrays element-by-element and not attempt to assign non-lvalues. My compiler (gcc) wouldn't even compile your assignments "contact.geom = contactposition". You might be using a non-standards-compliant C++ compiler such as the one from Redmond. 1) Change gravity to be 0,0,-0.0005. With your current -9.81 value the spheres are falling too quickly and this can conceivably cause problems when resolving penetrations (since if the sphere moves more than its diameter in one timestep, the formula used in the code won't work for computing the penetration) 2) Attach the joint NOT between the body and the ground plane, but instead between the body and NULL. This is because the ground plane is immovable with infinite mass. You create a ground plane body with dBodyCreate, but you never assign it any mass parameters. You want it to have infinite mass, so you don't need to create any body at all for the plane, just the Geom. Now, if only I could get that triangle-collider to work.... -Norman From erwin at vo.com Mon Jun 24 10:02:02 2002 From: erwin at vo.com (Erwin de Vries) Date: Mon Jun 24 10:02:02 2002 Subject: [ODE] How to compile Triangle Collider? Message-ID: <005a01c21ba0$c9c28140$0101a8c0@athlon> > > The current combination works just fine. Its what i use as well. Opcode1.1 > > might improve the accuracy for sphere collisions slightly, as i'm using an > > AABB Opcode test for the spheres right now. > > Uuh, that statement raises some serious concerns about accuracy for me. If > a sphere-mesh test is approximated with an AABB-test and this is only "slightly" > inaccurate, I wonder about the overall accuracy of the tri-collider for my > purposes. The tree query uses AABB's. Triangles that never touch the sphere wont contribute to the generated contact. > In my case, I need to do collisions with a spherical object and a mesh, where > the sphere and the mesh are assumed to be perfect representations of the > geometry. I am simulating a ball game where the ball will need to bounce > against and roll through tight geometry accurately (tubes, gutters, pathways, > corners, hills, holes). I need accuracy similar to what you would need for > a pool game. For a pool game the sphere collider is accurate enough. For a game you describe i would consider rewriting the sphere collision functions the way they did it in the flat four engine. It _might_ produce better results. But test it first of course. > Is the accuracy good enough for this, or am I better off using hundreds of ODE > primitives (boxes) to simulate my geometry? Should I upgrade to Opcode 1.1? > In your estimation is upgrading the tri-collider to Opcode 1.1 easy? I am already > behind schedule on my game (aren't we all) and want to spend as little time > as possible with porting code... I had planned on modeling my collision > geometry with hundreds of little boxes but it would be much easier for me > if I could directly use a low-poly mesh as my collision geometry - if it is > accurate enough. Upgrading to Opcode 1.1 would be fairly easy i think, but i've never looked into it, so i cant say for sure. Using boxes grouped together might work better for some geometry. It really depends on your geometry, and i havent done any real testing with any other data than our own car-racing games. I would say that for most types of geometry the spherecollider works. The boxcollider is a little more shady. > > The worst part about the algorithm is the clipping of the contacts. I > > couldnt think of a way of determining the penetration depth when a point is > > outside of the triangle. "Depth = 0.0f;" is what i do right now. You should > > try and see how good it works for you. > > What is wrong with this? If the point lies outside of the triangle then the > geometry does not collide with the triangle, merely with the infinte plane > containing the triangle. I think I am misunderstanding something here. Do > you mean that the generation of a contact point on the plane but outside of > the triangle might incorrectly inhibit the correct generation of another > valid contact point which IS in the triangle? In other words, is it correct > to say that the presence of contact points outside of the triangle is or > may be indicative of missing contact points within the triangle whose > influence is then ignored? Or am I totally off base here? Ehmm... Yes you are right. Moving a box towards a sharp edge will likely produce inaccurate physical behavior. Perhaps others can comment on how well it works for you? Erwin From russ at q12.org Mon Jun 24 10:50:02 2002 From: russ at q12.org (Russ Smith) Date: Mon Jun 24 10:50:02 2002 Subject: [ODE] ODE's license Message-ID: <000001c21ba7$9cd701e0$6701a8c0@rsmith2kdt2> hi all, i've recently had a number of enquiries about ODE's LGPL license and whether it is a problem to use ODE in a commercial product. in general it's no problem - the only minor issue is the LGPL "relinking" clause that asks that ODE be linked in as an external shared library (i.e. a DLL). however, there's a lot of fear, uncertainty and doubt about the LGPL, so i have decided to provide a dual licence: LGPL or BSD. what this will mean is that you may accept ODE under *either* the existing LGPL license, *or* the slightly less restrictive BSD license shown below. commercial users will have no problems with the BSD license. this change will probably happen in a few days. the (very few) people who have contributed code to the ODE core may chose to object to this, as they may have expected that their code would be licensed under LGPL, not BSD (note that ODE's "contrib" directory is separately licensed). i'll deal with any objections by simply taking the relevant feature out and reimplementing it at a later stage ... but i am not expecting anyone to object to this. comments? also: various people have contributed code to ODE that i've been sitting on for a while. i'll get around to this eventually, but i've had very little time for ODE recently. one thing i'll consider is hosting ODE on sourceforge and allowing any interested parties to be administrators of the project (and thus you can add your own code - but you have to test and document it yourselves as well :-) ). comments? ------ ODE's BSD LICENSE --- Copyright (c) 2001,2002, Russell Smith. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. Neither the names of ODE's copyright owner nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. -- Russ Smith http://www.q12.org From coding at natew.com Mon Jun 24 11:25:02 2002 From: coding at natew.com (Nate W) Date: Mon Jun 24 11:25:02 2002 Subject: [ODE] ODE's license In-Reply-To: <000001c21ba7$9cd701e0$6701a8c0@rsmith2kdt2> Message-ID: On Mon, 24 Jun 2002, Russ Smith wrote: > this change will probably happen in a few days. the (very few) people > who have contributed code to the ODE core may chose to object to this, > [....] but i am not expecting anyone to object to this. comments? No objection here. And, to save trouble in the future: Any code I have contributed to you for inclusion in ODE (and any code I contribute in the future) may be considered a donation. All rights associated with such code are assigned to you. -- Nate Waddoups Redmond WA USA http://www.natew.com From nlin at nlin.net Mon Jun 24 11:50:02 2002 From: nlin at nlin.net (nlin@nlin.net) Date: Mon Jun 24 11:50:02 2002 Subject: [ODE] ODE's license Message-ID: > this change will probably happen in a few days. the (very few) people > who have contributed code to the ODE core may chose to object to this, > as they may have expected that their code would be licensed under LGPL, No objection from me - somewhat ironically, my MSVC DLL changes were made in order to enable easier compliance the LGPL, but I can understand how users in commercial situations might have contractual difficulties with their clients and the LGPL. > > also: various people have contributed code to ODE that i've been sitting > on for a while. i'll get around to this eventually, but i've had very > little time for ODE recently. one thing i'll consider is hosting ODE > on sourceforge and allowing any interested parties to be administrators > of the project (and thus you can add your own code - but you have to > test and document it yourselves as well :-) ). Personally I kind of like the current situation where I can be fairly certain that the person who probably knows the code best (Russ) will manually integrate changes rather than having a wild-west free-for-all with the source code. However if someone has contributed a bleeding edge feature that you desperately need, I can also understand that the slow release schedule might be hampering. My suggestion would be the addition of an "incoming" directory where not-yet-integrated patches are simply dumped but can still be checked out vis CVS. Those absolutely needing bleeding-edge functionality can hack this into their own code; when Russ gets around to integrating it, it will be deleted from "incoming" and become part of the official release. This of course requires that Russ have enough time to eventually integrate the patches, but as I said, I would feel most comfortable with that solution. If a "free-for-all" CVS code repository is opened up, then I strongly suggest that as a first step Russ publish a detailed reference list to the particular research papers (Anitescu, Stewart, Potra, etc) used as a theoretical basis for ODE, plus document any changes to or specializations of these techniques. For instance, there appears to be a lot of speculation and possibly misunderstanding about the details of the time-stepping integration scheme used in ODE, and I would be wary of any changes to this part of the code without first being able to refer to a detailed theoretical explanation of how it is supposed to work. Another random suggestion, would it be possible to set up an ODE Wiki on q12.org? This way users and programmers could contribute documentation easily. Hopefully this will expand into a self-sustaining and organized body of knowledge about ODE (in particular, ODE internals). My 0.02, -Norman From anselm at hook.org Mon Jun 24 11:58:02 2002 From: anselm at hook.org (Anselm Hook) Date: Mon Jun 24 11:58:02 2002 Subject: [ODE] ODE's license In-Reply-To: Message-ID: > Another random suggestion, would it be possible to set up an ODE Wiki > on q12.org? This way users and programmers could contribute documentation > easily. Hopefully this will expand into a self-sustaining and organized > body of knowledge about ODE (in particular, ODE internals). http://q12.org/cgi-bin/wiki.pl?ODE_Wiki_Area From erwin at vo.com Mon Jun 24 12:12:02 2002 From: erwin at vo.com (Erwin de Vries) Date: Mon Jun 24 12:12:02 2002 Subject: [ODE] Tricollider sample References: Message-ID: <008601c21bae$551e8c40$0101a8c0@athlon> This is a multi-part message in MIME format. ------=_NextPart_000_0083_01C21BBF.17EFF320 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit > > Ehmm... Yes you are right. Moving a box towards a sharp edge will likely > > produce inaccurate physical behavior. Perhaps others can comment on how well > > it works for you? > > As soon as I get it working (still scratching my head about no contacts > being generated) and as soon as I have some time, I'll try to make a test > program where I can drag around a box on top of a tri-mesh and draw a little > dot at each contact point. Then I can drag the box towards the edge of the > mesh and watch exactly what contacts get generated or not. This is probably > months off before I get to doing this though :-( (gotta get the GAME finished....) If you do it you can use the attached stuff as a base. :-) Russ, could you put this in the CVS? Some very small things (that were not breaking for me) have been changed in the spherecollision code... Erwin ------=_NextPart_000_0083_01C21BBF.17EFF320 Content-Type: application/x-zip-compressed; name="dcTriList.zip" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="dcTriList.zip" UEsDBBQAAAAIAFSi7yqede2n8QcAAC4WAAAHAAAAYXJyYXkuaL1XbU/bShb+fJH4D2d1peJQYxKq 1WqBoE259BaJAiJhu+iqoo49IbPYnlzPmJCtur99nzkztkNC2y9s3UqxZ8555rw+Z9jdfqlnc4O2 6WUeh3UxEwX9tijiXCaaToo7WYiQjtVsUcq7qaHguEN73W6PriqtRZbRWUTDXJpptI5FdJLHMtun ErL/+LO3F6nyDqsfxXif5vN5VC9993l5H0dTqSmT4zIuF4TXSSkEaTUx87gUB7RQFSVxQaVIpTal HFdGkDQUF+muKlewcpXKycJuV0UqSjJTQUaUuSY14Y/fz6/pTGiNvd9FIco4o8tqnMlk3a4zmYhC C4o1zayInoqUxguGeWdtHDob8aVwWmykKg5ISOyXq1gPotTYpr2o5y2p4UOCE0FsrJ8lqZlF6cC5 BWUxLK81o58T+zbEKcmC7ZyqmcBLbGxU5xI1NhZUaTGpsvAJFrTo4+no/cX1iAbnN/RxcHU1OB/d HEDLTBV2xYNwmDKfZRJHIHplXJgFYvLUrg8nV8fvoTx4e3p2OrqxMXp3Ojo/GQ7p3cUVDehycDU6 Pb4+G1zR5fXV5cXwBIUvRJPjFuv5dDfZnQA6V0hiKgy6Q0c/re5vUNgacclSmsYPAgWeCPmAqMSU oMF/WLHP1mqmijuON5nl1Abax2YiM5Te6fHJOSI2+teoc0ByQoUyYYM1L6WBsPpuoYd0WiRRSH/9 O40EsinoMosTEa74OKws1ps33ZDeKm2s3ocBdfd6vd5O7033b3Q9HNiI/2TOealnd3Njc2N328U6 Ubmw7KVyjtznUqBLtuoURJxUbuxkGhd3EB3HyX0dZ43uT0QE45yz/4xLGY8zbMj/oCRsn4B5EGnL ChH6Vvg1qZH0ebzQhPCW3LZcQIWRd5WqNKMl06q4X9JiQh3bkmP4iAZ8DnSTUsRacJ9DCA645sgF fhaMZRQ0cWamEpiShpaIKQcmwKrMAANv2OQy4SKuT/Uo7GR9Yir8idNYowxJTCYiMaSYJ7wCDqvx 2gANGFFkIheF0a7k4TXoq0oQCA3KAHj7ifIFviFdzWaqhOF/YZi3lUED8JDJK224EyGTTBvokMDn YgtHgAOt9/eFmu+mat8X5Q69lWYutXAJltqSYwppUfCKtA05VZkPgo4avY/LIrJI5YNMK7S3RJ41 BQ8yxuDR06ATYhf9b4IOCZN0XHn1t5quCMSf0NMdjA/wA9ytrbAprzQtWqZJxUQWggu2lYZTqWrQ YhovORQt89SsVGNUpc2IVi2Wk1wOPzuJ7rD/fpWTAqJ0e/Hbya2dCTe372+x7NRXllm+SLIqFXQI NIQmmh798svurmNqkSfcRal9zdWDCDruFAiwU+PYGp7FWvuS+k5VhIzJgxdCGE5SFGhCC+cQUq6y txbyy+YGvDciQenY1CMlhm5tDR+wdUWVj0WJem9rEp3wGWwZbzXiMaRYvO2fHyo+KJnS9q39ZlXf S/YbhtYCt/bWNEDTBjiIW0tNQO7tvhZmiFW3X4i5FQlpTRj4kGx7lndtgXz2OlthbTtSs0wOPEcw wrS2bOexsOb1jth5mzmmLJqpufPazJkBC5c+/L+rYnspECLFuY1NPtgMwFDY9NguYzMeivteAa2+ v5w+tM4Xh9DvHjgA+8JhtS9fOZZNPCDOZQOlUpiqLJwu5LxUm8Dhs+J8AsTbDLbtBqspsHC37rA2 Ta1MimIwMNvpzgxqdUWj1lmu7x962aaFo+30KuRQ6tYjR6Y5fwNRAl7EsI1zGdYXcg+VQMyBGWXT xHfvWfScfWcKwo63A24HNrCpOwaZigwhoElVJJbv2ai5beNipxRt4XkudcOoPUGkHsvPD23siA1U 2VxmRTx7UqidqKk7jfmNd4DD09gD3YOJ7rjqPAf6268Pkng0pchhAcaLR2pNT4y9gN0LDxUvZwr0 Lw1O5fgBDfJVIQtpZJzxxPdNxRdvnsYYISk+azSOY5tAWMi7zAuRDy3weW2dYhi3tqtcGufR8tz9 cD0cwd+VyuAKrPuMPH0ETat16LU/fttvjTpe2CetheOA4fLiPCzEA6w01mtFTbaF5WzLbq3ztX07 7MaWdhT+bzVG2X09cPOgvivRoaPy0REtczrtkyOMVY5vWYSL101WCjh1XvYQWK8eO1ac8DTM+hg5 6nAVTfWwCrj9wseo+bViIIQmPKzgKcifwYT1tLW5fdv9dYvWNRrzH2vt/y7BN0MjaC1ZpqznRgar NRv1HFnTH9G2dXadF4PRdsfxUSP5qmG9Pz65s+S6mtVjtc4f8hNU1xmz/42QrMag1uS7Va0z4ktX k1IwROCydEiOpIg/X79GSDMtlkLg1nvhSjLpickstNP7RH0+p053G+k5aCl4trpsPEw+67FOPUuw sOcWeK/vhpNn/sfIf/qXvlNvpf1s4h9I+0//siK91/fJ4h9I+0//0rcijTvcnP6uaruVnaXYvc+U lsyLn+VWZCMsD7tu8Mdp2kob1fa55e/ShCxMR31umG+qkCjSJ39uRHV4vUW+tkL6v6XcYrChgU94 B9MTOfdfB7i9OcuVNZZ1GNvZ0CIcUheK/S7ue62KC0YtyC3ZQu/Ig2WI4ggA/oJMQVuJlpslLKeV pZCK7TVvvq7XsfxmBZeCz6rb98tKQLr06hVJG1pPItavGegY49bfHoQ27dVPE98Zuy/gbkhr/j/r LnnwnWX3v7YD5VekTE42N/4HUEsDBBQAAAAIAP19miuv/PO1IAkAACsiAAASAAAAZGNBQUJCQ29s bGlkZXIuY3Bw3Vltb9u2Fv7sAv0PpylQWK6cWOqnxXWANE23AG2Su7pDtywLaItOiMmSS8qp5Db3 Z9/P9xySeleSdWiHoWmjSIfPeXt4SIrUYxHNw3XAYYtJybLtq62HD0pZkE6leC1UouXVlpPVPA64 Fq+ViC4hYkuuVmzOwTSN6/hgvr//4sVBHIYi4NKa29l5BO8Uh4PTdzCPlysmhYojBX18WPIogeSK JRCKiEMSwxqRKmFRwGQArwoVrhx0FPAFwsjSxcHJm9P9nw/JwcXFIpZzLiJtYxbHIZhAppLzPJjd 3Rdxiv9PrrkM2QqdRyqB01hEyRM4TBMMRI1cqIkPUMjlyPn08EFvZwBvebJewWAHnzpgHkwA7W8v zeMYUV0+Cph9RpyxfiLFpYhYGGYwy+BUcCm5cbYIY4YspTDJI9pOYZi73U7HBYYjpnCEoKdFZgYl FtDfP/q5n6QO7AHe8NRxQGJeMoIFCxV1aOkxq3jMKh6zises6jGresxqHrPcY3aXx03F46bicVPx uKl63FQ9bmoeN7nHTadHK0nkmgQ3eaVOT+DFIbw8OXj35vB4eviys7xWIYv4bcUUxXLJwryUTNBB o7KWLJ3FqS4sLYHrpYhcvDLTm7GE/jr4GMsAPmC6ozH+eT4BH/8+farVdJ7G1dmHc8x0tD1amJYe GSPhBIbGET6MbQtLTUu94YYuHLmBpoXbDAw7LNxY+m1c8Fmn5WAXBTbAZke08Sxt48tuQoWKgTs7 rpwu9t8fvZ0evp1evB95febCzEVt/J05PfPzO5rFQDFbNrg2pT6jm83YAiyEpQbi5xC/CRGLPhra 01l8qhZAslxNqHOJtQlCxoCXCUrHvRutKVkAE4wLBsBNPdNowiBLATprOiKtz5/J6PMh3jfo/RJq /K/CjJdDvO+GmV9H91BjGYGh4SjtooZqxUDoJv2G1KT/JDXeV2HGyyHed8PMb949RWPTzQdLdttM YyE05fyT1GTfkJrRX5lpbNqjDmaa5P37mck5eHV0/PLN0fGb/ff9dORC6uGv74Je+incCgkmz3Q0 rieWes9pRdWBp9640WZyxku7za/o+c22ip5PAVNnfh8/mMhg8PABDHpTKVh0GfIhvrZBbN7bIOEq AbOzSa44KL5ikiX0yFKhSBZLvtw2Bq5QYoRAWx9YyHgJ03jJFLz5Xxhy6QKDmUggXiViKTY82NWK Q/gokitQ8ZLDEu1ByDYZ8GsWrtFXHEF/wVTCJawYwvD59MCpKjLAiDJjeQFMKb6chVkVsfV2fzoM RcK3gK1WoeABiAVEnAc8sDgWBbDi8oqtVCMcqolY4m0gFmp7WyerlX4nMpa93ly/g/d6ZyI6hxmy ZwQ1jB0dFZCVGJQZEb0evcVRaIntDHgCs7I7CLvzHZXeX9yXYmVWthJms7mjN5vISGMXabm/Z6tp ue/eae5gwd9a6pDEelAUI2TGk4+cR2WPUSFRnxlTVGOFDmZb6ImITKKjQEg+pzJXu1bHc6gJPqVu 5m5uhiUA+myerGkH7IIS0ZzDR07BajjxhvVP90Uw1iAAAYMYojjBccWjWlgmDsdifcfuz26x9cyB uYyVWsk4WM+TPg8uzUgnoNsMOnLKEBKaHy7FNVfwLH02+cEMLopAQc78EumhCGWGaKRexajGdIhE qu1coYi+/sjFfw6UW8SRC9ce/vrU4XqNnMBrzha/cJmos9H5cI+WRGNkO9UgrwHyukB+A+S3QOUO ndYqWkNNPq9EFBTLV5NRSiItu9el0ukslPdorLI0UmaUKV0ptsoCOS5X3WKBLtbeQtJage2IYkuu Xf9q6Mta9GVl0pmhrwHyukB+A+S3Qa0EM0qQrqR9d4JZK8HsvgR/MwluWgluyrA2JsEGyOsC+Q2Q 3wK1E9xQgnQl7bsT3LQS3HQnSIN3SvUjFvmIAUEhKKwwRSJzMNMsRKNM54jrJIfwD3bxJazF7dqp YZA+DSYjo/X48WPUXIcBzFBVcmslaE9QitgPOSvtgaKhzkJIxJKr+iQNfAQTpAiGOK7HzTaP2nxq 85ptdvaakIE/gOv22kkTNg0N6DNaNnQ/ah5YGYBL51KWdKebc5oQtw5CphQcHR1tmfmsmA0kC8Y1 dsvcaeJUpm1oHmrvPXZ+Zn9yYME1ixJ2qfuNMxkiKBVJobxgM1Wjvn/FwgVSjTHhCdmfLqxipcQs 5LZTbEbAJBoPP7JMwd7Iyc3N1yqJ9esZFh3N9d2BUJdG6zDUmcURGrQGzHp5jSUXSwiEmjMZ8KAI IgPFcA2gsqAIacqnTBq9tOAZ9T+ltujzEQ7pcQuxqSE2GlE7yiKpC6TtarirzXZYSmuWzCCsnm+U ltLSUmos1ba05KvEZQWuM0GvdOp1J1hFdCbo6bA8m6DnarNdCdYstRMsLaXWklZqJDjSgZawrApr DlEfPfYH1enVgWFN4p93RJr5ZaR+NytVRIsVXwtdIGVXo11ttYuUqqEWKV5pKLWGtE6708lVicuq uO5j9K6X3LbMHpoH81/0UHo2eAIXRJyYc5WfliPTJD6KApI6sAs5ol9gHRdse78A0jv09OAlSxhM 9Ci+K7T/toX5Wzhq1fbvh9ODny5eH+6/6k+lQGcc9+y1swfqfS1Hvzlk3GtiypqhItIFNXCe5Amd 2SzOcgMwgGfwFEbn5+OGAe+LDHhtA/4XGfDRgDkeuI5FAF1kHkUi+c+ay8x2r25RIo4I+oT2I5ra gzhK2ByXesWTt2LD+3oSwQZ6ix7uIcxsXooD/gFYH7hFvMO9vbPOqf04pmwJNQC6unBnYGX8JMk/ UNhaemSKSQPNNxqaCoT5QCPgORjccE9RSg7K8o81vYs8shwSr7hkWPdn533hONVPKOY7TKFAQQ/3 fuTJcRxgjWvszT29kCubrSVWs82jsdXU8rIvVmt11S8qmPxQODf3eepmnKIdACtcP6p/fkUGlgQu dqcuFCK7rS3eSDAQawQhPzFF5vPgK0OSaZZOpViKRFzzvmW1ycW4k2WrHBPBXf78+x36f8fjMb8k tbLMf+QRFQafHtxd6SXubxb77aXdGgSUU+mvsyLvr5SKhX9vsdw6SHr5uNWDhBm0Xfzag7eS61et rG8WXlmG/wdQSwMEFAAAAAgAnX4jLGG0iIeJAQAAxQMAABAAAABkY0FBQkJDb2xsaWRlci5onZNv a8IwEMZfK/gdAoJoEfrCdzqEmpZRKNaJ880YJTZXCJRE0tRNxvbZd+kfRecmDIrEu+d+91yu7YtM cshIkvjU8xaLzToIaBxFoR+sk3BJo2c/8JOk1+2jSki4L+x105wVBYlXNPaDxFuFhKdVhQagKs8F B/3R63aqcyGUtEmyUO8zW9xZKSGNQyJg2Ra0KV4mrzMMl/xNaV6FQ3Rsxftyl4t0iknXIaEkjovH VMnCYMctpEbpiTMgliJSKGanLDbAOGKacEtw49LUFO5pzY4Ptdz6Wyrbeak4OHOHbKjPDDtVXpch f06okoal5synFqZLa8vl0B7rwp83NPx9kDG5McbIjvd1gzM6GWhCdceDEryNDK/ntACH2N+218Wy BnZbyG0ojyBBMwMb+m/QXosDEqYtMmmcbbRABc5wnRjeXA1hVnnSno3dkbtOM0ReX85Oqdxawyc+ gM7ZvgFUL+eAsDG5+L9CUFtmLZ/LqnhrKJTCPJWgj8O/7uKzLukDLjYjrnv/k/sGUEsDBBQAAAAI AAN+miupta78Ng0AAII4AAARAAAAZGNPQkJDb2xsaWRlci5jcHDlW2tzEzkW/eypmv9wgSrGNu3g 7jAPMElVEsJMqoBkwUOxy7Ap2S0nDf3wtOSk28D+7P28V1fdVj9kQ6bIFMUyE8e+ujo6ui+1JeVW EE/Dhc/hJktTlm+d3/z+OyPzs3EaPAmEJHm15Xg+TXxO4oUI4jOIWcTFnE056KZRXd+fHu/vHyRh GPg8LdBOT2dJOuVBHAYxh4sk8GGcsligNDpJglh26fU2+FxIB6ZJLCSQqA8iWWDXUviUyTTItrPt 25AmRlX3lgqz9/777zoKZyuDHS3Cd3cKnMFuBn3VdSt6PXyD/1da8lWL22hZrlo81TIqR8hXI+Tr RnDXjuCuHcE1IyxXIyzXjeCtHcFbO4KnRvioXHP37g34XXA4OPkdjRnNWRoItCl08UPEYwnynEkg v8kEFqgpJIt9lvrweNWFix6GgM9nQUxIpwfHT0/2nh/SAN/GP5xIv//9d9DvYHgP8AeSC56GbA4S /QSUGmgrDoKjQZhUH1kWCCVLUh5tUd8BJGlwFsQsBJU6MMnh1yTiS7gLv7KIiQX6GroiiIKQpWhw bJVSTM9Z+O4HAQlaN4jh+d7J0aNeiTeXqL3kPmAywd4eEpMp5wKhyTkLWRJD5yOtJIaIcgjRMIW7 L46fHD0azJg4x6YClNRnbCJKVZzGPOUaDkdiAi55GALGAfC5CMIkHshLzt5hW5fYDYTMQ+6gGtJa xD4iIgYLowRtFan4kUmal8MdhEwIODo6Qosh8ymLYcLBDwSbhNzf2toqaMJtOIolD6FBFzVw7jwm dWW1OU9VaQGBtkXmySwI0QpauxXpC4GdLs95DGyOuvM0YJIXuiFb5sAvWLgg0xEg2htJCnbBhR7g MknfoV+Qt+CQzICzNMReWSAxjRZY895xIP7El5D/UDESdTqs0+m8DuI3qC1Vss3SJIJJksFeTe1k pTdFLZ6u05usg9uvw02scEYv5XKRxp2OTBccgplq4qIMeKVy9xvK6/riNEmSEGgNG2MalevYgwf7 SYb/H2sTdGvLDmssQyeM1qCabAI7gP1prezMwoRJkI709Oe7d8sUgAewh4k+YSIQcMGnmCVCLa4z rK21wlqCjDMEjsauTIa4yg1w7C01SEeimNG6t7+fuUoSzLp7R8+746wHu4BvZK/X0X7GdAoFr1Ib 5wY116i5Qc0JNa+h5p+DujSoS426NKhLQl3WUJfrUW9x/P3XzKAq26wwhPxCRigwc8L8QiYoMJd2 zFs89oNZI35UAO1/XgDRmOOsHz0nNuZxaJzXZC7JlhUZPT50pEecEWDvuemtLGMkrpYsjcRTkgk6 x3hZ9nbVq9f2sYWkayHpWki6VpJui6TbIumuSOZ/laRnIelZSHpWkl6LpNci6a1ILm0k7dnylfhc h7WkqPa+Vp/XSH6tPreS3FwgqELch2maCKGejPzFVG4sEMtmYAxoivbAyBtON+SpL5W3U3dk4hWZ WyNWMX6CkHtDyGB/aCHjWsi4VjJui4xryHhXJuNayHgWMp6VjNci4xky21cm49lz2iMyy0aem6jb 5KZhQebeVci45CZr7rbJuG0ydjcZMj9emYxrzdE2Ga9Nxu4mQ+anq5IxbsqbpXfQdJ3bJmOKat52 089XIeNV3NTInDYZ10rGNWTabvrlymRcCxnPQsazkvEMmbab7l+ZjFcslNdd+zbV7esudZvGvu7K tmns6y5km8a+7rq1aezrLlObxr7uqrRp7OsuQpvGvu6a83nPZaVcbbJUd2PHx7B/CI+OD35/evhs fPjIukMxD1nM121IxEkasbDcldDfPP3GJkXEskmS0UYFSeAiCmIHXxk9p+OA0F34uLXlw584/+EI fz3cAQ9/37lD3XCm0NVDvf7zDc51uDWc6ZaOAkMhdhzogfDDqGhhmW6pN3xUL6r4QhNhHcCgjaB+ iFbBCz7QtHroHL8kCHV3tPVZ1tY3bsIOFYCNjjNb4nuvjl6MD1+MT18N3S5zYOJgb/yZ9Dr63x8I i0RVoPUv9HbDRL1ZjlSrUWGZVvFKFa+pguGHQLs0i/fVAJDRfEc5V1ltB1VGgC87KB11PlLPlPkI PmPQL7YP6VQDSRoBDtYcSPX68EGBPhzg+4Z5r2Ia74tYxi1V3G/GMv8cfso02iIw0DbKbKahWCEV 9Sa7RtNkf6dp3C9iGbdUcb8Zy/zL/WQ+0XTLZMnXVhpSoZLzd5omv0bTDD+j0pTTHq61jDHe12+Z 0gaPj549enr07Oneq242dCBz8cdzgJZ+RbdiBD3PbDiqTyxzH6oVlYhn7qjRpueML+02r9LPa7ZV +nlI+Js8Nx6nAYvPQj7Ax7a/dHg8PkeJFtLpsT62GycRE/D0v2HIUwcYTAJpDoUfFOeYl4E814eV EeK1jjXxiVWoc8A5QzX8fHLQq3ZkgIxyjTwDJgSPJmFe1bj5Ym88CAPJb6pD1DDgvjo2jDn3ua/1 6LB4ztNzNhdNOhgTSYpv8bFY4Flu65RUn1LqI0s6ptSCmk6RHRWlQmI/0ZSFM+C20v3/PtrEwKx8 k+i91xvGL9Bi88YxZmlTc5hJqguxNnJBJhTjq4CfcHnJeWwcgHFBLiAoCplVHyS/6hfEChIH8oOU T1XUigdFH7dHKfE+c3Jn+XFgFKDLpnLBwjB3AFNsyuGSE1lU11clkpl6b8hoQACl6CcQJxLThMd1 WsSjV+h6veLr1hqs7Z7ebC/22rvcP9OJqxSdJum4ZyjQlYmzQF0zwPtOO/cpV4iBgNLyEZpHMUxz 1EbTiwS7MaKojKrzBFTZwCQfOvhfD5o+vRiiO59wNnvJUynUNkNLw61puBYNr6bhkYam+DhIhXSI d9WZdo+V88LFyl+tSi3LYvfMdHIohGwB88qcvBKYWnoLUl8Kv1NZUdVDg4PGolcPX826OjKLtVnX yyV7JWkt3C38nPBzws834+ct/PzT+EvCXxL+cjP+soW/bOOXKTJW1gtmZVxCoOJSoH0FiWg3o+kG 6lzcYSpV+J/FipWYEv6gSMB+dsffGepet27dwp6LEEsLr15dapcBwSIOIWcGD4RKKBYCXfSpRzpw TBaVDwNMm1GzzVVtnmpzm22aIrYjwL+BU3ttewabBlrpAyJrc99o7vKUGzu+U1bintXmVHZuro78 buqqscqFlPmjmnXN3FV5ErptoD/UHhaKKsjecWD+BYslO2tceSo70/2xmum75yycoamFoBtTDswT IYJJyLVTVmsLSxE8vGS5gN1hr4SbLoRM9EW3iKmKaiVCLo0XYUgzS2IELAFYtroRAX4gpiz1ub8i kesLXSosiCEWVjWThpdmPFf+1/t7fIgZNWppLGsaS9Ko7f9wSjPV2yF1h2AtSFkNSSdhdVPAIGUG KdNI1e+BxNTo5UbPNkHXDOraJ1jVsE7QJVpuMUHXIVjbBGtI7QkapMwgZW5jgkMiatTyqlozRb3G WgeD+rLVtodnOHp2e1Q1WvbwSIjsvMIcnkOoNnNUgVrmcA1QZoAyr+Vu4mn08qqefdfZ8kzYEnU1 V3/6klJou38bTpXVgikX5dYyWliJj2JfSXvwAEqN7kq350DR3i0V6YlzfPCISQY7lL0biP2nJSuf WIs+dLvc0vEoDuQ/FjzN63vlWF3rd8vvZfdIqj8R9kGC9WWKK5zg8gWWoC7lDjaoR7TBLipXH4hX MDjRixWQsj5+RiucPNeSbrXZqQxZFPG+fgSnO7jKTPTVpBM9H8oE86YO3ql+2vqVS7pe343GSpk8 r081FE/TqWPtovR6q4XkZFXBASMzCdUbdyCTwbB5obg8NVB5FugjgwAewjb+Kk4MTPtb3f5Wt78t 29WAh/pCMagFh9buC1oVKEnwEXcwT2iAmE2ni5RNAy6gK2TKJD/LYZKkaXLJfXrCLi5KE7A+qQne vH6rjhRcPvhpBneKZNOmKZt75jCh8IOxAT28DPAHfAxW7RB1sVCbtXUvCmXmgMrI6od1I8LILRiu BcO1YLgFxtKC4VkwvDaGLn2EcqpRTA/Pwtw1zE89M+pa/WFFf9votyyTW/Tvtfm4Fj5uqf9jm4/b 5mP0f2rzMZa36P/c5uNZ+Hil/i9tPl6bj9G/3+ZjvFjX31zxine63tH33WeJWuyUVh/UqwNXroWm jKK8VbXoMK0o5Td0Lade1sqg9Qa7QpXUXqVMdE5L6qVKMueY4Un6+k036NUyVJ8Zmg44q8EuVrNn ic9Fl3Q3GqnsqTdBaC2hSTQ2RUhuFoL5Qpx3lS1xCeM4d83lY22r9XB88Nvpk8O9xwqL9Bz6m6Xi z5Q6+p/ZCF3BoYXKHiNqbWo2/naq+jzjQJeE/d7tcsV9jUj0uwSFPmxjPA3fvKkRGm3Gdq+C7V4N 27sKttfE3ujedUmg4qMPrNztOin+YmT/5WD/ZW13toiHG/U/AMCYjBTYVnSov7Y4YEQHtO2y+mpm MgNVfmNCDV9GVCVKGMXtSRpEgQwuMCMc0Iu9A5V1vNMM2JEtD0qwhFLAMr73aQLel2DwjJ+tkvB/ UEsDBBQAAAAIANZ9mitIKbecygEAAFIEAAAPAAAAZGNPQkJDb2xsaWRlci5olVRda9swFH1uof9B ECiuGbip03ZrRsEfeTBkcRqyvowhVEsGgWtlspw6Letv75UVGZS2g2FhdM49956rDzTiZU1ZiTBO kzyOk3w+z9LZCmeLZP4znaUYnxyPQMBr9k+N/oqKNA3Kl0meznC0zBAtQL6WjCWiqjhl8uXk+Ggp eK1QLLqpzjkqK0EAxt0Y8IB2Dnoeu1rsRPGFg0IHTRx06aArB1076KuDvhn/H0RJ3oVdiB6j1dQl VudKjA+5sRLn02HNj2ursXgfH5g5I+U9k6r5Ff7WupY+CUl7OoNjMlu2aR8qXtxAOPBRViM/gGkh 6kbBht+zQgkZ+qdI1+EFa6ZDFByAh0KaNrY0kpLsvpt4FMXxQmizhaDMv/XROkmJIiA1ZnmrtNuQ BgVvUSJqRQrVDKpEF5Ot7iOgzE5N4rsb4X3e+Bf0Qdtnejmv78ucDfY91XBRoz8tk5w1xnkrOEV7 uXe4Xl3KR/pvTfvzONXX1DLmXCfdpGcN0q4bybdEsRvrgfcma8lBB40dBrwPdxuRXgnjQYhKW8DI t0xWZOM5PZGDHpeQadOMqU3reWuf1VzdwY7svP9d4V9TZsTgCEoUBP1D8OlL8AZQSwMEFAAAAAgA FJ3YLDogbfUSCgAA+yYAABUAAABkY1RyaUxpc3RDb2xsaWRlci5jcHC9Wv9v2koS/5lK/R+273SR TQhg0jvdK02khHBVdEngCKpOiqKTwQtxYmxqmyrpu9zffjP73d4FXqqni1piz37m687O7mzodMhF Rm5GUzLbxElEyoe4IIs4oaSga5qHJU1e2uSyJECO03myiWgEDySa5vFVXJTt+XpNwk2ZrcIynocJ oN+/+5NAkl/CPA9f2g+/mLToWfDW6XNBH2RJEkc0Z+MG4vNoPc8i2n44ff9uU8TpkqThihbrcE4J H+pX5Z2dnZ9LYZaykRzTiiK6iFNKvgxvhpOz6fB8dHE5vMURy7RPnyySFz1/odmqSfCTlvmLTz4R 0wLvK80hRrRokcs0wge/RUY7x397/66BM3J0KoWSEyW/D4P4fBGWIZA9FdemHyH9Cy0HSVgUOO4p o4AL+FZ0VdDSO8+eB1lahvMSlHZbpIh/0Gxhkn1keN0Sg//aQWAmdzqC53sWR8TBeI655sVpSdBn Cto2adkiQEDXxTsTNRoPRhfDwWQI80GmOaWMlebovPHavpmBkoKcGPykQ45tGCosGiem4jpISPI2 aREvU5bvEFMxJ3UwymHoccZg+O7CTTYJRdzt+Opy+u/B6Hp8NQSX/iMI8Hk2nQ4n49HlzfTWMju7 ouECuMt8Q+uD/9yEaQkTF8H4IkwKC/APStejPF7GaZiYmPOviGrzyTAY1JTjfERi1s7HxJtnaVES medZ0CI1So/P4SIJl5BQkUgiHCTNOX/hiOIpXvt9SBQCs4sUmqNxi006L+MsNVfjYHQzPRtMvXGZ t8htmYMtPvE8U3gTCd7spaRNH2A+OSSeQPq+csROQ/EE6a4WLzxzC/9u+QCjerEgRKjANGXlBEMo hR8Q+UROzEXOl18Hq0RJZtkzaXbgXYRx/pXOyyw/PkAzBjQtGXfTUwN6ZY+zIsZI4VoVazoSIGS+ jSOeggwPBGC5oumyfCiQo6UwyGsbgMPD5xIsALhA3nXvYUX12t2F5r4LHLSepFVlT2iYsPhOsjJE 08E16Q2SlDcqRNfhE8XY8RhdhxDu54/PH1EGf0EH1Ut7BRaikSemEiDUUYEDFViongPVQ5StM6jj Pto6Hai/2DodqL+6dfbquL/ZOh2oX22dDlTQdSg95gHRqYmhtTFBFRO4ML0KBl7VlF8ioYAk5HOu Nmjx4IkShNsqr4m45pq+qGSQSfjb81uiHB/4OpGBplKI0fmbTrcJhXf6nZIINkyuH1c5VI0wXSb0 8oLvKidEWSXLQRv3TU9IihfEq/N8OCFdVica0RmeiD6D4FNDcuGSysU1BmGSzML5E1u3Jo/fx2H4 z8tJiqc10/jGIssJ22RjAvr78Otz3RsgHh5yy8Q6xaghiu2jwGcovIvvhU3MyQ9fQzCYmaUYfJ9g nY/TDRVQNG6Q05ppfGYLSDYpH/2HZ/TJsPyRW/4Ilh/DL2Vrg6Pbcre9e8SUOlCvYrO+U440yTHs Co/391wBbG9ayDgJU4rVaM6evGZdePe+RSxi4CL27n0zRKYCPq9xWngq833pzX5/7S3iexf3BjsO /a0MgYvBe4S4BD75MzlWrAIzjJZMohGa790WyMH/5IhUvLvJ8lWY+ELEq/ArycKSXMCme/uNnLgY 2hdZOc6zaDMvdVxAtmMOpGwxMkiyghYlW+cg22T2HIpIU6rn5tSkKRsX4axYeE4o++RVqgCzKvnc UGfXvjGljMCnlD9+Jlbiy+ohIHLKdQZpQ5zsd4ztXkAUc8OhKGZ2c6taIhzcOfyZwSp9km+vah65 JcqXk+0eKN0OxHpTPAhnjByRn+y0qRx2S9dF1Cx42AXORcGUc4FTMdqUIEBW7C6qdBTE3fMR67kQ +c8qoywXTU9Q9/VbKEDz2RqxsPJcFWCdUWIvkH7owzgvu1JLixy3iNG1qU7OPL6yVm57vTFVVUuP UUPGGet1NMXXWrFUtNdZ0a+zEb4CkXEHZ8oLCKzTo0CJwEPjAbmg6/IB2GscEZIlFH+Znj1xz554 JX1S7piTCQVu64SI6vfEi6IuqLyksaojzUIkW35hOqfkCINkljUcNsujWtuGkFPShQOzNrGBgT7k onUB0wx9BZRGIL+ivhqr2CpOO6qTuWzsetSoNkMTCh2pas906okNV7ZHTKW1GdRyAWQdnULu8Oj5 7etwmcblJqK337xq0GQlBIcDM2BaGBqmMs5SwtNMx0+BMdw32wbFHLDCoIc7HV4zO9DHji+Hk8nw g2sGrApqRNkd3AOEiHesNFaQTRGOUGtuXJD83I5Z+bwNEUjEyzZETyJ+uBA8qlyRiNjzDlxg4F52 4Hoa59YbiewXi8IGLAO7bix7TmTPgQzYjeIiogvrVtASMHOomrlUAdWBZKpoGsULyKu6MiVET/vh ob1Xq0/XrkbLW8zfrtoGclpu8tRMJRgREmhSUCIAuHsi1SK+7r9buV0/0Jyq6xX++nM3LGdnO65Y YNB9x1Iwjc5rFmENPzZ61s0KH2W7pln7BdckjOJNIe8wOA24OVnw1q4y0EZmiJ4eJGEmiCa5vZK3 PqqBNW1UKNHStrF6m+ZYgJd9gB8W4Pd24vt7cHGZ0/jj2uvGW/rrg7c22DwOVo8NGNXE4nFzFafx arOqHjvdp87/XxeubXc34ls7yH0tc5e3zO5+cj97sJ299zvYe/fcWX1qQw9rvWjPrwREAHTDLYJT 67lVeGTZdJspkkUdKJR0TnE6J5n4adnUTo5qApvW8qwcNCWa7W9au3ncrMg3z501S31yWNOlY1bR csoW09u62mPrtPiT6caeRc78bNIJC9W9hhSnc8hxmVGPlgiPTKpaRukJhnx6awN97P/2xx7Dxfsb TuMqsvtPzVq+cXgWUmQx3najo2T6rMP5FQ7scLiBpF4DQ1yG+QspaVGqA7WpSx7tovn12b88jy0H 3wK0KiuEu6cnw9UQ/dSBvEl0jN96GK80OrVQ+u6Kwn6sSJie9t92IjRvWDSH3jgr7ToAuCkeLBD8 x31Rt7nZahan9sWLe6vT2vQ297boxpWYcm6Qqru2nQEG5mogXfVetKY4zHpTJd5qRB3XTwv8u6qM hQwFBlrIM5t7l0bQV3zLy4XEu7zsyBYHl4/sRUE5Ivc2j/q4Y6Vjtcnz7d0KAK6dap8wld1agLzY 2dPBWYBlUP3Og9W2KaN39Wp2pybP++dZ9KLO6za0V4Pqm709/ZpusAL9NwersXp7vzXLssTVcImM pNOB6rZGs0eYG/lX+krTwf7EzFJyOsALS6s9rHx3hmPwLyz8qV8HaOVvaAzEYZ6LtG95R7sNkOGV 34nQEWPcbvvTTZIYvPq7EK97vrEySGiYg3do2h7Zo62De3TIRsSav3pTo74eJCIovwV0dMqAUg75 wPXycG4BqXxuKXVaQxt7Nc/XJH3Xz4K2JyVZa2J5A27oNsV2wbbemC8bZtuvhVvrSGcLkP8HUEsD BBQAAAAIAHODmit3EidGfAIAAAUGAAATAAAAZGNUcmlMaXN0Q29sbGlkZXIuaJ1UTU8bMRA9LxL/ YQQShQjBgVuDIpHdtIqUsohsc6mqyLFng1tjL7aDQIj+9o69ZkOIWqperPXMe/Pmy7svay2whvm8 yKvr8WQ8rfJyMhkXo+v5+DKffC1GxXy+u7NPIKnxXRwhpeZqJRDOy4YbgSc3g92dlZN6CZrdomsY R2hd/Q38nuAXF8NhbpSSAu3Jzd6ms9z0EZUr5hwIXlk5kc6/eJ92dzLx8BnNbQ/Cid4+9rPTU6hu EJZkALP4gdxHWOK2yIJ5FpHDVV2jRQGNkdqjBW8gqglCBOnMebviHqKmk0ZTHKaXCoN4JviVYhoh nv0sexH3CdQEewucUSLGnkGujEPnr4JelyxvjW0WIQdPRkOHXZeQcaMJ0kXqwQytlxzdt7Pv/bfK HxzcJ3fg1sowDwU1YHr3Kk93t2KhekEOpjlp1uD/LZ/X5Y/Ess2iCxwLd0Qj1bRRfjM7DBwK8tyn Q1xYyx7Pt5o82O67i6WOw7A0U7CIA4zpiNxoz7gPA4aheUjXdXvwtjGW2ccNUtzFyiK+bBW8Xs5A TEsMPNkiq3xDKt/jEKu8ystiNP9CDgXDWeBT8evy44Cj/KWZIKsvCdgbQJV361rlXe7NaqEk/0js rXdx+PZRHIUe/9rGHUX5Py9Wv3NK7XvUdJGsZL83UtDzkUockjNSkFq+0v44oAM43ZNKMCZlGk6X I323hE+KLd0xdFOM3nRpEVNviUzhNoJNG1pL7OK11/8IuTBGUcc0WuaxyruAJS18gMdGrPcxjOkg ZE/k1I1cIbPEDJbOxpRaMP5zK1yaOSUxOAAaTGruOpUZo+q2aIRPaIzKz+2/FYld04b8/bf9G1BL AwQUAAAACAAGl7Asx91n3DgEAABxEAAADAAAAGRUcmlMaXN0LmNwcLVWbW/bNhD+nAD5D9cMCGQ1 tiVl2xejBewkDQIEGFAH+RIYAy3SrjaGMiTatbvuv+/4KsmWsm5JACciec8dn+d4R+mnTKR8TRmc 0vS+yO6yUl7mnGeUFYN0tTo9Gg5hzHn+FTLBM5GJ5clx5UOKguwGX07ra3Rr45j17vjafnKcCQnU mTgpS/gA/XikTAcuIdwweUUkCej2huVPIVhA76+T4yO/cwgKg3GCaqlHlQO66z10DOc7Qt+CyXUh tF//o9sODX8biiidwTzPOTwQNBHJNKbMcuGp5PE5+HFiGU1yugthHiMZR0AtBXmst/WA5ACQKABC sgUE81iH0+N3VNlvy2tB5pxRZTPGI71LNFJjpI1/1jl5xjnxzknT2edEkf/+HRlW2ZBAbYqm93f7 R1ElYbr6wgp2DsrhEyfL8lz5CUlSaQB2YhBTWWBAZGNYH+bZhnP7GOKWpK8LZ/SHaLycs+Xhd3a7 jqxkxksGNmTUJnjynOBJvn01tRjrv0pFF+X2ApHj8WRyz0r5nMjf5n+wVM0/M8JBeTz+OlMEHb/Y 1i0GdP3c6L3AREA6RrsFOVSRr1d6yYj2GVE7qQzrEsXn4OmSCYnXyFY1uuYRz+C9YRTNejCEZBAt DuA7D7/w8KQb/s3Df/Hwn1vg11uJDmWTTd+y6cbX6Xh80o1v8um38emukxsmWEEku78M3Cli7GZd 6KS3lBhnpEA/DfYnrT1tAbkOKT6J0F/o1Vqg6kGsn3zJ41gfOjIwx+1KMqhH6p3VOm+052qa+oe8 p8Ybf/uFv8kzCvQKq77Id5Z2oEvx9gqW/+vFsjR3O+NMso5XyjAEdaKFIBwWa5FKrPASwqHlo2Pa HaYYmnA+J+mfFa9znWK3HoIbvYCvIeoCoZMbOs6NHRsUbyqKr5K6xtu4SaM9QWP1IdKVpYYxBD19 tXw1oqGnnTcpexad6dPWt8thKyt3o9PLghHJfO1PVyRluHupnl2F9u+p9Z2+93WHn3f2c0ZTN6up vlfSwXwnGWKgzL6xfFHp7Fl7avsIIWeHl4wFETKfa8CtWGQik0zdkjXb77iH1IDqhWfNVOYmdvNC QKuy7ylxmfMygrPU3ab43+V32UQ28+FfgzrbPTDZH1Ma2PTr03yTpv6xCvYxqswL9hUOvs3NhlXh LTv7dbLOOK03aZqLUmLEB5Zi+i9CeGCFzFJW6m8lPWPby3wtpMPicgi3gnqQmljMi1vaKep/dDzQ 3Q3bYJYIonDUBTKq61rqnDuThSxxRMSSs3rKvGTsQ5+2TdSYxY1Z8oK8qPrcRPDuA0Smc/dO7Aw2 GKkre48d+XrUAiCEC3gP0WymWzAIN1EPv5gw3gYftbXYrMX1tcSsJfW1C7X2+Xp8F0SDyLSjkxC/ qYS4khC3SIhbJMQtEuJnJSRvKiGpJCQtEpIWCUmLhKRDAv7+AVBLAwQUAAAACAA5obAswVH1gNoE AAChEgAACwAAAGR4VHJpTGlzdC5opVjxT9s4FP6ZSfsfPCFVbSANsP10pZy4dkOVgCHamyYxVJnE ZblLky5xqiSM+9vvvdiNbZLSAkyi9nvP3/ve52ebbtefhR6bkel0+H1yPTofjSfT0eXg/O/h5+F0 +v7dLjj9kK31Q4QfukHqMXIceezHD/jV/XmCjoTHqcuJ535jLo/ijw/v3+3Mgohyku2TfJ8UPYza qfztzsOjMfeuGQ0wWAzy1aDoINQO/+kn9klG+qRdwnaynjLnypxr5kKZCzQ/PqHgRmHCRRqLLEUe LcPy5uC2RMt126GwFbrt6FbB/6eXKEyORU49j1iOnp1ECxZTGO1JHpWnBVxIaUNG2oqvKS9zw2cX eWZkjyy7WWVDnnlpyysb8ixKW1HaYsbTOESoBkVailS/xkoptNev0uYwqfIVYmIksnAr0FBJMU7v 1klhv0EKu0EKu0EK+6VS2M9JYetS2LoU9hZSXKTBOimsN0hhNUhhNUhhbZCizkmc6LFLAxpvzUbG 1wgps+JUmV+yQ9ZzO2TpO2TpO2Q179CmVLoGKolOO38yL9T8+X4Y+st1/eC8oR+chn5wGvrBeWE/ OK/qB6e5H5TZ5PSKfnCe6wdH7wdH7wfnFf3gNPeDY/aDmleptuqHS3ZPub9k2BTNd1NbvVq2LAqH siQcbriCBtF8QWM/iUKR5C6Kggq+39/QdRIW0peqklaL5GKc47gQY/X4mvAftob/IOB//ya5GOc4 LmBswou9GEb8Ko681OXb4lsl/N7qnoRRdTvW238QR0kiE7z6VOYCn9gyU24ch0IysiW3wjgVmWRp S5Ss8XAoPS7ofejz1GPjX+16+bpcZX901q5vWp38ivmsbaTQAJaR75HLKJ7TwC+Y7Fbt8GjQHfNp ZPM7FhPquixJsDUlGdX7N7dtP+RkFHos6+iMrHYL9lI4arU0rZZVbcJ4hE/8h6cmoMBqNCyJsYwz WIJw3iT2z/2El/6eDL6COnjs0/A+YAROfXBH3X/LlTxfMI/NqqUD6Wx7ZyyaA7yE2ycrwzWbfb37 h7lgwkUTCVvxRL1FsFw6ZryGer9vZLPIaoQIpkeHOmuC6uhVRiW15hoFM4A6jWOav6RSsTtYr4Vh UKsPTVEJMIjSkK+rXSZrFsBwWsSYImAVs1YP5W0WZRCF4ouRL+9XL8MYwBnEjHImkdreeEFdBksT /Fy3PZtZV4mhdO6H98SjnGLiujh/pX7g6Yo8ucks8o3FXCmNM5ah2OaO6NuBExlTMTnbyAQiVn2s +Gh4UHbFaXlgzA6N2ZFMiqTwSNKAYPeJ68PFIwnlrU5oFAS+x+Ke/uU1k068CcS3z8XNp9veTvnj OBBwFdCQgbd5g/Ci2LRFGFNjYRGNz6PByS1TPugvkLxQe+rBAygaukx8x5ZL8OunmtUfKpSybjys G1HYJ69ZSvoQSmwA6ZmeJXqOVh70CbJgTrvGy7nslEtX3HHdQVd7i8Q6EaRekA1vixTkC0U2AHnY PZgRR0Z11WujwxKrLxcYhJTZ/PMFDzWnfpjUJNXvLMHj8yLxgygEIgdApP7OSGJ62RVGB0SsuJzA RIIZrxFn80VAOTsW7T05kbs3aQGvi9Pv7Wqa7StXjlqtKGQAnpM/4fMPkmP7bcYdXW6Fe1zH3WVw XczgLDX/F9P/UEsDBAoAAAAAAN2i2CwAAAAAAAAAAAAAAAAIAAAASW5jbHVkZS9QSwMEFAAAAAgA 5GsmLCC4Z/WDAQAAGgQAABIAAABJbmNsdWRlL2RUcmlMaXN0LmiVUs1PwjAUP7tk/8MLXmBZxI8j J50JITHRCOHkpbQPrM6WtB0ZGv9329INGliIh2V9fa+/r/aSC1pWDKEnGb7Z7+q9lyZpMsygKInW MHmEbJgmWBtUArgwwGaKP3FtfH8UhqdcrEqEtULKNZciByFhTRiz+7BBaqSCSiODpV1oW5EVemBt VEUtKJ37obufNLlYlpIYqHPY5vBtGX4blhdUYBQnnouSslwQ+ulhzHaNDJetwCI0+2yM8suaCKJz aDZecfm8+LCkuT80C7ATwbAeWMKN5Gw3HI5O0RyhrvKILYNm5RCiTgQ1PgU1OHQpvbTTHp0yT3uv FNn+yymVQhvnN3Nj1iunqNsAClkJ0+Xdk3UFEDUziEoH2M505hG6naEUUuyeCpfCp8FqN2NxCoXE YEDqs+maULRHtft3Xc951S2xtW7cI2bEEEd8HM5DxUu2lxxS3j/pDOaoTJu0r7B2Ycc3El2HLcJM q2R8VomdaN7xoZ4Wz9puNW2uo+omqm4Hoz9QSwMEFAAAAAgA86PYLJqZKbJ3AgAAOwQAAAoAAABS RUFETUUudHh0bVPLbtswELwb8D8scokDxIrrFDm4SNDUySGHIEYdtMeCFlcWG4rL8mFZf99dWmkv AQRJJLizMzvD5ef5zXy5WCynk+nkNRjl9hZrstZoDLAb4DH0xoFG+BEMRpihrL8eqKqpu4CGAuSI 0JvUwsvDIyyqxfV0MlNOQ0sem2ztANlfgOz8NO56yeeN28Pz9sf6pipdWxPBml1QYQBlLfURBsqQ CDRBGjnNo28xoOD839vREQrZaMjFSrAQjEsYItZJ2rwfjaC4eI8Og0qoRdnLZs2MuejJQeI6dLp8 VZ2ysozrEv9+UKhJkBV4qxzOfTCdSQeEhDFVoxx+GhWgCdQxUAjMBqjh38zMLmGXE5gEyntUIYrS nsIbGCEyNhMGKuI4IW54GopD1O+TIT4pOKWYT6ymkzk8UO8sKV0GxR55Y3GUCodP1QJmbUp+dXXV 9z17yC4zP+4nfl69eNmp2tRdVAL25GqbNYqz5xHOVQhqqNpzwRanAI8Jg2Oq5nQwlqpn0qYZxiK9 PoXp20bk7ZG6qvZeyAfsSMZ2st/hCs700/12+/j9FWa0nN/9qq2KcX7ncge3t6A3Mu+17F18OZO5 bChGkdfklAOC6XxgxA5diqtCxOzFNGmmoDV7DtC/UWCQzJQAd+o3v6NH1NnHy6Kuo8C4qBh4VHWv NcTsPYUkVaO8WjzkQQ+sQG7MexrG8bsDHqHN1n6MQYkpSY4Srzo5w2lsitGtYhDWs7PYRUnMnt+N OaIQ1JocfylwmyFJOiCgLfm0mKBDeHPUF7gt8epPNvUbOEoYx5C4VO6tpryzo8D1GJYSgiLg5E2k HGoU9yL6cgvktsbqL1BLAwQKAAAAAAD1otgsAAAAAAAAAAAAAAAABQAAAHRlc3QvUEsDBBQAAAAI AJei2CyCCRPvrA4AABguAAAVAAAAdGVzdC90ZXN0X3RyaWxpc3QuY3BwvVprU9tIFv2cqZr/0MlW EQuEkWSYzMQwtcaQDFsQKJskm52lUo3UxkpkSSvJgDPDf9/TTz1jMlWp4WX1ffXt27fP7W6xs/m9 vn78gWyS7/MlbZ2nLCZHq5guQj8nx/FNGDObjJN0lYU384L0xhbxHMclk2Wesygip30yXYTFvN+2 RcjxgobRS5JB9p//c71+kt2A+p5dvyR3d3d9TVr79f3HeDkPcxKF1xnNVgSPs4wxkiez4o5mbEhW yZL4NCYZC8K8yMLrZcFIWBAaBztJ1rC1SIJwtuLsZRywjBRzRgqWLXKSzETj9Zu35JTlOXivWcwy GpGL5XUU+m2/TkOfxTkjNCcpF8nnLCDXK2HmFfdxKn1EK0FvtAiTeEhYCH7WtHXLshxs4vVd5Yk2 bxMMokcLPs6MJCm3YmFwKxJReK41+39P7MsQBySMhZ/zJGV4oAWP6l2IHLtmZJmz2TKya7agRd6f XP52/vaSjN58IO9Hk8nozeWHIbSKeQIuu2XSZrhIoxBdIHoZjYsVYlL36+x4Mv4NyqPDk9OTyw88 Rq9OLt8cT6fk1fmEjMjFaHJ5Mn57OpqQi7eTi/PpMRKfMTPHpa3u6TazO4PpRYJJDFiB1ZH3/7a8 /4DEzhGXKCBzesuQ4D4LbxEVSnws8EcztjNXoyS+EfEmRXVqe7mKzSyMkHon4+M3iNjlvy+tIQln JE4K29i6y8ICwsnaRLfJSez3bbL3C7lkixRGLyLqM7sxxumS2xoMHJscJnnB9c5GxPFc1912B84L 8nY64hH/mzHne33t/PjDjz/8I4z9aBkwsp8EbAe//fmvVWqQ0bu8WM5mO+apKXGZhadYeSBzg7dJ GJAgn7JiOqdBcpeTXhgD8Kyh7G4WsBk5m74bo5Fm9GZB+UKKw/imh/VLryP2ctfb3SW7A2fPImRn RyT5u/HWlo2ZJikSLRRoFCV5jlzD9FF0kMMci4GfvBcooZ4wvwA/y/gndx5dkNky9nkG5BVngqPz t4enx2ijhRIF748gfpjcl09HTe40BVDWGy2Z8SoKOZA3mm05mqYs0OxO4lE5PD3AZMGIj5EUVIy+ NPrm7RnK6pMnTyC1oPckXi6uYRYrMrn+hGDkpegRVhJHqN5e37GEQoCVGEpMo1HU1nh9cUgGxna4 WC4q9m8YnAIEMxQdUK6TYGX8DfQ+AKUPfkeRmEXTAYQA3ktM1dnqXNDIH0h2EhzCyMmRsDWU/WJl i6Zgv0aXYPOef4dvV0MuUnUkY0iZnMUFpl/AitJ9GMo+aQEwQgLxYRw4Qr0dMQiQHIONBHzU1dh9 ASmjiqbSAgpxWFz5EQNMCfsHmBujHbxPsiiA83f8c1jSpynACPScfxp6GRiY/x2Grioq/0rgy+ss WabQQ1YU1C9ueHNYdVatCqD0Adl2h/DXUJTPlZgE/jsQkmxA3rEMBJb/vndVN3cSB4LuemCUGSgU 2P04WfIuwy8smfW0DYvsaJLpwCo1YbGhCEpDDz1bMqnkfOLHR66K/Y0K3pjnF8Dpbs5r9l1Sm0cu QFAQhIU0KXhuQH8lszJAnvQrYRB4FjOajSFzTf3PpCdImygl1DYJmLiVZw/+8ewVQQoRGoFjyIFe 4m7/yvOPbGxATD5byJJimcWQU5LsPizMviNI4BHfU2GweAhFYRWDgjLPcJoJIIgxQBkDSj7xdKgt H5ccSP9es4LT4Ik1rEl4LQlPSAi/oQ+PIYO/wShjY9MfWPa1ZzUGEYxlDupc/H1wpVbvMuXrYqAZ GinuoSWQvhdiKZFwf4A/W1uWRAFi7IRX/XyZzTCF/UWCGT4wXR0ia7BcED9NOVt6w69rL7nuSYy0 A96tk+OBcb4ucC365TL9vcekPt6ySEi6QvJBh1fhj89d0rmLGbITzx7YG9qcc9XnwGardaCHaVkm ShxnzyiA735AJifDkjhBPT4JkOkc23uTE8vwZA2BBKMRyXNMFJz4w+k7nm3+PAjp+vxwd+tTRBQM IZkwENUYZ4wWTGdDT0CdXQUo3dgK4VPNzqgAfU56vi1TzLDhdFmieybYMjr9NMntyYmd51rhQYX6 oaydBc2KCqCTbeBgQW5DdpfynhvLX8r39KJWnFmU0ILcr76okOF09NOuM7O33T72hr/MbLf/4ifH mSF4TaV5mikl19vr7zmOUHvRd8STg0+tJ3dS77RjpIf+bKjLsaUZaEifZ5cJCbIkBUok/ACn4M6G AMvzl/+NnzXkEZVrzKZYeP1Odi7YudjYdEv4QsJXG5RumXshQ8U2LcG+ginP2tIYgt6z0bjuv0Ts bhW1ZeSQaEpZQzvo1mTxY4qmy5pq5zj1Nk2CMSaB5Ms0TTIYffpUaJj08+c0I1Hi0xxLXDR8Uy1m oJBfD8jz0XMOtD7Zx/N/nmtsBWGb9J7T59sQkE6wKGeGO6zkuCqJsgJS8pmt5KhY0ExuzM2CxoEE IX8R1GqX/cn+zDvS+ABg4hAhSWcUUVqoAEGTHJiBoVUWD8HCSK6fkz//JLqV11p+rXX/XKGKNACs Ift8X2uooKM30A0o4Hlrq7riZXBqCnqzppV0Wynq7hQVM8GtWlpKlYEqCjHsWZOV2ZGKvS0HIbV6 ogQhlPKq0B4pjR7sccTiWjJQBl8/c3z9jPFiO4sHBbBPwplREpvdz1eWLNfKZItrrD7ohwVbcJjr bUhJ29GVRLatCmDKh4qT5EAOQOK5AnKu0PB7fyB9lqkCP7jihMYif3rWJorklix/UNVRAcRdAB44 FNciY2PcT4TrNRvetmuvaW+52q+yFmrC5FWWLEb3YT6Kg1F8EzEUw7qtvgMAd7powpsnjwm7Doj8 ODWsD3CSFLQ9wElT7IgWtC4itpubFgk1FDUXlVkUaknCiiiMGwtbne9sORnOlXpw9YNXSZNq+jhi 2uRcC1sCgteZaa+8mpd+1UtthmzKTVPT+/rRtzaQQduHx0cwLk11j+NR9/O/4r68DeiM/+O+SuWG o2v8a+Fl5UzsVU7ELPZpmvP9Dgsqx2Opo+E9QJEWOmK7LgAuKuh2qtamQLWvW9K2zAaL+v5yAUFx 9F4gOExaAFyu98fUFq8V3P+wLOGhtepIzHEtwyJMFtJnYnyuYSs/ppNP+xgiPjSydqCXjMSnqy78 GmwDv/SsG7DsgkHdQR2Yy7nm83QJr3MoLtSUW0MoBDUOXxERo/EybWK8DaSTpQHdHjiyNz2ZGQ3C Zd5y3+P468B/SPIU+dyRfI4tlYX1rsT2dGZXBR/wazIT/rjwx/TSBBTnETB50gIz7xvRzPjxLdFw dTCMYMTim2LeEATIq6plhtNGlzJutjQivFkHa16Jax2aD12ZwNutNBAecR1oyMUg7wi0nio8NPi0 zAVLrEZSJIml+6iVYGHP5msAnwi0eXTNow62GJxwEEtZ5sY3KpraXNzzdldpBuuvFWeCr28v0Gbs pjqbsaPncnhgmrGBUQaaBoF+1VBAJhJh1VojMKFiQ8vqQgvoL5Jbxq9Za2ho7qpybpnK+fJZXIgb STlzYc6TDd9WF/Z4GnvWTK4KVzlV24u+j48mw5UMt8XwJMPr2mi2k8LW5rW1irKJy9otsLb91X3w VF5btRZHx077obn75P7Wd12ywmjRWrElptiak6M6QEg5TdTnh+qtq9Mlt0+cDiH03FHpA3EyrHbh 1Aj7skv4V5455BlZjk8LqoCs6Yn99Z6O40c7MgdU8UqGUFH7y/dGoEmEM5sYu3ZBtYnsa1Am1ePz 0xtzEWlIULEI/pj7zdpqsErBiUUmRkhjghHSZ+JilbKK1DhC7tTsSAFIoHAJbhkkfaMu6hUUzHYN orB1KsCfW5MVTeVr9bZL3G5pbnvyTN+yVte6r72s0pZE75LEhyyrJEaz1rgpeQ37ptKaQlYdo9Hi E0AzuhAD3VDyG1KhPuR6ydQ+S0lVMdc5Wq+eDWfNLpk0BeEfb5tJJa0U9LpzyeuUn3jdSQXpRlpQ v1jS6CM6qB9gDWdi6G9PL08uTj84HwcDl/QUW4YHf41pwxAHlq0DIp/aXNdw3Q6up7l46nJhYFyY 2Pg23Zv1jNHaFSe1cBsWqreyUZKkzdsqsE9BlrdVKV3mTC//QOyxkijJZG2UTtReCOlzFbgb1Vc6 FQyQJtW7uWnBUn1nzfeJVvmKJmO6eOvbfvnSJQe/+jrueJHyG/fqjTe30nTYtV3bAUOTL9k9QAz+ Hk0/vj8/P5IsJKcceHkHX7+C5zyfW/zoz2l80yo54cGBxmWj04pc/4XtmqLeMud+5Sj6VL1JymUR COpXXN29Ydjo75v7MsOXxzhUIHOQM5lWL/+frlQHJgK1LqzuOTBVn//+UQZdeISP/cprShl/vtPS mHUaxqzXExf9m9aGeXeq35WGZJu4V1c2WSNydaXc0CuDd7+gYSwdodmNbxNxd7y5icatXAL6IIxz onhZwDK+xSfm/zaIr9K9+l8Q3OtXuklmomzio6//5+uAIAPfHU+mJ+dvNE+c7sHZEA8llaWcqFao JuvrZXDUY6mQcAVHt1NazD8WycdC5n4O3rN+fwc/Zgg7mvesXIm+vJEUq1QQ5SO05SIeC35PRlQs f876jeZzgQw1dnWZQqqyjvW9p0wQjQ8MTHobFiuDEvje5lDREBu/OtMiLtvWQGKKkPoXmvJQqQgK roiDH6Nj3stPcXvLuxEP/Xto41gzKymrFuULKF5/DxST3yb7nCthYlsaGzZ5K8NbtXgwq+yDVWO6 0miXTXeNTXedTe/rNj1ps8ukt87kYM3YB1+3OVhnc1fadIZN6qqT+kVRQefwokKriCXJ5SS3RvI4 abehOmjL7XKSVyPtdan+1JZ7wUmDGunnLtVf2nJu1yBcrWwWgUr4w2UYBT3VsE2A5JOCXFvbsSs4 rFaHeceBKlB7v2FVavc0WTAi8ASE2v+qYXmLe099ZMoluaz6y+r/ASlt05YbE4HOHJXtwZ5nez// bG/MYtV7FVHMe5sq6FT3LFpAgkAVUCRHg46yrV8DOvI14P8BUEsBAhQAFAAAAAgAVKLvKp517afx BwAALhYAAAcAAAAAAAAAAAAhAAAAAAAAAGFycmF5LmhQSwECFAAUAAAACAD9fZorr/zztSAJAAAr IgAAEgAAAAAAAAAAACAAAAAWCAAAZGNBQUJCQ29sbGlkZXIuY3BwUEsBAhQAFAAAAAgAnX4jLGG0 iIeJAQAAxQMAABAAAAAAAAAAAAAgAAAAZhEAAGRjQUFCQkNvbGxpZGVyLmhQSwECFAAUAAAACAAD fporqbWu/DYNAACCOAAAEQAAAAAAAAAAACAAAAAdEwAAZGNPQkJDb2xsaWRlci5jcHBQSwECFAAU AAAACADWfZorSCm3nMoBAABSBAAADwAAAAAAAAAAACAAAACCIAAAZGNPQkJDb2xsaWRlci5oUEsB AhQAFAAAAAgAFJ3YLDogbfUSCgAA+yYAABUAAAAAAAAAAAAgAAAAeSIAAGRjVHJpTGlzdENvbGxp ZGVyLmNwcFBLAQIUABQAAAAIAHODmit3EidGfAIAAAUGAAATAAAAAAAAAAAAIAAAAL4sAABkY1Ry aUxpc3RDb2xsaWRlci5oUEsBAhQAFAAAAAgABpewLMfdZ9w4BAAAcRAAAAwAAAAAAAAAAAAgAAAA ay8AAGRUcmlMaXN0LmNwcFBLAQIUABQAAAAIADmhsCzBUfWA2gQAAKESAAALAAAAAAAAAAAAIAAA AM0zAABkeFRyaUxpc3QuaFBLAQIUAAoAAAAAAN2i2CwAAAAAAAAAAAAAAAAIAAAAAAAAAAAAEAAA ANA4AABJbmNsdWRlL1BLAQIUABQAAAAIAORrJiwguGf1gwEAABoEAAASAAAAAAAAAAAAIAAAAPY4 AABJbmNsdWRlL2RUcmlMaXN0LmhQSwECFAAUAAAACADzo9gsmpkpsncCAAA7BAAACgAAAAAAAAAA ACAAAACpOgAAUkVBRE1FLnR4dFBLAQIUAAoAAAAAAPWi2CwAAAAAAAAAAAAAAAAFAAAAAAAAAAAA EAAAAEg9AAB0ZXN0L1BLAQIUABQAAAAIAJei2CyCCRPvrA4AABguAAAVAAAAAAAAAAAAIAAAAGs9 AAB0ZXN0L3Rlc3RfdHJpbGlzdC5jcHBQSwUGAAAAAA4ADgBKAwAASkwAAAAA ------=_NextPart_000_0083_01C21BBF.17EFF320-- From martin at metahuman.org Mon Jun 24 12:30:03 2002 From: martin at metahuman.org (Martin C. Martin) Date: Mon Jun 24 12:30:03 2002 Subject: [ODE] ODE's license References: Message-ID: <3D1772FE.B2B1860F@metahuman.org> Same here, no objections, an everything I've done should be considered a donation. All rights are assigned to Russ. From my understanding, under the LGPL, if a company modifies ODE they need to release the source for their modifications to it. Under BSD that's not the case. In neither case do they need to release the source for the rest of the program however. On the other hand, I don't feel strongly either way; whatever you think is right Russ. - Martin Nate W wrote: > > On Mon, 24 Jun 2002, Russ Smith wrote: > > > this change will probably happen in a few days. the (very few) people > > who have contributed code to the ODE core may chose to object to this, > > [....] but i am not expecting anyone to object to this. comments? > > No objection here. > > And, to save trouble in the future: Any code I have contributed to you > for inclusion in ODE (and any code I contribute in the future) may be > considered a donation. All rights associated with such code are assigned > to you. > > -- > > Nate Waddoups > Redmond WA USA > http://www.natew.com > > _______________________________________________ > ODE mailing list > ODE@q12.org > http://q12.org/mailman/listinfo/ode From nlin at nlin.net Mon Jun 24 12:33:01 2002 From: nlin at nlin.net (nlin@nlin.net) Date: Mon Jun 24 12:33:01 2002 Subject: [ODE] ODE Wiki In-Reply-To: Message-ID: > > Another random suggestion, would it be possible to set up an ODE Wiki > > on q12.org? This way users and programmers could contribute documentation > > easily. Hopefully this will expand into a self-sustaining and organized > > body of knowledge about ODE (in particular, ODE internals). > > http://q12.org/cgi-bin/wiki.pl?ODE_Wiki_Area Great. I've started to put up a basic structure, everyone else feel free to jump in (in marked contrast to source code and CVS, a Wiki is a great place for a "wild-west free-for-all"). We could also use the Wiki for organizing bleeding edge code patches or code suggestions. -Norman From martin at metahuman.org Mon Jun 24 12:34:02 2002 From: martin at metahuman.org (Martin C. Martin) Date: Mon Jun 24 12:34:02 2002 Subject: [ODE] ODE's license References: <000001c21ba7$9cd701e0$6701a8c0@rsmith2kdt2> Message-ID: <3D1773F9.64966234@metahuman.org> Almost forgot: Russ, if you're going to be just as busy in the future as you have been in the last few months, I'd vote for a sourceforge deal. Not a "free for all," but instead allow a small group of administrators, people who have demonstrated some competency by, say, contributing code that stays within your coding standards. The idea would be to have a small group of "surrogate Russ's" who are empowered to add their and other people's changes. Just a thought, Martin Russ Smith wrote: > > also: various people have contributed code to ODE that i've been sitting > on for a while. i'll get around to this eventually, but i've had very > little time for ODE recently. one thing i'll consider is hosting ODE > on sourceforge and allowing any interested parties to be administrators > of the project (and thus you can add your own code - but you have to > test and document it yourselves as well :-) ). > > comments? From russ at q12.org Mon Jun 24 14:18:02 2002 From: russ at q12.org (Russ Smith) Date: Mon Jun 24 14:18:02 2002 Subject: [ODE] Tricollider sample In-Reply-To: <008601c21bae$551e8c40$0101a8c0@athlon> Message-ID: <000001c21bc4$b81c0820$6701a8c0@rsmith2kdt2> > Russ, could you put this in the CVS? done -- Russ Smith http://www.q12.org From nlin at nlin.net Tue Jun 25 05:42:01 2002 From: nlin at nlin.net (nlin@nlin.net) Date: Tue Jun 25 05:42:01 2002 Subject: [ODE] Tri-collider page on wiki In-Reply-To: <020d01c21bc3$35fa1630$0101a8c0@athlon> Message-ID: I've put up a brief wiki page explaining how I got the tri-collider to compile and link, along with the problems I had (float/double issues). Feel free to correct/expand on this. http://q12.org/cgi-bin/wiki.pl?TriangleCollider -Norman From bovet at ifi.unizh.ch Wed Jun 26 06:01:01 2002 From: bovet at ifi.unizh.ch (Simon Bovet) Date: Wed Jun 26 06:01:01 2002 Subject: [ODE] Spring joints Message-ID: <003b01c21d11$7d725690$b6633c82@kyndias> Hi, I want to use spring joints with different spring/damping constants. The simplest way is probably to use ball joints, but then, who can I change the ERP and CFM values for each joint individually? Thanks for your help! Simon From dmcclurg at pandemicstudios.com.au Wed Jun 26 16:47:01 2002 From: dmcclurg at pandemicstudios.com.au (David McClurg) Date: Wed Jun 26 16:47:01 2002 Subject: [ODE] Tri-collider page on wiki Message-ID: Thanks Norman. This is very helpful. Under "Limitations of the Triangle Collider" I see-- # Current tri-collider code might not yet support moving tri-meshes (the transformation matrix for the tri-mesh must be identity, see mailing list) # Once moving tri-meshes are supported, you still need external library to compute arbitrary inertia tensor for moveable tri-meshes >>> I searched the mailing list archive and didn't find anything about this. <<< What I'm interested in is a tri-list that responds to dGeomSetPosition() and dGeomSetRotation(). My tri-list geom is linked to a scene graph and I'd like to follow the scene graph node as it moves/rotates. I don't need inertia or a body yet. Just teleporting through space would be fine. Moving platforms you can jump between in a game is an example where you don't need inertia badly. Of course, I can do this myself by transforming the vertex list but I was surprised to find that tri-list geoms didn't respond to dGeomSetPosition(). This approach also requires two vertex lists so errors don't build up!! -----Original Message----- From: nlin@nlin.net [mailto:nlin@nlin.net] Sent: Wednesday, 26 June 2002 12:40 AM To: Erwin de Vries Cc: ode@q12.org Subject: [ODE] Tri-collider page on wiki I've put up a brief wiki page explaining how I got the tri-collider to compile and link, along with the problems I had (float/double issues). Feel free to correct/expand on this. http://q12.org/cgi-bin/wiki.pl?TriangleCollider -Norman From Tony.Peguero at xtra.co.nz Wed Jun 26 19:21:02 2002 From: Tony.Peguero at xtra.co.nz (Tony Peguero) Date: Wed Jun 26 19:21:02 2002 Subject: [ODE] Tri-collider page on wiki In-Reply-To: Message-ID: Yeah, I'm hanging out for movable trilists as well. Calculating the inertia tensor separately doesn't scare me too much :) -----Original Message----- From: ode-admin@q12.org [mailto:ode-admin@q12.org]On Behalf Of David McClurg Sent: Thursday, 27 June 2002 11:48 a.m. To: ode@q12.org Subject: RE: [ODE] Tri-collider page on wiki Thanks Norman. This is very helpful. Under "Limitations of the Triangle Collider" I see-- # Current tri-collider code might not yet support moving tri-meshes (the transformation matrix for the tri-mesh must be identity, see mailing list) # Once moving tri-meshes are supported, you still need external library to compute arbitrary inertia tensor for moveable tri-meshes >>> I searched the mailing list archive and didn't find anything about this. <<< What I'm interested in is a tri-list that responds to dGeomSetPosition() and dGeomSetRotation(). My tri-list geom is linked to a scene graph and I'd like to follow the scene graph node as it moves/rotates. I don't need inertia or a body yet. Just teleporting through space would be fine. Moving platforms you can jump between in a game is an example where you don't need inertia badly. Of course, I can do this myself by transforming the vertex list but I was surprised to find that tri-list geoms didn't respond to dGeomSetPosition(). This approach also requires two vertex lists so errors don't build up!! -----Original Message----- From: nlin@nlin.net [mailto:nlin@nlin.net] Sent: Wednesday, 26 June 2002 12:40 AM To: Erwin de Vries Cc: ode@q12.org Subject: [ODE] Tri-collider page on wiki I've put up a brief wiki page explaining how I got the tri-collider to compile and link, along with the problems I had (float/double issues). Feel free to correct/expand on this. http://q12.org/cgi-bin/wiki.pl?TriangleCollider -Norman _______________________________________________ ODE mailing list ODE@q12.org http://q12.org/mailman/listinfo/ode From nlin at nlin.net Thu Jun 27 05:46:01 2002 From: nlin at nlin.net (nlin@nlin.net) Date: Thu Jun 27 05:46:01 2002 Subject: [ODE] tri-collider + DLL Message-ID: To use tri-collider with the msvc-dll configuration, you have to add a few new exports to the config/msvcdefs.def file, because the tri-collider uses functions not exported in the current msvcdefs.def. You need to add: dGeomGetClassData dSpaceAdd dCreateGeom dCreateGeomClass dInfiniteAABB ?_freeAll@dArrayBase@@IAEXH@Z ?dCollideBP@@YAHPBUdxGeom@@0HPAUdContactGeom@@H@Z ?_setSize@dArrayBase@@IAEXHH@Z The last three entries are rather troubling, since they are C++ mangled names (MSVC calls these "decorated" names). I have no idea about how MSVC generates these names, if they change according to build settings, or if they change from version to version of MSVC: You could probably also use __dllexport and __dllimport in the ODE code itself to take care of that, but then you need to #ifdef such declarations so that the code still compiles on other, standards-conforming C++ compilers. It's probably possible to make a DLL without the .DEF exports list, but I don't have the time to investigate it right now. Also I've updated the tri-collider wiki page with some new notes. If you see anything which needs improving, jump right in and do it. -Norman From p.terdiman at wanadoo.fr Thu Jun 27 06:11:02 2002 From: p.terdiman at wanadoo.fr (Pierre Terdiman) Date: Thu Jun 27 06:11:02 2002 Subject: [ODE] tri-collider + DLL References: Message-ID: <004d01c21ddc$617feee0$7401a8c0@nwpc1> Most of the time I just use something like this: #define EXPORTED_FUNCTION extern "C" __declspec(dllexport) Then in the cpp, for ex in a MAX plug : EXPORTED_FUNCTION int LibNumberClasses() { // Returns the number of plug-ins in this DLL. return 3; } This is enough to export a function correctly. No need for DEF files. The "extern "C"" part makes sure exported names are not decorated. Only drawback is it's limited to C-functions, so you can't export polymorphic functions this way. Ex, this failes: EXPORTED_FUNCTION void DoSomeStuff ( int data ) {} EXPORTED_FUNCTION void DoSomeStuff ( float data ) {} For classes, you only need the "__declspec(dllexport)" part (exported names are ok). Pierre ----- Original Message ----- From: To: Sent: Thursday 27 June 2002 16:43 Subject: [ODE] tri-collider + DLL > To use tri-collider with the msvc-dll configuration, you have to add > a few new exports to the config/msvcdefs.def file, because the tri-collider > uses functions not exported in the current msvcdefs.def. You need to > add: > > dGeomGetClassData > dSpaceAdd > dCreateGeom > dCreateGeomClass > dInfiniteAABB > ?_freeAll@dArrayBase@@IAEXH@Z > ?dCollideBP@@YAHPBUdxGeom@@0HPAUdContactGeom@@H@Z > ?_setSize@dArrayBase@@IAEXHH@Z > > The last three entries are rather troubling, since they are C++ mangled > names (MSVC calls these "decorated" names). I have no idea about how > MSVC generates these names, if they change according to build settings, > or if they change from version to version of MSVC: You could probably > also use __dllexport and __dllimport in the ODE code itself to > take care of that, but then you need to #ifdef such declarations > so that the code still compiles on other, standards-conforming C++ > compilers. It's probably possible to make a DLL without the .DEF exports > list, but I don't have the time to investigate it right now. > > Also I've updated the tri-collider wiki page with some new notes. > If you see anything which needs improving, jump right in and do it. > > -Norman > _______________________________________________ > ODE mailing list > ODE@q12.org > http://q12.org/mailman/listinfo/ode From coding at natew.com Thu Jun 27 09:38:02 2002 From: coding at natew.com (Nate W) Date: Thu Jun 27 09:38:02 2002 Subject: [ODE] tri-collider + DLL In-Reply-To: Message-ID: On Thu, 27 Jun 2002 nlin@nlin.net wrote: > The last three entries are rather troubling, since they are C++ mangled > names (MSVC calls these "decorated" names). I have no idea about how > MSVC generates these names, if they change according to build settings, > or if they change from version to version of MSVC [...] I *think* the names will remain stable for the forseeable future, as any change would probably break DLL interactions in god-knows-how-many applications and DLLs. Also, there is an API, UnDecorateSymbolName, which turns mangled names into human-readable names (provided the human in question speaks C++), and it's been around since Win95. I was able to build and use tri-collider without those functions, though. It's been so long since I built it that I'm not sure how I did it, though. That wiki site is a great idea. -- Nate Waddoups Redmond WA USA http://www.natew.com From ericc at xenopi.com Thu Jun 27 10:49:02 2002 From: ericc at xenopi.com (Eric Cha) Date: Thu Jun 27 10:49:02 2002 Subject: [ODE] Tri-collider page on wiki In-Reply-To: Message-ID: <004701c21e02$e1c72d90$6401a8c0@donald> I recently wrote up a routine to calculate the inertia tensor for an arbitrary tri-mesh. I haven't tried to integrate it with ODE/Tri-collider, but I would be happy to generalize the code a little bit and donate it to ODE... Eric > -----Original Message----- > From: ode-admin@q12.org [mailto:ode-admin@q12.org] On Behalf > Of Tony Peguero > Sent: Wednesday, June 26, 2002 7:17 PM > To: ode@q12.org > Subject: RE: [ODE] Tri-collider page on wiki > > > Yeah, I'm hanging out for movable trilists as well. > Calculating the inertia tensor separately doesn't scare me too much :) > > > -----Original Message----- > From: ode-admin@q12.org [mailto:ode-admin@q12.org]On Behalf > Of David McClurg > Sent: Thursday, 27 June 2002 11:48 a.m. > To: ode@q12.org > Subject: RE: [ODE] Tri-collider page on wiki > > > Thanks Norman. This is very helpful. > > Under "Limitations of the Triangle Collider" I see-- > # Current tri-collider code might not yet support moving > tri-meshes (the transformation matrix for the tri-mesh must > be identity, see mailing list) # Once moving tri-meshes are > supported, you still need external library to compute > arbitrary inertia tensor for moveable tri-meshes > > >>> I searched the mailing list archive and didn't find > anything about > >>> this. > <<< > > What I'm interested in is a tri-list that responds to > dGeomSetPosition() and dGeomSetRotation(). My tri-list geom > is linked to a scene graph and I'd like to follow the scene > graph node as it moves/rotates. > > I don't need inertia or a body yet. Just teleporting through > space would be fine. Moving platforms you can jump between > in a game is an example where you don't need inertia badly. > > Of course, I can do this myself by transforming the vertex > list but I was surprised to find that tri-list geoms didn't > respond to dGeomSetPosition(). This approach also requires > two vertex lists so errors don't build up!! > > -----Original Message----- > From: nlin@nlin.net [mailto:nlin@nlin.net] > Sent: Wednesday, 26 June 2002 12:40 AM > To: Erwin de Vries > Cc: ode@q12.org > Subject: [ODE] Tri-collider page on wiki > > > I've put up a brief wiki page explaining how I got the > tri-collider to compile and link, along with the problems I > had (float/double issues). Feel free to correct/expand on this. > http://q12.org/cgi-bin/wiki.pl?TriangleCollider -Norman _______________________________________________ ODE mailing list ODE@q12.org http://q12.org/mailman/listinfo/ode _______________________________________________ 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.372 / Virus Database: 207 - Release Date: 6/20/2002 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.372 / Virus Database: 207 - Release Date: 6/20/2002 From p.terdiman at wanadoo.fr Thu Jun 27 12:34:01 2002 From: p.terdiman at wanadoo.fr (Pierre Terdiman) Date: Thu Jun 27 12:34:01 2002 Subject: [ODE] Tri-collider page on wiki References: <004701c21e02$e1c72d90$6401a8c0@donald> Message-ID: <00d201c21e11$42652f40$0e00000a@pierre> > I recently wrote up a routine to calculate the inertia tensor for an > arbitrary tri-mesh. I haven't tried to integrate it with > ODE/Tri-collider, but I would be happy to generalize the code a little > bit and donate it to ODE... Hmmm, why not simply use the good old one from Brian Mirtich ? From Nguyen Binh Thu Jun 27 19:44:02 2002 From: Nguyen Binh (Nguyen Binh) Date: Thu Jun 27 19:44:02 2002 Subject: Re[2]: [ODE] Tri-collider page on wiki In-Reply-To: <00d201c21e11$42652f40$0e00000a@pierre> References: <004701c21e02$e1c72d90$6401a8c0@donald> <00d201c21e11$42652f40$0e00000a@pierre> Message-ID: <99836272.20020628094626@glassegg.com> Yes! It's at www.acm.org/jgt -- 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 falagard at hotmail.com Sun Jun 30 22:47:01 2002 From: falagard at hotmail.com (Clay Larabie) Date: Sun Jun 30 22:47:01 2002 Subject: [ODE] First Impressions Message-ID: My name is Clay Larabie, aka Falagard. Going to be playing around with ODE, trying to integrate it with a middleware 3d game engine called Auran Jet. I'm using Visual C++ and have had mixed results trying to compile ODE. I wasn't able to get 'make' to work, so I created added all the source files to a project from Visual C++ and got it to compile, was able to play with the examples, etc. I wasn't able to compile the trilist collider code with 0.03, so I downloaded the latest CVS code and dropped that in with my 0.03 files, even though it may be only working with 0.035. After some tweaking, I got the trilist collider to compile. When I ran the trilist test example though, the trilist collision detection is not working. Spheres and boxes are passing right through the trilist object. I'm not able to get 0.035 to compile at all. Got some errors I haven't yet been able to figure out. g:\downloads\ode\ode\src\geom.cpp(1289) : error C2501: 'SHAREDLIBEXPORT' : missing storage-class or type specifiers Does anyone have this working in Visual C++? Thanks for any help Clay Larabie _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com From ps_yumemi at yahoo.com Sat Jun 1 03:36:09 2002 From: ps_yumemi at yahoo.com (pia dalusong) Date: Sat Jun 1 03:36:09 2002 Subject: [ODE] Re: ODE digest, Vol 1 #181 - 8 msgs In-Reply-To: <200205291901.g4TJ1B209225@hook.org> Message-ID: <20020601103536.27825.qmail@web9305.mail.yahoo.com> people, thank you for all your help. i know it will be better for me to create an app and just use the mfc there however, this project has been finished 3 months ago and my friends and i didn't use mfc. we only have a menu. however my professor wants me to add toolbars or at least something the user can click on to make it easier for them to use it. its kind of tricky changing an existing program. pia __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com From kaffiene at xtra.co.nz Sun Jun 2 02:59:02 2002 From: kaffiene at xtra.co.nz (kaffiene) Date: Sun Jun 2 02:59:02 2002 Subject: [ODE] Wheels bending ;-) References: <00a001c20881$84345220$a24036d2@growltiger> Message-ID: <006f01c20a1b$b1e86f30$ee4136d2@growltiger> Hi - I posted this and got no replies, so I'm asking again =) p.s. should the axis passed into dBodySetFiniteRotationAxis be the swiftly rotating axis in model space or word space? (I was using model space) Cheers, Peter. ----- Original Message ----- From: kaffiene To: ODE List Sent: Friday, May 31, 2002 8:59 PM Subject: [ODE] Wheels bending ;-) Hi All, I've come across a problem which seems to be mentioned in the docs (section 11.9) - the problem of wheels on a car moving out of alignment under fast rotations. I've applied the recommended fix (dBodySetFiniteRotationMode(, 1) when bodies are created, and dBodySetFiniteRotationAxis(, 0, 1, 0) before or after each time step of the simulation) but it doesn't seem to work. When I use the setFiniteRotationAxis with axis y as above, I cannot steer my car at all! Anyone come accross this before? Any ideas? p.s. I have tried using dBodySetFiniteRotationAxis(, 0, 0, 0) and dBodySetFiniteRotationAxis(, 0, 0, 1) (it's a hinge2 joint with z and y axis, but I'm pretty sure that the z axis is *not* the one the wheel rotates about). Neither of those approaches fixes the original problem, but I can at least steer =) Help! =) Thanks in advance for any ideas. Peter. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://q12.org/pipermail/ode/attachments/20020602/93189f04/attachment.htm From Daniel.Groll at t-online.de Sun Jun 2 08:30:02 2002 From: Daniel.Groll at t-online.de (Daniel.Groll@t-online.de) Date: Sun Jun 2 08:30:02 2002 Subject: [ODE] Wheels bending ;-) Message-ID: <1023029211.3cfa2fdb850d2@webmail.t-online.de> Hi! I have posted a similar question a few days ago. I can't provide a solution to the problem, but I discovered some tips: 1. For your steering axis use Hinge parameters "dParamLoStop", "dParamHiStop" instead of "dParamVel2" (as mentioned in the source of the buggy sample) 2. Take a hinge (not hinge2) joint for the non-steering axis. 3. Don't put additional velocity on the steering axis. Use the non-steering for the impellent. 4. Check the speed of rotation frequently (I do this every time step) with "dJointGetHingeAngleRate", and if the wheel rotates too fast, break it down (e.g. dJointSetHingeParam(wheeljoint, dParamVel, 0)). The reason is, if the car turns at higher speed, often a wheel gets off the ground and begins to rotate very fast almost immediately (or is there a parameter to limit the rotation in advance??). Hope this helps, Daniel From kaffiene at xtra.co.nz Mon Jun 3 15:19:02 2002 From: kaffiene at xtra.co.nz (kaffiene) Date: Mon Jun 3 15:19:02 2002 Subject: [ODE] Wheels bending ;-) References: <1023029211.3cfa2fdb850d2@webmail.t-online.de> Message-ID: <000001c20b4c$1976a0a0$8a4136d2@growltiger> Hi Thanks for the ideas. I'm using (1) already since my code is based on the test buggy code - but I'm using four steering/driving wheels using hinge2s. I tried tip (4) - but using the hinge2 equivallents - and it's still broken. Can anybody else help? I'm a graphics guy, not a physics guy so I'm kinda stuck =) Cheers, Peter. ----- Original Message ----- From: To: Sent: Monday, June 03, 2002 3:28 AM Subject: Re: [ODE] Wheels bending ;-) > Hi! > > I have posted a similar question a few days ago. I can't provide a > solution to the problem, but I discovered some tips: > > 1. For your steering axis use Hinge parameters "dParamLoStop", > "dParamHiStop" instead of "dParamVel2" (as mentioned in the source of > the buggy sample) > 2. Take a hinge (not hinge2) joint for the non-steering axis. > 3. Don't put additional velocity on the steering axis. Use the > non-steering for the impellent. > 4. Check the speed of rotation frequently (I do this every time step) > with "dJointGetHingeAngleRate", and if the wheel rotates too fast, > break it down (e.g. dJointSetHingeParam(wheeljoint, dParamVel, 0)). The > reason is, if the car turns at higher speed, often a wheel gets off the > ground and begins to rotate very fast almost immediately (or is there a > parameter to limit the rotation in advance??). > > Hope this helps, > > Daniel > _______________________________________________ > ODE mailing list > ODE at q12.org > http://q12.org/mailman/listinfo/ode From filipe.dias at mind.pt Tue Jun 4 08:26:02 2002 From: filipe.dias at mind.pt (Filipe Dias) Date: Tue Jun 4 08:26:02 2002 Subject: [ODE] Wheels bending ;-) References: <1023029211.3cfa2fdb850d2@webmail.t-online.de> <000001c20b4c$1976a0a0$8a4136d2@growltiger> Message-ID: <004401c20bdb$4f3657a0$4601a8c0@intranet.mind.pt> Ok, I have to admit I haven?t yet really dug into the use of ODE (lack of time, no spare time, no time extension, and smashed my car (the real one))... but, I can suggest something I would try in that case. I would try to bypass the mystery part, and do it my own way: instead of letting ODE solve the angle of the weels, I would impose one. I would probably have four joints of rotation over a single axis, and each time a simulation step is taken, I would readjust the angle to have the disired value. Hey, this isn't the solution to the problem, and it has disadvantages... This is only a shortcut to see something working.. This way there is no interference from the wheelspin in the speed you turn the steeringwheel.. there may be outher aspacts, but discard them for my needs... See if this works, or if it is adequate to do (as I mentioned before, I haven't learned ODE enough) I don't rememer if there is drawback in starting a new simulation with some values of the previous one but with a new angl value... Fil. From anders.olofsson at licentiaten.umea.hsb.se Tue Jun 4 09:16:02 2002 From: anders.olofsson at licentiaten.umea.hsb.se (Anders Olofsson) Date: Tue Jun 4 09:16:02 2002 Subject: [ODE] ODE and msvc Message-ID: <3CFCE78E.7209132B@licentiaten.umea.hsb.se> Ok, I'm a msvc weenie.. Is it possible to set up my own ode lib workspace from the ide, instead of using makefiles and stuff? Or to download some prebuild .lib file. From filipe.dias at mind.pt Tue Jun 4 09:38:02 2002 From: filipe.dias at mind.pt (Filipe Dias) Date: Tue Jun 4 09:38:02 2002 Subject: [ODE] ODE and msvc References: <3CFCE78E.7209132B@licentiaten.umea.hsb.se> Message-ID: <006801c20be5$2d1e1e00$4601a8c0@intranet.mind.pt> Just a question: isn't a prebuild .lib the same thing we get when we "make.exe" the ODE? what is the problem of executing make.exe? (provided the \Program Files\Microsoft Visual Studio\VC98\Bin\VCVARS32.bat is executed before) Well it is inconvenient if we keep altering the ODE source and compiling it, but I don't do that often :-) Fil. ----- Original Message ----- From: "Anders Olofsson" To: Sent: Tuesday, June 04, 2002 5:15 PM Subject: [ODE] ODE and msvc > Ok, I'm a msvc weenie.. Is it possible to set up my own ode lib > workspace from the ide, instead of using makefiles and stuff? > > Or to download some prebuild .lib file. > _______________________________________________ > ODE mailing list > ODE at q12.org > http://q12.org/mailman/listinfo/ode > > From jason at 379.com Tue Jun 4 10:19:01 2002 From: jason at 379.com (J. Perkins) Date: Tue Jun 4 10:19:01 2002 Subject: [ODE] ODE and msvc References: <3CFCE78E.7209132B@licentiaten.umea.hsb.se> Message-ID: <3CFCF423.1000802@379.com> Anders Olofsson wrote: > Ok, I'm a msvc weenie.. Is it possible to set up my own ode lib > workspace from the ide, instead of using makefiles and stuff? Yes, it's easy. Just create a .LIB project in MSVC and put in all of the source files (except for drawstuff and the examples, obviously). Jason 379 From anders.olofsson at licentiaten.umea.hsb.se Tue Jun 4 10:44:02 2002 From: anders.olofsson at licentiaten.umea.hsb.se (Anders Olofsson) Date: Tue Jun 4 10:44:02 2002 Subject: [ODE] ODE and msvc References: <3CFCE78E.7209132B@licentiaten.umea.hsb.se> <006801c20be5$2d1e1e00$4601a8c0@intranet.mind.pt> Message-ID: <3CFCFC2C.BE3127BC@licentiaten.umea.hsb.se> Oups.. It was a combination of a missing .dll and not running that .bat file that stoped me. Thanks! Filipe Dias wrote: > > Just a question: isn't a prebuild .lib the same thing we get when we "make.exe" > the ODE? what is the problem of executing make.exe? (provided the \Program > Files\Microsoft Visual Studio\VC98\Bin\VCVARS32.bat is executed before) > > Well it is inconvenient if we keep altering the ODE source and compiling it, but > I don't do that often :-) > > Fil. From anders.olofsson at licentiaten.umea.hsb.se Tue Jun 4 10:51:02 2002 From: anders.olofsson at licentiaten.umea.hsb.se (Anders Olofsson) Date: Tue Jun 4 10:51:02 2002 Subject: [ODE] ODE and msvc References: <3CFCE78E.7209132B@licentiaten.umea.hsb.se> <3CFCF423.1000802@379.com> Message-ID: <3CFCFDD1.F880EAC7@licentiaten.umea.hsb.se> Ok. Got the makefile stuff working now though. There were duplicate headerfiles (objects.h I think) and config.h missing.. And then some directory structure is used in the #include statements.. Made it difficult just copying the files into a project. > Yes, it's easy. Just create a .LIB project in MSVC and put > in all of the source files (except for drawstuff and the > examples, obviously). > From ashok at globalsoft.co.in Thu Jun 6 01:33:09 2002 From: ashok at globalsoft.co.in (Ashokkumar) Date: Thu Jun 6 01:33:09 2002 Subject: [ODE] ODE.lib linkage errrors(2) Message-ID: <000a01c20d34$969ae7f0$5a00a8c0@ashok> Hi, i have downloaded carterrain source and trying to compile it. i have downloaded allegro,allegrogl and ode latest. all are compiled fine,but i'm getting the following linkage errors of ode, ode.lib(space.obj) : error LNK2001: unresolved external symbol __ftol2 ode.lib(misc.obj) : error LNK2001: unresolved external symbol __ftol2 ode.lib(error.obj) : error LNK2001: unresolved external symbol __imp__MessageBoxA at 16 can u help to sove this problem please reply me asap. thanks & regards ashokkumar -------------- next part -------------- An HTML attachment was scrubbed... URL: http://q12.org/pipermail/ode/attachments/20020606/a6850ada/attachment.htm From dylan.banarse at creaturelabs.com Thu Jun 6 05:17:02 2002 From: dylan.banarse at creaturelabs.com (Dylan Banarse) Date: Thu Jun 6 05:17:02 2002 Subject: [ODE] Job Offered: Physics Simulation Programmer Message-ID: <408CF8163395D411B8B4006097D902DA012ECA2C@phoenix.cyberlife.co.uk> Position available to work on a groundbreaking artificial-life, cross-media entertainment project for Creature Labs in Cambridge, England. Based on Artificial-life the project involves evolution, distributed artificial worlds and mass audiences. The candidate will work within a team of developers and will be responsible for customising and optimising 3D real-time physics engines for particular applications. The primary requirement of the candidate is a strong background in applied mathematics and numerical algorithm optimisation. Experience working with 3D real-time physics engines is essential. The candidate will be working in C++ and C, experience in processor optimisation would be a bonus. Must work well within a team and be capable of working to tight deadlines in a dynamic environment. An interest in Artificial-Life is required, particular interest in evolutionary systems, neural networks and control theory would be beneficial. The position is due to open summer/autumn 2002 and Creature Labs will be interviewing for the best candidate in the preceding period. Competitive salaries for the right candidate! Contact sarah.reardon at creaturelabs.com with CV, references and details. www.creaturelabs.com From peanutt at iprimus.com.au Fri Jun 7 03:31:02 2002 From: peanutt at iprimus.com.au (Adam Robinson) Date: Fri Jun 7 03:31:02 2002 Subject: [ODE] Expieranced ODE User Message-ID: <002001c20e0e$a82f5340$a0d832d2@peanutt> Heyas, Im looking for someone with expierance with ODE to help port into a game engine we are using to create a story driven car racing game. We have a pending deal with a large scaled Australian muscle car magazine to help proived funding and assistance. We are looking to present a demo to Codemasters who have said to provide them with a working demo. At the moment it would be a non paid job to help complete a working demo of the game. We have a full art team and only one programmer tho ( the lead guy decided hed quit) that would handle the 3d engine side of the game. Any help or assistance would be appreciated. Cheers Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: http://q12.org/pipermail/ode/attachments/20020607/cd3b53f4/attachment.htm From martin at metahuman.org Fri Jun 7 06:21:02 2002 From: martin at metahuman.org (Martin C. Martin) Date: Fri Jun 7 06:21:02 2002 Subject: [ODE] Expieranced ODE User References: <002001c20e0e$a82f5340$a0d832d2@peanutt> Message-ID: <3D00B31C.1CE23E95@metahuman.org> > Im looking for someone with expierance with ODE to help port into a > game engine we are > using to create a story driven car racing game. You realize ODE is distributed under the LGPL right? And that means you need to provide the source to the lib, and a way for anyone who hacks it to link their changes into the game? So people will be able to reduce gravity, change friction, or even completely replace the physics engine if they want? If so, that'll be a lot of fun. :) Does the company providing the funding know that? Does the deal you're about to sign allow that? Note: I'm not a lawyer, but that's my understanding of the LGPL. I suggest you show both the deal you're signing and ODE's LICENSE.TXT file to your lawyer. Thought you'd want to know now rather than later, Martin From francis.irving at creaturelabs.com Fri Jun 7 06:35:01 2002 From: francis.irving at creaturelabs.com (Francis Irving) Date: Fri Jun 7 06:35:01 2002 Subject: [ODE] Expieranced ODE User In-Reply-To: <3D00B31C.1CE23E95@metahuman.org> References: <002001c20e0e$a82f5340$a0d832d2@peanutt> <3D00B31C.1CE23E95@metahuman.org> Message-ID: On Fri, 07 Jun 2002 09:20:28 -0400, "Martin C. Martin" wrote: >You realize ODE is distributed under the LGPL right? And that means you >need to provide the source to the lib, and a way for anyone who hacks it >to link their changes into the game? So people will be able to reduce >gravity, change friction, or even completely replace the physics engine >if they want? If so, that'll be a lot of fun. :) > >Does the company providing the funding know that? Does the deal you're >about to sign allow that? In practice it isn't a problem. If they link ODE into a separate "ode.dll", and provide their source code changes somewhere, then that's fine. Publishers, and most customers, won't even know or understand this subtle distinction, and their contracts almost certainly won't mention it. It's really no different from dynamically linking to DirectX, or even user32.dll. As professional programmers, we set the agenda as to what level of open source code reuse is acceptable in a commercial application (before the whole thing is effectively open source). There's no need to fear that power. Francis From anselm at hook.org Fri Jun 7 10:20:02 2002 From: anselm at hook.org (Anselm Hook) Date: Fri Jun 7 10:20:02 2002 Subject: [ODE] Expieranced ODE User In-Reply-To: Message-ID: I can already see that debating this here isn't going to go far without some kind of action! I looked at the LGPL just now and there certainly seems to be some ambiguity, such as clause 5 about what constitutes a derivative work or not. Honestly I think the LGPL is a pernicious license and complex enough that it would scare investors - it certainly scares me. May I suggest that the best action to do is ask Russ to liberalize the license more for you (even if you are confident that you have no liability under the LGPL). Your investors (who may not be schooled in the LGPL) would appreciate the clarity anyway. Basically I just don't see any resolution here at a discussion level without consulting Russ. -a On Fri, 7 Jun 2002, Francis Irving wrote: > On Fri, 07 Jun 2002 09:20:28 -0400, "Martin C. Martin" > wrote: > > >You realize ODE is distributed under the LGPL right? And that means you > >need to provide the source to the lib, and a way for anyone who hacks it > >to link their changes into the game? So people will be able to reduce > >gravity, change friction, or even completely replace the physics engine > >if they want? If so, that'll be a lot of fun. :) > > > >Does the company providing the funding know that? Does the deal you're > >about to sign allow that? > > In practice it isn't a problem. If they link ODE into a separate > "ode.dll", and provide their source code changes somewhere, then > that's fine. Publishers, and most customers, won't even know or > understand this subtle distinction, and their contracts almost > certainly won't mention it. > > It's really no different from dynamically linking to DirectX, or even > user32.dll. As professional programmers, we set the agenda as to what > level of open source code reuse is acceptable in a commercial > application (before the whole thing is effectively open source). > There's no need to fear that power. > > Francis > _______________________________________________ > ODE mailing list > ODE at q12.org > http://q12.org/mailman/listinfo/ode > From ericc at xenopi.com Sat Jun 8 00:29:01 2002 From: ericc at xenopi.com (Eric Cha) Date: Sat Jun 8 00:29:01 2002 Subject: [ODE] Newbie question Message-ID: <004301c20ebe$190f1870$6401a8c0@donald> Hi, I'm playing around with ODE (very cool and a whole lot more stable than my crude and amateur physics code). One question I have is, what/where is the file "dcCore.h"? I am trying to integrate the Tri-list collider code (in the "contrib" directory) and it is trying to include this file, but I can't find it anywhere in ODE, Contrib, or Opcode. Can someone illuminate this poor unfortunate soul? Thanks, Eric --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.365 / Virus Database: 202 - Release Date: 5/24/2002 From erwin at vo.com Sat Jun 8 03:30:02 2002 From: erwin at vo.com (Erwin de Vries) Date: Sat Jun 8 03:30:02 2002 Subject: [ODE] Newbie question References: <004301c20ebe$190f1870$6401a8c0@donald> Message-ID: <004c01c20ed7$5c669760$0101a8c0@athlon> You should get a more recent version .The first version wasnt compilable. The current (2nd) version is. Erwin ----- Original Message ----- From: "Eric Cha" To: Sent: Saturday, June 08, 2002 09:28 Subject: [ODE] Newbie question > Hi, > > I'm playing around with ODE (very cool and a whole lot more stable than > my crude and amateur physics code). One question I have is, what/where > is the file "dcCore.h"? I am trying to integrate the Tri-list collider > code (in the "contrib" directory) and it is trying to include this file, > but I can't find it anywhere in ODE, Contrib, or Opcode. Can someone > illuminate this poor unfortunate soul? > > Thanks, > > Eric > > --- > Outgoing mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.365 / Virus Database: 202 - Release Date: 5/24/2002 > > > _______________________________________________ > ODE mailing list > ODE at q12.org > http://q12.org/mailman/listinfo/ode > > From SkeedaddIer at aol.com Sun Jun 9 08:57:01 2002 From: SkeedaddIer at aol.com (SkeedaddIer@aol.com) Date: Sun Jun 9 08:57:01 2002 Subject: [ODE] collision detection/response without using ODE's collision engine Message-ID: <63.cb4af31.2a34d491@aol.com> Hi, I am confused as to how to do collision detection/response of SPHERE objects against PLANES, without using ODE's internal collision engine. For example, I am trying to hack the test_boxstack.cpp file to handle bouncing of spheres against the ground plane when the user presses 's'. What i did: 1) i removed the nearCallback function and the dSpaceCollide function that calls it 2) i defined a groundplane struct containing a dBodyID/dGeomID with a position of 0,0,0 and normal of 0,0,1 groundplane.body = dBodyCreate(world); dBodySetPosition(groundplane.body, 0, 0, 0); groundplane.geom[0] = dCreatePlane (space,0,0,1,0); 3) during simLoop, i coded a simple test where: const dReal *p = dBodyGetPosition(obj[i].body); const dReal *v = dBodyGetLinearVel(obj[i].body); //vector3 is a personal vector lib I use, not part of ODE & also well tested vector3 position = vector3(p[0], p[1], p[2]); vector3 velocity = vector3(v[0], v[1], v[2]); vector3 newposition = position + velocity; if((newposition.z - sphere.radius) <= 0.0f) { //..filled in dContact struct here - see 4) below... dJointID c = dJointCreateContact (world, contactgroup, &contact); dJointAttach(c, obj[i].body, groundplane.body); } 4) this is how I filled my dContact struct: dVector3 contactposition = {newposition.x, newposition.y, (newposition.z - sphere.radius)}; dVector3 contactnormal = {0.0, 0.0, 1.0}; dContact contact; contact.surface.mode = dContactBounce; //dContactMu2; contact.surface.mu = dInfinity; contact.surface.mu2 = 0; contact.surface.bounce = 1.0; contact.surface.bounce_vel = 0.1; contact.geom.pos = contactposition; contact.geom.normal = contactnormal; contact.geom.depth = 0; contact.geom.g1 = obj[i].geom[0]; contact.geom.g2 = groundplane.geom[0]; 5) lastly i called dWorldStep as shown in the source. The spheres are not bouncing as they are expected to. Anyone have ideas what i may be doing wrong? Thanks in advance. From wgold at flyingplastic.com Sun Jun 9 09:10:02 2002 From: wgold at flyingplastic.com (Ken M) Date: Sun Jun 9 09:10:02 2002 Subject: [ODE] collision detection/response without using ODE's collision engine References: <63.cb4af31.2a34d491@aol.com> Message-ID: <003301c20fd0$30762ae0$4502a8c0@samson> Your contact depth is 0, which I think will never result in a bounce, as there is no interpenetration to recover from. Ken ----- Original Message ----- From: To: Sent: Sunday, June 09, 2002 11:56 AM Subject: [ODE] collision detection/response without using ODE's collision engine > Hi, > > I am confused as to how to do collision detection/response of SPHERE > objects against PLANES, without using ODE's internal collision engine. > > For example, I am trying to hack the test_boxstack.cpp file to handle > bouncing of spheres against the ground plane when the user presses 's'. > > What i did: > > 1) i removed the nearCallback function and the dSpaceCollide function > that calls it > > 2) i defined a groundplane struct containing a dBodyID/dGeomID with a > position of 0,0,0 and normal of 0,0,1 > > groundplane.body = dBodyCreate(world); > dBodySetPosition(groundplane.body, 0, 0, 0); > groundplane.geom[0] = dCreatePlane (space,0,0,1,0); > > 3) during simLoop, i coded a simple test where: > > const dReal *p = dBodyGetPosition(obj[i].body); > const dReal *v = dBodyGetLinearVel(obj[i].body); > > //vector3 is a personal vector lib I use, not part of ODE & also > well tested > vector3 position = vector3(p[0], p[1], p[2]); > vector3 velocity = vector3(v[0], v[1], v[2]); > vector3 newposition = position + velocity; > > if((newposition.z - sphere.radius) <= 0.0f) { > //..filled in dContact struct here - see 4) below... > dJointID c = dJointCreateContact (world, contactgroup, &contact); > dJointAttach(c, obj[i].body, groundplane.body); > } > > > 4) this is how I filled my dContact struct: > > dVector3 contactposition = {newposition.x, > newposition.y, > (newposition.z - > sphere.radius)}; > > dVector3 contactnormal = {0.0, 0.0, 1.0}; > > dContact contact; > > contact.surface.mode = dContactBounce; //dContactMu2; > contact.surface.mu = dInfinity; > contact.surface.mu2 = 0; > contact.surface.bounce = 1.0; > contact.surface.bounce_vel = 0.1; > > contact.geom.pos = contactposition; > contact.geom.normal = contactnormal; > contact.geom.depth = 0; > contact.geom.g1 = obj[i].geom[0]; > contact.geom.g2 = groundplane.geom[0]; > > 5) lastly i called dWorldStep as shown in the source. > > The spheres are not bouncing as they are expected to. Anyone have > ideas what i may be doing wrong? Thanks in advance. > _______________________________________________ > ODE mailing list > ODE at q12.org > http://q12.org/mailman/listinfo/ode From eli at nuprometheus.com Mon Jun 10 13:47:02 2002 From: eli at nuprometheus.com (Eli Curtz) Date: Mon Jun 10 13:47:02 2002 Subject: [ODE] Optimizing for SIMD Message-ID: Hi all, This may be insane, but I just got the PS2 Linux kit and was idly considering porting ODE to it. Doing this "right" would involve implementing portions on the vector unit of the PS2. Has anybody out there thought about trying to optimize ODE for Altivec, SSE, or anything similar? I'm a little bit scared of the LCP solver, but it's only a few hundred lines of code, how hard could it be? - eli -- Eli Curtz Sycophant to the Stars eli at nuprometheus.com From stjaerna at mac.com Tue Jun 11 11:46:02 2002 From: stjaerna at mac.com (jon klein) Date: Tue Jun 11 11:46:02 2002 Subject: [ODE] Setting torque imparted by a hinge joint Message-ID: <4B286284-7D6B-11D6-A1F9-0003936A7C02@mac.com> Hi folks, in my application, I'd like to be able to set the torque applied to hinge joints. I see that the preferred way to use a hinge joint is to set the preferred speed of the joint, but I need to be able to set the torque explicitly for compatibility with my current physical simulator. First of all, is it possible that a future version of ODE might allow the joint torque to be a parameter that can be set in the joint? Secondly, in trying to do this manually, I seem to be getting the wrong results. Simulating hinge torque would impart both a torque and center of mass force on the body, but I suspect that the force I'm applying is somehow wrong, since the whole articulated body is picking up angular velocity in a way that it shouldn't be. Here are the forces I'm applying: For a hinge joint (with normal n) applying a torque T on a body (with center C relative to the hinge), the body's center of mass torque should be nT and the instantaneous center of mass force should be the cross product nT x C. Both of these forces are relative to the body's frame. Is this not correct? Any help is greatly appreciated! Thanks! - Jon From coding at natew.com Tue Jun 11 12:04:01 2002 From: coding at natew.com (Nate W) Date: Tue Jun 11 12:04:01 2002 Subject: [ODE] GETting torque imparted by a hinge joint In-Reply-To: <4B286284-7D6B-11D6-A1F9-0003936A7C02@mac.com> Message-ID: On Tue, 11 Jun 2002, jon klein wrote: > First of all, is it possible that a future version of ODE might > allow the joint torque to be a parameter that can be set in the > joint? On a related note, I'd like to be able to do the reverse - to *get* the force applied to a joint during the previous timestep, e.g.: dReal force = dJointGetXxxxxParam (dJointID, dParamFActual); One of the next things I want to add to my app is a seismograph-style readout of joint positions, but joint torques would probably be even more useful. Thanks, Nate Waddoups Redmond WA USA http://www.natew.com From duhprey at tosos.com Tue Jun 11 12:56:01 2002 From: duhprey at tosos.com (Daniel Duhprey) Date: Tue Jun 11 12:56:01 2002 Subject: [ODE] Enabling/Disabling bodies In-Reply-To: Message-ID: In an attempt to optimize over static bodies, I have some code to set the geometry of a body to zero and then set the Disable that body (also removing any joints, so that it should be in a disabled island) ... Except that when I do this the geometry, which I'd still like to collide with, no longer collides. Everything is fine if the geometry is set to 0 initially. But if its set to a body and then later reset to body 0, it stops colliding. Any ideas? -- ------------ email: duhprey at tosos.com www: http://paradox.tosos.com/~duhprey icq: 129354442 The European finds intercourse with Americans easy and agreeable. Einstein Not a shred of evidence exists in favor of the idea that life is serious. Gill From grubertm at hotmail.com Wed Jun 12 19:02:02 2002 From: grubertm at hotmail.com (Marco Grubert) Date: Wed Jun 12 19:02:02 2002 Subject: [ODE] Collision detection for arbitrary polytopes ? Message-ID: Hello, While reading through the manual I was surprised by the lack of triangle / poly collision detection. So how do you simulate arbitrary 3d models? By duplicating them based on the collision primitives available to ODE or by using a different collision detection system ? Or did I just miss something in the docs ? Thanks, Marco Grubert From ngbinh at glassegg.com Wed Jun 12 19:51:02 2002 From: ngbinh at glassegg.com (Nguyen Binh) Date: Wed Jun 12 19:51:02 2002 Subject: [ODE] Collision detection for arbitrary polytopes ? In-Reply-To: References: Message-ID: <116920493.20020613093723@glassegg.com> Hi Marco, You can use Opcode to do that and fortunately ODE had incoporated with Opcode (ver 1.0 though not the latest version). Let see the contribs\Tri-collider in ODE dir. Opcode is http://www.codercorner.com/Opcode.htm A great col-det lib IMHO. -- 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 coding at natew.com Wed Jun 12 20:09:01 2002 From: coding at natew.com (Nate W) Date: Wed Jun 12 20:09:01 2002 Subject: [ODE] Collision detection for arbitrary polytopes ? In-Reply-To: Message-ID: On Wed, 12 Jun 2002, Marco Grubert wrote: > While reading through the manual I was surprised by the lack of triangle / > poly collision detection. So how do you simulate arbitrary 3d models? ODE itself only includes support for a handful of primitive objects, but it can be extended - and fortunately for us, it has been extended. Check out the 'triangle collider' code in the /ode/contrib/ CVS directory: http://q12.org/cgi-bin/cvsweb.cgi/ode/contrib/tri-collider/ I am using it to do collision detection against height-mapped terrain, and it's working nicely. > Or did I just miss something in the docs ? Documentation for this stuff is sparse, but that's what the mailing list is for. :-) -- Nate Waddoups Redmond WA USA http://www.natew.com From grubertm at hotmail.com Wed Jun 12 20:41:01 2002 From: grubertm at hotmail.com (Marco Grubert) Date: Wed Jun 12 20:41:01 2002 Subject: [ODE] Collision detection for arbitrary polytopes ? References: <116920493.20020613093723@glassegg.com> Message-ID: Dear Nguyen, Hey that?s great news- I have been using Opcode for the past few months already, that should make things easy. But how do you deal with Opcode not supplying penetration depth ? Ah well, I am gonna take a look at Tri-collider and figure it out. Thanks a lot, Marco Grubert > From a_mark_as3 at bk.ru Thu Jun 13 05:43:01 2002 From: a_mark_as3 at bk.ru (Andrey) Date: Thu Jun 13 05:43:01 2002 Subject: [ODE] (no subject) Message-ID: <000a01c212d8$8e04a460$1c5c83c3@wplus.net> Is received quite good and even competitive (and furthermore - charge-free) engine. From joints there are no springs, and from geometry - convex hulls. All remaining looks not bad. On my sight it is not necessary to give the special attention additional features, and it is necessary to achieve the greatest stability of work. As a whole engine is almost completed and can be used in the serious projects without the special modifications. Andrey Markovich - Russia - Programmer -------------- next part -------------- An HTML attachment was scrubbed... URL: http://q12.org/pipermail/ode/attachments/20020613/e9f36fa5/attachment.htm From jason at 379.com Thu Jun 13 07:06:02 2002 From: jason at 379.com (J. Perkins) Date: Thu Jun 13 07:06:02 2002 Subject: [ODE] Collision detection for arbitrary polytopes ? References: Message-ID: <3D08A453.8080307@379.com> Nate W wrote: > http://q12.org/cgi-bin/cvsweb.cgi/ode/contrib/tri-collider/ > > I am using it to do collision detection against height-mapped terrain, and > it's working nicely. I'll take this opportunity to say that OPCODE 1.1 makes this integration with ODE a lot easier. I had no trouble getting a sphere-mesh test working within a day. If I ever get the chance to add tests for the other primitives I will package it up as a contrib, but for now you can get the source from my project at: http://www.379.com/f4/ Look here: F4/Services/Collider/Src/mesh.cpp (Thanks to Pierre for the lib and his help getting it working). Jason From jason at 379.com Thu Jun 13 07:10:02 2002 From: jason at 379.com (J. Perkins) Date: Thu Jun 13 07:10:02 2002 Subject: [ODE] Collision detection for arbitrary polytopes ? References: <116920493.20020613093723@glassegg.com> Message-ID: <3D08A56A.70809@379.com> Marco Grubert wrote: > Hey that?s great news- I have been using Opcode for the past few months > already, that should make things easy. But how do you deal with Opcode not > supplying penetration depth ? Opcode 1.1 does provide a penetration depth, at least for spheres, I haven't looked at the other shapes yet. But the workaround is to use Opcode to generate a list of colliding faces, then use a more sophisticated test on those faces to determine the depth. Jason 379 From p.terdiman at wanadoo.fr Thu Jun 13 07:23:01 2002 From: p.terdiman at wanadoo.fr (Pierre Terdiman) Date: Thu Jun 13 07:23:01 2002 Subject: [ODE] Collision detection for arbitrary polytopes ? References: <3D08A453.8080307@379.com> Message-ID: <006701c212e5$ec80a5e0$7401a8c0@nwpc1> And I'll take this opportunity to say that Opcode 1.2 has faster sphere-mesh tests (but still unreleased, no time - old song, I know). Two things provided huge speedups (in case someone can't wait and want to implement them) : - sphere-mesh queries can early exit as soon as the sphere totally contains a box of a node (hence we know it also contains all boxes of all children and we can directly dump the list of related triangles) - temporal coherence can help by using a slightly larger sphere for the query, and keeping track of touched triangles. Next frame, if the previously used larger sphere still contains current sphere, no need to do the query, we can reuse the list of triangles from the previous frame to compute the collision response. We'll get more triangles than strictly necessary, but overall it runs faster. It also works for other volumes of course, not only spheres. Pierre ----- Original Message ----- From: "J. Perkins" Cc: Sent: Thursday 13 June 2002 15:55 Subject: Re: [ODE] Collision detection for arbitrary polytopes ? > Nate W wrote: > > http://q12.org/cgi-bin/cvsweb.cgi/ode/contrib/tri-collider/ > > > > I am using it to do collision detection against height-mapped terrain, and > > it's working nicely. > > I'll take this opportunity to say that OPCODE 1.1 makes this > integration with ODE a lot easier. I had no trouble getting > a sphere-mesh test working within a day. If I ever get the > chance to add tests for the other primitives I will package > it up as a contrib, but for now you can get the source from > my project at: > > http://www.379.com/f4/ > > Look here: > > F4/Services/Collider/Src/mesh.cpp > > (Thanks to Pierre for the lib and his help getting it working). > > Jason > > > > _______________________________________________ > ODE mailing list > ODE at q12.org > http://q12.org/mailman/listinfo/ode From dmcclurg at pandemicstudios.com.au Thu Jun 13 21:20:02 2002 From: dmcclurg at pandemicstudios.com.au (David McClurg) Date: Thu Jun 13 21:20:02 2002 Subject: [ODE] are force accumulators zeroed if body is disabled? Message-ID: i'm lazy. does anyone know off hand about this? dBodyDisable (bodyID); dBodyAddForce (bodyID, fx, fy, fz); dWorldStep (worldID, stepsize); // should the force accumulators be set to zero after this integrator step for bodyID? dBodyEnable (bodyID); From dmcclurg at pandemicstudios.com.au Fri Jun 14 00:25:02 2002 From: dmcclurg at pandemicstudios.com.au (David McClurg) Date: Fri Jun 14 00:25:02 2002 Subject: [ODE] are force accumulators zeroed if body is disabled? Message-ID: I found that dBodyDisable() allows large force accumulators to build up. I suppose this is just a user error and not a bug but perhaps it could be documented. also, i have some memory leaks. for example, dSphereClass never gets freed. i don't see anywhere in ode that takes care of freeing dSphereClass. Am I missing something? thanks for a great lib in ode (opcode too) -----Original Message----- From: David McClurg Sent: Friday, 14 June 2002 2:21 PM To: ode at q12.org Subject: [ODE] are force accumulators zeroed if body is disabled? i'm lazy. does anyone know off hand about this? dBodyDisable (bodyID); dBodyAddForce (bodyID, fx, fy, fz); dWorldStep (worldID, stepsize); // should the force accumulators be set to zero after this integrator step for bodyID? dBodyEnable (bodyID); From ngbinh at glassegg.com Fri Jun 14 00:39:01 2002 From: ngbinh at glassegg.com (Nguyen Binh) Date: Fri Jun 14 00:39:01 2002 Subject: [ODE] Collision detection for arbitrary polytopes ? In-Reply-To: <3D08A56A.70809@379.com> References: <116920493.20020613093723@glassegg.com> <3D08A56A.70809@379.com> Message-ID: <18721443434.20020614143708@glassegg.com> Yes, Opcode does provide penetration depth in Sphere and Ray collides with a poly soup! But I can't see any in poly-poly (TreeCollider) test. But would we need to get penetration depth of two arbitrary poly soup? I think we won't, or at least won't need to "compute" things like that (Maybe a little cheat here by a fake value???). Maybe the art of GAME physics is not (or not yet) making something ACT real just LOOK real. -- 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 p.terdiman at wanadoo.fr Fri Jun 14 01:32:08 2002 From: p.terdiman at wanadoo.fr (Pierre Terdiman) Date: Fri Jun 14 01:32:08 2002 Subject: [ODE] Collision detection for arbitrary polytopes ? References: <116920493.20020613093723@glassegg.com> <3D08A56A.70809@379.com> <18721443434.20020614143708@glassegg.com> Message-ID: <000f01c2137e$04b0ae10$7401a8c0@nwpc1> > Yes, Opcode does provide penetration depth in Sphere and Ray collides > with a poly soup! But I can't see any in poly-poly (TreeCollider) > test. Because that's very hard to do for arbitrary meshes. I don't think a good, convincing solution exists, and the ones I've seen are too slow for realtime anyway. If I had to implement it for next week, I would probably decompose the mesh into convex parts using SWIFT++, use the hierarchy of convex hulls as a BV-tree, then use SOLID 3.0 on top of this to compute penetration depth between 2 hulls. Would work, for a very high price. Pierre From SkeedaddIer at aol.com Fri Jun 14 04:07:02 2002 From: SkeedaddIer at aol.com (SkeedaddIer@aol.com) Date: Fri Jun 14 04:07:02 2002 Subject: [ODE] collision detection/response without using ODE's collision engine Message-ID: <195.83dd588.2a3b2845@aol.com> Hi, Ken - I tried to setting depth to (sphere.z-sphere.radius) since it would equal the penetration depth of the sphere against the plane at 0.0f. The spheres still pass right thru the plane, no bouncy collision response. Figured it would help if you or anyone could look over the code and figure out why i'm not getting the right results, so I posted it at: www.qlink.org/test_boxstack.txt Hope someone can fix this, i'm at wits end trying to figure out the basics so I can build on from there. Thanks in advance! From si_br0wn at hotmail.com Fri Jun 14 04:12:01 2002 From: si_br0wn at hotmail.com (Si Brown) Date: Fri Jun 14 04:12:01 2002 Subject: [ODE] are force accumulators zeroed if body is disabled? Message-ID: Hi David, >also, i have some memory leaks. for example, dSphereClass never gets >freed. i don't see anywhere in ode that takes care of freeing >dSphereClass. Am I missing something? > >[snip] dGeomDestroy destroys any geometry class in a generic manner. It does so by removing it from the space, calling the class destructor (null for dSphereClass) and freeing the memory used by the class. Also, destroying a space using dSpaceDestroy automatically calls dGeomDestroy on every geometry object in that space. Hope that helps, Simon _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. From coding at natew.com Fri Jun 14 11:09:01 2002 From: coding at natew.com (Nate W) Date: Fri Jun 14 11:09:01 2002 Subject: [ODE] apparent memory leaks In-Reply-To: Message-ID: On Fri, 14 Jun 2002, Si Brown wrote: > >also, i have some memory leaks. for example, dSphereClass never gets > >freed. i don't see anywhere in ode that takes care of freeing > >dSphereClass. Am I missing something? I ran into the same thing, using MSVC's _CrtDumpMemoryLeaks to detect leakage. Are you using VC.Net? Anyhow... In ODE .025, the geometry class singletons were not freed, but it's not a problem because they're singletons (only one of each will ever be allocated) and the OS wipes the entire heap when the process terminates. So it's nothing to worry about. I still prefer a clean memory leak dump when my app closes, though. It beats having to scan a list of a half-dozen "leaks" and make sure there isn't an extra leak or two due to something wrong in my application code. So I wrote some code to explicitly free the singletons. My recall is pretty fuzzy here, as I haven't dealt with this since upgrading to .030, but... I think Russ put some cleanup code in .030 but now there's a timing issue - your app is probably calling _CrtDumpMemoryLeaks before ODE cleans up the singletons. I couldn't find a way to resolve that timing issue because MFC calls _CrtDumpMemoryLeaks from deep inside itself... so, I put the explicit-cleanup function back into my ODE DLL and now I'm getting perfect memory leak reports again. Here's the function, just invoke it somewhere in your app's shutdown code. In my case it's called during CMyApp::~CMyApp, and that works fine: void __declspec (dllexport) dCloseODE () { if (colliders) { dFree (colliders->_data, sizeof (dColliderEntry) * classes->_anum); dFree (colliders, sizeof(dArrayBase)); colliders = 0; } if (classes) { for (int i = 0; i < classes->size (); i++) { dFree ((*classes)[i], sizeof (dxGeomClass)); } dFree (classes->_data, sizeof (dxGeomClass*) * classes->_anum); dFree (classes, sizeof(dArrayBase)); classes = 0; } } Nate Waddoups Redmond WA USA http://www.natew.com From gene at erachampion.com Fri Jun 14 11:15:02 2002 From: gene at erachampion.com (Gene Ruebsamen) Date: Fri Jun 14 11:15:02 2002 Subject: [ODE] Optimizing for SIMD In-Reply-To: Message-ID: Hello, I wonder how much SIMD operations will help speed up ODE. Unless I am mistaken, 3DNow! and SSE only support single-precision floating point operations. Thus, unless you are willing to take a hit in accuracy, your performance may not benefit too much; although, I am sure there are some areas of ODE where the SIMD instructions would benefit greatly.. Check out http://libsimd.sourceforge.net/ . Looks like someone is working on a portable SIMD library. Maybe we could use this in ODE... Any thoughts? Gene Ruebsamen > -----Original Message----- > From: ode-admin at q12.org [mailto:ode-admin at q12.org]On Behalf Of Eli Curtz > Sent: Monday, June 10, 2002 1:46 PM > To: ODE group > Subject: [ODE] Optimizing for SIMD > > > Hi all, > > This may be insane, but I just got the PS2 Linux kit and was idly > considering porting ODE to it. Doing this "right" would involve > implementing portions on the vector unit of the PS2. Has anybody out > there thought about trying to optimize ODE for Altivec, SSE, or > anything similar? I'm a little bit scared of the LCP solver, last words> but it's only a few hundred lines of code, how hard could > it be? > > - eli > > -- > Eli Curtz > Sycophant to the Stars > eli at nuprometheus.com > _______________________________________________ > ODE mailing list > ODE at q12.org > http://q12.org/mailman/listinfo/ode > From si_br0wn at hotmail.com Fri Jun 14 11:33:02 2002 From: si_br0wn at hotmail.com (Si Brown) Date: Fri Jun 14 11:33:02 2002 Subject: [ODE] apparent memory leaks Message-ID: Oops I should make sure I'm talking about the right thing before hitting the send button (i.e. geometry class objects vs geometry objects). It's worth mentioning though that the singletons still aren't freed by ODE when the app exits, and in a debug build are just flagged by the debug allocator so that the used memory is not reported by ODE when the app exits. Ta, Si (hopefully talking on-topic now) >From: Nate W >To: ode at q12.org >Subject: RE: [ODE] apparent memory leaks >Date: Fri, 14 Jun 2002 03:11:11 -0700 (PDT) > >On Fri, 14 Jun 2002, Si Brown wrote: > > > >also, i have some memory leaks. for example, dSphereClass never gets > > >freed. i don't see anywhere in ode that takes care of freeing > > >dSphereClass. Am I missing something? > >I ran into the same thing, using MSVC's _CrtDumpMemoryLeaks to detect >leakage. Are you using VC.Net? > >Anyhow... In ODE .025, the geometry class singletons were not freed, but >it's not a problem because they're singletons (only one of each will ever >be allocated) and the OS wipes the entire heap when the process >terminates. So it's nothing to worry about. I still prefer a clean >memory leak dump when my app closes, though. It beats having to scan a >list of a half-dozen "leaks" and make sure there isn't an extra leak or >two due to something wrong in my application code. So I wrote some code >to explicitly free the singletons. > >My recall is pretty fuzzy here, as I haven't dealt with this since >upgrading to .030, but... I think Russ put some cleanup code in .030 but >now there's a timing issue - your app is probably calling >_CrtDumpMemoryLeaks before ODE cleans up the singletons. I couldn't find >a way to resolve that timing issue because MFC calls _CrtDumpMemoryLeaks >from deep inside itself... so, I put the explicit-cleanup function back >into my ODE DLL and now I'm getting perfect memory leak reports again. > >Here's the function, just invoke it somewhere in your app's shutdown code. >In my case it's called during CMyApp::~CMyApp, and that works fine: > >void __declspec (dllexport) dCloseODE () >{ > if (colliders) > { > dFree (colliders->_data, sizeof (dColliderEntry) * classes->_anum); > dFree (colliders, sizeof(dArrayBase)); > colliders = 0; > } > if (classes) > { > for (int i = 0; i < classes->size (); i++) > { > dFree ((*classes)[i], sizeof (dxGeomClass)); > } > dFree (classes->_data, sizeof (dxGeomClass*) * classes->_anum); > dFree (classes, sizeof(dArrayBase)); > classes = 0; > } >} > > >Nate Waddoups >Redmond WA USA >http://www.natew.com > > >_______________________________________________ >ODE mailing list >ODE at q12.org >http://q12.org/mailman/listinfo/ode _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com From jvanwingen at piglet.toward.com Fri Jun 14 12:24:01 2002 From: jvanwingen at piglet.toward.com (Jacob Van Wingen) Date: Fri Jun 14 12:24:01 2002 Subject: [ODE] problem with 3 contact joints Message-ID: <200206141523.AA49480200@mail.toward.com> I'm new to ODE - attracted by the Freefall buggy demo. I've run into a problem while setting up a simple test program. In the test there is a bounding box defined using 6 planes, with no body attached and 2 spheres of equal mass thrown randomly into the box. The spheres roll and collide with each other nicely in the box, however when a sphere rolls into a corner of the box it begins to sink into the ground plane and then shoots straight up at a very high velocity. This also occurs if a sphere is touching the other sphere and two walls. It always appears to sink into the ground plane. my dSpaceCollide callback seems to allow for more enough collision points. the world ERP is set at 1.0 and the problem occurs even with very small time-steps. has anyone else encountered this problem, or know what's going on? thanks, Jacob From coding at natew.com Fri Jun 14 12:24:33 2002 From: coding at natew.com (Nate W) Date: Fri Jun 14 12:24:33 2002 Subject: [ODE] apparent memory leaks In-Reply-To: Message-ID: On Fri, 14 Jun 2002, Si Brown wrote: > It's worth mentioning though that the singletons still aren't freed by ODE > when the app exits, and in a debug build are just flagged by the debug > allocator so that the used memory is not reported by ODE when the app exits. OK, thanks for the clarification. _CrtDumpMemoryLeaks doesn't grok ODE's debug flag though, so if you use that to dump memory leaks for your whole application, ODE's singletons still show up (unless I use dCloseODE). -- Nate Waddoups Redmond WA USA http://www.natew.com From coding at natew.com Fri Jun 14 12:35:02 2002 From: coding at natew.com (Nate W) Date: Fri Jun 14 12:35:02 2002 Subject: [ODE] problem with 3 contact joints In-Reply-To: <200206141523.AA49480200@mail.toward.com> Message-ID: On Fri, 14 Jun 2002, Jacob Van Wingen wrote: > my dSpaceCollide callback seems to allow for more enough collision points. My guess, based on the behavior you've described, is that not all of those collision points are being processed correctly (read as: contact joints aren't being created properly for all of the collisions). Have you tried setting a breakpoint on dJointCreateContact and manually inspecting all of the parameters to that (and to dJointAttach) to make sure they're all reasonable? Since it behaves properly most of the time, you could try doing something like this inside your contact-processing loop: int iCount = dCollide (o1, o2, iMaxContacts, &contact[0].geom, sizeof (dContact)); if (iCount) { for (int iContact = 0; iContact < iMax; iContact++) { if (iContact > 0) Breakpoint (); Where "Breakpoint()" is a platform-specific function that causes the debugger to break. In Win32, it's DebugBreak (); That way your app should run freely until you get into the multiple-contact situation. And if that breakpoint never gets hit, that tells you something too. -- Nate Waddoups Redmond WA USA http://www.natew.com From jimfing at yahoo.com Sun Jun 16 15:25:02 2002 From: jimfing at yahoo.com (James Fingleton) Date: Sun Jun 16 15:25:02 2002 Subject: [ODE] Another lame newbie question Message-ID: <20020616222412.58613.qmail@web9502.mail.yahoo.com> Hi everyone, just discouvered ODE today...it looks pretty cool. Been trying to make the config.h file, but can't get make to work. I'm using VC++ 6 and have run the VCVARS43.bat file to set stuff up. When I type: make configure I get the following message: make: *** No rule to make target `configure'. Stop. What the hell??? I noticed someone else on this list had the same problem but no one replied. Oh yeah, I'm using the make.exe supplied by the link in the help docs. Thanks for any help James Fingleton __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com From anselm at hook.org Sun Jun 16 18:53:02 2002 From: anselm at hook.org (Anselm Hook) Date: Sun Jun 16 18:53:02 2002 Subject: [ODE] Another lame newbie question In-Reply-To: <20020616222412.58613.qmail@web9502.mail.yahoo.com> Message-ID: from cygwin: lynx http://www.q12.org/ode/release/ode-0.03.tgz[return][return][q][y] tar zxvf ode[esc][return] cd ode[esc][return] vi config/user-settings - changed to cygwin - [return] lynx http://www.q12.org/ode/bin/make.exe[return][return][q][y] mv make.exe gmake.exe [return] gmake [return] Don't make configure - just 'make'. And make sure that your path doesn't refer to the wrong make. Also make sure to set your config/user-settings. If you still have problems, what OS? -a On Sun, 16 Jun 2002, James Fingleton wrote: > Hi everyone, just discouvered ODE today...it looks > pretty cool. > > Been trying to make the config.h file, but can't get > make to work. I'm using VC++ 6 and have run the > VCVARS43.bat file to set stuff up. When I type: > > make configure > > I get the following message: > > make: *** No rule to make target `configure'. Stop. > > What the hell??? I noticed someone else on this list > had the same problem but no one replied. > > Oh yeah, I'm using the make.exe supplied by the link > in the help docs. > > Thanks for any help > > James Fingleton > > __________________________________________________ > Do You Yahoo!? > Yahoo! - Official partner of 2002 FIFA World Cup > http://fifaworldcup.yahoo.com > _______________________________________________ > ODE mailing list > ODE at q12.org > http://q12.org/mailman/listinfo/ode > From ngbinh at glassegg.com Sun Jun 16 19:19:02 2002 From: ngbinh at glassegg.com (Nguyen Binh) Date: Sun Jun 16 19:19:02 2002 Subject: [ODE] Optimizing for SIMD In-Reply-To: References: Message-ID: <1412763974.20020617092204@glassegg.com> Hi , Yeah, I share the thoughts that SIMD code will improve ODE speed (thus stability) much. For example, on big part of ODE, the LCP solver can be rewritten in SIMD .Base on some docs at Intel it will improve speed about 5 times(Oh lah). And Intel has SML (Small Matrix Library) written in SIMD, MMX. I think we can use it to solve LCP problem in ODE. SML is http://www.intel.com/design/pentiumiii/sml/src.zip -- 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 dmcclurg at pandemicstudios.com.au Sun Jun 16 20:04:01 2002 From: dmcclurg at pandemicstudios.com.au (David McClurg) Date: Sun Jun 16 20:04:01 2002 Subject: [ODE] Optimizing for SIMD Message-ID: How portable? From the libsimd website: > Most modern processors possess Single Instruction Multiple Data (SIMD) instructions hmmm. For myself, I'm using single-precision ODE on game consoles where I might not have an intel chip. Could this be a contrib or an #ifdef thing? -----Original Message----- From: Gene Ruebsamen [mailto:gene at erachampion.com] Sent: Saturday, 15 June 2002 4:20 AM To: ODE group Subject: RE: [ODE] Optimizing for SIMD Hello, I wonder how much SIMD operations will help speed up ODE. Unless I am mistaken, 3DNow! and SSE only support single-precision floating point operations. Thus, unless you are willing to take a hit in accuracy, your performance may not benefit too much; although, I am sure there are some areas of ODE where the SIMD instructions would benefit greatly.. Check out http://libsimd.sourceforge.net/ . Looks like someone is working on a portable SIMD library. Maybe we could use this in ODE... Any thoughts? Gene Ruebsamen From anselm at hook.org Sun Jun 16 20:31:01 2002 From: anselm at hook.org (Anselm Hook) Date: Sun Jun 16 20:31:01 2002 Subject: [ODE] Another lame newbie question In-Reply-To: Message-ID: Oh, VC6.0. Can't help you there unfortunately. -a > > If you still have problems, what OS? > > -a From dmcclurg at pandemicstudios.com.au Sun Jun 16 20:31:09 2002 From: dmcclurg at pandemicstudios.com.au (David McClurg) Date: Sun Jun 16 20:31:09 2002 Subject: [ODE] apparent memory leaks Message-ID: Nate's patch worked for me. No more leaks. If you use CVS, put this function at the bottom of geom.cpp and call it before exit. void dCloseODE() { if (colliders) { delete colliders; colliders = 0; } if (classes) { for (int i = 0; i < classes->size (); i++) { dFree ((*classes)[i], sizeof (dxGeomClass)); } delete classes; classes = 0; } } -----Original Message----- From: Si Brown [mailto:si_br0wn at hotmail.com] Sent: Saturday, 15 June 2002 4:31 AM To: ode at q12.org Subject: RE: [ODE] apparent memory leaks Oops I should make sure I'm talking about the right thing before hitting the send button (i.e. geometry class objects vs geometry objects). It's worth mentioning though that the singletons still aren't freed by ODE when the app exits, and in a debug build are just flagged by the debug allocator so that the used memory is not reported by ODE when the app exits. Ta, Si (hopefully talking on-topic now) >From: Nate W >To: ode at q12.org >Subject: RE: [ODE] apparent memory leaks >Date: Fri, 14 Jun 2002 03:11:11 -0700 (PDT) > >On Fri, 14 Jun 2002, Si Brown wrote: > > > >also, i have some memory leaks. for example, dSphereClass never gets > > >freed. i don't see anywhere in ode that takes care of freeing > > >dSphereClass. Am I missing something? > >I ran into the same thing, using MSVC's _CrtDumpMemoryLeaks to detect >leakage. Are you using VC.Net? > >Anyhow... In ODE .025, the geometry class singletons were not freed, but >it's not a problem because they're singletons (only one of each will ever >be allocated) and the OS wipes the entire heap when the process >terminates. So it's nothing to worry about. I still prefer a clean >memory leak dump when my app closes, though. It beats having to scan a >list of a half-dozen "leaks" and make sure there isn't an extra leak or >two due to something wrong in my application code. So I wrote some code >to explicitly free the singletons. > >My recall is pretty fuzzy here, as I haven't dealt with this since >upgrading to .030, but... I think Russ put some cleanup code in .030 but >now there's a timing issue - your app is probably calling >_CrtDumpMemoryLeaks before ODE cleans up the singletons. I couldn't find >a way to resolve that timing issue because MFC calls _CrtDumpMemoryLeaks >from deep inside itself... so, I put the explicit-cleanup function back >into my ODE DLL and now I'm getting perfect memory leak reports again. > >Here's the function, just invoke it somewhere in your app's shutdown code. >In my case it's called during CMyApp::~CMyApp, and that works fine: > >void __declspec (dllexport) dCloseODE () >{ > if (colliders) > { > dFree (colliders->_data, sizeof (dColliderEntry) * classes->_anum); > dFree (colliders, sizeof(dArrayBase)); > colliders = 0; > } > if (classes) > { > for (int i = 0; i < classes->size (); i++) > { > dFree ((*classes)[i], sizeof (dxGeomClass)); > } > dFree (classes->_data, sizeof (dxGeomClass*) * classes->_anum); > dFree (classes, sizeof(dArrayBase)); > classes = 0; > } >} > > >Nate Waddoups >Redmond WA USA >http://www.natew.com > From ps_yumemi at yahoo.com Sun Jun 16 21:47:01 2002 From: ps_yumemi at yahoo.com (pia dalusong) Date: Sun Jun 16 21:47:01 2002 Subject: [ODE] optimizing ode Message-ID: <20020617044613.12121.qmail@web9304.mail.yahoo.com> My friend developed a robot simulator in ode using a 1.4GHz p4. The problem is, am just using 550 MHz computer with winxp and everything is so slow. What can I do to make the program faster? can i use all the primitive shapes to create a robot and the collision detection will still work fine or do i have to take note of the capped cylinder? thanx __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com From dmcclurg at pandemicstudios.com.au Sun Jun 16 23:15:01 2002 From: dmcclurg at pandemicstudios.com.au (David McClurg) Date: Sun Jun 16 23:15:01 2002 Subject: [ODE] memory trashing bug in dcTriListCollider.cpp? Message-ID: In dcTriListCollider::CollideBox(), I'm getting a memory overwrite around Line 158. I think the OutContact reference is past the end of the Contacts list. My Box is a "big" box if that matters at all. I think there is a missing test somewhere. Could someone who understand this code better shed any light on this? if (Index == OutTriCount){ dContactGeom& OutContact = *CONTACT(Contacts, OutTriCount * Stride); From dmcclurg at pandemicstudios.com.au Sun Jun 16 23:31:02 2002 From: dmcclurg at pandemicstudios.com.au (David McClurg) Date: Sun Jun 16 23:31:02 2002 Subject: [ODE] RE: memory trashing bug in dcTriListCollider.cpp? Message-ID: When I increased my contact array size from 6 to 20, the crash went away (or moved :p). I'm hoping there is a incorrect/missing test somewhere since I'm passing in the size (N) of the contact array to dCollide(). static void NearCallback(void* data, dGeomID o1, dGeomID o2) { const U32 N = 20; // changed from 6 -> 20 and crash went away dContact contacts[N]; // get the contacts up to a maximum of N contacts const U32 n = dCollide(o1, o2, N, &contacts[0].geom, sizeof(dContact)); -----Original Message----- From: David McClurg [mailto:dpm at efn.org]On Behalf Of David McClurg Sent: Monday, 17 June 2002 4:16 PM To: ode at q12.org Subject: memory trashing bug in dcTriListCollider.cpp? In dcTriListCollider::CollideBox(), I'm getting a memory overwrite around Line 158. I think the OutContact reference is past the end of the Contacts list. My Box is a "big" box if that matters at all. I think there is a missing test somewhere. Could someone who understand this code better shed any light on this? if (Index == OutTriCount){ dContactGeom& OutContact = *CONTACT(Contacts, OutTriCount * Stride); From coding at natew.com Mon Jun 17 00:24:01 2002 From: coding at natew.com (Nate W) Date: Mon Jun 17 00:24:01 2002 Subject: [ODE] RE: memory trashing bug in dcTriListCollider.cpp? In-Reply-To: Message-ID: FWIW, I ran into the same thing. I don't remember what value of N I was using at first, but I'm now using 50. I didn't investigate any further though, so I can't shed any light on what's going on. But, if it makes you feel any better, you're not alone. :-) On Mon, 17 Jun 2002, David McClurg wrote: > When I increased my contact array size from 6 to 20, the crash went > away (or moved :p). I'm hoping there is a incorrect/missing test > somewhere since I'm passing in the size (N) of the contact array to > dCollide(). > > static void NearCallback(void* data, dGeomID o1, dGeomID o2) > { > const U32 N = 20; // changed from 6 -> 20 and crash went away > dContact contacts[N]; > > // get the contacts up to a maximum of N contacts > const U32 n = dCollide(o1, o2, N, &contacts[0].geom, sizeof(dContact)); -- Nate Waddoups Redmond WA USA http://www.natew.com From dmcclurg at pandemicstudios.com.au Mon Jun 17 00:25:02 2002 From: dmcclurg at pandemicstudios.com.au (David McClurg) Date: Mon Jun 17 00:25:02 2002 Subject: [ODE] GeomGroups Message-ID: I'm using a GeomGroup so that my static geometry (triangle lists) will not self-collide. The problem I'm having is that the NearCallback gets a pointer to the Group instead of the Geoms in it. Is that intended? From jimfing at yahoo.com Mon Jun 17 03:36:02 2002 From: jimfing at yahoo.com (James Fingleton) Date: Mon Jun 17 03:36:02 2002 Subject: [ODE] Another lame newbie question In-Reply-To: Message-ID: <20020617103501.69370.qmail@web9505.mail.yahoo.com> Yeah, I'm using Windows XP. All I need to do is to create config.h. Then I can just use the IDE to compile everything else. Jim --- Anselm Hook wrote: > > Oh, VC6.0. Can't help you there unfortunately. > > -a > > > > > If you still have problems, what OS? > > > > -a > > _______________________________________________ > ODE mailing list > ODE at q12.org > http://q12.org/mailman/listinfo/ode __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com From erwin at vo.com Mon Jun 17 11:27:02 2002 From: erwin at vo.com (Erwin de Vries) Date: Mon Jun 17 11:27:02 2002 Subject: [ODE] RE: memory trashing bug in dcTriListCollider.cpp? References: Message-ID: <00d601c2162c$75737c30$0101a8c0@athlon> This is indeed a problem with the current tri-collider. The problem is finding the N contacts that affect the simulation the most. I didnt bother with this, and simply assumed an infinite amount. Erwin ----- Original Message ----- From: "Nate W" To: Sent: Monday, June 17, 2002 01:25 Subject: Re: [ODE] RE: memory trashing bug in dcTriListCollider.cpp? > > FWIW, I ran into the same thing. I don't remember what value of N I was > using at first, but I'm now using 50. I didn't investigate any further > though, so I can't shed any light on what's going on. But, if it makes > you feel any better, you're not alone. :-) > > > On Mon, 17 Jun 2002, David McClurg wrote: > > > When I increased my contact array size from 6 to 20, the crash went > > away (or moved :p). I'm hoping there is a incorrect/missing test > > somewhere since I'm passing in the size (N) of the contact array to > > dCollide(). > > > > static void NearCallback(void* data, dGeomID o1, dGeomID o2) > > { > > const U32 N = 20; // changed from 6 -> 20 and crash went away > > dContact contacts[N]; > > > > // get the contacts up to a maximum of N contacts > > const U32 n = dCollide(o1, o2, N, &contacts[0].geom, sizeof(dContact)); > > -- > > Nate Waddoups > Redmond WA USA > http://www.natew.com > > > _______________________________________________ > ODE mailing list > ODE at q12.org > http://q12.org/mailman/listinfo/ode > > From dmcclurg at pandemicstudios.com.au Mon Jun 17 16:44:02 2002 From: dmcclurg at pandemicstudios.com.au (David McClurg) Date: Mon Jun 17 16:44:02 2002 Subject: [ODE] RE: memory trashing bug in dcTriListCollider.cpp? Message-ID: Perhaps this will do the index checking correctly... if (Index == OutTriCount){ dIASSERT(OutTriCount < Flags); dContactGeom* Contact = CONTACT(Contacts, OutTriCount * Stride); -----Original Message----- From: Erwin de Vries [mailto:erwin at vo.com] Sent: Tuesday, 18 June 2002 4:24 AM To: ode at q12.org Subject: Re: [ODE] RE: memory trashing bug in dcTriListCollider.cpp? This is indeed a problem with the current tri-collider. The problem is finding the N contacts that affect the simulation the most. I didnt bother with this, and simply assumed an infinite amount. Erwin ----- Original Message ----- From: "Nate W" To: Sent: Monday, June 17, 2002 01:25 Subject: Re: [ODE] RE: memory trashing bug in dcTriListCollider.cpp? > > FWIW, I ran into the same thing. I don't remember what value of N I was > using at first, but I'm now using 50. I didn't investigate any further > though, so I can't shed any light on what's going on. But, if it makes > you feel any better, you're not alone. :-) > > > On Mon, 17 Jun 2002, David McClurg wrote: > > > When I increased my contact array size from 6 to 20, the crash went > > away (or moved :p). I'm hoping there is a incorrect/missing test > > somewhere since I'm passing in the size (N) of the contact array to > > dCollide(). > > > > static void NearCallback(void* data, dGeomID o1, dGeomID o2) > > { > > const U32 N = 20; // changed from 6 -> 20 and crash went away > > dContact contacts[N]; > > > > // get the contacts up to a maximum of N contacts > > const U32 n = dCollide(o1, o2, N, &contacts[0].geom, sizeof(dContact)); > From erwin at vo.com Tue Jun 18 12:30:02 2002 From: erwin at vo.com (Erwin de Vries) Date: Tue Jun 18 12:30:02 2002 Subject: [ODE] RE: memory trashing bug in dcTriListCollider.cpp? References: Message-ID: <00b201c216fe$78461bc0$0101a8c0@athlon> Yea that probably works. Make sure to use Flags & 0xffff for future compatibility. Erwin ----- Original Message ----- From: "David McClurg" To: Sent: Tuesday, June 18, 2002 01:45 Subject: RE: [ODE] RE: memory trashing bug in dcTriListCollider.cpp? > Perhaps this will do the index checking correctly... > > if (Index == OutTriCount){ > dIASSERT(OutTriCount < Flags); > dContactGeom* Contact = CONTACT(Contacts, OutTriCount * Stride); > > -----Original Message----- > From: Erwin de Vries [mailto:erwin at vo.com] > Sent: Tuesday, 18 June 2002 4:24 AM > To: ode at q12.org > Subject: Re: [ODE] RE: memory trashing bug in dcTriListCollider.cpp? > > > This is indeed a problem with the current tri-collider. The problem is > finding the N contacts that affect the simulation the most. I didnt bother > with this, and simply assumed an infinite amount. > > Erwin > > ----- Original Message ----- > From: "Nate W" > To: > Sent: Monday, June 17, 2002 01:25 > Subject: Re: [ODE] RE: memory trashing bug in dcTriListCollider.cpp? > > > > > > FWIW, I ran into the same thing. I don't remember what value of N I was > > using at first, but I'm now using 50. I didn't investigate any further > > though, so I can't shed any light on what's going on. But, if it makes > > you feel any better, you're not alone. :-) > > > > > > On Mon, 17 Jun 2002, David McClurg wrote: > > > > > When I increased my contact array size from 6 to 20, the crash went > > > away (or moved :p). I'm hoping there is a incorrect/missing test > > > somewhere since I'm passing in the size (N) of the contact array to > > > dCollide(). > > > > > > static void NearCallback(void* data, dGeomID o1, dGeomID o2) > > > { > > > const U32 N = 20; // changed from 6 -> 20 and crash went away > > > dContact contacts[N]; > > > > > > // get the contacts up to a maximum of N contacts > > > const U32 n = dCollide(o1, o2, N, &contacts[0].geom, > sizeof(dContact)); > > > _______________________________________________ > ODE mailing list > ODE at q12.org > http://q12.org/mailman/listinfo/ode > > From G.J.A.v.d.Bergen at cebra.tue.nl Wed Jun 19 04:12:02 2002 From: G.J.A.v.d.Bergen at cebra.tue.nl (Bergen, G.J.A. van den) Date: Wed Jun 19 04:12:02 2002 Subject: [ODE] Collision detection for arbitrary polytopes ? Message-ID: <81E5F727841DD211A5FD0008C728DB7B06E94BD0@campusx1.tue.nl> Even for a concave solid decomposed into convex subpart, finding the penetration depth is not trivial. Imagine a rod standing on the floor and leaning against a wall. Decomposing the static scene into a convex floor and a convex wall part, would result in two penetration depth vectors. The wall vector would be horizontal while the floor vector would be vertical. The actual penetration depth vector would point diagonally away from the floor and the wall. The problem is that in general you cannot combine the different penetration depth vectors to a single penetration depth vector for all subparts. You'd have to find the actual penetration depth vector on the level of the Minkowski sum of the rod and the floor-wall object. However, this Minkowski sum is concave and thus finding the point on the boundary closest to the origin is not that simple. Of course, you can treat the floor and the wall as separate objects and impose a glue constraint between them if the floor-wall object is dynamic as well. But if the number of supparts are large, the large number of glue constraint would impose quite a load on the simulator (torus tossed on a cone). -----Original Message----- From: Pierre Terdiman To: ode at q12.org Sent: 6/14/02 10:32 AM Subject: Re: Re[2]: [ODE] Collision detection for arbitrary polytopes ? > Yes, Opcode does provide penetration depth in Sphere and Ray collides > with a poly soup! But I can't see any in poly-poly (TreeCollider) > test. Because that's very hard to do for arbitrary meshes. I don't think a good, convincing solution exists, and the ones I've seen are too slow for realtime anyway. If I had to implement it for next week, I would probably decompose the mesh into convex parts using SWIFT++, use the hierarchy of convex hulls as a BV-tree, then use SOLID 3.0 on top of this to compute penetration depth between 2 hulls. Would work, for a very high price. Pierre _______________________________________________ ODE mailing list ODE at q12.org http://q12.org/mailman/listinfo/ode From ericc at xenopi.com Wed Jun 19 10:29:02 2002 From: ericc at xenopi.com (Eric Cha) Date: Wed Jun 19 10:29:02 2002 Subject: [ODE] Recommendations? In-Reply-To: <81E5F727841DD211A5FD0008C728DB7B06E94BD0@campusx1.tue.nl> Message-ID: <001601c217b6$c04306a0$6401a8c0@donald> Hi Everyone, I have been playing with ODE now for about a month, and while it is very impressive at what it does and what it is designed for, it's not quite what I am in need of. I was wondering if anyone could give me some direction here or at least some suggestions, since I've been searching for quite some time... I'm looking for a physics simulator which has the following features: 1) Does simple non-articulated rigid body simulation (collision detection/response) using the micro-collision (Mirtich et al.) method. 3) Handles triangle soups (incl. collision between two triangulated bodies). Collision with other primitives is helpful, but not really required... 3) Source Code freely available - I am trying to learn and stabilize my own simulator. As you can see, while ODE is very cool, it doesn't really address my needs (and wasn't meant to...) Can anyone point me in a good direction? (BTW, I've purchased the O'Reilly book "Physics for Game Developers" and while it was quite good for explaining the core theories of the microcollision method, it came up quite short on implementation, IMHO..) Thanks, Eric --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.370 / Virus Database: 205 - Release Date: 6/5/2002 From amoravanszky at dplanet.ch Wed Jun 19 11:08:02 2002 From: amoravanszky at dplanet.ch (Adam Moravanszky) Date: Wed Jun 19 11:08:02 2002 Subject: [ODE] Collision detection for arbitrary polytopes ? References: <81E5F727841DD211A5FD0008C728DB7B06E94BD0@campusx1.tue.nl> Message-ID: <003701c217bc$49462720$8911da50@powerhouse> Hi Gino, your post doesn't make sense to me. Surely in your example, you would have two contact points, each with its own (one horizontal, the other vertical) relatively well defined penetration depth. I think that is what the original poster was talking about. -- -- Adam Moravanszky http://n.ethz.ch/student/adammo/ From p.terdiman at wanadoo.fr Wed Jun 19 11:16:01 2002 From: p.terdiman at wanadoo.fr (Pierre Terdiman) Date: Wed Jun 19 11:16:01 2002 Subject: [ODE] Collision detection for arbitrary polytopes ? References: <81E5F727841DD211A5FD0008C728DB7B06E94BD0@campusx1.tue.nl> Message-ID: <007b01c217bc$fd539900$0e00000a@pierre> > The problem is that in general you cannot combine the different penetration > depth vectors to a single penetration depth vector for all subparts. Well, I wouldn't have done that. I would have recorded 2 (or more) contacts, and let the simulator deal with it. Unless I'm missing something, it looks like composite objects to me... Sure, it can stress the simulator a bit :) Pierre From stjaerna at mac.com Thu Jun 20 06:30:02 2002 From: stjaerna at mac.com (jon klein) Date: Thu Jun 20 06:30:02 2002 Subject: [ODE] alloc vs. malloc again Message-ID: <9E236B3C-8451-11D6-9E31-0003936A7C02@mac.com> I've seen that the issue of allocating memory on the stack has come up a few times on this list, and that a lot of people have had problems with crashes due to stack overflows. While these can generally be fixed by increasing the stack size, I think there's a strong argument to be made for giving the option of not using the stack for this temporary memory allocation. The main issue is that for applications with an arbitrary number of objects and contacts, it's impossible to come up with a stack size at compile time which will be guaranteed to be big enough. The specific problem that I'm having is that the OS X AppKit threading code (NSThread) does not allow the stack size to be changed for threads, meaning that I can't even fix the stack overflow in the normal way. This is clearly not ODE's fault, but the only fix for me is to modify the LCP solver to use malloc/free. Obviously allocating on the stack has a large speed advantage over malloc/free, but for people who are more concerned about stability and runtime scalability, I think that malloc/free would do the trick. Another solution, which would fix the speed issue, would be to have static pointers to buffers which grow when necessary and don't get freed at all until the program terminates. This would be even faster than allocating memory on the stack, but is considerably more work. Is there anybody else who would like to see either of these options available (via a #define statement)? Thanks, - jon klein From martin at metahuman.org Thu Jun 20 19:49:02 2002 From: martin at metahuman.org (Martin C. Martin) Date: Thu Jun 20 19:49:02 2002 Subject: [ODE] alloc vs. malloc again References: <9E236B3C-8451-11D6-9E31-0003936A7C02@mac.com> Message-ID: <3D1293F5.B3145D71@metahuman.org> jon klein wrote: > > Obviously allocating on the stack has a large speed advantage > over malloc/free, but for people who are more concerned about > stability and runtime scalability, I think that malloc/free > would do the trick. > > Another solution, which would fix the speed issue, would be to > have static pointers to buffers which grow when necessary and > don't get freed at all until the program terminates. This would > be even faster than allocating memory on the stack, but is > considerably more work. Actually, a good memory manager should do something like this for you, behind the scenes. > Is there anybody else who would like to see either of these > options available (via a #define statement)? I certainly would. - Martin From nathan at whatever.net Thu Jun 20 22:38:02 2002 From: nathan at whatever.net (Nate Waddoups) Date: Thu Jun 20 22:38:02 2002 Subject: [ODE] alloc vs. malloc again In-Reply-To: <3D1293F5.B3145D71@metahuman.org> Message-ID: > > Is there anybody else who would like to see either of these > > options available (via a #define statement)? > > I certainly would. As would I. It just occurred to me that heap-based allocation could probably be made to work as quickly as stack-based allocation (or close to it), if the memory manager treats the pool like a stack. In other words, have the assumption that allocations and frees will be invoked in stack order like push and pop operations. Anyone know of an existing memory manager that works that way? -- Nate Waddoups Redmond WA USA http://www.natew.com From amoravanszky at dplanet.ch Fri Jun 21 02:14:02 2002 From: amoravanszky at dplanet.ch (Adam Moravanszky) Date: Fri Jun 21 02:14:02 2002 Subject: [ODE] alloc vs. malloc again References: Message-ID: <001b01c21904$00f8bca0$e412da50@powerhouse> > memory manager treats the pool like a stack. In other words, have the > assumption that allocations and frees will be invoked in stack order like > push and pop operations. Anyone know of an existing memory manager that > works that way? > Hi, Such a manager is absolutely trivial to write: just an array of objects with a 'last' pointer, you can even use an STL vector -- no need to look for 3rd party code. I have been doing this for my contacts (and all other often allocated/freed objects) from day one. The advantage of this approach is that you can even reallocate the whole thing if you run out of space, so there is no fixed max # of objects -- the STL vector will just grow automatically. I always thought it is quite foolish to think that ODE contacts are so special that they require using some weird nonstandard and dangerous allocator. -- -- Adam Moravanszky From amoravanszky at dplanet.ch Fri Jun 21 02:14:24 2002 From: amoravanszky at dplanet.ch (Adam Moravanszky) Date: Fri Jun 21 02:14:24 2002 Subject: [ODE] alloc vs. malloc again References: Message-ID: <001c01c21904$02444f70$e412da50@powerhouse> > memory manager treats the pool like a stack. In other words, have the > assumption that allocations and frees will be invoked in stack order like > push and pop operations. Anyone know of an existing memory manager that > works that way? > Hi, Such a manager is absolutely trivial to write: just an array of objects with a 'last' pointer, you can even use an STL vector -- no need to look for 3rd party code. I have been doing this for my contacts (and all other often allocated/freed objects) from day one. The advantage of this approach is that you can even reallocate the whole thing if you run out of space, so there is no fixed max # of objects -- the STL vector will just grow automatically. I always thought it is quite foolish to think that ODE contacts are so special that they require using some weird nonstandard and dangerous allocator. -- -- Adam Moravanszky From amoravanszky at dplanet.ch Fri Jun 21 02:14:27 2002 From: amoravanszky at dplanet.ch (Adam Moravanszky) Date: Fri Jun 21 02:14:27 2002 Subject: [ODE] alloc vs. malloc again References: Message-ID: <001e01c21904$09b5d3f0$e412da50@powerhouse> > memory manager treats the pool like a stack. In other words, have the > assumption that allocations and frees will be invoked in stack order like > push and pop operations. Anyone know of an existing memory manager that > works that way? > Hi, Such a manager is absolutely trivial to write: just an array of objects with a 'last' pointer, you can even use an STL vector -- no need to look for 3rd party code. I have been doing this for my contacts (and all other often allocated/freed objects) from day one. The advantage of this approach is that you can even reallocate the whole thing if you run out of space, so there is no fixed max # of objects -- the STL vector will just grow automatically. I always thought it is quite foolish to think that ODE contacts are so special that they require using some weird nonstandard and dangerous allocator. -- -- Adam Moravanszky From amoravanszky at dplanet.ch Fri Jun 21 02:14:30 2002 From: amoravanszky at dplanet.ch (Adam Moravanszky) Date: Fri Jun 21 02:14:30 2002 Subject: [ODE] alloc vs. malloc again References: Message-ID: <001d01c21904$099a5cb0$e412da50@powerhouse> > memory manager treats the pool like a stack. In other words, have the > assumption that allocations and frees will be invoked in stack order like > push and pop operations. Anyone know of an existing memory manager that > works that way? > Hi, Such a manager is absolutely trivial to write: just an array of objects with a 'last' pointer, you can even use an STL vector -- no need to look for 3rd party code. I have been doing this for my contacts (and all other often allocated/freed objects) from day one. The advantage of this approach is that you can even reallocate the whole thing if you run out of space, so there is no fixed max # of objects -- the STL vector will just grow automatically. I always thought it is quite foolish to think that ODE contacts are so special that they require using some weird nonstandard and dangerous allocator. -- -- Adam Moravanszky From amoravanszky at dplanet.ch Fri Jun 21 02:16:02 2002 From: amoravanszky at dplanet.ch (Adam Moravanszky) Date: Fri Jun 21 02:16:02 2002 Subject: [ODE] Sorry! References: Message-ID: <004601c21904$5f888020$e412da50@powerhouse> Sorry about the multiple posts, the stupid mailer kept reporting an error but apparently sent the message anyway. -- -- Adam Moravanszky From coding at natew.com Fri Jun 21 10:00:02 2002 From: coding at natew.com (Nate W) Date: Fri Jun 21 10:00:02 2002 Subject: [ODE] alloc vs. malloc again In-Reply-To: <001e01c21904$09b5d3f0$e412da50@powerhouse> Message-ID: On Fri, 21 Jun 2002, Adam Moravanszky wrote: > > memory manager treats the pool like a stack. In other words, have the > > assumption that allocations and frees will be invoked in stack order like > > push and pop operations. > > Such a manager is absolutely trivial to write: just an array of objects with > a 'last' pointer, you can even use an STL vector -- no need to look for 3rd > party code. That's a good point. Given that all objects are the same size, the problem gets even easier... I hadn't thought of that. -- Nate Waddoups Redmond WA USA http://www.natew.com From nlin at nlin.net Sat Jun 22 12:49:01 2002 From: nlin at nlin.net (nlin@nlin.net) Date: Sat Jun 22 12:49:01 2002 Subject: [ODE] How to compile Triangle Collider? Message-ID: Hi, I've wrestled all day with MSVC trying to get the triangle collider to work, but am constantly confounded with those wonderful "Microsoft-specific extensions to the C and C++ languages", namely, compiler warning C4273 dealing with dllexport linkage specifications. After reading through the MSDN docs about these "Microsoft-specific extensions to the C and C++ languages" (to use MSDN's terminology) I'm still none the wiser and I can't get Opcode 1.0, the triangle collider, and ODE to work together. The README for the triangle collider is a bit terse - where do I compile the CPP files? As part of the ODE static library? As part of the ODE DLL? As part of my project? None of the above worked for me; I always got bizarre linkage errors regarding DLL export conventions. I tried adding entries for the triangle collider cpp files to the ODE static library makefile, the ODE DLL makefile, and to a totally statically linked MSVC project workspace, but none worked. Can anyone point me to a simple set of instructions to get this to work, or provide me with a compilable example? Also, does the triangle collider + opcode work under Linux? I started a port attempt of opcode but again ran up against too many "Microsoft-specific extensions to the C and C++ languages", so I was wondering if anyone else had studied this issue in more detail. Thanks, -Norman From nlin at nlin.net Sun Jun 23 14:55:02 2002 From: nlin at nlin.net (nlin@nlin.net) Date: Sun Jun 23 14:55:02 2002 Subject: [ODE] More tri-collider questions Message-ID: 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. Now that it's compiling, there's the small problem of getting it to run :-) My problem is that no contacts seem to be generated for my simple test of colliding a sphere with a 2-triangle terrain. My test program is a modified test_boxstack where I drop spheres at 0,0,0 onto a test triangle mesh consisting of points created with the following code: trilist = dCreateTriList(space, NULL,NULL); dcVector3 vertices[10]; int vertexcount; int indices[10]; int indexcount; vertexcount=0; vertices[vertexcount].x = 0.0; vertices[vertexcount].y = 0.0; vertices[vertexcount].z = 0.0; vertexcount++; vertices[vertexcount].x = 1.0; vertices[vertexcount].y = 0.0; vertices[vertexcount].z = 1.0; vertexcount++; vertices[vertexcount].x = 0.0; vertices[vertexcount].y = 1.0; vertices[vertexcount].z = 1.0; vertexcount++; vertices[vertexcount].x = 1.0; vertices[vertexcount].y = 1.0; vertices[vertexcount].z = 0.0; vertexcount++; indexcount=0; indices[indexcount++] = 0; indices[indexcount++] = 1; indices[indexcount++] = 2; indices[indexcount++] = 3; indices[indexcount++] = 2; indices[indexcount++] = 1; dGeomTriListBuild(trilist, vertices, vertexcount, indices, indexcount); Then when I run my program, the spheres do collide with the mesh, but no contacts are getting generated. I put a debug message in dcTriListCollider::CollideSphere to print out the "TriangleIDCount" variable right after it is computed. It is always zero. Any idea what I am doing wrong? I really would like to get this working! Thanks, -Norman From erwin at vo.com Sun Jun 23 16:55:02 2002 From: erwin at vo.com (Erwin de Vries) Date: Sun Jun 23 16:55:02 2002 Subject: [ODE] More tri-collider questions References: Message-ID: <001001c21b11$3573a300$0101a8c0@athlon> > Then when I run my program, the spheres do collide with the mesh, > but no contacts are getting generated. I put a debug message in > dcTriListCollider::CollideSphere to print out the "TriangleIDCount" > variable right after it is computed. It is always zero. > > Any idea what I am doing wrong? I really would like to get this working! Have you perhaps moved the tri-list geom? The matrix of the trianglelist should be an identity one. I did this for speed purposes. The best implementation would have both versions, and determine at runtime which to use by doing a simple matrix identity check. (Or rather a position and quaternion check since it is quicker) Erwin From ericc at xenopi.com Sun Jun 23 22:28:02 2002 From: ericc at xenopi.com (Eric Cha) Date: Sun Jun 23 22:28:02 2002 Subject: [ODE] More tri-collider questions In-Reply-To: Message-ID: <000601c21b3f$edb6b960$6401a8c0@donald> Ummm, I ran into the same difficulties (w/regards to compiling) -> perhaps it would be helpful to post the steps necessary to get tri-collider and Opcode to compile to a static library? I know *I* would appreciate it... =) Eric > -----Original Message----- > From: ode-admin at q12.org [mailto:ode-admin at q12.org] On Behalf > Of nlin at nlin.net > Sent: Sunday, June 23, 2002 4:54 PM > To: ode at q12.org > Subject: [ODE] More tri-collider questions > > > 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. > > Now that it's compiling, there's the small problem of getting > it to run :-) > > My problem is that no contacts seem to be generated for my > simple test of colliding a sphere with a 2-triangle terrain. > My test program is a modified test_boxstack where I drop > spheres at 0,0,0 onto a test triangle mesh consisting of > points created with the following code: > > trilist = dCreateTriList(space, NULL,NULL); > > dcVector3 vertices[10]; > int vertexcount; > int indices[10]; > int indexcount; > > vertexcount=0; > vertices[vertexcount].x = 0.0; > vertices[vertexcount].y = 0.0; > vertices[vertexcount].z = 0.0; > vertexcount++; > vertices[vertexcount].x = 1.0; > vertices[vertexcount].y = 0.0; > vertices[vertexcount].z = 1.0; > vertexcount++; > vertices[vertexcount].x = 0.0; > vertices[vertexcount].y = 1.0; > vertices[vertexcount].z = 1.0; > vertexcount++; > vertices[vertexcount].x = 1.0; > vertices[vertexcount].y = 1.0; > vertices[vertexcount].z = 0.0; > vertexcount++; > > indexcount=0; > indices[indexcount++] = 0; > indices[indexcount++] = 1; > indices[indexcount++] = 2; > indices[indexcount++] = 3; > indices[indexcount++] = 2; > indices[indexcount++] = 1; > dGeomTriListBuild(trilist, vertices, vertexcount, indices, > indexcount); > > Then when I run my program, the spheres do collide with the > mesh, but no contacts are getting generated. I put a debug > message in dcTriListCollider::CollideSphere to print out the > "TriangleIDCount" variable right after it is computed. It is > always zero. > > Any idea what I am doing wrong? I really would like to get > this working! > > Thanks, > -Norman > _______________________________________________ > ODE mailing list > ODE at 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.372 / Virus Database: 207 - Release Date: 6/20/2002 > > --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.372 / Virus Database: 207 - Release Date: 6/20/2002 From nlin at nlin.net Mon Jun 24 02:54:02 2002 From: nlin at nlin.net (nlin@nlin.net) Date: Mon Jun 24 02:54:02 2002 Subject: [ODE] More tri-collider questions Message-ID: Erwin de Vries wrote: > Have you perhaps moved the tri-list geom? The matrix of the trianglelist > should be an identity one. Nope, I didn't move the tri-list geom. To make sure I explicitly set its position with dGeomSetPosition and dGeomSetRotation and checked it with dGeomGetPosition and dGeomSetRotation. Position is 0,0,0, rotation is identity. The tri-list creation code is exactly as shown in my previous e-mail. Help? -Norman From nlin at nlin.net Mon Jun 24 05:04:01 2002 From: nlin at nlin.net (nlin@nlin.net) Date: Mon Jun 24 05:04:01 2002 Subject: [ODE] collision detection/response without using ODE's collision engine In-Reply-To: <200206141901.g5EJ13202282@hook.org> Message-ID: SkeedaddIer at aol.com wrote: > Ken - I tried to setting depth to (sphere.z-sphere.radius) since it would > equal the penetration depth of the sphere against the plane at 0.0f. The > spheres still pass right thru the plane, no bouncy collision response. > > Figured it would help if you or anyone could look over the code and > figure out why i'm not getting the right results, so I posted it at: > > www.qlink.org/test_boxstack.txt > > Hope someone can fix this, i'm at wits end trying to figure out the > basics so I can build on from there. Thanks in advance! I got your code to work. You should: 0) Copy your contact.geom.pos and contact.geom.normal arrays element-by-element and not attempt to assign non-lvalues. My compiler (gcc) wouldn't even compile your assignments "contact.geom = contactposition". You might be using a non-standards-compliant C++ compiler such as the one from Redmond. 1) Change gravity to be 0,0,-0.0005. With your current -9.81 value the spheres are falling too quickly and this can conceivably cause problems when resolving penetrations (since if the sphere moves more than its diameter in one timestep, the formula used in the code won't work for computing the penetration) 2) Attach the joint NOT between the body and the ground plane, but instead between the body and NULL. This is because the ground plane is immovable with infinite mass. You create a ground plane body with dBodyCreate, but you never assign it any mass parameters. You want it to have infinite mass, so you don't need to create any body at all for the plane, just the Geom. Now, if only I could get that triangle-collider to work.... -Norman From erwin at vo.com Mon Jun 24 10:02:02 2002 From: erwin at vo.com (Erwin de Vries) Date: Mon Jun 24 10:02:02 2002 Subject: [ODE] How to compile Triangle Collider? Message-ID: <005a01c21ba0$c9c28140$0101a8c0@athlon> > > The current combination works just fine. Its what i use as well. Opcode1.1 > > might improve the accuracy for sphere collisions slightly, as i'm using an > > AABB Opcode test for the spheres right now. > > Uuh, that statement raises some serious concerns about accuracy for me. If > a sphere-mesh test is approximated with an AABB-test and this is only "slightly" > inaccurate, I wonder about the overall accuracy of the tri-collider for my > purposes. The tree query uses AABB's. Triangles that never touch the sphere wont contribute to the generated contact. > In my case, I need to do collisions with a spherical object and a mesh, where > the sphere and the mesh are assumed to be perfect representations of the > geometry. I am simulating a ball game where the ball will need to bounce > against and roll through tight geometry accurately (tubes, gutters, pathways, > corners, hills, holes). I need accuracy similar to what you would need for > a pool game. For a pool game the sphere collider is accurate enough. For a game you describe i would consider rewriting the sphere collision functions the way they did it in the flat four engine. It _might_ produce better results. But test it first of course. > Is the accuracy good enough for this, or am I better off using hundreds of ODE > primitives (boxes) to simulate my geometry? Should I upgrade to Opcode 1.1? > In your estimation is upgrading the tri-collider to Opcode 1.1 easy? I am already > behind schedule on my game (aren't we all) and want to spend as little time > as possible with porting code... I had planned on modeling my collision > geometry with hundreds of little boxes but it would be much easier for me > if I could directly use a low-poly mesh as my collision geometry - if it is > accurate enough. Upgrading to Opcode 1.1 would be fairly easy i think, but i've never looked into it, so i cant say for sure. Using boxes grouped together might work better for some geometry. It really depends on your geometry, and i havent done any real testing with any other data than our own car-racing games. I would say that for most types of geometry the spherecollider works. The boxcollider is a little more shady. > > The worst part about the algorithm is the clipping of the contacts. I > > couldnt think of a way of determining the penetration depth when a point is > > outside of the triangle. "Depth = 0.0f;" is what i do right now. You should > > try and see how good it works for you. > > What is wrong with this? If the point lies outside of the triangle then the > geometry does not collide with the triangle, merely with the infinte plane > containing the triangle. I think I am misunderstanding something here. Do > you mean that the generation of a contact point on the plane but outside of > the triangle might incorrectly inhibit the correct generation of another > valid contact point which IS in the triangle? In other words, is it correct > to say that the presence of contact points outside of the triangle is or > may be indicative of missing contact points within the triangle whose > influence is then ignored? Or am I totally off base here? Ehmm... Yes you are right. Moving a box towards a sharp edge will likely produce inaccurate physical behavior. Perhaps others can comment on how well it works for you? Erwin From russ at q12.org Mon Jun 24 10:50:02 2002 From: russ at q12.org (Russ Smith) Date: Mon Jun 24 10:50:02 2002 Subject: [ODE] ODE's license Message-ID: <000001c21ba7$9cd701e0$6701a8c0@rsmith2kdt2> hi all, i've recently had a number of enquiries about ODE's LGPL license and whether it is a problem to use ODE in a commercial product. in general it's no problem - the only minor issue is the LGPL "relinking" clause that asks that ODE be linked in as an external shared library (i.e. a DLL). however, there's a lot of fear, uncertainty and doubt about the LGPL, so i have decided to provide a dual licence: LGPL or BSD. what this will mean is that you may accept ODE under *either* the existing LGPL license, *or* the slightly less restrictive BSD license shown below. commercial users will have no problems with the BSD license. this change will probably happen in a few days. the (very few) people who have contributed code to the ODE core may chose to object to this, as they may have expected that their code would be licensed under LGPL, not BSD (note that ODE's "contrib" directory is separately licensed). i'll deal with any objections by simply taking the relevant feature out and reimplementing it at a later stage ... but i am not expecting anyone to object to this. comments? also: various people have contributed code to ODE that i've been sitting on for a while. i'll get around to this eventually, but i've had very little time for ODE recently. one thing i'll consider is hosting ODE on sourceforge and allowing any interested parties to be administrators of the project (and thus you can add your own code - but you have to test and document it yourselves as well :-) ). comments? ------ ODE's BSD LICENSE --- Copyright (c) 2001,2002, Russell Smith. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. Neither the names of ODE's copyright owner nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. -- Russ Smith http://www.q12.org From coding at natew.com Mon Jun 24 11:25:02 2002 From: coding at natew.com (Nate W) Date: Mon Jun 24 11:25:02 2002 Subject: [ODE] ODE's license In-Reply-To: <000001c21ba7$9cd701e0$6701a8c0@rsmith2kdt2> Message-ID: On Mon, 24 Jun 2002, Russ Smith wrote: > this change will probably happen in a few days. the (very few) people > who have contributed code to the ODE core may chose to object to this, > [....] but i am not expecting anyone to object to this. comments? No objection here. And, to save trouble in the future: Any code I have contributed to you for inclusion in ODE (and any code I contribute in the future) may be considered a donation. All rights associated with such code are assigned to you. -- Nate Waddoups Redmond WA USA http://www.natew.com From nlin at nlin.net Mon Jun 24 11:50:02 2002 From: nlin at nlin.net (nlin@nlin.net) Date: Mon Jun 24 11:50:02 2002 Subject: [ODE] ODE's license Message-ID: > this change will probably happen in a few days. the (very few) people > who have contributed code to the ODE core may chose to object to this, > as they may have expected that their code would be licensed under LGPL, No objection from me - somewhat ironically, my MSVC DLL changes were made in order to enable easier compliance the LGPL, but I can understand how users in commercial situations might have contractual difficulties with their clients and the LGPL. > > also: various people have contributed code to ODE that i've been sitting > on for a while. i'll get around to this eventually, but i've had very > little time for ODE recently. one thing i'll consider is hosting ODE > on sourceforge and allowing any interested parties to be administrators > of the project (and thus you can add your own code - but you have to > test and document it yourselves as well :-) ). Personally I kind of like the current situation where I can be fairly certain that the person who probably knows the code best (Russ) will manually integrate changes rather than having a wild-west free-for-all with the source code. However if someone has contributed a bleeding edge feature that you desperately need, I can also understand that the slow release schedule might be hampering. My suggestion would be the addition of an "incoming" directory where not-yet-integrated patches are simply dumped but can still be checked out vis CVS. Those absolutely needing bleeding-edge functionality can hack this into their own code; when Russ gets around to integrating it, it will be deleted from "incoming" and become part of the official release. This of course requires that Russ have enough time to eventually integrate the patches, but as I said, I would feel most comfortable with that solution. If a "free-for-all" CVS code repository is opened up, then I strongly suggest that as a first step Russ publish a detailed reference list to the particular research papers (Anitescu, Stewart, Potra, etc) used as a theoretical basis for ODE, plus document any changes to or specializations of these techniques. For instance, there appears to be a lot of speculation and possibly misunderstanding about the details of the time-stepping integration scheme used in ODE, and I would be wary of any changes to this part of the code without first being able to refer to a detailed theoretical explanation of how it is supposed to work. Another random suggestion, would it be possible to set up an ODE Wiki on q12.org? This way users and programmers could contribute documentation easily. Hopefully this will expand into a self-sustaining and organized body of knowledge about ODE (in particular, ODE internals). My 0.02, -Norman From anselm at hook.org Mon Jun 24 11:58:02 2002 From: anselm at hook.org (Anselm Hook) Date: Mon Jun 24 11:58:02 2002 Subject: [ODE] ODE's license In-Reply-To: Message-ID: > Another random suggestion, would it be possible to set up an ODE Wiki > on q12.org? This way users and programmers could contribute documentation > easily. Hopefully this will expand into a self-sustaining and organized > body of knowledge about ODE (in particular, ODE internals). http://q12.org/cgi-bin/wiki.pl?ODE_Wiki_Area From erwin at vo.com Mon Jun 24 12:12:02 2002 From: erwin at vo.com (Erwin de Vries) Date: Mon Jun 24 12:12:02 2002 Subject: [ODE] Tricollider sample References: Message-ID: <008601c21bae$551e8c40$0101a8c0@athlon> > > Ehmm... Yes you are right. Moving a box towards a sharp edge will likely > > produce inaccurate physical behavior. Perhaps others can comment on how well > > it works for you? > > As soon as I get it working (still scratching my head about no contacts > being generated) and as soon as I have some time, I'll try to make a test > program where I can drag around a box on top of a tri-mesh and draw a little > dot at each contact point. Then I can drag the box towards the edge of the > mesh and watch exactly what contacts get generated or not. This is probably > months off before I get to doing this though :-( (gotta get the GAME finished....) If you do it you can use the attached stuff as a base. :-) Russ, could you put this in the CVS? Some very small things (that were not breaking for me) have been changed in the spherecollision code... Erwin -------------- next part -------------- A non-text attachment was scrubbed... Name: dcTriList.zip Type: application/x-zip-compressed Size: 20394 bytes Desc: not available Url : http://q12.org/pipermail/ode/attachments/20020624/f40820a9/dcTriList.bin From martin at metahuman.org Mon Jun 24 12:30:03 2002 From: martin at metahuman.org (Martin C. Martin) Date: Mon Jun 24 12:30:03 2002 Subject: [ODE] ODE's license References: Message-ID: <3D1772FE.B2B1860F@metahuman.org> Same here, no objections, an everything I've done should be considered a donation. All rights are assigned to Russ. From nlin at nlin.net Mon Jun 24 12:33:01 2002 From: nlin at nlin.net (nlin@nlin.net) Date: Mon Jun 24 12:33:01 2002 Subject: [ODE] ODE Wiki In-Reply-To: Message-ID: > > Another random suggestion, would it be possible to set up an ODE Wiki > > on q12.org? This way users and programmers could contribute documentation > > easily. Hopefully this will expand into a self-sustaining and organized > > body of knowledge about ODE (in particular, ODE internals). > > http://q12.org/cgi-bin/wiki.pl?ODE_Wiki_Area Great. I've started to put up a basic structure, everyone else feel free to jump in (in marked contrast to source code and CVS, a Wiki is a great place for a "wild-west free-for-all"). We could also use the Wiki for organizing bleeding edge code patches or code suggestions. -Norman From martin at metahuman.org Mon Jun 24 12:34:02 2002 From: martin at metahuman.org (Martin C. Martin) Date: Mon Jun 24 12:34:02 2002 Subject: [ODE] ODE's license References: <000001c21ba7$9cd701e0$6701a8c0@rsmith2kdt2> Message-ID: <3D1773F9.64966234@metahuman.org> Almost forgot: Russ, if you're going to be just as busy in the future as you have been in the last few months, I'd vote for a sourceforge deal. Not a "free for all," but instead allow a small group of administrators, people who have demonstrated some competency by, say, contributing code that stays within your coding standards. The idea would be to have a small group of "surrogate Russ's" who are empowered to add their and other people's changes. Just a thought, Martin Russ Smith wrote: > > also: various people have contributed code to ODE that i've been sitting > on for a while. i'll get around to this eventually, but i've had very > little time for ODE recently. one thing i'll consider is hosting ODE > on sourceforge and allowing any interested parties to be administrators > of the project (and thus you can add your own code - but you have to > test and document it yourselves as well :-) ). > > comments? From russ at q12.org Mon Jun 24 14:18:02 2002 From: russ at q12.org (Russ Smith) Date: Mon Jun 24 14:18:02 2002 Subject: [ODE] Tricollider sample In-Reply-To: <008601c21bae$551e8c40$0101a8c0@athlon> Message-ID: <000001c21bc4$b81c0820$6701a8c0@rsmith2kdt2> > Russ, could you put this in the CVS? done -- Russ Smith http://www.q12.org From nlin at nlin.net Tue Jun 25 05:42:01 2002 From: nlin at nlin.net (nlin@nlin.net) Date: Tue Jun 25 05:42:01 2002 Subject: [ODE] Tri-collider page on wiki In-Reply-To: <020d01c21bc3$35fa1630$0101a8c0@athlon> Message-ID: I've put up a brief wiki page explaining how I got the tri-collider to compile and link, along with the problems I had (float/double issues). Feel free to correct/expand on this. http://q12.org/cgi-bin/wiki.pl?TriangleCollider -Norman From bovet at ifi.unizh.ch Wed Jun 26 06:01:01 2002 From: bovet at ifi.unizh.ch (Simon Bovet) Date: Wed Jun 26 06:01:01 2002 Subject: [ODE] Spring joints Message-ID: <003b01c21d11$7d725690$b6633c82@kyndias> Hi, I want to use spring joints with different spring/damping constants. The simplest way is probably to use ball joints, but then, who can I change the ERP and CFM values for each joint individually? Thanks for your help! Simon From dmcclurg at pandemicstudios.com.au Wed Jun 26 16:47:01 2002 From: dmcclurg at pandemicstudios.com.au (David McClurg) Date: Wed Jun 26 16:47:01 2002 Subject: [ODE] Tri-collider page on wiki Message-ID: Thanks Norman. This is very helpful. Under "Limitations of the Triangle Collider" I see-- # Current tri-collider code might not yet support moving tri-meshes (the transformation matrix for the tri-mesh must be identity, see mailing list) # Once moving tri-meshes are supported, you still need external library to compute arbitrary inertia tensor for moveable tri-meshes >>> I searched the mailing list archive and didn't find anything about this. <<< What I'm interested in is a tri-list that responds to dGeomSetPosition() and dGeomSetRotation(). My tri-list geom is linked to a scene graph and I'd like to follow the scene graph node as it moves/rotates. I don't need inertia or a body yet. Just teleporting through space would be fine. Moving platforms you can jump between in a game is an example where you don't need inertia badly. Of course, I can do this myself by transforming the vertex list but I was surprised to find that tri-list geoms didn't respond to dGeomSetPosition(). This approach also requires two vertex lists so errors don't build up!! -----Original Message----- From: nlin at nlin.net [mailto:nlin at nlin.net] Sent: Wednesday, 26 June 2002 12:40 AM To: Erwin de Vries Cc: ode at q12.org Subject: [ODE] Tri-collider page on wiki I've put up a brief wiki page explaining how I got the tri-collider to compile and link, along with the problems I had (float/double issues). Feel free to correct/expand on this. http://q12.org/cgi-bin/wiki.pl?TriangleCollider -Norman From Tony.Peguero at xtra.co.nz Wed Jun 26 19:21:02 2002 From: Tony.Peguero at xtra.co.nz (Tony Peguero) Date: Wed Jun 26 19:21:02 2002 Subject: [ODE] Tri-collider page on wiki In-Reply-To: Message-ID: Yeah, I'm hanging out for movable trilists as well. Calculating the inertia tensor separately doesn't scare me too much :) -----Original Message----- From: ode-admin at q12.org [mailto:ode-admin at q12.org]On Behalf Of David McClurg Sent: Thursday, 27 June 2002 11:48 a.m. To: ode at q12.org Subject: RE: [ODE] Tri-collider page on wiki Thanks Norman. This is very helpful. Under "Limitations of the Triangle Collider" I see-- # Current tri-collider code might not yet support moving tri-meshes (the transformation matrix for the tri-mesh must be identity, see mailing list) # Once moving tri-meshes are supported, you still need external library to compute arbitrary inertia tensor for moveable tri-meshes >>> I searched the mailing list archive and didn't find anything about this. <<< What I'm interested in is a tri-list that responds to dGeomSetPosition() and dGeomSetRotation(). My tri-list geom is linked to a scene graph and I'd like to follow the scene graph node as it moves/rotates. I don't need inertia or a body yet. Just teleporting through space would be fine. Moving platforms you can jump between in a game is an example where you don't need inertia badly. Of course, I can do this myself by transforming the vertex list but I was surprised to find that tri-list geoms didn't respond to dGeomSetPosition(). This approach also requires two vertex lists so errors don't build up!! -----Original Message----- From: nlin at nlin.net [mailto:nlin at nlin.net] Sent: Wednesday, 26 June 2002 12:40 AM To: Erwin de Vries Cc: ode at q12.org Subject: [ODE] Tri-collider page on wiki I've put up a brief wiki page explaining how I got the tri-collider to compile and link, along with the problems I had (float/double issues). Feel free to correct/expand on this. http://q12.org/cgi-bin/wiki.pl?TriangleCollider -Norman _______________________________________________ ODE mailing list ODE at q12.org http://q12.org/mailman/listinfo/ode From nlin at nlin.net Thu Jun 27 05:46:01 2002 From: nlin at nlin.net (nlin@nlin.net) Date: Thu Jun 27 05:46:01 2002 Subject: [ODE] tri-collider + DLL Message-ID: To use tri-collider with the msvc-dll configuration, you have to add a few new exports to the config/msvcdefs.def file, because the tri-collider uses functions not exported in the current msvcdefs.def. You need to add: dGeomGetClassData dSpaceAdd dCreateGeom dCreateGeomClass dInfiniteAABB ?_freeAll at dArrayBase@@IAEXH at Z ?dCollideBP@@YAHPBUdxGeom@@0HPAUdContactGeom@@H at Z ?_setSize at dArrayBase@@IAEXHH at Z The last three entries are rather troubling, since they are C++ mangled names (MSVC calls these "decorated" names). I have no idea about how MSVC generates these names, if they change according to build settings, or if they change from version to version of MSVC: You could probably also use __dllexport and __dllimport in the ODE code itself to take care of that, but then you need to #ifdef such declarations so that the code still compiles on other, standards-conforming C++ compilers. It's probably possible to make a DLL without the .DEF exports list, but I don't have the time to investigate it right now. Also I've updated the tri-collider wiki page with some new notes. If you see anything which needs improving, jump right in and do it. -Norman From p.terdiman at wanadoo.fr Thu Jun 27 06:11:02 2002 From: p.terdiman at wanadoo.fr (Pierre Terdiman) Date: Thu Jun 27 06:11:02 2002 Subject: [ODE] tri-collider + DLL References: Message-ID: <004d01c21ddc$617feee0$7401a8c0@nwpc1> Most of the time I just use something like this: #define EXPORTED_FUNCTION extern "C" __declspec(dllexport) Then in the cpp, for ex in a MAX plug : EXPORTED_FUNCTION int LibNumberClasses() { // Returns the number of plug-ins in this DLL. return 3; } This is enough to export a function correctly. No need for DEF files. The "extern "C"" part makes sure exported names are not decorated. Only drawback is it's limited to C-functions, so you can't export polymorphic functions this way. Ex, this failes: EXPORTED_FUNCTION void DoSomeStuff ( int data ) {} EXPORTED_FUNCTION void DoSomeStuff ( float data ) {} For classes, you only need the "__declspec(dllexport)" part (exported names are ok). Pierre ----- Original Message ----- From: To: Sent: Thursday 27 June 2002 16:43 Subject: [ODE] tri-collider + DLL > To use tri-collider with the msvc-dll configuration, you have to add > a few new exports to the config/msvcdefs.def file, because the tri-collider > uses functions not exported in the current msvcdefs.def. You need to > add: > > dGeomGetClassData > dSpaceAdd > dCreateGeom > dCreateGeomClass > dInfiniteAABB > ?_freeAll at dArrayBase@@IAEXH at Z > ?dCollideBP@@YAHPBUdxGeom@@0HPAUdContactGeom@@H at Z > ?_setSize at dArrayBase@@IAEXHH at Z > > The last three entries are rather troubling, since they are C++ mangled > names (MSVC calls these "decorated" names). I have no idea about how > MSVC generates these names, if they change according to build settings, > or if they change from version to version of MSVC: You could probably > also use __dllexport and __dllimport in the ODE code itself to > take care of that, but then you need to #ifdef such declarations > so that the code still compiles on other, standards-conforming C++ > compilers. It's probably possible to make a DLL without the .DEF exports > list, but I don't have the time to investigate it right now. > > Also I've updated the tri-collider wiki page with some new notes. > If you see anything which needs improving, jump right in and do it. > > -Norman > _______________________________________________ > ODE mailing list > ODE at q12.org > http://q12.org/mailman/listinfo/ode From coding at natew.com Thu Jun 27 09:38:02 2002 From: coding at natew.com (Nate W) Date: Thu Jun 27 09:38:02 2002 Subject: [ODE] tri-collider + DLL In-Reply-To: Message-ID: On Thu, 27 Jun 2002 nlin at nlin.net wrote: > The last three entries are rather troubling, since they are C++ mangled > names (MSVC calls these "decorated" names). I have no idea about how > MSVC generates these names, if they change according to build settings, > or if they change from version to version of MSVC [...] I *think* the names will remain stable for the forseeable future, as any change would probably break DLL interactions in god-knows-how-many applications and DLLs. Also, there is an API, UnDecorateSymbolName, which turns mangled names into human-readable names (provided the human in question speaks C++), and it's been around since Win95. I was able to build and use tri-collider without those functions, though. It's been so long since I built it that I'm not sure how I did it, though. That wiki site is a great idea. -- Nate Waddoups Redmond WA USA http://www.natew.com From ericc at xenopi.com Thu Jun 27 10:49:02 2002 From: ericc at xenopi.com (Eric Cha) Date: Thu Jun 27 10:49:02 2002 Subject: [ODE] Tri-collider page on wiki In-Reply-To: Message-ID: <004701c21e02$e1c72d90$6401a8c0@donald> I recently wrote up a routine to calculate the inertia tensor for an arbitrary tri-mesh. I haven't tried to integrate it with ODE/Tri-collider, but I would be happy to generalize the code a little bit and donate it to ODE... Eric > -----Original Message----- > From: ode-admin at q12.org [mailto:ode-admin at q12.org] On Behalf > Of Tony Peguero > Sent: Wednesday, June 26, 2002 7:17 PM > To: ode at q12.org > Subject: RE: [ODE] Tri-collider page on wiki > > > Yeah, I'm hanging out for movable trilists as well. > Calculating the inertia tensor separately doesn't scare me too much :) > > > -----Original Message----- > From: ode-admin at q12.org [mailto:ode-admin at q12.org]On Behalf > Of David McClurg > Sent: Thursday, 27 June 2002 11:48 a.m. > To: ode at q12.org > Subject: RE: [ODE] Tri-collider page on wiki > > > Thanks Norman. This is very helpful. > > Under "Limitations of the Triangle Collider" I see-- > # Current tri-collider code might not yet support moving > tri-meshes (the transformation matrix for the tri-mesh must > be identity, see mailing list) # Once moving tri-meshes are > supported, you still need external library to compute > arbitrary inertia tensor for moveable tri-meshes > > >>> I searched the mailing list archive and didn't find > anything about > >>> this. > <<< > > What I'm interested in is a tri-list that responds to > dGeomSetPosition() and dGeomSetRotation(). My tri-list geom > is linked to a scene graph and I'd like to follow the scene > graph node as it moves/rotates. > > I don't need inertia or a body yet. Just teleporting through > space would be fine. Moving platforms you can jump between > in a game is an example where you don't need inertia badly. > > Of course, I can do this myself by transforming the vertex > list but I was surprised to find that tri-list geoms didn't > respond to dGeomSetPosition(). This approach also requires > two vertex lists so errors don't build up!! > > -----Original Message----- > From: nlin at nlin.net [mailto:nlin at nlin.net] > Sent: Wednesday, 26 June 2002 12:40 AM > To: Erwin de Vries > Cc: ode at q12.org > Subject: [ODE] Tri-collider page on wiki > > > I've put up a brief wiki page explaining how I got the > tri-collider to compile and link, along with the problems I > had (float/double issues). Feel free to correct/expand on this. > http://q12.org/cgi-bin/wiki.pl?TriangleCollider -Norman _______________________________________________ ODE mailing list ODE at q12.org http://q12.org/mailman/listinfo/ode _______________________________________________ ODE mailing list ODE at 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.372 / Virus Database: 207 - Release Date: 6/20/2002 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.372 / Virus Database: 207 - Release Date: 6/20/2002 From p.terdiman at wanadoo.fr Thu Jun 27 12:34:01 2002 From: p.terdiman at wanadoo.fr (Pierre Terdiman) Date: Thu Jun 27 12:34:01 2002 Subject: [ODE] Tri-collider page on wiki References: <004701c21e02$e1c72d90$6401a8c0@donald> Message-ID: <00d201c21e11$42652f40$0e00000a@pierre> > I recently wrote up a routine to calculate the inertia tensor for an > arbitrary tri-mesh. I haven't tried to integrate it with > ODE/Tri-collider, but I would be happy to generalize the code a little > bit and donate it to ODE... Hmmm, why not simply use the good old one from Brian Mirtich ? From ngbinh at glassegg.com Thu Jun 27 19:44:02 2002 From: ngbinh at glassegg.com (Nguyen Binh) Date: Thu Jun 27 19:44:02 2002 Subject: [ODE] Tri-collider page on wiki In-Reply-To: <00d201c21e11$42652f40$0e00000a@pierre> References: <004701c21e02$e1c72d90$6401a8c0@donald> <00d201c21e11$42652f40$0e00000a@pierre> Message-ID: <99836272.20020628094626@glassegg.com> Yes! It's at www.acm.org/jgt -- 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 falagard at hotmail.com Sun Jun 30 22:47:01 2002 From: falagard at hotmail.com (Clay Larabie) Date: Sun Jun 30 22:47:01 2002 Subject: [ODE] First Impressions Message-ID: My name is Clay Larabie, aka Falagard. Going to be playing around with ODE, trying to integrate it with a middleware 3d game engine called Auran Jet. I'm using Visual C++ and have had mixed results trying to compile ODE. I wasn't able to get 'make' to work, so I created added all the source files to a project from Visual C++ and got it to compile, was able to play with the examples, etc. I wasn't able to compile the trilist collider code with 0.03, so I downloaded the latest CVS code and dropped that in with my 0.03 files, even though it may be only working with 0.035. After some tweaking, I got the trilist collider to compile. When I ran the trilist test example though, the trilist collision detection is not working. Spheres and boxes are passing right through the trilist object. I'm not able to get 0.035 to compile at all. Got some errors I haven't yet been able to figure out. g:\downloads\ode\ode\src\geom.cpp(1289) : error C2501: 'SHAREDLIBEXPORT' : missing storage-class or type specifiers Does anyone have this working in Visual C++? Thanks for any help Clay Larabie _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com