by date
TorqueX Newbie Diary #3
TorqueX Newbie Diary #3
| Name: | David Everhart | |
|---|---|---|
| Date Posted: | Dec 07, 2007 | |
| Rating: |  Not Rated | |
| Public: | YES | |
| Comments: | YES | |
| RSS Feed: |  or Subscribe with  . | |
| Profile Page: | View profile page for David Everhart |
Blog post
Animation Creator
Well, after spending a lot of time with the torquex 3d stuff, I have decided to instead spend some more time trying out some 2D approaches. As such , I began researching 2d character itemization techniques. There was a lot of basic information out there, but most of it was not too helpful. Techniques ranged from swapping out channels, to writing the individual peices to the screen as individual peices, held together by a logical representation of the base object.
I tried the second approach somewhat, but mounting a helm animation, chest animation, leg animation, boot animation, weapon animation, etc adds up, and thats just ONE direction. If your animations were 10 frames per animation, your looking at around 100+ easily for a complex animation. While these are definitely viable, they just dont seem to practical to me. After some more research, I came upon this:
Diablo II's Animations
Paul Siramy in his excellent pdf went through how Diablo II did their character itemization, even down to the file formats, structure, and how it all comes together. They used a technique where they applied images (sprites) into frames at runtime, then meshed them all together for one final animation. In his pdf, he explains how they basically have body parts, weapons, and items, and can literally adjust the tint (via a colormap) to create new versions of an existing item . The neat thing about this approach,is you only deal with the final animation, versus say 10 T2dAnimatedSprites mounted to each other.
With all that in mind, and after dissecting that pdf over many smoke breaks, lunches, late night reading, and good old fashioned bathroom reading material, I decided to build my own. I first checked out XNA support for Texture2D. It seemed pretty lacking, and although you can render a texture to another texture, it doesnt seem like it was really built for manipulating images. My next technology I looked at was GDI+, something I have worked with extensively in the past. I know it has very robust image handling capabilities, but the downside is it does not run on Xbox 360 (which is fine for me). Windows Presentation Foundation is a little too far in the future for me to really use (although I can see it will be a powerhouse when .NET 3.0 is used everywhere). With all that in mind, I chose GDI+, with the mindset that the logical structure of my AnimationCreator library wont change much, although the underlying image manipulation might.
At a high level,the rough prototype I have now basically merges images into a frame, and then merges frames into a framelayer, and then finally merges framelayers into an animation. There is also an AnimationDatabase singleton, allowing you to cache your animations, framelayers, and spritesheets if you have any. and call them at will. I also built the prototype so you can load a spritesheet directly to a framelayer (you use a List<FrameDefinition> to specify how to slice it up, any colormaps, etc).
The goal was to be able to produce that final animation image. This image is then converted to a DefaultEffect, then passed in as the material for a T2dAnimationData object. In essence, you can literally build either frame by frame, or whole frame layers at once, or anywhere inbetween, and come out with an animation that takes around 200 milliseconds so far to create. You can also apply colormaps at the frame, framelayer, or animation level.
A good example of the flexibility I am aiming for is that you could, at runtime, get an animation you created already via the AnimationDatabase, and then change the 7th frame of the helm frame layer if you wanted to. I wanted it so you can literally touch any frame or framelayer in the animation, then rebuild the animation on the fly.
I am having some issues with the defaulteffect aspect of the Torque engine however,and I may just need to create my own effect to support this (I hope not). The current effects assume you have an asset or a file, but no real stream support. It does have some functionality allowing you to change the base texture of an already loaded one, but my tests have not been successful as of yet(nor have I got a response from the forums). I will post it once it is cleaned up , has a lot more validation, and has been optimized. Since it is a seperate project, you can just drop in the binary or add the project once its done, and of course, I will provide it to anyone that wants it. Until next time!
Well, after spending a lot of time with the torquex 3d stuff, I have decided to instead spend some more time trying out some 2D approaches. As such , I began researching 2d character itemization techniques. There was a lot of basic information out there, but most of it was not too helpful. Techniques ranged from swapping out channels, to writing the individual peices to the screen as individual peices, held together by a logical representation of the base object.
I tried the second approach somewhat, but mounting a helm animation, chest animation, leg animation, boot animation, weapon animation, etc adds up, and thats just ONE direction. If your animations were 10 frames per animation, your looking at around 100+ easily for a complex animation. While these are definitely viable, they just dont seem to practical to me. After some more research, I came upon this:
Diablo II's Animations
Paul Siramy in his excellent pdf went through how Diablo II did their character itemization, even down to the file formats, structure, and how it all comes together. They used a technique where they applied images (sprites) into frames at runtime, then meshed them all together for one final animation. In his pdf, he explains how they basically have body parts, weapons, and items, and can literally adjust the tint (via a colormap) to create new versions of an existing item . The neat thing about this approach,is you only deal with the final animation, versus say 10 T2dAnimatedSprites mounted to each other.
With all that in mind, and after dissecting that pdf over many smoke breaks, lunches, late night reading, and good old fashioned bathroom reading material, I decided to build my own. I first checked out XNA support for Texture2D. It seemed pretty lacking, and although you can render a texture to another texture, it doesnt seem like it was really built for manipulating images. My next technology I looked at was GDI+, something I have worked with extensively in the past. I know it has very robust image handling capabilities, but the downside is it does not run on Xbox 360 (which is fine for me). Windows Presentation Foundation is a little too far in the future for me to really use (although I can see it will be a powerhouse when .NET 3.0 is used everywhere). With all that in mind, I chose GDI+, with the mindset that the logical structure of my AnimationCreator library wont change much, although the underlying image manipulation might.
At a high level,the rough prototype I have now basically merges images into a frame, and then merges frames into a framelayer, and then finally merges framelayers into an animation. There is also an AnimationDatabase singleton, allowing you to cache your animations, framelayers, and spritesheets if you have any. and call them at will. I also built the prototype so you can load a spritesheet directly to a framelayer (you use a List<FrameDefinition> to specify how to slice it up, any colormaps, etc).
The goal was to be able to produce that final animation image. This image is then converted to a DefaultEffect, then passed in as the material for a T2dAnimationData object. In essence, you can literally build either frame by frame, or whole frame layers at once, or anywhere inbetween, and come out with an animation that takes around 200 milliseconds so far to create. You can also apply colormaps at the frame, framelayer, or animation level.
A good example of the flexibility I am aiming for is that you could, at runtime, get an animation you created already via the AnimationDatabase, and then change the 7th frame of the helm frame layer if you wanted to. I wanted it so you can literally touch any frame or framelayer in the animation, then rebuild the animation on the fly.
I am having some issues with the defaulteffect aspect of the Torque engine however,and I may just need to create my own effect to support this (I hope not). The current effects assume you have an asset or a file, but no real stream support. It does have some functionality allowing you to change the base texture of an already loaded one, but my tests have not been successful as of yet(nor have I got a response from the forums). I will post it once it is cleaned up , has a lot more validation, and has been optimized. Since it is a seperate project, you can just drop in the binary or add the project once its done, and of course, I will provide it to anyone that wants it. Until next time!
Recent Blog Posts
| List: | 09/03/08 - TorqueX 3D Hiding Meshes Part 2 07/09/08 - TorqueX - First Stab at Hiding Mesh Resource 06/22/08 - Journey Into 3D 01/28/08 - TorqueX Newbie Diary #6 01/07/08 - TorqueX Newbie Diary #5 12/12/07 - TorqueX Newbie Diary #4 12/07/07 - TorqueX Newbie Diary #3 12/01/07 - TorqueX Newbie Diary #2 |
|---|
Submit your own resources!| Ross Pawley (Dec 07, 2007 at 21:56 GMT) |
One thing I've wanted to try for a while (I have a *basic* version of it working) but have had trouble with due to speed, is making all the "sprites" actually be SVG vectors, and then drawing them onto bitmaps for blitting. Ideally you'd specify 2-3 midpoint frames and then just have it interpolate the control point positions before it renders. Unfortunately, practically every SVG library I've tried is *very* slow for being able to do what I'd like, and almost none of them are hardware accelerated.
| David Everhart (Dec 08, 2007 at 01:59 GMT) |
I know the XNAExtras pack has a 2d library that specificaly deals with sprites. I checked it out, but it didnt really do what I was envisioning. Since I posted this, I ran some tests with the cached framelayers, and it generates the image in 31 milliseconds. It takes around 125 milliseconds just to load the torquesettings.xml file! If the whole animation is cached , I am guessing it would be under 10 milliseconds (Ill find out tonight :) ) I am thinking, at the games initial startup, firing an asynchronous thread, that loads framelayers, animations, frames, etc based on an xml file, and by the time you get to the actual game, it will have them all ready for use.
| Ross Pawley (Dec 08, 2007 at 03:54 GMT) |
I fixed a small problem in Anti-Grain Geometry lib that was causing the loading of SVG to fail and found out that it's a lot faster than cairo is. The real benefit would be to put it all onto the GPU so it could be properly fast. I estimate that I could render maybe ~10 objects as dynamic SVG (as opposed to an SVG loaded then converted to raster and blitted from then on as raster) at ~30 fps in AGG.
One other benefit this would allow is arbitrary scaling while in game. That's one thing I really wanted to do, since it would allow you to zoom in on the action parts. The game I was/am making using that technique is an homage to the game "N" using my own programmer art, but would be a platformer action game with some concepts (well one) inspired from the game Worms (i.e., the ninja rope would be very prevalent). I haven't had time to port it to Anti-Grain yet, or try hardware accelerating AGG's drawing (really though, it appears that the blit isn't even the slow part, it's the actual computation of the line data, so that would have to be done via some general purpose GPU shaders).
So if you're interested in maybe taking my code and converting it to AGG and/or jointly trying to accelerate that, shoot me an email! If we managed to do the latter, I'm sure GarageGames would be interested in it, since they're going to be using it for their GUI in Torque 2.
| David Everhart (Dec 08, 2007 at 17:06 GMT) |
| David Everhart (Dec 09, 2007 at 02:44 GMT) |
<AnimationCreator>
<Animations>
<Animation>
<Name>SwordWalk|SE</Name>
<FrameLayers>
<FrameLayer>
<Name>Sword|SE</Name>
<Sort>0</Sort>
</FrameLayer>
<FrameLayer>
<Sort>1</Sort>
<Name>Skeleton|SE|NoSword</Name>
</FrameLayer>
</FrameLayers>
</Animation>
</Animations>
<FrameLayers>
<FrameLayer>
<Name>Skeleton|SE|NoSword</Name>
<Image>data/images/SkelWalkNoSword.png</Image>
<ImageAttributes><!--This is not flushed out Yet--></ImageAttributes>
</FrameLayer>
<FrameLayer>
<Name>Sword|SE</Name>
<Image>data/images/SwordWalk.png</Image>
<ImageAttributes><!--This is not flushed out Yet--></ImageAttributes>
</FrameLayer>
</FrameLayers>
<SpriteSheets></SpriteSheets>
</AnimationCreator>
and populated it in a seperate thread on game initialize in 91 milliseconds. Once it was in the AnimationDatabase singleton, retrieval was 0 milliseconds. Now its time to build the animation configurator that says what framelayers go with what animation!
Edited on Dec 09, 2007 02:45 GMT
You must be a member and be logged in to either append comments or rate this resource.
