Ultimate Death Smashers: The Smashening

bevis · 3:24pm 25 Oct 2012

So! HELLO ALL YOU BEAUTIFUL PEOPLE!

We are jamming this weekend, on a first person shooter (basically to test and get multiplayer working for broforce!)
When jamming I think its important to do some prep first, especially if you want the weekend to be reasonably stress free. Jst to research style and stuff.
So heroes the wip player model :P!
314 triangles, texture will be 64x64.

Fengol · 11:48am 26 Oct 2012

They're crab people? If so, his pincers should be red!

I love how it's 16-bit but in 3D. I think the antenna by his head superfluous, just make the earpiece block a little bigger and different colour to highlight it.

Tuism · 12:29pm 26 Oct 2012

Looks awesome! And I dig the idea of using one prototyping process to basically develop skillset for a possible future project ;)

I don't mind the antenna :) Dude looks like fun :) Jamming sounds like fun! :)

Elyaradine · 12:47pm 26 Oct 2012

On a related note:

Pixel art normal maps and real-time lighting. :P (7.7MB gif)

Tuism · 12:53pm 26 Oct 2012

How does that work?? Lots of clever code? :O

Rigormortis · 1:05pm 26 Oct 2012

@Elyaradine, at the risk of sounding like a total noob. What exactly are we looking at?

dislekcia · 1:24pm 26 Oct 2012

@Elyaradine said:
On a related note:

Pixel art normal maps and real-time lighting. :P (7.7MB gif)

... I've wanted to do something similar to that for Spacehack forever. Is that actually self-shadowing? How the fuck did they get that right?

@Rigormortis said:
@Elyaradine, at the risk of sounding like a total noob. What exactly are we looking at?

You're looking at an otherwise totally "flat" sprite (not a 3D model) being lit according to a moving lightsource. My guess is that there's a second sprite that acts as a normal map and tells a shader which direction each pixel of the actual sprite is facing (and possibly its height as well, given how the light behaves over distance), then they use that to figure out if a pixel is affected by the lightsource or not.

@Tuism said:
How does that work?? Lots of clever code? :O

Normal maps are hacks to store surface data for pixels of a texture. It's basically a second texture, but instead of colour information, the rgb data is used as a 3D vector instead. The vector itself is always positive, so it's relative to the surface (usually a triangle in 3D) of the mesh that it's being put on. That explains why normal maps look mostly bluish, because they tend to deviate away from the Z axis (xyz = rgb, hence blue) less. A shader whose job it is to determine the colour of a pixel on screen will take any lights and their positions as inputs, look up the texture colour for that pixel, look up the normal map "colour" too and then figure out how much of each light's colour should be added to the texture colour.

Shadowing is another wrinkle ;)

Elyaradine · 2:00pm 26 Oct 2012

@dislekcia: I can't say for certain, but I think there isn't actually any shadowing going on at all. Everything is coloured so that it's all in shadow, and then only pixels that are in the light's falloff get "lit" sampling the direction in the normal map.

I say "lit" because I don't think one could get such a drastic change in lighting with ordinary real-time lights, i.e. getting a surface to shift from a blue-purple all the way to a yellow. It's beautifully painterly. You could try it in some custom lighting model... and I'm sure there are win shader hackers that could pull it off, but I don't know how I'd approach that. :)

Staring at it for a bit, it seems that the "unlit" blue bits never get any darker. Similarly, once a pixel is lit the light close by, it never gets brighter either. (i.e. no overbrightness, white highlights, hdr kinda stuff.) I'm totally thumbsucking here, but I'd guess that they have two textures: a "shadowed world" texture (bluish) and a "lit world" texture (yellowish), and lerp between them using the result of the lighting calculation. This is how I'd try doing it anyway (or some variation. Lookup maps maybe, instead of having to texture the whole world twice).

Hey, here's a weird thought, maybe using tesselation and whatever DX11 hacks exist, one could get shadows working too, by actually deforming the geo? :P

@dislekcia wrote:
The vector itself is always positive

99% of the time, yeah. :) Occasionally you see people actually using the backward normal direction to get a fake subscattering effect, for leaves and stuff. (Like here.) I've also seen it used for some other non-standard stuff, but I can't remember the details.

Rigormortis · 2:12pm 26 Oct 2012

@disleckia, <3 thanks so much for that :) Makes me feel like I still know so little about making games(which I do :( )

On Topic : @Bevis, are you guys planning to put up the resulting games here? :)

dislekcia · 3:16pm 26 Oct 2012

@Elyaradine: You're definitely right about only having the two lighting modes. It's like "is this pixel close to light and at correct angle? Yes, then change that colour!"

I dunno about deforming geometry - if you're going to do that then you need to generate 3D models to figure out the deformation texture info from anyway. Then you'd be re-rendering some sort of shadow volume to figure out which pixels need to be lit or not.

I was mainly wondering about the shadowing due to a bump-shadowing technique I saw somewhere that would sample blurred (or mipmapped) versions of the normal map "back" along the line of light in order to see if a particular pixel should be in shadow or not. It wouldn't be perfect (wouldn't take other occluding objects into account, for instance) but it might work out, especially given that they're working with such large texels - there's basically "free" samples available that they're not using for aniso/trilinear or whatever.

@Rigormortis: Games are usually just collections of tricks ;)