You can support our project with donations.
To give back some reward to donors, we have created a new forum rank.
The details are explained in this post.
I’ve been following the development of LuxRender/LuxCore from the beginning. During that time I didn’t have an easy time getting anything decent out of it and stuck to Cycles and playing with the (for me) more easy to control free version of IndigoRenderer. But now I must say LuxCore is getting better and better and I left Indigo Renderer for what it is (even removed it from Blender!). I’ve been working with the new LuxCore for a couple of months and there’s still a lot to learn. Thanks to the excellent Blender integration, that is something I look forward to. I’d love to see more documentation, though; getting things done by trial and error is not very efficient… Also: a basic Cycles to LuxCore material converter would be a great addition. Even if it just converterd textures and basic material attributes initially, that would save a lot of time and increase productivity.
One thing I am noticing from Dade’s leadership is that Luxcore is going in the very unusual direction of introducing caching techniques and pre-processing steps, while the vast majority of engines are moving away from them. Is there any reason for it?
I’m sure it would be faster, but that is only if it’s done in a very smart way. Otherwise, the time saved is going to be canceled out by the forest of settings that this type of rendering tech. will bring (ie. trading render time for setup time/trial and error). Even more so, it may bring a higher chance of new feature A not working fully with feature B, something that was a pain with Blender’s old internal engine.
I know that these features will probably be completely optional, but path-based sampling techniques get better and better every year.
You are certainly right with your observation. One reason is that the LuxCore team made a feature poll, asking users to name the 6 most wanted features which they wish to be implemented. And the result was that caching for indirect light, caching for direct light and a Disney type principled shader won the ranking (see link) https://forums.luxcorerender.org/viewtopic.php?f=5&t=308
If this is a good strategy to decide on new features is debatable. It is certainly listening closely to the users and their wishes. One drawback I see is that most users (not all) know current features from commercial engines but may not be up to date with the newest developments or trends in rendering technology and research, providing potentially better solutions than the ones they know.
B.Y.O.B
(Node Preview and LuxCore Addon Developer)
5
Humm Vray / Corona / Redshift are changing what made them so fast ???
Which renderer using theses method are moving away ? with wich method ?
AI ?
I’m supprise seriously !
Compared to the existing denoiser in LuxCore (BCD), OIDN is much faster, uses less RAM and gives better results. Since the performance is so much better, I will also integrate it into the viewport like I did in my experiment with Optix.
a little thing, Auto brightness setting (tonemapping) as default is misleading(bug?).i was reducing light gain, but the object render color was not reducing correspondingly.after disabling auto brightness and setting linear gain to 1.0 it was working as expected.
Autobrightness is actually a feature, not bug.
I do agree it shouldn’t be on by default cause I’ve seen few people already having trouble when first trying luxcore.
B.Y.O.B
(Node Preview and LuxCore Addon Developer)
15
I agree that it can be an annoyance, and actually I think it should be turned off by default.
The reason why I did not do this so far has been that the sun and sky light sources in LuxCore use realistic brightness, which means they are a lot brigther than all other lights (which are around the brightness of normal household light sources).
I have two choices:
Turn off auto-brightness and leave light sources like they are now: The user will see a correct image with most lights, but only white with sun/sky. Or correct image with sun/sky, but black image with other lights
Turn off auto-brighness and modify sun/sky brightness: This would be the most user-friendly solution, but sun/sky brightness would no longer be physically based by default. Or: I could make all other light sources much brighter by default.
There’s also the problem of changing a default value in an addon: it will screw up all old files where the default was not changed (this is Blender behaviour).
Currently I’m considering to implement the second choice when I finish the 2.8 port of the addon.
Why did the color of the light shift from a bluish tint to stark white?
One thing to note about introducing Photons is that you’re going back to the day when you would need a ton of them at small sizes to get accurate lighting on small details, that’s not to mention the potential difficulty in using them for expansive outdoor scenes. Then there’s the introduction of the need for thick walls unless the implementation does some sort of anisotropic clipping.
I do have some experience with Photons via experimental Blender builds that tried to add them to Blender internal and SPPM with old versions of Luxrender, getting the right resolution for smooth lighting and no leaks is no easy feat.
Pathtracing has problems getting enough sunlight there, bidir does work better but is slow, caching seems to give proper lighting while being also fast.
Also there were light leaks/bleeding but now is there a workaround(check luxcore forum thread if you’re interested)
And lastly, this is first attempt at gi and also caustics caching for luxcore. If it should fail, there are other possibilities how to approach the problem.
B.Y.O.B
(Node Preview and LuxCore Addon Developer)
20
It is more accurate.
Here’s a 500 samples Bidir render, with denoised version, as something like a ground truth.
