Advances in Engineering Software 43 (2012) 7186

Contents lists available at SciVerse ScienceDirect

Advances in Engineering Software

journal homepage: www.elsevier.com/locate/advengsoft

An adaptable virtual engineering platform for distributed design based on open source game technology
Paul McIntosh, Aleksandar Subic , Ka Wai Lee, Patrick Clifton, Pavel Trivailo, Martin Leary
School of Aerospace, Mechanical and Manufacturing Engineering, RMIT University, Melbourne, Australia

a r t i c l e

i n f o

a b s t r a c t
This paper presents the RMIT Adaptable Platform for Interactive Distributed Design, Customisation and Optimisation (rapidDCO), a CAD/CAE research platform which is an extension of distributed component based gaming technology. rapidDCO is designed for use in multidisciplinary, collaborative and distributed engineering environments where conicting design parameters have to be resolved by remote input from a range of disciplines and techniques. rapidDCO leverages the open source game engine Delta3D, which itself leverages existing open source technologies to provide features such as: cross-platform 3D rendering, physical simulation and networked interaction. Our approach enables the CAD/E platform to seamlessly adopt advances in the technology but leveraging work done through the broader open source community. Through these technologies and the access to the underlying source code rapidDCO is highly adaptable and can be applied to novel problems not readily supported by conventional CAD/CAE environments. Rather than building CAD/CAE capability from a top down tool perspective we take a modelcentric approach, building capability from the model up. In rapidDCO individual models are dened as software components which are then shared as libraries that are used by the component aware environment. This component based approach means that development can be focused on dening specialised models to address a specic need and not on the infrastructure to realise and interact with those models. We present rapidDCO with a formal design customisation and optimisation example demonstrating the use of rapidDCOs custom interface capability, distributed design and integration with the modeFrontier design optimisation tool and Microsoft Excel. Crown Copyright 2011 Published by Elsevier Ltd. All rights reserved.

Article history: Received 26 January 2011 Received in revised form 17 May 2011 Accepted 7 August 2011 Available online 15 September 2011 Keywords: Virtual engineering platform Distributed design Open source software Gaming technology Engineering product development User interface

1. Introduction Novel approaches to computer aided design and engineering, by their nature, necessitate the development of novel computer software to realise and evaluate the application of those approaches. As engineering technology and the associated design and analysis software increase in complexity, so does the complexity in developing the infrastructure to support applied CAD/CAE research. An increasing proportion of the available research effort is expended in developing custom versions of support tools, such as 3D visualisation, le formats and networking capabilities. These support tools are fundamentally necessary, but do not directly contribute to the associated research outcomes. As a consequence, the research effort available for the design project is reduced. Furthermore, the support tools are typically optimised for a specic purpose and the generic functionality is kept to the absolute minimum required, resulting in software that is not easily reusable or extendible to
Corresponding author.
E-mail addresses: paul.mcintosh@internetscooter.com (P. McIntosh), aleksandar. subic@rmit.edu.au (A. Subic), kawai.lee@rmit.edu.au (K.W. Lee), patrick.clifton@ rmit.edu.au (P. Clifton), pavel.trivailo@rmit.edu.au (P. Trivailo), martin.leary@rmit. edu.au (M. Leary).

other research areas. This lack of generic functionality results in multiple instances of similar support tools being developed for multiple research projects, each optimised for a specic purpose with little generic capability and with highly limited capacity for integration. The net result is that much effort is lost due to the focus on short term goals. This research addresses the identied deciencies by creating a platform that supports novel engineering design, while building a reusable capacity of generic functionality. Our platform is based on the architecture of gaming technology, leveraging a platform which is designed to enable highly customised and reusable content in the context rapidly advancing graphics technology. We have extended this architecture to support distributed design, customisation and optimisation in the context of computer aid design and engineering. The result is rapidDCO, the RMIT Adaptable Platform for Interactive Distributed Design, Customisation and Optimisation. rapidDCO provides a long term solution, while supporting the needs of short term research, reducing the non-research effort and increasing the reuse of any effort that is required. The paper presents the rational behind rapidDCO, the theoretical and practical basis for its development, and a case study to demonstrate its features and effectiveness. This research effort

0965-9978/$ - see front matter Crown Copyright 2011 Published by Elsevier Ltd. All rights reserved. doi:10.1016/j.advengsoft.2011.08.002

72

P. McIntosh et al. / Advances in Engineering Software 43 (2012) 7186

represents 6 months of development by a senior software engineer supported by two PhD students, demonstrating both the reuse of existing RMIT research and the accelerated development provided through open source game technology. 2. Overview In this section we summarise the need for a virtual engineering platform and the fundamental requirements of computer aided design and applied engineering design research in general. These requirements provide the basis for the capabilities of the rapidDCO. Also, this section will reect on related work in the eld that is of relevance to this research. 2.1. Problems in applied CAD/CAE research The requirements of software for CAD/CAE research may be fundamentally different to the capabilities of conventional CAD/CAE software. For example, CAD/CAE typically aims to assist engineering practitioners to develop representative virtual engineering models. Whereas as CAD/CAE research aims to explore a particular design problem in detail, with an emphasis on demonstrating features outside the standard CAD/CAE feature set. Applying software to solve three dimensional problems is accepted as difcult and evidence of this can be seen in the expense of commercial CAD/CAE software packages and the limitations of the open source equivalents. For research into novel areas either an existing software package needs to be extended or custom software must be developed. Basing research on existing solutions present a number of problems and creating new software is inherently difcult. Established commercial software provides an industrial quality platform but introduces limitations through restricted access to the underlying source code and restricted freedom of use through licensing structures. Research is bounded by what can be accomplished within the give feature set of the tool and the provided extensibility. Research is further bounded by licensing conditions preventing, for example, a deployment involving large groups of users in a distributed environment. Open source software, which aims to provide similar features of commercial software by contrast is less mature and needs careful evaluation before being considered a viable alternative. Also some licensing terms of open source software may conict with the needs of the research project when considering how the developed extensions can be used and ownership of intellectual property protected. The above situation has lead to research projects continually re-inventing the wheel or using a wheel that cannot be reused elsewhere. For example, one research project has used a commercial VRML browser to successfully visualise snowboard design, although the VRML browser accelerated the process it has introduced limitations in what is possible to model. The limitations have removed the ability to freely test the solution on multiple users (due to licensing cost) and to customise the underlying 3D model used for the visualisation. These issues are not unique to RMIT and occur whenever considering a platform to base research on. Due to these problems RMIT have developed its own platform with a specic focus on CAD/E research. The goals of this platform are outlined in the next section. 2.2. rapidDCO objectives The overall goal of rapidDCO is to accelerate research in CAD/ CAE by building a platform that reduces development effort and in-

creases reuse. In particular RMIT is interested in supporting research projects that have a large long term component of analysing a particular problem domain outside of a CAD/CAE environment. Once the analysis is complete, the projects then generalise the solution through implementation in a CAD/E environment. In this context the key goal of rapidDCO is not to accelerate modelling but to provide an anything goes platform that can implement key ndings from a research project. As an example at RMIT Sports Engineering Technologies (SportzEdge), performance parameters of sports equipment are quantied through user studies and experiments, once these parameters are quantied then CAD/CAE techniques can be customised to meet the needs of the specic product (see Section 5). To meet the overall goal we approached rapidDCO implementation through the following high level requirements: 2.2.1. Model-centric approach Due to the applied research nature of the problem domain rapidDCO does not attempt to provide a platform that initially supports typical CAD features, such as various modelling tools for constructing an object. The platform focuses on models and their features being developed as a C++ library. This library makes use of C++ inheritance where all models are derived from a generic base model. Through inheritance and reuse over a number of research projects the base model will evolve into a fully featured modelling kernel. The evolution path means that a feature such as surface modelling may be introduced as needed through one research project and made generic in the base model so that all derived models gain this feature. Once such generic features exist, the user interface can then be updated to exploit those features (i.e. typical CAD interface tools can be developed). 2.2.2. Open source with permissive licensing We have a requirement that RMIT have control over the source code RMIT develops for the purposes of commercial in condence research to be undertaken. This need is served well by licenses such as LGPL (GNU lesser general public license [1]), which enables software to be closed though at the same time, allows access to the underlying libraries that the platform is built on. 2.2.3. Distributed interactive design We have the requirement that multiple stakeholders can observe and interact with design objects in real-time. The rapidDCO platform must therefore enable real-time distributed communication between instances and have a customisable interface to suit the needs of different users. Further to this, the installation size and licensing terms need to support ease of download, installation and use across the internet. 2.2.4. Heterogeneous parametric design We have the requirement for an anything goes approach, to allow design techniques to be combined in anyway the research sees t. The rapidDCO platform must therefore provide a number of means of interacting with the model parameters. 2.2.5. Integrate with existing CAD/CAE technology We have a requirement for a platform that supports the application to novel problems in a research context. The goal is not to imitate existing CAD/CAE environments but to provide a platform to address issues that are not supported by existing CAD/CAE environments. Therefore we have a requirement to allow ease of integration such as supporting a variety of CAD formats and providing interfaces for external tools to utilise.

