I have recently started work on a 2D platformer with XNA, the game basically uses sprite animations, now for me these sprite animations for player movement are a little restrictive and as seen as I am doing per pixel collision I thought it would be clever if I had a blend between ragdoll style physics and sprite animation. i.e player character runs into a wall, on collision there is a blend between current animation frame and ragdoll physics Is there any toolchains or custom data format out there that are specially made for 2D sprite based models with extensions for bones/keyframe animations or will I have to write my own? Ideally I want to keep my current sprite animations but I dont think this is going to be possible as there is no way of linking this together with physical data in a sprite format not unless something exists like I mentioned above... I could spend some time in writing a custom max exporter/importer but I want to avoid this if at all possible, besides MAX is designed for creating 3D models, if I am mistaken please say. There is a tool I found that converts a 3D model to 2D sprite sheets, which is along the right lines, but its animations/bone data that I want as well.

http://www.torquepowered.com/community/blogs/view/16207

Can anybody give advice or make any suggestions? Thanks Rama

I'm a little confused how you expect "ragdoll physics" to work with sprites. Are you going to be applying 2D rotations or something?

I think the basic idea is that you define a model skeleton (basically, the geometry of a stick-figure), and have the physics calculate the final position of each endpoint; then, along each bone, you render the corresponding "flesh" sprite. I don't see how keyframes would figure into it.

That said, I can't imagine it looking terribly good with 2D artwork. :/

Quote:Original post by Zahlman
I'm a little confused how you expect "ragdoll physics" to work with sprites. Are you going to be applying 2D rotations or something?

I think the basic idea is that you define a model skeleton (basically, the geometry of a stick-figure), and have the physics calculate the final position of each endpoint; then, along each bone, you render the corresponding "flesh" sprite. I don't see how keyframes would figure into it.

That said, I can't imagine it looking terribly good with 2D artwork. :/

I see your point about the ragdoll without rotation. The effect I am going for is basically a 2D game but I want the player character to be effected by the world environment, hence if something is thrown at him, he will react realisticly rather than some predefined animation that is basically just repeated all the time.

Regarding the approach you mentioned, I imagine your talking about skinning, and just modelling the skeleton in a tool like 3DS max, I will have to look into the fbx or .x file format to see if they support the physics constraints I will need.

Perhaps I will have to just got for the 3D player character, and use a skeleton system with skinning like you said, from there I can do all the character ragdoll calculations in 3D. I would probably just ignore the Z or Y (whichever is forward/back) when doing collision detections.

[Edited by - reaper93 on February 27, 2010 5:50:04 AM]

Hi Reaper,

Knowing only the basics of physics, I have to agree that it would be very odd to see this effect in 2D. Depending on what happens to the player(being hit or being burned) the player would respond with different predefined animations.

I'm not sure if there's a way around and achieving a realistic reaction without moving a fully rigged model.

You can of course construct the images and just direct the code to the proper animation in conventional fashion.

Quote:Original post by antmj2317
Hi Reaper,

Knowing only the basics of physics, I have to agree that it would be very odd to see this effect in 2D. Depending on what happens to the player(being hit or being burned) the player would respond with different predefined animations.

I'm not sure if there's a way around and achieving a realistic reaction without moving a fully rigged model.

You can of course construct the images and just direct the code to the proper animation in conventional fashion.

Yeh, I have already considered this solution but the problem I have with it is it is just too precalculated, I may want more dynamic movement for example he gets hit on leg, so his body gives way, or he gets hit on the head and basically the physics model just takes over allowing for natural movement. Or lets say he was trying to jump onto a ledge, but he just misses it and his foot gets caught on the edge, I would expect him to fall flat on his face while colliding with the floor. I will only be going for a basic stickman style of artwork but I want to make up for the simple styles with immersive player-world interaction.

What if I do the work in 3D but ignore the collision detection tests in the Z axis and then simply render the results from a fixed camera angle. That way we still get a 2D perspective of the game but the motion and physics are all fully modelled? So something like:

Start frame1.From sprites in the scene, do per pixel collision tests.2.If collision is detected for main player character, apply a force to the player model (full 3d physical model, in memory only, not displayed).3.Allow physics engine to work out new model position.4.Render model from a side view onto a texture in memory.5.Use that texture as the sprite for the player character.End frame

Does this sound viable? Not quite sure how I would map the collision detected from the sprite into a position to apply a force on the actual 3d player character, maths question I suppose.

ps Thanks for the responses so far, all helpful, any suggestions or obvious downfalls of the method i have suggested would be great.

Quote:Original post by JTippetts
If you're going to do a render to texture of the model, why not just use an orthographic view and just render it to the screen instead? Not sure why you need to do an intermediate RTT step. You can still get that "spritey feel" to the game due to the ortho projection, minus all the weird hassle of trying to 2D-ify ragdoll.

Is this just basically projecting the rendered scene onto the viewport without doing the extra transform from camera -> world space? My 3d maths is abit rusty, havvnt done much graphics programming lately.

Sort of.

I'm surprised you're facing so much confusion about 2D ragdolls. Something like this, right? Well, it depends on how you're integrating physics into your engine. This link has information about doing it yourself. There's also physics engines already available; I know that Box2D has a 2D ragdoll in its examples section. Ultimately, though, you'll need some way to assign the textures per body segment; some way to apply your character's arm texture to the arm quad, the leg texture to the leg quad, etc. For that, you might want to make your own editor.

yes thats exactly the kind of effect I am going for FunkyMonkey, but obviously mixed with preset animations, blending between the two somehow, dont see why so many people think it would be odd.

I have already integrated JibLibX into my XNA game as I was going to go with the solution I suggested above but I will take a look at what Box2D can offer before I go ahead with that, ideally I want to stick with the 2D approach and 2D physics engine, I heard the 360 can struggle with heavier apps. Somebody has already started a port it seems, not sure how complete it is, but its a bonus as it will run on the 360 which is my target platform.

http://code.google.com/p/box2dx/
hmmm wheres the source code... only dlls, looks like farseer is in a much bettr state.

Thanks alot for your input! Reading the article too.

[Edited by - reaper93 on March 2, 2010 6:28:59 PM]