Better Cycles compatibility

Discussion related to the LuxCore functionality, implementations and API.
Post Reply
Nicknroll
Posts: 3
Joined: Fri Oct 23, 2020 9:40 am

Better Cycles compatibility

Post by Nicknroll » Fri Oct 23, 2020 10:48 am

Hi!
At the week occasionally decided to test LuxCore because of LightGroups, and was surprised how good engine is, especially for interior renders. There is a lot of features i wished before, which in Cycles we can wait eternity.


So i tried to test some cycles assets and found many of them can't be translated to work in Lux properly.

My attempt to render Quixel assets with Cycles shaders, which isn't complex (same with Scatter addon assets), Log says about lack of basic operators:
LuxCore Quixel asset.jpg
LuxCore Quixel assets.jpg
Here i get different result at preview and final render, when i tried to render tree with simple cycles translucent material.
Left is correct result in viewport rendering, right is final render, i tried to play with different settings but result remained the same (both Lux, cuda+cpu):
LuxCore colors bug.jpg


Some other notes:
In the scene lighting i can't see and use HDRi managers like Gaffer and ProLighting addons, i don't see any reasons they have to be disabled if i use Cycles settings for Luxcore:
Screenshot_1.jpg
Also in my opinion i would prefer to use single shader editor, if it possible, for both Cycles and Lux, because if material translated wrong i could just put maps into Lux shader, but now if asset has a dozen of maps to find them manually and put into new lux shader it takes a lot of time:
Cycles to Lux shaders.jpg

So i would like to know about developers vision about compatibility in future.

Thank you in advance!
-Nick
Last edited by Nicknroll on Thu Feb 11, 2021 10:40 pm, edited 4 times in total.

User avatar
Sharlybg
Donor
Posts: 2628
Joined: Mon Dec 04, 2017 10:11 pm
Location: Ivory Coast

Re: Better Cycles compatibility

Post by Sharlybg » Fri Oct 23, 2020 11:12 am

Also in my opinion i would prefer to use single shader editor if it possible for both Cycles and Lux, because if material translated wrong i could just put maps into Lux shader, but now if asset has a dozen of maps to find them manually and put into new lux shader it takes a lot of time:
https://drive.google.com/file/d/1ePwD3Y ... sp=sharing
This last part if possible can be really time saving.
Support LuxCoreRender project with salts and bounties

Portfolio : https://www.behance.net/DRAVIA

User avatar
B.Y.O.B.
Developer
Posts: 4033
Joined: Mon Dec 04, 2017 10:08 pm
Location: Germany
Contact:

Re: Better Cycles compatibility

Post by B.Y.O.B. » Fri Oct 23, 2020 1:50 pm

Please embed the images into your post.
Nicknroll wrote:
Fri Oct 23, 2020 10:48 am
My attempt to render Quixel assets with Cycles shaders, which isn't complex (same with Scatter addon assets), Log says about lack of basic operators:
The problem with these "basic operators" is that there are just so many of them, so it takes time and effort to implement support for all of them.
We have already added some of the math operations, see https://github.com/LuxCoreRender/LuxCore/issues/118
But almost none of the color operations were implemented so far.
You can see what Cycles nodes are supported here: https://github.com/LuxCoreRender/BlendL ... issues/272
Nicknroll wrote:
Fri Oct 23, 2020 10:48 am
Here i get different result at preview and final render, when i tried to render tree with simple cycles translucent material.
Left is correct result in viewport rendering, right is final render, i tried to play with different settings but result remained the same (both Lux, cuda+cpu):
Please open an issue on github and upload the scene so we can try to reproduce the problem.
https://github.com/LuxCoreRender/BlendLuxCore/issues
Nicknroll wrote:
Fri Oct 23, 2020 10:48 am
In the scene lighting i can't see and use HDRi managers like Gaffer and ProLighting addons, i don't see any reasons they have to be disabled if i use Cycles settings for Luxcore:
This is not our responsibility. You will have to contact the authors of these addons, and they will have to enable the panel in this case.
Nicknroll wrote:
Fri Oct 23, 2020 10:48 am
Also in my opinion i would prefer to use single shader editor, if it possible, for both Cycles and Lux, because if material translated wrong i could just put maps into Lux shader, but now if asset has a dozen of maps to find them manually and put into new lux shader it takes a lot of time:
This is planned: https://github.com/LuxCoreRender/BlendL ... issues/362

Your points are valid and we are aware of them, it just takes time and effort to make them happen.

evacnoc
Posts: 12
Joined: Sun Sep 29, 2019 6:33 pm

Re: Better Cycles compatibility

Post by evacnoc » Sun Nov 01, 2020 1:15 pm

Would a Cycles Material Reader Node be possible?
cyclescomp.jpg
Most of the time, with simple materials, the Use Cycles Nodes can read the material but the mapping is wrong as it's not supported yet.
So it's frustrating having to redo all the material in Luxcore, reassign textures, etc just because of a mapping issue. If we could have a Cycles Material Reader Node, we could just plug in a Luxcore mapping (2d, Triplanar) to adjust it.


Is the translucent bsdf supposed to work? For example a Cycles mix shader between a Principled BSDF and a Translucent BSDF?
Just like Nicknroll, on trees for example, I'm having white leaves when Luxcore tries to read it.


The Cycles scene reader project is so important because of:
-Eevee (it's so nice to prepare shader with it)
-Inhouse already made materials (huge work to redo all of them)
-Libraries that come with Cycles shaders
I'd like to use Luxcore only but sometimes it's so much more work than to simply do it with Cycles even if the result is not as beautiful.

Mapping and translucent compatibility represent most of my problems, that's why I'm asking.

juangea
Donor
Posts: 224
Joined: Thu Jan 02, 2020 6:23 pm

Re: Better Cycles compatibility

Post by juangea » Tue Nov 03, 2020 9:16 am

I agree that to vastly improve compatibility just so minor nodes have to be improved/implemented.

Usually they are Mapping / texture coordinates, and translucent / sub surface, with that toolset a big majority of cycles shaders could be fully compatible since ArchViz materials tend to be simple enough.

Like a principled shader and some textures with some mapping, other more complex materials can be found of course, but in general broad way, the main reason why materials are incompatible are those nodes.

On the other hand we also have in the roadmap the improvement of the principled shader in Lux to be on pair with the Cycles one, that would improve things too, since the subsurface scattering algo implemented could make SSS work way easier than now :)

Post Reply