P. McIntosh et al. / Advances in Engineering Software 43 (2012) 7186

73

2.2.6. Reduced cost of ownership We have the requirement to reduce cost of maintaining a source code base. The goal of rapidDCO is to maximise research effort and reduce ancillary costs involved to supporting the research effort. 2.2.7. Future proof We have the requirement for the solution to evolve with changing technology. The rapidDCO platform should absorb new technology easily rather than be made obsolete by it. 2.2.8. Cross platform rapidDCO should be cross-platform and support a variety of possibilities from a Windows desktop to a Linux high performance computing cluster. With our goals set out for rapidDCO, in the next section we discuss related work and how they relate to these goals. 2.3. Related research There is an enormous body of literature and developed technology in the general areas of Computer Aided Design and Computer Aided Engineering. To place rapidDCO in the context of this literature and to enable us to focus our discussion on closely related research we rst position rapidDCO within a subset of CAD/CAE technology. We then discuss this subset followed by an exploration into a number of closely related technologies. Within the context of open source CAD/E research tools notable frameworks are Open CASCADE, OpenFOAM and to some extent VTK. Open CASCADE is a framework aimed at pure CAD/CAM/ CAE modelling applications and has many similarities to rapidDCO, such as component based architecture. The key differences between rapidDCO and Open CASCADE are that rapidDCO is based on more permissive licensing and it leverages open source technology outside the realm of pure CAD/E, in areas that are under more active development. OpenFOAM is a framework for CFD analysis, although not representing an anything goes approach it is a good example of how such frameworks can accelerate research into CAD/E. OpenFOAM however needs extensive knowledge of the framework to achieve research outcomes and is difcult to use and learn. VTK, the Visualisation Tool Kit, is another example of a successful open source framework in the area of visualisation that had accelerated research. Like OpenFOAM it to is difcult to use and learn, however some issues are addressed with a user interface implementation called ParaView. ParaView now presents researchers with access to features of VTK and also OpenFOAM as a viewer to the results. Although rapidDCO is designed to support an anything goes approach, as we will see in the subsequent sections, the rapidDCO implementation has particular strengths which places it within the eld of CAD/CAE technology. The underlying infrastructure of rapidDCO specically supports the use of design artefacts within a networked environment and with multiple users interacting in real-time. This was intentional in supporting Distributed Interactive Design and therefore rapidDCO falls into the area of Collaborative Computer Aided Design or Co-design [26]. Additionally from a pure technology perspective, rapidDCO leverages computer gaming technology to achieve non-gaming benets; therefore it can also be classed as an example of Serious Games [7]. To overcome some of the described limitations of conventional stand-alone CAD/CAE software packages, and to provide added versatility through virtual product design, this research is concerned in particular with the problem of Process Integration and Design Optimisation (PIDO). Some early applications of modeFrontier and other PIDO tools are described in [8,9]. Also, an example of custom software algorithms developed to overcome limitations of commercial CAD/CAE systems is given in [10].

3. Delta3D architecture The approach implemented in rapidDCO development leverages software architecture from game engine technology. In some respects game engine technology addresses the same issues that occur in CAD/CAE research. There is a need to utilise existing cutting edge technology with minimum effort, yet allow a highly exible approach to introducing unique content to make best use of that underlying technology. In this section we discuss the Delat3D software architecture as background to how it has been used in rapidDCO. We rst discuss Delta3D and the synergies between its objectives, the resulting architecture and CAD/CAE research. Delta3D is an open source game and simulation engine built for military training [11] with a developer community supported through the Delta3D website [12]. The design philosophy is stated in a four part credo as: (1) Keep everything open to avoid lock-ins and increase exibility. (2) Make it modular so we can swap anything out as technologies mature at different rates. (3) Make it multi-genre since we never know what type of application it will have to support next.1 (4) Build a community (or leverage an existing ones) so the military does not have to pay all the bills [11]. In realising these principles the software architecture is built as an Application Programming Interface (API) layer which brings together a number of other open source projects. Rather than building a complete engine and maintaining it, Delta3D uses best of breed components that are under active development outside of the game engine context. For example Delta3Ds rendering uses OpenSceneGraph [13] which has a community of over 2000 developers, with 372 of those actively contributing to the 2.8.1 release [14]. By using this approach Delta3D has reduced the overhead of code directly maintained by the project to 4% of the total (50,000 lines for Delta3D out of 1.2 million for its components) [11]. These benets afforded to the game and simulation space, are also benets to CAD/CAE research. The Delta3D platform presents a highly exible basis for developing a CAD/CAE research platform. It builds on high performance components without precluding access to the code of those components, as well as the active communities supporting them. Additionally, as there is a vested commercial interest in Delta3D building an active community, there is ready access to good documentation and support through the Delta3D website [12]. In this section we discuss the aspects of the Delta3D software architecture necessary for further discussion into its application to rapidDCO. This has been derived from the training material provided at the Delta3D website [9] and the software design documentation [15]. Delta3D is designed specically for creation of user dened applications. An overview (Fig. 1) is given above and below we will discuss the individual features. 3.1. Actor-proxy mechanism To enable custom content to be used transparently Delta3D uses the concept of a proxy which is an abstract interface hiding the internal implementation of an object. The purpose of a proxy is to provide a surrogate or placeholder for another object to control
1 In gaming a genre refers to the style of game, with the style inuencing the supported user interaction techniques. Some game engines only support one genre such as rst person shooter and would not be suitable for any other types of game genre or CAD/CAE style interaction.

74

P. McIntosh et al. / Advances in Engineering Software 43 (2012) 7186

Fig. 1. Overview of the Delta3D engine architecture.

access to it [16]. The term actor (see Fig. 2) is used in reference to an object within the context of a game (such as a tank, helicopter or person). As we will see later when considering Delta3D in the context of CAD/E the term actor can be interchanged with the term model (and this can also be done so here by the reader without loss of clarity). The proxy presents a standard interface within the Delta3D environment for dening and using properties of an actor. Conceptually

we can think of a property as a name and value pair both dened by strings (e.g. Height = 0.1111). The Delta3D environment is not concerned with what the properties mean, instead it provides services for listing, changing, adding, removing and invoking properties from external components (such as user dened ones) which are aware of their meaning. Both the proxy and the actor are C++ classes which have the ability to be extended within a class hierarchy, enabling reuse of common behaviour.

Fig. 2. Game Manager provides the runtime environment for components to be created and interact. Image from Delta3D tutorial 2010 Alion Science and Technology.

P. McIntosh et al. / Advances in Engineering Software 43 (2012) 7186

75

