SIO2 Architecture and Bullet Physics integration

I'm beginning to study SIO2 and have made one pass through most of the tutorials. As you know, it's extremely cool. Now that I'm seeing and appreciating the potential power of the integration of OpenGL/ES, Bullet, importing from Blender, sound, video, etc, ... I'm sort of overwhelmed.

So, I'm picking a starting point for getting a better understanding and that is the Bullet integration and Bullet itself.

I'm starting with way more questions than answers so I'll just list them and then I'll contribute whatever I can as I learn more and hope that others will help as my questions move from general to more specific. I'm looking at using Tutorial 6-2 and Tutorial 9 (as others have suggested) as examples to study for this investigation.

Architectural questions:
1) What corresponds to the "Canonical Game Loop"?
- I think it is templatePhysicCullingThread (which calls sio2PhysicRender). This leads to question 2.

2) What are the primary threads and what API calls are safe on each thread, basically what is the thread for, and _not_ for?
- It seems DrawView calls templateLoading until that's done, then it calls templateRender, and then there is sio2ThreadRun

3) Which leads to questions like: If I want to do this or that where do I put the code? Things like if I want to move objects, change their physics properties etc. where does this kind of code go and what do you have to do to play nicely with the physics world? Like:
3a) Add a new object (or remove an object) to the world and kick start it.
3b) Change the location/position of an existing object without freaking out the culling or the physics properties/behavior of the object (I might want a magician to zap an object, but its velocity would stay the same after it finds itself in the new position).
3c) Simulate hitting an object (an outside force acts on the object that's not part of the physics model, or only temporarily part of the model, if that's the easiest way to accomplish this).

or slightly different but maybe not: what if I want to change an object in a more fundamental way, like change its shape, mass or scale it up or down? is it safe to do so and where would that code go?

Some example code snippets or classes that do this sort of thing would be wonderful, as new examples taking off from tutorial 6-2, 9, or whatever makes sense.

-George

Has anybody:

1) Used bullet constraints such as btHingeConstraint?
2) or the vehicle or character controller?

-George

I got the following code to work. It moves objects (translates or sets their velocity) when they are selected (as mods to tutorial06_2). My question is this: is it OK to make these bullet physics calls to btRigidBody from the templateRender thread?

Code:


// put these declarations at file/global scope
SIO2object *selection = NULL;
SIO2object *lastSelection = NULL;

