Skip to content
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

Merged
merged 18 commits into from
Dec 19, 2023

Conversation

robertoranon
Copy link
Contributor

No description provided.

@gkjohnson
Copy link
Owner

gkjohnson commented Nov 26, 2023

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:

  1. We should remove the ability to hit "lights" from the traceScene function since this is causing light surfaces to cast shadows and is causing them to "use" path bounce. If this is addressed then the dimming issue you reported should no longer be an issue.
  2. Then we should iterate over all lights in the path tracing loop and add any light contribution from lights that are passed through up to the next ray termination point.
  3. On the state.firstRay || state.transmissiveRay we find the closest light marked as visible we intersect with if any and terminate so it's visible.

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!

@robertoranon
Copy link
Contributor Author

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 traceScene function, as well as other modifications:

  • removing all code that was executed when traceScene was returning a light hit
  • some code refactoring using a variable to hold the value to be returned, instead of early return statement, as I have noticed that they "contributed" to the crashes on macOS. I'll now move into point 2 above.

Copy link
Owner

@gkjohnson gkjohnson left a 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!


}
}
Copy link
Owner

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

Comment on lines +44 to +46
}

else {
Copy link
Owner

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?

Comment on lines -89 to +91
return vec3( 0.0 );
return result;
Copy link
Owner

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.

@gkjohnson gkjohnson merged commit c71f0f6 into gkjohnson:main Dec 19, 2023
4 checks passed
@robertoranon robertoranon deleted the invisible-area-lights branch January 16, 2024 19:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants