Cycle X (and OpenCL)

Discussion related to the LuxCore functionality, implementations and API.
User avatar
Dez!
Posts: 368
Joined: Sun Apr 08, 2018 1:09 am
Location: Ekaterinburg
Contact:

Re: Cycle X (and OpenCL)

Post by Dez! »

Sharlybg, I don't understand you. What are you trying to say?
Linux Plasma | Ryzen 5, 32Gb, SSD M2, GT 590 RX | BenQ 27 | Wacom One | Microsoft Ergo | Tie Guan Yin tea
http://dezigner.tilda.ws/
User avatar
Sharlybg
Donor
Donor
Posts: 3101
Joined: Mon Dec 04, 2017 10:11 pm
Location: Ivory Coast

Re: Cycle X (and OpenCL)

Post by Sharlybg »

Many people me included and even Devs know about this Viewport
Lagging issues. And how hard it is to move object inside the viewport.
And if irc you also mention this laggy viewport. so Juangea is saying
That the viewport make the work with luxcore painfull and just hide
the potential.

https://youtu.be/PpBVFQOjojM

https://youtu.be/_DENVWWTAQE
Support LuxCoreRender project with salts and bounties

Portfolio : https://www.behance.net/DRAVIA
pepe
Posts: 38
Joined: Wed Sep 12, 2018 1:18 pm

Re: Cycle X (and OpenCL)

Post by pepe »

The way I see it, the quality of Luxcorerender renderings are very high and the engine features are very good, but to sustain that is very hard. Can some of the code be dropped to be easier to maintain it? I am thinking something like Corona render.

https://corona-renderer.com/features/proudly-cpu-based
https://corona-renderer.com/features/the-cpu-advantage
User avatar
Dez!
Posts: 368
Joined: Sun Apr 08, 2018 1:09 am
Location: Ekaterinburg
Contact:

Re: Cycle X (and OpenCL)

Post by Dez! »

Sharlybg,
In the post about B-Renderon, I was talking about the final rendering time. Not about the rendering time of the view window.
I was talking about the fact that if the final rendering takes 30 minutes, 1 hour, even 8 hours - it doesn't matter if this rendering is done in the program B-Renderon. It will just switch to the next one on the list when it's ready. And this list can be added at any time without interrupting the rendering process.

By the way, I learned quite successfully to move objects in the preview window when pre-rendering. I found the settings that make the preview window as responsive as possible.

And it allowed me to finally start using Luxcore in commercial projects.
I think I'll be able to start February as a regular Luxcore sponsor.
Linux Plasma | Ryzen 5, 32Gb, SSD M2, GT 590 RX | BenQ 27 | Wacom One | Microsoft Ergo | Tie Guan Yin tea
http://dezigner.tilda.ws/
User avatar
Dez!
Posts: 368
Joined: Sun Apr 08, 2018 1:09 am
Location: Ekaterinburg
Contact:

Re: Cycle X (and OpenCL)

Post by Dez! »

pepe wrote: Fri Dec 24, 2021 12:35 am The way I see it, the quality of Luxcorerender renderings are very high and the engine features are very good, but to sustain that is very hard. Can some of the code be dropped to be easier to maintain it? I am thinking something like Corona render.
I think that's what the developers are doing right now. This is the reason for the lull in development. These are my thoughts, and they come from posts here on the forum about getting rid of OpenCl.
These are not facts, these are my hopes and guesses
Linux Plasma | Ryzen 5, 32Gb, SSD M2, GT 590 RX | BenQ 27 | Wacom One | Microsoft Ergo | Tie Guan Yin tea
http://dezigner.tilda.ws/
User avatar
Sharlybg
Donor
Donor
Posts: 3101
Joined: Mon Dec 04, 2017 10:11 pm
Location: Ivory Coast

Re: Cycle X (and OpenCL)

Post by Sharlybg »

The way I see it, the quality of Luxcorerender renderings are very high and the engine features are very good, but to sustain that is very hard.
read here for insight. In normal condition this could have been ......... hum
Dade wrote: Sun Apr 25, 2021 9:49 am
Dez! wrote: Sun Apr 25, 2021 12:58 am I didn't understand the situation. Are we in a panic?
No but there is quite big strategic decision ahead: what to do ? And how to get there ?