// then inside of ...
void templateRender( void )
{

// just after the call to
// selection = sio2ResourceSelect3D( ... );
// add this code:

if (selection) {
   // see if selected object is the ground or not, we don't want to ask the earth to move!
   bool isGroundObject = strcmp(selection->name, "object/Plane") == 0;
   if (!isGroundObject) {
      // calculate vector from cam to the selected object
      vec3& camLoc = *(sio2->_SIO2camera->_SIO2transform->loc);
      vec3& selectionLoc = *(selection->_SIO2transform->loc);
      btVector3 towardsCam = (make_btVector3(camLoc) - make_btVector3(selectionLoc)).normalize();
      selection->_btRigidBody->setActivationState(ACTIVE_TAG); // get ready to change the object
      
      if (selection != lastSelection) { // a new object is selected
         // move it 10 meters towards the cam, unless already close enough
         if (selection->dst > 10.0f)
            selection->_btRigidBody->translate(towardsCam*10.0); // inch it closer
      }
      else { // same object is selected
         // figure out how fast to move
         float dist = selection->dst;
         float factor = dist > 0.0f ? 200.0f/dist : 200.0f; // move faster if object is closer (this is fun)
         if (factor > 50.0f) factor = 50.0f;
         btVector3 velocity = towardsCam*factor;
         velocity.setZ(0); // scoot it on the ground (cam is higher than object center)
         if (selection->dst < 10.0)  // away from the cam if within 10m
            velocity = -velocity;
         selection->_btRigidBody->setLinearVelocity(velocity);
      }
   }
   lastSelection = selection;
}


Its mildly interesting to note (as should be expected) that translating the object will skip collision detection if there is an intervening object. Setting the velocity does not (and should not) have this effect.

Here's the make_btVector code (convenient to use this class since it has nice operator overloading for vector stuff). If I did more than this little "fake constructor" I might subclass it.

Code:


btVector3 make_btVector3(const vec3& v3)
{
   return btVector3(v3.x, v3.y, v3.z);
}


-George

I set the rate to 1/20 in the following places:

Code:


glView.animationInterval = 1.0 / 20.0;

... and
sio2PhysicRender( sio2->_SIO2physic, 1.0f / 20.0f, 1 );


and I made sure I compiled with Optimization Level: Fastest

So three changes together seem to make the release build (on the 3G phone) much more responsive. I'm not sure about the exact effect of these changes so at some point I'll go back and try them again one at a time. Seems like performance could be a serious issue as the number of objects and complexity of the model increases. What else can be done?

waterbuffalo99 wrote:I got the following code to work. It moves objects (translates or sets their velocity) when they are selected (as mods to tutorial06_2). My question is this: is it OK to make these bullet physics calls to btRigidBody from the templateRender thread?

...
...

-George

Hi George,

It is perfectly fine to make physics bullet calls in templateRender() - of course and in order to improve performance, you probably should have as many of the bullet calls be done in a separate thread (with NO OGL in it) such as the templatePhysicCullingThread() one example in tutorial6_02.

As far as compiling for 'release' on the device, make sure to add as OTHER_CFLAGS in XCode, the following flags '-fno-regmove -O3'...

Performance could be suffering if you have a lot of MOVING objects with collisions...

You could try a simulation step of something like 1 / 35 with 2 passes...It comes down to what gives you the best result really I guess.

I'm only using bullet Pivot constraints so I can't really share much experience about the Hinge ones...I have seen a few threads about Hinge contraints here on the forums. Make sure to use the advanced search for the best results and I'm pretty sure you'll find quite a few answers to the points you raised here...

Thanks for sharing your experience and posting these code snippets - it is going to be useful to newcomers too.

You might want to check the SIO2 wiki at:
http://sio2interactive.wikidot.com/wikimain
and even contribute to it ;-)

Cheers

--Franky

Hey George,

I'm using Bullet physics too. It's an amazing package ...

I tried driving objects in Bullet using forces ( ... ApplyCentralForce) for a mini flight sim gm but the result is unstable. Shame but linear and angular velocity work well enough. The work is all done in the templateRender thread.

Your fake constructor is a nice touch. The Bullet vectors make for more concise code but I have been doing the memcpy kluge to covert from btvector3 to vec3 from time to time.

Thanks

Chris

Thanks for the feedback and info Franky and Chris,

I tried force too, I think both linear and angular. Now that you mention it I think I did see cases where an object seemed to go through the hill at the edge of the scene. I assumed that it was due to the force being too great, but seems like a bug.

Franky: I'll try the simulation params you suggested. Can you outline how you use the pivot constraint?

BTW - I see this post: https://sio2interactive.forumotion.net/sio2-engine-f3/physics-constraints-t539.htm
So, I'll try that. I suppose setting up a Win-doze virtual machine (or maybe Xterm on linux or OSX) might be in order so I can compile and play with the bullet samples.

-George

When should I call sio2PhysicPause and Play?

I think the calls are commented out in my code above, but I've tried it both ways and don't know if its good bad or indifferent. I'm guessing it could be for thread safety and/or it could be that it makes anomolies due to changes in velocity (for example) less likely to happen, like I've seen my objects going through other objects in some of my experiments.

What's the true story?

thanks,
george

sio2Physic play will let the sio2PhysicRender function being executed... if you push pause the current simulation will pause until you call sio2Physic play again... that's all there is to it

I followed the post below and adapted it a little. Next I'll try the custom hinge and other constraints and variations on the 6DOF. In this case I got hinge like behavior.

