Rethinking Prototyping

By contrast, DesignScript implements a hybrid imperative-associative approach to programming where code blocks from one style of programming can be nested within code blocks of another style of programming; both, associative blocks can be nested within imperative blocks and imperative blocks nested within associative blocks. This enables the designer to use and combine each style of programing where its unique strengths are relevant to the representation and execution of his design. In this example, associative programming has been used for model building, while imperative programming has been used for design iteration. Effectively, the designer has built his own custom design optimisation system.

Fig. 9 Associative-imperative programming, where the associative ‘model building’ code has been embedded within the Imperative ‘design iteration’ code.

A further progression in sophistication is to create a solution space of design alternatives. In this example, the compact, associative model building code has been repackaged as the constructor of a user defined class (Fig. 10) and this class has then been instantiated with different values for two-driver variable, with the resulting design alternatives output as a 2D array (Fig. 10). This process of repackaging of existing code or code refactoring is itself an interesting example of the progression the designer may make. Starting initially with a more open-ended and exploratory style of programing, the designer can progress to a more formal software engineering approach which may be more suited to design documentation and re-use.

Fig. 10 The original associative ‘model building’ code is re-used as a constructor for new class

Fig. 11 A solution space has been generated by instantiating a user-defined class with a range of values for two different driver variables (number of columns in X and X height) to create a 2D solution space.

DesignScript is a .Net application, which allows any existing .Net library to directly instantiated in DesignScript. This allows the user to access existing analysis and simulation library or to build his own library of tools (Fig. 12).

Fig.12 An example of a multi-disciplinary design model created with DesignScript, using a mix of simulation and analytical techniques provided by the different available plug-ins, including: form-finding (with SmartForm), structural analysis (with Robot) and insolation on the shading devices (using Performative Design). The colour coding on the structural members indicates structural utilization, while the colour coding on the shading devices represents insolation. Note: the structural nodes on the periphery are fixed, the ones in the centre are free to find their correct position.

At the Design Modelling Symposium Berlin in 2011 [7], we presented (1) the concept of DesignScript as a “domain specific, end-user, multi-paradigm programing language” (2) that one of the programming paradigm would be new type of associative language acting as a human readable text based notation for data flow programing (3) the idea of a learning environment for design computation. This paper reports further progress in these directions. It is, however, very important to understand that it is not being suggested that associative programing is universally more advantageous than imperative programming. There are, however, two specific advantages where associative programming can contribute as part of a comprehensive computational system:

First for the novice programmer: The associative language offers a direct notational equivalent of a data flow graph node diagram and (via the node to code conversion] a way for the novice programmer to make the transition from data flow programming to text based programming as part of a design computation learning curve.

Second for the experienced programmer: There is the advantage of being able to choose between two different types of programme execution, either associative or imperative. Each is equally valuable and each may be appropriate in different contexts.

In fact, the example scripts (in Figs. 7-9) exactly illustrate a key idea that different programming paradigms match different ways of design thinking. On the one hand designing is characterised by the relationships between different aspects of the design, which can be expressed through a graph-based associative language, and on the other hand designing often involves a process of iterative refinement which can be represented by conventional imperative programming. Any serious design activity is quite likely harness both ways of thinking. Therefore if such a design activity is to be assisted by computational means then the two styles of programming and program execution are also required to be combined.

DesignScript is the integration of some original and some familiar computational ideas and forms of interaction, with the aim of providing a comprehensive learning environment for design computation.

Acknowledgements

DesignScript Development Team, Autodesk Singapore Research & Development Centre

Buro Happold for the SmartForm and Robot plug-in’s for DesignScript

Andrew Marsh for the Performative Design plug-in for DesignScript

1. http://en.wikipedia.org/wiki/Imperative_programming [08.08.13].

2. Green, T.; Blackwell, A., 1998: Cognitive Dimensions of Information Artefacts – A Tutorial, Version 1.2 [www.cl.cam.ac.uk/~afb21/CognitiveDimensions/CDtutorial.pdf 08.08.13].

3. http://en.wikipedia.org/wiki/Dataflow_programming [08.08.13].

4. http://cycling74.com/products/max/ [08.08.13]

5. Aish, R.; Woodbury, R., 2005: Multi-Level Interaction in Parametric Design. Smart Graphics, Lecture Notes in Computer Science, Volume 3638, Springer, pp. 151-162.

6. http://www.grasshopper3d.com/profile/DavidRutten [08.08.13]

7. Aish, R., 2011: DesignScript: Origins, Explanation, Illustration. In: Gengnagel, C. et al. (eds): Computational Design Modeling, Proceedings of the Design Modelling Symposium Berlin 2011. Berlin Heidelberg, Springer.

DesignScript is available at Autodesk Labs, http://labs.autodesk.com/utilities/designscript/

Additional information and plug-in’s for DesignScript are available at http://www.designscript.org/

Mathias Bernhard

Abstract Frequencies of Wood – Designing in Abstract Domains presents the application of Fourier analysis to translate images of wood textures to the frequency domain. With this encoding, a lot more details can be captured by the same amount of data points than with other procedures in the spatial domain. The hereby-composed vectors are then used to compare, qualify and mix different types of wood and to re-synthesize them to new artifacts.