irrBullet 0.1.8 - Bullet physics wrapper
Re: irrBullet 0.1.71 - Bullet physics wrapper
from what i understand bullet use the aabb to filter the more precise collision code and avoid making some per triangle cheq on every shape every time
Re: irrBullet 0.1.71 - Bullet physics wrapper
serengeor wrote:Didn't he just say that?mubashar wrote:@polylux looks valid to you ?
I'm pretty sure bullet does not really do any real collision calculations based on AABB. (is that even bullet's AABB?)wikipedia wrote:In geometry, an axis-aligned object (axis-parallel, axis-oriented) is an object in n-dimensional space whose shape is aligned with the coordinate axes of the space.
http://en.wikipedia.org/wiki/Bounding_volume wrote:In collision detection, when two bounding volumes do not intersect, then the contained objects cannot collide, either.
When it's all over, it's not who you were. It's whether you made a difference
Re: irrBullet 0.1.71 - Bullet physics wrapper
That applies to transformed bounding boxes or even up-scaled bounding boxes that can contain the full object. While with AABB the object can sometimes leave it,mubashar wrote:serengeor wrote:Didn't he just say that?mubashar wrote:@polylux looks valid to you ?
I'm pretty sure bullet does not really do any real collision calculations based on AABB. (is that even bullet's AABB?)wikipedia wrote:In geometry, an axis-aligned object (axis-parallel, axis-oriented) is an object in n-dimensional space whose shape is aligned with the coordinate axes of the space.
http://en.wikipedia.org/wiki/Bounding_volume wrote:In collision detection, when two bounding volumes do not intersect, then the contained objects cannot collide, either.
Working on game: Marrbles (Currently stopped).
Re: irrBullet 0.1.71 - Bullet physics wrapper
@serengeor can you identify from my post (screenshots) which bounding Box is this ... actually my question is is it possible to transform this when object when scene node transforms... as it is happening in plain bullet demo ... but not in my case using Irrbullet
When it's all over, it's not who you were. It's whether you made a difference
Re: irrBullet 0.1.71 - Bullet physics wrapper
Scene node?? if you transform scene node instead of bullet body it wont update itself. Unless you're already using irrBullet, in that case it would reset scene node to bullet's body's position. Anyways you shouldn't do that as will make you need to update the body itself to the scene nodes transform. Better transform bullet's bodies and scene nodes will follow them (if you're using irrBullet ofc.).mubashar wrote:@serengeor can you identify from my post (screenshots) which bounding Box is this ... actually my question is is it possible to transform this when object when scene node transforms... as it is happening in plain bullet demo ... but not in my case using Irrbullet
Working on game: Marrbles (Currently stopped).
Re: irrBullet 0.1.71 - Bullet physics wrapper
Wicked. I told you. serengeor told you. The one in the second screenshot is the axis-aligned bounding box. It's the one that encloses your geometry given its bounding axes are parallel to your x, y and z axis in world space. So once the geometry (mesh) is rotated, the AABB will only change in size, not in orientation. The other part of your question is perfectly answered in serengeor's post.mubashar wrote:@serengeor can you identify from my post (screenshots) which bounding Box is this ... actually my question is is it possible to transform this when object when scene node transforms... as it is happening in plain bullet demo ... but not in my case using Irrbullet
beer->setMotivationCallback(this);
Re: irrBullet 0.1.71 - Bullet physics wrapper
@serengeor yes i am using Irrbullet Rigidbody as cars Chassi and now my question is now same
@serengeor can you identify from my post (screenshots) which bounding Box is this ... actually my question is is it possible to transform this when object when scene node transforms... as it is happening in plain bullet demo ... but not in my case using Irrbullet
When it's all over, it's not who you were. It's whether you made a difference
Re: irrBullet 0.1.71 - Bullet physics wrapper
Take a look in the irrBullet code, which box is drawn.mubashar wrote:@serengeor yes i am using Irrbullet Rigidbody as cars Chassi and now my question is now same
@serengeor can you identify from my post (screenshots) which bounding Box is this ... actually my question is is it possible to transform this when object when scene node transforms... as it is happening in plain bullet demo ... but not in my case using Irrbullet
Re: irrBullet 0.1.71 - Bullet physics wrapper
hi
first of all nice work:)
i have some questens about it:
1)
in the destruktor of rigidbody and softbody stands
i think it must be in the base class (icollisionobject) because it is there declared
2)
i think removeCollisionObject and other remove func are "slow" if you had many objects
because if it found the obj that will be deleted the loop will go on
maybe a break if ob found is missing?
3)
in btTriangleMesh *ITriangleMeshShape::getTriangleMesh(IMesh* const mesh)
at the end stands:
e.g.
in IGImpactMeshShape the member var btGImpactMeshShape* gimpactShape is declared
it is not necessary to store it in gimpactShape becauce it is stored by the base class (shape)
that is a just a little bit confusing not a error itself
generell questions:
1)
what was your purpose to use UniqueID and dont let the user to handle it like in irrlicht?
eg
2)
in the collision loop
thx for your help
chris
first of all nice work:)
i have some questens about it:
1)
in the destruktor of rigidbody and softbody stands
Code: Select all
if(collID)
delete collID;
2)
i think removeCollisionObject and other remove func are "slow" if you had many objects
because if it found the obj that will be deleted the loop will go on
maybe a break if ob found is missing?
3)
in btTriangleMesh *ITriangleMeshShape::getTriangleMesh(IMesh* const mesh)
at the end stands:
i think it makes no sense at the end because the var pTriMesh is used before. if it is really necessary put it before the loopif(pTriMesh)
return pTriMesh;
e.g.
4)if(!pTriMesh)
return nullptr
in IGImpactMeshShape the member var btGImpactMeshShape* gimpactShape is declared
it is not necessary to store it in gimpactShape becauce it is stored by the base class (shape)
that is a just a little bit confusing not a error itself
generell questions:
1)
what was your purpose to use UniqueID and dont let the user to handle it like in irrlicht?
eg
Code: Select all
IGImpactMeshShape(ISceneNode *n, IMesh *collMesh, f32 m, s32 id = -1)
in the collision loop
Code: Select all
for(int i=0; i < world->getNumManifolds(); i++)
{
ICollisionCallbackInformation *info = world->getCollisionCallback(i);
bool hasCollideAttribute = (info->getBody0()->getAttributes()->existsAttribute("collide")); // <-2.1 is an obj that is non static only gets the colide attribute?
ICollisionObject* obj = (hasCollideAttribute) ? info->getBody0() : info->getBody1();
((IRigidBody*)info->getBody0())->applyForce(core::vector3df(0,10000,0), core::vector3df(0,1,0), ERBTS_LOCAL); //<-2.2 is this the right way to bounce the body away from the sec? is a effektor here better?
info->getPointer()->clearManifold(); //<-2.3 is this the right way to clear & delete the info?
delete info;
}
chris
Re: irrBullet 0.1.71 - Bullet physics wrapper
Hi Zerochen,
I greatly appreciate you reporting these findings to me so that I could fix them.
These are quite surprising as they are not things that I would do in a normal state-of-mind, but I've worked a lot on IrrBullet when I was tired, hurrying, or concentrating on deep implementations or big changes so I guess that is probably how they weaseled their ways in there. Also, these oddities are in code that dates back to the start of IrrBullet, so I haven't worked with them in quite some time; in fact, I haven't worked on IrrBullet much in quite some time, either.
With that said, all of the things you mentioned have been fixed. Update from the IrrBullet trunk to get the new code.
Now on to your question about UniqueID:
I chose not to let the user handle UniqueID so that it can never be -1 and there can never be any duplicates. It should never be -1 because the IrrBullet system uses UniqueID to identify collision objects.
About the collision loop:
"<-2.1 is an obj that is non static only gets the colide attribute?"
The "collide" attribute was only used in the collision example for special types of objects. It is not added by IrrBullet.
"<-2.2 is this the right way to bounce the body away from the sec? is a effektor here better?"
If you want to apply a single instantaneous impulse to something, use applyImpulse() or internalApplyImpulse().
If you want to bounce the object away from where it collided, use something like this:
I wrote this code directly in my reply, so it hasn't been tested, but it should work just fine. Note that you must loop through all of the contact points in the collision callback.
Make sure you check that point.getDistance() is equal to 0 to make sure it is an actual physical collision and not just an AABB intersection.
Also, don't use an affector for something like this. Affectors are for behaviors that are meant to persist for an object's lifetime or for special cases where an affector would be useful.
"<-2.3 is this the right way to clear & delete the info?"
Yes, that is the correct way to delete the info. I might end up renaming the function "getCollisionCallback()" to "createCollisionCallback()" so that it's more obvious that the returned pointer must be manually deleted.
I hope that covers all that you need to know. Thank you for using IrrBullet, and thank you for being an important part of its progress (by reporting bugs and oddities).
I greatly appreciate you reporting these findings to me so that I could fix them.
These are quite surprising as they are not things that I would do in a normal state-of-mind, but I've worked a lot on IrrBullet when I was tired, hurrying, or concentrating on deep implementations or big changes so I guess that is probably how they weaseled their ways in there. Also, these oddities are in code that dates back to the start of IrrBullet, so I haven't worked with them in quite some time; in fact, I haven't worked on IrrBullet much in quite some time, either.
With that said, all of the things you mentioned have been fixed. Update from the IrrBullet trunk to get the new code.
Now on to your question about UniqueID:
I chose not to let the user handle UniqueID so that it can never be -1 and there can never be any duplicates. It should never be -1 because the IrrBullet system uses UniqueID to identify collision objects.
About the collision loop:
"<-2.1 is an obj that is non static only gets the colide attribute?"
The "collide" attribute was only used in the collision example for special types of objects. It is not added by IrrBullet.
"<-2.2 is this the right way to bounce the body away from the sec? is a effektor here better?"
If you want to apply a single instantaneous impulse to something, use applyImpulse() or internalApplyImpulse().
If you want to bounce the object away from where it collided, use something like this:
Code: Select all
SManifoldPoint point = info->getContactPoint(i);
irr::f32 speed = 10.0f;
static_cast<IRigidBody*>(info->getBody0())->internalApplyImpulse(point.getNormalWorldOnB().normalize()*speed, ERBTS_WORLD);
Make sure you check that point.getDistance() is equal to 0 to make sure it is an actual physical collision and not just an AABB intersection.
Also, don't use an affector for something like this. Affectors are for behaviors that are meant to persist for an object's lifetime or for special cases where an affector would be useful.
"<-2.3 is this the right way to clear & delete the info?"
Yes, that is the correct way to delete the info. I might end up renaming the function "getCollisionCallback()" to "createCollisionCallback()" so that it's more obvious that the returned pointer must be manually deleted.
I hope that covers all that you need to know. Thank you for using IrrBullet, and thank you for being an important part of its progress (by reporting bugs and oddities).
Re: irrBullet 0.1.71 - Bullet physics wrapper
I created a small patch to add an extra constructor IBvhTriangleMeshShape.
This is very usefull if you want to create a RigidBody for the TerrainSceneNode.
This is very usefull if you want to create a RigidBody for the TerrainSceneNode.
Re: irrBullet 0.1.71 - Bullet physics wrapper
Thank you for irrBullet. It was easy to set up and looks really usefull. This is the first time I have really tried to understand and use it. I can't for the life of me figure out how to create terrain that works with irrbullet. Could you post an example of how to do this given an ITerrainSceneNode?
Re: irrBullet 0.1.71 - Bullet physics wrapper
Take a look at this post: http://irrlicht.sourceforge.net/forum/v ... 30#p260684BenT wrote:Thank you for irrBullet. It was easy to set up and looks really usefull. This is the first time I have really tried to understand and use it. I can't for the life of me figure out how to create terrain that works with irrbullet. Could you post an example of how to do this given an ITerrainSceneNode?
Re: irrBullet 0.1.71 - Bullet physics wrapper
Hi would you consider/have you considered, making an irredit plug-in?
-
- Posts: 3
- Joined: Tue Feb 28, 2012 5:46 pm
Re: irrBullet 0.1.71 - Bullet physics wrapper
Hey all,
I am compiling irrBullet 1.7.1 on Ubuntu 11.10. Running a simple make command to compile irrBullet yields the following error: make:
The full log is:
Now, I haven't really done anything other than "cd" into the build directory. Judging from the readme, there aren't any external dependencies. If anyone could provide some assistance, it would be greatly appreciated.
Thank you in advance
I am compiling irrBullet 1.7.1 on Ubuntu 11.10. Running a simple make command to compile irrBullet yields the following error: make:
Code: Select all
*** No rule to make target `Bullet/btBulletDynamicsCommon.h', needed by `../source/trianglemeshshape.cpp'. Stop.
Code: Select all
MYUSERNAME@ubuntu:~/Downloads/irrBullet-0.1.71/build$ make
make: Circular ../source/trianglemeshshape.cpp <- ../source/trianglemeshshape.cpp dependency dropped.
make: *** No rule to make target `Bullet/btBulletDynamicsCommon.h', needed by `../source/trianglemeshshape.cpp'. Stop.
Thank you in advance