[Bf-gamedev] Directional lightmaps and light probes

[David Rosen]

Thanks for all the suggestions! I'll start by going into a bit more detail
about what I am talking about, starting with light probes.

Historically, iirc the first light probes where physical ping pong balls
and ball bearings placed in front of the camera on a film set to get an
idea of what the diffuse and specular light looks like in the scene, so
that the same lighting can be mapped onto CGI objects. The modern game
equivalent is cubemaps: 90-degree square renders of the scene along each
cardinal axis, processed into a series of mipmaps from perfectly reflective
(no processing needed) to perfectly diffuse (90 degree blur applied). These
cubemaps are baked at representative points in the level. Typically there
is a dense grid of diffuse light probes, and a sparser grid of reflective
probes (because they are much more detailed and thus require more memory).
When the game is running, dynamic objects sample the nearest probes to
match the lighting of the static objects as closely as possible.

Light probes are pretty easy to calculate in-engine by essentially just
taking screenshots and applying blurs, so I'm not sure why I brought it up
here really -- it would be a nice feature for anyone using BGE though.

The more difficult feature is directional lightmaps. Right now it seems
that if you bake the lighting using cycles, it stores the results as a
single RGB value at each texel. The diffuse and specular equations are
already solved, and baked into the lightmap. This is fine if you're making
a game that has no normal maps, or normal maps that are lower-resolution
than the baked lightmap. Modern games typically have very high-resolution
normal maps, however, so it's important to store some directional
information about the light as well, so that the final diffuse and specular
equations can be solved per-pixel in real-time. Basically, each texel in
the lightmap needs to act like a light probe, storing the accumulated
lighting to a low-res cubemap, spherical harmonics or even just a
linked-list of incident photons including their color and direction.

This would be especially useful for game developers, but could also be
useful for accelerating film rendering in certain situations. I'm guessing
it wouldn't be super hard to implement, since the information is already
calculated when the scene is rendered -- it's just a question of storing it.

-David


On Thu, Mar 12, 2015 at 8:14 AM, Marc Dion <marcdion1974 at gmail.com> wrote:

> @ Derek, I think this does belong either here or there, but I think it
> does belong here just as much as there.
>
> Without a Shadow Catcher BSDF, Cycles baking is not much use for normal
> Cycles rendering.  At this point I think anything to do with baking is
> really only useful for game development.  This means either BGE or external
> game engines hence ->Bf-gamedev.
>
> Not sure migrating the topic over to another list changes much at this
> point, at least not without a definite plan of action regarding how Cycles
> should be modified/expanded.
>
> A task/patch page created on developer.blender.org should be a good place
> for details, progress, etc... something similar to the following by Lukas
> Stockner. -> https://developer.blender.org/T38401   (Well, maybe once
> there are solid details in place :)
>
>
>
>
> _______________________________________________
> Bf-gamedev mailing list
> Bf-gamedev at blender.org
> http://lists.blender.org/mailman/listinfo/bf-gamedev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-gamedev/attachments/20150312/46bc14c6/attachment-0001.htm