Parametric objects in Python

I have made a Python framework to deal with parametric objects, in particular parametric 3D objects.
To design a new type of parametric object, you specify a set of parameters such as width and height and a versatile Python class is automatically created for you.
It contains Mesh exports to Blender through BPython. There are a few example classes implemented, such as Sergio Moura’s Bolt (
Everything is free to download at (Python 2.5 required). Documentation and tutorials are on the website.

I am a programmer and not a modeller, and my knowledge of Blender is very limited. I would appreciate very much any feedback and suggestions for improvement.
Hopefully, a tighter integration with Blender is possible, so that parametric objects can not only be imported into Blender as Meshes, but edited within Blender as well.

EDIT: I made a Spyder parametric object editor for Blender: download it at look for post #16 of this thread for installation instruction and details.


every now and then there are people complaining about the lack of parametric modeling in Blender. hopefully they’ll find your system and give it a try … i might too, but am not experienced in that really so can’t comment that relevantly.

btw i like your approach of having the py lib working both in and outside of Blender.


Thanks! It should be fairly easy to use if you don’t mind creating your parametric objects by script instead of by UI.
I could create a Blender UI generator for Spyder models. But once you create the object in Blender, it’s still dumb meshes instead of editable objects.
To solve that, you need something that looks like a mesh but is under the control of a Python script.

Hopefully this attracts some attention from the Blender devs because I really need their help…

hi, these could help a little,
check the scripts wiki index
for the following scripts:
Blender Analytical Geometry,
& most of the Wizards Scripts for scripts dealing with Parametric Objects.
There’s a lot to learn from the code.

Prim.Blender only has one developer, yet it seems a great interface for adding parametric objects in Blender & he’s still working on it.
Might be worth someone giving this guy a hand.

I think you all might want to have a look at these parametric objects created by yorik [1]:

These are modifiable after ‘creation’ since they use mainly shape-keys and bones (and some python for geometry ‘creation’ instead of deforming).

Since Custom-properties are now implemented (as yorik mentioned briefly) somebody could try to extend this system to be even more flexible?


[1] This sort of parametric object was meant for Architecture, but is surely usable for other things :slight_smile:

Thanks for the suggestions!

I have also read Yorik’s article and I was very impressed, especially the Stairs object (creating new geometry).
Still, he uses the NLA editor to manipulate the object, which is actually for time-dependent animations AFAIK.
It would be much better to tie the object to a PupBlock + a Python script to recreate the object whenever the PupBlock parameters change.

Ideally, normal mesh edits should be blocked, since these changes would be lost upon recreation. The object should be “collapsed” into meshes if you want mesh editing.

For the time being, I will have to wait for the devs to implement this kind of thing.
In the meantime, I will follow Meta-Androcto’s suggestion and implement Second Life prims and more parametric objects in Spyder (the name of the framework).


This looks very interesting! I use Blender for architecture, but not the doors-and-chairs variety. I would love to see this combined with the nodal system in Blender, so you could link {10x10 array} and {chair} and get an array of chairs (for example). I know this example duplicates Blender modifiers, but you could chain them for much more complicated effects. I think the key is a seamless way of re-calculating the objects - the problem with a lot of parametric systems (I’m thinking of Bentley’s Generative Components here) is there’s not enough control over the re-draw functions, and very complicated systems can overwhelm the system.

I’ll look more closely at Spyder when I get a chance.


Just FYI: No necessarily, they do not need to be time dependent, if you only modify the value (which is qutie easy) but do not animate it it’s like what one needs for parametric objects.

The big disadvantage of the method used by yorik (and some of the other methods as well) is that :

  1. the objects are not ‘one single object’ (e.g. if the method uses Armatures, empties or even curves as helpers)
  2. There is no common gui to add these objects and/or change their settings (same problem as the other methods)

EDIT: The first problem could be solved with object-groups (or something very similar) where one can edit (move/rotate/scale) parts of the whole thing. This way one could insert/add a new Param. object and modify it with ‘sliders’ (bones or empties) without even any need of a popup/dialog (not all of them of course).
Also the editing of the “base” mesh (before or while creation) would be a must-have in some cases Thinkg of e.g a stairway where you need to edit the shape of the stairs, but do not want to do it for all of them.


I respectfully disagree with that. You could allow the user to convert the parametric object into different lower level representations, such as into independent meshes (useful for a stairway with a few missing steps) or into a single mesh with a Blender Array modifier (useful in your example) or even into other parametric objects.
Actually, Spyder contains Blender draw functions for only very few objects, and all others are drawn by conversion into those objects.

I think I wrote this a bit misleading (especially the word “editing”) :slight_smile:

I’m talking about changing the whole shape of one step before (or while) generating the (general shape of the) parametric object. In the staircase example: I really want to define how my single steps (or whatever part I’m modifying is right now) will look. Maybe i want some steel-grid steps, Some out of whole wood, etc…
Same for heads of screws, shape of the single wood-pieces in a fence, window-borders, etc…

The optimal way would be to already have this as a option in the generation/option-dialog (i.e. “What type of xxx do you want”) or by creating an extra mesh and ‘linking’ it into the parametric mesh somehow. Dunno how the second way could be possibly implemented code- and interface-wise though.
I know that some parametric geometry can only be achieved by generating them via script, but there are lot’s of cases where “using a template mesh” should work fine. The Array modifier shows quite well what i mean (although in a different way)

When the shape is final the conversion into lower level representations can be done (if needed).

Didn’t try Spyder yet, so I’m not sure how it works and what you are talking about here :slight_smile:

An example of a (very simple) parametric stairway:
(Select something else and then the stairway to get a popup with the parameters.)
Update: New version of the file where the object now preserves it’s settings (in an ID property group) in the dialog.
2 things that would be really cool to have in Blender (-Python API) in order to create good (modifiable) parametric objects:

    1. [preferable] A way to trigger a linked script on “selecting” or otherwise triggering (e.g. the [P] key is pressed or similar) an object or
    1. alternatively make it possible to attach (link) scripts to object but never execute them (we do this manually).

Or is any of this possible already?
That’s because right now I have one script liked to the scene that does all of the object handling - which is kinda bad for easy adding of completely new parts (with different code needed to modify/generate it) by simply placing it in the file.


In this file I added a new parametric primitive - a simple cylinder.
This is quite different from the stairway in that it needs to generate the geometry itself. I currently use the existing blender primitive function, but manually generation is what this is meant for.
And in contrast to the default cylinder primitive it can also be changed afterwards.

Layer 1: The parametric stairway as above
Layer 2: New parametric cylinder (right now a new mesh is generated and the old one unlinked - but still there)

For both you need to deselect and select the object.

The code for is currently hard-coded into the “scene” script-link file. A way to each of them into its object is definitely needed. I prepared it for that already if we’ll ever be able to do it though :slight_smile:

Edit: As a workaround a simple object-space script in the menu (“Edit parametric properties”) that triggers the editing of the properties might be a good idea. And a second one for adding the primitives. Still … appending the script to the objects making them independent from these scripts is the future IMO.


Nice work! It never occurred to me to put parametric objects under “global script control”. Like you say, local (object) control should be the future, but I think that I can already create a workable Spyder UI based on this… thanks a lot! Since Spyder data models look like
Type Cylinder {
Float radius
Float height
… it shouldn’t be so hard to auto-generate a pupblock() method. Generating geometry is already implemented.

Major update
I found a way to link scripts to an object without them being executed while working normally. This now allows us to create ‘smart’ objects that are modified by the new menu entry - see below.

The parameter handling script is now located in the menu: Object -> Scripts -> Edit Parametric Objects
For this you need to place the file in your .blender/scripts directory.


Objects are ‘created’ via appending (not linking) right now.
Try it in a new file and append the “cyl” object (Append -> (select blend file) -> Objects -> cyl).

The “step” object doesn’t append the “column” object automatically though, so this needs some work :slight_smile: The stairs themself work fine though.

Let the smart objects roll in :slight_smile:


This is wonderful. Just give me a week or two and I will come up with something based on this.



Glad you like it :slight_smile:

Just one more update with a new parametric “cube” object (Layer 3).
For this object I really modify (i.e. generates from scratch) the geometry of the cube with vertices and faces instead of replacing it with a different one.

Have a look at the PARA_cube file in the blend. This is pretty much everything one needs to generate more complex geometry.

Everything else is the same as in the previous file.


It is done! Download the (very experimental, very basic) parametric objects editor at Unzip it in .blender/scripts. Make sure you have Python 2.5. A Blender-specific Spyder distribution is included.

Currently implemented are: bolts, tubes and molecular pi-orbitals (something I created with my colleague this afternoon). Objects can be created or edited, and they are persistent in the .blend file. Whenever you edit the object’s parameters, it gets recreated. You can turn on auto-preview to see how your object responds to parameter changes.

The editor should work for any Spyder model that only consists of Floats, Bools, and Integers, I will try to add support for more complex models, too (manipulating Rubik toys in Blender, anyone?).

One HUGE todo is that the lack of rotation matrix updating, this should happen whenever the user moves/rotates an object. Right now, you can move an object, but once you edit its parameters, it’s moved back to the origin.

Suggestions for improvement, large or small, are most welcome.

It would be good if you could generate an object from u and v values to define an object. Like in this parametric object script:

Looks good functionality-wise and very easy to handle. But if I see this correctly you left out the most vital part of truly parametric objects.

There is no handling code stored with the object (as I did with the scriptlinks) - only a function-name with its parameters.
You always need to have the ‘master’ python script with all used object-specific code installed in order to change the settings.

I my script above the ‘handling’/‘editing’ code stored with the object you can in theory append the object from another blend file and change it without using any extra code - sans the ‘trigger’ function that executes the attached code. (I left out the “generation” of new object in the list below - call me lazy :))
I know this way has its downsides as well, but I would call them the lesser evil.

I your case you would have 3 places where there is code needed:

  • spider framework (generic code installed with blender). [No updates needed for new parametric objects]
  • ‘trigger’ script - the script that checks if a parametric object is selected and triggers the attached code. It may also generate parametric objects, but then it also needs to link the “handling” code to the newly generated object. [No updates needed for new parametric objects]
  • object-specific code - the code actually attached to the parametric object that is triggered on edit. <-- this is the only part that needs to change for each object-type.Hope I did write this in a good way? I’m never sure if i can express what I mean correctly in English :slight_smile:


PS: If you do store the needed code with the objects I clearly missed that and you can ignore this post :wink:

@hunter551: I don’t exactly understand what you mean… you can edit the parameters, no matter if they are called u or v or anything, and the object is generated.
Or maybe you mean texture mapping? The three objects that I implemented just don’t use it, but I can implement an object with texture mapping if you like…

@Werner: I think we have a bit of disagreement here :wink:
IMO, only the data should be stored in the .blend file, i.e. a string called “Tube3D(innerradius=3,outerradius=4, …)” containing all the parameters that is needed to reconstitute the Spyder object. When you want to edit the parametric object, you need to have Spyder installed (or anything else that does the job). You can still edit the meshes normally without Spyder.

I really believe that separating data and code is the lesser of the two evils. Just to name a few reasons:

  • Your .blend files will be much smaller

  • You don’t need to redistribute (parts of) Spyder with your .blend file. This means that you can edit your copyrighted .blend file using open-source Spyder plugins or vice versa.

  • Parametric code may call external DLL libraries or other data that cannot be included in a .blend file.

  • If you think that some parametric objects look poorly in Blender, you can install another Spyder plugin that does a better job. You can then still edit .blend files created with the “old” plugin, and people with the “old” plugin can still open and edit your .blend files. For example, trees would be stored as “Tree(…)”, and whenever an improved tree generator comes out, all the old .blend files will benefit from it!

btw, you mentioned that there are three places where code is needed. However, there is no object-specific code, all code except the trigger script is part of the Spyder framework. New objects are implemented by updating the framework.