3.2. Dynamic Actor Layer (plug-in libraries) The actor-proxy mechanism allows the creation of custom libraries of actors. These libraries are used through the Dynamic Actor Layer which provides services for loading and registering custom actors within the Delta3D environment. Conceptually in the same way an actor denes its properties as string values, a custom library denes the actors it contains as string values. This enables the environment to use new content through its interface without needing to know the internal details. 3.3. Project map With the environment aware of the custom actor that we have created through interfaces of string values, this also allows us to save any state of the data in a predened project structure. The actors that are registered and their contained properties can be saved in a map le within that project structure. A map le is simply an XML format which stores the textual property values that we set. For example a Tank object, with a property Height = 0.1111, can be saved to le and reloaded at a later date. 3.4. STAGE (simulation, training, and game editor) At this point we will talk about the STAGE editor which is a level editor for composing a scene of objects by making use of all the services mentioned above. The STAGE editor is a standalone tool for creating and manipulating project resources such as project maps. This tool allows us to import custom libraries to use in our environment, load those libraries and use them in the editor as with any other predened Delta3D content. For example, the STAGE editor could be used to load libraries for trees, cars, buildings, etc. A content creator, such as a game artist or training content creator, can then instantiate instances of the objects and position them around a terrain to construct a city. Once the content has been created it can then be saved along with images, sounds and other resources associated with the custom content.

3.5. Game Manager The previous features describe aspects of Delta3D for managing static behaviour and content. The Game Manager (see Fig. 3) provides the runtime management of Delta3D Components (described in the next section), which handle things such as input, networking and logging. It does so by using the same actor-proxy mechanism that manages actors in managing components. This mechanism allows components to be custom built and added transparently to the environment. The Game Manager loads the static content descriptions (project les) and custom libraries, then brings the runtime behaviour to life through its messaging system (see Fig. 4). The Actors and Components send, receive and react to messages on their interfaces. For example, an input component may detect a J key press, this generates a Jump message, a Person Actor receiving this Jump message then Jumps in response, based on its internal programming. For distributed multiplayer games, the act of Jumping may also trigger an ActorUpdated message that is broadcast to the network. This message enables everyone else on the game to see the position of the jumping actor change up and down as it happens. 3.6. Components The components used by the Game Manager are also designed to be extensible. We can build custom components and plug them into the environment. This is the typical scenario when dening the global behaviour of a game, where game logic is dened in central components that process messages. 3.7. Leveraged open source software As stated previously, Delta3D is built as an Application Programming Interface (API) layer which brings together a number of other open source projects. As part of our discussion on the architecture of Delta3D, we present two major contributing code

Fig. 3. The Game Manager manages actor collaboration through a messaging system. Image from Delta3D tutorial 2010 Alion Science and Technology.

Fig. 4. Actor property states are shared through the game context as update messages. Image from Delta3D tutorial 2010 Alion Science and Technology.

76

P. McIntosh et al. / Advances in Engineering Software 43 (2012) 7186

bases, OpenSceneGraph and Qt that have been leveraged further in rapidDCO. 3.8. OpenSceneGraph The 3D graphics engine used by Delta3D is based on OpenSceneGraph which is an open source high performance 3D graphics toolkit, used by application developers in elds such as visual simulation, games, virtual reality, scientic visualisation and modelling. Written entirely in Standard C++ and OpenGL it runs on all Windows platforms, OSX, GNU/Linux, IRIX, Solaris, HP-Ux, AIX and FreeBSD operating systems [13]. OpenGL [17] is a cross platform software interface to graphics hardware. OpenGL is not designed for describing three-dimensional models for objects but provides geometric primitives for points, line and polygons [18]. OpenSceneGraph builds a scene graph on top of OpenGL that provides a higher level of abstraction for managing OpenGL geometric primitives. With OpenSceneGraph programmers can work at a level where geometric objects are dened as nodes within a tree structure (nodes containing nodes) which manages complex scenes. OpenSceneGraph provides features to interact with the scene graph with features such as picking (the ability to select objects) built into the framework [22]. The way the Delta3D engine has been integrated with OpenSceneGraph does not precluded access to the underlying scene graph and this provides a powerful and exible means of dening custom objects. OpenSceneGraph itself does not precluded access to low level OpenGL features, further extending the customisation possibilities. The result is that Delta3D is ideally suited to high performance complex visualisation and modelling, as complexity can be hidden through abstraction while at the same time allowing access to bare metal optimisation. As an example, a programmer can manage objects at a high level abstraction level dealing with models such as shoe, person (with shoes), city (with people)

or at the low level as manipulating individual vertices sitting in the graphics hardware. 3.9. Qt Qt, pronounced cute, is an open source cross-platform application and user interface framework that provides a large array of features expected in modern desktop applications such as windows with menus, dialog boxes for opening and saving les, tree views for item and other such widgets [16,19]. The Delta3D project editing utility STAGE is build with Qt and makes use of these features for supporting the complex task of creating scenes. In the same way OpenSceneGraph allows users to customise code down to the hardware rendering level, Qt allows users to customise code at the application user interface level. 4. rapidDCO architecture In the previous section we discussed the two major parts of Delta3D, the STAGE editor and the Game Manager. We also discussed the architecture of these parts and how they enabled customised content to be created and executed. In this section we present how we have leveraged these Delta3D concepts into an adaptable platform which supports interactive distributed design, customisation and optimisation. We rst present an overview of rapidDCO and then the detail of how each aspect of Delta3Ds architecture has been leveraged. In this section we cover the general principles and in the next we demonstrate these principles being applied to the design of a snowboard. In the previous section we used the term actor as the Delta3D nomenclature for the customised content based on the actorproxy software design pattern. In the section we shall exchange this term for model for clarity in the nomenclature of Computer Aided Design and Engineering. We have not altered the design

Fig. 5. rapidDCO architecture.

P. McIntosh et al. / Advances in Engineering Software 43 (2012) 7186

77

Fig. 6. rapidDCO screenshot. This shows a model of an airfoil. The view of the airfoil is on the right and the properties governing the shape of the airfoil are on the left. In the background is an example of rapidDCO displaying large model data.

pattern used however we are now treating the actor as a primary and singular design artefact rather than one of many participants in a game scene. The actor is explicitly used to dene our model of interest and therefore we shall call it our model. From a high level perspective the most signicant change we have introduced is that rapidDCO removes the separation from model creation, i.e. the STAGE editor, and the model runtime, i.e. the Game Manager. rapidDCO presents instead a platform where the user of the application can interact with the model in real-time as well as alter its properties. As the separation has been removed, any change in model properties in one application will be reected in any other connected application through the game manager distributed networking component. Fig. 5 gives a high level view of how we have structured rapidDCO enabling distributed real-time model manipulation. These will be discussed in more detail in subsections below. A users view of a rapidDCO application is shown in Fig. 6. Relating this view to the structure presented previously (Fig. 5) rapidDCO consists of a Qt 4.5.3 application; the left panel shows the model property editor and the right the model viewer. In this instance we see the design of an airfoil where the properties of Total Length and Teardrop Thickness govern the shape of the model. To connect and interact with other instances of rapidDC0, users use the Collaboration menu item, once connected all changes in one application instance are reected in all. The Data Connection menu item allows users to expose changing property values to applications such as Microsoft Excel, ESTECO modeFrontier or other applications capable of reading and writing to a le (such as a script). The user interface can also be customised through CustomMenuItem and scriptable Qt GUI extensions. Like Delta3Ds design credo we have leveraged existing code bases where possible rather than write our own. This approach has enabled us to reuse an existing code base and have access to a rich feature set that will improve as the underlying components improve. We now discuss in detail how we have extended individual Delta3D underlying components to support CAD/CAE.

CAD/CAE research projects. To address this issue, we have leveraged the Delat3D architecture to enable reuse through a ParametricModel based class. In the previous section we discussed the actor-proxy mechanism where the model (Actor) and its interface (Proxy) are dened as C++ classes which have the ability to be extended, enabling reuse of common behaviour. For rapidDCO we have derived a ParametricModel class from the Delta3D GameActor class hierarchy (including the associated proxy class). This extension promotes a model-centric approach to evolving a CAD/CAE environment by providing a central class for modelling behaviour. This ParametricModel now becomes the base class for all specic modelling tasks and becomes the central point for reuse of modelling concepts. For example, the problems described later in this paper are based on a ParametricModel class. In the case described, there was a need for surface visualisation and as this is a likely need in many problems, we dened a generic method in ParametricModel rather than in our specic model. As the number of research projects accumulate, so too will the generic features available in the ParametricModel.2 In situations where a project does not generalise a solution, the base class at least forces the solution to adhere to a reusable format. The reason we extended the Delta3D GameActor class, rather than start a new hierarchy, was to automatically gain access to underlying Delta3D features. The same mechanism described above that allows ParametricModel features to be inherited by all subclasses of ParametricModel, allows us to leverage GameActor features such as spatial position and game behaviour (such as distribution of property updates across a network). 4.2. Parametric model library Having specically designed content based on the ParametricModel, we make use of the features of the Delta3D Dynamic Actor Layer to create libraries which contain these models that are then loaded as content. For example on a Microsoft Windows system, models are built as Dynamic Linked Libraries (dlls) that are used as subcomponents of the rapidDCO application. This enables one
2 Delta3D provides reuse mechanisms more than just standard C++ inheritance. Parameters and features of models/actors can themselves be plug-in components. These features are noted later as future work.

4.1. ParametricModel As discussed in the overview, a signicant problem in the area of CAD/CAE research is the lack of reusable software between

78

P. McIntosh et al. / Advances in Engineering Software 43 (2012) 7186

version of the rapidDCO application to be installed on the users machine, with the specialised content being provided later via the library mechanism. Both versions of the ParametricModel model kernel and derived models can be provided as separate libraries. As an example, to start using new modelling concepts, the rapidDCO user may be provided a someNewModel.dll library along with the project directory content (explained next) and they are able to interact with that model. If the research project that produced the someNewModel.dll also generalised a solution in the model kernel then providing a new version of the ParametricModels.dll library is all that is required for rapidDCO to realise the new functionality.

4.3. Project directory The project directory, containing the Delta3D project map, is extended to contain not just resources but links to Excel spreadsheets and custom GUIs Extensions. Fig. 7 shows the project directory structure with the rapidDCO Excel and Extensions directories. The other directories StaticMeshes and Textures are other features provided by Delta3D that provide the ability to include geometric data and pixel data for inclusion in the model. For example we may wish to apply a design to a model surface and this can be stored as a .tiff or other image format.

The current message processor is implemented as a simple relay using a timed delay to ensure that updates are applied to all models before subsequent changes are broadcast. This delay prevents an echo situation where updates are received out of sequence causing periods where model properties oscillate between two values. Future implementation will provide lters to remove unnecessary updates (e.g. models receiving updates that they themselves have generated) and logic to buffer messages (e.g. collect messages and send a consolidated update). This mechanism means that no extra effort is needed for creating distributed applications with regard to the type of problem being modelled; adding new parameters is automatically recognised by the system and broadcast. The only requirement is that each rapidDCO instance has the same version of the parametric model library. 4.5. Qt interface The rapidDCO GUI (Graphical User Interface) is built using the Qt 4.5.33 framework, this was chosen as it is cross-platform, mature and fully featured. Qt was also chosen due its LGPL licensing and the fact that STAGE was also built using Qt 4.5.3. This allowed the reuse of STAGE components as well as concepts from other Delta3D Qt 4.5.3 utilities. Within the rapidDCO GUI we extended STAGEs property editor to provide a central point for control of changes to property values (see the left hand panel of Fig. 6). The Qt framework itself is extremely powerful and allowed us to make use of features such as scripting, saving application state (e.g. user preferences) and providing expected features such as le dialogs. The more advanced features utilised are discussed in the next section under Qt extensions. 4.6. Extensibility We have already presented how the actor-proxy mechanism presents a exible approach, where the environment is only aware of parameters as name and value string pairs. This approach also extends to integrating to processes outside of the environment. In this section we discuss a number of external tools that have been integrated with rapidDCO, all of which make user of the ability to work with string values without being concerned about the underlying code. 4.7. Qt extensions rapidDCO makes use of the advanced Qt features of application scripting and GUI extensions using scripts [20]. In rapidDCO we have coupled this scripting technology with the custom models through the project directory structure. This has been implemented through rapidDCO associating les within the Extensions directory as GUI extensions to be loaded with models. All scripts and uis (user interface les) within that directory are added to the main GUI when the model is loaded. This enables complete customisation of the interface based on the model, not only is the model itself a specialised software object, it can also carry specialised user interface components for interacting with the model. Our implementation currently follows the convention of each script (e.g. somefeature.js) having an associated GUI (e.g. somefeature.ui). The scripts are written on ECMAScript and rapidDCO exposes access to functions on the model property editor for these scripts to change and retrieve information about model properties. Custom GUIs are created in QtDesigner, a interface design tool, and saved as .ui les. In addition to accessing model properties
3

4.4. Distributed design In a typical Delta3D distributed multiplayer game a central server broadcasts actor property change messages resulting from game logic to the network so every player sees the same game state. This can be thought of as a star network pattern, the central server plays the role of managing and updating system state through actor update messages. The Delta3D architecture means that the messaging system does not need to be aware of the type of actor the message is about, it only collates a list of parameters and sends them to the network. To enable real-time distributed interaction with rapidDCO models, rapidDCO leverages the Delta3D Game Manager messaging system in a novel way. With rapidDCO we expect complex models and all changes to model properties to be initiated by the user or a local rapidDCO interface. To reduce the coupling of the parameters to the environment and avoid repetitive coding for every model property we leverage the update actor messaging system on the client side. Our extension to this has the rapidDCO client applications also generating actor update messages on any change to model properties. These updates are explicitly sent to the server through our custom message processor. At the server, our custom network component then applies the change on the actor local to the server which in turn broadcasts the change to all clients. This moves control from the central server to the rapidDCO clients.

Fig. 7. Project directory.

The next release of rapidDCO has been successfully built against Qt 4.6.3.

P. McIntosh et al. / Advances in Engineering Software 43 (2012) 7186

79

rapidDCO GUI events can also be connected to script functions (e.g. when les are opened). The result of the above is that a researcher can ne tune functionality for their model without updating the actual code of rapidDCO. For example a set of slider controls can be provided for convenience of users. The slider dialog can be created using QtDesigner and slider values linked to the property values. 4.8. Excel interface In the context of this research, we have incorporated Microsoft Excel as a commercially available tool through the ActiveQt framework (another Qt feature). Here we have provided a model property for referencing an Excel spreadsheet name. This means that individual spreadsheets can be associated with individual versions of a model. When the Excel data connection is activated, rapidDCO opens the named spreadsheet and connects to it. Our implementation follows the convention that within an Excel workbook the worksheet named rapidDCO io contains only information concerning rapidDCO. The rst column is the name of the property, the second is the rapidDCO values and the third are new values created by the spreadsheet calculations. The interaction convention is that rapidDCO writes then reads, meaning that it refreshes all data in the spreadsheet and then reads the resulting calculations to update the properties of the model. The technique is especially powerful in conjunction with the Excel VLOOKUP feature. As the model properties are simply name and value string pairs, VLOOKUP can be used to retrieve the value based on a name from anywhere within the spreadsheet. This means that if the model changes, for example a model property is added or deleted the spreadsheet is not invalidated as it would be if it were referring to cells by location. The result of the above is that complex calculations can conducted efciently in an ad hoc fashion using Microsoft Excel and then used directly in a model. 4.9. Shared le interface To provide a exible general purpose interface we have provided a shared le data connection. This allows data to be read and written through a le and a simple protocol. We chose a shared le rather than shared memory to enable a wide variety of scripting languages to interact with rapidDCO. Here the convention is that rapidDCO initiates shared le data connection by creating a le for communication and periodically checking that le for updates. When rapidDCO rst creates the le it updates it with a list of all of the models name/value pairs and when complete heads the le with a string ag of new_rapidDCO_data. An external process can then read the le, if it sees new_rapidDCO_data it can then read and update the properties as needed. After any update the external process changes the new_rapidDCO_data ag to new_external_data. The new_ external_data indicates to rapidDCO to read the le and update the model properties. The ag means that information is only read by one process when the other has completed its write. The result of the above is a simple but effective inter-process communication mechanism with no deadlocks. The shared le interface has been utilised for connecting rapidDCO to modeFrontier, which is explained in detail in the next section. 4.10. ESTECO modeFrontier interface

