LuxCoreRender Forums

Got it, thanks!

acasta69 wrote: Thu Jan 17, 2019 7:37 am

Dade wrote: Tue Jan 15, 2019 10:27 pm Yup, may be reducing the number of concurrent compilations can solve the problem or is it a 32bit vs 64bit compiler problem

I have eliminated concurrent project builds for the OpenCL version and apparently this solves the problem.
You should find again Windows OpenCL build among the daily binaries.
Total build time is only slightly longer... Maybe those VMs have too small virtual memory to handle several big builds efficiently at the same time
Anyway, I'll keep looking for a more efficient solution if possible.

I have done the same also for Windows OpenCL-less version, since the problem has just showed up there too.

Ok, I got it working and I think this is going to be really awesome!

The psor-cube file is Bidir metro at default but when changing the engine to path it creates nice caustics quickly.

I copied the photonGI parameters into my causticcube file and it didn't work at first until I changed "rougmatte" to "matte" material.

Now I have set up another simple scene and there I'm stuck: The photon cache works, but no caustic photons are registered and therefore no caustics rendered.

I tried spot, area and point light but nothing works (file attached). Where is my error?

From this short testing I can already see that the old problem of all photon mappers is back: how to aim photons so that they are not wasted?

Would it be possible in the case of caustic photons to send them only at reflective and refractive surfaces (the rest is cared for by the indirect photons), like with a visibility map, in an automatic way?

Now I'm going to check out the indirect cache ...

epilectrolytics wrote: Thu Jan 17, 2019 2:53 pm Now I have set up another simple scene and there I'm stuck: The photon cache works, but no caustic photons are registered and therefore no caustics rendered.

I tried spot, area and point light but nothing works (file attached). Where is my error?

You have forgot to replace the roughmatte with matte material.

epilectrolytics wrote: Thu Jan 17, 2019 2:53 pm From this short testing I can already see that the old problem of all photon mappers is back: how to aim photons so that they are not wasted?

It needs a Metropolis sampler. In order to give you an idea of the difference, this is a 4 samples/pixel LIGHTCPU rendering with Sobol sampler (the same sampler currently used by PhotonGI):
And this with Metropolis (what I plan to use):
The difference in photon density is huge. Metropolis "aims" the photons where they are visible.

Dade wrote: Fri Jan 18, 2019 11:29 am You have forgot to replace the roughmatte with matte material.

Ooops

In Blender I assigned a matte material with sigma=0 and then didn't check the cfg file.
Apparently this produces a roughmatte material, so how to make matte from Blender?
(Assigning no material does the trick: "matte" in cfg, but is that the only option?)

Anyways, caustics from that file render now in PathOCL though very slowly (0.01M/s), one pass takes several minutes and the image shows strong aliasing but I guess all that will be optimised later once the cache works.

It needs a Metropolis sampler.
()
The difference in photon density is huge. Metropolis "aims" the photons where they are visible.

That looks very promising!

I'd like to suggest to make the photon gathering pass(es) visible in the viewport so that the user can gauge the photon density and correct earlier.

epilectrolytics wrote: Fri Jan 18, 2019 1:17 pm In Blender I assigned a matte material with sigma=0 and then didn't check the cfg file.
Apparently this produces a roughmatte material, so how to make matte from Blender?
(Assigning no material does the trick: "matte" in cfg, but is that the only option?)

The matte node always exports roughmatte, as you say matte is used only in the fallback material when no material is assigned.
So you will have to edit the exported files, or you have to edit this BlendLuxCore file: https://github.com/LuxCoreRender/BlendL ... tte.py#L27
Change type from "roughmatte" to "matte" and comment out the line with the sigma (add a "#" in front of the line).

B.Y.O.B. wrote: Fri Jan 18, 2019 1:46 pm Change type from "roughmatte" to "matte" and comment out the line with the sigma (add a "#" in front of the line).

Ok thanks for the hint!

B.Y.O.B. wrote: Fri Jan 18, 2019 1:46 pm The matte node always exports roughmatte, as you say matte is used only in the fallback material when no material is assigned.

However it is now important to export a "true" matte when possible because, even with PhotonGI generic support for materials, it will be still the faster option to render. A simple "if (sigma == 0) than export matte else export roughmatte" can do the trick.

epilectrolytics wrote: Fri Jan 18, 2019 1:17 pm Anyways, caustics from that file render now in PathOCL though very slowly (0.01M/s), one pass takes several minutes and the image shows strong aliasing but I guess all that will be optimised later once the cache works.

You mean PATHCPU, right ? PATHOCL is unchanged for the moment.

epilectrolytics wrote: Fri Jan 18, 2019 1:17 pm I'd like to suggest to make the photon gathering pass(es) visible in the viewport so that the user can gauge the photon density and correct earlier.

Yes, at the moment, I'm doing it by modifying the code but I will expose a flag to directly render any of the caches: it is very useful to understand if the cache needs more photon, etc.

I added the support for generic "DIFFUSE | GLOSSY | REFLECT" materials (all not specular and not transparent materials). Support for transparent materials and volumes will come later. It works well:


As expected, if the glossy surface start to be too "Specular" (i.e. very low roughness and working like a mirror), some splotch-ness of the cache starts to be visible:


It is not a big deal as something nearly specular should be handled like any other specular surface (i.e. use brute force instead of the cache). I'm planning to introduce a Material setting with AUTO/CACHE_ENABLED/CACHE_DISABLED options. AUTO will automatically switch on/off according the roughness. Other settings will give the freedom to the user to decide on its own.