[ODE] Moving trimesh trouble

[Shamyl Zakariya]

I tried a more literal than interpretive porting of the  
test_moving_trimesh code using a double-buffered transform and  
sending the previous transform *after* dWorldStep but it's still  
acting wonky, in the same manner, in fact.

So now, for each body with a trimesh collider, this method is called  
after dWorldStep()

void TrimeshGeom::transformDidChange( void )
{
     vec3 p = dGeomGetPosition( _geom );
     mat4 R = dGeomGetRotation( _geom );

     _transforms[ _transformIndex ].setPositionAndRotation( p, R );
     _transformIndex = !_transformIndex;
	
     dGeomTriMeshSetLastTransform( _geom, _transforms 
[ _transformIndex ] );
}


The oddest part about it is that the trimesh -- at the origin with no  
transform -- still takes place in collision detection. So if I drop  
stuff on it ( sort of like the box stack demo ) stuff lands on the  
trimesh and acts correctly. Only, instead of being an active body,  
the trimesh just sits there at the origin.

Here's a screenshot, for clarification:
http://zakariya.net/shamyl/etc/ImmobileTrimesh.png

Yes, it's a high poly trimesh. I'm not really intending to use  
trimeshes of so many triangles, I just want to know that the  
functionality actually works, and that I'm using it correctly.

shamyl at zakariya.net
	In the same episode, the scientist suggests that the
	debigulation can only be reversed by a rebigulator.
		-- wikipedia


On Mar 6, 2007, at 8:37 AM, Shamyl Zakariya wrote:

> I've been experimenting with moving trimeshes, using
> test_moving_trimesh.cpp as a tutorial.
>
> First, I want to say that fairly certain my trimesh data is good,
> because when I don't have a body attached, ray/capsule/box/sphere ->
> trimesh collisions are working just fine. Thus I can infer that my
> trimesh data is good.
>
> Reading test_moving_trimesh, I see that there's only two things that
> are "special" about having a body attached to a trimesh. One:
> COnfigure the mass with dMassSetTrimesh. Two: Call
> dGeomTriMeshSetLastTransform() with the current trimesh transform
> before calling dWorldStep and the like.
>
> So here's some code snippets
>
>
>
> World::step():
>
> for ( EntityRefSet::iterator it( _bodiedEntities.begin() ), end
> ( _bodiedEntities.end() );
>        it != end; ++it )
> {
>      (*it)->aboutToUpdateBody();
> }
>
> /*
>      step ODE
> */
> if ( _world )
> {
>      dSpaceCollide2( (dGeomID) _staticSpace, (dGeomID) _actorSpace,
> this, &nearCallback );
>      dSpaceCollide2( (dGeomID) _groundSpace, (dGeomID) _actorSpace,
> this, &nearCallback );
>      dSpaceCollide( _actorSpace, this, &nearCallback);
>      dWorldStep( _world, simtime::interval() );
>      dJointGroupEmpty( _contactGroup );
> }
>
> The function Entity::aboutToUpdateBody() calls the following when
> bodies have trimesh geoms:
>
> void TrimeshGeom::transformWillChange( void )
> {
> 	dGeomTriMeshSetLastTransform( _geom, _lastTransform );
> 	_lastTransform.set_ode_transform( dGeomGetPosition( _geom ),
> 	                                  dGeomGetRotation( _geom ) );
> }
>
>
> I've put in printfs of my bodied trimeshs' position and rotation
> before dWorldStep and after, and what I see is interesting.
>
> On the very first step cycle, before dWorldStep, my trimesh prints
> the position and identity rotation I've assigned to it. After the
> world update, my trimesh is at (0,0,0) and has an identity rotation
> matrix but with R(4,4) at zero, instead of 1.
>
> Here's what's being printed before dWorldStep -- this is what I've
> manually assigned:
> Entity[Nubbles]::aboutToUpdateBody position: (0.00, 0.00, 50.00)
> rotation: ((1.00, 0.00, 0.00, 0.00), (0.00, 1.00, 0.00, 0.00), (0.00,
> 0.00, 1.00, 0.00), (0.00, 0.00, 0.00, 1.00))
>
> And here's what's printed after the first dWorldStep:
> Entity[Nubbles]::synchronizeToBody position: (0.00, 0.00, 0.00)
> rotation: ((1.00, 0.00, 0.00, 0.00), (0.00, 1.00, 0.00, 0.00), (0.00,
> 0.00, 1.00, 0.00), (0.00, 0.00, 0.00, 0.00))
>
> Notice that rotation( 4,4 ) is zero, instead of one. All subsequent
> output is like that.
>
> I've read over test_moving_trimesh over and over and I have to assume
> I'm missing some particular, but I can't figure out what it is.
>
> For reference, I'm using ODE 0.8 with trimesh=OPCODE. I tried using
> GIMPACT, but it kept crashing when I tried to upload my trimesh data.
>
>
> shamyl at zakariya.net
>    "this is, after all, one of those movies where people spend a great
>    deal of time looking at things and pointing."
>      From a review of _Fantastic Voyage_
>
>
>
> _______________________________________________
> ODE mailing list
> ODE at ode.org
> http://mooshika.org/mailman/listinfo/ode