Proun - OUT NOW!

[Oogst]

Latest update:

I have just released Proun! It is Pay What You Want, so you can get it for any price from my website: http://www.proun-game.com

Launch trailer:



I hope you'll like it!

--------------------------------------------------------------------------------

Original topic start:

I am working on an artsy fartsy racing game called Proun, which is getting close to a first beta/playable/test thingie. I want to have two tracks completely done for IGF (deadline end of October), so I need to step up the pace of finishing this a bit...

I have made some target renders in 3dsmax of what I want the game to look like. So these are not in-game screenshots, but since I want to be sure I don't bail out of this, I am posting these now, so that you folks know what I wanted to achieve and can blame me if it looks a lot worse. Also, I think they are nice pictures, so I felt like sharing them.

Ow, in case anyone is wondering: these images miss the player's vehicle, since I have not figured out a design for that yet. The point of the game is to rotate around the cable to avoid obstacles. A very simple idea, but rather challenging in terms of gameplay.







The main things that I still need to add to get close to this look in real-time, is baking fake HDRI light maps. The depth of field blur already looks nice in-game (although not as smooth as in these renders), but I need to make that look more HDRI as well. I already talked about the depth of field blur a bit in an earlier topic (from before I came up with the name of the game).

[Praetorian]

Oooooh pretty (if you can get it looking like that ingame that'll be awesome!).

Nice to another Ogre user looking to enter the IGF, (I'm frantically putting together levels and adding last minute features to my project (Quanta)).

[nikki]

Wow that's cool. Can't wait to see some shots with the car.

[Assaf Raman]

Nice style.

[Oogst]

So, here it is: the same shots, but now in-game. Spot the differences! I got really close, I think, so I am really happy with that. This was done by doing high-quality post process depth of field blur in combination with baked lightmaps that contain fake-HDRI.







A friend of mine also came up with a nice idea for the vehicle, so I can start adding that soon too.

Also, if anyone here knows someone who would like to play some short pieces of saxophone music for the soundtrack, then please let me know! The rest of the soundtrack sounds quite okay as I made it on my computer, but the saxophones sound really bad right now: those really need recordings of real saxophones instead of samples.

[sinbad]

Wow, you got really close to the target renders, kudos!

I love games that have a unique look to them, the sort of thing that you can see for 2 seconds and know what it is instantly. Retro games used to have that , now it's harder since racing / FPS / strategy games tend to look quite similar. Great work.

[Shockeye]

Call me crazy, but to my eye the in-game images look better than the 3dsmax renders! Maybe you were hoping for the blurring effect on the track in the distance, but I think it looks cooler the way it appears in-game.
Great visuals.
What's the gameplay going to be like? I hope you can drive an any side of the cylindrical track.

[Oogst]

Thanks!

The blurring is deliberately done slightly different than in the target renders. Blur is very important for the gameplay, because without a 'normal' game world to judge distance by, the blur is necessary for the player to estimate how far she is from the next obstacle she needs to avoid. This is why in the game I only blur in the distance and not close to the camera. I couldn't get VRay to do that in the target renders, which is why they differ in that respect. The distance blur is also set to start at a slightly longer distance in the game than in the target renders.

The gameplay is all about rotating around the track to avoid obstacles. So what is up and down constantly changes as you rotate around the track. When playing, this actually feels less dizzying than you might think, though.

[peopleITA]

Good work man!!!

[kajjjak]

Cool, really like the artwork. Cant wait to play it !!

[sinbad]

The gameplay is all about rotating around the track to avoid obstacles. So what is up and down constantly changes as you rotate around the track. When playing, this actually feels less dizzying than you might think, though.

I'm thinking F-Zero GX and the levels where you race along the outside of a pipe. Man, you did not want to play that game on a really big screen, it's eyeball overload

[Oogst]

Yeah, an intern showed me that level after seeing Proun last week, that F-Zero level looked really chaotic and awesome!

[trnrez]

I *LOVE* the style of this! Can't wait to see more from this project.

[Oogst]

The vehicle is definitely the most difficult thing to get right for me in this game. I want something simple and abstract, not some kind of car or plane or something like that, and I want it to look good from behind, and I want it to be close enough to the sphere that is used for collision detection.

So I ended up with a sphere.

Ahum.

What is the sound design of a sphere going really fast?

If you go slow, the sphere morphes into some kind of noise and the closer you get to top-speed, the smoother it becomes. During a turbo, it becomes more like an arrow. I think I am okay with the design for this, but the materials need some more work to make it look better. However, if someone has some cooller idea for the vehicle, do let me know! I'm not in love with the vehicle yet...

So, I've got a vehicle in the game now, but I need it to cast some form of shadow on the cable. I just want a blurred circle gradient beneath the ball, on the track. Like on the screenshots below, for which I added the shadow under the ball in Photoshop. Would anyone here have some advice on how to achieve this? I was thinking of just putting a polygon with a circle texture on multiply under the vehicle, but there is little room between the vehicle and the texture. So how can I make sure that it is always rendered over the cable, and still have the rest of the scene occlude it when needed? Any thoughts on this? Is there some simple way to force the rendering order to first render the cable, then the shadow (without z-testing), and then the rest of the scene?

Slow speed:


High speed:

[Praetor]

Try putting a negative light in the vehicle. Basically, when drawing the track, pass in the vehicle's position and some attenuation parameters as if it were a light. Doing normal point light equations except use a negative color. With a good attenuation set you should end up with a decent contact AO-style shadow when the vehicle is close to the track.

[xadhoom]

Maybe you could add a visual link between the sphere and the cable?! I mean just to emphasize the actual connection between both. Instead of a "real" connector it could be also a lightbeam or so...

xad

[Shockeye]

I like the idea of the morphing vehicle. It reminds me of the movie Flight of the Navigator.

Just another idea: Instead of sphere, a torus, on its side like a wheel. Sort of like a monocycle. Maybe with a tyre tread when moving slower and the morphing to smooth as it accelerates.

[sinbad]

How about a simple sphere, but as you get faster it stretches much like the typical animator's technique of making a ball look like it's travelling fast?

[Oogst]

I found the function MovableObject::setRenderQueueGroup(), which seems to let me do exactly what I want do: first render the cable, then render the shadow without depth checking, and then render the rest of the scene. So I set the cable to group 4, the shadow to group 5 and the rest of the scene to group 10 (using setDefaultQueueGroup()). However, I now get this weird thing with the cable, as if its material is gone:



This is what the standard white material of Ogre looks like with my depth of field blur, so I guess the material is somehow gone. Just removing the line cable->setRenderQueueGroup(4); makes the cable look good again. I don't get this. How can the render queue group influence the material?

The queue does work for the shadow, though: even though depth check is turned off, it is rendered behind the noiseball instead of in front of it.

Would anyone know what is going wrong here?

@Shockeye:
I like the idea, but the problem with it is that the camera is almost exactly behind the object. So the hole in the torus would never be visible during racing. And without the hole, a torus kind of looses its charm, I suppose.

@sinbad:
Such a stretching sphere is what I have exactly right now, but only when you go into turbo! It is hardly visible, though, since the camera is too straight behind the sphere. I'll post a screeny as soon as I get the normals right: morphing meshes in Ogre don't seem to support morphing normals (WTF?), so I need to do some fiddling around to get the morphing to look good.

@xadhoom:
A power link would help show the position of the player on the cable more clearly , but it is also a very gamy-idea. I deliberately want the aesthetic of this game to not be like what 'normal' games look like, and power lines are definitely part of that. It's a bit pretentious, but that's the goal I have in mind with this game.

@Praetor:
Wow, a negative light, that is also a really neat solution for this shadowing thing! Clever, me like! However, the vehicle is the only object that gets real-time lighting in the scene at all, so adding a light to all my shaders is a lot of work. Just using the quad as I do now seems a lot quicker to implement for me at this point.

[xadhoom]

I'll post a screeny as soon as I get the normals right: morphing meshes in Ogre don't seem to support morphing normals (WTF?), so I need to do some fiddling around to get the morphing to look good.

/** Set whether to automatically normalise normals on objects whenever they
are scaled.
@remarks
Scaling can distort normals so the default behaviour is to compensate
for this, but it has a cost. If you would prefer to manually manage
this, set this option to 'false' and use Pass::setNormaliseNormals
only when needed.
*/
virtual void setNormaliseNormalsOnScale(bool n) { mNormaliseNormalsOnScale = n; }

[Oogst]

I know how scaling and normals work, but I was talking about morphing: vertex animation. I've tried various 3dsmax exporters and they all only export vertex positions in the animation. Normals are only exported for the base model (at the first frame).

[xadhoom]

Ah, yes!
Thats a recent feature request (as a side note): http://www.ogre3d.org/forums/viewtopic.php?f=3&t=52554

xad

[sinbad]

This is what the standard white material of Ogre looks like with my depth of field blur, so I guess the material is somehow gone. Just removing the line cable->setRenderQueueGroup(4); makes the cable look good again. I don't get this. How can the render queue group influence the material?

It can't, but it can affect what gets rendered into your compositor, check the options on the render_scene pass for start & end queues.

[Oogst]

I am not sure I understand how that can be the cause of the problem here? I don't use a compositor: I wrote my own system for post effects before the compositor system was in the engine. And the cable gets rendered, just without its material. Would the option you mention cause the object to be rendered, but without its material?

[Oogst]

Okay, this is weird. Using renderQueues 10-11-12 fixes the problem. RenderQueue 1-2-3-4 render all objects in white, without their materials. RenderQueue 5 renders objects white in parts of the scene. Really weird. Check this:



The cable does not a multi-pass material and I do not use a compositor here. This only seems to happen in renderQueue 5. Definitely looks like either a bug or a really weird feature to me. Does someone know what is happening here?