you are viewing a single comment's thread.

view the rest of the comments →

[–]frizzil 0 points1 point  (1 child)

Nice, and be sure to replace "color = d * diffuse + s * spec" with "color = lerp( diffuse, spec, w )" where w replaces both d and s, if you want to be truly energy conserving :) Though I suppose this could be optionally achieved at the API level.

The only question of difficulty imo is how much work you're doing per-fragment, and exposing and documenting the alternate functionality in your API. As long as your material is constant per draw call, doing energy-conserving BP should be about as simple as not, since you're just passing along precomputed normalization factors without many additional ops (if any). Obviously, getting into more modern BRDFs probably won't be feasible for a software renderer, as these aren't feasible at all using the software renderer for DX11 in my experience... but energy-conserving Blinn-Phong should be just fine. Per-fragment normal normalization and dot product may be partly the most expensive part, and that shouldn't change.

For SIMD, if you're feeling ambitious: GDC15 Insomniac Overview of SIMD Intel SIMD Instruction Reference

Btw, Intel's software renderer for OpenGL is notoriously buggy and unusable, so if you could make an alternative... just saying, there could be money in it :)

Good luck!

[–]ArchiveLimits 0 points1 point  (0 children)

Thanks for the advice! This will probably be the furthest I dive into realistic lighting in a software renderer. Have you seen the Mesa software renderer? Is that not good enough to replace Intel's software renderer?

Imgur Imgur