[Bf-committers] SystemError when using simple mesh commands in scripts started from the command line...

Campbell Barton ideasman42 at gmail.com
Tue Nov 10 12:26:42 CET 2009


there are no plans to get this working in the near term and a fair
number of missing features you could call critical.
Id not say batch processing is necessarily linked with background mode either.

For durian we need a renderfarm and a auto-rigging system, both will
use the python api so it will get some testing & development with this
for sure.

On Tue, Nov 10, 2009 at 8:39 AM, Goat Man <goatman.py at gmail.com> wrote:
> how long do we have to wait for python scripts to work again in background
> mode?  Batch processing is a critical feature for dealing with large amounts
> of data.  Blender2.4x was a little weak in this area, i'm hoping for
> something much better.
>
> On Mon, Nov 9, 2009 at 3:55 PM, Campbell Barton <ideasman42 at gmail.com>wrote:
>
>> Python can define its own context which may help to work in background
>> mode, I think this would be the script context your asking about but I
>> didn't test this yet.
>>
>> At first I tried to generate python documentation in background mode
>> but it didn't missed the python operators since they are not loaded.
>>
>> AFAIK we haven't even tried to have the python api work in background
>> mode - (speaking for myself at least)
>>
>> Unless your prepared for debugging/fixing internals Id not recommend
>> testing background mode at the moment.
>>
>> On Mon, Nov 9, 2009 at 8:11 AM, Dietrich Bollmann <diresu at web.de> wrote:
>> > Hi Martin :)
>> >
>> >>
>> > http://wiki.blender.org/index.php/BlenderDev/Blender2.5/WM_Architecture
>> >
>> > Interesting reading. Sounds much more involved than I initially
>> > thought... :)
>> >
>> > Reading this document, I have the impression that some parts are still
>> > under heavy development.  Especially the context handling looks like not
>> > being solved for the moment.  I also seem not to be the first who
>> > stumbles about the problem of scripts executed from the command line...
>> >
>> > So probably I just should stop to ask stupid questions, let you work
>> > and ... wait :)  The only thing I don't like about this option is, that
>> > everything I will create until then is already outdated...
>> >
>> > The other option - to try to hack things myself - probably makes
>> > everything only worse :)
>> >
>> > ...Of course I would be happy to ask, why you don't simply move the code
>> > for executing the command line scripts to some place after the
>> > initialization of the window manager, create some special script context
>> > and than use some "non-interactive" kind of flag to make the event
>> > handler skip the gui polling...
>> >
>> > But I am sure that you already have thought about better ways to handle
>> > this problem and are searching some more general and elegant solution :)
>> >
>> > So I'll wait...
>> >
>> > Thanks for the interesting Mails!
>> >
>> > Regards, Dietrich
>> >
>> >
>> > On Sun, 2009-11-08 at 13:16 -0800, Martin Poirier wrote:
>> >> Hi,
>> >>
>> >> --- On Sun, 11/8/09, Dietrich Bollmann <diresu at web.de> wrote:
>> >>
>> >> > So invoke would be used for functionality which for
>> >> > instance use mouse
>> >> > input to rotate some object?
>> >>
>> >> Yes. Like transform, loop cut, lasso, brush select, ...
>> >>
>> >> > And operations used in a script which does not need user
>> >> > input would
>> >> > only use exec?
>> >>
>> >> Hopefully.
>> >>
>> >> > Probably the bpy.ops.mesh.primitive_cube_add() command than
>> >> > would be of
>> >> > the second kind and not require the window context?
>> >>
>> >> It's not as clear cut as that. Some operator supply both an invoke and
>> exec function, so it has to be decided based on calling function, not
>> operator type.
>> >>
>> >> > Just by curiosity:
>> >> >
>> >> > Concerning interactive commands, why isn't it enough to
>> >> > specify the
>> >> > window(s) when registering an event handler?
>> >>
>> >> It's not so much the window that is missing but the whole windowmanager.
>> When running scripts from command line, it tries to run them before the UI
>> is fully initialized.
>> >>
>> >> > Aren't interactive commands (event handlers) reacting on
>> >> > user input
>> >> > invoked by events in the queue of the window they
>> >> > registered for?  As
>> >> > there is exactly one event queue per window the window
>> >> > should be clear,
>> >> > no?
>> >>
>> >> The window missing from context only applied to operator running from
>> the command line (or in background mode), otherwise it is not a problem.
>> >>
>> >> > Non-interactive commands on the other hand wouldn't need
>> >> > the context at
>> >> > all.  (At least if they only manipulate a scene and
>> >> > not some window
>> >> > itself.)
>> >>
>> >> Context is like a generalized dictionary. They would take the current
>> scene from the context too.
>> >>
>> >> > Are there documents which explain Blenders new event
>> >> > system?
>> >>
>> >> Some of it is on this wiki, like on this page for example:
>> >>
>> >> http://wiki.blender.org/index.php/BlenderDev/Blender2.5/WM_Architecture
>> >>
>> >> Martin
>> >>
>> >> __________________________________________________
>> >> Do You Yahoo!?
>> >> Tired of spam?  Yahoo! Mail has the best spam protection around
>> >> http://mail.yahoo.com
>> >> _______________________________________________
>> >> Bf-committers mailing list
>> >> Bf-committers at blender.org
>> >> http://lists.blender.org/mailman/listinfo/bf-committers
>> >
>> >
>> > _______________________________________________
>> > Bf-committers mailing list
>> > Bf-committers at blender.org
>> > http://lists.blender.org/mailman/listinfo/bf-committers
>> >
>>
>>
>>
>> --
>> - Campbell
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>



-- 
- Campbell


More information about the Bf-committers mailing list