PDA

View Full Version : Render profile?



regularfry
03-28-2007, 02:18 AM
When you render a frame, is there any way to get a profile of where the renderer spends its time? It'd be great to be able to know that, say, 25% of the time was spent rendering transparent polygons, of which 77% was spent on wine_glass_broken.lwo, for example.

The way I'm imagining this being used is that you'd take a profile of a low-res version of your render, and use that to optimise the scene so that when you actually hit F9 for your final render, you know it's as fast as it can be.

Bog
03-28-2007, 04:06 AM
Never heard of such a thing. You could try, though, just selecting each object in turn and whacking F11 - "Render Current Object". I know that's coarser than the "time spent on transparencies" and such, but it's a step.

Dave Jerrard
03-29-2007, 12:21 PM
When you render a frame, is there any way to get a profile of where the renderer spends its time? It'd be great to be able to know that, say, 25% of the time was spent rendering transparent polygons, of which 77% was spent on wine_glass_broken.lwo, for example.

The way I'm imagining this being used is that you'd take a profile of a low-res version of your render, and use that to optimise the scene so that when you actually hit F9 for your final render, you know it's as fast as it can be.

It's called Show Render In Progress. :hey: You watch that and you can see exactly which polygon is causing problems. This is only really effective for the Classic Camera though since it renders the scene polygon by polygon. The new cameras ray trace the scene, line by line, and thus, there is no "Rendering Transparent Polygons" phase. You can still see where the rendering slows down though.

He Who Has Used This Method To Pick Out One Single Point Polygon That Was Causing Trouble.

regularfry
04-04-2007, 06:30 AM
I guess I just think of these things like a coder - 'cos that's what I am :) I'm fairly used to being able to monitor the execution of code to see where it's spending its time. Without getting actual numbers, the temptation is to assume that one knows exactly where a slowdown is happening and work on that, rather than measuring it and knowing without a shadow of a doubt that optimisation effort is being well-spent.