(www.esteco.com) that enables users to create workows and applying optimisation strategies to multivariate design problems. This integration not only demonstrates the capability of integration with external tools but the robustness of chained interfaces. Here we demonstrated two separate applications coordinated through rapidDCO to achieve a design objective. We implemented a modeFrontier workow to drive property changes in the rapidDCO model. The rapidDCO model then recalculated its parameters based on the new values. rapidDCO then calculated the optimisation result through the Excel integration. Finally rapidDCO returned this resulting value to modeFrontier. For this integration we made use of the modeFrontier Cygwin script interface. The Cygwin shell script managed modeFrontier workow communication to rapidDCO by writing and reading values to the shared le. The workow initiates the script with a set a variables to test and gain the optimisation result. The script writes the variables to the shared le and then goes into a loop waiting for the new_rapidDCO_data ag. rapidDCO then processes the test variables, returns the result and sets the new_rapidDCO_data ag. Once the workow script reads the ag, it reads the optimisation result variable and returns this result to record and apply logic to the next set of variables to test. 5. Virtual snowboard design study In this section we now present a specic example of how rapidDCO has been applied to the design of snowboards. First we present the research project and then how rapidDCO has been applied to codifying the results of the project. The objective of the RMIT Sports Engineering and Technology (SportzEdge) research program is to establish a technology platform for the design and mass customisation of personalised sports products applicable across a wide range of product domains, including sports equipment, apparel and footwear. http://tinyurl.com/RMITSportzedge. Within the context of Sportzedge a research project was undertaken focusing on the characterisation and optimisation of snowboard feel. This project, through user studies and experiments, identied the parameters and opportunities for innovation for snowboard design [18]. The result of this research was full characterisation of the correlation between the design parameters of a snowboard (Fig. 8) and the user desired performance parameters. With the characterisation complete it is now possible to build a rapidDCO CAD/CAE solution specically for customisation of snowboards and to extend this computer aided design capability further. For this example it was desirable to allow multiple users to collaborate on the design and apply appropriate optimisation techniques. Based on the research into snowboard characterisation, the snowboard research group has further extended the application to develop a software package which aims to provide full customisation of snowboard design and generate a visually realistic snowboard model in an interactive virtual 3D environment as a rapid prototyping tool for manufacturing. The customised software was developed using VB (Visual Basic) and VRML (Virtual Reality Modelling Language) under the Microsoft Windows platform. It combined the two different languages using Cortona automation library provided by Cortona3D, Parallel Graphics Company. Before giving an overview and discussing the VB/VRML software, we will now discuss the rapidDCO design approach and later evaluate rapidDCO against the above VB/VRML approach. 5.1. Dening the model

To assist in design optimisation we have enabled the integration of rapidDCO with modeFrontier through the shared le interface. modeFrontier is a multiobjective design environment

At this stage of rapidDCO development the modelling process is primarily a software development activity, however unlike

80

P. McIntosh et al. / Advances in Engineering Software 43 (2012) 7186

Fig. 8. Snowboard parameters [18].

Fig. 9. ParametricModelProxy denes the parameters that are exposed for the ParametricModel. ParametricModel denes the internal behaviour of a parametric model. This generalises parametric models and specialised versions are created for each need (e.g. Snowboard).

developing new CAD/CAE software rapidDCO provides an existing platform for the developed software to run in. Instead of focusing on coding the CAD/CAE features to enable modelling, we code the model itself, thus effort is focused directly on the problem being solved. Although we may model for a specic purpose, in the next section we will see how the way we model can be used to evolve rapidDCO towards less of a software development activity. Since rapidDCO is built using C++ Object Oriented principles we are able to leverage inheritance to extend existing C++ classes. In programming terms we create a specialisation of a class which is derived from a generalised class. rapidDCO has specialised the GameActor class to a ParametricModel class meaning that we have derived a new class which adds special features to the GameActor specically for aiding in parametric modelling. As we have derived our ParametricModel from the GameActor we also have access to its features. The initial ParametricModel provides features such as referencing an Excel spreadsheet, broadcasting changes to model properties and a visualisation method which is invoked on changes to model properties. The ParametricModel is now the base class for further specialisation, in this case our SnowboardModel. To develop a new model, we inherit a new class from ParametricModel to dene the internal behaviour of the model and also inherit a new class from Paramet-

ricModelProxy to dene the interface to the model. Fig. 9 shows the software structure. Within the above class structure we then dene the snowboard model in the following way. For the SnowboardModel we add properties (e.g. double contactLength) and the internal model calculations for translating the properties into a parametric model. We also have the opportunity to dene runtime behaviour by overriding the inherited game functions (e.g. dening what happens when a message is received). For the SnowboardModelProxy we dened the properties that are accessed within the SnowboardModel via a BuildPropertyMap() function. This function enables us to add or hide properties viewable to the environment. For example double contactLength is exposed as Contact Length with additional information as Property for the Contact Length of a snowboard. These properties are viewable in the model editor, game update messages and through the rapidDCO interfaces.4 With the parameters and interface dened, the core modelling happens when translating the parameters into something useful. For the snowboard we translate the parameters into a surface for
4 It should be noted that this coding effort is mostly repetitive and could easily be automated through a wizard. This has been noted as future work.

P. McIntosh et al. / Advances in Engineering Software 43 (2012) 7186

81

Fig. 10. modeFrontier workow, communication is via a Cygwin script node.

visualisation and further calculation. With the SnowboardModel we dene a Calculate() function which generates a series of vertices dening the shape of the snowboard. In the next section we discuss how those points are used. 5.2. Modelling for reuse For the snowboard we wish to now visualise the result of calculations derived from the parameters. As surface modelling is a common activity in CAD/CAE, rather than implement the snowboard modelling in SnowboardModel we implement it in the ParametricModel. This allows any class that derives from ParametricModel (i.e. all future models) to gain access to this feature. With the ParametricModel we update the Visualise() function to iterate through a list of vertices and create surfaces from those vertices. This enables the snowboard model, or any other rapidDCO model, to visualise a surface by creating a line object with vertices, adding that line to the list and calling Visualise(). At this early stage the geometry is a simple tessellation generated via OpenGL commands shown in Fig. 11. Future updates will introduce more complex mesh generation suited to analysis tasks directly off the geometry, for example when calculating snowboard stiffness. 5.3. modeFrontier integration

with rapidDCO, we see the model viewer in the bottom left hand corner which is displaying the resulting model of the current set of variables being tested. Right of the model viewer is the undocked property editor window allowing the user to view the parameters and optimisation values. Above rapidDCO is the Excel workbook that contains the resulting calculations from the actual research project. To integrate the workbook into the conguration we added a new rapidDCO io spreadsheet and linked those parameters from those cells to existing cells in other spreadsheets. Although the calculations could have been converted to C++, rapidDCO allowed us to avoid this step during the investigation phase and instead provided a means of validating the mathematics rst. To the right of the screenshot we see the analysis of optimisation results by modeFrontier. The graph shows a variety of tests starting with high variability to the left converging to an optimal result at the right. In this conguration we see a complex workow that has been used by a researcher to optimise a snowboard design. The ultimate goal of rapidDCO is to allow researchers to collaborate with industry and consumers of products. The next two sections discuss hiding the complexity of the above through distributed design and interface customisation. 5.4. Distributed design

In the previous section we discussed how modeFrontier has been integrated through the shared le interface. In Fig. 10 we show and example of the modeFrontier workow incorporating the rapidDCO interface. Variables such as Contact_Length are manipulated by modeFrontier and injected into rapidDO via the Cygwin script node. The Freeride_Output is returned as the result of the Snowboard optimisation calculation and compared to the Objective. The above workow is part of the larger conguration managed by rapidDCO. In Fig. 11 we see the complete conguration. Starting

In the instance of distributed design, we have tested the concept with a peer to peer rapidDCO connection (i.e. two instances running). This demonstrated rapidDCO functioning across a WAN with updates being shared across instances. User testing has not yet been undertaken, however there is no technical reason that the rapidDCO should not scale to the maximum 64 client connections (an internal limit set by Delta3D). Delta3D is aimed at high render rates of 30 frames per second, with hundreds of models interacting in real-time. The usage scenario for rapidDCO however is only one

