-
-
Notifications
You must be signed in to change notification settings - Fork 133
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
first tentative modifications for "invisible" area lights #470
first tentative modifications for "invisible" area lights #470
Conversation
The "dimming" of the area where the light surface technically is is caused because hitting the light technically counts as one of the limited "bounces" that a path is allowed to traverse. So the paths that go around the light surface bounce around the scene 3 times while the paths that hit the light only bounce twice since the light absorbs one. To that end - here's what I'm thinking:
It depends on how you want to handle it - but it might be easiest to handle points 1 and 2 first and then 3 can be done in separately. Hopefully that all makes sense - let me know if you have any other questions or need more direction on the codebase! |
Hi, sorry for taking so long, but I was quite busy. Here is a modification of this PR that removes the ability to trace lights from the
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Amazing! Thank you. I added a couple small comments around code style and a comment. I can make the changes later this week when I have time, as well, if I get to it first!
|
||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: extra space added between tabs
} | ||
|
||
else { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: can we align this code style with the other else brackets?
return vec3( 0.0 ); | ||
return result; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For the sake of documenting some of these decisions can we add a comment saying that the Mac regressions seem to be related to early return statements? Maybe with a reference to this PR id, as well.
No description provided.