search

appleseedhq / appleseed

A modern open source rendering engine for animation and visual effects
https://appleseedhq.net/
MIT License
2.19k stars 329 forks source link

Implement Light Near Start #314

Open dictoon opened 10 years ago

dictoon commented 10 years ago

See http://www.luxrender.net/forum/viewtopic.php?f=34&t=10529.

vidarn commented 10 years ago

Is anyone working on this? I'd love to give it a shot otherwise. :)

dictoon commented 10 years ago

Sure thing, start hacking! This is an interesting feature. You should check how it works with LuxRender and Cycles. I'd also be curious if Arnold has a similar feature.

I have no idea yet how to implement this properly and where to do it so you'll probably need to do some digging and experimentation.

Should I add you to the appleseed team?

vidarn commented 10 years ago

Great! I'll investigate how LuxRender and Cycles handles it :) It would be nice of you to add me to the appleseed team. Thanks!

dictoon commented 10 years ago

It would be nice of you to add me to the appleseed team. Thanks!

Done.

vidarn commented 10 years ago

Here's some initial thoughts on this. I've decided to focus on the "Light Near Start" feature first.

Arnold has this feature: https://support.solidangle.com/display/SItoAUG/Light+Decay The implementation is a bit more advanced than in Luxrender/Cycles (allowing you to adjust both the start and end of the light cone) but I believe for now just the near attenuation is enough for us? It should be easy to extend later anyway. :)

Cycles handles things a bit different than Luxrender/Arnold. There's a "Smooth" parameter in the "Light Falloff" node that achieves a similar thing but it fades the light as it gets close to the light source, not just clipping it. From the documentation: "Smooth intensity of light near light sources. This can avoid harsh highlights, and reduce global illumination noise. 0.0 corresponds to no smoothing; higher values smooth more. The maximum light strength will be strength/smooth" This might be a nice way of doing it. The fact that the user doesn't have to specify the value in world coordinates could be a plus. I will investigate it further and take a look at the code to see how they have implemented it.

It seems to me that the best place to add this would be as a common EDF parameter (like "Cast Indirect Light") since it would make sense to specify it separately per emitter. However, this would mean that it has to be added separately to each lighting engine (as far as I understand it) [EDIT: to handle the indirect light]. For now I will try and get it to work in the path tracer and worry about the other two later :)

vidarn commented 10 years ago

Hmmm. Never mind that last paragraph. I'm clearly not familiar with this yet. I will have to look into things a bit more before I know how to implement this properly :)

dictoon commented 10 years ago

I suspect that the Light Near Start (LNS) value is not honored during path tracing: when a path "randomly" hits a light source, the distance from the last path vertex to the point on the light source should be checked and the hit rejected if it's nearer than the LNS value.

I found out while playing with a scene that looks like that:

lns_bug

There are two light sources in this scene: one area light to provide the base lighting, and another area light that shines very strongly on the ground. I set a LNS value on this light, but there is still fireflies on the pyramid, indicating that the LNS value is not always honored.

vidarn commented 10 years ago

I must have overlooked something. I'm sorry! Thanks a lot for finding the error . I will investigate it :)

dictoon commented 10 years ago

Hehe no worries Vidar.

The problem is when a ray randomly hits a light source, here: https://github.com/appleseedhq/appleseed/blob/master/src/appleseed/renderer/kernel/lighting/pt/ptlightingengine.cpp#L456

I wonder if we could regroup all those distance checks in one place (ideally in the EDFs and lights).

vidarn commented 10 years ago

I agree. Having the distance checks in different places for different integrators is a bit messy! I couldn't find any better way of doing it when I wrote it but I'm pretty new to the code so I might have missed something. Having all the checks in the lights/EDFs would be really nice. :)

dictoon commented 10 years ago

Turns out my comment about a possible bug was wrong, the distance check is done inside PathVertex::compute_emitted_radiance(). Not sure what causes the fireflies then.