Thanks for the explanation, after further testing the image looking brighter was because I set the Large Mutation Probability too low, for this scene, setting it at around 50% gives you the same brightness as the Sobol Sampler.
Iâve also got a few questions regarding Metropolis: if you set the rendering method to GPU and switch to Bidirectional, you canât choose Metropolis, while if you set the rendering method to CPU first, then choose Bidir, the Metropolis option appears. How come?
And the second question: if render time wouldnât matter, would Bidir + Metropolis yield the most realistic, physically correct result in the end?
Thanks.
This was simply a bug, I fixed it, thanks for the report.
Depends on the light paths involved in the scene.
Bidir has the problem that it canât render SDS paths (specular-diffuse-specular, for example caustics on the bottom of a pool seen from above the water surface). Our unidirectional Path engine, on the other hand, can render SDS paths because it can use the PhotonGI caustics cache. In such a scene, Bidir would actually be unable to produce the correct result.
I think since Path has been augmented with the âadd light tracingâ feature and the caustics cache, there are only a few scenarios left where Bidir is more correct.
This is extremely useful to know.
Just got of a phone today with a pool designer client in Florida asking about render engines.
Thanks for the explanation. I assume with âcaustics cacheâ youâre referring to PhotonGI Cache?
So if I understand it correctly, using Path + Sobol and activating Light Tracing + PhotonGI Cache is at least as good as Bidir + Metropolis, but renders faster because it uses GPU?
And does changing the Pattern from Progressive to Cache-friendly have disadvantages for the quality of the result? Maybe the Cache-friendly pattern is blurrier / less detailed?
Thanks.
Most of the time, yes.
No, the quality is exactly equal, the pattern only changes how many samples per pixel are rendered per walk over the image. (progressive = 1, cache-friendly = 32, out-of-core = 512)
We have released LuxCoreRender v2.4RC1.
If all goes well, the final release of v2.4 will follow in a few weeks.
I have created a page with a user-friendly overview of the new features in v2.4, which you can see here: https://luxcorerender.org/new-features-in-v2-4/
Nice overview, thanks. Especially the Sampling pattern differences are more clear to me now.
I want to dive deeper in luxcore, it looks so good,. You guys are doing an amazing job!
Of course thatâs easier said than done given the amount of stuff I have to do during the day, but I hope I can find some time to play with lux soon!
I canât use Luxcore since it makes my PC really slow and causes blender to crash. I can render but when building the materials causes problems. Is there a way to fix this?
If youre getting into LuxCore I would suggest making a scene specifically for LuxCore rather than getting a Cycles scene and rendering it with LuxCore, it makes the experience mroe enjoyable, at least for me.
Do you have an Intel GPU ? Does it happen with CPU-only rendering ? used OS ?
I have an AMD Ryzen 3 3200 and a NVIDIA 1050ti and use Linux. Itâs a bit faster on CPU but still laggy.
How much memory do you have ? Does LuxMark work fine ?
Quick question to the amazing devs of my favorite free photo real spectral render engine of all time. Yes I am a fanboy⌠I am still on the original 2.3 release. I am starting a new project that I planned to do in lux. Is 2.4 going to be compatible with all the same node setups? If I start now before I update when the official 2.4 release is out, should I expect to do any reworking of any materials or should it all pretty much render the same?
Usually we do our best to maintain backwards-compatibility, so yes, old scenes will work in newer versions.
The only recent release where we had to break this was 2.3 because of reworks in the light unit system. In this case we provided an automatic conversion button for old scenes.
In v2.4 there were some fixes to the behaviour of bumpmapping with mix and glossycoating materials when rendering on GPUs, which could lead to subtle changes in old scenes, but I donât expect it to be a problem.
Thats awesome. I really appreciate it. I donât think I will be to lighting yet by then but I am happy to know the materials shouldnât really be affected so I can get started on them immediately.
Besides the materials I noticed above a video someone posted about it being able to detect best render settings. I have done this myself for many years just out of habit, but I am interested in trying it out when I get to the rendering stage. Out of curiosity, does the questionnaire factor in computer specs into its analysis or is it purely an answer based, situational, âget you close,â sort of solution?
I have 4gb. what do i do with LuxMark?