TECHNICAL FIELD

The present invention relates to a computer-implemented method and a corresponding system and computer program for facilitating product development processes.

BACKGROUND

The product development of composite products that are assembled of a plurality of distinct components generally comprises different development steps or stages. Irrespective of whether these steps are performed as distinct steps, e.g. sequentially and/or in parallel, or whether they may be performed as overlapping or interleaved processes, the different steps or stages usually focus on different aspects of the product and/or different processes related to the product, such as manufacture, assembly, marketing, operation, maintenance, etc. Several of these steps or stages may involve the generation of visual representations of the product or parts thereof, e.g. in order to visualise the product during design, for the generation of instructions or manuals for assembly, operation, maintenance, and/or disassembly of the product, for the generation of marketing and/or training material, for the generation of packaging material, etc.

The visual representations may be in the form of a picture, an image such as a digital image or raster graphics image, an animated movie, and/or any other form of visual representation. Often, the different stages or steps of the product development may pose different requirements on such visual representations, e.g. in terms of speed and/or cost of generation, quality, form, etc.

Examples of composite products comprising a large number of components include large machines, cars, airplanes and other vehicles, buildings, as well as products that are sold and shipped unassembled, such as furniture, toy models, etc. A particular example of products that are composed of a large number of smaller components, include toy construction sets including a plurality of interconnectable toy building elements.

There are various known types of modelling concepts of such toy construction sets. Especially modular or semi-modular concepts are very popular as they provide an interesting and challenging play experience. Typically, these concepts provide a set of pre-manufactured building elements that can be interconnected with each other in some predetermined way by means of connection elements or other coupling means of the pre- manufactured elements. The pre-manufactured building elements may resemble well-known objects adapted to a specific modelling task. Thus in e.g. building a model of a house the building elements may resemble wall bricks, roof tiles, doors, and windows. An advantage of selecting the building elements in this way is that the work involved with the building of a model of a house is reduced significantly compared to a situation where all details of the house are to be defined each time a new model should be made. However, the complete freedom in building a house or another object is traded off for the simplicity of building the model.

For example, the toy construction sets available under the name LEGO comprise a plurality of different types of interconnectable building elements having protrusions and corresponding cavities as connecting elements. The connecting elements are arranged according to regular grid patterns, thereby allowing a wide variety of interconnections between building elements.

Typically, such toy construction sets comprise a set of building elements suitable for creating one or more building element models, e.g. an animal, a robot, or another creature, a car, an airplane, a spaceship, a building, or the like. A toy construction set typically further comprises building instructions for one or more building element models that can be constructed from the building elements included in the toy construction set. The building elements and building instructions are typically packaged and sold in a box having various illustrations of the building element model(s) printed on it. The product development of such toy construction sets typically involves the design of the toy model from a plurality of suitable building elements. The designer typically selects the building elements from a pool of available elements; however in some cases new building elements may need to be designed in order to accommodate the needs of a new model. When designing a new toy model, the designer typically uses a computer-program allowing the construction of virtual models from virtual counterparts of the available building elements resulting in a digital representation of the toy model. The digital representation may then be used during subsequent production steps, for the generation of marketing and packaging material, etc.

Generally, in modern product development processes an increasing part of the product development is performed by means of computer-implemented tools that support and facilitate respective phases of the product development. For example Computer-Aided-Design (CAD) and Computer- Aided-Manufacturing (CAM) tools exist as well as 3D computer graphics tools for generating visual representations such as images and/or animations etc.

3D computer graphics generally refers to graphics that use a digital representation (also referred to as a 3D model) of three-dimensional geometric data for the purposes of performing calculations and rendering 2D images. This process may roughly be sequentially divided into three basic phases: A 3D modeling phase including the process of forming the shape of an object, a layout and animation phase including a definition of the placement and optionally motion of objects within a scene, and a 3D rendering phase which produces an image of an object. Apart from serving as an input for the rendering process, a 3D model may be used in non- graphical computer simulations and calculations. In the context of 3D Computer Graphics, the term rendering generally refers to the process of generating an image or other visual representation from a 3D model by means of one or more computer programs. The 3D model is a description of three dimensional objects to be rendered in a predetermined language or data structure including information about the 3D geometry of the object(s) to be rendered. The model may further include additional information such as viewpoint, texture, lighting, and/or shading information. An example of such a computer-implemented tool is the integrated 3D modelling, animation, effects, and rendering solution marketed under the name Autodesk Maya by Autodesk Inc.

The different product development stages also involve different requirements on the general computer-implemented tools for working with composite products and its components. While the above tools have increased the efficiency of product development processes, there remains a continued need for further improvements of such tools.

An important issue in connection with digital representation of composite products including many components is the size of the digital representation and the computer resources and time required to process them. For example, a toy building element model of the type described above may include hundreds or even thousands of individual building elements, and the computer-manipulation of digital representations of such models becomes a very resource-demanding task.

It is thus a general problem to keep the digital representations of the composite products used by computer-implemented tools as small as possible in order to reduce to requirements for the underlying hardware but still providing the desired functionality, ease-of-use, quality of visual representations, and supply of information needed during respective product development stages.

SUMMARY

Disclosed herein is a computer-implemented method of supporting production of a composite product, the composite product comprising a plurality of components. Embodiments of the method comprise: At least a design step comprising

- providing a computer-implemented construction tool for allowing a user to select a respective digital representation of each of the plurality of components from a repository of components, and to arrange the selected components in a spatial relationship to each other so as to generate a digital representation of the composite product; and a further processing step comprising

- generating a visual representation of at least a portion of the composite product for use during at least one of production, marketing, and use of the composite product.

Embodiments of the method further comprise:

