Fix for FXComposer 2.5 clear bug

The new Nvidia FXComposer is still mostly made of dog poo. Sorry, but it's an application that adds zero useful features, and a tons of bugs. Well not really, shader debugging would be useful to me, but I tried to debug my posteffect, made with SAS, and it failed miserably, so...

Unfortunately, FXComposer 1.8 is getting really old nowadays and sometimes it crashes on newer cards... so I'm forced to juggle between to two to find the one that has less bugs...

One incredibly annoying thing is that 2.5 on XP does not clear the screen, if you're using SAS at least. It doesn't work both on my Macbook 17'' and my Dell Pc at work (nothing weird, two of the most popular products in their categories, both with NVidia GPUs), so I had to find a workaround. Ironically, they seem to have so many bugs in SAS just now that for the first time since the beginning of FX composer, they released a little documentation about it... So now you kind of know how to use it, but you can't because it's bugged...

If you're having the same problem, here's my fix. I hope that NVidia engineers will make this post obsolete soon by showing some love for their product and fix this, as it's such a huge bug.

#define USEFAKECLEAR

[...]

struct FSQuadVS_InOut // fullscreen quad
{
float4 Pos : POSITION;
float2 UV : TEXCOORD0;
};

FSQuadVS_InOut FSQuadVS(FSQuadVS_InOut In)
{
return In;
}

#ifdef USEFAKECLEAR
struct FakeClear_Out
{
float4 c0 : COLOR0;
float4 c1 : COLOR1;
float4 c2 : COLOR2;
float4 c3 : COLOR3;

float d : DEPTH;
};

FakeClear_Out FakeClearPS(FSQuadVS_InOut In)
{
FakeClear_Out Out = (FakeClear_Out)0;
Out.d = 1.f;

return Out;
}
#endif

[...]

#ifdef USEFAKECLEAR
pass FakeClear
<
string Script =
"RenderColorTarget0=ColorBuffer1;"
"Draw=Buffer;";
>
{
ZEnable = true;
ZWriteEnable = true;
ZFunc = Always;

VertexShader = compile vs_3_0 FSQuadVS();
PixelShader = compile ps_3_0 FakeClearPS();
}
#endif

Calling for a brainstorm

Problem: Depth of Field. I want bokeh and we want correct blurring of both front and back planes.

Now I have some ideas on that. I think at least one good one. But I'd like to see, in the comments (by the way, if you like this blog, read the comments, usually I write more there than in the main post) your ideas for possible approaches.

Some inspiration: rthdribl (correct bokeh, but bad front blur, slow), lost planet dx10 (correct everything, but slow), dofpro (photoshop, non-realtime).

Words (and publications): gathering, scattering, summed area tables, mipmaps, separable filters, push-pull

I have developed something out of my idea. It currently has four "bugs", but only one that I don't know yet how to solve... The following image is really bad, but I'm happy with what it does... I'll tell you more, if you tell me your idea :)


Update: The following is another proof of concept, just to show that achieving correct depth blur is way harder that anchieving good bokeh. In fact you could have a decent looking bokeh even just using separable filters, the first image to the left just takes twice the cost of a normal separable gaussian, and looks almost as good as the pentagonal bokeh from the nonrealtime photoshop lens blur (while the gaussian filter, same size, looks awful)


Second Update: I've managed to fix many bugs, now my prototype has a lot less artifacts... I don't know if you can see it, but the DOF correctly bleeds out, even when the object overlaps an in-focus one. Look at the torus, the far side shows clearly the out-bleeding (as you can see an artefact still along the edges...). Now you should be able to see that the very same happens for the near part (less evident as it doesn't have problems, I dunno why, yet), and it doesn't shrink where the torus overlaps the sphere.

You should already know...

...that singletons are a bad, baaad, bad, idea: The Clean Code Talks - "Global State and Singletons"

It's interesting how people think that globals are bad, but singletons are not. They are the same thing, but still, internet noise can really destroy your brain.

You're told that globals are evil, and you're told that design patters are good. There is so much noise about that, they just become facts, with no need of reasoning around those.

Singletons are a design pattern (probably the only one you really know or seen actually used), so they're good.

Now try to remove that brainwashed ideas from your programmers minds... They won't believe you so easily, everyone loves design patterns (in my opinion, they're mostly crap), but you can use internet at your advantage. The video I've posted is on youtube, and done by google. That should be a very powerful weapon. Enjoy.

Code quality

Sooner or later, in every company there will be a discussion about code quality, how to monitor it, and how to make engineers care more, design and produce better code. How to massage and hone the existing one into more improving its quality...

Well it's everything very useful but sometimes we go to much into the details and lose focus on the only thing that really matters. What we always have to remember is that code rots, and it's inevitable.

It's up to your company to come up with a balance between how much effort you have to spend on design and maintenance, you can make quick and dirty hacks that will rot fast, or well designed software that rots slower but won't hit the target (because it moved somewhere else while you were designing for it)...

Or you can be smart and do iterative development with many short cycles and a lot of refactoring. In the end, the only thing you really want to avoid is to stick with only one pair of shoes for the rest of your life.

Make your code perishable, plan for its death, do not rely on its existence. Modules, interfaces, dependency control, that's your only goal when you're thinking about long-term. You have to be able to throw away everything.

The added bonuses of designing code this way are everywhere. You can throw less experienced programmers to a feature just because you know that it won't affect anything else than itself, and it can be replaced later on. Good code won't be built on top of bad code, bad code does not spread. You can create DLLs and achieve faster iteration. Your compile/link times will be faster and you can create testbeds with only the features a given area needs. You can do automatic/unit tests more easily. You can multithread more easily, and so on.