“overrides from partitions had biggest performance gain so far”. ok, so if you put all objects in a partition and put a default phong material on the partition (rendering everything as grey phong, no textures, no displacement...) – does it become really fast (or normal speed)?
there are different ways to use overrides on partitions, and they have some caveats/consequences. if you add an override material on a partition, you are replacing the material/s of the object/s completely with this material. it comes at very little performance cost – use at will, but keep in mind that if objects have displacement for instance you are loosing that too. if you put an override on say the surface port, and plug something in there, something quite different is going on – if you look at the material, you will see that a new branch replaces what was in the surface port, while keeping everything on all other ports. (great, you get to keep the displacement and so). But this has some important consequences for performance. The way this is handled is that for every affected material, a duplicate is made, which is modified. (you can see this in the explorer if you look at the material libraries). if there is one object in the partition it hardly matters. If you have thousands of objects though, each with their own material, this can seriously slow down scene interaction and rendering. And you can do more than one thing in an override: override various ports on various shaders, override parameters, add properties, all at the same time – which complicates things even more. I’ve seen production scenes increase up to 30 fold in size when breaking out passes - switching passes in the interface would take up to 30 minutes! It was faster just to kill the scene, edit the TOC to switch to another pass and reopen the scene – which in itself was fairly slow as well. We spent some time on the rendering pipeline to do things another way, and avoid some of the pitfalls of overrides – and it made a huge difference in performance as well as the daily life of the artists. If your scene is really pushing the hardware’s capabilities as it is, and you add fancy overrides – you can make the scene unmanageable. Without going in too much detail – if you can nail it down to the overrides being the cause for slowdown – perhaps you can approach them differently, and get the result you’re after, with less of a performance hit. Now I come to think of it – there are different ways to render passes. One way is to render one pass completely, then switch to the next pass and so on. Another is to render the one frame for all passes, then the next frame for all passes and so on. This approach can be very ineffective and cause considerable slowdown or become unstable with complex scenes and overrides. Say it takes a minute to switch passes, and you have ten of them. If you render with skip frames that way, it would take 10 minutes per frame, to render nothing at all - and many machines on the farm could be doing it at the same time. A render manager should avoid all of this, by telling the machines which frames to render - so they don’t need to verify it themselves using skip frames – as well as avoiding switching passes – for instance by sending each pass as a separate job – and giving priority to the machine/s already working on a certain pass, to continue on it. From: Ales Dlabac Sent: Thursday, March 26, 2015 9:16 AM To: softimage Subject: Re: Fwd: very slow skip frame Yes you are right with difference between viewport skip and render skip what we are dealing with is the rendering skip. it's is happening on renderfarm and as well as in local GUI session. There's no simulation just non simulated ice tree, our findings so far showing us that if we delete part of the scene objects than it will gain some speed back but doesn't matter which part. In other words there isn't particular object which is causing the slowdown only amount of objects. We are using Arnold and we tried to replace some geometry with ass standins, this helped a little. We also suspected udims textures from confusing XSI as not existing texture paths but with no luck. Regarding network traffic overload even if we removed all external resources like textures from scene it didn't help. Removing overrides from partitions had biggest performance gain so far. We keep searching. On Wed, Mar 25, 2015 at 1:37 PM, <pete...@skynet.be> wrote: just a few stabs in the dark: is this on renderfarm / using a rendermanager? is there any simulations (not just ice, also syflex...) ? if so, any chance that the caches aren’t working and it’s simulating – on each machine? lot’s of huge textures or other data from a shared server that isn’t up to the task? how is the pre-render time? there is a big difference between skipping frames in the viewport and skipping frames while rendering – which is: rendering. so any render related slowness could be misinterpreted as frame skipping slowness? when rendering with skip frames, machines have to verify if each frame exists, or at least the placeholder 10kb file – normally that’s not a big deal but with heavy load on server (many people doing 3d, compositing, with textures and caches on the same server) things that are usually fast can become a hindrance – such as finding a 10kb file while someone else is copypasting 2TB of data. a rendermanager on a separate server than the fileserver(s) can help in distributing the rendertasks without needing to verify if data exists on the server ... From: Ales Dlabac Sent: Wednesday, March 25, 2015 11:11 AM To: softimage Subject: Fwd: very slow skip frame Hi, we are experiencing huge slowdown when we have active frame skip in render pass. Normally in simple scene frame skip occurs immediately but for unknown reason our specific scenes takes up to10mins to skip one existing frame. If you play the scene frame changes almost immediately, there is not any slow cache reading or similar thing. Have anybody idea what it can be? Thank you. AD
