ProfL

it makes me always sad to see how some people and companies try to handle languages and libs like religions
I like c++, yet for WP7 and Xbox-Indie I'd be forced to one particular language, although there is no reason something else wouldn't run. just like they've tied DX10 to Vista and a lot of morons spread the word "it's for technical reason, superior driver model and..." while every programmer knows that an API is just a thin interface, not really related to a driver model or internal implementations (that's why there is an interface).
While I'm sad for you XNA guys if it would be really true that it 'dies", I hope people learn from it, to not stick to one language, to one api, one lib, especially if it's build solely by one company and their marketing department.
Standards are the way to keep your freedom of choosing what and how you want to develop.

crossing fingers for you XNA fans

In general, you should prefer methods that do not cause side effects.

do you imply that a function that is supposed to calc something based on members, is having side effects although it's on purpose?
otherwise I'm confused what you could possibly mean, could you make your reply more detailed?

that depends on the art and raytracing quality.
quite often you can combine both, rendering forward the usually ray to get a gbuffer and then use the gbuffer and raytrace all market pixels/fragments for reflections etc.

I have to disagree, bi-directional path tracer should have a faster convergence, if you have smaller lightsources. They are kind of bad for light domes (IBL).
I mean, the noise is mostly visible in the in-directional areas, it shouldn't be like that. You might end up with some fire flies if you add specular surfaces, tho.

I'm not sure what your error is, but if both images converge to different result, it's clearly wrong. My wild guess would be that something is wrong with your probability calculations. check out:
http://graphics.stanford.edu/courses/cs348b-03/papers/veach-chapter10.pdf
and additionally
http://www.sjbrown.co.uk/2011/01/03/two-way-path-tracing/

your GPU just executes one render job at a time, spreading it to multiple rendertargets will rather make it slower than faster, as it has to switch at least twice. also notice that you cannot just use two threads to render with one device, you need to create a deferred context with DX11, which just records your commands, once you're done, you still submit it from the main context, so it won't make any difference, unless you are really CPU bound while creating your draw commands.

there are some interesting paper about this, indeed.
best so far that I've found: http://research.microsoft.com/en-us/um/people/hoppe/perfecthash.pdf

I think I understand how it's done now. If all of the triangles are CW or CCW the outward pointing normals can be calculated correctly.

My terrain is rendered using triangle_strips, which changes the ordering of the triangles for each row. So I think in order to calculate my normals I need to swap the way I calculate the normals each time I change rows (which changes CW/CCW ordering).

I intended to optimize my index buffer for gpu cache coherency in the future. I suppose I should look into that before I hard code how my normals are calculated. Any tips on that are appreciated =)

keeping the order is especially important to have backface culling running, this saves you 50% of the rasterized pixel, low hanging fruit everyone should use (except on PS2 )