Rigid body Physics status

#41 You right Melv.
I get wrong by thinking that TGB will have full rigid body features and that partially due to the first features pages publicity when I buy my License long time ago with pre-ordering support and when everybody was on buzz with Rigid Body.

Fully integrate Box2d inside TGB would be the ULTIMATE feature but unfortunately it's way out of my scoop. Trying to understand thousand lines of someone esle code is not an easy task.

Maybe I didn't lost 2 years on my project. Maybe... or Maybe GG had to rethink his communication. I mean look at all these hidden forum parts, ambiguous community ressources pages or chaotic blog "official~unofficial" news system. Even the tutorial(s) ! You don't know if they are valid for your version of TGB and I seriously doubt that they all will be finished one day...

I respect all that work done with and for TGB and I found it's a great and powerfull tool for particular games.
But since 3 years know I found it's always the same problems that keeps me not to choosing it.

#42 @Rivage -

Quote:You don't know if they are valid for your version of TGB and I seriously doubt that they all will be finished one day...

I'll take exception to that remark. I am modifying the official tutorials to reflect which version they work for, and any tutorial I put my hands on will be finished. All past gripes about documentation for all the engines will be completely destroyed by the time I'm firing on all pistons.

#43 Would these fixes work in TGEA/TGE as well? I'd like to have a simple physics solution for use in my game that didn't result in exploding velocities.

#44 I'm sorry to hear that TGB isn't the perfect fit for you, I really am. The honest truth is that the rigid-body response became a very popular thing to have and when people started wanting it to do resting contacts was when people became aware of its limitations. Over the last few years we've had several problems related to the collision system and lots of people associated those with the "broken" rigid-body response when of course it wasn't broken, it just wasn't all that sophisticated.

The recent fixes were targetted at the core collision system though unfortunately.

There have been numerous discussions over adding in a solid rigid-body solution whether that be home grown or more than likely something like chipmunk or box2d. The problem here is that it's not easy to just merge the two and keep all the existing functionality. Box2d can only achieve what it does well by constraining things such as masses, sizes, velocities etc. TGB doesn't do that and it's hard to have a fully TGB interactive object that supports Box2D.

There are different ways of approaching this and I've spoken about this many times but it'd be much easier if we were supporting only rigid-body (like Box2D) does. Supporting many different collision responses is much, much harder especially when you're doing that on an existing code-base with existing people who are not bothered about rigid-body.

Looking back, would I build TGB differently? Absolutely! For starters I wouldn't use inheritance like I did and go for a more composite model, especially in the physics. I'd also use several different design patterns that would enable integrating something like Box2D on objects much easier. What's done is done but ignoring rigid-body, it's still a very good solution for many, many people.

If someone wants to incorporate Box2D into TGB then perhaps what's a limitation could become a money making opportunity!

Just trying to see good in bad. :)

@Andy: I don't quite follow.


Melv.

#45 @Michael Perry
That's a very good news then !
Documentation and clarification are the key for learning new tools though I must admit that lately a very good work has been achieved with documentation.

@Melv
Perhaps TGB isn't suitable for this specific case and that easy to understand since I was constantly comparing both physics engine which is impossible.
But as soon as I'm comfortable with TGB and find possible to build a scenario with it, I probably won't hesitate since TGB tools are just great.

#46 If you need any help or advice then please just buzz.

Melv.

#47 Hi,

I have created a Box2D wrapper for TGB as part of a project at university. t2dSceneObjects and derivates can be made to Box2D bodies and shapes via behaviors in the editor. The wrapper does not replace TGB's physics and collision systems though. They are just ignored mostly - object picking is still present for example. I am currently writing documentation for it as part of my bachelor thesis which I plan to release as soon as it is done. Although the money making idea isn't bad either :P

-Michael

#48 Michael,

That's good to hear. I did a similar thing for my personal exploration of Box2D, nothing official. I'd love to see that thesis! if there's any way I can help in that respect then please send me a private email my friend.

Melv.

#49 @Melv - I am assuming the code base for rigidbody for TGB and TGE/TGEA is the same. My question is, with your fixes work with TGE/TGEA as well because I want to have some physics controlling the debris objects in my game, and I can't have them jumping around and flying off randomly.

#50 The physics in TGB is for TGB, not for TGE/TGEA. TGB inherits alot of core services from TGE such as audio, console, GUI, network etc. TGB then adds its own stuff such as collision-detection, physics, scene-graph, mounting etc.

The "jumping around and flying off randomly" issues were the aim of the physics fixes and I've seen those mostly solved with few exceptions. These have *nothing* whatsoever to do with the rigid-body collision response. Also, to say it again, we haven't really got a full rigid-body physic implementation, we've got a single function that provides a basic rigid-body response, that's all. :)

People keep lumping the fact that we've only got a basic rigid-body physics (have jitter, can't do stacking etc) with some collision detection issues that were hopefully fixed. I believe this is simply because people now just use the word physics and collision to mean rigid-body physics/collision when of course they're not necessarily the same thing.

It looks like Michael may have something for you guys in the near future, you never know. I could certainly implement Box2D into TGB but doing it as a supported part of the product wouldn't be easy.

