Usability and Luxcore workflow streamlining ideas

Discussion related to the LuxCore functionality, implementations and API.
Racleborg
Posts: 621
Joined: Sat Apr 07, 2018 10:31 am
Location: UK

Re: Usability and Luxcore workflow streamlining ideas

Post by Racleborg »

Metropolis is not working well on gpu and should simply be disabled
From a layman's point of view, I ask: is Metropolis capable of doing things on GPU that can't be done by Sobol on GPU? (GPU presumably being faster than CPU)

My apolgogy if my question is crass.

Thanks
Fox
Posts: 437
Joined: Sat Mar 31, 2018 11:17 am

Re: Usability and Luxcore workflow streamlining ideas

Post by Fox »

What about tooltip that warns too little photons?
I don't know how much it has to store them.

Example:
caustic photon stored: 219117
radiance photon stored: 9854
merged caustics photons: 40341 [18.4%]

Code: Select all

[LuxCore][13420.203] PhotonGI total photon traced: 3240067072
[LuxCore][13420.219] PhotonGI total indirect photon stored: 648015096 (2604318720 traced)
[LuxCore][13420.219] PhotonGI total caustic photon stored: 219117 (3240000000 traced)
[LuxCore][13420.219] PhotonGI building radiance photon data
[LuxCore][13420.219] PhotonGI filtering radiance photons
[LuxCore][13420.219] PhotonGI total radiance photon stored: 9854
[LuxCore][13420.219] PhotonGI building radiance photons BVH
[LuxCore][13420.219] PhotonGI merging caustic photons BVH
[LuxCore][13420.750] PhotonGI merged caustics photons: 219117 => 40341 [18.4%]
[LuxCore][13420.750] PhotonGI building caustic photons BVH
[LuxCore][13420.766] PhotonGI caustic cache photons memory usage: 1890Kbytes
[LuxCore][13420.766] PhotonGI caustic cache BVH memory usage: 1867Kbytes
[LuxCore][13420.766] PhotonGI indirect cache photons memory usage: 346Kbytes
[LuxCore][13420.766] PhotonGI indirect cache BVH memory usage: 457Kbytes
[LuxCore][13420.766] PhotonGI total memory usage: 4677Kbytes
User avatar
B.Y.O.B.
Developer
Developer
Posts: 4146
Joined: Mon Dec 04, 2017 10:08 pm
Location: Germany
Contact:

Re: Usability and Luxcore workflow streamlining ideas

Post by B.Y.O.B. »

Racleborg wrote: Sat Mar 02, 2019 12:23 am From a layman's point of view, I ask: is Metropolis capable of doing things on GPU that can't be done by Sobol on GPU?
Metropolis is working fine on GPU, the only problem is that it needs a lot of VRAM.
Apart from that, it works the same as on CPU: it's an "intelligent" sampler that spends more samples on bright areas of the image, thus rendering e.g. caustics much better than a "dumb" sampler like Sobol or Random. If the reduced speed and increased RAM usage is worth it for you depends on your scene.
https://wiki.luxcorerender.org/Render_Configuration
Fox wrote: Sat Mar 02, 2019 3:14 am What about tooltip that warns too little photons?
I don't know how much it has to store them.
I think this information will be presented in the statistics panel in the image editor.
Since the PhotonGI is so new, I don't know it well enough yet to create warnings and better tooltips. I will have to ask Dade about that once the work on PhotonGI is done.
User avatar
lacilaci
Donor
Donor
Posts: 1969
Joined: Fri May 04, 2018 5:16 am

Re: Usability and Luxcore workflow streamlining ideas

Post by lacilaci »

Last time I wanted to use metropolis on gpu I had some issues with it being super slow with and this is the response I got
Dade wrote: Sat Oct 27, 2018 11:37 am Metropolis on GPUs is "problematic": there is a sampler for each rendering thread, the problem is that, for instance, you have 12 threads on a 6 core+hyper-threading CPU while you have 512,000 threads on a GPU (it is not a typo, it is 0.5M threads).
The end result is that the convergence speed of each Metropolis sampler on GPU is a LOT slower (i.e. 512,000 / 12) that CPU version.

