[ODE] Unsubscribe

ashok ashok at globalsoft.co.in
Tue Jan 28 21:33:01 2003


i want to unsubscibe
thank you
ashokkumar

----- Original Message -----
From: <ode-request@q12.org>
To: <ode@q12.org>
Sent: Tuesday, January 28, 2003 11:01 AM
Subject: ODE digest, Vol 1 #445 - 3 msgs


> Send ODE mailing list submissions to
> ode@q12.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://q12.org/mailman/listinfo/ode
> or, via email, send a message with subject or body 'help' to
> ode-request@q12.org
>
> You can reach the person managing the list at
> ode-admin@q12.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of ODE digest..."
>
>
> Today's Topics:
>
>    1. Re: Terrain<->Box collision without tri-collider (Fabian Herb)
>    2. RE: Collision response etc (Byron Wright)
>    3. dxHashSpace::collide2 (Adam D. Moss)
>
> --__--__--
>
> Message: 1
> Date: Tue, 28 Jan 2003 19:16:14 +0100
> To: ode@q12.org
> From: Fabian Herb <commander@herb-clan.de>
> Subject: Re: [ODE] Terrain<->Box collision without tri-collider
>
> Hello,
>
> >I think in keeping with the spirit of ODE, we shouldn't use C++ (though
I'm
> >a big fan).  It might be an idea to have different heightfield types, eg,
> >dGeomHeightfield8,
> >dGeomHeightfield16 & dGeomHeightfieldF.
>
> I think we should use a single type that we use in our collider code,
> and that can be changed in the header file (using typedef).
>
> >
> >It's an option, but it would require people modifying ODE source code,
which
> >I think we should avoid.
>
> I mean we should only do typecasts in our code, so that we won't get
> any surprising results when we try to divide an integer (if the user
> chose that).
>
> >I actually do that with my terrain now, ie. I work off a large bitmap in
> >memory, but it's split into tiles that point at subrects.  Should
certainly
> >be in there as an option.
>
> Perhaps another useful option would be using only every second (or
> fourth?) heightfield value, so that people can have high-detail
> graphics and faster collision detections (with compromised accuracy
> of course).
>
> >  Ah, right.  Again, I guess we should make on-the-fly optional, and
allow
> >  for interleaved normals
> ...
> >Again, we could have an option for normal decompression (eg. creating z
from
> >x & y) for user-supplied normals.
>
> That's quite complicated, since everyone can have her/his own format
> of indexed normals and/or accessor functions.
>
> That's already a lot of options. We should do multiple interfaces (to
> the same code) for quick and full-featured setup of the geometry
> object.
>
> >Hopefully we can come up with something general that still works
optimally
> >for all of us... thanks for the code Fabian, I'll probably check it out
over
> >the weekend.
>
> No problem. Take your time.
> Fabian
>
> --__--__--
>
> Message: 2
> From: "Byron Wright" <bslayerw@mindspring.com>
> To: <ode@q12.org>
> Subject: RE: [ODE] Collision response etc
> Date: Tue, 28 Jan 2003 10:21:57 -0800
>
> *bump*.
>
> Anyone have any idea on how I might solve this?
>
> -Byron
>
> -----Original Message-----
> From: ode-admin@q12.org [mailto:ode-admin@q12.org] On Behalf Of Byron
> Wright
> Sent: Friday, January 24, 2003 5:30 PM
> To: ode@q12.org
> Subject: [ODE] Collision response etc
>
>
> New to ODE, trying to figure out how to play a sound effect when objects
> collide.
>
> Here are the steps I take to produce a "bump" sound effects.
>
> - do collision detection and response
> - world step
> - check all bodies for contact joints, if they have contact joints and
> their forces are greater than 0 then play a the bump sound effect
>
>
>
> The problem is that after a collision and the contact joints have been
> created the magnitude of the force is alway 0. When should I get be
> requisting the force from my bodies? Or should I be checking something
> else to find out if the body has been "bumped"?
>
> Here is my update function :
>
> void update(float dt) {
>     dSpaceCollide(space, 0, &NearCallback);
>     dWorldStep (world, dt);
>     //iterate though all boxes, if they have contact joints (collision)
>     //then play a sound effect if the box's force is greater than 0
>
>     //BodyCollection is = typedef vector<dBodyID> BodyCollection;
>     BodyCollection::iterator it = boxBodies.begin();
>
>     while(it != boxBodies.end()) {
>         int numJoints = dBodyGetNumJoints(*it);
>         if(numJoints > 0) {
>         for(int joints = 0; joints < numJoints; ++ joints) {
>             dJointID joint = dBodyGetJoint (*it, joints);
>                 if(dJointGetType(joint) == dJointTypeContact) {
>                 //it's a contact joint. check force of
> bodies
>                   const dReal * forceA = dBodyGetForce(*it);
>
>       cout << magnitude(forceA) << endl;
>                   if(magnitude(forceA) > 0.05 ) {
>       Mix_PlayChannel(-1,bump,0);
>                   }
>             }
>         }
>
>         }
>        ++it;
>     }
>
>     //remove all contact joints from the system
>     dJointGroupEmpty(contactGroup);
> }
>
> Byron Wright
>
> _______________________________________________
> ODE mailing list
> ODE@q12.org
> http://q12.org/mailman/listinfo/ode
>
>
> --__--__--
>
> Message: 3
> Date: Tue, 28 Jan 2003 18:43:31 +0000
> From: "Adam D. Moss" <adam@gimp.org>
> Reply-To: aspirin@ntlworld.com
> To: ode@q12.org
> Subject: [ODE] dxHashSpace::collide2
>
> This is a multi-part message in MIME format.
> --------------6AA5026233094F9AEC49DF81
> Content-Type: text/plain; charset=us-ascii
> Content-Transfer-Encoding: 7bit
>
> Hi!
>
> I implemented dxHashSpace::collide2() in the O(n^2) manner
> of dxSimpleSpace::collide2() since I was happier to have a
> relatively inefficient implementation than have no implementation
> at all (and an implicit abort()).
>
> The patch for this is attached.
>
> I know it'd be significantly nicer to have an implementation that
> really took advantage of the hash structure when collide2()ing
> geoms with a hash-space, to avoid the O(n1*n2).  I assume that's
> why Russ left the function stubbed-out.
>
> --Adam
> --
> Adam D. Moss   . ,,^^   adam@gimp.org   http://www.foxbox.org/   co:3
> --------------6AA5026233094F9AEC49DF81
> Content-Type: text/plain; charset=us-ascii;
>  name="ODE-COLLIDE2.diff"
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline;
>  filename="ODE-COLLIDE2.diff"
>
> Index: ode/src/collision_space.cpp
> ===================================================================
> RCS file: /cvsroot/opende/ode/ode/src/collision_space.cpp,v
> retrieving revision 1.4
> diff -u -u -r1.4 collision_space.cpp
> --- ode/src/collision_space.cpp 9 Dec 2002 01:12:02 -0000 1.4
> +++ ode/src/collision_space.cpp 28 Jan 2003 18:35:47 -0000
> @@ -620,8 +620,21 @@
>  void dxHashSpace::collide2 (void *data, dxGeom *geom,
>       dNearCallback *callback)
>  {
> -  //@@@
> -  dDebug (0,"dxHashSpace::collide2() not yet implemented");
> +  dAASSERT (geom && callback);
> +
> +  // this could take advantage of the hash structure to avoid
> +  // O(n^2) complexity, but it does not yet.
> +
> +  lock_count++;
> +  cleanGeoms();
> +  geom->recomputeAABB();
> +
> +  // intersect bounding boxes
> +  for (dxGeom *g=first; g; g=g->next) {
> +    collideAABBs (g,geom,data,callback);
> +  }
> +
> +  lock_count--;
>  }
>
>
//**************************************************************************
**
>
> --------------6AA5026233094F9AEC49DF81--
>
>
>
> --__--__--
>
> _______________________________________________
> ODE mailing list
> ODE@q12.org
> http://q12.org/mailman/listinfo/ode
>
>
> End of ODE Digest
>
>