Usability and Luxcore workflow streamlining ideas

[lacilaci]

It only give me the feeling that it is there to avoid newbie to do things wrong.

Yes you are correct!

[lacilaci]

Ok, so here's an idea that I always get but I'm not sure if applies to other users.
I have pretty big library of textures that I gathered thourough the years and they are great but.
I almost never use them as they are by default, almost always i need to plug a mix node between texture and material input(mostly applies to roughness)
It is kinda slow and very repetitive process, not a big deal but...

What if there was color mix and saturation+contrast controls right in texture node? So that every texture can be tweaked in it's own node?

By color mix I mean basic color just a swatch and mix mode with % control. Saturation and contrast with a % control too. And if the user needs more advanced mixing(with other textures) and controls over it, they can use regular nodes and/or do it outside blender.

Reasoning is, that roughness or glossines maps you get from internet or even when you make your own outside blender and luxcore will always need some tweaking for final material look, and even more so in some specific situation/lighting. And diffuse maps often need some saturation/contrast tweaks too.

Vray and if I remember corona too, have this covered by having a default color for every input that can have color and when you plug-in texture you can then lower the % right in material node to get weaker influence of the texture by mixing it with the default color of given input.
But having this in texture node gives much more freedom since every texture can be tweaked on it's own.

I think this could be a pretty big timesaver and makes material editing cleaner.

[B.Y.O.B.]

I have also thought about this.
In the old LuxBlend there was an "M" button for each texturable property, and if you pressed it, the original color would be multiplied with the texture ("M" as short for "Multiply").

I have done a mockup/hack how this could look like:
Video: https://youtu.be/08W_nVxosuw

[lacilaci]

I have also thought about this.
In the old LuxBlend there was an "M" button for each texturable property, and if you pressed it, the original color would be multiplied with the texture ("M" as short for "Multiply").

I have done a mockup/hack how this could look like:
Video: https://youtu.be/08W_nVxosuw

Multiply looks like a very bad way to control texture color to me.

Your mockup is close, but if instead "M" there was value input in % to signify how much effect does the texture has over color (basic mix not multiply) /this is how vray and corona in 3dsmax work afaik. Feature being not too useful for diffuse as much as Roughness for example. (It still might need a little thought to clarify to user how it works, like positioning "###%" value box near input and color swatch on the far side/after "Diffuse color" name with default value of 100% for texture )

For diffuse type of textures it would be much better to have a texture node setting for contrast, value/brightness, hue maybe. To avoid using extra nodes for basic tweaking if only single texture is being tweaked..

I'm doing lots of rendering these days but then I maybe find some time to do a mockup if needed to clarify what I'm asking for.

[B.Y.O.B.]

Your mockup is close, but if instead "M" there was value input in % to signify how much effect does the texture has over color (basic mix not multiply)

Yes, makes sense.

Instead of changing the UI we could also make a shortcut that inserts a mix node or HSV node.
We could try to mimic some of the top features of node wrangler.

[lacilaci]

Your mockup is close, but if instead "M" there was value input in % to signify how much effect does the texture has over color (basic mix not multiply)

Yes, makes sense.

Instead of changing the UI we could also make a shortcut that inserts a mix node or HSV node.
We could try to mimic some of the top features of node wrangler.

Yes I even forgot about node wrangler. Super useful when working with 2.8 and cycles.

It is kinda less intuitive since it would be hidden behind some shortcut for new users I think. On other hand, people that use blender also tend to use node wrangler and are familiar with it's shortcuts.... Although I only remember ctrl+t myself

[B.Y.O.B.]

I have created a github issue to keep track of all the different threads about simplification/streamlining of settings: https://github.com/LuxCoreRender/BlendL ... issues/243
I will read them again after the port to 2.8 and I will re-evaluate them. A lot of the ideas in these threads unfortunately require to break old scenes (meaning you would have to downgrade BlendLuxCore to render a scene you saved with an old version). Usually I want to avoid this at all costs for obvious reasons (imagine if your asset library has to be re-done every few months).

