Page 31 of 92

Re: BlendLuxCore Development

Posted: Mon Apr 09, 2018 5:19 pm
by jensverwiebe
On SUSE this embree tweak does not help, where in other distro/configs it does.
I wonder if there is something broken with runpathes in SUSE or just different,
because also blender shows such unexplainable errors, while the libs are in their
proper location and pointed right. Could be also libstdc++ related.
SUSE expertise is needed here.

[bug] Dimensions

Posted: Mon Apr 09, 2018 8:39 pm
by kintuX
If render Dimensions are set as 'Portrait' format (Y - longer), image is cropped & enlarged.

I think that Lux considers it as X dimension then crops and scales relatively (i'm not 100% sure, just a quick observation on 1:2 portrait format).
Image is rendered in proper dimensions.

eg: live preview - this gets rendered and scaled up
bugDIM.jpg

Re: [bug] Dimensions

Posted: Tue Apr 10, 2018 5:54 am
by neo2068
kintuX wrote: Mon Apr 09, 2018 8:39 pm If render Dimensions are set as 'Portrait' format (Y - longer), image is cropped & enlarged.

I think that Lux considers it as X dimension then crops and scales relatively (i'm not 100% sure, just a quick observation on 1:2 portrait format).
Image is rendered in proper dimensions.

eg: live preview - this gets rendered and scaled up
bugDIM.jpg
It seems that you don't use automatic sensor fit in the camera view. Changing that property is a quick workaround of the bug. I added the issue to the bug tracker (https://github.com/LuxCoreRender/BlendL ... issues/122) and will look into the code this evening.
horizontal sensor fit:
horizontal.JPG
automatic sensor fit
Auto.JPG

Re: [bug] Dimensions

Posted: Tue Apr 10, 2018 10:04 am
by kintuX
neo2068 wrote: Tue Apr 10, 2018 5:54 am It seems that you don't use automatic sensor fit in the camera view. Changing that property is a quick workaround of the bug. I added the issue to the bug tracker (https://github.com/LuxCoreRender/BlendL ... issues/122) and will look into the code this evening.
Oh, I totally missed that. Thought, i always had it on Auto. Ever since similar problem appeared with Pixar's RenderMan bridge/exporter (year or more ago). Guess i wasn't thinking at all.
Yup, Cycles is unaffected by this.
8-)
Thank you very much for reminding me.

Re: BlendLuxCore Development

Posted: Thu Apr 12, 2018 6:35 pm
by B.Y.O.B.
The color channel of smoke is now supported.
However it is slower to export than the other channels (because it needs a bit of work in Python to convert from 4-element array to 3-element (RGB) for LuxCore, and because it's 3 times as much data to transfer).

And it requires a rather peculiar node setup, because we want to use the colors on the absorption color, however Blender puts black colors where density = 0 which results in a big black domain cube if you just plug the color into the absorption.
So you have to replace black with white where the density is 0, which basically means: invert the density and add it to the color, then plug the result into the absorption socket.

Re: BlendLuxCore Development

Posted: Thu Apr 12, 2018 8:28 pm
by B.Y.O.B.
Is there ever a situation where the wrap mode in the smoke node is needed?
I can't think of one. The density grid is always transformed to be exactly as large as the smoke domain.

Re: BlendLuxCore Development

Posted: Thu Apr 12, 2018 9:51 pm
by Dade
B.Y.O.B. wrote: Thu Apr 12, 2018 8:28 pm Is there ever a situation where the wrap mode in the smoke node is needed?
I can't think of one. The density grid is always transformed to be exactly as large as the smoke domain.
For instance, you could enable "repeat" and scale the grid by 1/10 of the smoke domain to repeat the patter 10 times. It is just an heterogeneous volume so it can be water, smoke, fire, clouds, etc. To repeat the pattern can be handy (however it may be useless in Blender if it doesn't have such concept).

Re: BlendLuxCore Development

Posted: Fri Apr 13, 2018 7:58 am
by B.Y.O.B.
Dade wrote: Thu Apr 12, 2018 9:51 pm (however it may be useless in Blender if it doesn't have such concept)
I have the feeling that this is the case.
We could add a 3D transformation socket to the smoke node, but it would make everything much more complicated for little benefit (e.g. the automatic step size calculation would have to account for it).

I removed the wrap mode setting, but added the storage setting with explanations about the various storage types and what they incline.

Re: BlendLuxCore Development

Posted: Sat Apr 14, 2018 9:44 am
by B.Y.O.B.
I'm working on cached node export.
Up until now, if a node was used by multiple sockets, it was exported multiple times.
This is not a problem for most nodes (including images, they are cached by LuxCore), but it starts to get annoying with nodes that have long export times (i.e. smoke).

In the image below, the image was previously defined eleven times, now it is defined only one time and the name is re-used on the other sockets.

Re: BlendLuxCore Development

Posted: Sat Apr 14, 2018 4:08 pm
by Dade
We need some kind of integration of network rendering with BlendLuxCore: it can be as simple as a flag in scene export panel to execute "pyluxcoretool netconsoleui <exported binary scene file name>" or, may be, something a bit more visible like a dedicated "Network rendering" button.

The idea is just to export the scene in binary format and execute the appropriate command (for Windows or Linux). pyluxcoretool.exe (or pyluxcoretools.zip) can be included in BlendLuxCore inside bin directory as other binaries.
One the command has been lunched, BlendLuxCore can simple forget about pyluxcoretool. The pyluxcoretool GUI will take on from there.