"Tower of Goo" type of physics in TGB
by Steven Smith · in Torque Game Builder · 06/29/2009 (3:03 pm) · 17 replies
Is it possible to make "Tower of Goo" type of physics in TGB?
#2
06/30/2009 (5:34 am)
You could mount objects (layers of the christmas tree) together, and give each of them a certain amount of rotation over time.
#3
07/05/2009 (6:21 pm)
Look into Verlet contraints/integration systems. These are pretty simple to implement and might get you some of the way there, but will require a bit of tweaking/alteration on your part. I implement a system in Flash for a driving game recently and it worked pretty well. 
#4
To be fair, nobody insisted on anything. Applying something like Box2D would completely change TGB. It just isn't something you can bolt on with loosing a bunch of stuff. For a very long time the collision/physics system has been more than adequate for a huge variety of games. TGB never has been a pure rigid/soft body system.
Also, it's not about optimization. You can perform crazy amounts of non-rigid-body collision detection and response in TGB and the performance is good and I certainly wouldn't say it's not optimized. It just isn't a rigid-body system with the iterative solvers and other systems that are required.
Many years after the development of TGB, physics systems have become very popular and make this kind of thing relatively easy but these have mainly come along after the fact and it's been very difficult to know how to use those systems without a complete revamp of the internals and breaking much of what exists of functionality, documentation, tutorials etc.
For the future, using a 3rd party solution is the way we want to go and certainly no home-baked solution.
07/06/2009 (11:16 am)
Marc,To be fair, nobody insisted on anything. Applying something like Box2D would completely change TGB. It just isn't something you can bolt on with loosing a bunch of stuff. For a very long time the collision/physics system has been more than adequate for a huge variety of games. TGB never has been a pure rigid/soft body system.
Also, it's not about optimization. You can perform crazy amounts of non-rigid-body collision detection and response in TGB and the performance is good and I certainly wouldn't say it's not optimized. It just isn't a rigid-body system with the iterative solvers and other systems that are required.
Many years after the development of TGB, physics systems have become very popular and make this kind of thing relatively easy but these have mainly come along after the fact and it's been very difficult to know how to use those systems without a complete revamp of the internals and breaking much of what exists of functionality, documentation, tutorials etc.
For the future, using a 3rd party solution is the way we want to go and certainly no home-baked solution.
#5
It is true that the devs did not do it on purpose, but to give my two cents to this conversion, I would have to say the physics are horrible for rigid/soft body in TGB. Absolutely poor considering how much work went into it.
The collision in TGB is very inaccurate. If you look through many threads, you will see how many problems people run into due to bad collision detection. Rigid bodies also go out of control when they collide into each other. I have not really used soft body physics yet, but I hear things about that too.
So far, physics would have to make it second on my list of things that need to be added/improved:
1. Shader support
2. Physics
3. Collision
4. Networking
07/06/2009 (1:30 pm)
@MelvIt is true that the devs did not do it on purpose, but to give my two cents to this conversion, I would have to say the physics are horrible for rigid/soft body in TGB. Absolutely poor considering how much work went into it.
The collision in TGB is very inaccurate. If you look through many threads, you will see how many problems people run into due to bad collision detection. Rigid bodies also go out of control when they collide into each other. I have not really used soft body physics yet, but I hear things about that too.
So far, physics would have to make it second on my list of things that need to be added/improved:
1. Shader support
2. Physics
3. Collision
4. Networking
#6
If you ever find a thread where I have said anything else then please kick me. I have tried to balance the requirements of a rigid-body system without having to massively change the existing API. You also have to remember that such a significant change isn't something that I can just personally launch into. There are many, many factors to consider including changes to the level-builder and other systems which as you can imagine requires a lot of collaboration internally.
In terms of collision detection problems, there's an equal amount of threads with collision problems in the Box2D forums, the bullet forums etc. It's the way code goes.
I have found that a majority of the issues are nothing to do with collision-detection (which itself has nothing to do with the rigid-body response) but nearly always to do with people using the rigid-body response and configuring it using crazy mismatched forces. I also find that a majority of people don't split up the collision detection from the physics and just call it physics.
I am NOT saying that the rigid-body is perfect, nor am I saying that anyone struggling with it are somehow doing something fundamentally wrong nor am I saying that the jist of what you're saying is wrong either e.g. a paying customer expecting the most from their investment.
For many years I wanted to remove the rigid-body response (and it is JUST a collision-response, not a fundamental feature of the engine).
I have personally looked at Box2D as a feature but it does come at a price in many areas. For instance, the picking is limited, networking it would be extremely difficult, you can't easily resize objects, you need to deal with the fact that the physical areas and forces have strict limits, so on and so forth. It certainly wouldn't be TGB as normal. It'd be a whole new ball-game with new rules on what you can and cannot do. In my opinion, the result would probably be awesome.
Reading this post again I know it sounds defensive and honestly, the "tone" isn't one of annoyance on my part, just a need to clarify that time has gone by and there's a history why things turned out the way they did. We're working on changing these systems though right now so we are listening but consider that rewriting TGB so that you get realtime networking with full editor support takes time so your shopping list of shaders, networking and new physics engine is a huge task leaving something that doesn't look like the existing TGB. It takes much more time to change an existing product whilst maintaining existing resources. Eventually we'll do a clean-slate development but right now we don't have that luxury. Boy, I wish I did!
07/06/2009 (1:48 pm)
The fact that you're saying is horrible for rigid/soft body physics is odd. There is obviously no soft-body physics. The rigid-body physics equates to a single "collision response" function of 30 lines of code and NOT a rigid-body physics engine. I have said more times than I care to mention (oh so many) that the rigid-body physics is sufficient for a basic rigid-body response but will never be comparible to a dedicated rigid-body solution with iterative solvers etc. As soon as you start pushing objects together you'll expose the fact that the contacts are not iteratively solved. It was NEVER meant to be able to perform stacking or resolve multiple resting contacts. I have NEVER personally said it would nor have I ever been involved in claiming it can. If you want to use it for an asteroids style game where the asteroids response in a rigid-body way then it'll be perfect. If however you want to use it for a platformer with lots of stacking and resting-contacts then forget it.If you ever find a thread where I have said anything else then please kick me. I have tried to balance the requirements of a rigid-body system without having to massively change the existing API. You also have to remember that such a significant change isn't something that I can just personally launch into. There are many, many factors to consider including changes to the level-builder and other systems which as you can imagine requires a lot of collaboration internally.
In terms of collision detection problems, there's an equal amount of threads with collision problems in the Box2D forums, the bullet forums etc. It's the way code goes.
I have found that a majority of the issues are nothing to do with collision-detection (which itself has nothing to do with the rigid-body response) but nearly always to do with people using the rigid-body response and configuring it using crazy mismatched forces. I also find that a majority of people don't split up the collision detection from the physics and just call it physics.
I am NOT saying that the rigid-body is perfect, nor am I saying that anyone struggling with it are somehow doing something fundamentally wrong nor am I saying that the jist of what you're saying is wrong either e.g. a paying customer expecting the most from their investment.
For many years I wanted to remove the rigid-body response (and it is JUST a collision-response, not a fundamental feature of the engine).
I have personally looked at Box2D as a feature but it does come at a price in many areas. For instance, the picking is limited, networking it would be extremely difficult, you can't easily resize objects, you need to deal with the fact that the physical areas and forces have strict limits, so on and so forth. It certainly wouldn't be TGB as normal. It'd be a whole new ball-game with new rules on what you can and cannot do. In my opinion, the result would probably be awesome.
Reading this post again I know it sounds defensive and honestly, the "tone" isn't one of annoyance on my part, just a need to clarify that time has gone by and there's a history why things turned out the way they did. We're working on changing these systems though right now so we are listening but consider that rewriting TGB so that you get realtime networking with full editor support takes time so your shopping list of shaders, networking and new physics engine is a huge task leaving something that doesn't look like the existing TGB. It takes much more time to change an existing product whilst maintaining existing resources. Eventually we'll do a clean-slate development but right now we don't have that luxury. Boy, I wish I did!
#7
07/07/2009 (10:19 am)
@Melv: I really wish T2D would get a much deserved upgrade. Believe it or not, but some of us are still using it. I see a greater potential in T2B than I do in T3D, because of the appeal to smaller groups and hobbiests.
#8
07/07/2009 (10:40 am)
I agree with Teromous... The collision and physics deserve a good upgrade. I don't know what you use for your physics, but it is glitchy for the most of us...
#9
I get up now and spend 8-12 hours a day on T2D so it's definately moving forward now. Before that I was spending that much a week!
07/07/2009 (11:18 am)
Well it's a good job that I'm now full-time rather than producing TGB in my spare-time! :)I get up now and spend 8-12 hours a day on T2D so it's definately moving forward now. Before that I was spending that much a week!
#10
Sure there are issues, but when you say Collision and Physics need to be improved, you don't offer much help on what exactly needs to be improved on in the current systems. This thread was asking for a "Tower of Goo" type physics solution in TGB. The reality is that if you want to make a physics based game, you look for a physics engine first. TGB has never attempted suggest that it is this, take a look at the product page:
Like I said, it is a basic system which tries to cater for as many scenarios as possible - and if you check out how many games people have made with TGB, you'll see that very few require such a complex physics solution.
07/07/2009 (3:14 pm)
I think everyone is far to critical of Collision and Physics in TGB. There is no *one* solution that meets everybody's requirements and no solution is perfect. TGB does exactly what it is meant to do, provide a fast, effcient and easy to use solution which caters for as many people as possible.Sure there are issues, but when you say Collision and Physics need to be improved, you don't offer much help on what exactly needs to be improved on in the current systems. This thread was asking for a "Tower of Goo" type physics solution in TGB. The reality is that if you want to make a physics based game, you look for a physics engine first. TGB has never attempted suggest that it is this, take a look at the product page:
Quote:
Physics
TGB physics are modeled after real-world Newtonian physics. Apply inertia, linear velocity, angular velocity, friction, restitution, relaxation, damping, or a number of other physical attributes to your object and watch it handle interactive collision with perfect scaling.
Like I said, it is a basic system which tries to cater for as many scenarios as possible - and if you check out how many games people have made with TGB, you'll see that very few require such a complex physics solution.
#11
It's the only missing feature that push me to write my very own cross-platform engine in very short time.
My game is nearly done now, working so hard to overcome every "nowadays essential" missing features (to me) learn me that creating tools for most basic features wasn't that hard and obviously give me way more flexibility than TGB will ever offer even with his unmanageable monstrous sources.
I'm not saying I will never use TGB cool tools for fast prototyping or static/simple-play games but never for original and tremendous games like Gish, World of Goo, LocoRoco, etc. you get the point.
It's not because adding a Physical or Networking system in your engine is hard that it shouldn't be part of your ToDo List!
I'm sure Broken scenarios like Networking impossible with this or that features is something most of us could understand and go with it.
When I buy TGB at that time Torque 2D, your advertising about that features was surfing over the wave of the physics games and that's why I must admit I didn't choose wisely this engine.
Don't get me wrong :
Now I see you are making progress on the way you inform people by opening privates forum which is a good thing but at that time it wasn't like that. Informations on this features was biased at the very beginning !
Excuse my impertinence Phillip but giving the fact that most of games people have made with TGB aren't physics based is a bit demagogic since TGB can't correctly handle them. But you are right about the physics engine line : How to start a project without the right tools ?
You know what's people want the most now :)
Dig it ?
By the way : I return from time to time on this website to see if TGB Major updates and can't see anything relevant easily and wasting my time. Could you inform the web designer on this ? I don't give a think about most of the Blog post, just want to get inform on the latest news of my selected engine.
Still 1.7.4 anyway
to bad...
07/08/2009 (3:09 pm)
TGB need a huge improvement on this point since a very long time now...It's the only missing feature that push me to write my very own cross-platform engine in very short time.
My game is nearly done now, working so hard to overcome every "nowadays essential" missing features (to me) learn me that creating tools for most basic features wasn't that hard and obviously give me way more flexibility than TGB will ever offer even with his unmanageable monstrous sources.
I'm not saying I will never use TGB cool tools for fast prototyping or static/simple-play games but never for original and tremendous games like Gish, World of Goo, LocoRoco, etc. you get the point.
It's not because adding a Physical or Networking system in your engine is hard that it shouldn't be part of your ToDo List!
I'm sure Broken scenarios like Networking impossible with this or that features is something most of us could understand and go with it.
When I buy TGB at that time Torque 2D, your advertising about that features was surfing over the wave of the physics games and that's why I must admit I didn't choose wisely this engine.
Don't get me wrong :
Now I see you are making progress on the way you inform people by opening privates forum which is a good thing but at that time it wasn't like that. Informations on this features was biased at the very beginning !
Excuse my impertinence Phillip but giving the fact that most of games people have made with TGB aren't physics based is a bit demagogic since TGB can't correctly handle them. But you are right about the physics engine line : How to start a project without the right tools ?
You know what's people want the most now :)
Dig it ?
By the way : I return from time to time on this website to see if TGB Major updates and can't see anything relevant easily and wasting my time. Could you inform the web designer on this ? I don't give a think about most of the Blog post, just want to get inform on the latest news of my selected engine.
Still 1.7.4 anyway
to bad...
#12
Please do keep an eye out in the future, as Torque 2D begins to make an appearance.
Thanks.
07/08/2009 (3:13 pm)
Rivage, you can follow GarageGames on Twitter now, along with the Newsletter and RSS feeds. If you just need to get information on updates to TGB or new releases, those would be good choices for you to stay informed.Please do keep an eye out in the future, as Torque 2D begins to make an appearance.
Thanks.
#13
This is cool, after T3D is finished, then T2D will be in development... Here's hoping for shader support!
07/08/2009 (4:08 pm)
Torque 3D and Torque 2D will be the new line-up engines for GG?This is cool, after T3D is finished, then T2D will be in development... Here's hoping for shader support!
#14
It will be awesome though, I can tell you that.
07/08/2009 (4:21 pm)
Torque 2D has been being developed for a while now, we just aren't quite ready to talk about it just yet :)It will be awesome though, I can tell you that.
#15
07/08/2009 (9:54 pm)
Screenies or you are lying! (this is how you get info about something supposedly to be a secret)...
#16
It really is exciting stuff!
07/08/2009 (9:56 pm)
Tyler, GG are going to Casual Connect with an alpha build of Torque 2D next week! I think you guys will start to see some information once the convention is over.It really is exciting stuff!
#17
www.garagegames.com/community/forums/viewthread/83463
07/24/2009 (12:38 am)
For those who haven't seen this thread which is related:www.garagegames.com/community/forums/viewthread/83463
Torque 3D Owner Marc 'Dreamora' Schaerer
Gayasoft
TGB has a pretty rudimentary physics system thats not really optimized for such large linear systems.
The devs insisted on keeping this broken and slow system instead of replacing it with one of the freely available, stronger and much more performant systems (chipmunks physics, box2d and a few others), at least so far.
Perhaps T2D will get an as well designed core as T3D which would allow users to pretty easily replace systems