Box2D integration

#1

Quote:Or is there a third option?

For ODEScript, I went with the third option - Don't take TGB's physics out, just quietly ignore it. By using collision information provided by torque instead of ODE's collision detection, I was able to enjoy ODE physics without impacting the built in "physics" in TGE. If you want to use the Box2D collision detection stuff, then you may find it's worth pushing collisions with TGB objects back into TGB, but mostly if I were you I'd just ignore it altogether.

Don't make work for yourself!

ODEScript's big failing in the end was network stuff - not properly designed from the ground up to function in a networked environment. TGB being what TGB is, you don't have to worry about that, so Box2d should be a lot better in TGB than ODE ever was in TGE. There was a time when ODEScript worked great with torque2d, but torque2d as it was then is long in the past.

Just my .02

Gary (-;

#2 We are also thinking about inlcuding Box2d into TGB. Allthough we don't (necessary) want more advanced phyiscs stuff then the built in physics can do, we noticed that most of our processors work is spent for collision checking and physics calculation allthough there isn't too mcuh stuff going on. So we think that using Box2d for that stuff might bring us better performance.
Do you guys think that assumption is true and will a goal like this require a complete swap of the collision system in the engine rather then just ignoring the TGB part and using box2d ontop of it?

#3 Man, i have been thinking about trying this for ages, but my c++ skills would not be up to it ( i am having trouble getting physx in to tgea 1.70), but i would try!

box2d is awsome, even in the flash version!

Patrick, if you get this working would you be willing to make your intergration available? box 2d would make the upgrade to tgb pro well worth it, and i could finally work on the game i have been wanting to create!..... that would make me smile :)

good luck, keep us posted.

Neil.

#4 @Gary
Sorry for the late response - I'm trying finish my masters degree and get a journal article published for the last week. I'm all for doing as little work as possible! My current plan is to mirror the TGB world in a Box2D world and selectively use physics and collision from either system.

@AYIM
I don't whether Box2D is necessarily faster. With the exception of trigger volumes, my projects have been either render or script bound. My principle reason for Box2D is strictly some of the more advanced dynamic systems.

@Neil
My C++ skills are pretty weak, but I'm going to do my best! If I get it working, I'll definitely make it available as a resource.

#5 I'm a little skeptical that a little 1 mb physics engine is going to be better than TGB's physics system, but I am willing to try and integrate it into TGB and see what happens.

The only C++ I've done is changing the icon of TGB. I'm guessing I won't be able to do this. ;D

#6 You can't really compare Box2D with TGBs physics engine and come up with something useful. TGB can't match the rigid-body physics sophistication of Box2D nor does it try to. I'm very familiar with Box2D and it's simply an awesome bit of code, as is the Chipmunk engine (albeit without CCD and Sleeping).

In tests Chipmunk comes out slightly faster (in my opinion) but is beaten hands-down by the features of Box2D (in my opinion).

If you want a sophisticated rigid-body simulation then TGB cannot currently provide that but it does provide a fast and comprehensive set of picking, collision detection and collision response routines required for a myriad of game scenarios. Sure there's been a handful of issues but part of its problem is that it offers so many collision detection and response parameters that its easy to screw things up. It's also true that there have been several issues inherent in the engine (which have hopefully now been solved) that have not helped either.

That's my sales speak but it also happens to be the honest truth. :)

Melv.

#7 Kevin,
I agree with Melv - stock TGB is good for basic physics and collisions. However, for my game design, the collision system is enough, but it calls for more robust rigid bodies and advanced systems such as dynamic rope bridges, complex gear systems, etc. I could write these systems into TGB from scratch using C++ (I have tried doing it in TS), but I think it will be easier to bring in another physics system. I pretty busy this week, but I'm hoping to make progress next week.

#8 All my skepticism has been washed away in a flood of pure amazement. At first, I wasn't too impressed with the Box2D demos, but then I started to see chains, rope bridges, rag dolls and gears interact with each other realistically. That's when I needed to wipe the drool from my face.

