Torque 2D Development Blog - 2D Model Overview
by Melv May · 11/10/2009 (8:26 pm) · 32 comments

Welcome to another entry in the Torque 2D Development Blog series. In the last blog we announced that our new 2D engine would use Box2D as the physics core, inheriting all the physics goodness that it provides. Today we want to give you more detail on both how and why we did this.
Rigid Body Physics
Rigid-Body physics in games has become extremely popular in recent years, not simply because it adds great game dynamics but also because it can make the task for developers easier. It is far simpler to configure a vehicle to work very much like it would in the real world and draw on that knowledge than it is to try to fake every aspect of its movement. This is particularly true when the vehicle has to interact with its environment in realistic and convincing ways. Having a unified way to do that for all game entities simply makes development easier. Previously, we implemented our own physics solutions, but there are now so many great 3rd party physics solutions out there that it makes sense to work with them.As we've already announced, we chose Box2D which provides pretty much all the features you'd like to see in any realistic 2D physics simulation. When we started looking at Box2D, however, it became pretty obvious that we couldn't just “plug” it into the existing codebase. That was one of the many reasons why we chose to develop a new Torque 2D from the ground up.
So what does the physics look like in Torque 2D? Well, the first thing to point out is that we've hidden away Box2D from the end-user. Sure, you can drill down to Box2D if you want but there's no need to do so. The reason we chose to do this is three-fold:
- Abstract away from some of the confusing aspects of Box2D, which is especially important for new users.
- Provide the ability to unify the way all aspects of Torque 2D are controlled, e.g. physics, rendering, sound-fx etc.
- Provide the ability to extend Torque 2D in a unified way.
2D Model
In doing this, the 2D Model was born. Now we're sure this immediately puts the thought of 3D Models into your mind. The good news is that this is exactly what it is! Torque 2D has its own 2D equivalent of a 3D Model. This means that inside the model you can have all the features provided by Torque 2D such as collision-detection, rendering, joints, pathing, sound-fx, particles, text etc. These 2D Model features are represented by things called Model Nodes. These nodes are arranged into a hierarchy meaning that some nodes are children to other nodes. To give you a sense of how powerful and flexible the 2D model is, consider that the “Apocalypse” demo shown in the last blog was done using a SINGLE model!Now as crazy as that sounds, it should give you an idea of how flexible the 2D model is! Typically though, you can think of a model as a way to encapsulate some discreet element of your game such as:
- Player Character
- Non-Player Character
- Misc Scene Item
- Vehicles
- Tile-Layers
- Etc

