PhysicsEditor discussion
by Mike Lilligreen · in Torque 2D Beginner · 07/08/2013 (2:18 pm) · 5 replies
As mentioned in the roadmap for 3.0 blog, one of the features should be PhysicsEditor support. I've started work on an exporter for T2D and would like to open up a discussion on what people would like out of this tool.
There are still a few bugs to work out before I post a copy of the exporter to my fork for others to try out but right now PhysicsEditor is exporting TAML XML for Polygon and Circle collision shapes like this:
Some notes and points for discussion:
1. PhysicsEditor works with pixel units so all those numbers you see in my examples need to be converted to T2D world units in meters. Need to figure out if there is a way to automagically do that in the template otherwise this program will only be of limited utility.
2. Importing sprite sheets is bad as PhysicsEditor has no way to display frames. Need to break sheets down into individual frames with an image editing program and then make collision shapes based on those files.
3. Obviously PhysicsEditor is very image oriented so I have the template set up only to export the Sprite class, as you can see in my examples above. Is this fine for everyone or do we want some way to specify the export as a SceneObject, Scroller, Trigger, etc?
4. Again, with the examples above, the output right now is only for CollisionShapes and eventually their related properties (like Sensor, Density, Restitution, etc). Do we want to add fields for non-collision properties like Size, Position, LinearVelocity, BlendMode, etc? Basically turn PhysicsEditor into a TAML Sprite editor?
5. I am not sure how we can enforce the 8 vertices hard limit default for polygon shapes within the stock engine. With the tracer, it is very easy to go above 8 vertices.
Feel free to bring up any other points or suggestions. You are able to download an evaluation copy and play with most of the features, so don't let the price tag of the software stop you from being part of this discussion.
There are still a few bugs to work out before I post a copy of the exporter to my fork for others to try out but right now PhysicsEditor is exporting TAML XML for Polygon and Circle collision shapes like this:
<Sprite>
<Sprite.CollisionShapes>
<Polygon>
<Point>64.0 64.0</Point>
<Point>-64.0 64.0</Point>
<Point>-63.0 -67.0</Point>
<Point>64.0 -64.0</Point>
</Polygon>
</Sprite.CollisionShapes>
</Sprite><Sprite>
<Sprite.CollisionShapes>
<Circle
Sensor="true"
Offset="0.0 6.0"
Radius="57.1" />
</Sprite.CollisionShapes>
</Sprite>Some notes and points for discussion:
1. PhysicsEditor works with pixel units so all those numbers you see in my examples need to be converted to T2D world units in meters. Need to figure out if there is a way to automagically do that in the template otherwise this program will only be of limited utility.
2. Importing sprite sheets is bad as PhysicsEditor has no way to display frames. Need to break sheets down into individual frames with an image editing program and then make collision shapes based on those files.
3. Obviously PhysicsEditor is very image oriented so I have the template set up only to export the Sprite class, as you can see in my examples above. Is this fine for everyone or do we want some way to specify the export as a SceneObject, Scroller, Trigger, etc?
4. Again, with the examples above, the output right now is only for CollisionShapes and eventually their related properties (like Sensor, Density, Restitution, etc). Do we want to add fields for non-collision properties like Size, Position, LinearVelocity, BlendMode, etc? Basically turn PhysicsEditor into a TAML Sprite editor?
5. I am not sure how we can enforce the 8 vertices hard limit default for polygon shapes within the stock engine. With the tracer, it is very easy to go above 8 vertices.
Feel free to bring up any other points or suggestions. You are able to download an evaluation copy and play with most of the features, so don't let the price tag of the software stop you from being part of this discussion.
About the author
#2
I've had a brief look at other framework's PhysicsEditor tutorials, and a lot of them suggest simply making 1 best fit collision shape for a sprite sheet with lots of animation frames, for example.
I think PhysicsEditor is able to decompose shapes (especially when the overall shape is concave, it gets broken down into multiple convex shapes) but I will have to look into that more deeply. Right now I have been focused on just getting very basic circle and box shapes working.
07/08/2013 (3:13 pm)
Some of the exporters for the other frameworks and engines have a pixel to meter field in their metadata. Might have to go down that same route, yes.I've had a brief look at other framework's PhysicsEditor tutorials, and a lot of them suggest simply making 1 best fit collision shape for a sprite sheet with lots of animation frames, for example.
I think PhysicsEditor is able to decompose shapes (especially when the overall shape is concave, it gets broken down into multiple convex shapes) but I will have to look into that more deeply. Right now I have been focused on just getting very basic circle and box shapes working.
#3
github.com/lilligreen/PhysicsEditorExporter
Right now there is the hassle of converting the export's pixel units into meters (basically take your image size and divide it by the size of your object). We would probably need some engine additions to make it more user friendly. Perhaps a flag in the TAML file that it is from PhysicsEditor, so when it is read the units can be automatically converted by the engine?
07/10/2013 (1:18 pm)
So I've uploaded what I have done so far into a Github repo. You can grab a copy here:github.com/lilligreen/PhysicsEditorExporter
Right now there is the hassle of converting the export's pixel units into meters (basically take your image size and divide it by the size of your object). We would probably need some engine additions to make it more user friendly. Perhaps a flag in the TAML file that it is from PhysicsEditor, so when it is read the units can be automatically converted by the engine?
#4
Just exploring multiple options.
07/17/2013 (8:52 am)
What about generating a new asset/data type that just contains the collision information, which can then be loaded by an object? Basic example:%sprite = new Sprite()
{
collisionData = "^ArtModule/myCollisionData.taml";
};Just exploring multiple options.
#5
1. New asset type just with collision info.
2. Bare Sprite only with collision info.
3. Bring all or many non-collision shape fields into the exporter template to get a more fleshed out object.
In all cases we will need a way to handle the pixel units since we can't edit a collision shape after it is created. (I inserted the PhysicsEditor="true" field as an example way to let the engine know the units aren't in meters). Or the instructions on how to use the exporter includes a step where you manually have to convert the units to meters in XML/JSON.
07/17/2013 (11:06 am)
Yes, that's a possibility. I guess there are 3 levels of data we could potentially export.1. New asset type just with collision info.
<CollisionShapes
PhysicsEditor="true">
<Polygon>
<Point>64.0 64.0</Point>
<Point>-64.0 64.0</Point>
<Point>-63.0 -67.0</Point>
<Point>64.0 -64.0</Point>
</Polygon>
</CollisionShapes>2. Bare Sprite only with collision info.
<Sprite
PhysicsEditor="true">
<Sprite.CollisionShapes>
<Polygon>
<Point>64.0 64.0</Point>
<Point>-64.0 64.0</Point>
<Point>-63.0 -67.0</Point>
<Point>64.0 -64.0</Point>
</Polygon>
</Sprite.CollisionShapes>
</Sprite>You would then have to do something like this:%sprite = TamlRead("PEExport.taml");
%sprite.Image = "ToyAssets:blahblah";
%sprite.size = "6 6";
...3. Bring all or many non-collision shape fields into the exporter template to get a more fleshed out object.
<Sprite
PhysicsEditor="true"
SceneLayer = "8"
SceneGroup = "0"
CollisionGroups = "4"
Size = "6 6"
LinearDamping = "1"
Image = "@asset=ToyAssets:something">
<Sprite.CollisionShapes>
<Polygon>
<Point>64.0 64.0</Point>
<Point>-64.0 64.0</Point>
<Point>-63.0 -67.0</Point>
<Point>64.0 -64.0</Point>
</Polygon>
</Sprite.CollisionShapes>
</Sprite>In all cases we will need a way to handle the pixel units since we can't edit a collision shape after it is created. (I inserted the PhysicsEditor="true" field as an example way to let the engine know the units aren't in meters). Or the instructions on how to use the exporter includes a step where you manually have to convert the units to meters in XML/JSON.
Torque Owner Richard Ranft
Roostertail Games
Creating collision shapes on a frame-by-frame basis might not be good - performance could suffer greatly.
The 8 vert limit is per shape - you could find a way to decompose the full shape into multiple shapes of 8 verts or less.