• Register
Post news RSS 3D Pixel Effects

Getting my head wrapped around doing effects for Super Hematoma has been a real challenge. I actually took some classical animation in college, but that was really focused on character animation more-so than effects. In fact I think I only did a couple of exercises on paper that involved any sort of effects, so it wasn’t until I started learning to do fluid dynamics in Maya that I began to really think about that side of production.

Posted by on

Getting my head wrapped around doing effects for Super Hematoma has been a real challenge. I actually took some classical animation in college, but that was really focused on character animation more-so than effects. In fact I think I only did a couple of exercises on paper that involved any sort of effects, so it wasn’t until I started learning to do fluid dynamics in Maya that I began to really think about that side of production.


So starting my career with fluid dynamics, and then moving from there to particles, rigid bodies, and procedurally generated shader and geometry effects means that I probably think about things differently than a traditional or pixel art effects animator would. I’ve been reading through Joseph Gilland’s Elemental Magic books (Vol. 1 & Vol. 2), and there’s a lot about the character of effects that is really good to have introduced to my brain. It’s very different than the line of thinking I’ve developed over the years for realistic looking effects, and it’s a challenge to think differently.

I’ve been trying to work on the fire effects for Super Hematoma. As I discussed last time, we’ve got a level that catches on fire. Because this will be multiplayer and people will be at different points in the stage when it ignites, this means we’re going to have to have some sort of a flash/ignition effect, the flames will then spread across the level, cycle, and then die out. When dying out, characters may be able to restart the intense burning cycle again and keep the flames going. I don’t think I’m going to be fancy and have any sort of extra flare-up happen if characters splash about in the liquid while it’s on fire. And of course, since there is a 3D environment, we’ve got to have the flames properly being masked out around rocks etc. I’d kind of forgotten about this when I set out to start animating the fire that will happen from our molotov weapon itself:

Superhematoma_effects_molotov_fire_004a

You see, I started trying to get a nice flame going here that would spread out from the impact source, and then allow us to cycle the flames, and then have them die out. This is similar to how the flames will burn on the whole oil field. I was kind of pleased with the fire that I’d started, until I realized two other things. One: this fire really is kind of flat given that the games takes place in a three dimensional world… and Two: we’ve got platforms, and obstacles in this game that the fire will need to contend with. It can’t just be a one off crafted fire like what you see above, because in the event that the flames occur near the edge of something like a cliff…

Superhematoma_effects_molotov_fire_005c

…we run into a problem where I’m not really sure of a good way to deal with the flames. Afterall, we don’t really want flame burning in mid-air. Clipping the sprite looks atrocious though. So what’s interesting/horrifying, is that (I see no other way around it) we’re going to have to build a particle system for our game the same way that we would be required to do if we were making a fully 3D game. Yet, if we’re going to maintain that pixel art look to everything, the flame really should still remain as a fairly straight forward sprite similar to what we’ve got below.

SpriteFire

I’m sure the fire isn’t the only thing that will make use of particles. Maybe we should throw the clouds onto a particle system now. Instead of having one repeating tileable card that pans, we could just populate the clouds semi-randomly each time the level opens. We could have each individual cloud pan at an ever so slightly different speed. Exciting in a way, but it’s a bit of a set-back to have a new thing to engineer. It also means that I’m thinking about the fire differently now too. Whereas I was planning on having a bit more of a cartoony solid color to the flames (not just a single color like what you see above… but still opaque), I’m now looking at the fact that we’re going to have particles with sprites spread around a 3d scene. And transparency goes a long way to selling depth. For example if we look at this test below:

opaquefire

Ignoring the fact that we’ve got a single flame animation instanced around the character… and ignoring that the character is able to hold such a pose in the fire… you can see that having opaque fire tends to look a little clunky. Sure it looks like pixel art… but it’s hard to get a sense of depth out of that. If we’re going to make things take up three dimensional space, I’d like to make use of some of the shading methods I’m used to, and perhaps do a luminance look-up of the fire to have some transparency in the flames.

transparentfire

This gives us something that still has a pixely look to it… but I think is going to help make things come together a little more as an interactive environment. I doubt we can expect any change in the lighting from fire…. but giving some transparency does help give it a voluminous appearance. I don’t know that we’ll be able to get as charming of a “spreading ignition” effect out of these particles compared to the one-off effect that I had started with… but since particles will more easily be able to get depth, and not look like crap at the edge of platforms or when near collidable objects, I really think this is the approach to take. I think we will be limiting the molotov’s behavior to ignition on impact with the ground (as opposed to ceilings or walls), but it will still have a bit of a fireball effect on impact…

Fireball

…but it’s extremely difficult to get a sense of what this will all look like at the moment without a particle system in place for me to combine the different elements in-game.

Comments
Pixelcry
Pixelcry

what is the point of turning 2d sprite into 3d FX? you use an orthographic camera ?

Reply Good karma Bad karma+1 vote
Sprixelsoft Author
Sprixelsoft

Well, what I'm doing in the preview image with Houdini is literally just so I can preview it. We don't have the game engine programmed yet, so that's the only way I can visualize it.

But if you mean in game, then the reason is that the game is going to play somewhat similar to the old school River City Ransom or Battletoads (or any beat-em-up) in that you can move through the depth plane as well as the horizontal and vertical.

Because the game is three dimensional, if you have an AoE attack like a molotov it's going to feel less cohesive if that AoE is only horizontal and not through depth. So to be able to get the fire to look like it belongs in 3D space (wrapping around obstacles or not going off into mid air when at the edge of a platform) I think that everything does indeed need to take place in 3D space.

Reply Good karma+1 vote
Thaiauxn

Excellent article.

Reply Good karma Bad karma+2 votes
Sprixelsoft Author
Sprixelsoft

Thanks!

Reply Good karma+1 vote
isbeorn
isbeorn

Oh a 2D + "simulated" 3rd dimension particle engine. My favorite! Please do a write-up on that as well when it is done :). I have one in my game, though I'm not using sprites for any particles that travel in depth. Have a look: Indiedb.com
It will be interesting to see this fire spread. At what resolution are you modeling the third dimension? I.e. what is the lowest depth your obstacles can have and how do you store the platform/collision data?

Reply Good karma Bad karma+1 vote
Sprixelsoft Author
Sprixelsoft

Hello kind sir,
Thanks for the comments! We're still working out details for the particle system ourselves, though we'll have more to say about this soon. To answer your question, collision data is stored a number of ways depending on the complexity of the particular geometry. For the most part, level geometry is axis aligned to planes on X Y and Z axes. Real 3D data points are used for all meshes including the more complex slopes and arbitrarily oriented walls and such, but axis-aligned planes use simpler collision checks. Actual solid objects usually have bounded box collision that can be described in two points, but a position + radius scheme exists for spheres as well.

As for resolution of the third dimension, that's a little harder to answer. The third dimension is actually fully present, though its display is a bit simplified. Our sprites are obviously flat, but the bruisers and objects themselves have "thicknesses" so that they can still collide with each other even if their positional depths differ within some threshold.

Good luck on your project!

Reply Good karma+1 vote
Post a comment
Sign in or join with:

Only registered members can share their thoughts. So come on! Join the community today (totally free - or sign in with your social account on the right) and join in the conversation.

News
Browse
News
New
Post news
Share
Related Games
Super Hematoma
Super Hematoma Fighting