I have a complete scene with a single real-time sequence shot starting from the sky, then flowing through the streets.
The whole scene has just few 4k textures and no more than 10 rigged characters, some buildings and some nodes to scatter ambient elements.
when I decided i was the right time to start giving a first run I discovered that…
once I clicked on render animation the render window didn’t even start doing anything, stayed still and then blender crasched…
I separated the scenes, keeping environmnet in one and characters in the other, and, at least it started again doing his job
BUT: each frame takes 5 minutes to INITIALIZE and then the render itself takes just few seconds!!!
do you have some suggestions about;
reduce initializing timins (even with persistent data + environment map at 512 + tiling at 256)
the correct way to separate scene elements to being then able to composite them togheter
the best way to split the workflow among scenes or even files, to have the best performances (i.e. flyover part in one file, the the first part, etc)
any hint will be much appreciated!
find enclosed the view from the very beginning, in orange I have selected the camera path and in the middle you will notice a “mass of items”, which should be a market
Looking at this picture, your scene doesn’t look very heavy, I can tell the buildings are not that high res (by the way, you should activate “auto smooth” on them, I can see artifacts because some buildings are shaded smooth).
Based on your description, the scene should really not be that heavy, so I don’t think splitting the scene or compositing is the problem here.
If you don’t have many textures, then the loading times must come from something else. Does the scene have lots of modifiers? Look especially for modifiers that are disabled in the viewport but will add lots of data at render time. Do you have subdivision surface modifiers? If yes, can their render level be reduced without a visual impact? Are there modifiers that take a long time to process when you activate them, like remesh, decimation, large arrays or complex geometry nodes setups?
You could try deactivating different elements of the scene to find what is causing the problems. How long is the build time with only the landscape? With only the characters?
When you say you have 10 characters, is there actually that number of characters in the entire scene, or do you have 10 rigged models that are duplicated to create a crowd? Because if you have a crowd, simply duplicating an entire character rig would be terrible for performance.
The first thing I would check is doing a render without the characters. That way you can know if the performance issues are caused more by the characters or more by the environment.
One thing that could help, if it applies to your situation:
If some of the characters share the same animation, you could put them in a collection and then create a collection instance instead of duplicating the character. That way, you can instance an animated character and have the data be stored in memory only once.
When you duplicate an object with shift+d, the new copy is considered separate and will take space in memory. However, if you use alt+d instead, you will get an instance.
Instances are objects that share the same mesh, so the data will be stored in memory only once. This saves on memory and also allows you to edit all objects at once, because any change to one model will be shared between every instanced object. You will get better performance than a duplicate, at the condition that the instance doesn’t have any modifier on it, because modifiers cause the meshes to become different and forces them to be stored separately. You will know you have made an instance successfully if you duplicate the object and the scene’s polygon count stays the same.
There is also a more advanced form of instance called a “collection instance”. These will allow entire collections to be instanced instead of single objects and they even support modifiers, animations and physics.
Collection instances can be useful for assembling large scenes. You split your scene into base sections, like you could create a collection with an entire building with all the furniture inside, then you can instance the whole building as if it was an single object and make an entire street with little memory used, because the building is store in memory only once.
gosh I totally FORGOT the ALT+D for repeated items and didn’t know about the collection istance approach.
I already started rebuilding a new scene, btw, as I am doing this job for hobby/learning/other purposes, so I want to lear at first TO DO THINGS WITH RIGHT AMOUT OF CONCENTRATION and patience
probably will look for duplicated object and will replace them with instances. TYVM.
about the chars, i have been doing some training and therefore I want them to be different as everyone have his/her own cloth set, to do some correct clothing/mixamo/basic animation…
I started a new scene from scartch.
scaled to centimeters from its orginal 1:1 scale
cleaned orphans blocks and kept anything a bit more in order.
drastically reduced the vertex count…
REDUCED the count of characters > just 5 of previous ones
it keeps crashing with NO CRASH.log output
there could be somthing related to mixamo rigged chars?
I ran blender in debug mode and there are tons of repeating warning:
don’t know whether this is an INFO or not as I cannot find anydetailed info:
I0522 09:59:37.227391 83272 device_impl.cpp:1130] Using fast to trace OptiX BVH
I0522 09:59:37.227391 77708 device_impl.cpp:715] Buffer allocate: optix temp index data, 3,240 bytes. (3.16K) in device memory
I0522 09:59:37.227391 83272 device_impl.cpp:715] Buffer allocate: optix temp as build mem, 30,088 bytes. (29.38K) in device memory
I0522 09:59:37.227391 77708 device_impl.cpp:715] Buffer allocate: optix temp vertex data, 2,192 bytes. (2.14K) in device memory
I0522 09:59:37.227391 83272 device_impl.cpp:715] Buffer allocate: optix blas, 41,984 bytes. (41.00K) in device memory
I0522 09:59:37.228387 83272 device_impl.cpp:715] Buffer allocate: optix compacted as, 16,256 bytes. (15.88K) in device memory
Invalid clnors in this fan!
or Invalid clnors in I0522 09:59:36.642953 83412 device_impl.cpp:715] Buffer allocate: __texture_info, 12,576 bytes. (12.28K) in device memory
and
the closing:
