magicstix

My pet peeve is not making it clear that variables are member variables, but that's more of a C++ism I guess than a C# one. The problem is someone reading your code will have a hard time telling what scope the variable is in without something like m_ or self. (as in the case of python) on the front of it. It's just a readability nitpick, but at work forgetting m_ or the less common using m_ for local scope variables is punishable by death. >:]

Why not use google protocol buffers instead? It'll be much faster and it has inter-language communication capabilities. The only drawback is the awkward build process.

Did you try CryZe's blend mode, AKA "alpha blending"?

it will never fade completely(theoretically), but it should get really close.

You've got to keep the 8-bit quantization in mind with regards to this.
If the background is 1/255, then when you multiply by 0.99, you still end up with 1/255 -- e.g. intOutput = round( 255 * ((intInput/255)*0.99) )

Instead of directly blending the previous contents and the current image, there's other approaches you could try.
e.g. you could render the previous contents into a new buffer using a shader that subtracts a value from it, and then add the current image into that buffer. This way you'll definitely reach zero, even in theory

Yes I tried Cryze's recommendation, however it didn't look right either. I like how color blending looks over pure alpha better anyway, since I can fade the individual channels separately and get a "warmer" looking fade that looks even more like a CRT. I see your point about the dynamic range, and I agree that subtracting would be best, except when you subtract 1 from 0 you still clamp at zero, so the accumulation buffer's dark bits would block out where the "new" accumulated yellow bits should go.

I think I'll try and get around the dynamic range issue by rendering into a second texture, one that's 32-bit float, instead of using the backbuffer. This is how it'd be used in practice anyway, so using the backbuffer for this test is probably not a real representation of the technique. Hopefully the greater dynamic range will let the accumulation eventually settle on zero.

Here's what I mean by the "warmer" look of using color blending instead of alpha, it looks a lot more phosphor-like:

This might actually be a precision problem. Are you using low-color-resolution rendertargets/backbuffer/textures (8 bit per channel) ?

I'm using 32-bit color for the backbuffer (R8G8B8A8) but 32 bit float for the texture render target. I didn't know your backbuffer could go higher than 32bit (8 bit per channel) color... When I try R32G32B32A32_FLOAT for the back buffer I get a failure in trying to set up the swap chain.

Maybe I need to accumulate in a second texture render target instead of the back buffer?


-- Edit --

I forgot to mention I've changed my blending a bit. I'm using a blend factor now instead of straight alpha blend, but I'm still having the same effect with not getting it to fade completely to zero.

Here are my current settings:

rtbd.BlendEnable    = true;
rtbd.SrcBlend	 = D3D11_BLEND_SRC_COLOR;
rtbd.DestBlend	 = D3D11_BLEND_BLEND_FACTOR;
rtbd.BlendOp	 = D3D11_BLEND_OP_ADD;
rtbd.SrcBlendAlpha    = D3D11_BLEND_ONE;
rtbd.DestBlendAlpha    = D3D11_BLEND_ONE;
rtbd.BlendOpAlpha    = D3D11_BLEND_OP_ADD;
rtbd.RenderTargetWriteMask  = D3D11_COLOR_WRITE_ENABLE_ALL;

/* .... */
float blendFactors[] = {.99, .97, .9, 0};
g_pImmediateContext->OMSetBlendState(g_pTexBlendState, blendFactors, 0xFFFFFFFF);

If I understand this correctly, it should eventually fade to completely black, since the blend factor will make it slightly darker every frame, yet I'm still left with the not-quite-black trail.

Does anyone know of any papers/blogs/whatever out there that discuss doing the projected-grid water approach with a sphere instead of a plane?

I'm using lat/long/altitude coordinates projected onto an ellipsoid for my terrain, and I have concerns that at high altitudes, the water horizon won't bend with the terrain horizon.

I assume this would involve line-sphere intersection tests instead of the line-plane tests in the projected-grid approach, but I don't really have any idea how to go about creating the screen-space grid so that it properly follows the curvature of the horizon...

I use bullet at work. It doesn't strictly *need* OpenGL unless you want to use its debug drawing functions (which I don't use, even though I use GL to visualize the data bullet produces). There's no reason you can't use it with D3D. IIRC though, one of the annoying things is that it won't build without opengl, even if you don't use the opengl functionality, though I'm not entirely sure about this (it may be that you only need the GL portion for building the examples).

Rastertek's tutorial would probably be able to explain it better than I can.


The main things to keep in mind are that you're no longer rendering to the screen, but to the texture. This isn't much of a change, since when you render to the 'screen' you're really rendering to a texture as well.

Once you've rendered to the texture, bind it to a quad that's whatever size you want and render it like a normal polygon. You can then use a shader or d3d's built in functions to scale and rotate the quad with standard 3D matrices. if you don't rotate it around the Y or X axes, it'll remain a "2D" quad.

Just make sure you render the quad last with depth buffering disabled, that way it will always be on top of your screen.