irrBP - An Irrlicht - Bullet Physics Wrapper
Erm, I would like to know how to find what bodies are colliding in physics world, what is the fastest method to do so?
I've seen that you made some callback stuff in the wrapper, should I use it or is there any better solution for this?
(I'm kind of slowly improving my game engine and I need this badly for trigger system.)
EDIT: Ok I got some collision code to work, but now I have another problem, it seems wrapper is missing user pointer functions, which are used I guess for irrlicht nodes?
I really need those user pointer functions as I need to know what entities collided
EDIT2: It seems that code completion fooled me, I made it to work, tough I'm still confused about user pointer function, is it used internally or not?
I've seen that you made some callback stuff in the wrapper, should I use it or is there any better solution for this?
(I'm kind of slowly improving my game engine and I need this badly for trigger system.)
EDIT: Ok I got some collision code to work, but now I have another problem, it seems wrapper is missing user pointer functions, which are used I guess for irrlicht nodes?
I really need those user pointer functions as I need to know what entities collided
EDIT2: It seems that code completion fooled me, I made it to work, tough I'm still confused about user pointer function, is it used internally or not?
Working on game: Marrbles (Currently stopped).
Hi serengeor, i would like to help you, but i don't understand what "user pointer functions" means. Are you talking about irrBP animators?
irrBP - an Irrlicht - Bullet Physics Wrapper.
The only irrlicht-physics wrapper that uses multithread technology.
The only irrlicht-physics wrapper that uses multithread technology.
Nooooo, I mean these functions:
Did you use them for anything, or not?, if not great, because I need them to store my Entity object pointer.
Code: Select all
/*From bullet documentation*/
void * getUserPointer () const
//users can point to their objects, userPointer is not used by Bullet
void setUserPointer (void *userPointer)
//users can point to their objects, userPointer is not used by Bullet
Working on game: Marrbles (Currently stopped).
Ah, ok!
The answer is NO, i don't use them since i wrote the CMotionState class. Altough i forgot to delete the assigning function in the rigid body constructor. Just Fixed in SVN (rev. 45).
Thank you again for your help
The answer is NO, i don't use them since i wrote the CMotionState class. Altough i forgot to delete the assigning function in the rigid body constructor. Just Fixed in SVN (rev. 45).
Thank you again for your help
Last edited by Zurzaza on Mon Feb 21, 2011 3:50 pm, edited 1 time in total.
irrBP - an Irrlicht - Bullet Physics Wrapper.
The only irrlicht-physics wrapper that uses multithread technology.
The only irrlicht-physics wrapper that uses multithread technology.
Great!Zurzaza wrote:Ah, ok!
The answer is NO, i don't use them since i wrote the CMotionState class. Altough i forgot to delete the assigning function in the rigid body constructor. Fixed in SVN (rev. 45).
Thank you again for your help
Also, Is the debug drawer working properly? last time I tried to use it it was kind of slow, and it messed with fps cam a lot, was hard to move around.
Tough I don't really need it anyways
Working on game: Marrbles (Currently stopped).
Yes, it can be very slow if you use the "DBG_DrawWireframe" flag (for example), because it will draw each "line" in the world. For example, if you load the irrlicht' quake 3 example map, and if you use the debug drawer in "DrawWireframe" mode, the performace can drop down to ~30-40 FPS (or less).serengeor wrote:Great!Zurzaza wrote:Ah, ok!
The answer is NO, i don't use them since i wrote the CMotionState class. Altough i forgot to delete the assigning function in the rigid body constructor. Fixed in SVN (rev. 45).
Thank you again for your help
Also, Is the debug drawer working properly? last time I tried to use it it was kind of slow, and it messed with fps cam a lot, was hard to move around.
Tough I don't really need it anyways
So, my tip is to use the debug drawer, only if you need it, and only with the proper flags (defined in the IBP_DEBUG_FLAGS enum, in types.h).
irrBP - an Irrlicht - Bullet Physics Wrapper.
The only irrlicht-physics wrapper that uses multithread technology.
The only irrlicht-physics wrapper that uses multithread technology.
Yes I indeed used wireframe mode tough if I remember correctly the weird cam behavior wasn't because of low fps, but now I'm too lazy to reproduce the problemZurzaza wrote:Yes, it can be very slow if you use the "DBG_DrawWireframe" flag (for example), because it will draw each "line" in the world. For example, if you load the irrlicht' quake 3 example map, and if you use the debug drawer in "DrawWireframe" mode, the performace can drop down to ~30-40 FPS (or less).serengeor wrote:Great!Zurzaza wrote:Ah, ok!
The answer is NO, i don't use them since i wrote the CMotionState class. Altough i forgot to delete the assigning function in the rigid body constructor. Fixed in SVN (rev. 45).
Thank you again for your help
Also, Is the debug drawer working properly? last time I tried to use it it was kind of slow, and it messed with fps cam a lot, was hard to move around.
Tough I don't really need it anyways
So, my tip is to use the debug drawer, only if you need it, and only with the proper flags (defined in the IBP_DEBUG_FLAGS enum, in types.h).
Working on game: Marrbles (Currently stopped).
Hi again serengeor, thank you again for your testing.
The code that you posted there, is probably taken from There. The problem of this algorithm is the following:
"This should be done during a simulation tick (substep) callback, because contacts might be added and removed during several substeps of a single stepSimulation call. "
So maybe this is the problem that you're complaining about.
Another things that you forgot to insert in the algorithm is the contact points distance control:
You can also see(and use, of course) the complete source in the isBodyColliding() function in CIrrBPWorld.
To avoid this kind of problem and get in an endless loop searching for the bug, you can use the better stable function to see if a pair of object is currently colliding:
GameCore::instance()->GetPhysicsManager()->getWorld()->isPairColliding(ent,ent2)
edit: I saw now your edit (I forgot to press the submit button and i changed tab...nice to hear that!
The code that you posted there, is probably taken from There. The problem of this algorithm is the following:
"This should be done during a simulation tick (substep) callback, because contacts might be added and removed during several substeps of a single stepSimulation call. "
So maybe this is the problem that you're complaining about.
Another things that you forgot to insert in the algorithm is the contact points distance control:
Code: Select all
for (int j=0;j<numContacts;j++)
{
btManifoldPoint& pt = contactManifold->getContactPoint(j);
if (pt.getDistance()<0.f)
{
const btVector3& ptA = pt.getPositionWorldOnA();
const btVector3& ptB = pt.getPositionWorldOnB();
const btVector3& normalOnB = pt.m_normalWorldOnB;
}
}
To avoid this kind of problem and get in an endless loop searching for the bug, you can use the better stable function to see if a pair of object is currently colliding:
GameCore::instance()->GetPhysicsManager()->getWorld()->isPairColliding(ent,ent2)
edit: I saw now your edit (I forgot to press the submit button and i changed tab...nice to hear that!
irrBP - an Irrlicht - Bullet Physics Wrapper.
The only irrlicht-physics wrapper that uses multithread technology.
The only irrlicht-physics wrapper that uses multithread technology.
Hi Zurzaza, have you ever used "using namespace" keyword in irrBP?
I would like to remove them as I don't like them, sometimes you can get into weird troubles with them. Already had a few earlier, tough solved in a hackyish way.
I would like to remove them as I don't like them, sometimes you can get into weird troubles with them. Already had a few earlier, tough solved in a hackyish way.
Working on game: Marrbles (Currently stopped).
yes, I use a local (irrBP) namespace to "isolate" the functions in the convert.h header, you can remove the "using namespace" instruction, but you must remove the function from the namespaceserengeor wrote:Hi Zurzaza, have you ever used "using namespace" keyword in irrBP?
I would like to remove them as I don't like them, sometimes you can get into weird troubles with them. Already had a few earlier, tough solved in a hackyish way.
irrBP - an Irrlicht - Bullet Physics Wrapper.
The only irrlicht-physics wrapper that uses multithread technology.
The only irrlicht-physics wrapper that uses multithread technology.
Have you used "using namespace irr", I was concerned about irr namespace usage, as my apps compiled fine without writing irr, tough I haven't used "using manespace irr" anywhere in my project.Zurzaza wrote:yes, I use a local (irrBP) namespace to "isolate" the functions in the convert.h header, you can remove the "using namespace" instruction, but you must remove the function from the namespaceserengeor wrote:Hi Zurzaza, have you ever used "using namespace" keyword in irrBP?
I would like to remove them as I don't like them, sometimes you can get into weird troubles with them. Already had a few earlier, tough solved in a hackyish way.
Working on game: Marrbles (Currently stopped).
using namespace irr is useful to avoid writing irr::core::vector3df in some cases, altough i can fix it in the next irrBP release for better clean code, but i think it isn't a primary thing.serengeor wrote:Have you used "using namespace irr", I was concerned about irr namespace usage, as my apps compiled fine without writing irr, tough I haven't used "using manespace irr" anywhere in my project.Zurzaza wrote:yes, I use a local (irrBP) namespace to "isolate" the functions in the convert.h header, you can remove the "using namespace" instruction, but you must remove the function from the namespaceserengeor wrote:Hi Zurzaza, have you ever used "using namespace" keyword in irrBP?
I would like to remove them as I don't like them, sometimes you can get into weird troubles with them. Already had a few earlier, tough solved in a hackyish way.
Your application can compile without declaring the namespace, just because in the irrBP headers I already use them
irrBP - an Irrlicht - Bullet Physics Wrapper.
The only irrlicht-physics wrapper that uses multithread technology.
The only irrlicht-physics wrapper that uses multithread technology.
this is bad for me, had to change some things in other libs because they had identical function names, just different argument types to irrlicht ones and I got ambiguous function call error. I personally never use using namespace, just because I would know where the function lies in, and also makes more sense to other people that read the code.Zurzaza wrote:using namespace irr is useful to avoid writing irr::core::vector3df in some cases, altough i can fix it in the next irrBP release for better clean code, but i think it isn't a primary thing.serengeor wrote:Have you used "using namespace irr", I was concerned about irr namespace usage, as my apps compiled fine without writing irr, tough I haven't used "using manespace irr" anywhere in my project.Zurzaza wrote: yes, I use a local (irrBP) namespace to "isolate" the functions in the convert.h header, you can remove the "using namespace" instruction, but you must remove the function from the namespace
Your application can compile without declaring the namespace, just because in the irrBP headers I already use them
And I think the purpose of the namespaces is to protect from having functions with the same name that came from separate libraries, so when you use "using namespace irr;" in your project you just removed the protection for your lib users(like me).
I would do it myself tough, I'm not in need for this atm, I've just seen a post by a guy from irrBulet thread about this kind of problem and I remembered that I encountered it too.
Working on game: Marrbles (Currently stopped).