Objecter

A Step towards a General Tool for Generative Design

Dipl. Inform. Univ. Guenther Doerner

Genestics - Germany

e-mail: gd@genestics.de

Dipl. Des. Univ. Oliver Endemann

Genestics – Germany

e-mail: oe@genestics.de

Abstract

This paper introduces a general approach to be able to use generic procedures for a wide range of design problems. Therefore we regard a certain product exponent as an instance of a product class, which contains well-defined degrees of freedom. The formal model of the product class is developed out of the product analysis results and is noted in a specific modeling language. For this we define the geometrical structure and relevant shaping characteristics of the product including variable parameters, dependencies and constraints. The modularity of the system permits the encapsulation of individual units, which can be reused as autonomous components in other models. The software Objecter parses the formal model, assigns concrete values to the parameters, propagates dependencies and so generates different representatives of the product class. For the variation of the parameters a choice of automatic procedures (i.e. Constant, Random, Mutate...) as well as interactive modes are provided. As a prototype of a design-supporting tool Objecter shows promising potentials in its latest state of development.

Introduction

When implementing generative approaches on computers, there is the question for the suitable environment. One can choose one of the specialized tools on the market like Maya, Illustrator, Flash or even Mathematica and use their scripting languages to integrate the generative idea. However, these tools are often very complex and demand intensive study of the whole software package. In many cases they do not offer the required methods for a certain approach.

Another strategy is to use a common, multi-purpose programming language like, Java, C++, Basic or others. But are these algorithmic programming languages ideal for solving construction and design problems in a generative approach? For the average designer, architect or artist the additional job of a software developer is quite strange, likely too technical and a too big effort – all in all: a different world. As a result, we see a variety of different individual implementation approaches, a mixture of used tools, programming environments and frameworks.

From this background we asked ourselves if there could be an environment more oriented to the goal of implementing generative ideas.

It should have the following characteristics:

• Generators for a wide range of applications should be implemented easily and straight- forward in the scope of an underlying model.
• Not only the results, but also the generators should be exchangeable and modular.
• Common generative methods like cellular automats, L-Systems and others should be integrated from the scratch.

The software Objecter we introduce here is our first step towards such a common environment for implementing generative ideas.

Methods

At the beginning of the Objecter workflow there is the idea of an arbitrary product or object. As the result of the process we want to generate many designs of this product.

We regard the designs as instances of our product class, they are all representations of the initial idea. On the one hand, they all show the same common product characteristics. On the other hand they vary in many aspects to cover the field of creative freedom.

Fig. 1: Workflow steps in Objecter

To illustrate the workflow steps we want to introduce the example “SimpleTable” here. Although a table of course is a 3D-Object, we just generate a 2D side view here to keep the things simple.

In the “2D side view scope” we could define for example: “A table is a plate and two equal-shaped legs, symmetrically placed below.” This describes the common characteristics of all instances of the product class “table”. As the degrees of freedom we find the width and height of the plate and the legs, and also the arrangement of the legs at the bottom of the plate. Aspects of the materials or the color are not to be regarded here.

Analysis

In the analysis phase, we extract the basic characteristics of our product class.

Therefore we have to answer the following questions:

What are the Product Components?

In our “SimpleTable” example, we can identify the following components:

1. Plate
2. Two equal-shaped legs

The term “equal-shaped” for the legs implicates that we actually have to define just one leg and then produce the other leg by cloning.

How are these Components Geometrically and Logically Related?

We can have at least two different views of logical relationships: either the legs are arranged at the bottom of the plate or: the plate is located on top of the legs. Both views will produce similar results here, however it is essential to have at least one point of view of the logical structure of the object.

What are the Variables, the Degrees off Freedom that Form a Creative Space?

The “SimpleTable” definition leaves out many aspects of our product. We use these “unanswered questions” to establish variation: These are the degrees of freedom in our

model space.

We can find:

1. The size of the plate
2. The size of the legs
3. The distance between the legs

What are the Constraints of Variation?

In our example, the distance between the legs is not totally free. The plate and the legs must stay connected somehow. In addition the elements should not overlap.

Model Synthesis

From the knowledge we gain in the analysis phase we are able to create a model of the product class using Objecter. At the current development state models are notated in an XML-Language called “Objective”. Later, models could also be created using a graphical editor.

Modeling means, creating a class graph for the product class using a set of given nodes.

Class Graph Nodes

Fig. 2: Types of node and their symbols.

There are nodes for different purposes. Altogether the set can cover the following demands:

• Primitive shapes can be combined and grouped to model more complex shapes
• Shapes can be scaled, moved and rotated regarding their group structure
• Shapes can be added, intersected or subtracted
• Text and Images are considered as shapes
• Degrees of freedom can be modeled by adding variant parameters for size, position, amount, color or any attribute
• Limitations, constraints or any other kind of logical or geometrical relationship can be modeled by expressions
• Special operators help simplify common tasks like arrangement and alignment of shapes
• Models can be based on themselves to create recursive models