Here's where I started: http://forum.sio2interactive.com/sio2-engine-f3/physics-constraints-t539.htm

Here's my code after some small modifications:

Code:



#ifdef HINGE_BASED_ON_6DOF_EXAMPLE
{
   // Put all my "objects of interest" on my own list later
   // for now I can look at them in the debugger if I declare them static
   static SIO2object *cylinder2 = (SIO2object *)sio2ResourceGet( sio2->_SIO2resource,
                                               SIO2_OBJECT,
                                               "object/Cylinder.002" );
   
   static SIO2object *cylinder3 = (SIO2object *)sio2ResourceGet( sio2->_SIO2resource,
                                                   SIO2_OBJECT,
                                                   "object/Cylinder.003" );
   // sio2PhysicInit does this
   //sio2->_SIO2physic->_btConstraintSolver = new btSequentialImpulseConstraintSolver();
   btGeneric6DofConstraint* hinge;
   btTransform frameInA = btTransform::getIdentity();
   // the cylinder heights happen to be 3.375 + 4.224
   // so 2.1 makes 1 partially embedded in the other, 1 has a slightly greater radius also
   frameInA.setOrigin(btVector3(btScalar(0), btScalar(0), btScalar(0.0)));
   btTransform frameInB = btTransform::getIdentity();
   frameInB.setOrigin(btVector3(btScalar(0), btScalar(0), btScalar(2.1)));
   
   hinge =  new btGeneric6DofConstraint( *cylinder2->_btRigidBody, *cylinder3->_btRigidBody,
                                frameInA, frameInB, true );
   sio2->_SIO2physic->_btSoftRigidDynamicsWorld->addConstraint(hinge, true);
   // limit the rotation about the X and Y axis but allow rotation about Z
   hinge->setLimit(3, 0.0f, 0.0f);
   hinge->setLimit(4, 0.0f, 0.0f);
   hinge->setLimit(5, 0.0f, 160.0f * M_PI/180.0f); // rotate up to 160.0 deg.
}
#endif


Here's the code for a ring on a rod, or a telescoping antenna, etc.

Code:


// constrain translation on x,y, and on z within limits (so it won't fall of the rod)
   constraint->setLimit(0, 0, 0);
   constraint->setLimit(1, 0, 0);
   constraint->setLimit(2, -10.0, 10.0);
// constrain rotation about x, and y but not z
   constraint->setLimit(3, 0, 0);
   constraint->setLimit(4, 0, 0);


Is it possible ... ? / how do you... ?

- Create an object that you can walk inside, yet the outside walls have collision detection
- a variation on this would be tunnels or caves, i.e. the ground plane would have to have an opening
- another would be an above ground structure -- it would have collision-walls inside and out but not physics otherwise
(you might call it an anchored object)

