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

Distance fog #72

Draft
wants to merge 12 commits into
base: master
from
Draft

Distance fog #72

wants to merge 12 commits into from

Conversation

@lyonsno
Copy link
Collaborator

lyonsno commented Feb 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)

Screen Shot 2020-02-18 at 9 46 05 AM

Pull Request Guidelines

  • I have added pull requests labels which describe my contribution.
  • All existing tests passed.
    • I have added tests to cover my changes, of which pass.
  • I have compared the render output of my branch to master.
  • My code has passed the ESLint configuration for this project.
  • My change requires modifications to the documentation.
    • I have updated the documentation accordingly.
const fogScale = renderingParams.fogScale;

const bounces = renderingParams.bounces; // number of global illumination bounces

This comment has been minimized.

@jaxry

jaxry Feb 18, 2020

Contributor

We could destructure these too if you like that idea.

@@ -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.

@jaxry

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.

@jaxry

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.

@jaxry

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.

@jaxry
Copy link
Contributor

jaxry commented Feb 18, 2020

Would it make sense to implement Scene.fog as best we can? We could use the near and far values. For color, we could either ignore it, or we implement it, and if it's set to null that's when we blend with the envmap?

const renderingParams = {
reprojectedSamples: module.reprojectedSamples,
initialUniformSamples: module.initialUniformSamples,
previewTime: module.previewTime,

This comment has been minimized.

@jaxry

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.

@lyonsno

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.

@jaxry

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.

@lyonsno
Copy link
Collaborator Author

lyonsno commented Feb 18, 2020

Would it make sense to implement Scene.fog as best we can? We could use the near and far values. For color, we could either ignore it, or we implement it, and if it's set to null that's when we blend with the envmap?

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.

@jaxry

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.

@elfrank elfrank added the on hold label May 17, 2020
@elfrank elfrank marked this pull request as draft May 29, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

3 participants
You can’t perform that action at this time.