Recent Cycles in 2.8: very slow init & overly large mem consumption?

Archive User Feedback
1

Hey all,

Blender 2.8 and Cycles were behaving normally with thousands of splines but something changed these last months – I don’t know when – which makes Cycles unusable.

To test that, it’s pretty simple:

  1. Take the latest beta 2.8
  2. Create roughly 10’000 splines with 10 random points each within one curve object with a script (note that you only have one curve object with many splines in it so this is usually fast)
  3. Bevel the curve object so that the splines are meshed
  4. Set render engine to Cycles and hit preview

You’re in for an extremely long and unbearable wait.
In comparison, Eevee behaves normally and is usable, just like Cycles used to be.

Does somebody (Brecht?) know about that?

2

@nantille Could you share the poly count in your scene that you tested?

3

Please report bugs in the tracker:
https://developer.blender.org/maniphest/task/edit/form/1/

4

@salaivv Here are numbers and the file with a script to generate splines as below.

4a_15k_std_cycles_render
4a_15k_std_cycles_render.jpg1920×1107 472 KB

Steps to reproduce this:

  1. Download and open b28_std_many_splines_test.blend
  2. Run the script and wait that it creates a ‘Curves’ object
  3. Select that object and go to Curve panel, set resolution to 2 and bevel depth to 1
  4. Hit viewport preview

For one curve object with bevel depth set to 1, numbers go as follow:

  • 1500 splines, 50 points each, resolution 2: ~2.5 million faces, 0.37GB in viewport & Eevee, 2.53GB in Cycles render preview
  • 15000 splines, 50 points each, resolution 2: ~20 million faces, 2.63GB in viewport & Eevee, 17.5GB in Cycles render preview

It seems that Cycles consumes roughly 6.5 times more memory for such scenes.
Now I’m troubled, I’m not sure if it was like that all along…I don’t know if it’s a bug or not.

@brecht I’ve seen many bug reports dismissed because Blender 2.8 is in beta but if you think it helps, I’ll do just that.

5

That is a LOT of polygons. Cycles will usually start to suffer when the polygons counts reach 8-10 million. That’s usual.

Init time is high since it takes quite a while to build BVH for such huge amout of geometry. Embree is on its way to Cycles. It may reduce the build times in the future.

And, the memory comsumption is also normal. All that extra memory is due to BVH. EEVEE has none of these issues, because it simply does OpenGL rasterization, hence its memory consumption is not drastically different from the viewport. And, if Vulkan makes its way into Blender, we can expect even better viewport performance.

I dont think this a bug.

6

Well…I have dealt with far more polygons than that.
Are you sure that the BVH needs that much memory?

Is it not possible to have a coarse BVH at the expense of longer render time?
There is a “BVH time steps” option now but it only makes it worse for my case at it makes subdivides the bvh, using more memory.

Thanks for your answer salaivv. If it’s not a bug then it was a good idea to ask here.

1 Like