7
$\begingroup$

Maxwell Render has a feature called Multilight, where the integrator keeps track of which emitter contributed how much to the scene, so that lights can be dimmed or brightened without re-rendering. As far as I'm aware, this feature does not exist in Blender.

If you wanted to implement Multilight in Blender, you would need to keep track of the different emitters' contributions in the integrator. So to any ray is associated a series of numbers indicating the contributions per light, and afterwards these extra numbers are available to the compositor (so that the different contributions can be mixed and matched however needed).

My question is not about Multilight, but rather about a more general problem:

Is it possible (and if so, how) to associate in Cycles' integrator to every ray some extra piece of information, process it on every bounce, and have the result available in the compositor?

The Multilight case is an example of this, but here are two others:

  • calculate for every ray the total distance it has traveled from camera to emitter
  • keep track of how many times a ray has hit a certain object

For the first of these, I'm aware of the Ray length socket in the Light path input node, but I don't see how to keep track of all these things along an entire ray.

$\endgroup$
  • $\begingroup$ What about bounce light or indirect lighting,Will you track them too? $\endgroup$ – Omar Emara Aug 1 '16 at 17:50
  • $\begingroup$ @OmarAhmad - Yes. $\endgroup$ – Daan Michiels Aug 2 '16 at 7:11
  • $\begingroup$ Maybe it would be more useful to check the Maxwell integration for Blender called BMaxwell if it has the same feature as original. It wasn't updated for some time though, so this might not be related $\endgroup$ – Mr Zak Aug 2 '16 at 16:12
  • $\begingroup$ @MrZak - I see. I'm not looking to imitate the Multilight feature, though. I want to have other information than just color associated to a ray. $\endgroup$ – Daan Michiels Aug 3 '16 at 12:01
  • $\begingroup$ Related : blender.stackexchange.com/a/91760/29586 $\endgroup$ – Rich Sedman Nov 15 '18 at 10:23
7
+50
$\begingroup$

Simple Answere

This is not possible without changing the code of Cycles. ;)

More Detailed

While rendering, there is no data stored about the individual rays, only until the current sampling function returns. There are multiple images – passes – stored and are kept and accessible, but storing data for every ray would need hundreds of gigabytes for large renders. Reading such amount of data would most probably be slower than rendering.

By touching the source of Cycles you could average out additional information about rays into new passes, like the number of bounces or total ray length. This is what other renderers do probably.

Emulating Multilighting

LuxRender allows to create light-groups. The lighting of those groups can be changed later, their color or intensity to be precise.

This behaviour can be achieved in Blender by separating your light-groups onto layers and creating a separate render layer for each group.

In the compositor you could mix these without rendering. Rendering each layer again in the compositor would be easy with the designated button.

Example Scene

Example Scene

Compositor Setup

Compositor Setup

The pass of the lamps are multiplied with (2, 2, 2) and (0.5, 0.5, 0.5) colors. The same result is achieved when the strength of lamps are changed to 200 and 50 from 100:

Simple Render

Emulating Bounce Count Pass

You would have to create multiple renders with the limit of total bounces increased on each render. Subtracting those from each other one would get the amount of contribution a given bounce provides.

You could multiply 0, 1, 2, etc with the related contributions and sum those. Dividing the result with the sum of the contributions – the last render – would result in the contribution weighted bounce count average.

You could use the bigger than node to get where each bounce contributed at least a little and multiply them with the related 0, 1, 2, etc and get the maximum of those. This would result the maximum bounce count for each pixel.

Bouce Count Setup

Bounce Nodes

$\endgroup$
  • $\begingroup$ Thanks, Róbert, that's useful. I like your bounce count setup. Since it seems to be impossible to do this without a lot of extra rendering time, I might actually look into changing cycles' code... $\endgroup$ – Daan Michiels Aug 3 '16 at 12:03
  • $\begingroup$ Some of these renders could get away with less samples than the amount required for the full render. Changing the code, that would be awesome. A few additional render passes would be useful. Awesome would be the feature of node-able render passes: Not compositing the rendered image, but manipulating the values of the camera ray before getting averaged. The input for this node-tree would be the ray-data (bounces, length, light index, etc) and the ouput would be a set of render passes. $\endgroup$ – Róbert László Páli Aug 3 '16 at 12:58
  • $\begingroup$ Whoa, thanks! :) I did not dare hope to get the bounty. $\endgroup$ – Róbert László Páli Aug 8 '16 at 9:04
0
$\begingroup$

If you could isolate your emission sources and render them independently, then you could manage this in the Compositor via a Brightness & Mix/Multiply node set. The isolation per render image would basically allow you to render with the max amount of Rays that you would desire to sample.

At this point you could then take those images as image inputs, and mix them together based on Brightness levels which essentially is determined by number of bounces, and length of rays (The sum of all of these parts / The fruit of the render labor). You could also use Math nodes to determine a "Less Than" or "Greater Than" factor of brightness, and logically have the same basic controls over your renders that you just described in your example.

$\endgroup$
  • $\begingroup$ Yes, rendering the scene once for each light source and blending afterwards is a way to emulate Multilight (albeit at the cost of having to render multiple times, which might be costly if you have many light sources). However, I'm aiming for something more general. I don't know how to get the number of times a certain object was hit, for example, and treat the ray differently according to that. $\endgroup$ – Daan Michiels Aug 1 '16 at 16:10
  • $\begingroup$ By the way, I suspect the true answer to my question in general is "this is not possible with the requested amount of flexibility, or at least not without making changes to the cycles source code". I'm just hoping I'm wrong. $\endgroup$ – Daan Michiels Aug 1 '16 at 16:13
  • $\begingroup$ @DaanMichiels - I would suspect that you are right, however I was just trying to give a solution (at least one that seemed to work around the final result that would allow for compositor control) that I felt was doable with my limited understanding of both your question, and what I know of Blender. Hope it was helpful insight anyhow. As far as getting a range of the number of times a ray has hit an object, (albeit labor intensive) you could render out different colors based on the "Greater Than" factor on the Light Path node in Cycles, which would give you some color info for the same purpose. $\endgroup$ – Rick Riggs Aug 1 '16 at 17:33
  • $\begingroup$ Once you have your different color pass per light, you could logically break that down into brightness and intensity, etc... using the same basic principles that my answer describes. I agree this does not sound like a easy user workflow, but it sounds like it is pretty doable if you can think of your "Meta information" as color & brightness translated by Number of Bounces & Ray Length equivalence. $\endgroup$ – Rick Riggs Aug 1 '16 at 17:34
  • $\begingroup$ "You could also use Math nodes to determine a "Less Than" or "Greater Than" factor of brightness, and logically have the same basic controls over your renders that you just described in your example." How would you have the total ray-length? I think it is not possible. I also suspect that true average bounce count is not possible, only things like I have written in my answere, which are not mathematically the same. $\endgroup$ – Róbert László Páli Aug 2 '16 at 10:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.