- storing a plurality of versions of digital representations of each component, each version of a digital representation of a component including geometry information for visualising/rendering the component at a respective level of detail, and each of the design step and the further processing step comprises:

- for each component of at least a portion of the composite product, selecting a level of detail to be associated with the component and obtaining a stored version of the digital representation of the component corresponding to the selected level of detail; and

- generating, from the generated digital representation of the composite product and from the obtained versions of digital representations of the components, a respective visual representation of at least the portion of the composite product.

Consequently, the method described herein provides an efficient way of facilitating computer-implemented product development processes and of visualising composite products comprising a large number of components while limiting the size of the data structures involved. In particular, the digital representation of the composite product does not need to include the geometry definitions of all its components, and the same digital representation may be reused in different development processes, as the digital representation of the composite product may be combined with respective versions of the digital representations of its components, depending on the needs of each development step. Hence, the digital representation of the composite product may be used both in connection with the generation of marketing materials where high-quality, often even photorealistic, graphics are required and in connection with early design stages, where efficient and frequent manipulation of digital representations is required.

In particular, the method allows use and visualisation of the components in different levels of detail (LODs) based on the needs for use in the current development step. Furthermore, at each development stage, representations of the model including representations of the geometric shape of the components may be kept as small as possible given the respective requirements of the corresponding development stage.

In terms of 3D computer graphics, the LOD on an element describes how detailed the 3D shape of a real-world element is displayed on a computer screen. Hence, accounting for level of detail involves changing the complexity of a 3D object representation. In 3D computer graphics, LOD management is used to manage the complexity of a 3D object representation as the object moves away from the viewer or according other metrics such as object importance, eye-space speed or position. Level of detail techniques increases the efficiency of rendering by decreasing the workload on graphics pipeline stages, usually vertex transformations. The reduced visual quality of the model is often unnoticed because of the small effect on object appearance when distant or moving fast. In a so-called discrete LOD (DLOD) approach a certain number of object representations of different complexity are cached for use at different distances of the object from the viewer. The creation of different versions of the digital representations of each component may thus be done off-line, e.g. by a separate system or separate module of an integrated system, i.e. without affecting the performance of the visualisation process. The versions of the digital representations of the components may be created by any suitable technique known as such in the art, such as polygon reduction techniques or the like.

In some embodiments, at least one version of each digital representation of a component further comprises a display parameter for controlling visual representation of the component; and the method comprises controlling generation of the respective visual representation of at least the portion of the composite product based on the respective display parameters comprised in the obtained versions of digital representations. Hence, aspects of the visual appearance of the composite product other than the level of detail may be associated with each LOD. For example, different versions of a digital representation may comprise different values of the display parameter.

Hence, respective schemes of representation may be associated with each version, and thus with each development stage, thereby allowing a uniform appearance of the components in an efficient way.

According to some embodiments, at least one version of each digital representation of a component further comprises an attribute indicative of at least one property of the component; and wherein the further processing step is based on the respective attributes comprised in the obtained versions of digital representations. Hence, in addition to the pure visual appearance, special information may be saved with each component, such as information about how parts of the component should be colored or production information like prize or weight or the like. Not all of such additional information is needed in all development steps. By associating different types of information with different versions of a component, the amount of data needed at each step of a development process is greatly reduced. When each version of a component has a corresponding LOD and a corresponding set of information associated with it, the change from one development stage to another may be performed in an efficient way, simply by replacing each component by another version of the component. As the user is not required to select both a suitable LOD and suitable additional attributes for a given development step, the risk for mistakes is reduced.

Embodiments of the method described herein may process a digital representation of the composite product. Such a digital representation may be provided by any suitable process and make use of a computer- implemented construction tool. The process may involve a bottom-up design from individual components and/or an automated process for generating a suitable initial representation, e.g. a process for generating a digital representation of a building element model from one or more images, such as images of a physical model or another object. One such process is described in US 7,092,899. In this process a digital representation of a building element model of an item is created from a CAD model or a set of two-dimensional images of a three-dimensional item. Some embodiments of digital representations may include information indicative of the types, position, and/or interconnection of building elements, etc. in any suitable data format. Embodiments of digital representations may further include information about global model attributes, attributes of individual building elements, such as a building element type, color, size, bounding box, etc.

A computer-implemented construction tool for interactively constructing a virtual model of a composite product may comprise a computer program that, when executed on a computer, provides a graphical user interface allowing a user to manipulate virtual models of composite products, including operations like selecting components, adding components to the model, deleting components from the model, changing the orientation of a component, changing properties of a component, e.g. color, type, size, and/or the like, viewing a model, saving a digital representation of a model, loading a digital representation of a previously saved model, etc. The virtual model may thus be assembled of virtual components, i.e. virtual counterparts of corresponding physical components, i.e. having corresponding relative size, shape, color, etc. The computer-implemented construction tool may also be referred to as a 3D modelling tool for creating a 3D model.

A computer-implemented construction tool may be configured to enforce a predetermined set of restrictions imposed on the relative positions of the components with respect to each other, such as collision detection between components. For example, the restrictions correspond to the corresponding restrictions applicable to the corresponding physical components, thereby ensuring that a virtual model actually can be constructed from the corresponding physical components as well.

The visual representation may have a variety of forms and serve a variety of purposes. For example, the visual representation may be building instructions, or instructions for maintenance and/or operation of a product, disassembly instructions, etc, or a part thereof. The visual representation may also be used for marketing material such as brochures, posters, etc. and/or for product packaging and/or the like. The visual representation may also be used in the manufacturing of the actual product.

