Quad Light wrong and antialias in pathtracer

[johguenther]

Hi, I'm happy to read that you consider to integrate OSPRay :-)

Which version of OSPRay are you using? I assume v1.2.0? One problem with light sources was fixed in 081587e6438a6d88f8e1e788680978093e687091, which will be part of a next patch release soon. Chances are high that this fixes your problem shown in the 3rd image (quad light illuminating also behind).

The behavior that the "invisible" light can be seen in the mirror is actually correct regarding the current definition: according to the documentation the parameter isVisible controls “whether the light can be directly seen”, i.e. via the camera, but not indirectly in reflections. The difficulty lies in a consistent definition of the “visibility” behavior. If you want the light to be also invisible when seen indirectly, this actually means that the light is not illuminating anymore. What we could do is to introduce a new parameter isVisibleInReflections with the meaning whether the light is visible via ideal specular reflections. Thus, when turned off, it won't be seen in the mirror anymore (changing your last image). However, please note that when you change the material of the mirror to be slightly rough (e.g. a highly polished metal) to get highly glossy reflections the light will immediately be visible again (because the reflection is then not ideal specular anymore). Would that be acceptable for you?

With anti-aliasing problems I guess you mean high (>>1) contrast edges (like the borders of a visible quad light with intensity 20, or the left lamp arm, which is in front of a high intensity background). This is actually an artifact introduced when clipping high dynamic range (HDR) images to the low dynamic range of the display. One solution is to have a better tone mapping algorithm which properly handles anti-aliasing. Another often used workround (which is also supported by OSPRay) is to clip contributions before accumulating. You can do this by setting the path tracer parameter maxContribution to e.g. 5 or 10 (depending on you scene brightness and tone mapping operator). A downside of this workaround is that bright highlights (e.g. on the chrome stair handles in the right of your first image) might loose brilliance.

Best regards, Johannes

[johguenther]

Hello Roberto, version 1.2.1 of OSPRay will be released before April. However, it won't contain a potential isVisibleInReflections feature, which will come in v1.3.0 the earliest (which will be later than April). Nevertheless, you could also easily (we hope) compile OSPRay yourself to get interesting changes independent of our binary releases (or to see whether the mentioned fix really solves your quad light problem). See Building OSPRay from Source.

Best regards, Johannes

[johguenther]

The Glass material implements refraction realistically and thus requires closed geometry – it is meant for thick objects. Windows are usually only modeled with one surface, so you probably see total internal reflection (which happens at ~43° for eta=1.45). For windows you may want to use the (undocumented, because work-in-progress) ThinGlass material. Its color can be currently controlled by a transmission parameter.

[johguenther]

Release 1.2.1 is now available, please test whether it indeed fixes your quad light problem.

If you like to be notified of future releases you can subscribe to the OSPRay announce mailing list.

[johguenther]

OSPRay and Embree use AVX2 (and higher) per default (when the CPU supports it) and also with the release packages.

I guess the error "only 64bit architecture supported" comes from CMake? When configuring the first time with CMake (or after deleting its cache) you need to select a 64bit Generator, e.g. "Visual Studio 10 2010 Win64".

Could you attache the image? It is missing. Three days seem really to much; a high quality image (FullHD, no perceivable noise) should typically be ready in one, two hours on an i7.

[johguenther]

Yes, if the CPU does not support AVX2 OSPRay automatically falls back to AVX or SSE4 (the CPU must support at least SSE4.1 to run OSPRay).

You only need to compile OSPRay yourself if you like to test new features in the devel branch that are not released yet, or if you want to disabled features you do not need (e.g. to get smaller DLLs). Otherwise the precompiled packages we provide for each release should be perfectly fine.

On Windows using the CMake-GUI is probably the easiest way, there you can select the Generator in a drop-down menu. On the command line you need to specify it via the -G flag (also refer to scripts/release/win.bat), e.g.

cmake -G "Visual Studio 10 2010 Win64" -DCMAKE_CXX_COMPILER=clang++ -DCMAKE_C_COMPILER=clang ..

Also, you need to start with the top-level folder of OSPRay for cmake to avoid the "INCLUDE_DIRECTORIES_ISPC not found" error.

I will have a closer look regarding the performance issues soon.