82

P. McIntosh et al. / Advances in Engineering Software 43 (2012) 7186

Fig. 11. Snowboard optimisation. modeFrontier drives parameter choice and rapidDCO modies the design and calculates optimisation result via Excel spreadsheet data connection.

model, and although a high frame rate for the snowboard was achieved, a reduced frame rate would have not have the same negative impact as in a game situation. As the model itself is contained in software library, the delivery and loading of the snowboard model is only needed at the start of the design process. Updates to the design in the distributed phase are reduced to the parameters that shape the model. For the development version of rapidDCO the debug software library, which included both the ParametericModel and the SnowboardModel as well as debug information, was less than 350 kB in size. In future versions of rapidDCO the ParametericModel will be provided standalone and only inherited library need be provided as the model. As an example, the Delta3D testActorLibrary.dll contains 10 actors (models) inherited from Delta3D libraries and the release version size is merely 148 kB. 5.5. Interface customisation For user testing, such as design reviews with professionals and consumers, we are able to hide the complexity of the processing going on behind the scenes. For instance the user can have their own instance of rapidDCO connected to the research instance processing extra information (for example the modeFrontier conguration above). The user is able to introduce other properties into the design scenario by editing property values. For the snowboard however there are many properties that are not of interest and would distract users from the design process. Although wider user testing has not been undertaken, we demonstrated the use of the interface customisation to provide a slider control to allow users to manipulate the length property. This showed that a specic interface could be provided as part of the model and loaded into the rapidDCO GUI as the model was loaded. This approach supports the model centric development of CAD/CAE functionality as we are able to provide whatever tools are necessary to manipulate the model at runtime that are not limited by what the application provides.

6. Evaluation This section rst presents an alternative virtual engineering approach existing at RMIT and then evaluates rapidDCO against this alternative approach. For both approaches the snowboard design case study is used as the basis for the evaluation. Presented are the strengths and weaknesses of both approaches against the design requirements, with a summary of the results with respect to rapidDCO. 6.1. Overview of existing VB/VRML implementation This section provides an overview of the existing snowboard parametric design and optimisation program which was originally developed using VB (Visual Basic) and VRML (Virtual Reality Modelling Language) under the Microsoft Windows platform [23]. The developed program allows the user to fully customise the geometric parameters of the snowboard and generate a visually realistic snowboard model in an interactive virtual 3D environment. It also provides quick on-snow performance estimation of the customised snowboard. Further development has been done by embedding MATLAB optimisation toolbox into the program for the optimal snowboard design process, which is based on extensive research into parametric design of snowboards conducted by authors in recent years [24,25]. The architecture of the VB/VRML program is shown in Fig. 12. The model properties and material properties are entered by the user via the GUI control panel which is developed in VB environment. Parametric modelling technique is applied to generate the snowboard geometric parameters for the VRML model depends on the model properties. The Cortona ActiveX control browser window is embedded in the VB environment via the Cortona Automation Library v3.0 to visualise snowboard model in the virtual 3D environment. Another important feature is the on-snow performance estimation which evaluates the feel of the board correlating subjective evaluations to objective laboratory and eld based tests [21].

P. McIntosh et al. / Advances in Engineering Software 43 (2012) 7186

83

Fig. 12. VB/VRML architecture.

The optimisation of the on-snow performance is a reverse engineering process that searches for the suitable model and material properties to maximise the performance of the snowboard. It can be obtained by using sequential quadratic programming (SQP) method in MATLAB optimisation toolbox or le sharing method using modeFrontier as mentioned in previous sections. 6.2. Evaluation of VB/VRML implementation vs. rapidDCO The existing VB/VRML approach is an ongoing research project that mainly focuses on snowboard design optimisation. The design requirements and research problem are slightly different to rapidDCO, however they are similar enough to provide a means of evaluating rapidDCO against a typical research approach to creating a virtual environment. Each design requirement is presented with a t criterion; this is a statement that can be used to qualify if a requirement has been met. 6.2.1. Model-centric approach Model-centric approach: Fit Criteria the solution allows a research problem to be modelled directly, with effort focused on the specic problem rather than supporting infrastructure. The VB/VRML approach has the initial advantage in that in modelling a particular problem VRML is relatively easier than direct 3D programming due to VRML being originally designed for website development using simple coding techniques. VB is also a recognised entry level high level programming language which reduces effort for a researcher in the development of GUI and test bed programs. However combining VB and VRML can be difcult for a researcher who may have no cross-language software development experience. Currently, there is limited documentation and instructions for novice user on software development using the VB/VRML approach. This and the restrictions required to make VB/VRML development simple have introduced limitations in what is possible to model and reuse. rapidDCO supports development on a model by model basis, reusing the rapidDCO infrastructure. This has been demonstrated

in the development of a snowboard model, where all snowboard specic logic was captured in a software library and supporting les captured within the project directory. The separation of model and infrastructure also extends to the user interface used for the snowboard, where it was also supplied as a project artefact. The disadvantage however is the model-centric approach uses complex software design patterns which require effort to learn and write. Although these techniques provide much benet they are time consuming to implement, especially for researchers who do not have a software engineering background. There is some relief in the Delta3D documentation which is aimed as novice users of the platform; however the correct solution is to automate and hide the complexity through various software abstraction techniques. One obvious solution is to provide a wizard, where the researcher provides a list of properties and framework code is generated. In summary rapidDCO provides a better solution for a research problem to be modelled directly but only if the user has some familiarity with C++ and 3D programming. The VB/VRML approach is also a valid approach due to reduced effort focused on programming however the 3rd party infrastructure introduces limitations to what can be modelled and reused. Future work in rapidDCO would reduce effort in programming through wizards assisting the user through common framework steps. rapidDCO should also evolve to require less 3D programming as the model kernel evolves. 6.2.2. Open source with permissive licensing Open source with permissive licensing: Fit Criteria the solution allows commercial in condence research to be undertaken and development IP retained by RMIT. The VB/VRML approach provides some areas of freedom of use. Microsoft Visual Basic Express Edition 2010 is a free development environment, without restrictive use. For individual research purposes, the free single user, xed license of Cortona3D viewer is available. However, it is restricted to one computer and distribution licenses are required for multiple users. In addition the Cortona3D is provided as a prebuilt control and it is not possible to view or alter the source code.

84

P. McIntosh et al. / Advances in Engineering Software 43 (2012) 7186

For rapidDCO all software is under taken using software which is LGPL licensed, meaning it is possible to have publicly releasable commercial software and the development IP retained by RMIT. Further to this, the model-centric approach allows other more restrictive licensing to be used for isolated cases without the need to change the rapidDCO licensing structure. This is due to the model being a self contained software library, allowing the library itself to be placed under other licensing terms should it make use of 3rd party utilities. It should be noted though that the term free does not include an individuals time to work around bugs or shortfalls in documentation. Although we found the Delta3D architecture of high quality, there were many instances of workarounds required for included components. Although Delat3D has an active forum, because we are using it in a novel way we experienced unique issues that only we could resolve. In summary rapidDCO meets the t criterion and allows commercial in condence research to be undertaken and development IP retained by RMIT or a 3rd party engaging RMIT to undertake research. 6.2.3. Distributed interactive design Distributed interactive design: Fit Criteria the solution allows real-time design interaction between geographically separated users. The VB/VRML approach enabled the snowboard design software to be interactive providing real-time visualisation and quick performance estimation for the user. VB has the advantage of fast and easy GUI development while VRML also supports Java script which extent the possibility of interactive design. The issue however is that multiple users are not automatically supported. An individual user may manipulate a design, however a specialised webserver is required to co-ordinate design changes between many instances. Although VRML support Java script, it has some limitations for interactive design. For example, VRML does not render some advance effects such as tactile and specular effects that other game engine do. rapidDCO implements a highly extensible distributed interactive design solution. It rstly leverages a gaming framework which is designed for much higher real-time interaction performance compared to CAD/E problems. rapidDCO also leverages the existing gaming distributed mechanisms to avoid any additional coding where any property added to a model is automatically available to every connected instance of rapidDCO. The design is only currently hindered by the simplicity of the network message component. It is currently a dumb relay and does no optimisation or sanity checking of messages it processes. For example, currently a model broadcasting a property change will also receive its own message and act on it. If the change is going through a set of values e.g. a slider going from 1 to 5, this can cause echo until the nal value is reached (e.g. instead of 1,2,3,4,5 we might get 1,2,2,3,3,4,5). This was easily resolved by introducing a delay but the true solution would be to have a more intelligent and optimal network message component which ltered and cached messages. In summary, as rapidDCO leverages a distributed game environment it also inherits a high performance real-time design interaction between geographically separated users. We have demonstrated its use for CAD/E but more work is required to improve message processing. 6.2.4. Heterogeneous parametric design Heterogeneous parametric design: Fit Criteria the solution allows for a wide variety of research problems to be undertaken. The VB/VRML approach has been demonstrated in the modelling of two components. The rst one refers to parametric modelling of snowboard geometry. The second one is the parametric design of composite and laminate materials properties of the snowboard. Research problems such as tennis rackets or running