For example, building instructions may be generated as a sequence of visual representations such as images. Each visual representation may include a graphical rendering of a partial building element model also referred to as a part-model, thereby providing easy-to-follow building instructions where each visual representation corresponds to a step in the building process where a predetermined number of building elements are added to the model. Alternatively, building instructions may be provided as animated sequences illustrating the actual assembly process. When the method further comprises providing a user interface for viewing the visual representations, wherein the user interface preferably facilitates a user-controlled manipulation of the generated visual representations, the digital representation of the composite product may be conveniently viewed on a computer.

Since the digital representation of the model includes all the information required for the generation of visual representations such as building instructions, the digital representation may conveniently be communicated from one computer to another, e.g. stored on a storage medium, sent via a communications network, e.g. as an e-mail attachment, uploaded on a web server, or the like. A recipient of the digital representation may thus change the level of detail of individual or of all components and utilise and/or manipulate the digital representation in a different stage of the production process, even if the new production step involves different requirements on the quality of the visual representations generated from the digital representation.

The present invention can be implemented in different ways including the method described above and in the following, a data processing system, and further product means, each yielding one or more of the benefits and advantages described in connection with the first-mentioned method, and each having one or more preferred embodiments corresponding to the preferred embodiments described in connection with the first-mentioned method and disclosed in the dependent claims related thereto.

In particular, the features of the method described above and in the following may be implemented in software and carried out on a data processing system or other processing means caused by the execution of computer- executable instructions. The instructions may be program code means loaded in a memory, such as a RAM, from a storage medium or from another computer via a computer network. Alternatively, the described features may be implemented by hardwired circuitry instead of software or in combination with software.

Accordingly, the invention further relates to a data processing system adapted to perform the method described above and in the following. The invention further relates to a computer program comprising program code means for performing all the steps of the method described above and in the following when said program is run on a computer. The invention further relates to a computer program product comprising program code means for performing the method described above and in the following when said computer program product is run on a computer. The program code means may be stored on a computer readable medium and/or embodied as a propagated data signal.

In some embodiments, the computer program comprises a plurality of different software components, e.g. for generating a digital representation of the composite product and for generating visual representations of the composite product, respectively. It will be appreciated, however, that the different processes may be integrated in a single software component or application.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention will be explained more fully below in connection with an embodiment of the method and system disclosed herein, and with reference to the drawing, in which:

Fig. 1 shows a schematic view of an example of a computer system for implementing the method described herein.

Fig. 2 illustrates an example of a building element and its connection elements for connecting the building element with other building elements. Fig. 3 illustrates visual representations of the building element of fig. 2 in three different LODs. Fig. 4 illustrates embodiments of a data structure for digitally representing a building element model.

Fig. 5 illustrates an example of a computer-assisted production process. Fig. 6 shows flow diagrams of embodiments of methods for generating a visual representation and for changing the LOD of a digital representation of a building element model, respectively.

Fig. 7 illustrates another embodiment of a data structure representing a building element.

Fig. 8 shows a block diagram illustrating an example of the process of loading an LOD version of a building element.

Fig. 9 shows a block diagram illustrating an example of the process of providing a new version/LOD of an element.

The invention will mainly be explained with reference to toy construction models comprising a plurality of building elements as an example of a composite product comprising a plurality of components. However, it will be appreciated that the method described herein may also be used in connection with other types of composite products, other types of product development processes, and other types and uses of visual representations. In the figures like reference numerals will be used wherever feasible for like or corresponding features, parts or steps.

DETAILED DESCRIPTION

Fig. 1 shows a schematic view of an example of a computer system. The computer system, generally designated 100, comprises a suitably programmed computer 101 , e.g. a personal computer, a workstation, etc., comprising a display 120, a keyboard 121 and a computer mouse 122 and/or another pointing device, such as a touch pad, a track ball, a light pen, a touch screen, or the like. The computer system further comprises a database 102 for storing information about all accessible building elements, e.g. indexed by a building element ID. The database 102 may be any suitable database system, e.g. a relational database such as an Oracle or MySQL databases, or the like. The computer system further comprises a file storage device 103 for storing geometry definitions for respective building elements in respective LODs. The file storage device may be any suitable type of remotely accessible storage like SMB or NFS-shares, etc., and the geometry definitions may be stored in any suitable directory structure.

The database 102 and the file storage 103 are accessible to the computer

101 via a suitable computer network 104, e.g. a local area network, a wide area network, an internet, or the like. It will be appreciated that the database

102 and/or the file storage 103 may be accessible to the computer 101 directly or via another computer such as a file server, a database server, and/or the like. It will further be appreciated that the database 102 and/or the file storage 103 may be integrated into the computer 101. It will further be appreciated that the information about building elements and/or the geometry files may be stored in a different manner. For example, the geometry data may be stored in a database, e.g. database 102 or a separate database.

The computer system 100 is adapted to facilitate designing, storing, manipulating, and sharing virtual building element models as well as generating building instructions as described herein. The computer system can be used as a stand-alone system or in connection with other computers. Accordingly, in some embodiments, the computer system 100 further comprises one or more interfaces for connecting the computer with other computers via a computer network, e.g. the Internet.

Fig. 2 illustrates an example of a building element and its connection elements for connecting the building element with other building elements. In particular, fig. 2 shows a perspective view of a building element 201. The building element 201 has a top surface 202 with eight knobs 203a-h that can engage with corresponding holes of another building element, e.g. holes on the bottom surface of another building element. Correspondingly, building element 201 comprises a bottom surface (not shown) with corresponding holes. The building element 201 further comprises side faces 204 that do not comprise any connection elements. Building elements of the type illustrated in fig. 2 are available under the name LEGO in a large variety of shapes, sizes, and colors. Furthermore, such building elements are available with a variety of different connection elements. It is understood that the above building element merely serves as examples of possible building elements.

