Cosmos objects used in any animation lead to excessive rendering times after few frames.

[imdb]

Seems like Cosmos textures are utilizing multi resolution files, which are related to the slow rendering bug. Not 100% sure that to be the case, so I'm posting that as a new issue.

These are the results from 20210908 build on Windows Stand Alone node. The frames are different by a slow camera move only. Seems like after initial ramp up, it maxes out at 12 minutes / frame vs an average of 1 min.

[imdb]

Attempted to use V-Ray C4D Bake on the Cosmos textures, it slowed the render down by nearly twice, then it hit the same snag of render times going out of whack. Seems like at least for now Cosmos objects are bound to stills only until this bug is fixed.

Perhaps you guys can create an option within Cosmos which produces diff resolution baked file, if that's quicker? It'll make Cosmos relevant to anyone outside of still shot production, at least until you fix that bug.

[imdb]

After some tests and letting it run, slowdown ramps up after few frames (depending on the scene & render settings), slowdown starts to show up in the following:

"Uploading texture '....'"

Where that uploading texture line was fast on previous frame, like 1 or less seconds, it begins to ramp up to 5 seconds, then 13, then 30.

If you have lower quality render, it'll take 30+ frames for this to start, if you have less noisy & higher quality render settings, the problem shows up quicker.

[imdb]

Here's another example of a Cosmos object renders on remote node slowdown


Here's the tail of the output of the log from the remote node.
log-file.txt

You can see the sudden delay increases towards the end on few items like marble texture loading into GPU and Uploading textures delays. From a quick glimpse, most of the increase is around 1 bump texture, but it's not always the case.

I can't really see from the surface what's in common other than removing all bump textures and testing.

Hopefully some of this will assist you with resolving this issue.

[imdb]

Looks like from a limited test, when I switch from Light Cache to Brute Force, it's able to continue past the frame where delay was starting. So far it's few frames past the point and there's no additional time being added.

Something to do with Light Cache.

[aleksandar.kasabov]

Hello imdb,

This seems to be related to the distributed rendering. If rendering locally, this doesn't seem to happen. However, in my tests, I also reproduced the issue with both Light Cache and Brute force for the secondary GI engine.

I reported this to our developers (bug ID: VC4D-1090) and I will let you know if we have more information. Thank you.