I don’t know why you can’t use the built in raytracer for raytracing I currently use Cycles over Eevee because Cycles is often faster. Its not hard to make Cycles render faster than Eevee with similar levels of detail.
If its a large scene with many materials Cycles is often more interactive and faster to render than Eevee.
Using blender 2.93
Cycles X
Blender 2.93
Cycles X has so much less overhead than older Cycles its insane, I have been able to render 60 FPS out of cycles on a single computer.
Do you have some tutorials, or some hints to optimize cycles renders like you do ?
I manage to get reasonable render times and optimize a bit, but you seems to have some tricks to get way faster renders especially on heavy scenes. Is there some information, tutorials, papers, or even a book I could learn from ?
If you want to learn how to optimize cycles just take any of these addons that charge way to much and see what they do, they literally just automate 10 button clicks for you and then do multi pass denoising.
hahaha ! looking at scripts ! that’s some written information but not the way I thought
Thanks a lot for the links , I’ll take a close look at them.
I probably should go back to the basics and also try multi-pass denoising !
That shed some lights on some mysteries !
It was some pretty simple renders for a looking glass, a looking glass requires 48+ renders per frame to get a holographic view of your render, so for a 10 second animation id have to render 12,000 frames minimum.
Here is an example rendering just under 60 FPS, rendering 108 views in ~2 seconds, CLI rendering is critical for these insanely low latency renders. 4 samples and persistent data, just a super fast flat render. But magnatudes faster than I could render it out of eevee.
Yes, Unity have now as well, out of curiosity I downloaded Unity some time ago and made a very simple little game just to explore its real time raytracing, and it was extremely beautiful, and it was running very smoothly despite me not having the best card (rtx 2060).
Ever since I’ve looked forward to Eevee implementing hybrid raytracing as well, it makes such a huge difference.
None whatsoever. They reached the first milestone less than three weeks ago, and it’s not on the 3.3 board. It’s a long term project, I’d guess 3.4 at the earliest (after September this year)
There’s also a ton of open, high-priority regressions in Eevee, mostly related to GPU Subdivision. Getting GPU Subdivision working is a prerequisite for this, and that’s not even a given in 3.3
I don’t think we will be getting a 3.4 version. So I bet it will be released for 4.0, like Cycles X was in 3.0 Apparently not, I had a look at the roadmap. I thought that because the versioning changed after 2.83 and 2.93 (LTS releases)
Thanks for the correction! I remember this other horizontal roadmap that had something different (or it might be my imagination) hence why the confusion, on the other hand these roadmaps would need an update as clearly we aren’t getting 3.3 on May 2022 (because of the 3 months delay of 3.0).
Hi everyone, I would like to announce that a second milestone was reached.
We now have material nodetree support inside EEVEE-Next. There is a placeholder lighting model to be able to check how the BSDFs are mixed. Note that only the forward shading pipeline is effectively implemented.
This was merged for the 3.2 release so we can have some user testing to see if some nodetree breaks. (Edit: The experimental options are disabled in beta and release builds. Testing is to be done with the 3.3 alpha branch.)
Mesh & Curves (Hair) surface types should be supported. Vertex Displacement is also enabled by default and will become an option down the line.
Grease Pencil geometry is done but disabled for the time being until we have a per object option to select which renderer to use.
The Shader To RGBA handling was not straight forward but was effectively dealt with. It should now be supported.
Volume shaders are not yet supported.
BSDF shading makes use of the stochastic sampling of the BSDFs. So the number of BSDF should no longer make the shader linearly more expensive. Temporal accumulation is still not implemented so there can be noise left if you stack many BSDFs with very different properties.
The next step will be to implement the “Film” sub-system which is what allows temporal accumulation and renderpasses.
I currently use Cycles over Eevee because Cycles is often faster. Its not hard to make Cycles render faster than Eevee with similar levels of detail.
