[Bf-python] Python API proposals

Dima Glibitsky dima.glib at gmail.com
Tue Oct 11 10:00:54 CEST 2011


> 2011/10/11 Campbell Barton <ideasman42 at gmail.com>
>
> > * Make unified access to both predefined and custom TransformOrientations:
>
> This breaks my own rule of thumb with the Py/RNA api which is not to
> hide internal functionality when exposing data, for 2.4x we did this
> and ended up shooting ourselves in the foot more often then making a
> good api.
> So if this is done I prefer it happen in blenders internals too, or not at all.

Agree with this completely :-)

> Don't think this is needed, we can have a way to access the matrix of
> orientations which allows access to both in a consistant way without
> fake-builtin orientations in a collection.

That's a nice solution too. But even in this case it should be
impossible to assign custom orientations names that coincide with
predefined ones.

> > * Introduce a method for getting location of current pivot (or, better, any
> > kind of pivot):
> > ** SpaceView3D.pivot_point_location([pivot_type]) -- returns the location of
> > the specified pivot point in global coordinates; if pivot_type is not
> > specified, active pivot point is returned.
>
> Can be added but wary of exactly how these api functions work.

I'm curious... What kinds of variations are possible?

> > * Add a drawing callback that gets called after rendering of common 3D
> > objects, but before rendering X-Ray objects.
> > ** E.g. 'PRE_XRAY'
>
> Guessing you need this for a specific case, I worry we get too many of
> these `special cases` when to decide whats *important* or not isnt
> easy but would like to know what this is for before commenting on it.

You are right, my case perhaps is quite specific. I want to display
custom-drawn bounding box around an object. But if there is at least
one X-Ray object in the scene, the Z-buffer from normal objects would
be erased by the time 'POST_VIEW' callback is called.
Currently I use a temporary mesh object for displaying bounding box.
Since it exists only for the duration of modal operator, I think this
is acceptable. But it would be nicer to have the bounding box look
different from the usual wireframe objects :-)

> > * Add a property definition for storing references to ID blocks (Objects,
> > Materials, etc.):
> > ** E.g. bpy.props.IDBlockProperty(type="", name="", description="",
> > options={'ANIMATABLE'}, update=None)
>
> We already got a lot of requests for this - it can be done but IMHO
> should be done in a way doesn't loop over _every_ other ID when _any_
> id is removed - which is the problem you get when any id can reference
> another.

I can think of two obvious solutions (1: use UUIDs, 2: use indirect
references), but they perhaps would require a rewrite of half the
Blender %)
Another solution I can suggest is to have a table of "alive" (or
"dead") pointers, so that a property that references some ID block
would look in the table before returning the pointer.



More information about the Bf-python mailing list