Fig. 3 illustrates visual representations 301 -303 of the building element of fig. 2 corresponding to three different versions of representations of the building element, the versions having respective LODs. As can be seen from fig. 3, in addition to an increase in level of detail, the different versions of the building element are also shown with different display parameters. For example, the version 303 of the building element includes a logo on each knob. Furthermore, in versions 301 and 302 the edges of the building element are shown as black lines rather than as rounded edges as in version 303, as can be seen by comparing e.g. edge 304. It is an advantage of embodiments of the method described herein that the level of detail and the file size of the model representations may be adapted to the different development stages. In particular, a model description at the highest level of detail used in a development process may well require file sizes that are a factor of 10 or more larger than the file sizes required by representations at lower LODs used in other developments stages.

A virtual building element model may comprise a plurality of different building elements of different shapes, sizes, colors, ornamentation, material, and/or the like. A digital representation of a virtual building element model may thus comprise a suitable data structure, e.g. a list or hierarchy of data records, where each data record identifies one building element, including an identifier identifying the type of building element, and information indicative of the spatial relationship of the building element relative to the model, e.g. by means of coordinates relative to a suitable coordinate system, by means of a hierarchical data structure, and/or the like.

Fig. 4 illustrates embodiments of a data structure for digitally representing a building element model. Fig. 4a illustrates a compact embodiment of a data structure for digitally representing a building element model independently of the version of the building elements to be used. The data structure 401 may comprise one or more data records 402 including global model parameters relating to the entire model. Examples of such model parameters include a model name, a name of a model creator, a program version number of the modelling application, a creation date, etc. The model data structure 401 further comprises a list 403 or other suitable structure of building element data records. In the example of fig. 4, the list comprises N data records "Building element 1 ", "Building element 2", ..., "Building element J", ..., "Building element N". The building element data records will also be referred to as objects. Each building element data record of the list 403 may be identified by an element ID and has the structure illustrated by the data structure 404 for "Building element J".

Each building element data record/object comprises a number of building element attributes 405 of a first type (in the following referred to as "dynamic attributes" or "shared attributes") indicating one or more attributes of the building element, such as color, texture, decorations, etc. A 3d-application may add attributes to such an object or change them, e.g. responsive to a user input, for example when the user moves a building element to a different location, changes the type of building element, and/or the like. The attributes may have different data types like integer, float, strings or even more complex types like arrays of data types or matrices and vectors. The attributes added by the 3d-application are called dynamic or "shared" attributes, because they are used to share information across different LODs of the element and are dynamically transferred during a change of the LOD. In particular, the dynamic attributes include a building element type ID, indicating an identifier identifying the type of building element; for the purpose of the present description this identifier will also be referred to as the DesignlD. In particular, when designing a building element model, the designer may choose building elements from a set of available types of building elements, each type being identified by a unique DesignlD. The DesignlD may uniquely identify some of the properties of the building element or type of building element. Further examples of shared attributes include the position and orientation of the object, a material-ID, e.g. an integer indicative of a unique ID of the material the building element should be made of, and a name (i.e. a string) for the element, the user can assign to easier identify the building element in a list representation of the scene. The dynamic attributes 405 may further include attribute data items representing the position and orientation of an internal coordinate system of the building element, respectively. The position and orientation of the building element may be defined by the coordinates of an origin of the internal coordinate system of the building element with respect to a global "world" coordinate system, and by the orientation of the internal coordinate system with respect to the global coordinate system. An example of a data format for storing building element models that includes a hierarchy of coordinate systems is disclosed in US patent no. 6,389,375.

The building element data item 404 further includes a version number 406 indicative of the LOD in which the building element is to be rendered. Additionally, the version number may be indicative of additional attributes of a second type (in the following referred to as "static attributes") associated with each LOD. Examples of static attributes will be described below. As described herein, a geometric description of the building element corresponding to the version number 406 is retrievable from a predetermined location; the location may be retrievable from a database using the version number and the DesignlD as an index. Similarly the static attributes associated with the specific version of a building element may be retrievable from the same or a different database using the version number and the DesignlD as an index.

Fig. 4b illustrates another embodiment of a data structure for digitally representing a building element model, suitable as an input for a suitable 3D- modelling application like Autodesk Maya, Autodesk 3D Studio max etc. The data structure 401 of fig. 4b has a similar overall structure as the data structure of fig. 4a, i.e. including one or more data records 402 including global model parameters relating to the entire model and a list 403 or other suitable structure of building element data records, where each building element data record of the list 403 may be identified by an element ID.

The data structure shown in fig. 4b differs from the data structure of fig. 4a in that the data structure for each building element is different from the structure 404 shown in fig. 4a, as illustrated by the data structure 414 of "Building element J". In this embodiment, each building element data record comprises a number of dynamic building element attributes 405 and a version number 406 as described in connection with fig. 4a. However, in this embodiment, the building element data structure 414 further comprises a geometric description 417 of the 3D shape of the building element, e.g. in the form of a polygonal mesh. The geometric description 417 describes the shape of the object in an LOD corresponding to the LOD identified by the version number 406.

The building element data structure 414 may further comprise a number of static attributes 418 associated with the version of the building element identified by the version number 406. Examples of static attributes include display parameters controlling how the building element should appear in a visual representation. Examples of such display parameters include an identification of areas of the building elements that should appear in a special way, e.g. in a special color such as black, in renderings, an identification of edges or other contours that should be drawn as black lines, areas of the building element where decorations should be shown in the visual representation, etc.

The above examples of display parameters are associated to respective parts of the building element, while other examples of static attributes may relate to the entire building element, e.g. attributes such as cost prize, weight, and or other production-related parameters that are of interest only during some development steps. Hence, even though shown as a separate block in fig. 4b, some or all of the static attributes may be stored as part of or associated with the geometric description 417 of the building element, e.g. as part of a data structure representing a polygon mesh.

Similarly, even though shown as a separate block in fig. 4b, some or all of the dynamic attributes may be stored as part of or associated with the geometric description 417 of the building element. For example, an object 414 representing a building element may represent a 3d-entity and have attributes like position, orientation, geometry for drawing the object on the screen, and optionally further dynamic and/or static attributes.

Since embodiments of the method and system described herein allows for an adding of new shared attributes, the system is extendable to future needs. If there is a need to maintain certain new information about an element, a new shared attribute can be defined and used.

It is understood that the above digital representations may be encoded in any suitable data or file format, e.g. as a binary file, as a text file according to predetermined modelling description language, or the like. It will further be appreciated that alternative or additional types of data structures may be used to represent a building element model. It will further be appreciated that the building element model may be represented by different data structures during different development stages and/or by different computer programs operating on the building element model. Furthermore, the data structure used as a file format for storing a building element model may differ from the internal data structure(s) used by the computer program(s) when processing a building element model. Examples of suitable data structures / file formats include the structure disclosed in US patent no. 6,389,375 known file formats used by 3D Graphics system, e.g. the Maya System by AutoDesk Inc., etc.

Fig. 5 illustrates an example of a computer-assisted production process. A typical development process can be split up in several steps. In the example of fig. 5, the production process comprises a design step 501 , an optimization/review step 502, a step for creating building instructions 503 (for end-users and/or for use during production), and a marketing and packaging design step 504. It will be appreciated that the process may include alternative or additional steps; and/or that some of the above steps may be merged and or performed in parallel and/or in a different sequential order. Furthermore, the development process may also include loops where the process returns to an earlier stage in order to revise the output of that earlier stage, e.g. when the optimisation step 502 results in a need or desire to change the design of the model, the process may return to step 501.

Each step may include the generation, manipulation, and/or use of a digital representation of the product by means of respective software entities executed on a data processing system, e.g. the computer system shown in fig. 1.

For example, the design step 501 may be implemented by a suitable interactive virtual construction system, e.g. a CAD system or a virtual reality modelling system, e.g. as disclosed in US 6,389,375. For example, an embodiment of a process of interactively placing a new virtual building element into a scene including a 3D structure is described in published International application WO04104811. Both documents are incorporated herein by reference in their entirety.

