[Bf-python] comments on writing an exporter

[Peter Amstutz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, 29 May 2003, Willian Padovani Germano wrote:

> The Blender Python API in 2.25, 2.26 and 2.27 is the same, no change.
> We refer to it as bpython or 2.25.  The new implementation we're working
> on is exppython, not usable yet, but already with more modules and
> features.

So is this new API an extension of the classes defined in 2.25, or a whole
new set of classes?  Is is it documented anywhere?  If so I'd like to take
a look at it.

I am a very experienced C and C++ programmer (rather less so of a Python
programmer, but Python is a lot easier :-)  so I am interested in possibly
working Blender's Python support so that it has the features I need for my
own application.

> Yes, I had problems with that, too.  That's why in exppython the Image
> module has both attributes: the name (as seen on the Image Window in
> Blender) and the complete filename are there.

Isn't it possible to embed an image in a .blend file?  Then you don't
necessarily have a valid filename associated with an image, in which case
you need to access the image data directly.  Personally I just want the
image in a standard, compressed format (png or jpeg) so I can embed it
into my own file format, but ideally there should be a whole interface to
accessing pixels and drawing on the texture.

> > * No file dialog for getting a filename from the user.  I understand this
> > has already been fixed?  I'd also like to be able to prompt for arbitrary
> > text and/or numerical entry.
> Draw has widgets for text/number entry.  BGL, the OpenGL wrapper is also
> available.  Both the old and new implementations have them.  About the
> file selector, yes, it's back. Now in the Window module in exppython.

Is it documented anywhere how to use the Draw or Window modules?  The only
online python API documentation I can find
(http://www.blender.org/modules/documentation/225PythonDoc/index.html)
doesn't have it.

> > * To export the camera orientation I am calling obj.getMatrix() on the
> > camera object.  This matrix seems to be garbage, as the exported
> > orientation simply does not match up with the way the camera was oriented
> > in blender.
> Blender script writers suffer! ; ), you've mentioned exactly the three
> problems I had, the texture filenames, the file selector (had to write
> my own with BGL and Draw) and the .matrix attribute.
>
> I just checked the current matrix (btw, it's an Object attribute,
> relating to all data objects, like mesh, camera, lamp, etc.).  Seems to
> be working fine, though it spits some weird zeroes, things like
> 2.788543254-07, sort of.  Better round matrix values in your script.
>
> >From what I remember, the trouble in understanding the matrix was
> because Blender increases angles clockwise.  So to confirm "on paper",
> stick a minus sign there (remembering this affects only the sin: sin(-x)
> = -sin(x); cos(-x) = cos(x)) and things should eventually make sense.

Hmm.  I didn't have any problems with rotations for other things, only for
the camera.  I was also looking in the forums and found this message:

http://www.blender.org/modules.php?op=modload&name=phpBB2&file=viewtopic&t=1377

This seems to imply that there is a memory-management bug (or something
weird anyway) going on with the camera matrix.

Incidentally, I convert all the rotations to quaternions; it would be nice
to be able to access quaternion orientations directly rather than having
to muck around with the matrix.

> Not yet, as far as I know.  That'll change when module Texture gets
> done, it wasn't part of bpython, though some work had been done towards
> it.

Okay.  This is pretty crucial for the exporter to be useful.

> That's the plan.  Getting to the point where to the user it doesn't
> matter whether some blender functionality was done in C or Python.  But
> this will come later, not in Blender 2.28.

This doesn't sound like it should be a tremendously difficult thing to do,
but then again I haven't really looked at the Blender source code yet ;-)

> Fine : ).  Yes, the API is good indeed, it just needed people working to
> fix, update and extend it.  BTW, later (think a few months from now)
> we'll also consider cleaning the API, so script writers will obviously
> be important in the discussion.

Coverage of basic modeler functionality is most important, I think.  All
the features, attributes, and aspects of Blender objects should be
available to the Python program, even if somewhat half-baked initially.
There's nothing wrong with just mirroring the C or C++ API directly
Python, even if there's a better way to do it :-)

Incidentally, is there a particular reason why Blender does not use a tool
like SWIG (http://www.swig.org/) ?  I have used it to bring a
sophisticated C++ library into Perl and amount of labor it saves is
absolutely incredible.

I'll probably check out the latest CVS blender and see what exppython
looks like...

[   Peter Amstutz   ][ amstutz at cs.umass.edu ][ tetron at interreality.org  ]
[Lead Programmer][Interreality Project][Virtual Reality for the Internet]
[ VOS: Next Generation Internet Communication][ http://interreality.org ]
[ http://interreality.org/~tetron ][ pgpkey:  pgpkeys.mit.edu  18C21DF7 ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE+1baCaeHUyhjCHfcRAiKCAJwKapON2hXSh0WC/+XfN5EzP/PxDQCdGV0j
FJXrlN+yp9iDG9qAk22NEjU=
=ZkrA
-----END PGP SIGNATURE-----