search

open-stage / blender-dmx

Blender addon to design and render DMX lighting.
GNU General Public License v3.0
195 stars 14 forks source link

Cycles: The problem with Collimated Beams #7

Closed hugoaboud closed 5 days ago

hugoaboud commented 3 years ago

Rendering collimated light beams in Blender is hard. Since this is fundamental for achieving good results with "Moving Beam" fixtures, I'm looking for the best solution. This issue outlines the problem on Cycles. I'm not sure how Eevee deals with it, however it does a reasonable job, except for the light source radius.

A collimated beam is one where the rays are parallel to each other. In real life fixtures the emitter has a size, so the beam angle is measured like this:

beam angle

In Moving Beam fixtures it's usual to find angles in the range α = 2~5°. However setting such narrow angles in Cycles causes an erratic sampling, even with high sampling values.

image

The light beam luminosity decreases, while the luminosity it causes in surfaces remains the same. In reality, this would probably increase (more light focused on a single point). In order to be able to see the light beams in the volume scatter, the intensity should be set to unrealistic values, which causes unrealistic features on the surfaces hit by those beams.

Also, the light beam seems weaker near the source, and it's intensity grows with distance. This is the opposite of what a moving beam looks like.

After some research and messing around with Blender Shade Nodes, I think the problem might be in the relation between the Volume Scatter shader and the raytracing technique employed by Cycles. In Cycles, rays are traced from the Camera into the scene. So, in order to control the beam angle you calculate the angle between the Incoming Ray and the Face Normal, if it's below a given threshold, that material appears lit.. So, as you decrease this angle, the scattered incoming rays are less likely to be within the threshold. This way, less volume points are lit by this source. This accounts for the reduced intensity on smaller angles. Small angles such as 5° = 0.087deg make the material neraly invisible for volume points close to the surface.

I must research more on the principles of Volume Scatter so I can figure out a way to make it better. As for the problem of constant luminosity on surfaces while reducing the beam angle, this can be compensated with a formula. Since the conversion from GDTF power units to Blender units stills needs to be tested an discussed in a separate issue.

schroef commented 2 months ago

Have you thought of submitting this as a bug for Cycles?

vanous commented 2 months ago

I don't think anyone has reported it.

schroef commented 2 months ago

Well perhaps do that with the example you showed. You can always try, right

vanous commented 2 months ago

Well perhaps do that with the example you showed. You can always try, right

Feel free to take this up in the Blender tracker.

nrgsille76 commented 3 weeks ago

It is possible to compensate this issue by taking the beam angle into account for calculating the energy. The formula for this is energy / beamangle² (beam angle in degrees) * 100 (100 to convert power(watts) to lumen, it matches with most LED sources) In the code it would be:

luminous_flux / pow(beam_angle, 2)

vanous commented 5 days ago

It is possible to compensate this issue by taking the beam angle into account for calculating the energy. The formula for this is energy / beamangle² (beam angle in degrees) * 100 (100 to convert power(watts) to lumen, it matches with most LED sources) In the code it would be:

luminous_flux / pow(beam_angle, 2)

This actually makes sense. Presumably, the beam definition in Blender is "static", thus any dynamic beam behavior is to be handled with the dynamic behavior initiator. Feel free to provide a PR, i will close this now as this sounds like a plausible explanation of the issue.