[Bf-committers] Trying again for detailed rendering progress...

Early Ehlinger early at respower.com
Wed Sep 13 06:27:15 CEST 2006

So my first patch was rejected :-(

I'm not the type to give up though, so I've looked at Ton's comments and 
I've started developing a revised version of the patch that's a little 
more useful (I hope).

Some quick background...

I'm the president over at ResPower, and we provide rendering services 
for Blender users worldwide.  One thing we do not provide is a 
screenshot of the render in progress (with 700+ nodes, trying to capture 
that much data would overwhelm the network), so without modification to 
Blender there is no way for a user to know what stage of the render they 
are in, or if it is even doing anything.

Our current solution is to take each new release and instrument it using 
printf so that interesting portions of the render appear in the 
console.  We then capture the stdout and send it to the log.

The result ends up looking something like this:

2006-09-12 20:05:52 	source\blender\render\intern\source\pipeline.c(1121)
source\blender\render\intern\source\initrender.c(640) - nr:0
source\blender\render\intern\source\initrender.c(640) - nr:1
source\blender\render\intern\source\initrender.c(640) - nr:2
source\blender\render\intern\source\initrender.c(640) - nr:3
source\blender\render\intern\source\initrender.c(640) - nr:4
source\blender\render\intern\source\initrender.c(640) - nr:5
source\blender\render\intern\source\initrender.c(640) - nr:6
source\blender\render\intern\source\initrender.c(640) - nr:7
source\blender\render\intern\source\initrender.c(640) - nr:8
source\blender\render\intern\source\initrender.c(640) - nr:9
source\blender\render\intern\source\initrender.c(640) - nr:10
source\blender\render\intern\source\initrender.c(640) - nr:11
source\blender\render\intern\source\initrender.c(640) - nr:12
source\blender\render\intern\source\initrender.c(640) - nr:13
source\blender\render\intern\source\initrender.c(640) - nr:14
source\blender\render\intern\source\initrender.c(640) - nr:15
source\blender\render\intern\source\pipeline.c(911) Rendering Tile 
source\blender\render\intern\source\rendercore.c(3183) Rendering layer 1
source\blender\render\intern\source\pipeline.c(911) Rendering Tile 
source\blender\render\intern\source\rendercore.c(3183) Rendering layer 1
source\blender\render\intern\source\pipeline.c(911) Rendering Tile 
source\blender\render\intern\source\rendercore.c(3183) Rendering layer 1

This information is admittedly not very meaningful to a typical user; 
however, it doesn't have to be in order to get the point across to the 
user that Blender isn't hung; it's just working.  For our part, it's 
helpful when something /does/ go wrong to know what the last thing 
Blender successfully accomplished was.

There are two drawbacks to our current printf-based instrumentation:

    * If you /have/ access to the GUI, you don't need it and it is
      actually quite annoying when you're trying to see printouts for
      stuff that you care about.
    * Every time a new version of Blender comes out, we have to
      re-instrument and compile the source.  In essence, we do not
      support Blender per se, but a fork of Blender that is
      file-compatible.  This is way less than ideal, because it means
      that we could screw up the build process and end up with a
      semi-compatible Blender. 
    * It also has the problem that in order for us to support a new
      version, we have to download the sources and build from them,
      which means it takes longer than simply downloading the official

Ton suggested a callback based approach, so this morning I set out to 
implement such a beast.  I hope I understood what he meant correctly.

We've replaced our printf-based instrumentation with a new mechanism 
that allows you to register a Python function that will receive callback 
messages when Blender encounters an instrumented portion of code.  Our 
instrumentation focuses on rendering progress, but Blender can of course 
be further instrumented using a simple function call, Blender_Trace, 
which has this signature:

    void Blender_Trace( const char* sFile , int nLine, const char* 
sFormat , ... )
    /* It uses vsnprintf to convert sFormat and the ... parameters into 
        then passes sFile, nLine, sMessage to the Python callback 
registered using
       Blender.Set( "traceCallback" , fn ); */

For example, one could instrument the fluidsim code and run a Blender 
script without the GUI to bake some fluid dynamics, or instrument the 
compositing code and use Blender as a background compositing application 
with the GUI disabled.

A Python script using my new patch looks something like this (actually, 
it looks /exactly/ like this, because this is my test script):

    def rpBlenderCallback( sFile , nLine , sMessage ):
        if ( sMessage == "#" ):
            print sMessage ,
            print "\n[RPBC]" , sFile , "(" , nLine , ") - " , sMessage;

    import Blender

    Blender.Set( "traceCallback" , rpBlenderCallback );

After running this script, you can hit F12 and see output in the console 
similar to the log I showed before.  rpBlenderCallback is called at 
various places in the renderer and all works well.  If you do not use 
Blender.Set( "traceCallback" , ... ), the rendering traces essentially 
go to /dev/null.

Are there any additional concerns or objections that I should address 
prior to submitting another patch?

-- Early Ehlinger, President, ResPower, Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://projects.blender.org/pipermail/bf-committers/attachments/20060912/53ce73d7/attachment-0001.htm

More information about the Bf-committers mailing list