Thanks for the perspective, Melv. As you know, I've encountered some of those issues, but I'm pretty confident that they've been resolved with the release of 1.7.3 -- for which I am greatly thankful to you. Of course, I'd appreciate any advice you'd be willing to give. Should we try and replace TGB's system with Box2D's, or should we just combine them? Forgive me for my ignorance; as I have said, I have no practical experience with C++ ;)

Patrick,

Cool, man! I can't wait to see what you come up with! However, I'll try my own hand at integrating Box2D into TGB as well. Mostly for the experience, I'm trying not to expect any success. The possibilities are too tantalizing.

#9 The more I learn about C++ and the more I look at code from TGB and Box2D: the more I realize I have no idea what I'm doing!

#10 I started working on this a bit today. I got box2D added to the t2d solution as its own project and got the source files in place. I am getting some errors that "new" is already defined.

I'm guessing I can get around this by defining TORQUE_DISABLE_MEMORY_MANAGER, but I don't really get why this would class with box2d anyway, and could this cause other issues if I disable the memory manager?

Next I'll see about making a b2d-ified t2dSceneObject.

#11 Ok this is rather frustrating ... heres my error output

1>------ Build started: Project: TorqueGameBuilder, Configuration: Release Win32 ------
1>Linking...
1>box2d.lib(b2World.obj) : error LNK2005: "void * __cdecl operator new(unsigned int,void *)" (??2@YAPAXIPAX@Z) already defined in winMemory.obj
1>box2d.lib(b2Shape.obj) : error LNK2005: "void * __cdecl operator new(unsigned int,void *)" (??2@YAPAXIPAX@Z) already defined in winMemory.obj
1>box2d.lib(b2Joint.obj) : error LNK2005: "void * __cdecl operator new(unsigned int,void *)" (??2@YAPAXIPAX@Z) already defined in winMemory.obj
1>box2d.lib(b2PolyContact.obj) : error LNK2005: "void * __cdecl operator new(unsigned int,void *)" (??2@YAPAXIPAX@Z) already defined in winMemory.obj
1>box2d.lib(b2CircleContact.obj) : error LNK2005: "void * __cdecl operator new(unsigned int,void *)" (??2@YAPAXIPAX@Z) already defined in winMemory.obj
1>box2d.lib(b2PolyAndCircleContact.obj) : error LNK2005: "void * __cdecl operator new(unsigned int,void *)" (??2@YAPAXIPAX@Z) already defined in winMemory.obj
1>../../../tgb/TorqueGameBuilder.exe : fatal error LNK1169: one or more multiply defined symbols found

This only occurs when I try to include a b2d header into a source file of the TorqueGameBuilder project.
Well, heres my source file mytest.cpp

#include "Box2D.h"

void b2Test()
{
   b2AABB aabb;
   b2World *myWorld = new b2World( aabb, b2Vec2(-100,100), true );

   delete myWorld;   
}

