choo choo! Get on board the rant blog :)

"So we grab the screen, blend that with the screen effect, and chuck that back up on screen. Simple!"

Translated:

"So we resolve the rendertarget (16bpp @ 1280x720x2XMSAA ~= 1.8ms), create a material effect that consists of a custom photoshop style overlay blending of the screen with some gore effects dripping down the screen and writing that back over the rendertarget paying 100% fill cost (1.9ms). Slow! (~3.7ms for a simple gore-on-lens effect)"

With most engines (proprietry or otherwise) now giving easy access to arbitrary buffer useage and art controlled malleable render pipelines, I'd like to make a taboo suggestion or two.
Maybe "last-gen" techniques and methods shouldn't be restricted to the last generation of hardware, and ignored when creating this generations games.
Maybe we should try and use the free 15 year old hardware functions before we re-invent it on a per pixel basis.

The above is a real example from a few years back, and here was the solution:

- Don't resolve (free ;) )
- Use a stencil, or draw an object over the screen which has been cut into the shape that the material can touch (minimise fill)
- Write material effect and change the blend mode to 2x multiplicative blending (visually identical to the custom blend. Most common photoshop blend modes can be emulated with hardware blendmodes)
= ~0.6ms

The original used dynamic branching conditionals to do the overlay blend effect, so that anything above 0.5 would multiplicatively brighten, and anything below would darken (leaving 0.5 doing nothing).

The equivelant is changing the hardware blendmode to the classic 2x multiply:
dest = (sourceRGB*destRGB) + (destRGB*sourceRGB);
which can be broken down to:
dest *= 2*sourceRGB;

I expect this to be the first of many posts on the subject of simulating the appearance of skin and other organic/translucent materials. It's definitely one of the fields I'm quite interested in, and it's far from being a solved problem (even in film).

The story so far...
There has been some decent approaches to realtime simulations of skin in the last 4 years, none of which seem to give both good visual results and generalized approach; it's one or the other. And certainly not very realtime in the context of games - more so "interactive" in isolated tech demos.

- NVIDIA human head
- PRT
- depth based splatting/raymarching
- custom light functions (wrapped lambert, biased normals, etc)

all have their pro's and con's. I've personally been quite unsatisfied with each one as a general solution for in-game lighting schemas... they work quite well in limited applications, but don't map very well to The General Solution for a title.

So... What now?
We innovate, share, and Frankenstein of course!
I definitely don't have a solution to this issue that covers everything I'd like it to, but I'll share some work over the last four years I've done and hopefully throw some new ideas and discussions into the pot.

Some pic's
Image 1
Image 2

This is a method I came up with about 3 years back which uses a pre-process to bake translucency coefficients into weighted vectors, and then use them in a similar way to tangent space normal mapping. It's like a very low-tech PRT, but a lot more flexible. The basic steps to get the data are:
1) using an offline renderer or your own tool (I used 3DSMax's in-built radiosity renderer for these shots, but I'm now using Vray), set up a light rig with +xyz=rgb lights
2) set up your translucent material and get it looking correct
3) bake these first 3 axis weights (+xyz)
4) bake the opposite direction axis weights (-xyz)

From here there's a lot of different things we can try to get the data into different formats for use - reducing the memory/resource footprint, or preparing it for easier mapping into your existing lighting format.
Since we can convert the data from world space to tangent space, animation can work just like on normal maps. We have the choice of storing it in vertex channels or per pixel in textures. You can even store it as a difference between the normal mapped asset in a variety of ways (manhattan distance for example). It's also very very cheap on the gpu - rolls into a regular lambertian tangent space normal map lighting model quite nicely. The general method I use only adds 4-6 ALU on the vertex shader, and 3 ALU on the pixel shader.

Well I recently set up google analytics, and apparently I get a decent amount of visitors per day - some are repeats, so I kind of feel sorry for those chaps who have been coming here and not getting any updates for years on end.

Hence the blog.

It's baby steps; this whole blogging thing is new and quite foreign to me. I'd like to call it less of a blog, more of a "journal with stuff" instead - I guess I don't really consider myself as hip as all the cool blogging kids :)

My little resources>hlsl log is out of date by around 4+ years, so I figure I can use this to post thoughts and ideas worth sharing instead (I'll eventually get around to deprecating that resources page).

So stick around if you're interested in graphics and r&d into graphical techniques.


Did you know?
The shader intrinsic 'smoothstep' can be evil and expensive. Write the equivelant yourself, or use something in hlsl like:
const float X = 0.4;
const float Y = 0.6;
const float Range = 1 / (X - Y);
float result = saturate((Source - X) * Range);
Give it a go, and profile against it. This maps up to 4 components at once, and you can precompile the constants out when possible (which smoothstep sometimes bungs up the compilation of).

Hello World!

It's alive!