## Implementing a new LuxCore exporter

General discussion regarding exporter development in general.

### Implementing a new LuxCore exporter

I have / am developing an exporter for luxcore and have some questions / reports.

I am currently using the luxcore dev built 2017-03-27 for win64.

First some questions on the implementation of an exporter:

Engines:
- there seems to be many engines and each at different implementation levels, currently we are only exporting to PathCPU e PathOCL since they seemed simplest and safest, is this a correct assumption, what would the other engines offer in terms of performance/options compared to these?

Materials:
- i am currently exporting what might be an aggressive number of materials and objects (for complex scenes up to thousands) how hard could this impact performance / stability ?
- fresnel textures, what are those? (i can't seem to find a way to actually implement a standard texture on a metallic material and have resorted to using a matte-mirror mix for this purpose).

Lights:
- we are currently exporting using the spot and point presets, are area lights much preferable?
- can you give some pointers as to what range of values should be correct for sun, sky and light emission? (and their relative tonemapping values?)

Normals:
- generally the generating environment does not deal with normals is there a way for luxcore to automatically generate them as it was for SLG?

Special characters:
- is there a way for to the generated files paths/names to include special characters? i get error in the loading of files whenever there are any, and have resorted to naming everything progressively.

Now to the report/technical issues part:

This is a sample (generated with the new exporter) and it's testing environment:

- Attachment "Esito LuxRender PC60 (Geforce GTX 1060 6GB).txt" is the result of trying to render the sample files on luxcoreui on a "Geforce GTX 1060 6GB" graphics card, it simply stops even though the card should have OpenCL support (no idea what this is except for a driver issues but those have been checked and updated multiple times).

- Attachment "Esito LuxRender PC51 (ASUS EAH5450, Intel HD Graphics 4600) - First try.txt" is the result of trying to render with an opencl executable (but not an opencl engine) the sample file on a different machine; you can see what is a recurring error on this machine and which is generated generally on the first try of every new file; consequent tries will instead highlight a completely different error which can be seen in attachment "Esito LuxRender PC51 (ASUS EAH5450, Intel HD Graphics 4600) - Second try.txt" i tried changing the workgroup size properties but it just doesn't seem to matter (the property might be ignored by the sampler compiler?).

- noopencl versions are, in general, stable; is there something wrong in the .cfg sample file when it comes to opencl?

- Aside from the ones included in the luxcore dev download, what libraries are required to run LuxCore? One of our machines had to have vcomp120 updated for instance.

Sorry my written language has always been terrible.
Attachments
Esito LuxRender PC60 (Geforce GTX 1060 6GB).txt
Esito LuxRender PC51 (ASUS EAH5450, Intel HD Graphics 4600) - Second try.txt
Esito LuxRender PC51 (ASUS EAH5450, Intel HD Graphics 4600) - First try.txt
spazio3d

Posts: 6
Joined: Tue Sep 11, 2012 10:26 am

### Re: Implementing a new LuxCore exporter

spazio3d wrote:Engines:
- there seems to be many engines and each at different implementation levels, currently we are only exporting to PathCPU e PathOCL since they seemed simplest and safest, is this a correct assumption, what would the other engines offer in terms of performance/options compared to these?

From my experience:
• PathCPU, BidirCPU and TilePathCPU are the ones that should be very stable.
• PathOCL/TilePathOCL can crash occasionally, mostly due to driver bugs, but maybe also because of remaining bugs in LuxCore OpenCL code. But in most scenes they work fine.
• BidirVMCPU (Bidir with vertex merging) is mostly stable, but can eat excessive amounts of RAM in some scenes and is in general considered unfinished and experimental, so don't use it in production.
You should use Path/TilePath engines for scenes with simple lighting, e.g. outdoors with bright sunlight. Combine them with the Sobol sampler for maximum speed (but be aware that it can lead to annoying noise patterns with low samples - Metropolis has nicer noise patterns).

Use Bidir + Metropolis in scenes with complex lighting, e.g. caustics or indoor scenes with many hidden lights or a lot of glass.

spazio3d wrote:- i am currently exporting what might be an aggressive number of materials and objects (for complex scenes up to thousands) how hard could this impact performance / stability ?

It should not make a considerable impact, in my experience LuxCore handles lots of objects very well. Stability is not impacted at all.
If you do instancing, try to make the single instance objects as large as possible (in terms of polygons). For example, if you have a field of grass, do not model one blade of grass and make 100,000 instances, but instead model a clump of grass with 100 blades and instance it 1000 times.
This leads to better performance and memory usage.

spazio3d wrote:- we are currently exporting using the spot and point presets, are area lights much preferable?

Well, with spot and pointlights you can't get realistic soft shadows (because they are infinitely small), so the lighting will not look as realistic as if you used area lights.
My simple rules for realistic renders are:
• Almost every material is a bit glossy (the amount of brightness and roughness varies)
• Almost every light creates soft shadows (the amount of softness varies)

http://www.luxrender.net/wiki/LuxCore_S ... l_Textures
You could declare a fresnel texture like this:

Code: Select all
scene.textures.my_fresnel_tex.type = fresnelcolorscene.textures.my_fresnel_tex.kr = 0 0.5 0  # This would be blue

And then you can use it on a metal2 material:
Code: Select all
scene.materials.my_metal_mat.type = metal2scene.materials.my_metal_mat.fresnel = my_fresnel_tex

There are some other types that can load fresnel specifications from file, and some predefined ones, see the wiki link above.

B.Y.O.B.

Posts: 5177
Joined: Wed Nov 10, 2010 4:10 pm
Location: Germany

### Re: Implementing a new LuxCore exporter

Thanks for the answers but i'll something more on a couple of points:

- i am currently exporting what might be an aggressive number of materials and objects (for complex scenes up to thousands) how hard could this impact performance / stability ?

It should not make a considerable impact, in my experience LuxCore handles lots of objects very well. Stability is not impacted at all.
If you do instancing, try to make the single instance objects as large as possible (in terms of polygons). For example, if you have a field of grass, do not model one blade of grass and make 100,000 instances, but instead model a clump of grass with 100 blades and instance it 1000 times.
This leads to better performance and memory usage.

I really was more worried about materials than objects since they are reaching the same numbers.

http://www.luxrender.net/wiki/LuxCore_S ... l_Textures

The problem is that i am trying to assign an actual color texture rather than a static color and the .kr property on a fresnel texture doesn't allow it (probably because it doesn't make sense to use a texture to initialize a texture?).
spazio3d

