[Bf-python] Problems

[Willian Padovani Germano]

On Sun, 2003-07-27 at 23:26, Jacques Guignot wrote:
> About python integration in blender.
> 
> 1) A forum has been created by Ton about yafray integration in
blender.

As I told you, I followed the discussions on that forum, though I
haven't visited it more recently.  Indeed Nishin's work seems well done
and if Blender goes for a as tight as possible integration with yafray
(sort of supporting it as Blender's default renderer), then that might
be the choice.

The cons I see to a C solution:

1) Yafray and Blender are separate projects.  There can be a lag of more
than a month between a new version of yafray and Blender's response to
it.  Even if the tightest integration is chosen and we launch new
Blender versions everytime yafray changes (ugh!), that's yet another big
download for the user.  OTOH, a Python script is a small download,
doesn't require a new Blender executable and can be updated faster and
without touching Blender's cvs source (so no problem with cvs freezes,
merging when more than one developer changed the same file, etc).

2) C code is not as easy to write and maintain as Python code.  Besides,
the proposed solution (C) is not modular (it's like "if (blender
renderer) do this; if (yafray) do that; -- which would be expanded like
-- if (povray) do ...; if (renderman) ...; etc).  Not good at all,
Blender code is already huge enough and modularity is a design wish for
the future.

We have to remember why scripting exists in Blender.  It's there exactly
to extend the program functionality.  Unless export script writers try
the Python way and we find out that something is really needed that we
can't code in the Python API, then I can think of *no* reason not to
prefer scripts.

That's how I see the forum discussion: let's wait for the new Yable, see
what it can do, help add what it needs.  If we get stuck, then there's
the C solution.

I mention yafray because that's what is discussed there and it was
decided that Blender would get better support for it.  But of course
this goes for any exporter.

> 2) blender/python integration.

> I propose this solution : (many ideas are borrowed to IanWill)
>     a) create a directory where these scripts should be placed,
allowing 
> blender to explore this directory.
>     b) add an entry "python" in the menu. (see screenshot)
> This entry will propose
>        1) the files in the a) directory
>        2) "OTHER"

Good idea this "OTHER" entry, Jacques : ).  But for the rest of the
menu, it'll probably be better (actually we'll discuss all this in the
other mailing list) to have submenus for exporters, importers, etc.  But
don't worry, your implementation is a showcase, the details depend on
feedback.

> Persistent variables : may be important. For instance, when launching
a 
> renderer, users may want to keep the values of the parameters.
> It would be fairly easy to give access to a global array of some 
> hundredths bytes (should be enough). Specially crafted scripts could 
> access this variable, whose value should be saved by blender, allowing
> the script to retreive values between two different sessions. Not 
> implemented yet.
> The problem is that if an user launches AAA script, closes blender,
then 
> launches BBB script, the BBB script will have strange values... But it
> is under the user's responsability. If he is warned, it is HIS
problem, 
> not our!

This is the third email (of those I said I'd send) I ended up not
writing ...

I guess there's a much easier way to solve this.  Ideally, as the NaN
programmer(s) commented, scripts should take care of cleaning the global
dict at the end of their execution, but this is not an ideal world ; ). 
So a good solution could be this:

Instead of what's default now, we should keep the global dict between
script runs.  But we, in C, will clean it of all unneeded stuff when the
script finishes.  We'll just keep there the basic data of newly created 
dicts plus a ** "special dictionary" **.

Let's say this dict is called _BlenderDict (or whatever, haven't found a
good name yet ...).  If script writers want to preserve a few variables,
like button state, dir locations, names and other options, they add a
dict to the _BlenderDict dict, related to their script, containing their
persistent data. Ex:

Script MyScript needs to keep a few button states and the path to the
export dir.  The script creates a "MyScript" key in the _BlenderDict
dict:

_BlenderDict['MyScript'] = {'exportMats':1, 'exportLights':0,
'exportTextures':1, 'path': '/path/to/export/dir/'}

When the script finishes, it saves this "persistent" data there.  AND
when it starts, it checks if there's an entry for it in the _BlenderDict
(it checks for 'MyScript' key there) -- if available, it gets the data
from there, if not, it uses its own defaults.

This is for persistence during a Blender session, but we can later
extend it: save the _BlenderDict so that Blender can restore that when
it gets executed again.  Scripts could also save their entries using not
only their name, but also version, in case of incompatibilities in the
new one:  _BlenderDict['MyScript1a'].

With things like this we end up creating a basic interface for Python
scripts (aka behaviors most or all scripts will contain).  Not good, not
bad -- probably necessary.

--
Willian, wgermano at ig.com.br