My current feeling is to start to make (most of) CPU code compatible with CUDA C++: you can compile the code with a normal C++ compiler for CPUs or with CUDA for CPUs and GPUs.
At that point I would have all the building blocks to write new CUDA-only render engines solving a long list of problems:

1) One single source code (no more C++ and OpenCL C code for the same stuff). The current code is expansive to maintain (i.e. it slows down the development of new feature);

2) Writing a new material in OpenCL C is currently mind bending. Writing the interpreted code is extremely hard (i.e. I'm the only one who has ever done it and it is likely to ever do). Plain C++ will solve the problem.

3) Solving #2 would finally allow me to introduce a new material system (or better to extend the current options).

4) Having all the same building blocks available both for CPUs and GPUs would allow to have the same rendering engines available for both: stuff like BiDir on GPUs, light tracing on GPUs, etc.

5) more fine grained control of GPU memory would allow to have a scene editing on GPU as fast as CPU editing;

And more.

This is what the stinky corpse of OpenCL is costing us at the moment. The draw back is to sell our bodies and souls to NVIDIA.

Blender Foundation is effectively locking in all Blender user base with NVIDIA. Don't have any doubt: if you think to have Cycle X for AMD or Intel, you are drunk. The technical architecture of Cycle X has CUDA written all over the places. There is never going to be a fully functional Cycles X outside CUDA. The best case scenario is to have an half broken support like current Cycle OpenCL support.

Are we going to lock in all LuxCore user base with NVIDIA too ?

In the post about B-Renderon, I was talking about the final rendering time. Not about the rendering time of the view window.
I was talking about the fact that if the final rendering takes 30 minutes, 1 hour, even 8 hours - it doesn't matter if this rendering is done in the program B-Renderon. It will just switch to the next one on the list when it's ready. And this list can be added at any time without interrupting the rendering process.
In reality Lux speed is among the best.
The issue is that many people doing benchmark for example don't factor the quality.
Some engine just ignore calculation to avoide noise and loose data as a result what
become to obvious at the final output when compared with a less shortcut prone solution.

1) For interior rendering the Gi cache + the GPU speed is wonderfull (weirdlly ignore in donut Man bench : https://youtu.be/myg-VbapLno )

2) For caustic Light tracing + SDS caustic most of the time do the trick.

But has the Quote from Dade say there is marge for progression and development improvement.

But Genuilelly the community must understand to be more supportive and positive be there when the project need them more.
As artist we have big influence on people perception of the tool. Use this power more often for the good. Look how quiet the forum
is now compared to 2 years ago where we add less features ?

By the way, I learned quite successfully to move objects in the preview window when pre-rendering. I found the settings that make the preview window as responsive as possible.
That could be interesting to share in a Tutorial ;)
Support LuxCoreRender project with salts and bounties

Portfolio : https://www.behance.net/DRAVIA
User avatar
Dez!
Posts: 368
Joined: Sun Apr 08, 2018 1:09 am
Location: Ekaterinburg
Contact:

Re: Cycle X (and OpenCL)

Post by Dez! »

In reality Lux speed is among the best.
The issue is that many people doing benchmark for example don't factor the quality.
Some engine just ignore calculation to avoide noise and loose data as a result what
become to obvious at the final output when compared with a less shortcut prone solution.
wholeheartedly agree
But Genuilelly the community must understand to be more supportive and positive be there when the project need them more.
As artist we have big influence on people perception of the tool. Use this power more often for the good. Look how quiet the forum
is now compared to 2 years ago where we add less features ?
Two years ago, no one was aggressive on this forum. And the discord was not yet the main place of communication on Luxcore.
That could be interesting to share in a Tutorial
This is the maximum possible viewport speed:
максимальная скорость.png
максимальная скорость.png (10.03 KiB) Viewed 2371 times
If I don't have enough, I replace the high-polygon objects with their low-polygon proxies.

That is, for me it is not a problem to promptly reduce the number of objects and polygons by a factor of 10 or more. And then the parameter Pixel Size can be set to 1x
Linux Plasma | Ryzen 5, 32Gb, SSD M2, GT 590 RX | BenQ 27 | Wacom One | Microsoft Ergo | Tie Guan Yin tea
http://dezigner.tilda.ws/
User avatar
Sharlybg
Donor
Donor
Posts: 3101
Joined: Mon Dec 04, 2017 10:11 pm
Location: Ivory Coast

Re: Cycle X (and OpenCL)

Post by Sharlybg »