Also, I will have to find a solution to the following problem:
When I rewrote the BlendLuxCore addon after the experiences I made with the old LuxBlend, my goal was to cut away as much unnecessary stuff as possible. For example, I felt that light strategy and metropolis parameters were settings that did not need to be changed in 99% of scenes, so I left them out, with the thought that if a power user needed them in his 1% scene, he could export to scn/cfg and manually set them there. However, over time these settings that I deemed unnecessary crept back into the UI, which was caused by user requests.
This is a problem I need to solve sooner or later if I want to prevent the UI to become like the one in the old LuxBlend: 100 settings but in almost all your projects you only tune 10 of them.
It's a difficult task: shielding the user from himself, without taking away his freedom and without holding back power users who really know what they are doing. Lately, I have seen a few scenes where people used path depths of 500 or more. I could force a maximum of 30 or so to help these people not screw up their render performance and VRAM usage, but on the other hand I would make life a lot harder for people who want to simulate optical phenomena with that many light bounces.

[lacilaci]

I have created a github issue to keep track of all the different threads about simplification/streamlining of settings: https://github.com/LuxCoreRender/BlendL ... issues/243
I will read them again after the port to 2.8 and I will re-evaluate them. A lot of the ideas in these threads unfortunately require to break old scenes (meaning you would have to downgrade BlendLuxCore to render a scene you saved with an old version). Usually I want to avoid this at all costs for obvious reasons (imagine if your asset library has to be re-done every few months).

Also, I will have to find a solution to the following problem:
When I rewrote the BlendLuxCore addon after the experiences I made with the old LuxBlend, my goal was to cut away as much unnecessary stuff as possible. For example, I felt that light strategy and metropolis parameters were settings that did not need to be changed in 99% of scenes, so I left them out, with the thought that if a power user needed them in his 1% scene, he could export to scn/cfg and manually set them there. However, over time these settings that I deemed unnecessary crept back into the UI, which was caused by user requests.
This is a problem I need to solve sooner or later if I want to prevent the UI to become like the one in the old LuxBlend: 100 settings but in almost all your projects you only tune 10 of them.
It's a difficult task: shielding the user from himself, without taking away his freedom and without holding back power users who really know what they are doing.

Do not listen to legacy requests.. it made vray a complete fuckfest of settings that don't need to be there...
"advanced" settings that as you said don't need to be changed 99% of time are also mostly requested to be kept by complete idiots that think they do some voodoo magic to make shit faster, but most of the time it even might be the opposite.

If you believe something should go and someone has problem with it then demand a specific concrete example. I'm all ok with artistic controls but technical stuff should be minimized to bare minimum. In other words things regarding optimization should be ideally non existent and decided internally, or by presets.

It is super easy to break stuff in luxcore right now... Also, since userbase seem to be very small at the moment, rather break compatibility now and make things future proof than do it later cause it spins out of control with new features and permutations of settings that make no sense.

[B.Y.O.B.]

I don't think you can write off wrong choices of settings as the user being an idiot. Most of the time, the UI is not communicating enough information (or the right information) to enable the user to make the correct choice for his situation.
For example, I just looked at the path depth tooltip and found that there is none! There should be a tooltip that helps the user decide how high to set the path depth. And if he still chooses a very high value, there should be a warning and if he runs out of VRAM, the error message should contain a list of possible causes, among them the unusually high path depth.
These kind of things get overlooked because a) we developers are too experienced with LuxCore, we don't even hover over the path depth long enough to see that there's no tooltip and we don't choose 500 path depth, and b) we don't do organized testing with real users in a lab (because it's too much effort and cost to handle). Our users could help us by reporting such things as missing tooltips.

When designing software, in my opinion you should always imagine an intelligent but inexperienced user.

[lacilaci]

I don't think you can write off wrong choices of settings as the user being an idiot. Most of the time, the UI is not communicating enough information (or the right information) to enable the user to make the correct choice for his situation.
For example, I just looked at the path depth tooltip and found that there is none! There should be a tooltip that helps the user decide how high to set the path depth. And if he still chooses a very high value, there should be a warning and if he runs out of VRAM, the error message should contain a list of possible causes, among them the unusually high path depth.
These kind of things get overlooked because a) we developers are too experienced with LuxCore, we don't even hover over the path depth long enough to see that there's no tooltip and we don't choose 500 path depth, and b) we don't do organized testing with real users in a lab (because it's too much effort and cost to handle). Our users could help us by reporting such things as missing tooltips.

When designing software, in my opinion you should always imagine an intelligent but inexperienced user.

Look, I believe you make correct choices, so far there isn't much to complain about.

But now, to the very specific topic you outlined... You can run out of vram with pathdepth only with metropolis right? Metropolis is not working well on gpu and should simply be disabled. There are couple of settings that don't work well and combinations of settings that don't work well and all of them should go away instead of communicating anything... Just my opinion, and I stick by legacy features should go now or will have to stay forever if userbase grows to a significant amount and will force you to keep stupid stuff in.