Posts: 6
Joined: Tue Sep 11, 2012 10:26 am

### Re: Implementing a new LuxCore exporter

I have no experience with thousands of materials, you will have to do a test yourself.

About fresnelcolor: in the code it accepts a texture for kr, so it should work.
https://bitbucket.org/luxrender/luxrays ... ew-default
I'll test in luxblend later.
How did you specify the texture, how does your code look like?

B.Y.O.B.

Posts: 5177
Joined: Wed Nov 10, 2010 4:10 pm
Location: Germany

### Re: Implementing a new LuxCore exporter

How did you specify the texture, how does your code look like?

Uploaded, but i have solved it already. It is referencing a texture that gets defined later on if i bring the textures higher the problem is solved, i don't understand why this is only relevant for fresnel textures though.
Attachments
Start log.txt
Scene.scn
spazio3d

Posts: 6
Joined: Tue Sep 11, 2012 10:26 am

### Re: Implementing a new LuxCore exporter

All textures/materials etc. have to be defined before you can use them.
So you have to export subtextures/materials before you export their parents.

B.Y.O.B.

Posts: 5177
Joined: Wed Nov 10, 2010 4:10 pm
Location: Germany

### Re: Implementing a new LuxCore exporter

Thx I wrote down enough stuff to try out on the next revision for the exporter, i'll post again for the results and whatever new questions arise when I actually get to work on it again.

Nic.
spazio3d

Posts: 6
Joined: Tue Sep 11, 2012 10:26 am