Irrlicht Engine

Posted: **Sun Feb 20, 2011 9:03 pm**

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?

Posted: **Mon Feb 21, 2011 3:25 pm**

Hi serengeor, i would like to help you, but i don't understand what "user pointer functions" means. Are you talking about irrBP animators?

Posted: **Mon Feb 21, 2011 3:27 pm**

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.

Posted: **Mon Feb 21, 2011 3:46 pm**

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

Posted: **Mon Feb 21, 2011 3:50 pm**

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

Posted: **Mon Feb 21, 2011 3:55 pm**

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).

Posted: **Mon Feb 21, 2011 3:58 pm**

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

Posted: **Sat Feb 26, 2011 10:41 am**

Edit: Never mind, fixed silly problem..

Posted: **Sat Feb 26, 2011 5:13 pm**

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!

Posted: **Sat Feb 26, 2011 5:21 pm**

Thanks anyways

Posted: **Thu Mar 10, 2011 9:26 am**

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.

Posted: **Thu Mar 10, 2011 2:00 pm**

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

Posted: **Thu Mar 10, 2011 2:40 pm**

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.

Posted: **Thu Mar 10, 2011 3:12 pm**

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

Posted: **Thu Mar 10, 2011 3:21 pm**

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.

Irrlicht Engine

irrBP - An Irrlicht - Bullet Physics Wrapper