Getting errors updating from 2.56 to 2.66

[S8N]

Hi, I've been using an older version of Bullet Physics till now and decided recently to update my program to the latest one. However I've been having error messages in the transition and I'm not sure exactly why I'm getting them.

I compiled the Bullet library using Microsoft Visual Studio Express C++ and got a few error messages, however these were post-build event errors which seemed to be to execute xcopy. Should I be concerned with these?

Afterwards I replaced the library and include paths with the newer 2.66 Bullet Physics ones. But when I compile my program I get error messages like this:

Code: btBoxShape *mShape = new btBoxShape(btVector3(boxSize / 2.0f, boxSize / 2.0f, boxSize / 2.0f));
Error: C2661 'btConvexShape::operator new' : No overloaded function takes 4 arguments.

Code: btRigidBody *mBody = new btRigidBody(200.0f,mState,mShape);
Error: C2661 'btCollisionShape::operator new' : No overloaded function takes 4 arguments.

These snippets of code worked in 2.56, but give the error in 2.66. I don't understand why I'm getting these errors when (as far as I can tell) I'm not using 4 arguments for either of the lines. I am using Microsoft Visual Studio Express C++ to compile.

Can anybody help me? Thanks.

[Erwin Coumans]

Code: btBoxShape *mShape = new btBoxShape(btVector3(boxSize / 2.0f, boxSize / 2.0f, boxSize / 2.0f));
Error: C2661 'btConvexShape::operator new' : No overloaded function takes 4 arguments.

Code: btRigidBody *mBody = new btRigidBody(200.0f,mState,mShape);
Error: C2661 'btCollisionShape::operator new' : No overloaded function takes 4 arguments.

That is odd.

- Does your application overload the global 'new' operator?
- Which version of Visual Studio Express C++ are you using?

Did you try to compile the Bullet demos, using the original projectfiles? Does it cause the same problem?

Thanks,
Erwin

[S8N]

- Does your application overload the global 'new' operator?
- Which version of Visual Studio Express C++ are you using?

Did you try to compile the Bullet demos, using the original projectfiles? Does it cause the same problem?

Thanks,
Erwin

Hi, thanks for the help!

No, my program doesn't overload the new operator.
I'm using Microsoft Visual Studio 2005 8.0.50727.762.

Yes, I successfully compiled the Bullet libraries and demos (except for those post-build errors I mentioned previously) and was able to run the .exe's fine, I used the solution in "/msvc/8/wksbullet.sln" for compiling them. I used the libraries that appeared in "/out/release8/" afterwards for my own program and I used the files in "/src/" as my headers. Is this correct?

Does this suggest that its not a problem with the code but a problem with the IDE/project settings? If so I could try remaking my VS project again and see if that fixes it.

-Thomas

[Erwin Coumans]

Does this suggest that its not a problem with the code but a problem with the IDE/project settings? If so I could try remaking my VS project again and see if that fixes it.

Usually this means some other included headerfiles causes a conflict.

In the .cpp file you include Bullet, are there any other includes before? Can you move the Bullet include (btBulletDynamicsCommon.h) so it comes first?

If this helps, can you tell which include file causes the problem?

Hope this helps,
Erwin

[S8N]

Well, turns out I was an idiot and your first hunch was correct. I was using a technique for detecting memory leaks in my program which apparantly overrides the new operator and while it was compatible with Bullet 2.56 it wasn't with 2.66 and so caused that error, I've now disabled it and can compile it fine now (after a couple of other changes).

I do have another problem now though, my program starts off okay but whenever the player collides with the world the screen goes blank and I can't see the world anymore, they seem to be moved to a far away point. The camera co-ordinates move from (0, 0, 0) to approx: (0, +-128000, 0) or (+-128000, 0, 0) depending on what wall they collide with. I was using the example Quake 3 BSP code from 2.56 for my world collision, I'll look over the 2.66 BSP code later to see if I can see any differences and find out whats wrong. I'll post again later if I'm having problems.

One last question, do you have any suggestions/links for techniques in detecting memory leaks that is compatible with the library? It is important for me to be able to do this.

Thanks!

-Thomas

[S8N]

Okay fixed the screen disappearing issue, turns out I had the restitution on my BSP body set too high.

I've come across another problem now though, my debug drawer has stopped working and I'm not sure why. It gets assigned to the physics world and I know from using breakpoints that getDebugMode() is getting called on it everytime stepSimulation() is called but the drawLine() function doesn't seem to be getting called at all. Any idea why this could be? I've set m_debugMode to DBG_drawWireframe.

[Erwin Coumans]

Okay fixed the screen disappearing issue, turns out I had the restitution on my BSP body set too high.

I've come across another problem now though, my debug drawer has stopped working and I'm not sure why. It gets assigned to the physics world and I know from using breakpoints that getDebugMode() is getting called on it everytime stepSimulation() is called but the drawLine() function doesn't seem to be getting called at all. Any idea why this could be? I've set m_debugMode to DBG_drawWireframe.

Good to hear the issues are fixed. In the latest version of Bullet, you need to call

Code: Select all

m_dynamicsWorld->debugDrawWorld();

Hope this helps,
Erwin

[S8N]

That did the trick! Its working now.

Okay, I think I've fully updated my program to 2.66 now. Had a couple of other problems along the way, AABB overflow mainly, I think this was because I was setting localScaling for bodies to 0 in one direction then trying to scale it up afterwards and it didn't like that, I just replaced 0 with 0.00001 to fix, also one of my kinematic physics objects isn't working as it did before but I was planning on rewriting that class from scratch in a different way anyway.

Thanks for all your help!

-Thomas

[S8N]

One last question, I compared the memory usage of my newly updated program with an older build and the memory usage is much higher, 43MB compared to 16MB. Admittedly I've added a lot of functionality to my program since that build but it still seemed odd.

I stepped through the program to check for increases in memory and it seems that the majority of this (approx 31MB) is taken up by the btDefaultCollisionConfiguration object which I didn't have to create in version 2.56. Is this normal? Is there some way to reduce its usage and would there be any adverse effects to doing so?

-Thomas

[Erwin Coumans]

I stepped through the program to check for increases in memory and it seems that the majority of this (approx 31MB) is taken up by the btDefaultCollisionConfiguration object which I didn't have to create in version 2.56. Is this normal? Is there some way to reduce its usage and would there be any adverse effects to doing so?
-Thomas

It is safe to just lower the reserved memory, it is indeed overly conservative. Just pass in smaller values into btDefaultCollisionConfiguration.

Thanks,
Erwin