Cycle X (and OpenCL)

Discussion related to the LuxCore functionality, implementations and API.
juangea
Donor
Donor
Posts: 332
Joined: Thu Jan 02, 2020 6:23 pm

Re: Cycle X (and OpenCL)

Post by juangea »

If you are answering me, yes, the problem is human time, not actual render time, I absolutely LOVE LuxCore final render times, the quality is astonishing and the render times are also astonishing, it's more a human time problem, something that right now it's hard to overcome I think.

Maybe in the future that can be overcome with proper Hydra delegate support in Blender/Lux, but I may be saying a total non-sense.
User avatar
chuchur
Posts: 27
Joined: Tue Sep 15, 2020 8:44 am

Re: Cycle X (and OpenCL)

Post by chuchur »

Sharlybg wrote: Thu Dec 23, 2021 9:37 pm 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
I've noticed it too. I feel like in some "real-time" renderers reprojection of samples is used. Noise patterns stay still as the user is moving a view. Also, there are a lot of "hybrid" techniques where OpenGL rendering is combined with the first bounce of simplified raytracing, and "final quality rendering" starts refining the preview after immediate input has finished for a certain time threshold.
juangea
Donor
Donor
Posts: 332
Joined: Thu Jan 02, 2020 6:23 pm

Re: Cycle X (and OpenCL)

Post by juangea »

There are several variables that come into play when we talk about human time.

- Viewport performance: yes, this is a super important one, and we have to limitations right now that seem to be very hard to overcome, GPU support, while we have it the update time is so big that it’s not worth it, and even with CPU, reaction time when moving lights, cameras, modifying materials, distribution/particle systems are quite slow compared with cycles, but it’s not a LuxCore thing, I think it’s a Blender limitation due to the Blender API, that’s why I think Hydra would be the only ultimate solution, so the integration is a proper native one.

- Available Libraries: this is another human time problem, since there is no full support for Cycles materials, it takes a lot of time to adjust and convert materials to the native LuxCore system, which is very good, and I like it a lot, but when we have to go at high speed, this is a problem because it takes a lot of time to convert every model the client wants to try, it’s a pity, but it is what it is.

Once more Hydra could be a solution, since Hydra + Matwrial-X support would give a native / uniform shading system that could work along different engines and will allow us to avoid conversions and be up to speed.

But first Blender should have native Hydra support, then we may start thinking about this as a possible solution :)
Post Reply