Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upDistance fog #72
Distance fog #72
Conversation
| const fogScale = renderingParams.fogScale; | ||
|
|
||
| const bounces = renderingParams.bounces; // number of global illumination bounces | ||
|
|
This comment has been minimized.
This comment has been minimized.
| @@ -205,6 +205,7 @@ void intersectScene(inout Ray ray, inout SurfaceInteraction si) { | |||
| int materialIndex = floatBitsToInt(r2.w); | |||
| vec3 faceNormal = r2.xyz; | |||
| surfaceInteractionFromBVH(si, tri, hit.barycentric, index, faceNormal, materialIndex); | |||
| ray.distance = length(ray.o - si.position); | |||
This comment has been minimized.
This comment has been minimized.
jaxry
Feb 18, 2020
•
Contributor
I believe this value is already stored in ray.tMax, so no need to compute it here. It's a weird variable name but it's what pbrt uses.
Edit: Actually, ray.t stores the distance too and that's the property we should be using. It's a parametric ray, where ray.o is the origin, and ray.t is the length.
| #ifdef FOG_SCALE | ||
|
|
||
| float fogWeight = max(0.0, 1.0 - ((max(0.0, distance)) / FOG_SCALE)); | ||
| fogWeight = pow(fogWeight, 2.0); |
This comment has been minimized.
This comment has been minimized.
jaxry
Feb 18, 2020
Contributor
If we're always doing a pow of 2.0 because it looks nice, fogWeight *= fogWeight would at least be as performant if not more so.
| vec3 applyFog(vec3 li, float distance, vec3 direction, inout vec3 beta) { | ||
| #ifdef FOG_SCALE | ||
|
|
||
| float fogWeight = max(0.0, 1.0 - ((max(0.0, distance)) / FOG_SCALE)); |
This comment has been minimized.
This comment has been minimized.
jaxry
Feb 18, 2020
Contributor
I'm not sure how different it looks, but supposedly a more "realistic" fog is exponential fog.
https://catlikecoding.com/unity/tutorials/rendering/part-14/
The weight would be 1 / pow(2.0, distance * scaleConstant), where the constant is some low number like 0.001.
|
Would it make sense to implement Scene.fog as best we can? We could use the |
| const renderingParams = { | ||
| reprojectedSamples: module.reprojectedSamples, | ||
| initialUniformSamples: module.initialUniformSamples, | ||
| previewTime: module.previewTime, |
This comment has been minimized.
This comment has been minimized.
jaxry
Feb 18, 2020
Contributor
I'm hesitant to expose these values to the user
- They are highly dependent on the current pipeline. Any change to the pipeline necessarily requires changes to these numbers, and if the user overrides them, their renderer will break when they update to the latest pipeline.
- They are scene independent. There are ideal numbers that work on the majority of devices that work better than other numbers. It's not opinionated in other words, so if our current numbers are off, it would be better to fix them with a PR than with user-overwritten values.
Thoughts?
This comment has been minimized.
This comment has been minimized.
lyonsno
Feb 18, 2020
Author
Collaborator
Hmm. I definitely see your point here. It has been very convenient for me to easily modify them in my work when using ray tracing renderer as a dependency though.. Ideas?
This comment has been minimized.
This comment has been minimized.
jaxry
Feb 18, 2020
•
Contributor
That makes sense. What about exposing these params prefixed with an underscore (or something to denote they're "private"), and not documenting them in the wiki? That gives us the power to add/remove params when necessary (for example, previewTime might not be used with benchmark redesign), and we don't have to worry about supporting them. But we can still tweak the numbers as a dependency, from a dev perspective, to hone in on good values to merge with a PR?
Just throwing ideas here.
yes! great idea. |
| vec2 uv; | ||
| vec3 lightDir = sampleEnvmap(random, uv, lightPdf); | ||
| float originalRayDistance = path.ray.distance; | ||
| vec3 originalRayDirection = path.ray.d; |
This comment has been minimized.
This comment has been minimized.
jaxry
Feb 18, 2020
•
Contributor
Instead of copying these values, what about keeping them as they are, and instead using a separate Ray for the shadow intersection? That takes less code I believe.
Edit: We could also do the fog calcs before the shadow intersection, letting us use the same ray for everything. Not sure if that micro-optimization would have any benefit though.
lyonsno commentedFeb 18, 2020
Add a fog scale parameter to the module. Default value is zero, which applies no fog. Fog works by blending objects into the env map as they appear further away. Values above zero will specify the ray distance at which objects are fully obscured by fog, i.e. replaced by the envmap in that direction.
Also adds a few params which allow for external fine-tuning of temporal filtering and sampling settings .
Image(s) or GIFs (if applicable)
Pull Request Guidelines
master.