Two years ago, no one was aggressive on this forum. And the discord was not yet the main place of communication on Luxcore.
This discord server is 99% about people talking offtopic. there is barelly any art there and it isn't representative of what the community was.
Most of them barelly do actual Luxcore project. There are even misinformation runing there about the engine and other things. All the time it is arguing. If there is any positivity there it as been completly overshadow by the negativity.
The discord is a trash we must simply cut that is the reality.
Support LuxCoreRender project with salts and bounties

Portfolio : https://www.behance.net/DRAVIA
User avatar
TAO
Developer
Developer
Posts: 851
Joined: Sun Mar 24, 2019 4:49 pm
Location: France
Contact:

Re: Cycle X (and OpenCL)

Post by TAO »

Dez! wrote: Fri Dec 24, 2021 9:09 am
In reality Lux speed is among the best.
The issue is that many people doing benchmark for example don't factor the quality.
Some engine just ignore calculation to avoide noise and loose data as a result what
become to obvious at the final output when compared with a less shortcut prone solution.
wholeheartedly agree
But Genuilelly the community must understand to be more supportive and positive be there when the project need them more.
As artist we have big influence on people perception of the tool. Use this power more often for the good. Look how quiet the forum
is now compared to 2 years ago where we add less features ?
Two years ago, no one was aggressive on this forum. And the discord was not yet the main place of communication on Luxcore.
That could be interesting to share in a Tutorial
This is the maximum possible viewport speed:
максимальная скорость.png

If I don't have enough, I replace the high-polygon objects with their low-polygon proxies.

That is, for me it is not a problem to promptly reduce the number of objects and polygons by a factor of 10 or more. And then the parameter Pixel Size can be set to 1x
I notice most other renderers use only CPU with small sample and tessellation for viewport interactive render and it is effective. i tried it and add it with a few other tricks like upscaling the few first steps and it is really fast in my test for 3dsmax. a few demos will be released very soon.
JulianoLisboa
Posts: 146
Joined: Sat Feb 22, 2020 3:29 am

Re: Cycle X (and OpenCL)

Post by JulianoLisboa »

Hi dear friends, I owe a formal apology to Dade and all the other developers and also to Sharlybg. I may have been rude in my remarks. Honestly, it wasn't my intention.
I'm going to tell you a little bit of my story so that you understand the context of my observations.
I'm Brazilian and I've worked with 3d for over 20 years, I'm from 3ds Max and Mental Ray times (yes I used pirate) and I didn't mind making materials and lighting without having any idea of ​​what would result, after 40 minutes of rendering the The result was not good and I would do it all over again. With the end of Mental Ray, I used Fstorm for a while, until it burned my graphics card rendering. I switched to Corona and even though it was CPU only I was very happy.
At the end of 2019 I decided to study Blender because it was free and quit piracy, abandoning 3ds Max. I used cycles for some time, but I felt that something was missing, it was then researching that I discovered Luxcore, it was passion at first sight. But I always felt guilty about not being able to help financially. Remembering that I live in Brazil and if I charge a product rendering more than 50 dollars I am called a thief, so living in 3d here is not easy. So my alternative to help Luxcore was to be an evangelist, I don't have the gift of making tutorials like Sharlybg, but I'm very active in 3d forums and social media communities here in Brazil, always defending Luxcore. I'm even considered boring because I fight with people, defending this wonderful renderer. But the Blender community, unlike the others, is a fanboy of cycles, on Max I didn't see it, because most of them never used the program's default renderer. So there was no such fight and everyone wore what they wanted. But with Blender it's different, cycles is like the soul of the program and if you say that there is something different and better you are considered a heretic.

Well, because of these fights I have with Cycles users, I sometimes charge developers wrongly, mainly because I want Luxcore to be much better known and used. Sorry if I punctuate the wrong way, I didn't mean to. Sometimes I joke with my friends if I won the lottery, I would donate 1 million dollars to Luxcore so that it could develop to the point of leaving Cycles humbled, both in terms of the quality it already has and its speed. Maybe I can do it one day.

At the moment what I can do is continue evangelizing Luxcore, I can also help in some way as I am a trained designer, maybe my biggest limitation is not being fluent in English, but I am willing to help in some way. In the future I want to help financially.

Once again I'm sorry, I just want the best renderer to be relevant in the market.

Long live Luxcore.

Thanks.

Juliano Lisboa
Post Reply