irrBP - An Irrlicht - Bullet Physics Wrapper

Announce new projects or updates of Irrlicht Engine related tools, games, and applications.
Also check the Wiki
serengeor
Posts: 1712
Joined: Tue Jan 13, 2009 7:34 pm
Location: Lithuania

Post by serengeor »

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?
Working on game: Marrbles (Currently stopped).
Zurzaza
Posts: 153
Joined: Fri Mar 26, 2010 9:41 pm
Location: Filo (FE), Italy
Contact:

Post by Zurzaza »

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.
serengeor
Posts: 1712
Joined: Tue Jan 13, 2009 7:34 pm
Location: Lithuania

Post by serengeor »

Nooooo, I mean these functions:

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 
Did you use them for anything, or not?, if not great, because I need them to store my Entity object pointer.
Working on game: Marrbles (Currently stopped).
Zurzaza
Posts: 153
Joined: Fri Mar 26, 2010 9:41 pm
Location: Filo (FE), Italy
Contact:

Post by Zurzaza »

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 :)
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.
serengeor
Posts: 1712
Joined: Tue Jan 13, 2009 7:34 pm
Location: Lithuania

Post by serengeor »

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 :)
Great!

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).
Zurzaza
Posts: 153
Joined: Fri Mar 26, 2010 9:41 pm
Location: Filo (FE), Italy
Contact:

Post by Zurzaza »

serengeor wrote:
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 :)
Great!

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 :)
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).
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.
serengeor
Posts: 1712
Joined: Tue Jan 13, 2009 7:34 pm
Location: Lithuania

Post by serengeor »

Zurzaza wrote:
serengeor wrote:
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 :)
Great!

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 :)
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).
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). ;)
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 problem :oops:
Working on game: Marrbles (Currently stopped).
serengeor
Posts: 1712
Joined: Tue Jan 13, 2009 7:34 pm
Location: Lithuania

Post by serengeor »

Edit: Never mind, fixed silly problem..
Working on game: Marrbles (Currently stopped).
Zurzaza
Posts: 153
Joined: Fri Mar 26, 2010 9:41 pm
Location: Filo (FE), Italy
Contact:

Post by Zurzaza »

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:

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;
			}
		}
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! ;)
irrBP - an Irrlicht - Bullet Physics Wrapper.
The only irrlicht-physics wrapper that uses multithread technology.
serengeor
Posts: 1712
Joined: Tue Jan 13, 2009 7:34 pm
Location: Lithuania

Post by serengeor »

Thanks anyways :)
Working on game: Marrbles (Currently stopped).
serengeor
Posts: 1712
Joined: Tue Jan 13, 2009 7:34 pm
Location: Lithuania

Post by serengeor »

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).
Zurzaza
Posts: 153
Joined: Fri Mar 26, 2010 9:41 pm
Location: Filo (FE), Italy
Contact:

Post by Zurzaza »

serengeor 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.
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
irrBP - an Irrlicht - Bullet Physics Wrapper.
The only irrlicht-physics wrapper that uses multithread technology.
serengeor
Posts: 1712
Joined: Tue Jan 13, 2009 7:34 pm
Location: Lithuania

Post by serengeor »

Zurzaza wrote:
serengeor 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.
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
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.
Working on game: Marrbles (Currently stopped).
Zurzaza
Posts: 153
Joined: Fri Mar 26, 2010 9:41 pm
Location: Filo (FE), Italy
Contact:

Post by Zurzaza »

serengeor wrote:
Zurzaza wrote:
serengeor 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.
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
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.
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.
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.
serengeor
Posts: 1712
Joined: Tue Jan 13, 2009 7:34 pm
Location: Lithuania

Post by serengeor »

Zurzaza wrote:
serengeor wrote:
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
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.
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.
Your application can compile without declaring the namespace, just because in the irrBP headers I already use them ;)
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.
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).
Post Reply