Stylized rendering

[Shifty Geezer]

This thread is spawned from the GI thread in the tech forum. I'm not quite sure what'll happen in it, but it's here to discuss stylised rendering, effects used now and before, effects that could be used in the future, etc.

As examples, I guess the most obvious is Okami on PS2, being totally unique and very effective.

Then you have the now quite common cartoon shading which can work very well. In DQVIII it does look very like a cartoon and I can't wait to see next-gen consoles render the same style but with buckets of AA and IQ enhancements.

From the tech thread, the idea of using a colourless Ambient Occlusion only renderer was suggested. Any thoughts on if that'll be possible next-gen (or this gen, I'm confused...) to some degree? Are the savings on pixel shading and texture requirements going to be applicable to AO rendering, or will they just represent unused capacity in the hardware.

And, um, what other examples are there, from previous games, or offline renders? Anyone got any favourite non-standard rendering techniques to share? I'll add a couple of offline styalized renders I produced years back to stir up ideas. These are 3D scenes that could be animated as such, and should be easily doable in a realtime game situation. The question is whether you'd want to or not! Thoughts please!

 

[TheChefO]

Interesting thread, Thanks Shifty - I can't wait to hear what the devs have to say on potential future uses.

 

[Squeak]

Those renders are not half bad Shifty! The first one is already pretty Okami-esque but a 2d game could be done in the style I suppose. The other one could could have some interesting uses. Titles such as "Electron Microscope Warrior" and "Immune system RTS" pops into my mind.

 

[AlNom]

And, um, what other examples are there, from previous games, or offline renders? Anyone got any favourite non-standard rendering techniques to share?

How about Max Payne 2's bullet time? All the colours became brownish, and lighting seemed to become more intense.

 

[standing ovation]

Lately, the most arresting (pen & ink) animation that I've come across combines 2D and 3D elements, like the New Super Mario Bros. on Nintendo DS with 3D characters in a 2D world. But the Japanese film "TEKKON KINKURITO", which places 2D characters in a seemingly 3D world, is even more attention-grabbing.

 

[Synergy34]

I wasn;t a big fan of the game but I really did enjoy the visual style of Mark of Kri. Had a nice old school Disney look to it.

 

[StefanS]

Stylish games:

Zelda: Windwaker
ICOs
Viewtiful Joe
Naruto Beat em Ups

 

[_phil_]

killer7.BTW ,the team is on the road for a ps3 title withsome special rendering style.

 

[aselto]

Jet Grind Radio and Jet Set Radio Future. The latter still looks awesome, I played it this week.

 

[Squeak]

