Page 2 of 2

Re: Some general questions about the terminology

Posted: Sun Jan 09, 2022 7:22 pm
by Sharlybg
JulianoLisboa wrote: Sun Jan 09, 2022 5:19 pm I totally understand, but it would be nice to have some speed presets from luxcore itself.
The problem as Dade told you is that speed isn't necessary related to engine settings.
But also to some trick arround shaders and faking behaviour like with the current cycles
caustics implementation. If we want to apply your render preset idea to luxcore it would
only create a twin of cycles while being very time consuming to code.

In the other hand Speed can be see as relative because in CGI it is directly connected with :
1__Quality wich isn't factored in many misleading benchmark
2__User time consumed to reach a typical level of realism

At the ends Lux have a different goal and philosophy compared to cycles. And if an artist is
completely satisfied with Cycles you aren't going to get him to use something Like Luxcore.
I mean If someone work require game engine quality level he will always tell you that Eevee
or Unreal are GOD. Because thoses kind of artist nor they clients search for accuracy.

If you look closely in Luxcore community thoses using it are searching for a more accurate
solution.High quality and realism is on top for people willing to try luxcore.And I think quality
like gold is a timeless value. Even game engine try to get it and each time they get closer they
say Next Gen tech.

A better solution over preset could be to make the current algo more efficient.

Conclusion :

Being fast by loosing quality is a strategy already employed by cycles and many other solution.
And it work for certain kind of audience.
But there is also Quality accuracy based strategy wich mean when you gain speed it is not by
sacrificing lof of quality but by being more efficient in the way you reach this level.
And such solution have its audiences.

Re: Some general questions about the terminology

Posted: Tue Jan 11, 2022 5:23 pm
by Storen
Sharlybg wrote: Sun Jan 09, 2022 7:22 pmnot by
sacrificing lof of quality but by being more efficient in the way you reach this level.
And such solution have its audiences.
I agree completely. I think accelerating the bidirectional raytracing for maximum quality and realism would be the "marketing" direction appreciated by most of the current users rather than trading speed for realism.

I know currently BiDir supports only CPU processing. I wonder why is that the case? Is it because of the nature of the algorithms used for calculating the rays, starting from the light sources, is too complex for the GPU? Or is it because it would require 2 dedicated GPUs - one for path tracing and another for light tracing? I am not suggesting this, I am just curious.