[Bf-committers] Replicable Crash in 2.34 with Yafray plugin, and suggestions

Charles Wardlaw bf-committers@blender.org
Sun, 8 Aug 2004 03:37:25 -0700 (PDT)

I've never worked with programs / processes calling other processes... 
One of the reasons I like the new yafray plugin is that it mostly
negates those kind of issues.  Off the top of my head I can't
conceptualize any sort of system in which two programs would work in
tandem in the manner you've described without creating some sort of hub
or server.  IE, blender would open a port locally and spawned renderers
would talk to blender through the server interface, passing messages
back and forth, and rendering the next chunk only after receiving
conformation from blender.  Something similar was done in Lightwave 7
(although I don't know if they used actual networking or not) with the
Hub application, which allowed people to pass data more "conveniently"
between Modeler and Layout.  (In my experience, though, it caused more
issues than it solved.)

As far as doing something like this internally would go, one could
simply wrap the stdout prints in a function or macro which prints both
to stdout and to the "console" at the same time.  I don't know how much
the yafray plugin is able to communicate with blender, but I would
assume there is some memory accessible to both programs in which
messages could be stored.  As well, since the in-blender console would
disappear on program crash, having the system do dual prints would
allow debuggers to go back to their terminal window.

- Charles

> I really like the suggestion of some kind of functionality to allow 
> generic feedback from external renderers.  While working on the 
> RenderMan export for Tuhopuu, I had begun to work on a system to
> parse 
> progress strings from Aqsis and display those results in Blender,
> with 
> the additional aim of catching ESC key-presses from Blender and
> killing 
> the renderer process when they were received.  This would have
> allowed 
> Blender to remain "alive" to some extent while the renderer is at
> work.
> While I think you're correct that this is fairly simple conceptually,
> I 
> found it was quite difficult to sort out all the details and so 
> abandoned the idea for more pressing issues.  What we need is someone
> familiar with the correct way of launching a process which can run in
> parallel with Blender (across platforms mind you!) and reading back
> the 
> output from that process.  The inter-process communication must all 
> happen in parallel with the normal event loop so that the Blender 
> display remains live.  I know that all sounds simple, but in my brief
> experience it was a nasty mess!