Nobody has mentioned REZ. It's a good example of non cartoony stylization.
I wish someone would do an even "cleaner" version of that style, so it would look exactly like an old colour vector scan display, complete with really good AA (vector scan didn't have AA problems) and slightly brighter endpoints of each stroke.

 

[_phil_]

Nobody has mentioned REZ. It's a good example of non cartoony stylization.
I wish someone would do an even "cleaner" version of that style, so it would look exactly like an old colour vector scan display, complete with really good AA (vector scan didn't have AA problems) and slightly brighter endpoints of each stroke.

i'd love a nextgen REZ !

 

[OtakingGX]

How about rendering a game so it looks like a pencil drawing on paper?

 

[pc999]

Noir games (like Sadness will be).

 

[DudeMiester]

The biggest challenge with good NPR is imho the edges of objects. Getting the right sillouhette, with smooth lines and texture is probably more important then the fill colour. However, GPUs are designed exactly the other way around. Great at filling polygons, but not so much when fiddling with their edges. The main problems are the fact that you pretty much have kill pixels in the shader but still have AA (selective super sampling maybe?), you've got complex calculations to make sure the lines flow correctly and find silouettes, and you need good tesselation to keep the results smooth. I think with NPR, smooth models and lines are much more important then with realistic rendering, because cartoony animation is all about form, curves and shape. This creates considerable pressure on the vertex shaders. Of course, this all can be done one way or another, but it will take quite a bit of GPU horsepower. The consoles may have enough though, but I don't think it would be by much.

btw, I'm speaking in terms of doing NPR by direct rendering instead of relying on pre-baked textures and 2D billboards/sprites everywhere.

 

[ShootMyMonkey]

The biggest challenge with good NPR is imho the edges of objects. Getting the right sillouhette, with smooth lines and texture is probably more important then the fill colour. However, GPUs are designed exactly the other way around. Great at filling polygons, but not so much when fiddling with their edges.

In one of my undergrad SIGGRAPH projects, we got around this issue mainly by treating the source geometry rather than a trilist, as a point cloud which defined the data to drive what was essentially a special-purpose particle renderer.

Still, had some decent results, even though the nature of the render scheme itself is extremely geometry heavy and requires a LOT of alpha-blended fillrate -- it still rendered at an *okay* clip (around 14-40 fps depending on the scene back in the days before programmable shaders)... Granted this wasn't anything but a viewer running in a 640x480 window, but it was a dual-pass render on hardware that would be arcane by today's standards -- one render-to-texture pass with the base geometry with regular old lighting to sample color information, and the actual displayed brushstroke render.

 

[_phil_]

i love that.
demo here :
http://www.acm.uiuc.edu/siggraph/eoh_projects/eoh2000.html

 

[StefanS]

That looks really good, like a painting. I could imagine playing a game that looks like that.

 

[ShootMyMonkey]

BTW, you can also get the paper (PDF) here --
http://chiranjivi.tripod.com/aEmber2.zip

I would be interested to see how it handles on modern hardware with all nature of techniques specifically to render large numbers of particles. The grass huts scene had source geometry of around 288 triangles, but it ends up having to be something like 11,000 brushstroke particles. And though we do have such a thing as backface culling, we also cheated a bit on the scene geometry (those huts don't have a back). Drawing tens of thousands of alpha blended quads (which in turn means that stripifying geometry isn't really possible vertex:tri ratio of 2:1) and all the overdraw is a necessary evil. That's what makes it die for the most part.

I get about 1 fps on my home machine, though I do have a pretty ancient video card (NV10). I'd like to see how it runs on my machine at work (7800GT), though I don't expect any major miracles -- I've seen it go okay on NV18 as well as Voodoo5 cards, but never really seen what people get on better hardware.

 

[fearsomepirate]

There was a non photoralistic mods for Quake running around that didn't require too much hardware power. The best one made everything look like a sketch.

http://modetwo.net/users/nachimir/vga/media/npr-quake-002.jpg
http://modetwo.net/users/nachimir/vga/media/npr-quake-002.jpg
http://modetwo.net/users/nachimir/vga/media/npr-quake-002.jpg

 

[ShootMyMonkey]

There was a non photoralistic mods for Quake running around that didn't require too much hardware power. The best one made everything look like a sketch.

That mod appears to do its job via simple texture replacement.

BTW, I ran a little test on the demo on the 7800GT I have at work. The fruit scene runs relatively well averaging a little over 100 fps. The grass huts which is a somewhat larger scene containing larger brushstrokes ran in the 60-70 fps range. The second largest scene in the demo, the "MeierFruit" scene ran pretty awful. Down around 15-20 fps. The fillrate is scaling pretty linearly with stroke count and the framerate is going with it. Granted, the code is far from optimized -- pretty much zero batching as the two prior versions were ripped apart and the 3.0 version was written in an all-nighter before we had to present at New Orleans -- so you're also getting the fun of API call overhead on every particle, IIRC.

Since there weren't images of the "MeierFruit" scene before, I put one up... part of the reason it's so demanding is the fact that it ends up dedicating a huge number of brushstrokes to that ground plane, and you get your loads and loads of overdraw.
http://www.thepolygoners.com/nickb/MeierFruit.jpg

Comparatively speaking, the vase scene, which is actually much larger still, uses a surrounding box to hide lack of brushstroke coverage so you can use smaller brushstrokes on the background, and hence save fillrate. Even though it's a few thousand strokes larger, it runs a little over twice as fast as the Meierfruit scene --
http://www.thepolygoners.com/nickb/VanGoghVase.jpg