Page 1 of 1

render baking efficiency on SMP machines.

Posted: Fri May 04, 2007 11:07 pm
by RipSting
I've been noticing that smaller polygons get rendered first when baking light maps. Is it just a coincidence, or is it coded that way? Wouldn't it be more efficient if larger polygons were rendered first?

Imagine there are hundreds of small polygons in an object and one very large quadrilateral. The way it is now, all 8 threads seem to render the small polygons first. Then, at the very end it will have a single thread render the large polygon while the other 7 threads are idle. Wouldn't it make more sense for one of the threads to be rendering the large polygon while the others were taking care of the smaller ones? It would simply load-balance more efficiently.

Therefore, I propose (regardless of how it may or may not be coded currently) that render baking should give polygons with the largest area first priority. In other words, the internal area of a polygon is directly proportional to the order in which it is rendered.

This could also be extended to render the most complex materials (read: time-consuming) first, perhaps based on the number of material nodes being utilized. Each material node could perhaps have a speed quotient associated with it (RGB->BW = 1.0, Curves = 1.5, Displacement Map = 5.0) to help with this type of calculation. The higher the sum of the speed quotients of all nodes, the more priority given to polygons with that associated material.

Any thoughts?

Re: render baking efficiency on SMP machines.

Posted: Mon Mar 17, 2008 3:37 am
by RipSting
I strongly believe this needs to be looked at once more. ToastBusters over at blenderartists came up with a simple load-balancing solution to tile-based rendering.

Posted: Wed Mar 19, 2008 9:28 pm
by brecht_
I don't think this would be a very important optimization, especially taking into account materials adds too much complexity for the average speed gain. The proper solution is really to make baking tile based.

Similarly for rendering doing the most complex tiles first only sidesteps the problem that the tiles should be smaller.

There's loads of opportunities for optimization in many parts of Blender, not sure why this particular one would need more attention, but well coded patches are always welcome.