LuxCoreRender Forums

epilectrolytics wrote: ↑Tue Jun 18, 2019 2:36 pm Using build 20190618.1 (commit 526e952), feels like OpenCL support is not included or very buggy on Windows 10.

I have tested the binaries and they do not include OpenCL support, I have no idea why. The binaries obtained compiling the latest sources have the support and work fine on Windows (aside from the "stop rendering thing").

Last two builds from Azure failed!
Files inside the "latest release" for windows are from 17. 06. 2019

Dade wrote: ↑Wed Jun 19, 2019 10:01 am I have tested the binaries and they do not include OpenCL support, I have no idea why.

No problem, the latest "latest" works again!
I hope the automatic pipeline can be fixed!

And now time for user-testing

Latest build, OCL works.

Caustic's cache reveals the edges.
Issue arises from Normal Angle size (OCL & CPU).
The lower the angle size, the greater the anomaly.
e.g.

Normal Angle: 90° Normal Angle: 10°(default) Normal Angle: 0° Scene:

provisory wrote: ↑Tue Jun 18, 2019 5:22 pm It crashes for me too, when I stop the render during the cache update. (Win 10, CPU, not OpenCL)

I should have fixed this problem.

Note: the update work will be finished and, only after, the rendering will be stopped so if you set long caustic cache build times, it will take a while to stop (however if you have long caustic cache build times, you are doing something wrong).

kintuX wrote: ↑Wed Jun 19, 2019 11:15 am Last two builds from Azure failed!

epilectrolytics wrote: ↑Wed Jun 19, 2019 1:03 pm I hope the automatic pipeline can be fixed!

I had a look and noticed that this happens quite often at times. The build actually succeeds, but the following deployment of one of the packed binaries to GitHub fails because of this error: I think there's little we can do about that, it looks like some kind of network problem on Azure servers.

acasta69 wrote: ↑Wed Jun 19, 2019 2:51 pm

kintuX wrote: ↑Wed Jun 19, 2019 11:15 am Last two builds from Azure failed!

epilectrolytics wrote: ↑Wed Jun 19, 2019 1:03 pm I hope the automatic pipeline can be fixed!

I had a look and noticed that this happens quite often at times. The build actually succeeds, but the following deployment of one of the packed binaries to GitHub fails because of this error:

Code: Select all

2019-06-15T15:09:03.8924021Z Uploading asset luxcorerender-latest-linux64-opencl.tar.bz2 - 0% - 192.0 KB/s
2019-06-15T15:09:04.0244740Z Uploading asset luxcorerender-latest-linux64-opencl.tar.bz2 - 0% - 320.0 KB/s
2019-06-15T15:09:04.1552241Z Uploading asset luxcorerender-latest-linux64-opencl.tar.bz2 - 1% - 896.0 KB/s
2019-06-15T15:09:04.2892601Z Uploading asset luxcorerender-latest-linux64-opencl.tar.bz2 - 3% - 1.9 MB/s
2019-06-15T15:09:04.3545391Z ##[error]An error occured, log returned: 
Error: socket hang up

I think there's little we can do about that, it looks like some kind of network problem on Azure servers.

Yes, noticed it too, but had no idea what's it all about. Thanks for enlightenment.

Dade wrote: ↑Wed Jun 19, 2019 2:10 pm

provisory wrote: ↑Tue Jun 18, 2019 5:22 pm It crashes for me too, when I stop the render during the cache update.

I should have fixed this problem.

Thanks!

Now for the first Impressions of periodic caustic cache with PathOCL:

We now have a progressive Photon mapper working with fast PathOCL+PGI which is great!
It is a weird thing, CPU photon mapping running parallel to path tracing without much sync.

I'm testing with B.Y.O.B.'s Wallpaper scene (dispersion!) trying to replicate BiDir caustics with periodic cache (=4mm lookup radius).

1. Periodic cache is probably slower than BiDir. That means while the non-caustic image probably is clean after 1000 samples in 10min, the photon mapper may need another hour of updates until it has converged all the while the path tracer is firing along on GPU wasting power.
In my test i set update period to 1 sample in order to shift the weight to the side of photon mapping rather than path tracing but it does not really work:
Over time the update period gets longer till the CPU (cache updating) works only at 35% of the time idling at 65% (resource monitor)
But in this case I want the CPU at 100% cache building and in between do only a low amount of PathOCL samples which number I'd like to specify in order to achieve the right balance for both algorithms to converge.

2. There are some artefacts: A green dot that does not converge and some small white splotches with red border.

3. In the prism there are splotchy caustics which don't converge either: I'm assuming this is a problem with visibility particles (first PGI pass): the prism is probably distorting visibility density on opposite of camera side. I can avoid this effect with bigger lookup radius but then all other caustics get blurry.
We may need access to visibility settings or this has to be fixed another way.
. .
Apart from these little quirks PGI caustic cache is now usable and up to the standard of indirect cache: a really great achievement

Edit: render after 75min (screenshot because of running version still crashing on render termination):

It depends of the importance of light paths and eye paths: if you need to render 99% light paths and 1% eye paths, you should rendering with LIGHTCPU (not even BIDIRCPU or PATHCPU/OCL+PGI).

You are pretty much doing the test with a caustic covering the 99% of the image and a ("hyper")cube over a plane.

For the fireflies, it is still path tracing so just use variance clamping.

Would it be possible to make caustics work/be calculated only for a certain object or certain light?

Unlike GI, caustics might actually benefit being "on demand". So for example we could tell the render engine that only "this light" and "this object" should generate photons.

For example, in an exterior rendering with a pool, I'd only have sun as the only light being able to generate photons and "pool water" as the only object.

I am all for one click universal solutions, but it seems caustics are either slow or blurry atm from the tests I'm seeing.