Seems that the question “do I need to multiply or divide by pi here?” should be considered as one of the most difficult in computer graphics. And it’s wonderful that there are some people who spent their time and wrote posts and source code on this topic.

https://seblagarde.wordpress.com/2012/01/08/pi-or-not-to-pi-in-game-lighting-equation/

http://www.rorydriscoll.com/2009/01/25/energy-conservation-in-games/

https://github.com/TheRealMJP/BakingLab

Have to add that the whole MJP’s series on baking lighting is wonderful

https://mynameismjp.wordpress.com/2016/10/09/new-blog-series-lightmap-baking-and-spherical-gaussians/

Advertisements

Grasping grains of information about new Wolfenstein and can’t wait to see/read the next year’s Siggraph presentation on its tech. Doom was one of the first titles that implemented a Vulkan rendering path and it seems that Wolfenstein is one of the first ones that uses this API. 30K draw calls, hail Mary full of grace! Volumetrics, async compute and, I’m pretty sure, tons of other great stuff!

And while we’re waiting it’s a great moment to refresh our memory and read what Doom’s rendering looked like:

http://advances.realtimerendering.com/s2016/Siggraph2016_idTech6.pdf

HZB

A good collection of links with info related to HZB occlusion culling (hierarchical z buffer occlusion culling). Like this method – very straightforward and rather effective.

http://blog.selfshadow.com/publications/practical-visibility/

http://rastergrid.com/blog/2010/10/hierarchical-z-map-based-occlusion-culling/

http://www.nickdarnell.com/hierarchical-z-buffer-occlusion-culling/

http://timhobsonue4.snappages.com/culling-visibilityculling.htm

Playing Order 1886 and it’s graphics is something that couldn’t be created without witchery and occult rituals =) Good reason to read some tech papers from Ready At Dawn:

http://www.readyatdawn.com/presentations/

And I must add one more link. This is a blog of Matt Pittineo, lead graphics programmer at RaD, and I’d say that this is an extremely useful and inspiring source of information if you want to learn something about modern graphics techniques (and the source code is very clean and easy to read):

https://mynameismjp.wordpress.com/

Things I don’t like about D3D9

I’ve been working with this API for quite some time and if at the beginning it seemed ugly and unfamiliar later I got used to it. Nevertheless, there are several moments that still causes pain.

  • Half-pixel (half-texel) offset. This is is well known topic but every time I write a posteffect shader I have to spend some time later to fix another bug related to this D3D9 feature (I’m just stupid, probably);
  • You have to use FOURCC to read the depth buffer. This is a problem because even in year 2016 you will find a user with a such “GPU-driver” combination that doesn’t support this extension.
  • The same bit depth for all render targets
  • We don’t have texture arrays. And it’s impossible to use such constructions in a shader:
sampler2D textures[8];
tex2D(textures[uniformIndex], texcoord);