Added path tracing renderer #393
Conversation
brayns/tasks/LoadDataFunctor.cpp
Outdated
| @@ -49,11 +49,11 @@ void LoadDataFunctor::operator()(Blob&& blob) | |||
| { | |||
| struct Scope | |||
| { | |||
| Scope(Blob&& blob, LoadDataFunctor& parent) | |||
| Scope(Blob&& b, LoadDataFunctor& parent) | |||
There was a problem hiding this comment.
Clang complains about variable shadowing the other one line 62. Gcc is happy though. I had this issue when compiling on MacOSX
favreau
force-pushed
the
pathtracing
branch
2 times, most recently
from
ca120af to
dacc288
Compare
| const vec3f hitpoint = dg.P + self->abstract.super.epsilon * dg.Ns; | ||
| setRay(localray, hitpoint, raydir); | ||
| localray.t0 = self->abstract.super.epsilon; | ||
| localray.t = self->abstract.ambientOcclusionDistance; |
There was a problem hiding this comment.
I'm not sure if limiting t (the maximum allowed hit distance along ray) to the ambientOcclusionDistance will work the same as setting it to a very large number. This may or may not result in some weird lighting, but may also be faster.
There was a problem hiding this comment.
I understand, but the ambient occlusion distance can be set to a very large value anyway. And this way, we can change it at runtime.
| Kd = Kd * (1.f - self->abstract.shadows); | ||
| } | ||
| else | ||
| Kd = Kd * (1.f - self->abstract.shadows); |
There was a problem hiding this comment.
This doesn't seem right, the if/else statement has the same outcome for both the if and else branch (if the surface faces the light source and is not occluded from it, then the hitpoint should receive additional light).
There was a problem hiding this comment.
Hum, you're right, I am not 100% sure either of the current implementation. Let's talk tomorrow.
| const vec3f sunSampleDirection = | ||
| getConeSample(lightDirection, rng, | ||
| self->abstract.softShadows); | ||
| const float sunLight = |
There was a problem hiding this comment.
I would rename sunLight to sunAngle to avoid confusion and reflect better what it's doing (that was a bad naming choice on my part, sorry)
There was a problem hiding this comment.
Sure, I usually use cosNL for diffuse and cosLR for specular. In this case, only diffuse shading is processed. And Sun is probably a specific case too since we can have many lights. I'll change it to cosNL then, unless you have an objection.
|
|
||
| // CHECK THIS!!! WITH OR WITHOUT * MASK | ||
| // results are very different. Color bleeding is much stronger with mask | ||
| color = accucolor * mask; |
There was a problem hiding this comment.
After some digging into path tracing theory, it would be more correct to not multiply the final color by the mask colour again, as it has already been taken into account. Otherwise this will result into too much colour bleeding.
favreau
force-pushed
the
pathtracing
branch
7 times, most recently
from
78017a7 to
aed7a75
Compare
No description provided.