Rendered View starts incredibly slow

Hey, Juan.

Thanks for your elaborate answer. I’m aware of all that and you’re mostly correct. One thing that you’re wrong about is, that I don’t have to pay for getting a faster performance out of Cycles at this point. But I already bought a monthly subscription of E-Cycles that I will use for now.

I don’t understand :slight_smile:

That is exactly what I said, that you don’t have to pay for getting a faster performance, why do you think I’m wrong?

I tried to say exactly that, you don’t have to.


1 Like

Yes that’s what you said and what I don’t agree with. I’m not a programmer and can’t even compile Blender builds. So I have to choose to pay.

I’m sure the developers are aware of all these things. Whether it’s the Scrambling Distance issue, Dithered Sobol, OIDN and E-Cycles. They have been discused in several places now. But we are diverging from the original topic at this point and better leave it at that. Let’s hope this bug gets some attention. I think it’s a pretty important thing that is used quite often.

But as I said you have builds with Scramble Distance, Dithered Sobol, Embree and Intel Denoiser In Graphicall, I myself have uploaded it there.

Now If BliBluBli is doing something that he has not published yet, no one can upload a build with that feature, that is for sure, but it’s not a matter of devs doing it or not, they are BliBluBli developments, so until he publish them nothing can be done :slight_smile:

1 Like

I know. I am aware of that and I have tested the GraphicAll build. I also commented in the forum about it.

1 Like

Ok :slight_smile:

Just wanted to clarify that :slight_smile:

Aaaah!! You were the one with problems with the 770, I have no card to test that, we had no problems but our cards are newer, and the same in Theory so nothing we can do, probably a bug present in the code used as base code for the build, and probably already fixed in master and 2.7 branches.

I’ll try to make a new build with all that, but updated for today’s code :slight_smile:


That’s correct. No need to hurry for me though. My best bet at the moment is E-Cycles. I assume that the GraphicAll build cannot reach its level of performance.

In fact it can, as far as I know everything inside E-Cycles is inside that build, there may be some thing that it’s not, I would like to know what if that is the case.

I have the BliBluBli course, so I think I have E-Cycles, I’ll check it if I can.


1 Like

Although Mathieu might not be too happy about it, it would be interesting to compare them both.

I will not share anything of the BliBluBli code in case I have access to it (I don’t know if it’s in the course or not), I respect what he is doing, and in the end his findings will be available for anyone as patches that could be reviewed by the core devs.

And I don’t think he will care about testing E-Cycles vs any other custom made build or the release, because the thing behind E-Cycles is that he is continuously working on different improvements and researching different things, is not the E-cycles build what people is paying for, is his time working in those features that will be published as patches :slight_smile:


1 Like

Regarding this report:
Doesn’t instancing effectively not working with Cycles at the moment deserve higher priority than medium? It’s a complete deal breaker for pretty much any degree of a serious production work.


Yes, totally agree.
What I don’t know if it’s performance would be the same as Collection Instance.

1 Like

yes ! as i say, from 18gb to 3gb for my forest scene, this is insane !

Even if it was, creating one collection per each object you need to instance would be such a bad workflow it would not even be a feasible workaround.

1 Like

The Group Pro addon works very well for that actually.

Think about it like creating a proxy file (like with the Vray proxy or MR Proxy, Corona didn’t use a specific proxy file, right? I don’t remember)

EDIT: I’ll answer myself, yes, Corona also has an specific proxy file format.

Proxies are intended to improve performance by displaying only a “proxy” of the rendered object. A simplified viewport representation. Collection instance is nothing like that. It has all the drawbacks of proxy with no benefits of it. You are making no sense here.

Let’s see, as I see it a Proxy (as understood in Vray, mentalRay or Corona) has two objectives:

1.- Optimize viewport speed
2.- reduce memory footprint at render time

With instanced collections or dupligroups you achieve two things:

1.- Optimize viewport speed (even if you don’t enable the bounds mode in the viewport, but maybe you don’t optimize as much as with the “point cloud” in vray or mr proxy)

2.- reduce memory footprint at render time

Now, the main difference I see between instanced collections (or dupligroups in 2.7x) and proxys is that proxys used to be created in a external file with a specific file format, but regardign dupligroups or instanced collections, this exact behaviour can be done linking a instanced collection from a external .blend.

So I don’t understand why you say that what I said makes no sense.


Because unless you enable the bounds mode, the performance benefit is negligible. You can enable bounds mode also on mesh without being an instanced collection, so it changes nothing. The collection creation still remains one excessive step. There’s almost no gain. Proxies, as seen in Vray or Corona will actually generate lightweight representation for the viewport, so they can be unloaded from viewport memory.

It’s mainly unacceptable because I can’t imagine a scene where I need to instance 30 different objects, having my outliner cluttered with 30 redundant collections. That would defeat the point of collection outliner as being a scene management tool - to manage your scene and keep it clean.

Instancing, in any software, should never be conditioned by having to make any kind of group of it first. The fact that instancing in Blender currently doesn’t work without dupligroups is a bug. Don’t try to turn it into a feature.