Let me clarify something though ... TGB *is* under heavy development, it's not idle and we're very keen to address issues such as the ones raised in this thread.

Melv.

#51 Michael your thesis could be one of the best add'on for TGB around !

And more
If your wrapper is around the last Box2D version with documentation, good use of the TGB environment and Tools, it probably worth a little money support ^^

It all depends on quality !
I can't wait for a little Demo :)

#52 I put together a very basic demo for your download pleasure:

http://www.unet.univie.ac.at/~a0402917/TGB%20Box2D.zip

A good team is definitely capable of creating a real game with this wrapper. But it would probably be hard to retrofit an existing source base.

Melv, I'll send you a sneak peek on the part about the wrapper but don't expect it too soon ;)

-Michael

#53 @Michael
Sweet !
I hope you will success with your thesis and produce a robust wrapper to enhance our gameplay :)
Don't hesitate to make some noise on this thread when you need beta testing or else !

#54 Michael,

Your TGB demo is . . . how should I say it? . . . . . . FREEAAAKING SWEET!

Seriously, its amazing and I hope to play around with a moddable version whether I have to pay for it or not.

#55 While Michaels demo is very nice indeed, I have to say there are many more ways in which TGB can, and should, improve before considering something like Box2D integration. For one, the audio sub system needs some more work and people have been talking about this for quite some time? More general usability and interface improvements would also be very welcome. My point is: TGB needs to improve on the basics of game development and continue on it's way to becoming the top of its class for game development before implementing something that is only used in a subset of game designs.

#56 @Melv All of your responses are professional and they do explain the situation quite well. I like how there have been a few cost/benefit analysis posts. I know you, other associates and GarageGames in general have this issue in front and are addressing in a way that makes sense for all parties. I will move forward with game development where rigid body collision responses are not included....holding onto hope that TGB will have an excellent solution for this one day.

@Michael As for the Box2D wrapper, add another person to the list that is interested in your success in that arena.

#57 Another idea I meant to mention was Verlet integration. I think it is a simple and performant solution to get a physics collision response (that can be used to have rigid and/or blob-like responses). I know the collision detection system in TGB is already excellent and performant and configurable, but I do not know how feasible the mixing of TGB collision detection with Verlet integration collision response is...probably doable.

I created a 2D physics engine in Java for games that uses Verlet integration. I only mention it because I have a demo (http://simpull2core.sourceforge.net) that shows the performance is pretty good, even for Java, and sitting atop a non-hardware accelerated rendering engine - PulpCore (http://www.interactivepulp.com/pulpcore/).

The way I achieved rigid-body (like) collision responses in my test scenes was through the use of circle particles (quicker collision detection) connected with inelastic joints (although the are called Springs, I set the elasticity to 0). The way I did it, the rigid bodies could be of any shape (convex or concave), which is better than what TGB offers now. Additionally, it fits right in with the points that are used in TGB now to define the collision shape of an object.

I also used my engine to create blobs that jiggle around when collisions occurred. It was quite cool...think Gish and Roco Loco!

One thing I did not implement was the ability to only have a one way collision on the rectangular bodies. I mention that because platformers use one-way collision for platforms much of the time.

I thought this might be a solution that would require less time to integrate into TGB than something like Box2D and it would be less code overall as well. Moreover, you can look at the demo of Simpull to know the physics look good!

#58 Wes,

I don't agree. How can you suggest that TGB's audio system be improved when Michael stands on the brink of giving TGB some truly intricate physics? Sure, maybe only a subset of games would use these physics, but 2D games today are all about realistic physics simulation, unless you're making a puzzle game -- and right now, TGB is perfect for puzzle games and very unadjusted for platformers. This would be a shift towards a more balanced game engine.

#59 Kevin,

I think the problem here is opinion. What's important to one isn't important to others.

I would like to mention that my recent blog on radically improving TGB gives hints at major work to improve the TGB experience. In polls, physics wasn't that high up on the list and that was general physics, not just rigid-body physics.

With that said, we are well aware of one important fact, we need to be able to allow anyone to hook in third-party physics. You can then see that after that it'd be easy for us to provide examples or even supply support for Box2D / Chipmunk etc.

BTW: Here's a video I dig out of my work when I was playing with Box2D in TGB. I hooked-up the sleep/wake processing and had the mouse add random velocities when I clicked.

Box2D Integration Test.

A few notes here: these objects only interacted with each other, they wouldn't interact with non-box2D objects. Also, they didn't support picking/mounting although adding mounting would be easy but it would've been using Box2D's own constructs not TGBs. All in all, a few days work but hardly useful when you consider it's not integrated into the editor and major chunks of TGB functionality cannot easily be supported as they cannot easily coexist or communicate with Box2D.

Non of the above is supported by GG or is an indication that GG is working on integrating Box2D into TGB right now.

Melv.

#60 Indeed, my friend.

Darn, I must have missed the polls. I don't remember anything like that. Well, I am undone because GG is undoubtedly going to go with what research suggests as most needed area to improve. At least TGB is great anyway, it'd just be amazing and useful (to me) to have a really intricate physics simulation on top of everything.

Cool video, Melv. I'm going to ignore your disclaimer at the bottom and start whining about where to find the box2d physics in TGB.