Use object only for collision
2 posters
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
Best,
Matt
Re: Use object only for collision
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
Best,
Matt
Re: Use object only for collision
What are you trying to do exactly? So I can figure out what is the best way to do it...
Cheers,
Cheers,
Re: Use object only for collision
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'm just looking at the code: if two objects collide, is the callback called twice?!)
Best,
Matt
Re: Use object only for collision
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
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
Re: Use object only for collision
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,
Tks in advance,
Cheers,
Re: Use object only for collision
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:
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:
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
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 );
- Code:
SIO2sensor *sio2SensorFree( SIO2sensor *_SIO2sensor )
{
// ...
if( _SIO2sensor->_SIO2object0 )
{ sio2ObjectDisableObjectCollisionCallback( _SIO2sensor->_SIO2object0 ); }
if( _SIO2sensor->_SIO2object1 )
{ sio2ObjectDisableObjectCollisionCallback( _SIO2sensor->_SIO2object1 ); }
// ...
}
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 )
{
// ...
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
Last edited by matt on Sat Nov 08, 2008 6:56 pm; edited 2 times in total (Reason for editing : Fixed first code sample)
Re: Use object only for collision
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,
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,
Similar topics
» Collision for animate object
» Collision with high speed object (ccd)
» physics object inside another physics object
» md2 collision
» Collision Again
» Collision with high speed object (ccd)
» physics object inside another physics object
» md2 collision
» Collision Again
Permissions in this forum:
You cannot reply to topics in this forum
|
|