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.

This year's buzzword: Image-Space

It shouldn't be news that the quality of publications done at Siggraph has been going progressively worse, in the last years, and other conferences are becoming more and more important, Eurographics, but also Siggraph Asia (see for example, those really neat publications).

A lot of politics, sponsors, pressure from universities, younger reviewers... Nowadays Siggraph is more an occasion to meet people and see what's going on in the industry, than a showcase of the best graphic research on the planet.

I didn't see anything groundbreaking, and a lot of publications were addressing problems that are not, in my view at least, so crucial. Still I don't think this year Siggraph's was bad, and you'll find plenty of coverage of the event online, so I won't write about that.

I have the impression that the non-realtime rendering, and GI in particular, has seen a slowdown recently, but it may also be that my interest shifted away from those subjects, so I don't have a good picture.

To me what's more interesting, at least now, is realtime graphics, and I'm probably more sensitive to publications in that field. At the main conference unsurprisingly, the most exciting realtime 3d presentation was done by Crytek (see this) but I was really looking forward for the papers of the HPG, one of the Siggraph's side-conferences.

Generally, there is some pretty good stuff there, like the Morphological Antialiasing paper, and many others... But you have to filter out the buzz and I was really bothered by some papers that, in my opinion, simply should not have been there. I don't know really why they bother me, probably it's also because I've seen published some ideas in the past, that I didn't bother to publish thinking they would have been rejected anyway, or maybe it's just that I have too many friends in the research community with good ideas and little luck.

Hardware-accellerated Global Illumination by Image Space Photon Mapping. Wow! Let's read...
And what's that? Well, if you've followed any GPU GI research in the last 1-2 years, it's really easy. They're using a RSM for the first-hit of the lights, they read it back in CPU and use that data for normal photon tracing (claiming that the slowest part is the first-hit, so they care about doing only that in GPU), then they splat the photons using... photon splatting.

It's mostly a tech-demo, it would be cool if they published it as such, maybe with better assets it could be a worthy addition to the other demos NVidia has. Maybe they could have published this applied research in NVidia's GPU Gems. But Siggraph?

Why "image space" anyway? And the worst part, why they don't say "RSM" or "splatting"? They cite those works as "related research", and that's it. They don't use any of those terms, they replaced everything with something else that makes it sound better and new... Photon splatting sounds slow, let's use "Image Space", is way more cool (doesn't matter if there's nothing happening in image space there). RSM are well-known... let's call them... bounce maps (genius)!

Image Space Gathering. Even worse! And it came just after the previous one in the HPG conference! It's something really minor, the only application seems to be blurry reflections, and from the images it doesn't look so nice for that either.

The algorithm? Render your image, and then blur it. But hey, preserve the edges using the Z-buffer, and make your kernel proportional to that too. Wow! Don't blow my mind with such advanced shit man!

They say "image space" and "gathering" and in the abstract,they also use "cross bilateral filtering". The idea is simple and little more than a not-so-neat trick, a curiosity with limited applications. But there's the buzz!

I think it would be easy to write a buzz-meter, check for the frequency of some keywords in the abstracts and build a filtering system that intelligently filters all the noise...