How do you get the children of a Blender object using python?

Hi guys,

I have a really strange problem: I cannot seem to find any function in the Blender.Object module that gives you the children of an object … you can get the parent, but not the children. I’m wondering if I’m looking in the wrong places, and I cannot think of a reason why such an obvious functionality should not exist.

Thanks a lot!

-D


def get_children(ob):
    return [ob_child for ob_child in Object.Get() if ob_child.parent == ob]

^^ Thanks ideasman, I already did that, and the point of my post was just that it it was rather an inconvenience. If you have like 10 thousands objects in your scene, and you need to know who’s whose parent at every frame, the loop can take up a bit of cpu time.

didu, agree - its not fast, however even if we added a .children attribute to the object, it would only have the advantage that it was in C and it would still have to do all that looping.

if you want to re-use the data, make a dict of children,.

all_children = dict([(ob.name, get_children(ob)) for ob in Object.Get()])

If your working with a subset of the objects, use that instead of Object.Get() of course.

Then you can have fast access to all object children, if your reparenting in your script- youll need to manitain that data of course.

^^ what about that .makeParent function? Couldn’t you just have an additional attribute in the Object class that gets updated every time the makeParent function is called? This wouldn’t require any looping as long as there is no other way of parenting an Object.

the problem with having an “ob.children” at all is that it would be stored in the PyObject and not the Blender Object

There can be any number of PyObjects referencing a blender object, for instance.

ob1 = Object.Get(“foo”)
ob2 = Object.Get(“foo”)

ob1 and ob2 reference the same object, but they are 2 seperate PyObjects. a good way to test this is…
ob1==ob2 == True
but…
ob1 is ob2 == False

is tests if they are the same object in memory.

So if the scripter only ever used ob1 for instance, and never got the object using Object.Get() or scn.objects… it would be fine, however they probably wont at times and it will cause all sorts of tricky bugs.

A better solution would be to enforce a 1:1 match so each object references a PyObject, that way youll never have more then 1. that way python could maintain the data as your suggesting, however that would require the ID or Object struct in Blender to have an extra pointer.

Um … I see, that indeed is a problem. I’ve been wondering for a while that how come the python interface to Blender is not as complete as other packages such as VTK. As far as I know, VTK is natively written in C/C++, but it’s written in a way such that the python (and other scripting language) interface is automated as part of the build process with SWIG or something similar, as a result, the python interface of VTK can be built and used just like an ordinary python package and can be invoked independent of VTK itself.

For blender, it seems that the python interface is more like an add-on, and that’s why updaing the python interface requires lots and lots of human labour and that’s why not everything accessible in the GUI is accessible through python, and blender python modules cannot be accessed without invoking blender. I guess that blender was probably not originally intended to have a python interface, and adding a comprehensive one is just too much work. But still, it’s a pity …

Anyway, sorry about the ranting.

-D

Your right, blender dosnt have an API we can easerly wrap likethe gimp for instance.

Not sure this is the best example though- its more of a problem with how python works and that blender dosnt have that data alredy available-

The Python api is still marked experimental :wink:

^^ The Python api is still experimental? That’s very funny! :smiley:

I can understand why it’d be hard to have a full-on python interface with Blender because of the heavy GUI manipulations that Blender provides, but hopefully someone could rewrite/repackage the other parts of the code so that we can get full access to the C/C++ objects of python in the future, and make everything consistent. I’d love to get involved in this task myself once I submit my thesis (and reinstall ubuntu on my home computer).

-D