Use object only for collision

I'd like to use an object ONLY for collision but not apply any other physical quantities, i.e. control it myself. How would I do that?

Best,
Matt

Checkout tutorial09 that should get you started...

Okay, simply overwriting Bullet's calculations is one way to do it, but it's a waste of CPU time also. Do you know other ways?

Best,
Matt

What are you trying to do exactly? So I can figure out what is the best way to do it...

Cheers,

I have an object which follows a predefined way (spline). The object's bounds are setup in Blender. The object shall collide with other objects as usual but it shall not get affected by any means, i.e. the object moves other objects away but doesn't move/rotate itself. Moreover, I need feedback if the object collides, that's where I use the sensor system currently.

(I'm just looking at the code: if two objects collide, is the callback called twice?!)

Best,
Matt

I've encountered another issue with the SIO2 sensor system. Maybe you can shed some light on this.

I create multiple sensors in a "one to many" relationship: for one object, I create multiple collision sensors with other objects. Once one sensor is triggered, I free it. The problem here is that the material flags for both objects are resetted although one of the objects is still registered for several other sensors.

Either I got something wrong with the sensor system and I simply used the wrong one, or a reference-counting system would be in order, wouldn't it?

Moreover, I recognized that removing a sensor in the collision callback leads to severe problems in the sio2PhysicCollisionCallback. One particular reason is that the counter i is compared by != instead of < so an overrun is produced easily. Still, it seems like the whole implementation doesn't really support removing sensors on the fly, right? I was thinking about changing the callback signature to return a flag whether the sensor was removed or not and increment the counter only if it wasn't, but that could be easily misused, so I guess I will collect all inactive sensors and remove them after the physic tick.

Best,
Matt

Honestly Im not quite sure I understand you here... what about you create a simple demo test project to show me what you are trying to achieve and where SIO2 cause problem, so I can fix it for you...

Tks in advance,

Cheers,

The first situation is pretty easy to understand if you simply look at the code:

Imagine you have three SIO2object*, obj1, obj2, obj3. Now create two sensors:

Code:

SIO2sensor* sensor1 = sio2SensorInitCollision( "sensor1", obj1, obj2, someCallback );
SIO2sensor* sensor2 = sio2SensorInitCollision( "sensor2", obj1, obj3, someCallback );

Now if you free one sensor in the callback, see what happens:

Code:

SIO2sensor *sio2SensorFree( SIO2sensor *_SIO2sensor )
{
   // ...
   if( _SIO2sensor->_SIO2object0 )
   { sio2ObjectDisableObjectCollisionCallback( _SIO2sensor->_SIO2object0 ); }
   
   if( _SIO2sensor->_SIO2object1 )
   { sio2ObjectDisableObjectCollisionCallback( _SIO2sensor->_SIO2object1 ); }
   // ...
}

For both objects, the collision callback is disabled and no longer called. But in this case, if you free one sensor, "obj1" is still part of the other sensor! The problem doesn't really get obvious because still obj3 has its callback activated, but the whole situation appears to be a design problem.


The second situation is easily described, too, when looking at the code. Imagine you remove a sensor right in the callback. Imagine it's the last one of - say - 10 sensors.

sio2PhysicCollisionCallback looks like that:

Code:

   unsigned int i = 0;
   
   while( i != sio2->_SIO2resource->n_sensor )
   {
      // ...

Now if i == 9 for the last sensor and n_sensor is 10, normally the loop would exit with the next iteration. But once you remove the senor in the callback, n_sensor becomes 9 and i becomes 10 at the end of the loop body, so the exit condition fails and you get a buffer overrun.

Generally speaking, I think it's okay not to allow removal of senors in the callback. One can easily collect all "deactivated" sensors and remove them after the physic tick. But, the problem I see in this case and in many other places in SIO2, too: it's not documented.

HTH.

Best,
Matt

I totally agree with you matt, that there's a lack of documentation, it would be nice is you can start helping writing decent documentation for the API, honestly me between my dayjob and the development of SIO2 I don't have time

It would be really nice also if other peoples are willing to help on this subject... also if people can give feedbacks and/or ideas about what kind of "format" the documentation should be presented it would be great!

Tks to all in advance,

Cheers,