shoes model can be create using similar technique through the VB/VRML approach. There are issues however due to not having access to the code base of the VRML control. This means modelling is limited to what is provided by the vendor as whenever a new object or equipment is created, we have to work within the bounds of the API to achieve the research goals. rapidDCO has been demonstrated modelling two problems. First we briey showed an example of an airfoil, second we presented an in-depth example of a snowboard. We believe that any research problem which requires the aid of a computer can be achieved through rapidDCO. Although this is a lofty statement based on just two models implemented in rapidDCO, it is true merely for the fact that all source code is available. Any limitation can be bypassed or bugs xed if it fails to meet the requirements. However, just because something can be done, does not mean it should be done as there is an implementation cost involved in adding missing features. rapidDCO is a research tool and established solutions should be leveraged instead of incurring this cost (as demonstrated below). In summary rapidDCO meets the t criteria and provides an adaptable approach to CAD/E research problems. The approach is more exible than the VB/VRML approach with the caveat that consideration needs to be given to development effort. 6.2.5. Integrate with existing CAD/CAE technology Integrate with existing CAD/E technology: Fit Criteria the solution allows the research to leverage existing CAD/CAE solutions. Similar to rapidDCO, the VB/VRML approach could be integrated with modeFrontier using the shared excel le technique. MATLAB Builder NE Software also allows MATLAB functions to be accessed from .NET programming platform. The VB/VRML approach has advantages in easy integration on Windows platforms through interoperability mechanisms common in Windows applications and provided by Windows development tools. The disadvantage is that it is limited to Microsoft Windows environments. For rapidDCO we have demonstrated it integrated to modeFrontier and Excel. The modeFrontier integration also demonstrated general purpose integration through a shared le. The Excel integration demonstrated the user of the Qt ActiveX frame work, which should also allow integration with other COM APIs. In addition to the above, as rapidDCO has OpenSceneGraph as a component it has the ability to import and export a number of CAD le formats. The current integrations are however simple and would not be considered of commercial quality. Further work would be required to make them seamless and robust. The integrations demonstrated required a sequence to be undertaken for the tool chain to work. In summary both approaches allow the leveraging of existing CAD/CAE solutions. rapidDCO does however provides better support for CAD le formats but may be harder to integrate if dealing with Microsoft Windows applications. 6.2.6. Reduced cost of ownership Reduced cost of ownership: Fit Criteria the solution reuses existing components and development is kept to a minimum. The VB/VRML approach was developed using free license VB and Cortona automation library which reduces the cost of ownership as far as initial development effort. In ongoing development cost, knowledge of VRML program and using Cortona automation library in VB is required. Learning could be difcult without comprehensive instruction documentation. The software licensing cost will rise for multiple user applications. rapidDCO has reused much of the Delat3D framework which in itself leverages other frameworks, this means that large team of developers are continuing to update and improve all or some of the framework. For example the OpenSceneGraph library continues

P. McIntosh et al. / Advances in Engineering Software 43 (2012) 7186

85

to keep pace with graphics hardware. In ongoing development cost, again knowledge of the framework is required. The licensing cost is however free and would be a distinct advantage in large user studies. As further evidence to the reduced cost of ownership of rapidDCO we undertook an exercise in upgrading from version Delta3D 2.4 to 2.5 prior to publication. Using the pre-compiled self installing Delta3D SDK on Windows we were able to download and compile an upgraded rapidDCO within 20 min, requiring only two lines of code to change due to a single class being moved to a different header. Linking required only one change to a new version of the XML parser but required a few hours of effort due to a conicting linker option in our project with the new library. In this instance the total effort to maintain rapidDCO at the latest version was less than 8 h. In summary rapidDCO provides reduced cost of ownership in both maintaining the code and licensing costs. 6.2.7. Future proof Future proof: Fit Criteria the solution uses components that are under active (external) development and are being updated in line with technology. The VB/VRML approach is updated in two ways. Microsoft upgrade VB every 23 years with frequent patch update for xing bugs. The latest Cortona3D viewer 6.0 and automation library 3.0 also provides more features and functions available for the development of interactive 3D VRML program. Issues occur where the upgrade of VB, the automation library may require changes of program structure and the commands that bridge VRML into VB. If the decision was made to purchase multi-user licenses, there would be ongoing costs to upgrade software as operating systems changed. The rapidDCO and Delta3D approach enables the platforms to leverage advances in the underlying technology. Not only will new versions of operating systems work, future features of rapidDCO will come about through osmosis due to new additions to features in the underlying technology. As an example, the current rapidDCO build uses the current release of OpenSceneGraph 2.8. OpenSceneGraph typically has a production release of versions twice a year. The current development release contains features for mobile device rendering, OpenGL 3.x support, writing of .3DS les, online 3D presentations and many bug xes [13]. Issues occur with each upgrade of a component as it requires a period of time before the changes make it into Delta3D due to code breaking changes. Also some components lose popularity and developer support and therefore risk becoming obsolete. If rapidDCO were to require cutting edge features then active contribution to the Delta3D code base would provide the most effective solution. In summary both the VB/VRML approach and rapidDCO leverages frameworks undergoing active development. 6.2.8. Cross platform Cross platform: Fit Criteria the solution will work on a variety of platforms such as Windows/Mac/Linux. The VB/VRML approach cannot be considered cross-platform as the software works only on the Windows platform with an installation of the Cortona3D viewer and Microsoft .Net Framework. rapidDCO is designed for and works on all platforms that Delta3D supports namely, Windows, Linux and Mac. Our development was undertaken using Microsoft Windows Visual Studio 2008 on Microsoft Windows 7. Windows is the main platform that Delta3D supports to the level of providing prebuilt SDK autoinstallers. As an exercise we undertook building rapidDCO on Linux and found this was relatively easy due to the downloadable Delta3D Ubuntu Linux Live DVD. This provided a full operating system precongured with a Delta3D Eclipse IDE build environ-

