Know your Z

What will the following two commented functions do? Will they break things? Could they be useful?

float4 VS(float3 pos: POSITION) : POSITION
{
float4 hPos = mul(worldViewProj,float4(pos, 1.0));
   

// OPTION A:
//hPos /= hPos.w;

// OPTION B: 
//hPos.z *= hPos.w / farPlaneViewZ;

return hPos;

}

Answer: They will screw with your perspective interpolation in different ways. 

Option A just gives the non-homogeneous space coordinates to the pipeline. It will effectively disable perspective interpolation on your texcoords, and I can't find much use for such a thing :) 

Option B is more tricky. If you do the math, you'll find out that it will force the Z-buffer to contain a linear depth value, as the Z-buffer stores z/w, and z ranges from 0 to far after the projection, so by multiplying by w and dividing by far, we get the resulting z/w to be z/far. 

Interestingly, it won't screw with texture coordinates as it does not touch w, so it could be really useful. 

There is a problem though, that at first I overlooked untill I received a detailed mail from one of my coworkers explaining my naivete. Now z is not linear anymore when interpolated in screenspace. and that could cause all sorts of artifacts where the z on your triangles does not lie on a plane anymore... But in some cases can indeed work fine, if your objects are tassellated enough and you don't get parallel walls close to each other... Shadowmaps for your characters for example...

Update: some interesting documents that I've found around...

This is basically the same idea as the trick "B" but going into yet another space. The article fails to account for the errors the system introduces, but in the comments you can read basically the same conclusions that I wrote here:

http://www.gamasutra.com/blogs/BranoKemen/20090812/2725/Logarithmic_Depth_Buffer.php

This is an analysis that suggest to invert the z with floating point buffers, that is a very common practice. It does make sense in terms of precision but it's really required by hi-z, because of the way it works.

http://www.gamasutra.com/blogs/BranoKemen/20091231/3972/Floating_Point_Depth_Buffers.php

And last but not least, this article shows the effects of triangle orientation on the z-fighting: http://research.microsoft.com/apps/pubs/default.aspx?id=79213

Threads, buffers and latency

This is interesting:

http://www.eurogamer.net/articles/digitalfoundry-needforspeed-tech-interview

It's a thing that I always suspected, but never tested. The next need for speed will ship with a single thread, without a simulation/rendering split, and that's because at 30fps that buffered split of one frame is enough to be noticeable in game.

How many frames of latency can you count in your game? Mine currently has at least three (maybe more, in subsystems that I don't master): sim->render, render->worker jobs, jobs->gpu.

Spam

An Italian coworker of mine just started a blog about authentic Italian food and the common mistakes that are made in North America.

Totally unrelated, but a nice read...

http://quatrofromaggio.blogspot.com/

Google reader sharing

Too busy at work. I couldn't even follow the recent Siggraph. But I still try to read and explore new stuff, so I figured it won't be a bad idea to share some of the stuff I read. This is my google reader sharing channel, it's young but I'll try to keep working on it.

http://www.google.com/reader/shared/c0de517e

This should also put an end to the "link collection" posts. That will also mean less posts in general but hopefully I'll be back to some more "quality" ones.