In general, the two best solutions in LuxCore are brute force on GPUs (PATHOCL+SOBOL) and being smart on CPUs (BIDIRCPU+METROPOLIS).
So that's why I'm avoiding it and would not use it at all unless doing CPU+BIDIR+METROPOLIS, and that would probably be a very special case still.
User avatar
Sharlybg
Donor
Donor
Posts: 3101
Joined: Mon Dec 04, 2017 10:11 pm
Location: Ivory Coast

Re: Usability and Luxcore workflow streamlining ideas

Post by Sharlybg »

Also i think we don't have to hide too much things from users. There are things that only teaching can help the best way.
This can start by nice tooltip.
Support LuxCoreRender project with salts and bounties

Portfolio : https://www.behance.net/DRAVIA
User avatar
lacilaci
Donor
Donor
Posts: 1969
Joined: Fri May 04, 2018 5:16 am

Re: Usability and Luxcore workflow streamlining ideas

Post by lacilaci »

Sharlybg wrote: Sat Mar 02, 2019 9:20 am Also i think we don't have to hide too much things from users. There are things that only teaching can help the best way.
This can start by nice tooltip.
But you still need to keep in mind users trying luxcore will come mostly from other renderers with some established general use. So while new to luxcore, not new to rendering and many times they have experience with other renderers, I used several of them myself and coming to luxcore was a bit of a shock at first. I don't want to be learning stuff that I already know and works elsewhere. It is very important that confusion and user error is kept at minimum and people that know how to work with other popular renderers have just as little time transitioning as possible.
User avatar
Sharlybg
Donor
Donor
Posts: 3101
Joined: Mon Dec 04, 2017 10:11 pm
Location: Ivory Coast

Re: Usability and Luxcore workflow streamlining ideas

Post by Sharlybg »

I agree with you ! i just hope that some important and special Lux feature/ability won't be throw out for the sake of simplicity. for example remove things like metropolis instead of hidde them as advance settings.

About all theses modification want to ask somethings to you BYOB.

Is modification about Luxcore shading will broke compatibility with user current asset ? i hope no. with all assets we moving to luxcore it will a total waste :?
Support LuxCoreRender project with salts and bounties

Portfolio : https://www.behance.net/DRAVIA
User avatar
lacilaci
Donor
Donor
Posts: 1969
Joined: Fri May 04, 2018 5:16 am

Re: Usability and Luxcore workflow streamlining ideas

Post by lacilaci »

I would be surprised if 2.3 with some material changes wouldn't break compatibility. And it should, to establish some new grounds for broad userbase.
User avatar
B.Y.O.B.
Developer
Developer
Posts: 4146
Joined: Mon Dec 04, 2017 10:08 pm
Location: Germany
Contact:

Re: Usability and Luxcore workflow streamlining ideas

Post by B.Y.O.B. »

Sharlybg wrote: Sat Mar 02, 2019 1:53 pm Is modification about Luxcore shading will broke compatibility with user current asset ? i hope no. with all assets we moving to luxcore it will a total waste
Materials/shaders won't break.
Light brightness in old scenes might change when opened in a more recent version of the addon, if I do the changes you and others have suggested about light settings simplification.
lacilaci wrote: Sat Mar 02, 2019 1:57 pm I would be surprised if 2.3 with some material changes wouldn't break compatibility. And it should, to establish some new grounds for broad userbase.
Whenever possible I will try not to break compatibility. For example, I could remove all material nodes from the "add node" menu and replace them with the disney principled shader and this would not break backwards compatibility - if I leave the old nodes in the code. They could not be added in new scenes, but old scenes would continue to work. Just an example of what's possible.

Other times, compatibility breaks in non-obvious ways. For example, when a user has not changed the value of a property in an old scene, and I change the default value of this property, the scene will render differently when opened in the new version of the addon because it will use the new default. However, if the user has set a value to the property, it will not change.
User avatar
Dade
Developer
Developer
Posts: 5672
Joined: Mon Dec 04, 2017 8:36 pm
Location: Italy

Re: Usability and Luxcore workflow streamlining ideas

Post by Dade »

lacilaci wrote: Sat Mar 02, 2019 1:57 pm I would be surprised if 2.3 with some material changes wouldn't break compatibility. And it should, to establish some new grounds for broad userbase.
It will be more about adding news stuff, I can usually just keep the old stuff as it is for compatibility.
Support LuxCoreRender project with salts and bounties
Post Reply