ment. The only change required for rapidDCO was excluding the Windows specic ActiveX code used for integration with Excel. The effort for porting was approximately 16 h and 90% of this effort was learning an unfamiliar build environment. We had best success with the Qt Creator IDE which was more intuitive for building Qt based applications such as rapidDCO. 6.2.9. Further evaluation into scalability In related research we discussed similar frameworks such as OpenFOAM and VTK. One notable feature of these frameworks is their ability to scale to large problems and run in a High Performance Computing (HPC) environment. As an exercise we investigated building rapidDCO on an 84 node HPC environment called MASSIVE (Multi-modal Australian Sciences Imaging and Visualisation Environment) (www.massive.org.au). Our motivation is in supporting portions of a distributed design being computational intensive and running in real-time. This section presents some of the issues and opportunities resulting from that investigation. The main issue is that, despite the relative ease of building rapidDCO in a single user Linux environment, building it in a shared environment is much more problematic (despite using the lessons learned earlier). The issue arises due to HPC environments being shared and therefore require users to be protected from each other through partitioning of software installs into unique locations. Unique locations mean that none of the prebuilt libraries could be used due to not being relocatable to non-standard locations (instead expecting access to for example /usr/lib). The non-standard locations also compounded problems in building components from source as every build conguration of every component had to be altered to succeed. The effort taken in building rapidDCO in this environment was approximately 40 h (including compile time), whereas OpenFOAM or VTK could be installed in less than an hour (excluding compile time). Having built rapidDCO, it was able to perform very well in the HPC environment. Fig. 6 shows rapidDCO running on MASSIVE with the large model data in the background being a 3D scanned Vespa with 14 million cells. The interactive rendering speed was comparable to ParaView, even without using ParaViews techniques of dynamically lowering the level of detail and using multi-threading/processors. To scale to extremely large models and datasets however, rapidDCO would need to use such techniques. These are both inbuilt into the framework but do require some digging into OpenSceneGraph and Delta3D to leverage effectively. Also for large distributed data interaction the actor-proxy mechanism, intended for internet speeds, would need to be altered to leverage the high performance communication mechanisms found on clusters. 6.3. Evaluation summary As rapidDCO was designed against the requirements above it is not surprising that it meets the t criterion stated for these requirements. Evaluating these against an existing research project, we see that comparatively rapidDCO accelerates research in CAD/CAE through building a platform that reduces development effort and increases reuse. 7. Conclusions and future work In this paper we have presented a new approach to developing CAD/CAE applications using a model-centric approach leveraging collaborative computer aided design and game technology architectures to provide underlying services. This approach allows the reuse for applied research effort to build up CAD/CAE features from the inside out without licensing restrictions on the use of the

86

P. McIntosh et al. / Advances in Engineering Software 43 (2012) 7186

resulting technologies. We have demonstrated the application of this technology to the design of a snowboard and evaluated the benets in comparison with existing approaches. Based on the presented research we can conclude that rapidDCO extends the existing computer aided design technology in the following ways: 1. The editing and interaction with models is integrated into a single environment. 2. The interactive component is extended to broadcast model property updates to all nodes in a distributed system. 3. The platform supports scriptable custom user interfaces associated with individual models. 4. The platform supports integration with external tools in the following areas: a. Excel through ActiveX. b. Any tool that is able to read and write to a shared le as input/output. c. modeFrontier. The current process has many repetitive tasks that can be automated to speed up the design process. To assist designers we propose adding helper functionality to reduce repetitive coding tasks. This will allow a new model to be quickly created by selecting the features required through a wizard. As an example, a wizard that allows the user to enter class name, derived class, parameter names/types/ranges, etc., could be used to generate C++ structure for the model and proxy classes. Future versions of Delta3D will include the Delta3D Game Object Component System which extends the concept of components to the granularity of the features that model objects possess. We have demonstrated rapidDCO working at the level of modelling the whole object, with features inbuilt into each model controlled through parameters. The Game Object Component System allows us to model features as complete standalone components that are dynamically added to models as required. This concept gives a new level of abstraction and reuse. For example the surface feature we have demonstrated built into the ParametricModel base class could be built as a standalone component. Models then become a framework in themselves which are dened by the components they are constructed from and the parameters used for instances of those components. Many design processes which model CPU intensive aspects cannot be combined in real-time through a standalone CAD/CAE environment, unless the CAD/CAE environment is extremely powerful such as a dedicated HPC cluster. By leveraging the distributed nature of rapidDCO we can distribute the processing of tasks to the CPU and GPU of connected systems, to replicate HPC cluster systems. For example one instance of rapidDCO could be used as the design decision node and 63 other instances undertaking computationally intensive tasks. Theoretically this would reduce a 30 min calculation to 30 s. The snowboard model presented in the paper uses OpenSceneGraph tessellation to generate the surface based on a series of vertices. This method is only effective for simple surface modelling and requires the user to consider the order in which vertices are created to effectively generate the mesh surface. Future versions of rapidDCO will contain advanced surface modelling (implemented as a Game Object Component) to encapsulate a hierarchy of surface

modelling techniques. For example rigidity analysis requires us to determine thickness at any given point on a snowboard, a surface component would enable us to include functions which return analysis information and do so in a reusable way. Acknowledgements We would like to thank Mr. Erik Johnson, Technical Director, Delta3D, for permission to use images and the assistance given via the Delta3D forum. References
[1] Free Software Foundation. GNU lesser general public license; 2007. <http:// www.gnu.org/licenses/lgpl.html> [cited 2010]. [2] Wang L, Shen W, Xie H, Neelamkavil J, Pardasani A. Collaborative conceptual design state of the art and future trends. Computer-Aided Des 2002;34(13):98196. [3] Li WD, Lu WH, Fuh JYH, Wong YS. Collaborative computer-aided design research and development status. Computer-Aided Des 2005;37(9):93140. [4] Fuh JYH, Li WD. Advances in collaborative CAD: the-state-of-the art. ComputAided Des 2005;37(5):57181. [5] Shen W, Hao Q, Li W. Computer supported collaborative design: Retrospective and perspective. Comput Ind 2008;59(9):85562. [6] Cutkosky MR, Engelmore RS, Fikes RE, Genesereth MR, Gruber TR, Mark WS, et al. PACT: an experiment in integrating concurrent engineering systems. Computer 1993;26(1):2837. [7] Leman Figen G. Studying design collaboration in designworld: an augmented 3D virtual world; 2006. [8] Hiriyannaiah S, Mocko G. Information management capabilities of MDO frameworks. Proceedings of the ASME international design engineering technical conferences and computers and information in engineering conference, ASME, vol. 3; 2008. p. 63545. [9] Flager F, Welle B, Soremekun G, Haymaker J. Multidisciplinary process integration and design optimization of a classroom building. Electron J Inform Technol Constr 2009;14:595612. [10] Prisco U, Giorleo G. Overview of current CAT systems. Integr Computer-Aided Eng 2002;9(4):37387. [11] McDowell P, Darken R, Sullivan J, Johnson E. Delta3D: a complete open source game and simulation engine for building military training systems. J Defense Model Simul: Appl, Methodol, Technol 2006;3(3):14354. [12] Delta3D. Delta3D webpage; 2010. <http://www.delta3d.org> [cited 2010]. [13] OpenSceneGraph. OpenSceneGraph website; 2009. <http://www.openscenegraph. org/projects/osg> [cited 2010]. [14] OpenSceneGraph. OpenSceneGraph 2.8.1 release bug/build x release; 2009. <http://www.openscenegraph.org/projects/osg/wiki/News/Press/OSG2.8.1> [cited 2010]. [15] Delta3D. Delta3D knowledge base; 2010. <http://tinyurl.com/delta3d-docs> [cited 2010]. [16] Gamma E, Helm R, Johnson R, Vlissides J. Design patterns: elements of reusable object-oriented software. Boston, MA, USA: Addison-Wesley Longman Publishing Co., Inc; 1995. [17] The Khronos Group. OpenGL; 2010. <www.opengl.org> [cited 2010]. [18] Shreiner D. The Khronos OpenGL ARB working group, OpenGL programming guide: the ofcial guide to learning OpenGL, versions 3.0 and 3.1. 7th ed. Addison-Wesley Professional; 2009. [19] Nokia. Qt.; 2010. <http://qt.nokia.com/>. [20] Blanchette J, Summereld M. C++ GUI programming with Qt 4. 2nd ed. Prentice Hall Press; 2008. p. 752. [21] Subic A, Clifton P, Beneyto-Ferre J. Identication of innovation opportunities for snowboard design through benchmarking. Sports Technol 2008;1(1):6575. [22] Oseld R. OpenSceneGraph-2.9.6 released; 2009. <http://blog.openscenegraph. org/?p=196> [cited 2010]. [23] Lee KW, Trivailo P, Subic A. Full customisation, parametric design and quick performance estimation of snowboard using advanced virtual reality platform. In: 4th Asia Pacic congress on sports technology, Hawaii, USA; September 2009. [24] Subic A, Clifton P, Beneyto-Ferre J, LeFlohic A, Sato Y, Pichon V. Investigation of snowboard stiffness and camber characteristics for different riding styles. Sports Eng 2009;11(2):93101. [25] Clifton P, Subic A, Sato Y, Mouritz A. Effects of temperature change on snowboard stiffness and camber properties. Sports Technol 2009;2:8796.