I could live with it, if the first frame had a slow bvh build time and all other frames of an animation was fast. As it is now it’s takes the same amount of time for every frame.
In the viewport with eevee it usually is one slow frame for everything to build up then it goes super fast after that. Why can’t final render work the same?
Maybe BVH isn’t the only way to do whatever it does. Maybe there are other methods worth consideration by the devs.
Yeah bvh build time takes a lot of ram and takes long long especially with microdisplacement It would be great if this could be optimized.
The sad part is that it already works great in the viewport because it’s cached. I am pissed because I really don’t understand why they won’t make it for the final render. Give us a switch to have the FAST viewport BVH like in 2.65. Arrrgh…
We need the VIEWPORT BVH CACHE!
Even if it has sometimes issues, MOST times it works.
How many times did i read in the forums that people capture the viewport preview just to be fast. This is crazy.
And no, the 2.92 multithreated BVH is not the solution, it’s still slow, especially at complex scenes. We need a cache, it’s instant. This is the way to go, Octane and most renderers do GPU caching.
3 Likes
Because some data (objects, meshes, etc.) cannot be persistent during final render because of how Blender works, so we have to destroy the previous data and recreate everything. We just need a nice way to identify which Blender object corresponds to which Cycles object during final render.
1 Like
Man oh man @KWD , if only someone was working on such performance optimizations right now. 
@enilnacs I think you’ll find the link relevant to your concerns.
As a post 2.79 blender user i dont remember the good ol days but i have some optimization tricks that I use but im not into archviz. If someone can throw me a 2.9 compatible .blend id like to see if i have the same issues. I have used c4d amd 3ds max in the past and render times are still workfloe and optimization dependent
Bvh / build times on Blender are slow - and this is particularly noticible in eevee - for this reason I try to use viewport render on eevee - which means no compositing, but often looks good enough.
I can’t share my blends that are bound to customer privacy. Could you share your tricks?
Well, that’s exactly the point of a cache. That is why in other renderers you can say which objects can be updated and which not. Because in most of the cases only the hero meshes update, and a lot of background meshes, etc are totally static. Those don’t need to be re-uploaded, it’s a total waste of bandwidth, time and power. The multi-threaded syncing doesn’t solve the fact that it still does everything again. A cache is a no-brainer.
Ok, I see it’s in the works, lets hope things get good soon.
As I said in my previous comment, there is no way to identify which Blender object corresponds to which Cycles object during final render due to how Blender works in this case, so the “cache” is useless.
Not sure if you refer to my patch or the one that got committed a few weeks ago, but my work is for real-time playback in the viewport. However, it will apply to final renders one there is a way to know what is what between Blender and Cycles.
Not really, you need to know when to invalidate. Also you need to know what’s in it and to whom it belongs.
Of course you can do that, the patch i was talking about does exactly that. You just flag the objects and read out those flags in gpu memory before syncing. Octane does this since eternity.
I understand what you’re saying, that once the BVH is built you need to destroy it. What Octane does for ex, is building a separate BVH layer for the static objects and one for the dynamic ones combining the renderings. As far as I understand.
Go to this link above.
The same can be said about the blender dynamic viewport BVH, it can update in realtime, so why not use that ? This bugs me the most, cause there is near zero development time to allow us to us it.
Couldn’t you make a patch that allows us to use it ? Just a simple button in performance saying: Dynamic Viewport BVH, pleaaaase. 
2 Likes
Some times ago in the 2.7x era, there was a patch by @lukasstockner97 that made just that: no bvh recalculations if only camera was moving. Iirc he said that the implementation was hacky and just inacceptable for regular codebase. But he also said (still iirc) that this was due to the old depsgraph design.
Then years passed and the depsgraph was rewritten by Dr. Sharabin with (I guess) the aim to make it future proof, more efficient, more robust and less prone to errors. So? Are we still to the point that a feature like this is not implementable due to the core design? The changes made, the new depsgraph still don’t allow this??
2 Likes
I actually looked at this patch a few weeks ago for my project, as I am making update between frames faster in the viewport, it would be nice to have the same “caching” and fast animation updates in final render. (According to my benchmarks I can get a ~3x speedup when updating a file with lots of animated objects, and ~15x for mostly static scenes) I cannot answer the part about the new dependency graph as I don’t remember how the old one behaves (last time I was really active in Blender development was 4 years ago).
The problem I faced when updating the patch is that in final renders the dependency graph gives us brand new objects whose pointers are different than the ones from the original (in viewport renders we get the same pointers across frames). We use the pointers in the Blender Cycles exporter to map between Blender and Cycles objects. I tried using the simple UUID system that Blender has to recognize which new object corresponds to which old one, but it was tricky to carry this information through the graph because of the copy on write system which I am not too familiar with. Then from comments in the Cycles code, it would appear that some operations are tricky because of the new system, but as I said, I am not too familiar with the differences between the old system and the new one.
However, I would like this week to revisit persistent data for final renders, at least for the Alembic procedural I am working on for Cycles. Then perhaps the Facebook folks (the sponsor for my project) will be happier, as currently they have to take screenshots of the viewport for speeding up animation rendering…
I am pretty sure you do not understand what I am saying. Maybe I am not expressing myself clearly. The problem is not Cycles, nothing prevents Cycles to have a fast BVH update (or no update at all) for final renders, if we know which Blender object is which Cycles object for final renders. The problem is called Blender. You could implement Cycles as a render engine for a different DCC and get faster updates in final renders no problem, provided that you can map the DCCs objects to the Cycles objects consistently.
Right now, even if we made data persistent for final renders, we would still free the BVHs and other device arrays, as the Blender exporter simply does not recognize the objects from frame to frame, or between renders when editing the scene, and tells Cycles to free them (I explained part of the reason above). We have to have a way to know which Blender object is which Cycles object when making final renders. If it were that simple, it would have been done by now.
Then as for dynamic BVHs in final renders, it is already the case for OptiX (with the difference that BVHs are compressed for final renders, so that may take a little bit of time but not too much). Other BVH types do not support this because it makes rendering slower. It could be added but it still won’t help, because we can’t yet know which Blender object is which Cycles object during final renders !
3 Likes
And what if (as octane suggestes) two bvh are build, one static and one dynamic, and then merged? So no matter anymore what blender object is what object in cycles. There would be only one bvh to update and merge for each frame. It’s on Blender’s side the decision of what objects fit in one bvh or the othre.
In most scenarios this would give speedups, up to the max in scenes where only the camera is moving.
We already have separate BVHs for the geometries and the scene. The geometries can have a separate BVH in some cases (if the matrix was applied (almost always the case in viewport rendering), or if using SSS, or if using OptiX). Then the BVHs from the geometries are merged with the scene one. The ones for the geometries are dynamic, the scene one is static. So when updating in the viewport, we are only concerned with updating individual BVHs if the underlying geometry changes. But again if the Cycles geometry is deleted because we don’t know to which Blender objects it belongs, its BVH is gone and we have to create a new one.
Really the issue is the dependency graph and the Blender exporter. If you look at Lukas’ patch, it is mostly modifying Blender and the scene exporter, there is no change in the BVH code.
2 Likes
will the USD implementation of Amd will help in this case ?
and how the other render engine like octane and redshift are doing it in blender right now ?
You can see an updated verison of that patch in E-Cycles
2 Likes
Thank you for clarifying it. But I still have some questions.
- If E Cycles is implementing it successfully, why can’t we have it in master ?
- If Octane can do it, did they program additional logic into Blender ?
- If we can combine separate BVH Octane-style, then is it too complicated to make those mesh switches available per mesh, and how different is it from Lucas patch ?
Thank you again a lot for your really good explanations, i appreciate it.
1 Like
The current E-Cycles implementation is very helpful for fly-through animations. However, what @KWD is developing should help in nearly every animation by smartly updating the bare minimum, cutting export time by a good factor. As a human being, I also appreciate him and I’m happy he got a good funding to work on Blender again 
6 Likes
… OR you can buy a monitor with 4K resolution and screencapture the monitor every time 
btw I found this thread because it’s a serious issue that is causing me pain too.