LuxCoreRender Forums

Dade wrote: ↑Tue Jan 15, 2019 7:02 pm Note: lately, the Windows builds fail because they run apparently out of memory: https://dev.azure.com/LuxCoreRender/Lux ... nitionId=1

Code: Select all

d:\a\1\luxcore\src\luxrays\utils\ocl.cpp(252,0): Error C1002: compiler is out of heap space in pass 2
LINK(0,0): Error LNK1257: code generation failed
d:\a\1\windowscompiledeps\include\tbb\concurrent_hash_map.h(891,0): Error C1002: compiler is out of heap space in pass 2
LINK(0,0): Error LNK1257: code generation failed
d:\a\1\windowscompiledeps\include\tbb\concurrent_hash_map.h(891,0): Error C1002: compiler is out of heap space in pass 2
d:\a\1\windowscompiledeps\include\tbb\concurrent_hash_map.h(892,0): Error C1002: compiler is out of heap space in pass 2
d:\a\1\luxcore\deps\openvdb-3.1.0\openvdb\tree\treeiterator.h(116,0): Error C1002: compiler is out of heap space in pass 2
Process 'msbuild.exe' exited with code '1'.

Not sure if Azure has reduced the amount of VM memory or we are just starting to be too "big" to compile.

@Acasta69 , would be nice if you could look into the problem, I'm not very experienced with VisualStudio

It used to happen every now and then, I didn't notice it is so frequent now.
I'll look into that as soon as possible...

acasta69 wrote: ↑Tue Jan 15, 2019 9:35 pm It used to happen every now and then, I didn't notice it is so frequent now.

Yup, may be reducing the number of concurrent compilations can solve the problem or is it a 32bit vs 64bit compiler problem

zeealpal wrote: ↑Tue Jan 15, 2019 2:45 pm Daily builds are available through here:

viewtopic.php?t=736

Will test when I have time tomorrow

I know about daily builds.. But this gi cache isn't in daily builds yet (or it's not exposed in blender addon) / or I somehow missed it.

It is in master, so it will be in the daily builds.
But it's not exposed in the Blender addon yet, so you would have to export your scene as .cfg/.scn files and edit them by hand to use the PhotonGI cache, then render with luxcoreui.

Added a (configurable) cap to the number of photons collected during the cache lookup: this improves cache lookup performance in high photon density regions and/or when using large lookup radius.

Reworked also the names of a couple of properties, updated the first post to reflect the latest version of the sources.

Dade wrote: ↑Wed Jan 16, 2019 2:02 pm
1) Cache entries are currently created only on "matte" material (note: "matte", not "roughmatte");

At first reading I missed this.. So if all my materials are glossy or metals, there will be no caching at this moment?

lacilaci wrote: ↑Wed Jan 16, 2019 4:08 pm

Dade wrote: ↑Wed Jan 16, 2019 2:02 pm
1) Cache entries are currently created only on "matte" material (note: "matte", not "roughmatte");

At first reading I missed this.. So if all my materials are glossy or metals, there will be no caching at this moment?

It will bounce over that materials with normal path tracing until it will not hit a matte surface. Like it does for specular surfaces (i.e. glass/mirror). Anyway I'm going to write the code for other materials very soon.

Anyway I'm going to write the code for other materials very soon.

I was afraid until i read the last sentence ! Just fear for all my interior render with sligtly shiny surface.

Dade wrote: ↑Wed Jan 16, 2019 5:34 pm

lacilaci wrote: ↑Wed Jan 16, 2019 4:08 pm

Dade wrote: ↑Wed Jan 16, 2019 2:02 pm
1) Cache entries are currently created only on "matte" material (note: "matte", not "roughmatte");

At first reading I missed this.. So if all my materials are glossy or metals, there will be no caching at this moment?

It will bounce over that materials with normal path tracing until it will not hit a matte surface. Like it does for specular surfaces (i.e. glass/mirror). Anyway I'm going to write the code for other materials very soon.

I understand. Can't wait to see more progress on this.

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.