[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
[158,118]-[322-242]
source\blender\render\intern\source\rendercore.c(3183) Rendering layer 1
############
source\blender\render\intern\source\pipeline.c(911) Rendering Tile
[318,118]-[482-242]
source\blender\render\intern\source\rendercore.c(3183) Rendering layer 1
############
source\blender\render\intern\source\pipeline.c(911) Rendering Tile
[158,238]-[322-362]
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
build.
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
sMessage,
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 ,
else:
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