Efficiency Render Element

[Pixelcon]

This might be a stupid or strange one but here goes...

What I think could be useful is a render element that somehow - based on a colour spectrum (like the samplerateelement) or per-bucket text - can help to diagnose where the inefficiencies lie within a rendered frame. This could help to diagnose which elements or materials within the render are being oversampled or could be further optimized. Obviously I can use the samplerateelement to diagnose some inefficiencies but not areas where I could, for example, further reduce cutoff and max reflection depth values.

So in short, a coloured map that changes depending on time spent rendering. This I suppose would be best if the upper and lower limits scale dynamically, but it might be impossible and have to be specified manually.

Thoughts?

Cheers.

[ToucanCreative]

Just did a quick search to see if I could find this in the wishlist, and cool to see others have thought about it too.

Yeah, if there was a render element that could help you identify how long each bucket took to render, that would be awesome. So you could end up with a big grid of times that you could overlay over the rendered image to identify areas of inefficiency, or as James has mentioned above, a grey scale map where buckets that took the least amount of time are black and the ones that take the most time are white.

[Joelaff]

Was thinking about this the other day. Thought it would be cool to be able to save that and then have future renders start on the slowest blocks first. This would help avoid Last Block Syndrome, where you are waiting a long time for that last block to finish in a single core.

Of course, more aggressive dynamic splitting would be even better, with a user, per-scene tunable setting for how aggressively dynamic splitting starts. Also, would be ideal to, once the number of remaining blocks is less than the number of cores, the idle cores are assigned to smaller sub blocks of the remaining blocks that have already been started. If the original core finishes the block first then the render is done. But if the two, or four, or eight, etc. other cores finish the remaing block in concert then the render is done that way.

Basically, you never have any idle cores. They are put to work on the remaining block, even if that means multiple cores are working on the same block. This only requires an extra buffer (per element as well as RGBA) the size of one block.