[Bf-python] Extending python

[Campbell Barton]

Hi  Stephen- your reply is concise and well thaught, yho I disagree in 
some areas- read inline comments.

Stephen Swaney wrote:

>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.
>  
>
I just thaught this convention seemed as good as any, and A convention 
is better then no convention, somtimes ppl split hairs on these things 
and never deciede.

>>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.
>  
>
getTransformed is good tho it all gets a bit confusing with, get, 
getRawFromObject, getDeformed, and getTransformed(ob) - But there a 
place for all of them.

>  
>
>>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.
>  
>
This one :)

>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.
>  
>
With in importer I wrote is was convieniente to have a AddThis if its 
not alredy there function, thats all.

> 
>  
>
>>||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.
>  
>
Whoops, you got me there

> 
>  
>
>>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.
>
>  
>
Some of your corrections are good but I think you miss the point.
First , Im proposing a python function that others can import-
Think of it as a *'Get my image and try root around if the answer isnt 
%100 obvious'*
if people want to deal with there own image loading they can. with there 
own script but this would give the user a set of fuzzee options that 
would stop a normal load function from bailing out.

Imagine you have a 3d file importer and you want to pull in models from 
3dsmax, some program- theres always cases the the image will have 
spaces, upper/lower case, formats will not be compatable, files might be 
in a subdir or paths not set properly, existing path is from sombody 
elses system so the path needs to be striped etc.
I wrote a MAX-ASE importer and had all of these problems.
Some of the ASE files I loaded into blender have over 80 images per 
file. (thanks to max modelers from turbosquid)
Dealing with each image name by name, changing case- hand editing the 
file etc. is not practicle- I needed a generic load image function that 
makes allowences for case/path/format etc.

Even with a batch renamer I came accross problems but The point Im 
making is that the same issue applies to many formats not just ASE-

Of course case insensitivity would be optional as well as looking in 
subdirs. - Using PIL, ImageMagick is for formats that blender dosent 
support and would only be used if they were installed, I dont see what 
the problem with that would be since there not a dependancy.

Creating a dummy image if very important since its very usefull to have 
an image mapped simply so you can go and replace it later with the real 
image.

Having the loader hunt about (the option to) is good because some MAX 
files are distributed with messing textures, that come with 3dsMAX, if 
you have these somewhere you can chuck then in your textures dir so the 
imported files dont raise errors.

This is somtjhing I have thaught of writing from converting 100's of 
files from turbosquid- But convert importing large scenes from other 
apps would pose similar problems.


>>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.
>
>  
>
You missed my point, I meant that the exporter could display in its name 
or tooltip what data is being exported- People who are new would assume 
that exporting a file would export all the scene data- When it may only 
expot the selected mesh's.

>>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.
>  
>
I disagree for a few resions
1) Some of the tooltips are alredy that long that they need to be multiline,
2) A tooltip should explain what the tool does, somtimes to explain this 
in english takes many words- more then fit nicely on a line (as sighted 
above)
- But this is a topic for the funboard.

- Cam