Dev:2.4/Source/Python/Scripted Objects

Introduction

This project aims to allow "scripted" objects in Blender: objects with type, corresponding data and configurable properties defined by a script.

In short, scripted objects can be used to define:

• Parametric objects
• Stock objects (Suzanne, a penguin, the Blender logo, etc.)
• Loaded models from any supported 3d format

Quick example: Blender has a mesh UV sphere. Its parameters are: rings and segments. But we can only define them once, when creating the sphere. An Scripted version would have the same parameters (and maybe more) accessible via buttons in a panel and would be regenerated whenever users changed any of the values there.

Why

This feature can bring interesting possibilities to Blender:

Parametric objects

Many users have requested them and a while ago, when I had started to plan this, Matt Ebb (broken) came up with an interesting idea + patch to test supporting parametric objects via modifiers.

Another advantage of having these objects is that it becomes easy to define "primitives" supported by external rendering engines. For example, Renderman and Povray support objects like spheres, cubes, cones and so on directly, we just write the relevant commands (object type and parameters) in a description file, instead of having to export each object as a mesh, writing all the vertices, etc.

Economy, performance

Scripted objects don't store their generated geometry on .blends. For each scripted object it's enough to save the script name and the current values of the parameters. With this info the geometry can be recreated on-the-fly when needed. So, considering a favorable example, where an actual mesh would store a lot of data, an scripted object might only use a few tens of bytes.

They also allow for two versions of the generated data, if desired: one for display and another for rendering. So we can display simplified or "placeholder" data on screen and, before rendering, let the script regenerate the data in all its glory. Then, after rendering, the script would again generate data for display.

A better interface for object creation

For users, quite simply: they select the desired scripted object from the Add menu or toolbox and the object appears, just as usual. Then they can configure the available parameters for their chosen object from a panel in the editing buttons win. Scripted objects support modifiers, but can't be edited directly (*).

(*) Since their data is generated by a script, isn't saved to .blends and can be recreated by the script, erasing all changes made by the user. So, no edit mode. But of course scripted objects can be converted to their "actual" object types, mesh or whatever.

For coders, we get the usual benefits from using Python: it's powerful, easy to program in and there's no need to recompile Blender for each addition or bug-fix.

Distribution: it's easy to bundle a library of scripted objects in Blender along with the other scripts we ship. 3rd parties can also easily create their own packages and distribute to their users. Users can create themes: architectural, animals, armatures, primitives, etc.

Implementation

I'm already playing with this, but still don't have a working version. It's late today, I'll explain what I'm doing some other time.

A few notes, anyway:

• Scripted objects should point to actual object data, where the script creates its geometry. This is a huge plus, since Blender can then deal with scripted objects just like it does with other types.

• After checking what Nathan (congrats, daddy!) did with PyNodes, I considered using a similar approach for our generator scripts: a derived class with its own __init__ and __call__ methods. Reasoning: it's a good idea and a little standardization in Python-related stuff in Blender is welcome, much better than each feature having a totally different way to handle things.

• First I considered having Scripted as a new obdata struct type, with struct->data pointing to the actual mesh or whatever data generated by the script. So we'd have ob->data (the Scripted struct) and ob->data->data (the actual...). But Campbell thought a new type was not needed (locking the mesh via a flag was enough) and so did Stephen, suggesting that the scripted struct could be embedded in the Object struct somehow. I had some points against that, but today finally it seemed a better option to me, too, it should make things even easier to implement. So that's what I'm testing first, thanks guys.

Willian 05:21, 20 April 2007 (CEST)