BlendLuxCore Development

[Dade]

I have no precise measurements of the used GPU RAM, but the task manager graph shows that your suspicion is probably right, as there's no difference in memory usage between 3 and 4 channel images.

I frankly find the idea of wasting 33% of GPU ram to store RGB images (i.e. the most common type of image maps) unacceptable.

I guess I will ditch the support for hardware image maps sampling.

P.S. you may able to increase memory usage by using 16bit PNG or an HDR format for the texture map.

[B.Y.O.B.]

I assume it is not possible to split an image with 3 channels into 3 textures with 1 channel each?
Or some other trickery along those lines, like putting all 3 channels behind each other into a 1 channel texture?

I don't know what hardware image maps are exactly, but I guess something like that would defeat their purpose?

[Dade]

I assume it is not possible to split an image with 3 channels into 3 textures with 1 channel each?

Yes but you need one image sampling ops for each channel instead of single one (i.e. 3 Vs 1): you are likely to loose the 0-15% performance boost you obtain by using the hardware instead of software texture sampling.

I don't know what hardware image maps are exactly, but I guess something like that would defeat their purpose?

I have done it for 2 reasons:

1) using the hardware is faster;

2) handling each image map as a single object allow to updated a single image in case of a scene edit (instead of having to re-transfer all of them like now).

I don't find acceptable to pay a 33% memory overhead to gain something like an avg. 8% performance boost. I'm probably going to ditch #1 and keep only #2. In any case this is going to be a CUDA only feature because the support is not available in OpenCL.

[Sharlybg]

Displacement make material preview crash.

test with this Lol material.

[juangea]

TBH that 8% sounds like something good... that can't be optional right? (well I know it can with a defined amount of work, the thing is that if that amount of work makes sense or not, probably not because of what you said, and there may be other and better optimisations, but just wanted to ask

In the end an 8% means nearly 1 minute in a 10 minutes render for an animation that means going from 58.33 hours for a 350 frames to 53.95 hours (if we take an equivalent of 9,25 minutes, instead of 9 full minutes.

Anyways, if what I just said is a non-sense... ignore this message, I'm lately looking for ways to optimise render times without loosing quality as much as I can

[Sharlybg]

Also another thing that can lead to crash is having both material preview and viewport rendering enable while thicking a shader.

[TAO]

I think there is a bug that causes the blender crash.
I test the issue with at least 10 different maps from HDRIheaven and png from various websites and the result was always the same.
viewtopic.php?f=5&t=3160

Step to reproduce the issue.
1- Select LuxCore as the renderer
2- Select any 16K/bigger HDRI as an environment map
3- Try to change the ENV gamma

Issues:
First, changing parameters is taken too much time compared to other renderers with the exact same steps.
Second, After a few try blender/3dsmax/LuxCore getting unstable and most likely crashes.

I think the issue is coming from converting all maps in LuxCore and not just use them. (it somehow no other choice with plugins like blender plugin)
It can be reproduced with any other big HDRI, or Png texture, used on objects material or environment map.

Sample scene, proof of concept, and other information is available in the viewtopic.php?f=5&t=3160 thread.

[juangea]

Dade is the Bevel shader finished in LuxCore so it can be implemneted in BlendLuxCore?

Thanks!

[Dade]

Dade is the Bevel shader finished in LuxCore so it can be implemneted in BlendLuxCore?

Nope.

[MetinSeven]

Dade is the Bevel shader finished in LuxCore so it can be implemneted in BlendLuxCore?

That'd be great!