Adding the preprocessor define TORQUE_DISABLE_MEMORY_MANAGER didn't seem to make a difference, except for requiring a full rebuild '-(

#12 Well for now I have it at least building by using /FORCE ...

I wonder if it is better to try modifying t2dSceneGraph and t2dSceneObject or to instead create new b2d specific classes ... seems like it would be a good idea to keep all the derived classes of t2dSceneObject working, else i would only have a box2D object in torque that doesn't render!

I guess this is where a physics interface or component that is used by all t2d classes (that could be replaced) would be useful.

Well, brainstorming ways to continue ...

Pull the physics specific code out of t2dsceneObject while leaving other important things ...

If the existing t2d classes represent the "rendered" object in the game, and this can be completely separated from the "physics" representation ... well that would be the goal. I don't see a good way to do this without destroying the existing classes.

The current t2d classes have to be preserved (in name at least) for any of this to work in the editor without a lot of extra work. Then again, if creating and modifying box2D objects only worked from script, that might be ok for a simplistic integration.

Perhaps a behavior could be created that represents "this is a box2D object". If it could turn off normal physics and add it to the box2D world and handle updating the physics results. This could potentially allow keeping all the existing features of the various t2d classes, and the behavior fields would allow you to tweak and create box2D objects within the editor.

But could that really work? I will have to look into if a special behavior can be subclassed in C++, and if it possible to redirect or disable the normal object processing and still perform interpolation and other necessities using the box2D physics results ....

#13 I decided to go the route of making entirely new classes for box2d integration. Right now I have...

b2dSceneWindow, place this in your gui instead of a t2dSceneWindow if you want to use box2D
SimB2World - Is used rather than a t2dSceneGraph, is attached to a b2dSceneWindow
SimB2Body - a simobject containing a b2Body pointer, is added to the b2World

This is currently in a "compiling" state, but the b2dSceneWindow methods for rendering are mostly all commented out at the moment.

The SimB2World class can create a b2World object but does not have the code for ticking it.

The SimB2Body class can create a b2Body object but does not have code for rendering it (which will be taken from t2dStaticSprite most likely).

#14 Well the previous approach "was" the fastest way to get a b2World with b2Body(s) created in Torque, at least in C++ with no rendering. But I'm starting to rethink the "total" replacement of t2dSceneObject.

Perhaps t2dSceneObject can modified so that its "getParentPhysics" returns a b2dPhysics object rather than a t2dPhysics object. This b2dPhysics object could implement many of the same accessors and mutators which t2dSceneObject currently has exposed to script (like setLinearVelocity, getPosition, ... ). And it could handle requests by the sceneWindow (or what it graph) to get the "render" position, and the interpolated postion.

t2dSceneGraph currently loops through all t2dSceneObjects and "ticks" them each to simulate physics. If this is contained within a b2World, then this needs to be replaced with a call to simulate the b2World. Then as long as the b2Physics object pointed to by the modified-sceneobject can handle requests for the render/interpolated postion, rendering should work properly...

#15 Hi james,

did you consider to use the t2dPhysics class as a interface for a box2d class? t2dPhysics handles (as far as i have seen) every aspect of physics and collision regarding an individual object (every t2dSceneObject has a t2dPhysics * parentPhysics). so maybe you could replace this class by a e.g. b2dPhysics * parentPhysics, which has the same interface (as far as it makes sense). this way you wouldnt need to change that much in the rest of the system.
you could still use the tick and interpolations system and keep the t2dSceneWindow and t2dScenegraph classes.

allthebest,
peter

#16 Oh nothing new to you :)

#17 Thanks, at least a second opinion im headed the right way. We even came up with the same name for the new physics class (b2dPhysics) '-)

#18 James/AYIM,
Your approach sounds good so far! My tack so far is a little different - I am creating a seperate b2world for each scenegraph. Whenever a sceneobject is added to the scenegraph, I am creating a b2 object that mimics the sceneobjecct. So, for example, changing the collision polygon in the TGB editor will change the b2 object as well. The plan is that on each tick, I'll simulate both the scenegraph and the b2worlds. Objects will have the option to send/receive collision and physics information from the box2d world.

#19 Patrick

I'll keep trying the "replace t2dPhysics" approach for a bit and see how it goes; I like the sound of what you are doing as well though.

By the way, did you have issues with "multiple definitions of the 'new' symbol"? I mentioned the link errors I was getting a few posts up and never really figured out how to fix it -- im just using /FORCE for now. I assume it has to do with the memory manager but TORQUE_DISABLE_MEMORY_MANAGER did not resolve the errors.

#20 There is a post about making STL compatible with the torque memory manager, so it wouldnt be neccessary to disable it:

http://www.garagegames.com/index.php?sec=mg&mod=resource&page=view&qid=7480

if this doesnt work there is a post about how to fix the disable macro:

http://www.garagegames.com/index.php?sec=mg&mod=resource&page=view&qid=6190

i hope any of the above works in 1.7.3