[Bf-python] Extending python

[Stephen Swaney]

Campbell Barton wrote:
> 
> Hi All, Matt- I like your naming convention, I dont think theres any
> resion to be Picky with this-

Actually, this is a good thing to be picky about.  Having
naming conventions helps keep things organized and makes it
easier to find stuff.  We already have naming conventions
for module and instance methods and types, for example.
 

> There are some issues with Intergrating Python into blender, mainly to
> do with file i/o
> 1)
> I added the getMatrix('worldspace'), this is good for getting the
> absolute matrix but you still have to pass each vert through the Matrix-
> this takes up processor time and  adds unneeded functions to apply a
> patrix to X/Y/Z
> 
> I think ||NMesh.GetRawFromObject|
> <cid:part1.03090900.01080701 at metavr.com>(name)
> could be modified to include the optional parm.
> |||NMesh.GetRawFromObject|
> <cid:part1.03090900.01080701 at metavr.com>(name, 'worldspace')
> 
> Then the vert coords and normals could be exported as is without any
> processing of there locations and the speed of exporters would improve.

I would be tempted to do this as a new method, GetTransformed...() for
example, rather than overload GetRawFromObject().  As you suggest,
doing this in C would save the overhead of repeated MathUtil calls.


> 2) - More Python functions that wrap BpyFunctions ()
> These need to be distributed with blender so the Coder can rely on them
> being there- They should also be documented in the EpyDocs.
> Could be Called BPyWrapper...
> EG
> from BPyWrapper import BPyMaterial, BPyNMesh.... etc

I am not exactly sure what you mean here by wrappers.
The bpy types and methods are thin wrappers around blender's
data and functions.
 
If you are talking about convenience functions for tasks
like adding a complete object with its obdata to a scene, 
I would agree it makes sense.

Or are you simply talking about distributing more scripts
written in python with blender?  Rather than BPyWrapper, I
would simply treat them as a module of utilities ( module Util ).


> resions for wrapping some functions are that somtimes its nicer if error
> handling and logic that can be a bit fuzy (fuzzy logic) can be handled
> better py wrappers writtin in Python.

In general, errors for exceptional conditions that occur during 
processing should be indicated by throwing an exception.  Returning
an error is different than returning PyNone or an empty list.
Return types and error handling is probably a subject we should
visit during our code cleanup.

 
> Wrappers that could be written are...
> 
> ||BPyWrapper.addMaterial(mat) # adds the material to the mesh and
> returns the material index, it the material is alredy on teh mesh then
> just return the index.

Shouldn't this simply be a Mesh method?  It needs to be bound to
a particular object instance.  To do it as a module (or class)
method means you need to pass a mesh instance to it as well as
the material.

The current NMesh.AddMaterial() already checks if the material
is on the list.  It probably should return the material index
instead of PyNone.
 
> ||BPyWrapper.getLights() # returns all light objects in the scene,
> ||getMeshs would be cool too.|

All the *.Get() methods are already ( or should be) overloaded to 
return  either a list of all data objects of that type if no argument 
is passed or the named object if a string is passed.  Lamp.Get() is
an example.  If we are missing some implementations, that should 
be fixed.
 
> 3)
> Generic Image Load/Write functions - again for importers and exporters,
> The writer of the file I/O can just simply load the image and handle the
> image path.
> 
> ||BPyWrapper.ImageLoad()|
> |* Return an image object, only load if the image is not alredy loaded.
> * Handle case mismatch with file names (vert important for importing
> windows files into linux)

Case insensitivity should probably be an optional argument.  Some
systems care about this.  Some don't.  Doing it by default seems
too drastic.  Also some method is needed for reloading an existing
image.

> * Varying levels of strength for file searching (
>   0=None,
>   ||1=Return None and raise an error menu
>   ||2=Recursively look in all subdirs of the path given as well as the
> existing .blend path
>   3=Perform a full search... mabe not, but it could be done.)

I would rather see exact path matching.  Searching for a file
is a separate operation than trying to open it.  Rather than
duplicating the search code in the file i/o code, we should
make it easy for an application to handle this as needed.
 
> * What to do if the image inst found (
>   0=Return None,
>   1=Return None and raise an error menu,
>   2=Ask the user to select the image,
>   3=Create a dummy image in the same path is the file asked for)
> 
> * If an image is in an unreadable format (
>   0=Return None;
>   1=Return None and Raise an error menu,
>   2=Make a dummy image in a format Blender can read,
>   3=Convert the image to a format Blender can read (will require PIL or
> ImageMagick))

Rather than having a large set of optional arguments and associated
behaviors, I would rather see this done by the application.  Especially
if it involves packaging PIL or ImageMagick with Blender.  Not that
these aren't useful packages, I just don't think we should be dragging
them around.

Once you start imbedding things like
>   1=Return None and Raise an error menu,
then you need to pass the error menu as a parameter also.  This is
another argument for handling this in an application specific way.

> 4) Import/Export
> * Standardize file I/O- Export only Selected?... Names.... re-use any
> error handling and add these functions to the generic BPyWrapper (As I
> have called it but it could be any name)
> * Mabe even have a style Guite for naming- Non essential but would make
> it easier to read  other ppls code.
> * Have a way to Show the user what Data is Exported.
>   eg The exporter name could be modified for this
>   Wavefront (.OBJ) : ME|UV|MA
> ||   Vrml (.WRL) : ME|UV|VCOL|LA|ANI
>   ... I think there must be a better way to do this but Im not sure,

Having exporters that take a list of things to be exported would be
useful.  This would then work with our existing *.Get() methods.
We should provide tools that allow a data specific
exporter to be created with only a couple of lines of code.

> Mabe the extra Info could be stored in the Tooltip.
>   ... Multiline tooltips would be good for this.

Multiline tooltips seems like a perversion of the whole idea
of tooltips as a reminder of interface functions.  Menu entry
names and  organization should make functionality clear.

-- 
Stephen Swaney			
sswaney at swbell.net