Page 4 of 7

Re: LuxeedRay opensource renderer

Posted: Thu Jun 10, 2021 10:33 am
by TAO
Honestly, I recommend LuxCore to many renderers and the majority of them was Cycles users (in 3dsmax V-ray), the main problem they talk about was not supporting Cycles nodes automatically by luxcore and bevel-node.
One developer in every area is good but not enough to support every feature and getting the best results, especially that all developers already have another job to make a living.
Everyone here especially Dade, B.O.B.Y, and the others try their best to keep up and personally I appreciate all the efforts.
One of the main reasons we work on plugins such as Maya or 3dsmax is to engage more users from all other ecosystems and not just blender.
I really know there is more thing we can do and there are more ways to do it but considering such a small community that we are, is a pretty great job that we do.

Re: LuxeedRay opensource renderer

Posted: Thu Jun 10, 2021 11:14 am
by Dez!
This is just disillusion. Your claim is obviously wrong.
I'm very interested, I really want to see the product and equipment visualization work at Luxcore. I really want to be inspired by other people's work in this field. I'm really experiencing isolation on this subject.
Where can I see it?

Re: LuxeedRay opensource renderer

Posted: Thu Jun 10, 2021 11:16 am
by Sharlybg
Honestly, I recommend LuxCore to many renderers and the majority of them was Cycles users (in 3dsmax V-ray), the main problem they talk about was not supporting Cycles nodes automatically by luxcore and bevel-node.
One developer in every area is good but not enough to support every feature and getting the best results, especially that all developers already have another job to make a living.
Everyone here especially Dade, B.O.B.Y, and the others try their best to keep up and personally I appreciate all the efforts.
One of the main reasons we work on plugins such as Maya or 3dsmax is to engage more users from all other ecosystems and not just blender.
I really know there is more thing we can do and there are more ways to do it but considering such a small community that we are, is a pretty great job that we do.
I know we all want the best for luxcore. And we are doing a great job. But it is also we need to improve and focus energy where it is require.
Ok so what is the plan ?
What to expect ?
What are the goals and time we give to achieve that considering our size ? a Roadmap adapted to our size and constrains ?
What feature development to priotize to improve ?
Why not anwser when we get invited by some community when we lack visibility ?

Even if we all work on the project on spare time i thime we have quite some big margin to improve how we use this time.

Re: LuxeedRay opensource renderer

Posted: Thu Jun 10, 2021 1:06 pm
by JulianoLisboa
Dez! wrote: Thu Jun 10, 2021 11:14 am
This is just disillusion. Your claim is obviously wrong.
I'm very interested, I really want to see the product and equipment visualization work at Luxcore. I really want to be inspired by other people's work in this field. I'm really experiencing isolation on this subject.
Where can I see it?
I also render products with Luxcore, but my focus is on beverages, cosmetics and medicines. I agree with everything you said, especially using Luxcore for love. It is the pure truth. I have already decided to stop using it several times and I always come back with the hope that some things will be resolved. Let's go in faith.

You can see some of my work here:
https://www.instagram.com/julianolisboadesigner/

Re: LuxeedRay opensource renderer

Posted: Thu Jun 10, 2021 4:09 pm
by Sharlybg
The vast majority of the our users use GPU rendering (and have NVIDIA GPUs). The source of your problem is in having picked an AMD GPU.
That is really strange i never saw it because of my workflow. I can confirm the same issue on GTX 1080Ti :shock:

Youtube Link

https://youtu.be/PpBVFQOjojM

Re: LuxeedRay opensource renderer

Posted: Thu Jun 10, 2021 4:24 pm
by TAO
The slowness in starting the render came directly from the time needed for converting the scene.
If you remember we all somehow report this issue in different threads, most of the problem is coming from the slow conversion of the scene especially with too many objects or maps. the main core of conversion is not thread-safe and objects should convert one by one object and for the maps converting all image to PNG take too much time especially big PNGs can take a long time, just converting one 300Mb HDRi to Png can take up to 20 seconds on my 9900k pc. you can test it just by using one single HDRi (more than 200Mb) for lighting and simply try to change the gamma of it and see what will happen.
I tried so many solutions like multi-threading and Async but it will not help really. in the best case, I was able to achieve 30% boot that was not bad but not good enough either.

Re: LuxeedRay opensource renderer

Posted: Thu Jun 10, 2021 4:32 pm
by Sharlybg
TAO wrote: Thu Jun 10, 2021 4:24 pm If you remember we all somehow report this issue in different threads, most of the problem is coming from the slow conversion of the scene especially with too many objects or maps. the main core of conversion is not thread-safe and objects should convert one by one object and for the maps converting all image to PNG take too much time especially big PNGs can take a long time, just converting one 300Mb HDRi to Png can take up to 20 seconds on my 9900k pc. you can test it just by using one single HDRi (more than 200Mb) for lighting and simply try to change the gamma of it and see what will happen.
I tried so many solutions like multi-threading and Async but it will not help really. in the best case, I was able to achieve 30% boot that was not bad but not good enough either.
So how radeon pro render does :|

And why not use the appleseed method that stop the rendering until the end of the action until we find a faster way.

Re: LuxeedRay opensource renderer

Posted: Thu Jun 10, 2021 4:35 pm
by TAO
Sharlybg wrote: Thu Jun 10, 2021 4:32 pm So how radeon pro render does :|

And why not use the appleseed method that stop the rendering until the end of the action until we find a faster way.
There are solutions of course, but most should be done from the main core, we all can try to create all mesh and maps directly from the plugins and just create the config file for it but it will be messy and also everyone should choose a different method depending on the language and limitations.
Stop the render and only update after the user stops editing is a good solution aside from a more convenient way of conversion in an async multi-thread way.
just stop the scene to finish the edit not the real solution because you can see the conversion time is too high anyway.

Re: LuxeedRay opensource renderer

Posted: Thu Jun 10, 2021 4:42 pm
by Sharlybg
Just tested with Cycles and it does stop the viewport update until you stop moving or change something.
Even the well integrated cycles does it. Guys this isn't good. I understand why people complain so much about the viewport.
I didn't try that on a complexe enough scene as i tend to avoid Viewport as complexety grow. I can work like this because of experience
And the fact that i do archviz most of the time. But this really not fair to have such a problem in a modern renderer :|

Re: LuxeedRay opensource renderer

Posted: Thu Jun 10, 2021 5:41 pm
by Dez!
Here's for an understanding of how product renderings are created, how many light sources are used to "finish off" the HDR: https://youtu.be/s_guXWSQi3U
Each light illuminates a certain area with a certain strength and softness, or is used to play light on a sharp edge.
Each needs to be precisely positioned relative to the object in rendering mode. Each has to be accurately shaped and sized.
And this is a simple case, without the use of shading planes.
Yes, 1-3 lights can be installed. Be patient for a while.
But when there are 20 of them?
Luxcore is suitable for amazing product visualizations. The highest premium class. Such orders are given to the work of the highest CG specialists. These are the kind of people we stop at the things I'm talking about. And they don't go to Cycles. They go to Corona, etc.