These pages are devoted to my shape grammar interpreter project.
And what is a shape grammar interpreter?
Simply put, it is a program that runs shape grammars.
An analogy is a spreadsheet program. A spreadsheet is just a piece of grid paper on which you write numbers and formulas. To use the spreadsheet, you perform the specified calculations and write down the results. You may change the numbers and formulas, and then you redo the calculations.
A spreadsheet program, on the other hand, does all the calculation. This mechanical work is time-consuming and error-prone, so the program frees you to concentrate on the higher-level work, like financial modelling.
So it is with a shape grammar and an interpreter. The interpreter matches shapes, applies rules, and calculates new shapes. You, the designer, can concentrate on the grammar and the shapes it creates.
This interpreter is intended to help you do design by using grammars easily and, I hope, enjoyably. It has two parts:
-
The back end (also called the engine or the sortal library). This does all the calculation: matching shapes, deriving new shapes, and so on. It is by Rudi Stouffs.
-
The front end (also called the user interface or the package). This takes what you draw and passes it to the engine, and also receives the shapes calculated by the engine and draws them. In other words, it is the part that the user actually sees and touches. It is by me.
Both parts are written in Python and work in Rhinoceros3d (aka Rhino). That means you can use a grammar in conjunction with the many other tools in the Rhino environment (e.g., Python scripts, Grasshopper), and you can connect easily to downstream processes like rendering and fabrication.
When you’re ready to get set up, please go to the next page.
Technical details for the hard-core
The interpreter handles labeled shapes composed of straight lines and labeled points in 3-space (in grammar-speak: shapes in the U13 and V03 algebras) and supports emergence.
The engine can handle curves and higher-order elements (e.g., surfaces and solids), but the interface does not yet support these capabilities. If these interest you, see Rudi Stouffs’s web site.
The interpreter is general, by which I mean that it can handle a grammar that you create. It is not a one-trick pony, running a single ‘hard-wired’ grammar. You can run your own grammars and create your own designs.
Here are two forthcoming papers by my collaborator Rudi Stouffs and me:
History and acknowledgements
I worked on an earlier version of an interpreter, which still runs. If you really want to use it, let me know. But I’m not supporting it any more, and the current version is better in most ways.
That version of the interpreter was built around an application by CHAU Hau Hing. CHEN Liang coded the front end. WANG Yang coded the Autocad applet (now obsolete) and wrote the documentation. The work was supported by the Hong Kong Research Grants Committee.
I have used both versions in workshops hosted by CHANG Teng-Wen (National Yunlin University of Science and Technology, Taiwan), José DUARTE (Pennylvania State University, USA), HUANG Weixin (Tsinghua University, China), and LEE Ji-Hyun (KAIST, Korea). Students of Mine ÖZKAR (Istanbul Technical University, Turkey) have used it as well. Thank you all.
Special thanks to my students at Kyoto Institute of Technology, Japan.
A confession
I use the terms interpreter and environment interchangeably. One could argue that, strictly speaking, the back end is the interpreter; the front end is the user interface; and that the ensemble is the environment.
I also use both shape and design when referring to the output of a grammar.
In any case, I hope I’m not confusing you.
|
