[WIP] Robot Project

[walaber]

I reached a point on my latest project that I think I can show it off, and ask a few questions while I'm at it



VIDEO
http://www.youtube.com/watch?v=wD6DVdWD0a0 - YouTube
http://walaber.com/misc/rp_wip_video01.wmv - Windows Media download

**don't mind the speed, the framerate dropped because of fraps.

The project is a physics-based 2D game that will involve robots. So far I have implemented the first revision of my graphics system (shaders) which are basically normal-mapped billboards. I think the system works pretty well, and it's extremely easy to create content for it in Blender. Each visual object has 4 maps: ambient, diffuse, normal, and specular.

The physics are working great so far, with some custom joints and constraints I've come up with for 2D. The robot is moving by powered joints (currently running off a Sin() wave).

Finally, at the end of the video you can see my "replay" system, which lets you stop and go back and "scrub" through the timeline, watching the physics. At any point in the past you can restart the simulation.


finally a question - the attenuation on my point light does not seem to work smoothly between objects (esp. noticable on the ground blocks at the bottom)... as you can see there are strange "steps" where each block is darker than the one next to it.

does anyone know what might be causing this?

[nedelman]

Cool looking demo.

As for the lighting issue, it may be helpful if you posted your shader code, in particular the parts that calculate the attenuation.

[walaber]

in the pixel shader:
lightDir is the object-spcace position of the light (passed over from the vertex shader without modification):

Code: Select all

float dist		= length(lightDir.xyz);

float attn		= clamp(0,1, 1 / (lightAttn.y + 
					lightAttn.z * dist + 
					lightAttn.w * dist * dist ));

[smernesto]

Hi, you always have original games !

Will you release the source code?
I am interested in how you record all the moves in the game and reproduce it again. I am making a animation software with ogre.

Thanks

Ernesto

[nedelman]

in the pixel shader:
lightDir is the object-spcace position of the light (passed over from the vertex shader without modification):

Code: Select all

float dist		= length(lightDir.xyz);

float attn		= clamp(0,1, 1 / (lightAttn.y + 
					lightAttn.z * dist + 
					lightAttn.w * dist * dist ));

Your lighting is being done per vertex even though all your other operations are occurring per pixel. The interpolated nature of lightDir is probably causing this very slight visual discontinuity. Try calculating lightDir per pixel.

[walaber]

I wasn't sure if light_position_object_space would be valid in a pixel shader (as in calculated properly as interpolated across the poly).

I will try moving that into the pixel shader, and see that happens!

[skullfire]

Great work walaber! This reminds me so much of Little Big Planet. Or at least at the early prototypes they did for Sony (shown public @ GDC 07). I hope this game evolves to be similar to PS3's savior game!

[walaber]

@skullfire - thanks! the game is coming along nicely, and although it will never be as beautiful as LittleBigPlanet, I'm enjoying making it!

regarding the shaders...

I can't seem to get light_position_object_space to be valid as a parameter into the pixel shader... Ogre appears to just pass me (0,0,0,0).


how would I calculate the distance / direction of a light in object space entirely in the pixel shader?

[walaber]

I'm ignoring the attenuation problem for now, and moving on with the game itself.

I thought I'd post a few updated screens... click for larger. Most of the shots are from the "Part Editor" that I have created to build the physics objects that are in the game. It's come out pretty well, so when the game is eventually released, I might include the editor so people can create their own levels and objects. You can also see the custom CEGUI skin I'm working on for both the editor, and the game itself. I think it's looking pretty nice if I do say so myself

[walaber]

Updated "Walking" Video

[Praetor]

With some really quick, late-night thinking this is what I came up with. I actually made a 2D, normal-mapped engine without Ogre this year and came across lighting anomalies like this. My guess is that the light position coming in is relative to the object. What you might want to do is pass in the light position in global coordinates. Then get the per-vertex direction by doing

Code: Select all

vertPos - lightPos

and letting that get interpolated into the pixel shader.

[walaber]

I'll keep that in mind... I was using light_position_object_space because I'm calculating all of my lighting in object space, because my normal maps are in that space...

once I get the game farther along, I'll try out some other methods.

[To1ne]

WHow, the replay function looks so nice!!

[Praetor]

Ok.

Here's my thought. Pass through both the object space position of the light and the object space position of the vertex. They'll get interpolated into the pixel shader. There calculate the direction by subtraction. Seems like an unnecessary operation put onto the pixel shader, but I think it will give you the results you want.

[walaber]

thanks Praetor - I'll give that a go.

To1ne - thanks for the comment! This thread has been pretty light on the feedback, so i appreciate it. perhaps I should have waited until I had more to show before I posted...

[smernesto]

Hi walaber,

how did you implement the replay function?

Thanks

Ernesto

[walaber]

it's similar to a system I implemented in Stunt Playground, feel free to download the source code for that game to see how I did it there. This game has a slightly more complex replay system, because it remembers keyframes for poses as well as basic physics movement, but overall the implementation is very similar.

Stunt Playground also lets you save and load replays, so if you're interested, have a look at the source. It's based on Newton's callback system, so keyframes are only added when an object actually moves, which makes the system pretty memory-efficient, especially if you have lots of props in a scene, that don't move constantly. In Stunt Playground I also implemented a filter so that objects keyframes are only recorded at a certain frequency, basically reducing the accuracy for some objects. So in that game for instance, all props only record keyframes at something like 30 frames per second, but the vehicles and tires have keyframes accurate up to >100 fps IIRC.