- Is there a way to attach physics objects to each other (they temporarily act as one object). I know constraints provide one way, but they seem to behave strangely at times (the constraint isn't always obeyed... this may be a bug), and it might be more processor intensive than some other way of "gluing" objects together.

-George

- Create an object that you can walk inside, yet the outside walls have collision detection
- a variation on this would be tunnels or caves, i.e. the ground plane would have to have an opening
- another would be an above ground structure -- it would have collision-walls inside and out but not physics otherwise
(you might call it an anchored object)

>> Check tutorial06 + video


- Is there a way to attach physics objects to each other (they temporarily act as one object). I know constraints provide one way, but they seem to behave strangely at times (the constraint isn't always obeyed... this may be a bug), and it might be more processor intensive than some other way of "gluing" objects together.

>> Check tutorial14

In tutorial 6, do you mean the outside walls that are "ghosted"? I get that idea, the ghost feature, and turning the normals inside.

In tutorial 6, the player is already inside the walls. But, how would you create an opening like a doorway that the player can walk through into a cube, where the cube has outside collision walls (except for the doorway) and inside walls?

-George

You can use a simple IPO that animate the door triggered by something that happen in your 3D world.

Maybe I'm asking for a feature in bullet collision detection.

You seem to be saying "detect when your player object is close to the doorway and animate the door opening (but the animation is not the main question here) and then temporarily turn off collision detection" which might work, but would have a lot of exception cases.

Alternatively I'd like collision detection to tell me, obj_a hit obj_b at face "doorway 10" with vector x (relative to the face). Then I decide what to do and let bullet know whether to ignore collision detection and let obj_a continue in that direction (i.e. only if the door is open, otherwise wham). It would also be tricky to _not_ render the faces of obj_b for the doorway while the door is open.

Does that make sense? Is there a way to label faces, points, or edges in blender?

-George

Is it possible to have a second ground plane, like a house with a second floor?

I've tried doing just what was done for the first one, creating a second plane only smaller and above the main plane. It doesn't work. Objects fall right through it.

-George

In this case simply create a collision ray after that you can have access to the SIO2object, hit point, normal etc...

Plenty enough information to let you do whatever you want...

waterbuffalo99 wrote:Is it possible to have a second ground plane, like a house with a second floor?

I've tried doing just what was done for the first one, creating a second plane only smaller and above the main plane. It doesn't work. Objects fall right through it.

-George

Check the following:

- That your new plane is an actor under Logic mode
- Make sure your new plane's normals are pointing the right way
- Ctrl+t to convert your plane mesh to triangle if not already
- select your new plane object, Ctrl+a, Object->Apply Scale/Rotation
- Ctrl+a, Object->Apply Transform
- Erase .sio2 file and exporter output directory
- Then export everything again in object mode

Just some thoughts

--francois

That worked Francois.

I'm pretty sure I had not tried the "Apply" steps. Not sure why those steps are necessary, you would think they would be automatic?

I noticed that I had a really weird behaving cylinder, it would hang in mid air, when a torque force was applied it would spin like crazy and its boundaries didn't seem to be in the right place in general. I did Apply Scale/Rotation to it and it went back to normal. I always wonder if there's a feature hiding behind such strangeness.

thanks!

-george

sio2interactive wrote:In this case simply create a collision ray after that you can have access to the SIO2object, hit point, normal etc...

Plenty enough information to let you do whatever you want...

This sounds interesting but pretty vague. Can you point me at an API call? some example code?

-George

Well that's all in the Bullet SDK... but, you can check tutorial09:

Code:




            // Create a collision ray starting from our player to the camera
            // position. Here we give a little offset to the Z value in order
            // to be right on top of the player head.
            btVector3 from( object->_SIO2transform->loc->x,
                        object->_SIO2transform->loc->y,
                        object->_SIO2transform->loc->z + object->dim->z + 0.1f );

            // Our "desired" camera position in world space.
            btVector3 to( tmp_pos.x, tmp_pos.y, tmp_pos.z );

            // Execute the collision ray.
            btCollisionWorld::ClosestRayResultCallback ray( from, to );
            sio2->_SIO2physic->_btSoftRigidDynamicsWorld->getCollisionWorld()->rayTest( from, to, ray );

            
            // We have a collide into something, our camera cannot be at our
            // desired position so we need to adjust its position to take
            // the same value in worldspace from where our ray intersect with
            // something.
            if( ray.hasHit() )
            {
               // Affect the collision ray XYZ position.
               sio2->_SIO2camera->_SIO2transform->loc->x = ray.m_hitPointWorld.x();
               sio2->_SIO2camera->_SIO2transform->loc->y = ray.m_hitPointWorld.y();
               sio2->_SIO2camera->_SIO2transform->loc->z = ray.m_hitPointWorld.z();               
            }
            else
            {
               // No collision was detected we can then use
               // the values from our "desired" camera position
               sio2->_SIO2camera->_SIO2transform->loc->x = tmp_pos.x;
               sio2->_SIO2camera->_SIO2transform->loc->y = tmp_pos.y;
               sio2->_SIO2camera->_SIO2transform->loc->z = tmp_pos.z;
            }