Bodies
A body is a point in space that can be orientated, have velocity, have mass, etc. As well as having an unlimited quantity of bodies, each can also have unlimited children nodes of any kind. These children nodes perform various tasks and live relative to the body in space so that if the body moves or changes angle, so do its child nodes. Bodies are extremely important to the 2D Model as they are the parent for all the other node types, so if you destroy a body, all its children are destroyed. Bodies also have an extremely powerful feature called "sleeping." When a body doesn't move or isn't involved in any collisions for a small period of time, it automatically goes to sleep. This has the effect of reducing its overhead to practically zero. If a body is involved in a collision or is moved either by the user or a joint, then it automatically wakes up. This happens completely automatically and results in huge performance gains when bodies are asleep.Collision-Shapes
Collision-Shape nodes allow you to add collision areas to your model. These collision-shapes not only add mass to the body and affect how the body moves/rotates, but are how reactions to collisions are configured. Currently there are two types of collision-shapes: circle and convex-polygon. Convex polygons can also be defined as a single edge only (line) and can even be configured to have one-way collision only, which is extremely useful for platformer games. As is the case with all nodes, you can have as many collision-shapes as you desire. This has the additional benefit that if you want to define concave polygons, you can by using multiple convex polygons.Collision-Shapes can also be configured so that the parent body becomes immovable. This is typically used for your level geometry. You can even configure collision-shapes so that they are "sensors" in that they report collisions, but don't cause the body to react to the collision. You can mix all these types of configuration under a single body as well if you so choose. Your player may need to collide with stuff, but it may have regions where you simply want to know if something collided. You can even detect collisions starting and collisions ending!
Render-Actions
Torque 2D abstracts rendering into what it terms Render-Actions. A render-action simply renders things to your scene. There are several types of render-action nodes including several sprite types, particle-effects, text etc. As mentioned before, you can have as many render-action nodes as you wish. This offers you a powerful way to design your game in that you can mix any render-action nodes together and create the effect you're after. As with all body children, these render-actions move/orientate with the parent body.Joints
So we've skipped many additional children nodes here (most of which will be subject of a future blog), but let's finally discuss a very important one - the Joint node. There are many types of joints and their sole purpose is to bind two bodies together in cool and interesting ways. You are not restricted to only linking bodies within the model; you are free to link any two bodies that exist in the scene, meaning you can binding multiple 2D Models together.As an example of how you can use joints, imagine that you wanted to ensure that two bodies are always a specific distance apart. To do this you could add a “Distance” joint between those two bodies. You can also configure the joint to be soft (e.g. springy) or hard (e.g. rigid), what distance you want etc. Alternately, if you wanted to have one body revolve around another, then you could use the “Revolute” joint. You could then configure the angle limits of this joint so the bodies could only rotate through specific angles. You could also activate the motor on the joint to cause it to turn one body with respect to another. You can even set the motor speed, its maximum torque and many other cool things. There are lots of joints available, each of which has a specific purpose. It is also common to use multiple joints together to create even cooler effects.
Joints are the bread and butter of interesting physics and are way too much fun to play with.
Prefabs
As you can see from above, it's possible to create 2D Models as simple or as complex as you like. Another great advantage of being able to aggregate functionality into a Model is that you can load/save them just like you would a 3D model. We call these Prefabs and they give you the ability to distribute your models between team members and/or the community. Now that's cool!All together now...
Now that we've introduced the 2D Model, here's another look at the Apocalypse demo video, but this time showing some of the elements we've described above using a cool feature we've not yet talked about called visualizers. If you look closely you'll see things waking up and going to sleep as indicated by transparency of the green lines:Performance
Obviously it is important to keep performance high and memory consumption low. Here we've addressed both. The 2D Model uses a very powerful and configurable caching factory to ensure that a balance between node creation and node memory usage is kept to a minimum.Many of the nodes are extremely lightweight and incur a tiny cost, especially when automatically retrieved from the cache. Render-Actions are particularly lightweight in that they allow you to create thousands of them without concern. Also, all rendering in Torque 2D uses a batching system to further increase performance.
The performance gains of this system, especially rendering, has allowed Torque 2D to free itself from having lots of specific types of objects such as tile-layers. Tile-layers don't exist in Torque 2D! Before you panic though, let's explain what they've been replaced with. A tile-layer can now be a single body with as many render-actions as you like. This has huge implications for people designing tile-layers and other complex game entities. You can now have any type of node in your "tile-layer" such as sprites, particle-effects, collision-shapes, sound-fx which all move together. Because the sprite render-actions and other aspects are so lightweight, they can be used as tiles. They are also not restricted by size, position or orientation - the builder will allow you to control that placement. Imagine creating a "tile-layer" that includes joints, particles, sprites etc!
As a final point to whet your apetite, Torque 2D now has a real X,Y and Z value for positioning your 2D Model nodes at depth. This Z coordinate means that you can place stuff at depth values such as 3.5 or 4.05 or any value you like. You can also place nodes at depth relative to other nodes, at the front or back of the scene! This works with Box2D in that we use metres, kilograms and seconds. We also provide comprehensive camera and construction methods to work with metres or pixels. We'll provide more on this feature and its usefulness in future blogs.
Conclusion
So as you can see, Torque 2D has a comprehensive 2D Model and puts practically no restrictions on the developer on how it is used. Anyone who knows how to use C++ can also extend the 2D Model as there is a standard way to do this that doesn't involve hours of coding.In designing Torque 2D we wanted to free users from having to deal with heavy-weight, specific-use objects but instead offer a way to almost “draw” the scene the way they want it. In offering a unified 2D Model with unlimited content, we've definitely achieved that. Almost everything in Torque 2D centers on the 2D Model so no matter what you're interested in - physics, collision-detection, rendering, sound-fx, etc. - you'll soon be at home using it.
We hope this blog has given you a taste of how everything in Torque 2D is unified. Please feel free to ask about this 2D Model and how you could use it for your next big game.
This is post #6.
Torque 2D development blogs:
- Post #1 - Real-Time Networking
- Post #2 - Expectations
- Post #3 - Integrating with Torque 3D
- Post #4 - Editor Design
- Post #5 - Box2D Overview
- Post #6 - 2D Model
- Post #7 - Coming Soon!
About the author
#22
I hate to ask an ignorant question but I'm trying to understand the implication of the change you folks have made to tile layers and the coordinate system.
For tile layers, would this mean that each individual tile can have its own collision shape and set of physics responses? I'm still new to tiles but I believe the way they're implemented you get a square for each tile as the collision shape and whatever response you've defined for the whole layer.
Also about the addition of the Z coordinate for 2d shapes: Does this mean that you could do more complex sorting that you'd get by changing the sort options in the Layer Management section of the Builder, say almost having objects sort on an object-by-object basis rather than by it's Layer number?
And with nodes having a Z dimension, does this mean you could create physics-based movement that looks as if it's moving through 3d space? For instance, could you take the Apocalypse demo and give it an isometric projection so that the chains swung not just through the X and Y but also through the Z?
Thanks and apologies in advance if these are no brainers, the full meaning just isn't clear at the moment!
11/13/2009 (3:18 pm)
Gotta start a Melv May fan club! I hate to ask an ignorant question but I'm trying to understand the implication of the change you folks have made to tile layers and the coordinate system.
For tile layers, would this mean that each individual tile can have its own collision shape and set of physics responses? I'm still new to tiles but I believe the way they're implemented you get a square for each tile as the collision shape and whatever response you've defined for the whole layer.
Also about the addition of the Z coordinate for 2d shapes: Does this mean that you could do more complex sorting that you'd get by changing the sort options in the Layer Management section of the Builder, say almost having objects sort on an object-by-object basis rather than by it's Layer number?
And with nodes having a Z dimension, does this mean you could create physics-based movement that looks as if it's moving through 3d space? For instance, could you take the Apocalypse demo and give it an isometric projection so that the chains swung not just through the X and Y but also through the Z?
Thanks and apologies in advance if these are no brainers, the full meaning just isn't clear at the moment!
#23
That's the point really: no more large monolithic t2dSceneObject type classes that have everything in. Think of the model scene-elements as very lightweight and primitive components. You connect them together however you wish.
Think of it this way; a specific platform may be composed of several render-actions at any position/size/orientation but you may choose to have only a collision-shape, such as a line (or connected lines) at the very top of the platform for objects to "walk" along. You choose where and how many you want and they are completely decoupled from the stuff that renders. The builder will obviously make this much easier.
This also means you can put collision-shapes down anywhere. This can be handy when you want to (say) have a list of collision-lines that form the ground a player might walk on but the ground is rendered using lots of different things at different depths (say).
Other modes are "Back" and "Front" which mean those scene-elements are always at the back or front of the scene respectively. Additional depth modes can (and will) be added that allow various depth usage. For instance, you may want to relate depth to the Y value or you may want to have a custom function.
11/13/2009 (3:53 pm)
Quote:For tile layers, would this mean that each individual tile can have its own collision shape and set of physics responses? I'm still new to tiles but I believe the way they're implemented you get a square for each tile as the collision shape and whatever response you've defined for the whole layer.One fundamental change to consider here is that render-actions (stuff that renders) is completely separated from collision-shapes (circles, polygons, lines). This means that you can draw your render-actions for the tiles (they don't have to be square or the same sizes) then you'll probably add the collision-shapes afterwards. Rendering and collision are not part of the same object e.g. t2dStaticSprite or t2dTileLayer etc.
That's the point really: no more large monolithic t2dSceneObject type classes that have everything in. Think of the model scene-elements as very lightweight and primitive components. You connect them together however you wish.
Think of it this way; a specific platform may be composed of several render-actions at any position/size/orientation but you may choose to have only a collision-shape, such as a line (or connected lines) at the very top of the platform for objects to "walk" along. You choose where and how many you want and they are completely decoupled from the stuff that renders. The builder will obviously make this much easier.
This also means you can put collision-shapes down anywhere. This can be handy when you want to (say) have a list of collision-lines that form the ground a player might walk on but the ground is rendered using lots of different things at different depths (say).
Quote:Also about the addition of the Z coordinate for 2d shapes: Does this mean that you could do more complex sorting that you'd get by changing the sort options in the Layer Management section of the Builder, say almost having objects sort on an object-by-object basis rather than by it's Layer number?The depth is just that, it controls the draw-order. Things drawn at larger depth are draw behind stuff with less depth. There's actually a depth-mode that every scene-element has. Typically you use "Absolute-Depth" mode. This places the scene-element at the "Depth" you specify. Other modes are "Relative-Depth" mode. This places the scene-element relative to the Model depth. It means you can have a model that centres around a specified depth but all scene-elements within it can be at relative depths.
Other modes are "Back" and "Front" which mean those scene-elements are always at the back or front of the scene respectively. Additional depth modes can (and will) be added that allow various depth usage. For instance, you may want to relate depth to the Y value or you may want to have a custom function.
Quote:And with nodes having a Z dimension, does this mean you could create physics-based movement that looks as if it's moving through 3d space? For instance, could you take the Apocalypse demo and give it an isometric projection so that the chains swung not just through the X and Y but also through the Z?No, this is a 2D engine, you'd need a 3D one for that. With that said, the physics simulation is just X/Y, T2D adds Z for rendering. There's nothing stopping anyone representing the Model in ISO or 3D. The thing to remember though is that all physics and collision is based upon X/Y only, rendering can add Z but that's all it is.
Quote:Thanks and apologies in advance if these are no brainers, the full meaning just isn't clear at the moment!No problem at all, an awful lot of work has gone into this so folks showing an interest is most rewarding in itself.
#24
11/20/2009 (4:53 pm)
So I've worked with Box2D in the past and have gotten "one-way collision" to work with it. But using my implementation there was always a problem when a body would stop moving inside a "one-way collision" shape. The body would kind of teleport to one side or the other of the "one-way collision" shape. I ended up working around this using Box2D's collision groups as well as some stuff with sensors. I was wondering if this is something that T2D/Box2D would handle on its own (using a better solution than the one I came up with) or if this is something that will occur that users might need to work around?
#25
I won't be hard wiring the solution to one-way, just providing a neat hook to this pre-solve called a contact behavior. The example behaviour that Erin shows in his latest test-bed is good but does rely on the overlap solver pushing the body through the collision shape. He uses the same hook technique to override the contact. The real problem of course is that there's no one perfect solution as a "one way" collision doesn't describe all the variations possible.
Previously, it was much more difficult to get access to this. I'm sure Phil O'Shea will refine this when it comes to getting the Platform Starter Kit up and running on the latest T2D. I wouldn't worry about that aspect. :)
11/20/2009 (4:59 pm)
I'm using the latest Box2D trunk which has all the new contact pre-solve callbacks allowing you to disable the contact using your own conditions and then apply any operation you wish (or none) to the appropriate body.I won't be hard wiring the solution to one-way, just providing a neat hook to this pre-solve called a contact behavior. The example behaviour that Erin shows in his latest test-bed is good but does rely on the overlap solver pushing the body through the collision shape. He uses the same hook technique to override the contact. The real problem of course is that there's no one perfect solution as a "one way" collision doesn't describe all the variations possible.
Previously, it was much more difficult to get access to this. I'm sure Phil O'Shea will refine this when it comes to getting the Platform Starter Kit up and running on the latest T2D. I wouldn't worry about that aspect. :)
#26
Also, in this new model system can behaviors/scripts be attached to individual bodies? For example, let's say I wanted to make a model that represents a lantern. So in this model I have a sprite Render-Action that represents the lantern's flame. Could I add a behavior to that sprite that alters the sprite's opacity to make it look like it's flickering?
11/20/2009 (6:02 pm)
Thanks, that's good to know. Also, in this new model system can behaviors/scripts be attached to individual bodies? For example, let's say I wanted to make a model that represents a lantern. So in this model I have a sprite Render-Action that represents the lantern's flame. Could I add a behavior to that sprite that alters the sprite's opacity to make it look like it's flickering?
#27
11/20/2009 (6:05 pm)
Well we're starting to get into ground that'll be covered by another blog so I'll just say yes, you'll be able to do this although not as a behavior and in a much easier/better way than you described. :)
#28
11/30/2009 (6:42 pm)
when is this comming out? pleaaaaaaaaaaaaaaaaaaaase
#29
12/14/2009 (5:22 am)
Cant wait to get my hands on this...
#30
Also, does T2D have a way of compressing the file size of resources such as graphics, music, etc...?
For browser games the final file size is very important.
Jason
01/12/2010 (8:48 pm)
So how large would a typical game file be using box2D?Also, does T2D have a way of compressing the file size of resources such as graphics, music, etc...?
For browser games the final file size is very important.
Jason
#31
In terms of a typical final size, I'm not sure that's possible to answer. I can tell you that Box2D only adds around 600Kb+. The total package size is subject to change but it should be well within the typical limits for a browser game.
01/13/2010 (3:50 am)
Torque 2D doesn't have any additional support for compression, it does have whatever Torque 3D has. I must admit to not being sure as to the state of zip-file support in Torque 3D. Because we inherit all the Torque 3D core goodness, if it's in, it'll be in Torque 2D.In terms of a typical final size, I'm not sure that's possible to answer. I can tell you that Box2D only adds around 600Kb+. The total package size is subject to change but it should be well within the typical limits for a browser game.
#32
Also, I would like to purchase the binary only version and I am hoping I can purchase it at the same time the full version is available so I can also start learning on the beta version at the same time as everyone else.
Jason
01/13/2010 (7:48 pm)
Is there a rough projected date for a beta release?Also, I would like to purchase the binary only version and I am hoping I can purchase it at the same time the full version is available so I can also start learning on the beta version at the same time as everyone else.
Jason
Employee Melv May
When it's asleep, the bodies are not updated however its possible for any child to see that the parent body has gone to sleep so if it made sense for that child, it could also stop processing stuff or perhaps just go into another mode.
Right now, we've no objects that need to do that.
If we take the Apocalypse demo and wake up every object in that scene, it takes a fair amount of time to update all those objects (still getting high frame-rates here though) but when a majority of objects are asleep, it's almost as if the objects are not there.
Behind the scenes, sleeping objects are connected together into "contact islands". This means that any objects that are touching each other are counted as a group. If you wake up one of those objects, the whole island wakes up. This makes sense if you consider stacked objects etc.
@Everyone: Feel free to ask away with regards to the 2D Model. :)