Some parts of the model are independent from the chosen 2D or 3D workspace, others have to be defined in a given representation space. For example, a shape in 3D has a different type of coordinates than a shape in 2D. So the available nodes are organized in libraries for 2D or 3D modeling. However, many core features are implemented independently from a representation space.

Fig. 3: Common Architecture for different modeling spaces

At the current state of development, the 3D library is not implemented yet. This is partially justified by the lack of a Java 3D environment on some platforms (e.g. Mac OS X).

The next figure (Fig. 4) shows the Class Graph for our example “SimpleTable”. In the center you can see the three operator nodes “Leg Distance”, “Leg Size” and “Plate Size”. These are the degrees of freedom in our model we identified during the product analysis phase. For instance “Plate Size” has a data flow connection to the “MultiTransform”-node (MT) for the plate, it is used to scale the plate shape. However the values of “Plate Size” are not totally free. You can see that there are constraints given by “Leg Distance” and “Leg Size”: The plate width is never chosen smaller than the leg distance plus the leg width.

Fig 4: Class Graph for “SimpleTable”

Generation and Variation of Instances

After loading the XML-notation to the Objecter workspace, the parameters “Leg Distance”, “Leg Size” and “Plate Size” immediately appear on the left side and a first instance of our “SimpleTable” is drawn in the “Render” area (Fig. 5). The value fields of the parameters reflect the chosen min/max-intervals and display the current value in this range.

Fig. 5: Screenshot of “SimpleTable” loaded to the Objecter workspace

The user now has several possibilities to vary one or more parameters:

Manual Parameter Variation

By dragging the mouse in the value field of a parameter, the changes of the instance are applied in real time. This manual variation is a suitable method to explore the effect of a single parameter.

Automatic Parameter Variation

By clicking on the button “Random”, a new instance is created with all parameter values chosen randomly in their definition range.

By clicking on the button “Create”, the values for the next instance are chosen by using one of the variation rules specified in each parameter:

Mutate	The next value varies from the current one by a small, random offset
Random	The next value is completely random
Tweed	The value slides from the current value to a randomly selected target value, after it is reached, a new target value is chosen
Sweep	The value oscillates through the complete definition range
Constant	The value does not vary at all and can only be changed manually

Applications

In this section we briefly introduce some example generators in different fields of application.

Furniture Design

Furniture is a quite good field of application, because the industry and handicraft uses mainly simply shaped profiles.

A Table Generator

The following example illustrates the range of designs of another more advanced table generator. All in all, this generator has 21 parameters.

Fig. 6: A series of instances of a more advanced table / sideboard generator

This generator uses style definition tables for different wood textures and fill colors.

Fig. 7: Instances with style definitions “Cherry-Style” and “Oak-Style”

The drawer handle bars are the output of a separate generator which is embedded in the main generator.

A Recursive Shelf Generator

Another furniture example demonstrates a recursive model implementing a “divide and conquer” algorithm. Beginning with the given outer size, the generator divides the shelf into smaller areas and finally decides to insert a solid or glass door element, a compartment or an empty unit.

Fig. 8: Results of a recursive shelf generator

Industrial Design

“The Watchmaker”

The example “Watchmaker” is a completely image based generator. It uses a library of predefined graphics and recombines them on different layers.

Fig. 9: Random “Watchmaker” results.

Science

Lindenmayer-Systems

Lindenmayer-Sytems are a wide spread method for simulation of natural growing structures. As a proof of feasibility we created models for many classic L-Systems in Objecter.

Fig. 10: Some L-Systems modeled in Objecter

Graphics - Arts

A 2D Pattern Generator

Using a single quadratic image as a tile, we create 2D-patterns by flipping and rotating in 90° steps. The tile used in the example below has only 4 different orientations due to its inherent symmetry. Generally 8 different orientations are possible.

Fig. 11: Single tile in its 4 possible orientations

Our pattern generator combines n x m tiles in variant orientations to create larger tiles for filling rectangular areas by repeat patterns. Instead of using images, one could also insert a tile generator into the pattern generator.

Fig. 12: Tile patterns with different complexities

A Comic Face Generator

75 Parameters distributed over 12 single generator templates (e.g. eye, nose, hair) are producing an uncountable amount of individual characters. In the animation mode you will see them being transformed one into the other.

Fig. 13: A comic face generator creates instances of “Mr. M. U. Tate”

Summary

Objecter is a suitable platform to develop generators for a wide range of objects. It could be a valuable tool for professionals in the field of design, architecture, engineering and arts. With Objecters ability of animation and direct user interaction it could also be used for visualizing complex issues and so applications in the e-learning market could be found.

Due to the modularity of class graphs, models could be exchanged and libraries for different trades could be built up by a user community. A future user forum on our web site will initiate this process and give us the desired user feedback for our development.

At the current state of development we see room for various improvements:

· Developing an Objecter class graph is not always straight-forward and can be tricky in

some cases. More special operators for common modeling problems will be added

· A graphical editor for modeling could replace the current necessity of a formal scripting language

· Algorithms for solving optimization problems are not implemented yet. All expertise has to be defined by the user

· The implementation of the 3D-library will open up new perspectives