0
$\begingroup$

Eevee compile times can get extremely long if you have multiple complex materials, such as procedural textures. I've had files with over 5 minute compile times. Cycles appears to have 0 compile time even on huge scenes. Both are using the GPU. I know these engines are different types (Cycles being a pathtracer), but what is the difference that causes this?

$\endgroup$
3
  • $\begingroup$ In my case it is because the version of compute I am using is new enough for the one, but not the other. Blender updates to take advantage of new hardware features, which is why sometimes computer works on older versions but not newer versions. Cycles is far more woven into hardware because it has been around longer, so it is to be expected that it would perform better. $\endgroup$ Sep 9 at 18:55
  • $\begingroup$ Cycles has been around much longer than Eevee, so most of the material nodes are set to function with Cycles. It's possible that the GPU doesn't like the specific material setup being used with Eevee. $\endgroup$
    – Ethan
    Sep 9 at 23:11
  • $\begingroup$ I know its an engine difference. Eevee and game engines do an upfront compile. Cycles and other path/raytracers don't. But I don't get how they are getting the material info onto the GPU if they aren't. Or if there's some way to do it fast, why aren't Eevee/game engines doing that too. $\endgroup$
    – Ascalon
    Sep 10 at 18:09

1 Answer 1

3
$\begingroup$

As far as I understand it (and I could be wrong):

Ray tracing engines like Cycles compute shaders on the fly as they are needed during ray tracing. The time spend by the engine precomputing stuff is more in the realms of scene analyzing (like BHV building) and optimizing ray tracing algorithms, which aren't shader precomputing.

Rasterized engines like Eevee precompute shaders and other data, compiling them to low level code and formats faster to execute by the GPU (GLSL for Eevee), optimizing (like eliminating dead code, folding constants, ...), and maybe other things. But at the cost of accuracy and overhead performance, static effects (reflection probes, shadow maps, baked global illumination, ...) and lots of manual work to do in order to set these up in a way that looks good.

Overall, the differences in approaches come from differences of needs. One prioritize accuracy over render time, another prioritize render time over everything.

$\endgroup$
2
  • $\begingroup$ That's my general impression too. But I'm looking at cases where Cycles will build a BVH in a couple seconds, then render several hundred samples up to full quality in 10-20 seconds (I have a fast GPU and this is a low geo scene but with high material complexity). The same scene in Eevee has a 3+ minute compile time! So even if Cycles is doing the compiling as it goes, its still doing it so much faster. $\endgroup$
    – Ascalon
    Sep 12 at 17:33
  • $\begingroup$ Well, yes depending on your hardware and the scene, that can happen. On a complex scene where it takes hours for a small fHD frame on Cycles you could make several frames with Eevee. $\endgroup$
    – L0Lock
    Sep 12 at 18:12

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .