WO1996023280A1 - Modelling and analysis of systems of three-dimensional object entities - Google Patents

Abstract

The invention provides the user a tool for real time modelling and analysis of a system of three-dimensional objects wherein behaviour characteristics can be associated with each object and the interaction between objects can be analyzed. The tool comprises: means for establishing for each such object entity, a discrete representative object in data form; means for displaying said representative object in graphical form; means for associating with each object entity a value for each of a defined set of parameters relevant to the system; means for associating with each object entity instructions enabling that object to interact with other object entities and, through the display, with the user; and means for interpreting and processing said instructions associated with a particular object entity.

Description

MODELLING AND ANALYSIS OF SYSTEMS OF THREE-DIMENSIONAL

OBJECT ENTITIES

This invention relates to a tool for and method of modelling and analysis of a system of three dimensional object entities, especially where such entities interact.

The invention might find use, for example, in any application in which data can be expressed as three dimensional graphics. One such application could be molecular modelling. Another application could be a virtual library with shelves of books which can be represented graphically and with each book individually accessible. Again, the invention can be used for scientific visualisation of data in 3D form such as 3D scattergrams or histograms. It may also be used as a 3D front end to spreadsheets or databases to allow data manipulation by a user through interaction with graphical representations of the data. Another use could be in spatially related searches such as a 3D geographic information system. The invention could have another application as a tool for writing and playing computer games. Particularly, the invention finds useful application in design; it addresses particularly many of the problems encountered in the area of architectural design.

In the area of architectural design, the design, construction and management of the built environment through its life cycle brings a large and varied group of organisations into contact. Although all are concerned with the same physical design, each have their own views of the object at hand, their own representations and tools for dealing with it and their own domains of expertise which are brought to bear on its evaluation. Even within each discipline individuals appear to use different modes of working. Essentially, the built environment sector has evolved this division of labour as a means of handling the complexity and apparent indeterminacy of its subject matter. By bringing together different approaches and knowledge domains based on fundamentally different world views more complex problems can be tackled than when a team is composed of people who share the same approach or view. However, as the size and complexity of projects has increased and project time scales have decreased, the organisational divisions implied by this system have become a source of problems in their own right. Architectural design itself, where problems are often ill specified and designs are carried out by those who do not necessarily have complete knowledge of the client's domain in exactly this way, provides a possible model. Here a form of working has evolved in which the definition of the brief emerges as the design is developed. As often as not the lay client is unable to provide more than a sketch statement of intent at the start of a project. The brief itself is often developed by the design team and forms one of the key negotiating documents in the design process in which the client is asked to "sign up" to a design strategy in "physical" sketch form as well as a brief, textual description of the functional requirements the design is aiming to fulfil.

Whether or not a specific physical design fulfils those functional requirements is a matter for analysis and this is where the different domains of knowledge encompassed by the design team come in. Design iterates between those two activities. In the first designers generate form - "a round building" - in the second they criticise the form from a number of standpoints - "high volume to surface area ratio means low energy gains and losses - good", "round buildings are tricky to construct - costs more", and so on. Engineers and other specialists know a lot about the effects of a proposed form for the outcomes in terms of their domain of knowledge, and a lot of this knowledge is systematised in terms of calculations, rules of thumb and analytic computer packages. The problem is that many of these analyses need the specialist to interpret their results, and so the form in which the software is produced tends to reinforce the divisions in the team. It is possible that by using graphical visualisation methods these techniques of analysis could be brought into the designer's frame of reference, not as a set of analytic results, but as a part of the medium the designer is manipulating during the synthetic and creative "form generating" phase of work.

It is an object of this invention to provide improved tools which by bringing more of the analytic potential of computing into the intuitive ambit of the "form generation" activity, enable design intuition to be harnessed to produce not only innovative forms, but innovative solutions to complex inter-domain functional problems of the sort that have proven virtually intractable to current techniques. Accordingly, the present invention consists in one aspect in a tool for modelling and analysis of a system of three dimensional object entities, comprising means for establishing, for each such object entity, a discrete representative object entity in data form; means for displaying said representative object entity in graphical form; means for associating with each representative object entity a value for each of a defined set of parameters relevant to the system; means for associating with each representative object entity instructions enabling that object to interact with other representative object entities and, through the display, with the user; and means for interpreting and processing said instructions.

Hence the present invention can provide the user with a tool for real time modelling and analysis of a system of three dimensional object entities in which behaviour characteristics can be associated with each object entity and the interaction between object entities can be analyzed. Changes to the system can be undertaken in real time without restarting the tool. Hence processing of data can be simplified and speeded up.

In the description of the present invention "parameters" may be referred to as "attributes"; and "instructions" comprise "scripts".

The establishing means can enable not only the creation but also the deletion or modification of object entities.

Preferably said instructions comprise intermediate level code. This can speed up the time needed to interpret the instructions whilst at the same time cutting down the memory and processing time needed to compile the instructions from a high level code.

Advantageously said instructions further include high level code and said tool further comprises a compiler for compiling said intermediate level code from said high level code. This can allow a user to use the tool without the need to be familiar with standard computer languages. Furthermore it can eliminate the need to use separate compilers which would complicate the procedure and require specialist knowledge.

Suitably said compiler can compile more than one high level code, and preferably also said high level code may be more than one type of high level language. This feature allows users of mixed experience to use their preferred language.

Advantageously object function means are provided for performing a function with respect to an object entity.

Preferably there is provided means for establishing an application entity comprising each such object entity and whereby all object entities are below the application entity in a hierarchical tree.

Preferably there is provided application function means for performing a function with respect to the application entity.

Preferably there is provided means for establishing a document entity comprising a group of such object entities, and wherein said application entity comprises all document entities, said object entities in the group are below the document entity in the hierarchical tree and all document entities are below the application entity in the hierarchical tree.

Preferably there is provided document function means for performing a function with respect to a document entity.

Preferably there is provided means for associating with the application entity and document entity instructions enabling that entity to interact with other entities and, through the display, with the user; and means for interpreting and processing said instructions associated with a particular application entity or document entity.

Preferably the instructions comprise: event instructions for instructing said means for interpreting and processing to send respective events to an entity; and event handlers for instructing said means for interpreting and processing to respond in a particular manner to a corresponding event sent from another entity; whereby when an event is sent to an entity the means for interpreting and processing is initiated with respect to instructions associated with said entity and, if present, the corresponding event handler is interpreted and processed. In the description of the present invention an "event" may be referred to as a "message".

Preferably there is provided forwarding means whereby if an event handler is not present in the instructions of said particular entity, it will, if possible, forward the event to a higher entity in the hierarchical tree.

Preferably if the event handler is not present in the instructions of said particular entity and the event does not correspond to any of said entity's function means, it will, if possible, forward the message to a higher entity in the hierarchical tree.

Preferably the instructions further comprise instructions to handle events sent from an external entity, said external entity not being part of the tool; and said instructions further comprise instructions to send events to such external entities.

Preferably there is provided means for establishing a group entity comprising object entities selected by the user whereby an object entity may only directly belong to one group entity.

Preferably an object function performed on the group entity is performed on all the object entities.

Preferably there is provided means for establishing a collection entity comprising one or more object entities selected by the user whereby an object entity may belong to more than one collection entity. Preferably there is provided means for establishing a camera entity, and said display means is adapted to display a representation of the view from the camera entity. Preferably said camera entity is an object entity.

Preferably there is provided user input means for initiating said means for interpreting and processing with respect to instructions associated with a particular entity.

According to another aspect of the invention there is provided a method of modelling and analysis of a system of three dimensional object entities, comprising: establishing, for each such object entity, a discrete representative object entity in data form; displaying said representative object entity in graphical form; associating with each object entity a value for each of a defined set of parameters relevant to the system; associating with each object entity instructions enabling that object entity to interact with other object entities and, through the display, with the user; and interpreting and processing said instructions associated with a particular object entity.

According to a further aspect of the invention there is provided a tool for modelling, analysis and measurement of a system of three dimensional objects, comprising means for establishing, for each such object, a discrete representative object in data form; means for displaying said representative object in 3D form; means for associating with each representative object a value for each of a defined set of parameters relevant to the system, and means for associating with each representative object instructions enabling that object to interact with other representative objects and, through the display, with the user.

Preferably, there is provided means for establishing two or more collections of representative object entities, each collection preferably representing a behavioural aspect of the system such as structural behaviour, thermal behaviour or acoustic behaviour, and each object entity possibly existing in more than one collection. Preferably means are provided for addressing objects of a selected collection.

Preferably there are defined categories of objects, one of said parameters comprising a label identifying the category to which the object belongs.

In one important form of the invention, means is provided for inferring the category to which a newly defined object entity should belong from the shape and from any parameter values which have been defined by the user.

The features of this aspect of the invention may be applied to the preceding aspects, and vice versa.

The present invention extends to a computer when programmed with a tool as aforesaid.

Preferred features of the present invention will now be described, purely by way of example, with reference to the accompanying drawings in which:

Figure 1 shows computer apparatus incorporating a tool according to the present invention;

Figure 2 shows a hierarchial relationship of entities;

Figure 3 shows different communication relationships between an object entity and other entities;

Figure 4 shows relationships of a collection entity; Figure 5 shows a typical window of the tool;

Figure 6 shows a schematic window of the tool including some embedded features;

Figure 7 shows a schematic relationship of script language to an intermediate level language; and Figure 8 shows relationships between different scripts. Referring first to Figure 1 there is shown, according to the present invention, computer apparatus which may be any personal computer, mainframe, minicomputer or laptop. It may be networked or be stand alone.

The computer apparatus comprises: a central processing unit (CPU) 100; memory 112 connected to the CPU 100; a video monitor (VDU) 104 connected to the CPU 100 for displaying output therefrom; an alphanumeric keyboard 102 connected to the CPU 100 for input thereto from a user; and a soft drive 106 and a hard drive 108 connected to the CPU 100 for storing and retrieving data from the memory 112.

The computer apparatus further comprises a mouse 110 connected to the CPU 100 for input thereto from a user. Movement of the mouse 110 produces signals received by the CPU 100 and further signals are generated by pressing (or clicking) on a button or buttons 111 on the mouse 110. The VDU 104 and the mouse are part of a graphical user interface (GUI) used in many well known systems. In particular, the CPU 100 generates a cursor 122 on the VDU ; the position of this cursor is movable either by keys on the alphanumeric keyboard 102 or by the mouse 110. It is used, where appropriate, to represent items, functions, and options as graphical objects such as icons and buttons (see Figure 6). The item, function or option is selected by moving the cursor 122 (by corresponding movements of the mouse 110) over an icon or button and clicking the mouse button.

Although terms such as 'clicking' and 'mouse button' are employed, the present invention is not limited to any specific interface tool and includes variants such as tracker balls, pointers and the like.

The memory 112 stores, amongst other things, an operating system and an application 10 according to the present invention.

The various sections below describe the features of the present invention, beginning with the overall structure of the application in which the invention is embodied. The various features described below can be provided by the invention independently of the other such features, or in any appropriate combination.

ENTITY STRUCTURE Figure 2 shows the overall structure of the application according to the present invention in terms of entities within the application. It shows how major entities within the application relate to one another. Each entity is named and arrows depict direct relationships of the entities. The highest entity is the application entity 10 of which there is only one. This entity 10 is permanent and it cannot be deleted while the application is in use. The other entities are an object entity 14 and a document entity 12 which are dynamic entities arising as a consequence of using the application.

The application 10 has means 50 (see Figure 6) to establish 1 to n document entities 12. The concept of a document arises from standard application design practices. For example, a 2D drawing package application may allow several sets of drawings (i.e. documents) to be edited, though the application 10 is only running once on the computer. With respect to the application 10, a document entity 12 does not consist of pages of drawings, but a 3D world. The application 10 may be executing in memory, but no document entities 12 are present. The number of document entities 12 is depicted in Figure 3 as O...n where n > O. Each document entity 12 has one 3D world associated with it.

Specifically in relation to architectural design, when a new document 12 is created by the application 10 on the user's request it has two object entities already established representing ground 42 and a camera 44. The view of the document is rendered from the position of the camera entity and this is described later. The ground entity 42 is analogous to a new document in a 2D drawing package having one blank sheet of paper. Means 52 are provided to establish and edit an object entity 14 having a physical representation in the 3D world, i.e. primitives, such as boxes, cylinders, spheres, implemented using polygons in 3D. The shape, position, size and colour are edited using said means. ATTRIBUTES

Referring to Figure 6, means 54 are provided to establish attributes (parameters) 18 for an object entity 14, i.e. physical or conceptual properties associated with the object 14. Such attributes 18 are name-value pairs. That is, each attribute 18 is defined by a name, distinguishing the attribute 18 from others, and a value of arbitrary type. The number of attributes which can be assigned to an object entity is only limited by the memory of the system. Different object entities can have different numbers of attributes. Examples of the default attributes 18 are the object's unique identification number, which has a text string value. Another example is colour which may have a more complex value, consisting of three values, one for each red, green and blue component, as commonly used in computer graphics systems. In general, all values are stored as text strings which are interpreted by some entity. Default attributes 18, such as the identification number or colour, are required by the application for a range of tasks including editing and displaying an object entity.

Access to attributes can be implemented by storing them as two strings. The scripting language can assume that any entity (even numerical values) are strings. A table of attributes can be stored in C++, for example, using linked lists of objects which store the textual name and value. Any agents which require access to these, such as the rendering system for an object's colour, can access them by specifying the name to a function which returns the attribute's value by searching the list of attributes.

SCRIPT to SCRIPT MESSAGES

To facilitate the construction of "Intelligent" entities, which can communicate with other entities, each entity is associated with at least one set of instructions 16 which includes a high level language part such as a script language programmed by a user.

The application comprises means 56 for establishing and editing said instructions 16.

The instructions for a particular entity also include an intermediate level language part compiled from the high level part. This is the part which is interpreted and processed. The instructions 16 enable an entity 10, 12, 14 to have a behaviour associated with it when it interacts with other entities 10, 12, 14. A script 10 includes instructions to send messages 24 and instructions to interpret messages 26 which are termed herein "handlers". An example of a handler is a size handler which calculates the size of a particular object. In the present claims the term "event" connotes a "message".

Figure 3 shows the various communication paths available to an object entity 14 when its instructions 16 are being processed. It may send a message to itself, for instance, so that, say, a size handler in the script which recognizes the message can calculate its size. It may send a message to another object entity 15, for instance so that a size handler in the script of the other object entity 15 can calculate its size and send the result back as a message to the originating object entity 14. It may send a message to a document entity; for example, the document entity 12 may have instructions to calculate which object entities are above a certain size and send identification codes of said object entities back to the originator. It may send a message to the application entity 10 to locate the largest object in any document. Finally, as shown in Figure 3 it may send a message to an external application 38 such as a database or spread sheet. This is described latter.

Hence a message can be sent from one entity to another entity to perform some user defined function. To perform the function, however, the latter script must contain the appropriate handler. Therefore messages can be sent by the object entity to itself (activating other handlers in the script), to any other object entity script, to the document script or to the application entity script.

Messages can also be directed at the user by changing, for instance, the colour of an object entity on the VDU. Messages may be displayed as text directly on the VDU and can ask the user to respond in some way.

EMBEDDED FUNCTIONS Embedded functions 28 are predefined and associated with a particular type of entity such as objects 14, documents 12 or the application 10 (see Figure 6). Such embedded functions 28 are object level functions, document level functions and application level functions. Examples of object level functions are move, rotate, scale and colour as applied to a particular object entity. Examples of document level functions are establishing and editing an object 52, copying objects, establishing and associating attributes 54, establishing and associating scripts 56 and grouping objects into groups. Collections are described later. Examples of application functions are establishing 50, opening, closing, saving, and deleting a document and communication with external applications (described later). The embedded functions 28 may be initiated by messages from scripts, or most can be initiated directly by the user by use of the mouse 110 on menus or icons.

THE SCRIPTING LANGUAGE

The scripting language is the means by which all object entities in the application have their behaviours defined. It is a high level language designed to incorporate the concept of objects and in particular 3D objects, not just text and graphics. Using an Object Orientated paradigm 'events' or 'messages' are sent between entities 10, 12, 14. In the scripting language, everything is an event, including commands in the language which are events sent to the application. Scripts contain the 'handlers' which are functions defined using the language which defines behavioural properties. For example an object entity can respond to a 'Mouse up' event from the application, meaning that the user has moved the on screen cursor over an on screen object entity and depressed and released the mouse button 111. A handler 'on mouseup' can be defined for the object entity which specifies what happens when this message is sent to the object entity. The structure of a message itself can be considered a 'name' followed by a text string, the name being that of the required handler.

The text string of a script represents source code in a supported language of which there may be several. For example if an object entity 14 is moved by the user, it receives a message "doMoved". If the language is based on HyperTalk (trademark, available from Apple Corporation, USA) it might look something like this: on doMove set the colour of me to white end doMove

If this object had moved then the colour of the object entity would be changed to white. Notice that "set the colour" is setting the attribute colour. Similarly, if the interpreter language was LISP the script would appear like this:

on doMove (setAttribute me 'colour 'white) end doMove

or in SmallWorlds Magik (trademark): on doMove self.colour « white end doMove

In the language C++, a class for scriptable objects can be defined which provides functionality required by such objects for scripting, such as storing a script itself, its parse trees and/or intermediate code, storing attributes for the object entity, and performing related functions. Classes for such object entities can then be derived from the scriptable objects class to inherit required functions. Therefore, classes for documents, buttons and so on can inherit functions for scripting.

THE COMPILER AND INTERPRETER

The application comprises a compiler 62 (see Figure 7). Once a high level script has been established by a means 56 for establishing and associating scripts 16, it is parsed and partially compiled by the compiling means 62 to an intermediate level code 36. An illustrative flow diagram is shown in Figure 7. This intermediate level code 36 is intermediate machine code and the scripting language of the user. The application comprises an interpreter 60 which interprets the intermediate code 36 into the machine code of the CPU 100. The script is directly associated with the intermediate code which is maintained for editing and for reference. Any changes to the script 16 are compiled to the associated intermediate code 36. The use of a compiler 62 to compile the high level script 16 into an intermediate code 36 allows much faster operation than a full compilation to machine code. This permits the application to run in real time and the user does not have to wait undue periods of time when he is defining his 3D world.

The code compiled by the system is somewhat language independent, allowing the incorporation of other high level languages, which compile to the format required by the interpreter. More than one language could be used simultaneously, such as C++ or Basic, customized for the application. The memory requirement for intermediate compilers is considerably smaller than for full compilers and so multiple compilers can be accommodated.

Currently when a message handler is found in an object entity's script class the text of the handler is passed to the compiler 62. There is only one compiler 62 for each language present in the system. The compiler is passed the text of the handler and is responsible for converting the text to an intermediate level code as a number of binary tokens 42.

Once created, the binary tokens 42 are associated with the object entity compiler and an "evaluate" message is called. Calls to embedded functions are encoded as strings (which are then passed as arguments to a doMethod function) with a number of binary expressions to evaluate arguments. Calls to attributes are also stored as strings which are then resolved at runtime via 'getAttribute' functions.

Dynamic Runtime linking is a compiler technology which allows separately compiled modules to be linked to the application while the application is running. Such a dynamic linking facility is provided in compilers such as gnu C++, MPW or in the Microsoft Windows 3.1 DLL environment. By providing access to runtime linking it is possible to treat compiled computational code as a library function which can be called from the scripting level. INHERITANCE

Means are provided for forwarding of an entity's message if the message is not recognised. The inheritance has a defined order as shown in Figure 2. When a message is sent to a particular entity, the interpreter 60 will attempt to execute an appropriate handler in the script of the entity. However if there is no handler within the script the message is forwarded to the level associated with the entity and the interpreter will attempt to execute an embedded function at that level for the message. For example, a message changing the colour of an object entity 14 may not be found as a handler in the object entity script 16 but may be found as an embedded function at the object level. However if it is not recognized at the object level as an embedded function the interpreter will pass the message on to the document level and so on to the application level. This forms a three level interpreting system. At each entity level the interpreter 60 attempts to execute a handler in the script of that entity but, if there is no handler, the interpreter attempts to execute an embedded function at the same level.

User defined scripts which are associated with documents are checked for handlers before performing any embedded functions provided by the document level. For example, an 'On Mouseup' handler can be written in the document script to perform, for instance, a colour change on all the object entities in the document. If an object entity is selected by the user and the mouse is clicked, the interpreter will search for an 'On Mouseup' handler in the object script. If this is not found the interpreter will search in the object level functions and if the handler is not found here the interpreter will search for it in the document script. Once found the interpreter will execute the colour change by sending messages to the object level functions in respect of all the object entities in the document. The interpreter will in turn execute the embedded object level function to change the colour of each object entity.

APPLICATION SCRIPTS As shown in Figure 2, the application 10 comprises a script 16. This can be written by the user, and is automatically executed when the application first loads and executes. This script 16 can send application level messages for certain requests. Application level messages include messages to create, delete, open, close and save a document. They also include messages to communicate with external applications using standard industry protocols and means are provided to perform these messages.

DOCUMENT SCRIPTS

Documents 12 also have a script 16. Such a script 16 is initially empty when a new document is created, but the script can be written by the user and is saved to the memory 112 when the document is saved. This script is automatically executed when the document is loaded into the application at a later date. The document script can send application level messages and document level messages to perform certain operations. Document level messages include making, editing, copying and selecting object entities, and grouping object entities as groups; means are provided to perform these functions and may be initiated by the user or by another entity sending a message to the document.

RESIZE EXAMPLE

Defining entity behaviour in terms of the entity's response to certain events or messages provides a rich tool kit for the development of complex, interdependent, interacting 3D environments.

One simple example in the area of architectural design is floor area calculation for architectural drafting applications. As an object entity is re-sized, a 'handler' in the script re-calculates the available area in real time. Another example of the re-size handler is a system which can insert floors as a building is stretched vertically.

Many other types of context dependent functionality can be developed, incorporating causal relationships, resulting in complex dynamic behaviour within the environment. Such systems can take advantage of facilities for importing and exporting information "on the fly" to external applications for services including real time analysis, logging, data access or external expert systems. EXTERNAL COMMUNICATION

An important feature of the application is the ability to communicate with external applications 38 (see Figure 3), such as spreadsheets and databases, in real time. Information can be exported for analysis externally, or imported for use in the application.

External message instructions are provided in the script language as application level messages. This allows an object entity to communicate with external applications using its script. The message arrow of Figure 3 is an "Inter Process Communication". This is implemented using the MicroSoft Windows (trademark) "Dynamic Data Exchange" (DDE) system for IBM PC compatibles, and through "AppleEvents" on Apple Macintosh (trademark) systems. Both are facilities within the operating systems. Other platforms could utilise similar facilities, such as UNIX "Pipes", the operating system independent REXX inter application communication language, Opendoc, or Microsoft "OLE". Specific data formats and protocols are required by external applications, such as spreadsheets and databases.

The means for external communication is provided in the platform to manage client server links to databases (both remotely via a LAN and locally on the same machine). Given that each geometric object would have a link to each data item in the database, the Attribute Manager would, in effect, provide a virtual database. There would be a link from an object entity to one or more databases via means for external communication. Once set up the system would not distinguish between inbuilt attributes (colour), local user attributes (room number) and items extracted from a remote database. In effect this gives the potential for full 3-dimensional functionality equivalent to current 2.5-dimensional Geographic Information Systems.

GROUPS, COLLECTIONS AND CLUSTERS

Most CAD systems incorporate the concept of a "layer" This is a conceptual grouping of elements of a design, used for separating related features. Commonly, they are used to simplify the amount of information presented to the designer, to abstract features of the design. Multiple groups (layers) are managed by the CAD application, and object entities within each design can reside in only one of these groups.

In the present invention means is provided to group object entities as a group and such a group may itself be an entity. Such a group entity has no physical representation, and can itself be part of another like group entity to form a hierarchy. Even though such group entities may have no direct physical representation, they consist of components that do.

In the present invention means are provided to collect object entities as a collection and such a collection 46 is an entity. Collection entities do not form hierarchies and an object entity may belong to one or more collection entities.

A collection of objects will have something in common. A collection is made, for example, of all the structural elements of a building, or a collection which contains a number of buildings with a common feature (like being next door to a residential building). A collection differs from a group, because the object entities can be moved around independently of each other and object entities can be in more than one collection. A collection can be saved separately from the rest of the model and imported into another world.

The present invention allows any 3D object entities to have multiple collection (set) membership. A document 12 can manage zero or more collections 46, as shown in Figure 4. Each collection can contain zero or more 3D object entities. However, these are not copies of the object entities from the document's 3D world. They are simply references to those object entities.

Scripts associated with various types of entity can communicate with the document level to perform high level operations on the collections associated with the document, such as creation or deletion of collections. Object entities within collections can be accessed for processing by the scripts. The advantage of multiple collection membership is that it makes a layering style system more than just an editing facility. For example, the case is considered where several analysis experts require only specific elements of an architectural (or other type of) design. Such elements can be placed in a collection, saved, and delivered in one dataset, without elements of the design which are irrelevant to the performance of their task. Due to the possible requirement of an object entity belonging to multiple collections, elements of the design required for more than one analysis may still be grouped.

Collections 46 may be managed by the user from the application's "3D editor". This editor allows the creation and manipulation of 3D object entities by the user in a document's 3D world. Selected object entities can be placed in collections, and removed using features supported by the application. Particular collections can be selected for display, omitting object entities in the 3D world which are not members of that collection.

Entities within the application may also manage collections. Figure 4 shows the data flow between a collection and an internal function. One example of this is a clustering algorithm. Given a set of criteria, the algorithm groups 3D object entities in the design, forming these groupings as in collections. Such functions can communicate with the document to create required collections. Other such functions can also exist which can function using collections for storage and retrieval. The ability to view only those object entities in a collection allows the user to configure collections as parameters to functions, and to view results easily.

Clusters of objects are similar to collections, apart from the fact that the collection is generated automatically by use of a cluster tool (not shown). The cluster tool automatically generates collections of object entities with similar attributes, and attributes can be selected by the user.

Collections can be derived from a scriptable object class when implementing using object orientated programming languages, such as C++ or Smalltalk. The collection itself contains a set of references (pointers) to 3D objects. This can be implemented using linked lists, or "Collection" facilities provided by development toolkits such as Liant's C++/Views, Microsoft's Foundation classes, or Rogue Waves (trade marks).

SCRIPTABLE TOOLS

The application allows the user to create tools for constructing, for instance, custom shapes. A tool is an entity with an associated script that can respond to events much like any other object entity. The user initiates the script by selecting the tool with the mouse cursor. The interpreter processes event handlers that track the path of the cursor 122 in the 3D world and particularly at certain positions along the path when the mouse is clicked. This path defines strategic points on the custom shape that are used by the tool to create a new object entity.

One example of this is to allow the user to create a new object entity having a profile that is rotated about an axis like a 'lathed' shape. By tracking mouse positions the user can define the profile and then the angle of rotation and the tool will do the rest.

Scriptable tools and their scripts are saved along with the document with any other object entities.

CAMERAS, LIGHTS and GRAPHICS

A 3D world can contain one or more camera entities 44. A camera entity 44 is like an object entity 14, and provides projections (usually perspective), to permit the visualisation of the 3D world. Each is associated with a 2D window into which the view is rendered by a rendering means (not shown). Such 2D windows are associated with the document itself and form the output via the VDU 104. As cameras are object entities in their own right, they also have attributes, and scripts. Means for creating camera entities are provided and are activated by the user or by sending a document level message.

Means is also provided for creating another type of entity called a light entity which is also initiated by the user or a document level message. The light entity can be a point source or an extended source. It simulates the lighting in a particular environment (for instance sun light or a room light). The light entity is an important feature required by the application for ray tracing.

Since the present invention is based around a 3D modelling capability, it is important to have a reliable 3D graphics system. Rendering is based upon a graphics subsystem (RenderWare by Criterion Software Ltd. (trademark)) but encapsulated in C++ classes (RenderWare is currently implemented in C). Such a set of C++ classes is then modified to support other graphics kernel systems such as Open GL or Renderman (trademark) while leaving the interface to the rest of the application the same. This allows the invention to produce high quality photorealistic non-realtime rendered pictures using Renderman simply by changing the renderer. Alternatively it would allow a machine specific renderer to be used, hence optimally using machine capabilities and so providing a high level of machine independent computing.

WHICH SPECIFIER

Of particular importance is the provision by the present invention of means for interpreting a "Which" specifier. Language commands which access object entities from collections may specify criteria for the conditional selection of object entities from those collections. For example, in a repeat loop, as well as specifying the collection whose object entities are to be iterated over, a Which condition can be specified at the same time. Criteria based on attributes can be stated using a postfix command "Has", for example Which Has <Attribute Name> of <Value>. Other types of postfix allow other conditions to be detected and used, including "Intersects", which takes another shape, and performs intersection tests. For example, in pseudo-code, a section of the program might be as follows:-

repeat for each shape in <Collection> which intersects shape <object name> ...Body Program... end repeat

Other types of Which include tests for 3D object entity enclosure, joining, and relative positions. Logical disjuncts (or), conjuncts (and) and inversions (not) can be included in a Which condition, for example, Which Has "Colour" of "Red" or Has "Colour" of "Blue". In place of Has, the following are possible: Encloses, Enclosed by, Ajoins, Above, Directlyabove, Below and Directlybelow. The English of the scripting language makes clear what the programmer intended.

Secondly the compiler can select a suitable Which operator, which can inspect the test which when executed can actually construct a temporary optimal data structure like a BSP tree (or use one if it exists inside the application already). Tests using binary trees are more efficient than ones using simple linear loops.

The advantage to the script editor is to have an efficient program without spending time writing complex data structures. If a more efficient method is used within the scripting language then all scripts would become more efficient. The use of efficient internal algorithms helps to compensate for the loss of a run time byte code system.

The Which operator has a number of functions which may be combined much like a query in a database language like SQL. For example, apart from spatial relationships it is possible to have attributes relationships. The following example of pseudo-code illustrates this:—

repeat for each shape id s which has an attribute "colour" of "1.0,0.0,0.0" set the attr "colour" of s to "0.0,1.0,0.0" — make red thing green end repeat

The Has filters work upon shape attributes either built in or user defined. Again these can be optimised by the use of databases like indexes to avoid searching object entities which do not have the appropriate attribute. Operators like "is" and "has" can be combined with "and", or "and not", to form complex spatial and attribute queries. This is illustrated in the following pseudo-code extract. repeat for each shape id s which -> has attribute "opacity" < "0.7" and -> — objects which are really transparent is intersecting shape id me — and inside this object, put "possible window at "&s end repeat

The byte code system built inside the application is based upon a C++ class. The compiler class takes a script string and compiles a lower level format from this (applying the above optimisation). This format is maintained in a cache so avoiding the overhead of recompilation each time the script is called. Lower level formats are compiled on demand whenever a script message is called. This along with a method for invalidating the code cache allows applications to be written at run time.

Object orientation makes it possible to derive a new class from a previous one. The utility of this is that a number of scripting languages can be implemented. For example it is possible to add a new class language to the application which would look like Basic or C++. The advantage is that the send message would allow scripts written in one language to be called from another. This helps to avoid the hostility of learning a new language. Each language would have to be capable of being sent messages like "on mouseup" and of passing them up the language hierarchy (from shapes to document to the application). The ability is also provided to modify each language to handle repeat for each item style operators.

In the preferred embodiment the application has two "languages" built into it, namely the Hypertalk (trademark) like language and an expression parser similar to that found in spreadsheets.

In summary, the Which specifier provides a means for selecting in real time efficient algorithms used in the compilation of scripts based on the syntax of the script.

OTHER FEATURES

Constructs within the program language are provided for flow control. For example, repeat and while constructs are provided, as well as if conditional execution constructs, as featured in most imperative languages. Means for interpreting mathematical expressions and logic operators are also provided.

Means for creating variables of several types are provided. These are global (so that they can be accessed by any script's handler), local (that is, those created within handlers, which are destroyed once execution of the handler is terminated), and object attributes (which can only be accessed by the object entity's handlers which created the attribute. These are not similar to an object entity's attributes, as they are destroyed once the document is closed, and are not saved to disk along with the 3D world, unlike attributes, which are.

The present invention also provides means for accessing members of a document's object collections. Such access can be defined in repeat style loops, allowing a section of program within the loop to operate on each object entity individually. For example, in pseudo-code, the section of the program might be as follows:-

repeat for each shape id s in <Collection> ...Body Program.... end repeat

Finally the object identifier for each object entity in the collection is placed in a prearranged variable.

ELECTRICAL DESCRIPTION

In operation, the computer apparatus is initially turned off. On power up the CPU 100 processes an embedded start up routine which includes a diagnostic check for hardware faults. If none exist the CPU 100 will load the operating system into memory 112 from the hard drive 108. An application 10 according to the present invention is then loaded into memory 112 from the hard drive 108 either as part of the start up routine or as a result of an operating system command from keyboard 102 or the mouse 110. On start up of the application 10 the monitor 104 displays no objects as no document or object entities exist. However the CPU reserves space in memory 112 for a document directory to store the numbers and addresses of documents. At this stage it is only possible to execute application level functions which are displayed on the VDU 104 as buttons or menus. The application functions are initiated by moving the cursor (by corresponding movement of the mouse) over the desired application level function button or menu and clicking. For instance, to create a document the create document button is clicked on. The CPU 100 detects the mouse signal and the position of cursor over the create document button and generates a create document event signal. This initiates means for establishing a document entity which are program instructions held in memory 112. The CPU 100 fetches the instructions from memory and processes them to create a document. Generally the CPU does this by assigning to the document entity space in the memory 112 at a particular address and storing the address in the document directory (also in memory 112). The CPU reserves memory space for an object directory in the document space so that the CPU can store identification numbers and addresses of object entities. A second and third document may be created in the same way.

Other application level functions may be initiated in the same manner as described. The document may be saved to hard disk 108 by initiating the program routine to send the data held in the memory at the address associated with the document.

When a document entity exists, document level functions are enabled and may be initiated by positioning the mouse icon over the desired function and clicking. Such a function is the means for establishing an object entity.

Already created with the document entity, in the area of architectural design, for example, is an object entity to represent the ground and a camera entity to provide the view into the 3D world. Generally the CPU establishes an object entity in a similar manner to establishing a document, by assigning the object entity a unique identifier and space in the memory 112 at a particular address and storing the address in an object directory located or linked to the document space (also in memory 112). To establish another object the button or menu representing the means for establishing an object entity is clicked on and a signal initiates the CPU to processes the establish object entity routine. A unique identifier and memory space are assigned as described above. Next an object shape is selected from the options of cube, box, sphere, cylinder and so on which are presented to the user as icons on the VDU. If the user clicks on the box option (say) the CPU stores a box identity in the object space and then processes a routine for determining the dimensions of the box. In this case the dimensions are determined firstly by assigning a clicked cursor position (in 3D) to a first corner of the cube and storing this in the memory 112 associated with the object. Secondly the user moves the cursor to a position representing the opposite corner of the cube and clicks the mouse to get the CPU to store the second position in memory. Thirdly the height is determined in a similar fashion. A second and third object entity may be created in the same way.

PROGRAM IMPLEMENTATION

The application is easily programmed with an object orientated paradigm such as the C++ computer programming language.

The implementation can be achieved, with reference to Figure 8, as follows.

All object entities present in the document are represented as computer objects; this list also includes normally non geometric entries such as cameras, flight paths and lights. Each object entity is derived from and is an expression of a class. The classes are organised in a pattern in which each class has a parent class holding information (member variables) and messages (routines or procedures); the parent class typically holds information which is similar across all child object entities. In this application the primary class is a "scriptableClass". The scriptableClass handles user extension of attributes (described below) and the conversation held with a compiler(s) object entities. This class also provides a number of messages which allow the C++ objects

to make visible the core C++ member data fields visible to the user scripting. For example, to allow the user to change an object entity's opacity from scripting the child class will override the setAttribute ("Opacity", value) message converting the value to a number then setting that number.

The other message which is key to the application is that of the doMethod ("name" arguments). This is provided in skeleton format via the scriptableClass. Subclasses override this message to incorporate new features to an object entity. For example, if the object entity understands how to move itself, it will override the domessage function for 'moveTo'. Methods are presented to access arguments, allowing the object entity to resend itself a pure C++ moveBy message. If a message is not understood (caught) by an object entity it is passed up the C++ message hierarchy. This permits commonly held messages to be provided by parent C++ classes; if a message is not caught by any child class it will eventually reach the scriptableClass doMethod. The scriptableClass provides some universal message handlers (such as sinQ Cos() and so on); if the messages are still not caught by the C++ system the scriptableClass looks though the object entity's script for a suitable message handler (ie. a matching 'on messageName' for each 'message') if one is found then the message is handled by the runtime 'compiler' (described below). If a message is still not caught (or the scripting language uses the 'pass' keyword) then the scriptable object gets the object which contains the current one.

Object entity containment mirrors inheritance; each shape belongs to a document entity and each document entity belongs to the application entity. Only the application has no parent and so the application catches all messages (defaulting to a 'message not understood' user alert). A shape may belong to another (for example a leg may belong to a chair group) the chair contains the leg and so also has a chance to catch a message sent to the leg, before the message is then passed up to the document level. This organisation allows both for simple internal maintenance on a per class level and a simple object entity containment message handling system for the userlevel scripter.

All classes in the application are derived from class Object. An important set of classes is called scriptableClass (see Figure 8). The application, the document and the object entity are all derived from scriptableClass. Support classes derived directly from class Object include tool, collection, and compiler. Derived from compiler are the specific interpreters which in the current application include a HyperTalk like compiler. Derived from class tool are the means for creating specific object entities such as cubes, spheres and so on.

EXAMPLE OF THE INVENTION - ARCHITECTURAL DESIGN The present invention provides an application 10 which is designed to provide a fluid interface for modelling 3-dimensional "worlds" and for navigating around them. This is achieved by using the cameras 22 with associated windows. Cameras 22 can be selected and moved either in a separate window in which both camera and the world are visible, or from within the camera's view itself - the "tank driver's body centric view". Cameras 22 also provide a simple metaphor for analysis. By linking a particular form analysis - say energy - to a camera, that view always carries with it the particular tools needed to construct and view an energy analysis of the design.

For instance, about 80% of the energy consumption of a building is determined in the earliest stages of a design when the buildings size, orientation, window to wall ratio, number of floors are defined. It is to aid the designer in the earliest strategic design decisions that a method like the Lighting and Thermal (LT) Method have been developed.

Such a method can be programmed in a script 16 to perform the calculations required on the size and shape of an object entity 14. The method may be in an object script if operating on one object or in a document script if operating on all the object entities 14 in the document. The script contains handlers that respond to a change in the shape or size of an object entity and then performs the calculation on the object entity with its new characteristics. The result is sent as a message to an external spreadsheet application 38 and is output to the VDU 104, for instance, by changing the colour of the object entity. As an example the colour of an energy efficient object entity may be red while an energy inefficient object entity may be blue so that the relative differences in the energy efficiency of the object entity can be visualised. If needed appropriate changes can be made to the object entity's shape and size as the application 10 allows the object entities, attribute data, and scripts to be modified interactively. The LT method may be applied to a group of object entities that form the walls, windows, doors and roof of a building, each object entity having attribute data defining its own particular thermal properties and other properties (mass, density, Young's modulus, colour, texture and so on).

The design of the LT method is based around the sketch design process and combines the results of heating, lighting and cooling analysis to construct a total picture of energy consumption.

Figure 5 shows a screen dump of a window which contains the controls and main outputs of the analysis. The primary inputs to the analysis are extracted from the geometry of the model. The primary results of the analysis are presented graphically as a pie chart representing the heating, lighting and cooling energy loads on the building, and numerically as a print out of the energy efficiency per unit area as well as total energy consumption. In this case the LT analysis and the graph and numeric feedback are all carried out in an Excell spreadsheet using Applied Events/OLE to link directly from the 3-D objects and supply the information on building geometry. The energy analysis can be put on automatic (recomputed every time an object entity is modified) or manual modes, with recalculation only carried out when the user clicks on a button in the energy window. The objective is that as the user modifies the building the energy consumption view of the building is updated. The results are fed back overtly in the energy window as a colour change in the model.

The next stage is to create several camera views each giving analytic feedback on different aspects of the design. Cameras can optimise shell/core arrangements to maximise work station layout efficiency using simple rule based techniques, and can analyze circulation layouts to maximise communication between workers in office environments using "space syntax" techniques. By analysing the same sketch design from all these points of view at once, as well as by evaluating it aesthetically and intuitively in the normal way, designers can 'internalise' the dynamics of how several functional systems interact with building form. Certain features are required to carry out this kind of analysis. First, it is clear that modelling and navigation must be achieved easily and fluidly if the computer interface itself is not to present a barrier to early stage sketch design. For a medium to be used in creative design it has to be attractive as a material in its own right, and in the case of software that is largely a matter of apparent fluidity of use. It is particularly important that analytic software makes the break out of the CAD bureau and onto the designing partner's desk, and this sets high standards for interface design. Second, objects in the real world are mainly three dimensional, solid or spatial objects, and have a large number of properties (mass, density, Young's modulus, colour, texture and so on), and for any kind of behaviour a different list of these properties is required knowledge. It is therefore important that the medium be based on 3-D objects with an arbitrary list of properties. Finally, real world objects have behaviours: a chair is pushed and it slides; a door is pushed and it swings. More generally, systems (structural, energy, transport) operate through the interactions between component parts which can also be thought of as behaviours. What is required is a way of coding behaviour and an ability to respond to external actions into our objects. Essentially, behaviour is treated as a special kind of object property, and in this way a minimal representation is defined that allows the creation of highly complex "worlds". This approach differs from the main thrust of knowledge based design support systems currently under investigation, as well as the current development of international standards for product information exchange. Instead of concentrating on the implementation of meta-models of the built environment that seek to capture the important aspects of buildings within a relative fixed (if general) model schema, a generic software tool has been developed that could in principal be used to implement a broad array of underlying model schema.

Although the basis of the present invention is simple and aims to be generic, the need for object entities to carry within themselves additional information could be seen as a drawback. The designer during the "form generation" phase of work is mainly interested in form. To interrupt that activity by requiring him or her to type in attribute data for every form would lead to the system not being used. However, some of these attributes are geometric: size, shape, location; others are material properties, and both of these are of interest to the "form generator" in "creative" mode. For most forms of analysis knowledge is required of both material properties and geometric information about the shape and location of the various components of a design. In addition, knowledge is often required of the topological relations between different components: "window 209 is in wall 153".

Although this may seem simple enough in principle, the present invention faces the problem of collecting information for many forms of analysis at once. This poses a problem for users who do not want to have to fill in a form for each and every component they create, especially in the strategic design phase where much of the information may not have been determined. This is a classic problem for traditional algorithmic computing which finds it difficult to cope with incomplete or inconsistent data sets. Most analyses require all the input variables to be filled in before any sensible results can be computed, but at the earliest stage of design the design tends to have the least ability to fill in that data, and they are loathe to "waste time on something that's going to change anyway".

The solution the present invention uses is to infer as much information as possible, with any missing information marked on the model in red (this is similar to the real world situation where an engineer redlines the architect's drawing where errors or ambiguities appear). The inferencing is performed by a mix of rule based expert system, fuzzy logic and neural network tools, using hybrids where appropriate. After a shape is created it is analyzed by a "smart attribute assistant"; the assistant has access to a number of local geometric properties of the object entity, for instance its size, arrangement of faces, ratios of dimensions and type. This is then combined with the local relational information about the object - what is it embedded in, what is it supporting, what is it supported by. The relational information is sorted in the object entity during its construction as a biproduct of the use of a "smart cursor". If the user confirms the "smart cursor's" suggestion that two faces on different objects should be aligned, that constraint is built into each object entity's knowledge of itself - by being added to the object entity's attribute list ("object A aligns with object B, object B aligns with object A"). In this way, topological and relational information is constructed with virtually no overhead to the user.

The inferencing engine then runs over the full list of object attributes, including their local topological relations to other components, and infers what kind of element they are most likely to be: a slab, window, column etc. These guesses can then be used to add default attributes and values to objects where these are missing, to spot and flag-up inconsistencies or possible to propose standardisation of components. By using a high level intermediate, the computer can label components as it goes which in turn helps it to label other components. The user is free to disagree with a label and provide a new label, and the learning part of the assistant can then use the parameters of the component to improve its recognition of other components without user intervention. By holding one central source for the attributes the present invention also gains through the ability to use one attribute for many analyses. For example, the wooden door can be used for rendering, sound analysis, and fire hazard analysis. When the door is changed then all the forms of analysis can be updated or marked up as "in need of recalculation". The main aim of this part of the system is to enhance the knowledge of attribute properties of object entities on the basis of the computer making suggestions and the user confirming them. The aim is to move from purely geometrical visualisation towards enhanced knowledge of other attributes of object entities in the world needed in order to model aspects of their function as real world systems; structural, in terms of energy or light, and so on.

The ability to visualise the design in terms of more than one analysis raises the possibility to trying to optimise the design from more than one point of view at once. The present invention gives access to a generic "optimisation toolkit". The purpose of the optimiser is to allow the user to propose constraints on the system and then allow the present invention to find a best solution to those constraints. The built world is inherently three dimensional and the primary constraint on the layout of objects is normally intersection, for example putting the maximum number of tables in a room implies that no two tables can intersect. When three dimensional information combines with attribute information and possibly time, the parameter space of the problem becomes highly irregular (implying a large number of local minima). If the problem space is enlarged to solve multiple problems - minimum cost for construction, heating, and maintenance over the building's life for instance - then simple hill climbing will not necessarily be sufficient.

The present invention gives access to a range of optimisation tools, including Genetic Algorithms and dynamic hill climbing. The costs functions for the optimisation have access to a number of attribute and spatial primitives which can be specified in terms of the analysis defined by one or more of the camera views of the world (energy, cost etc.). This provides a relatively simple metaphor for the hard part of most optimisation problems - that of defining the cost function.

EXAMPLE OF THE INVENTION - MOLECULAR MODELLING A further application of the present invention relates to molecular modelling particularly in the chemical field.

In this example, a molecule can be represented by an object entity and a complete chemical structure by a number of such entities.

The attribute data can contain information relating to the chemical element, such as its size, chemical properties, electrical properties, and so on, as well as its relationship with neighbouring molecules.

The script can, for example, provide instructions relating to the position of neighbouring molecules, so that the effect of addition of a molecule to a compound can be determined.

All molecules of a particular type can be collected within a collection entity so that a different type may be substituted into the compound. This is of particular interest when one is comparing elements in the periodic table.

Molecules can be grouped together to form compounds, and used as basic molecular building blocks. The camera entity can be used to view the compound from different angles and perspectives.

Whilst this invention has been described mostly by reference to the example of architectural systems, it evidently has application to a wide variety of other systems of interacting three dimensional objects. The ability to associate with each discrete data object entity representing a real world object entity not only values for parameters (such as mass, density and conductivity) but also instructions defining the behaviour of the object entity will prove valuable.

It will in any event be understood that the present invention has been described above purely by way of example, and modifications of detail can be made within the scope of the invention.

Each feature disclosed in the description, and (where appropriate) the claims and drawings may be provided independently or in any appropriate combination.

Reference numerals appearing in the claims are by way of illustration only and shall have no limiting effect on the scope of the claims.

Claims

1. A tool for modelling and analysis of a system of three dimensional object entities, comprising: means for establishing, for each such object entity, a discrete representative object entity in data form; means for displaying said object entity in graphical form; means for associating with each object entity a value for each of a defined set of parameters relevant to the system; means for associating with each object entity instructions enabling that object entity to interact with other object entities and, through the display, with the user; and means for interpreting and processing said instructions.

2. A tool as claimed in claim 1 wherein said instructions comprise intermediate level code.

3. A tool as claimed in claim 2 wherein said instructions further include high level code and said tool further comprises a compiler for compiling said intermediate level code from said high level code.

4. A tool as claimed in claim 3 wherein said compiler can compile more than one high level code.

5. A tool as claimed in any of claims 1 to 4 further comprising means for editing said instructions.

6. A tool as claimed in any preceding claim further comprising object function means for performing a function with respect to an object entity.

7. A tool as claimed in any preceding claim further comprising means for establishing an application entity comprising each such object entity and whereby all object entities are below the application entity in a hierarchical tree.

8. A tool as claimed in Claim 7 further comprising application function means for performing a function with respect to the application entity.

9. A tool as claimed in Claim 7 or 8 further comprising means for establishing a document entity comprising a group of such object entities, and wherein said application entity comprises all document entities, said object entities in the group are below the document entity in the hierarchical tree and all document entities are below the application entity in the hierarchical tree.

10. A tool as claimed in any preceding claim further comprising document function means for performing a function with respect to a document entity.

11. A tool as claimed in Claim 9 or 10 further comprising: means for associating with the application entity and document entity instructions enabling that entity to interact with other entities and, through the display, with the user; and means for interpreting and processing said instructions associated with a particular application entity or document entity.

12. A tool as claimed in any of the preceding claims wherein the instructions comprise: event instructions for instructing said means for interpreting and processing to send respective events to an entity; and event handlers for instructing said means for interpreting and processing to respond in a particular manner to a corresponding event sent from another entity; whereby when an event is sent to an entity the means for interpreting and processing is initiated with respect to instructions associated with said entity and, if present, the corresponding event handler is interpreted and processed.

13. A tool as claimed in the preceding claim as dependent on any of Claims 7 to 11 further comprising: forwarding means whereby if an event handler is not present in the instructions of said particular entity, it will, if possible, forward the event to a higher entity in the hierarchical tree.

14. A tool as claimed in the preceding claim wherein if the event handler is not present in the instructions of said particular entity and the event does not correspond to any of said entity's function means, it will, if possible forward the message to a higher entity in the hierarchical tree.

15. A tool as claimed in claim 12 wherein: the instructions further comprise instructions to handle events sent from an external entity, said external entity not being part of the tool; and said instructions further comprise instructions to send events to such external entities.

16. A tool as claimed in any of the preceding claims further comprising means for establishing a group entity comprising object entities selected by the user whereby an object entity may only directly belong to one group entity.

17. A tool as claimed in claim 16 as dependent on claim 6 whereby an object function performed on the group entity is performed on all the object entities.

18. A tool as claimed in any preceding claim further comprising means for establishing a collection entity comprising one or more object entities, selected by the user, whereby an object entity may belong to more than one collection entity.

19. A tool as claimed in any one of said preceding claims wherein said parameters comprise a label identifying a category to which the object entity belongs.

20. A tool as claimed in the preceding claim wherein means is provided for inferring the category to which the object entity belongs from the shape and any parameter values which have been defined by the user.

21. A tool as claimed in any of the preceding claims further comprising means for establishing a camera entity, and wherein said display means is adapted to display a representation of the view from the camera entity.

22. A tool as claimed in Claim 21 wherein said camera entity is an object entity.

23. A tool as claimed in any one of the preceding claims further comprising user input means for initiating said means for interpreting and processing with respect to instructions associated with a particular entity.

24. A method of modelling and analysis of a system of three dimensional object entities, comprising: establishing, for each such object entity, a discrete representative object entity in data form; displaying said representative object entity in graphical form; associating with each object entity a value for each of a defined set of parameters relevant to the system; associating with each object entity instructions enabling that object entity to interact with other object entities and, through the display, with the user; and interpreting and processing said instructions associated with a particular object entity.

25. A method as claimed in Claim 24 further comprising the step of compiling said instructions from a high level code to an intermediate level code.

26. A method as claimed in Claim 25 further comprising establishing said instructions via user input means.

27. A tool for modelling, analysis and measurement of a system of three dimensional objects, comprising means for establishing, for each such object, a discrete representative object in data form; means for displaying said representative object in 3D form; means for associating with each representative object a value for each of a defined set of parameters relevant to the system; and means for associating with each representative object instructions enabling that object to interact with other representative objects and, through the display, with the user.

28. A tool as claimed in Claim 27 wherein means are provided for addressing objects of a selected collection.

29. A tool as claimed in Claim 27 or 28 wherein there are defined categories of objects, one of said parameters comprising a label identifying the category to which the object belongs.

30. A tool as claimed in Claim 29 wherein means is provided for inferring the category to which a newly defined object should belong from the shape and from any parameters which have been defined by the user.

31. A computer when programmed with a tool as claimed in any of Claims 1 to 23 or 27 to 30.