I’m working with a massive scene, and now I’m using a relatively reduced version to do some animation, (when I say reduced I mean 42 million polys on viewport + instances , 4240 objects, that is the super-reduced version)
Cycles viewport render is working well, now I noticed that when I enter in the viewport render for the first time it takes a while, like in the normal viewport, but when I change to a different frame it just updates part of that BVH, it does not re-create the whole thing, so it’s way faster.
Could this be enabled for final render? even as a testing thing, because if this works from frame to frame it could save us A TON of render hours, it could have some cons I can’t see, but so far even with these cons, if it works, it would help A LOT.
To compare times, in this exact case, starting the viewport render takes 1 minute 35 seconds, while changing frame takes 5 seconds.
The problem is not about viewport vs. final render BVH, it’s this patch that needs to be finished:
Oh yes, I know that.
But I was thinking of a temporary workaround under experimental, or even to have in custom builds, because it could save A LOT of time, and right now finishing that patch AFAIK it’s very hard because all the changes the Deps Graph received, so I think it will be a big time until this is finished.
So as a fast workaround, maybe not in master at all, just as a temporary patch, could be good to have the ability to enable this, I just don’t know how to do it, so if it’s too hard… it won’t be possible, but maybe it’s a matter of letting the system to choose one technique or the other.
Reading through the code it does not seem so complex in the end, I’ll try to apply it to my build manually and see if I get that to work, maybe yes, maybe not
@brecht I’m totally unable to update that patch definitely, since there is no depsgraph.c anymore, I don’t know how to deal with that part at all, I don’t have a clue of where does the id update (and I’m afraid that even if I know where does it update, I won’t be able to fully understand that), also the anim_sys.c has been changed too, so I don’t know how to deal with that.
If you can tell me where can I tell cycles to use the viewport BVH build process at render time, I’ll try to do that workaround as an option for the time being, but I’m afraid that maybe that won’t work because it may be for an ongoing, non-stop render session like the viewport, but maybe not for the frame change.
Right now all that process add around 3 to 4 minutes in our scene, you could imagine how important could be to have something like that when you have to render around 2000 frames in that scene, we are talking about 133 hours of added render time. That’s a big amount, specially when the total render time per frame is 7 to 9 minutes, so we are having near a 40% / 50% of render time spent in BVH building.
If there is a possible workaround for this, I’m interested in exploring it… a lot
There is no point in building a viewport BVH without D2613, it will not help.
Ok, then there is no solution until that patch can be updated
I hope it can be updated, at least partially, sooner than later