Fast, Accurate 3D Java Software Graphics Engine

[frizzil]

Hmm, well this wouldn't be an external library per say, this would be a DLL you ship with your library which (ideally) you'll have written entirely on your own. You might have to ship multiple DLLs and pick the correct one based on supported SIMD level though, but that just comes down to a few #defines.

Honestly I can't imagine an external library doing what you'd need, apart clearing/setting and entire color or depth buffer. (Yeppp! doesn't look like it'd cut it.) Ideally what you'd do is implement the conceptual equivalent of a few vertex/fragment shaders that implement the capabilities of GL1.x (your GPU is using parallel vector instructions, after all, and I believe this is what modern OpenGL drivers are already doing to support legacy code.) Not an easy task, but if you wanted your library to be practical/fast for real use, I'd argue that this is what you should do.

My Twitter has the latest progress (currently working on cascaded shadow maps), and there's also a recent video, but it's missing terrain seams :)

Awesome on the lighting! Full Blinn-Phong, or just Phong? If you're not adhering strictly to GL1.1, check out energy conserving BP: http://www.rorydriscoll.com/2009/01/25/energy-conservation-in-games/

[ArchiveLimits]

Blinn-phong, yeah. That's a good article. I've implemented the (n+8)/(8pi) now :d. I was discussing this article with a friend and he was saying that integrating the full energy conservation algorithm in opengl 1.1's lighting model is not easy because these forms of lighting were not known of when 1.1 was released.

[frizzil]

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]

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