The optimisation/review step 502 may be implemented by the same software tool as the one described in connection with step 501 , or by a different tool. For example, a software tool implementing step 502 may allow a user to create different color-variations and/or other variants of the same model and compare how these variants compare to each other, e.g. how they differ in visual appearance and/or price, weight etc. The software tool implementing step 502 may further provide functionality for generating suitable representations (e.g. graphical representations, bills-of-material, and information on prize, weight and/or other properties of the model. For example, such information may be communicated to a customer of the model, thereby allowing the customers to be included in that process, so they can give feedback at an early development stage about the model before it is finalized. It may also be possible to build a model or a part of a model in a different way.

The step 503 of creating building instructions may be implemented by a suitable software application for generating visual representations of part models or another suitable software system. For example, a building instruction application may be adapted to read a digital representation of a model and to generate a building instruction from the read model data. The building instruction application may further provide a user-interface for displaying part-models according to a stored sequence of building steps, or any other suitable output format for the generated building instructions. The building instruction application may generate the building instructions in a suitable file format, e.g. in printable form or as a 3D animation. For example, the Internet publication "Designing Effective Step-by-Step Assembly Instructions", by M. Agrawala et al., retrieved from http://graphics.stanford.edu/papers/assemblyjnstructions/, describes design principles for effective assembly instructions based on cognitive psychology, and published international patent application WO 2005/124696 discloses an automated process for generating building instructions for a virtual building model.

Typically, a toy construction set may include printed building instructions or assembly instructions that illustrate how to construct a certain model from the building elements of the set. Typically, the building instructions enclosed in a toy construction set comprise a sequence of pictures illustrating step by step how and in which order to add the building elements to the model. Such building instructions have the advantage that they are easy to follow, even for children without great experience in toy construction sets and/or without reading skills. Similarly, assembly instructions are created for many other composite products, either for use during manufacture of the product or, when the product is sold and shipped unassembled, by the customer. It will further be appreciated that such assembly instructions may be created in a variety of different forms.

The production of marketing and/or packaging material (step 504) may utilise a suitable 3D Graphics system, e.g. the Maya System by AutoDesk Inc.

It is noted that the data processing system of fig. 1 may be configured to execute all or only some of the above processes. In some embodiments different ones of the processes may be implemented on different computers, each having access to the database 102 of building elements and the file storage 103 and operating on one or different digital representations 401 of the model.

Accordingly, as described herein, the computer program(s) (e.g. suitable client software) implementing or at least supporting the respective steps 501 - 504 may retrieve and/or store a digital representation 401 of the model from/to a a suitable data storage or data communication interface. For example, the computer programs may all have access to a file system, database, or other data storage where digital representations of one or more building element models are stored. As mentioned above, the computer programs have further access to a database 102 that may include a graphical definition of individual building elements in one of a number of possible LODs, or at least a reference, e.g. a pointer, filename, URL, or the like, to a storage location 103 where the actual graphical definition is stored. Consequently, the computer program(s) may generate visual representations of the building element model in different LODs and process a suitable version of the building element model. Preferably, the above programs implementing or facilitating steps 501-504 are adapted to accept the same or at least a compatible format of digital representations, and output the same or at least a compatible format of digital representations, thereby allowing the representations output by one step to be used in another step. Each of the steps may involve different requirements on the digital representation. For example, during the design step 501 , the designer may only work with a low-resolution representation of the model, since the visual aspects of the individual elements are not that important in this development stage compared to the right placement of the elements within the model. While creating the building instructions during step 503, however, the visual appearance of the elements may be more important, and therefore a different LOD with a more detailed, but still not photo-realistic, version of the element may advantageously be used. Finally, during marketing and packaging design it may be desirable that the elements should look like the real-world elements, e.g. when creating marketing material, animations, etc. Consequently, during step 504, the process may use a very detailed version of the elements for high-quality renderings of the entire model for boxes, posters, etc.

Furthermore, the different development processes may have different standards for how building element models should be visualised, .e.g. how contours such as edges are to be shown, etc. For example, for the design stage and the generation of building instructions, it may be desirable to generate a visual representation that allows a user to easily distinguish the individual building elements in a model. Similarly, the needs for additional product information may also be different during the respective development steps. For example, during the design step, the designer may require additional information about each building element, such as a cost prize, a weight, a production status, etc. in order to design the model according to given requirements or specifications. When creating marketing material and building instructions, on the other hand, such information may no longer be necessary. Hence, by adapting both the LOD and additional display parameters for visual representation and optionally also the number and types of additional attributes to the respective versions of representations of any given building element, the amount of data to be stored and processed in the respective development processes may be minimized. These needs may be accommodated by a system wherein each version of a building element not only has a respective LOD for visual representation associated with it but also a respective set of attributes such as display parameters for controlling the visual appearance of the building element and/or further attributes e.g. indicative of production-related data. Each version may thus be identified by a version number of other version identifier. For the purpose of the present description, each version may be identified by its LOD level. It will be appreciated, however, that in some embodiments, different versions of building elements with the same LOD may exist, where the different versions have different static attributes, e.g. different display parameters, associated with them. Accordingly, when the process proceeds from one of the development steps 501 -504 to another one, the computer system may change the version (e.g. as identified by the corresponding LOD level) of the building elements in the model to be developed. This update may for example be triggered by a user command. When changing the LOD of the building elements, the process requests new versions of the building elements whose LOD is to be changed from the database 102, and the database 102 delivers the requested building elements (or a reference to a location where the requested building element information is stored) in the requested LOD to the requesting process. The central database 102 may thus contain all available building elements in all available LODs, as well as attributes associated with each element, such as special production data that can be used in combination with the element by the client-software, and pointers to geometry definition files stored in a file storage 103.

The overall system may further implement a separate process 505 for generating different versions of a building element, e.g. when a new building element has been developed and is added to the pool of available building elements. For example, the process may receive information about a new type of building element in the form of 3d-data. In the case of moulded building elements, e.g. made from plastics, the 3d-data may define the mould to be used for producing the building element. Based on this input, the process generates different versions of the building element with the corresponding attributes and saves the generated versions into the database/file-storage. For example, the generation process of new elements can be done with any suitable 3D-modelling application like Autodesk Maya, Autodesk 3D Studio max etc.

Fig. 6 shows flow diagrams of embodiments of methods for generating a visual representation and for changing the LOD of a digital representation of a building element model, respectively.

Fig. 6a shows a flow diagram of an embodiment of a method for generating a visual representation.

The process receives a digital representation 401 of the building element, e.g. a digital representation of the type described in connection with fig. 4a. In step 610, the process initialises an output data structure, e.g. an output file 630 for accommodating a representation of a scene including the model and suitable as an input for a suitable 3D-modelling application like Autodesk Maya, Autodesk 3D Studio max etc. It will be understood that apart from the building element model, the scene may further comprise other objects, e.g. a 3d-world the model is positioned in. For example, the output file may have a structure as shown in fig. 4b.

The process then loops through all building element records of the digital representation 401 and adds the respective building elements to the file 630. In particular in step 611 , the process obtains the DesignlD or another identifier uniquely identifying the type of building element from the input representation 401. The process further obtains the desired LOD, e.g. from the input representation 401 , as a user input, and/or the like.

In subsequent step 613, the process queries database 102 for a filename of (or other reference to) a graphics file corresponding to the building element with the obtained DesignlD and the desired LOD. Database 102 has stored therein information about all available building element types. In subsequent step 614, the process retrieves the identified file from data storage 103 and imports the geometric description from the file as a new object into the scene. As described above, objects represent 3d-entities and may have attributes like position, orientation, geometry for drawing the object on the screen. In a scene all elements are typically stored with different orientation and position. Importing may thus include opening a file that contains 3d-data (e.g. triangles or polygons) representing the element to be added to the scene so as to "appear" in the 3d-world, and adding the element to the scene at a predetermined initial position, e.g. an origin of a coordinate system, the centre of the 3d-world or the like.

In step 615, the process copies all dynamic/shared attributes of the corresponding record in the data structure 401 into the newly imported object. For example, copying the position and orientation attributes results in the newly added object to be positioned at the correct position and in the correct orientation. Additionally or alternatively, some dynamic attributes associated with respective types of building elements may be stored in the database 102 indexed by the DesignlD. An example of such a dynamic attribute may be a material-ID or the like. Alternatively or additionally, attributes related to respective types of building elements and only required during certain development stages, e.g. cost prize, weight, delivery times, and/or production-related data may be treated as shared attributes stored in the database 102 which are only retrieved in response to a user request or a request from a software application, e.g. when creating bills of materials, calculations of the total weight or prize of the model, etc.

In step 617, the process controls (e.g. by executing a program) the visual appearance of the building element based on the shared attributes. For example, when a building element is imported into the scene it does not have any material associated to it. The material is defined by one of the shared attributes referred to as material-ID. Hence, in step 617 a program selects the shader for the 3d-geomertry according to the shared attribute that defines the material for the building element. For example, if a building element has a material-ID indicating that the material is a dark grey plastic, a predefined shader corresponding to this material-ID is assigned to the 3d-geometry of the object for simulating the look of "Dark grey" plastic in the scene. Another example includes applying of images to parts of the geometry to simulate decorations such as stickers.

In step 618, the process determines whether all building elements have been processed. If this is not the case, the process returns to step 611 so as to process the next building element; otherwise the process proceeds at step 619.

In step 619, the process generates a graphical representation of the scene from the output file 630. For example, the process may generate an output file 631 in a suitable file format, e.g. a PDF file suitable for viewing, printing or otherwise reproducing an image of the scene including the building element model.

Hence, the above example provides a process that generates a visual representation from a compact, LOD-independent digital representation such as the one shown in fig. 4a. It will be appreciated that other examples of the above process may receive a digital representation as an input that already includes 3D geometry data, e.g. the the data structure shown in fig. 4b. If the process receives such a digital representation including building elements in the desired version, the process may generate the graphics output 631 based on the received representation alone, i.e. without having to obtain data from the database 102 and the file storage 103. Otherwise, if the input representation includes building elements in a different LOD, the version of some or all of the building elements may need to be updated.

Fig. 6b shows a flow diagram of an embodiment of a method for changing the LOD of a digital representation of a building element model. As described above, a change in LOD may be triggered by a user command, thus providing the user with control over which representation and attributes to use. The user of the computer program implementing or facilitating one or more of the product development steps may trigger the process of updating the LODs by selecting the building elements to be changed and the new LOD which the selected building elements should be updated to. For example, the selection of building elements may be performed by a suitable operation with a pointing device, e.g. by clicking on individual building elements and/or by drawing a box around the building element(s) to be selected, and/or by issuing a "select all" command.

For every selected building element, the computer program may then execute the process illustrated in fig. 6b. The process receives as input an identified building element and a desired LOD level. As described above, the identified building element is represented in the model 401 by a data object, i.e. a data structure representing the geometry of the building elements and a number of attributes. As is described herein, the attributes may comprise static and dynamic attributes. The object representing the version of the element currently included in the model is also referred to as the current object. In the example of fig. 6b, it will be assumed that the process operates on a digital representation 401 as shown in fig. 4b, e.g. accessible to th process in internal or external memory of the computer system 101. The digital representation 410 may include the building element model alone or as a part of a larger scene including other objects, e.g. a 3d-world the model is positioned in.

In initial step 601 , the process obtains from the digital representation 401 the DesignlD of the building element whose version is to be updated, or another identifier uniquely identifying the type of building element.

In subsequent step 603, the process queries database 102 for a filename of, or other reference to, a graphics file corresponding to the building element with the obtained DesignlD and the desired LOD. Database 102 has stored therein information about all available building element types. In subsequent step 604, the process retrieves the identified file from data storage 103, and imports the geometric description from the file as a new object into the scene represented by the digital representation 401 . In a scene all elements are typically stored with different orientation and position.

The importing step may thus include opening a file that contains 3d-data (e.g. triangles or polygons) representing the element to be added to the scene so as to "appear" in the 3d-world, and adding the element to the scene at an initial position and orientation. The initial position may be the center of the 3d- world.

In step 605, the process copies all shared attributes from the old object which is to be replaced by the imported new object to the new object. Copying the shared attributes includes iterating over all shared attributes of an existing object and copying their information to the new object (the replacement for the first one). This way it can be assured that all necessary information is kept throughout the entire development process.

In step 606, the process deletes the old object. As the static attributes associated with the old object are not copied from the old object to the new object, they are deleted together with the deletion of the old object. Hence, as the static attributes are only useful (e.g. because they are related to the actual mesh in the given LOD) or desired in connection with a certain LOD, deleting them reduces the file size of the updated LOD, where the old static attributes are no longer needed. If, for example some identified (e.g. enumerated) faces of the geometry in one LOD are marked as having a predetermined property (e.g. marked as a decoration area where a user can attach a sticker), the same area may correspond to a different face list in a different LOD.

In step 607, the process changes (e.g. by executing a program) the visual appearance of the building element based on the shared attributes, as described in connection with step 617 of fig. 6a above. Fig. 7 illustrates another example of a data structure representing a building element. The building element data structure 404 has a set of attributes associated with it. In particular, the building element data structure has a set of static attributes 406 and a set of dynamic attributes 405 associated with it. The static attributes 406 depend on the LOD, i.e. the static attributes change together with the LOD, as is illustrated in fig. 7 by three LOD levels designated LOD1 , LOD2, and LOD3, respectively, corresponding to the LODs 301-303 shown in fig. 3. Accordingly, the version LOD1 of a building element has the static attributes 704 associated with it, the version LOD2 of a building element has the static attributes 705 associated with it, and the version LOD3 of a building element has the static attributes 705 associated with it. The static attributes are saved associated with the LOD of the elements, e.g. in the geometry description file stored in the corresponding file stored in file storage 103, and are not shared between all LODs. The static attributes 406 may thus be LOD-specific (e.g. an identification of parts of the geometry that should be treated in a special way) or they may only be needed in a specific development step (e.g. the weight of the element). The dynamic attributes 405 are shared throughout all stages of development and describe the final appearance of the element. Examples of dynamic attributes include the DesignlD of the element, the position and orientation of the building element in the model, color configuration of the element, applied decorations, and/or the like. Yet another example of dynamic attributes includes information about a hierarchy of a model, e.g. a hierarchical grouping of building elements into parts of the model. For example, if the model represents a figure, it can be grouped into e.g. a head, a body, a left arm, a right arm, a left leg, and a right leg. These groups can further be divided into other groups, f.x. the "left arm" can have a sub-group called "forearm" and this can have a sub-group "hand" and so on. If the LOD on an element is changed, the process ensures the imported elements are placed correctly in the model's hierarchy. In the example of fig. 7, the LOD versions 704-705 of an element have respective attributes associated with them indicative of the visual appearance of the building elements. In particular, in this example, the LOD1 and LOD2 versions each have an attribute associated with it causing a drawing process to show the building elements with edges shown as black lines. The LOD2 version further has an attribute associated with it causing a drawing process to show the side faces of the protrusions of the building elements in black. The LOD3 version has an attribute associated with it causing a drawing process to draw the protrusions as separate objects, thus allowing the process to delete protrusions from the scene that are invisible. Examples of different visual appearances of different versions of a building element are shown in fig. 3.

When an element is added to a model, e.g. by a computer-implemented construction tool or other interactive virtual modelling application, the process assigns an element-ID to this geometry that identifies the element, even when its LOD is changed. Hence, the element-ID is another example of a dynamic/shared attribute. As described above other dynamic attributes of the elements may need to be transferred during the LOD change, e.g. the description of which material to use or which decorations to be applied to the element in production. LOD-specific (i.e. static) attributes, on the other hand, may get automatically deleted during an LOD update.

Fig. 8 shows a block diagram illustrating an example of the process of loading an LOD version of a building element. In particular, fig. 8 shows two software modules executed on the computer 101 : A server application 810 and a client application 811. The client application 811 may be a 3D application providing a user interface and functionality facilitating one or more of the development stages of a product development process as described above. For example, the client application may be a 3D application for generating, manipulating, and/or viewing visual representations of the building element model, e.g. based on a digital representation of the building element model e.g. as described in connection with fig. 4. The client application is in communicative connection, e.g. via a socket interface, with the server application 810. The server application provides functionality and services to the client application, e.g. database access, rendering, etc. The server application is in communicative connection with the database 102 and the file storage 103. The client application is in communicative connection with the file storage 103. The 3D-Application 811 may initially retrieve a digital representation of the building element model, e.g. a digital representation as described in connection with fig. 4. The digital representation may include a representation of the geometrical shape of the individual building elements, as described in connection with fig. 4b. However, in other embodiments (e.g. as shown in fig. 4a) the received digital representation may not include such a representation, but only a reference thereto in the form of a version number. In other situations, the digital representation may include a representation of the shape of the building element in a different version than the one requested by the user. Hence, in the above situations the 3D-Application may need to obtain the representations of one or more of the building elements in the desired LOD in order to generate a visual representation and/or in order to replace an existing representation of the building elements in the model by the desired version. An embodiment of the such processes was described above in connection with fig. 6.

A process of getting and loading an element in a requested LOD by the 3D- Application for generating a visul representation or for replacing the current version of the element by a different version will now be described with reference to fig. 8. The process may be split up in 5 steps as indicated by arrows 801 -805 in fig. 8:

Step 801 : The 3D-Application 811 communicates over a network socket with the server application 810 and requests the filename of the version with a given DesignlD and LOD. Step 802: The server application 810 sends a query to the database 102 where the filename is stored, and receives a corresponding response including the requested filename.

Step 803. After receipt of the response from the database, the server application 810 retrieves information about the file from the file-storage, e.g. the file size, file date, etc.

Step 804: The server application 810 sends the collected information back to the 3D-application 811 as a response to the request of step 801. Step 805: The 3D-application 811 may now access the file-storage 103 directly and open the file from there.

The file-storage may be any kind of remotely accessible storage like SMB or NFS-shares. For example, the versions of the building elements may be stored in a conventional directory structure, e.g. where each element is stored in its own directory. This directory may be named after a unique ID for the element-LOD combination retrieved from the database 102 when the element is created and uploaded.

Fig. 9 shows a block diagram illustrating an example of the process of providing a new version/LOD of an element. The system architecture shown in fig. 9 is the same as the one shown in fig. 8. However, it will be appreciated that the client application may be a different application, e.g. a specific application for designing new building elements and creating geometry specifications thereof. Examples of such an application include any 3D-Modeling application like Autodesk Maya, Luxology Modo or Robert

McNeel & Associates Rhinoceros 3D.

A process of adding a new geometry in the system will now be described with reference to fig. 9:

Step 901 : The 3D-application 811 generates and saves the new geometry definition, e.g. on the local hard disk, and sends a request to the server application 810 including the filename of the new geometry definition as well as information about the corresponding LOD and the designlD. Step 902: The server application 810 sends a query to the database 102 asking for a new unique ID for the file. The server application receives the file ID as a response.

Step 903: The server application 810 stores the generated file on the file- storage 103 using the recived unique file ID. For example, the file may be stored into a new folder named like the unique ID of the file.

All geometry files may be stored in a suitable file format compatible with the 3D graphics applications that are to use the files, for example in a "mayaBinary" file when the Autodesk Maya program is used.

In summary, described herein is a memory-efficient computer-implemented method and system for constructing even very big products out of large numbers of individual components/elements, while still providing all information (also visually) required during different stages of a development process.

The method and system described herein provide an easy update of elements in models when the element itself has changed. Every model can thus be kept updated by updating the elements. With this system it is even possible to have different elements of different LODs in the same model. This may be advantageous during rendering in order to save memory and rendering time. Elements close to the camera may thus use a more detailed LOD than the ones far away.