U.S. patent application number 12/124041 was filed with the patent office on 2008-11-27 for computer-aided design apparatus.
This patent application is currently assigned to ARCHI.CON.DES INVENTIONS (UK) LIMITED. Invention is credited to Edvard Edo Ravnikar, Roman Soper.
Application Number | 20080291199 12/124041 |
Document ID | / |
Family ID | 38325640 |
Filed Date | 2008-11-27 |
United States Patent
Application |
20080291199 |
Kind Code |
A1 |
Ravnikar; Edvard Edo ; et
al. |
November 27, 2008 |
COMPUTER-AIDED DESIGN APPARATUS
Abstract
A computer-aided design apparatus generates a tree structure of
coordinate systems defining the topology of a three-dimensional
object to be fabricated. The coordinate systems are positioned and
orientated in accordance with mathematical functions. The
mathematical function positioning child coordinate systems has the
identity of the parent coordinate systems as a variable so that the
positions of the child coordinate systems relative to their parent
coordinate systems vary in accordance with the identity of the
parent coordinate systems. Data defining the coordinate systems and
connections therebetween is stored in a graph. Bases having a
defined relationship are identified and three-dimensional content
objects are added thereto. The content objects are added using the
same mathematical function to generate a three-dimensional content
object in each of a plurality of coordinate systems. The
mathematical function for generating the content objects has the
identity of the coordinate systems as a variable thereof to
generate the content object in each coordinate system with a
different shape.
Inventors: |
Ravnikar; Edvard Edo;
(Ljubljana, SI) ; Soper; Roman; (Novo mesto,
SI) |
Correspondence
Address: |
LOWRIE, LANDO & ANASTASI, LLP
ONE MAIN STREET, SUITE 1100
CAMBRIDGE
MA
02142
US
|
Assignee: |
ARCHI.CON.DES INVENTIONS (UK)
LIMITED
London
GB
|
Family ID: |
38325640 |
Appl. No.: |
12/124041 |
Filed: |
May 20, 2008 |
Current U.S.
Class: |
345/419 |
Current CPC
Class: |
G06T 17/10 20130101;
G06F 30/00 20200101 |
Class at
Publication: |
345/419 |
International
Class: |
G06T 15/00 20060101
G06T015/00 |
Foreign Application Data
Date |
Code |
Application Number |
May 21, 2007 |
EP |
07 010 053.2 |
Mar 31, 2008 |
EP |
08 006 351.4 |
Claims
1. A computer-aided design apparatus (2) for the design of
three-dimensional objects to be fabricated, the apparatus
comprising: a base generator operable to generate a topology for a
design of a three-dimensional object by generating a plurality of
different generations of bases, wherein each generation of bases
comprises a plurality of bases, each base comprising a local
coordinate system, and wherein the bases in the second and any
subsequent generation are arranged in a plurality of groups such
that each respective group is located in the local coordinate
system of a different base in a preceding generation; and a content
generator operable to add content to the design by using the same
mathematical procedure or procedures to generate a
three-dimensional content object in each of a plurality of bases
comprising bases within different groups of a generation.
2. Apparatus according to claim 1, wherein the base generator is
operable to generate a further generation of bases, wherein each
base in the further generation has at least one of a position and
orientation dependent upon a content object.
3. Apparatus according to claim 1, wherein: the apparatus is
arranged to store data defining the mathematical procedure(s) used
by the content generator to generate the content objects; the
apparatus further comprises a controller operable to change the
stored data defining the mathematical procedure(s) in accordance
with user instructions; and the content generator is operable to
regenerate the content objects in accordance with the changed
mathematical procedure(s).
4. Apparatus according to claim 1, wherein the content generator is
operable to generate the content objects using at least one
mathematical function having a variable defining respective bases
in which the content objects are to be located, such that each
content object has at least one of a position and orientation
relative to the local coordinate system of the base in which it is
located which depends upon the value of the variable and such that
at least one of the positions and orientations of the content
objects relative to their local coordinate systems changes in
accordance with the value of the variable.
5. Apparatus according to claim 4, wherein: each content object has
a unique feature identification number; and the content generator
is operable to generate the content objects using at least one
mathematical function having the variable defining the respective
bases and also the feature identification number as variables of
the function(s) so that each content object has at least one of a
position and orientation relative to the local coordinate system of
the base in which it is located which depends upon both the value
of the variable defining the base in which it is located and the
value of the feature identification number of the content
object.
6. Apparatus according to claim 5, wherein the content generator is
operable to generate the content objects using a first mathematical
function having the variable defining the respective bases as a
variable thereof and a second mathematical function having the
feature identification number as a variable thereof.
7. Apparatus according to claim 1, wherein the apparatus further
comprises a data generator operable to generate and store base data
defining bases generated by the base generator and connection data
defining, for each base, at least one base in the same group, a
base in the consecutive preceding group of the same generation, and
a base in the consecutive following group of the same
generation.
8. Apparatus according to claim 7, wherein the data generator is
arranged to: generate and store the base data as a respective
vertex for each base in a graph; and generate and store the
relation data as directed edges between the vertices in the
graph.
9. Apparatus according to claim 7, further comprising: a base
identifier operable to process the data generated by the data
generator to identify bases having a defined relationship; and
wherein the content generator is operable to generate further
three-dimensional content objects for the identified bases.
10. Apparatus according to claim 9, wherein the base identifier is
operable to process the data generated by the data generator to
identify bases having a defined geometrical relationship.
11. Apparatus according to claim 1, further comprising: a feature
identifier operable to identify features comprising content objects
having a defined relationship and/or operable to identify features
comprising at least one base and at least one content object having
a defined relationship; and wherein the content generator is
operable to generate further three-dimensional content objects for
the identified features.
12. Apparatus according to claim 11, wherein the feature identifier
is operable to identify features having a defined geometrical
relationship.
13. A method of operating a computer-aided design apparatus (2) to
design a three-dimensional object to be fabricated, the method
comprising: generating a topology for a design of a
three-dimensional object by generating a plurality of different
generations of bases, wherein each generation of bases comprises a
plurality of bases, each base comprising a local coordinate system,
and wherein the bases in the second and any subsequent generation
are arranged in a plurality of groups such that each respective
group is located in the local coordinate system of a different base
in a preceding generation; and adding content to the design by
using the same mathematical procedure or procedures to generate a
three-dimensional content object in each of a plurality of bases
comprising bases within different groups of a generation.
14. A method according to claim 13, further comprising generating a
further generation of bases, each base in the further generation
having at least one of a position and orientation dependent upon a
content object.
15. A method according to claim 13, wherein: data is stored
defining the mathematical procedure(s) used to generate the content
objects; the stored data defining the mathematical procedure(s) is
changed in accordance with user instructions; and the content
objects are regenerated in accordance with the changed mathematical
procedure(s).
16. A method according to claim 13, wherein the content objects are
generated using at least one mathematical function having a
variable defining respective bases in which the content objects are
to be located, such that each content object has at least one of a
position and orientation relative to the local coordinate system of
the base in which it is located which depends upon the value of the
variable and such that at least one of the positions and
orientations of the content objects relative to their local
coordinate systems changes in accordance with the value of the
variable.
17. A method according to claim 16, wherein: each content object
has a unique feature identification number; and the content objects
are generated using at least one mathematical function having the
variable defining the respective bases and also the feature
identification number as variables of the function(s) so that each
content object has at least one of a position and orientation
relative to the local coordinate system of the base in which it is
located which depends upon both the value of the variable defining
the base in which it is located and the value of the feature
identification number of the content object.
18. A method according to claim 17, wherein the content objects are
generated using a first mathematical function having the variable
defining the respective bases as a variable thereof and a second
mathematical function having the feature identification number as a
variable thereof.
19. A method according to claim 13, wherein the method further
comprises generating and storing base data defining the generated
bases, and connection data defining, for each base, at least one
base in the same group, a base in the consecutive preceding group
of the same generation, and a base in the consecutive following
group of the same generation.
20. A method according to claim 19, wherein: the base data is
generated and stored as a respective vertex for each base in a
graph; and the relation data is generated and stored as directed
edges between the vertices in the graph.
21. A method according to claim 19, further comprising: processing
the stored data to identify bases having a defined relationship;
and generating further three-dimensional content objects for the
identified bases.
22. A method according to claim 21, wherein bases having a defined
geometrical relationship are identified.
23. A method according to claim 13, further comprising: identifying
features comprising content objects having a defined relationship
and/or identifying features comprising at least one base and at
least one content object having a defined relationship; and
generating further three-dimensional content objects for the
identified features.
24. A method according to claim 23, wherein features having a
defined geometrical relationship are identified.
25. A physically-embodied computer program product having computer
program instructions to program a programmable processing apparatus
to become configured as an apparatus comprising: a base generator
operable to generate a topology for a design of a three-dimensional
object by generating a plurality of different generations of bases,
wherein each generation of bases comprises a plurality of bases,
each base comprising a local coordinate system, and wherein the
bases in the second and any subsequent generation are arranged in a
plurality of groups such that each respective group is located in
the local coordinate system of a different base in a preceding
generation; and a content generator operable to add content to the
design by using the same mathematical procedure or procedures to
generate a three-dimensional content object in each of a plurality
of bases comprising bases within different groups of a
generation.
26. A physically-embodied computer program product according to
claim 25, wherein the computer program instructions are such that
the base generator is operable to generate a further generation of
bases, wherein each base in the further generation has at least one
of a position and orientation dependent upon a content object.
27. A physically-embodied computer program product according to
claim 25, wherein the computer program instructions are such that:
the apparatus is arranged to store data defining the mathematical
procedure(s) used by the content generator to generate the content
objects; the apparatus further comprises a controller operable to
change the stored data defining the mathematical procedure(s) in
accordance with user instructions; and the content generator is
operable to regenerate the content objects in accordance with the
changed mathematical procedure(s).
28. A physically-embodied computer program product according to
claim 25, wherein the computer program instructions are such that
the content generator is operable to generate the content objects
using at least one mathematical function having a variable defining
respective bases in which the content objects are to be located,
such that each content object has at least one of a position and
orientation relative to the local coordinate system of the base in
which it is located which depends upon the value of the variable
and such that at least one of the positions and orientations of the
content objects relative to their local coordinate systems changes
in accordance with the value of the variable.
29. A physically-embodied computer program product according to
claim 25, wherein the computer program instructions are such that:
each content object has a unique feature identification number; and
the content generator is operable to generate the content objects
using at least one mathematical function having the variable
defining the respective bases and also the feature identification
number as variables of the function(s) so that each content object
has at least one of a position and orientation relative to the
local coordinate system of the base in which it is located which
depends upon both the value of the variable defining the base in
which it is located and the value of the feature identification
number of the content object.
30. A physically-embodied computer program product according to
claim 29, wherein the computer program instructions are such that
the content generator is operable to generate the content objects
using a first mathematical function having the variable defining
the respective bases as a variable thereof and a second
mathematical function having the feature identification number as a
variable thereof.
31. A physically-embodied computer program product according to
claim 25, wherein computer program instructions comprise
instructions to program the programmable processing apparatus to
become configured as an apparatus further comprising a data
generator operable to generate and store base data defining bases
generated by the base generator and connection data defining, for
each base, at least one base in the same group, a base in the
consecutive preceding group of the same generation, and a base in
the consecutive following group of the same generation.
32. A physically-embodied computer program product according to
claim 31, wherein the computer program instructions are such that
the data generator is arranged to: generate and store the base data
as a respective vertex for each base in a graph; and generate and
store the relation data as directed edges between the vertices in
the graph.
33. A physically-embodied computer program product according to
claim 31, wherein the computer program instructions comprise
instructions to program the programmable processing apparatus to
become configured as an apparatus further comprising: a base
identifier operable to process the data generated by the data
generator to identify bases having a defined relationship; and
wherein the computer program instructions are such that the content
generator is operable to generate further three-dimensional content
objects for the identified bases.
34. A physically-embodied computer program product according to
claim 33, wherein the computer program instructions are such that
the base identifier is operable to process the data generated by
the data generator to identify bases having a defined geometrical
relationship.
35. A physically-embodied computer program product according to
claim 25, wherein the computer program instructions comprise
instructions to program the programmable processing apparatus to
become configured as an apparatus further comprising: a feature
identifier operable to identify features comprising content objects
having a defined relationship and/or operable to identify features
comprising at least one base and at least one content object having
a defined relationship; and wherein the computer program
instructions are such that the content generator is operable to
generate further three-dimensional content objects for the
identified features.
36. A physically-embodied computer program product according to
claim 35, wherein the computer program instructions are such that
the feature identifier is operable to identify features having a
defined geometrical relationship.
Description
[0001] This application claims the right of priority under 35 U.S.C
.sctn. 119 based on European patent application numbers EP 07 010
053.2 filed on 21 May 2007 and EP 08 006 351.4 filed on 31 Mar.
2008 which are hereby incorporated by reference herein in their
entirety as if fully set forth herein.
[0002] The present invention relates to the field of computer-aided
design apparatus, and more particularly, to apparatus for the
design of three-dimensional objects to be fabricated. The invention
is particularly applicable to the design of complex objects made up
of over 5,000 constituent parts.
[0003] There are many examples of fabricated objects, such as urban
agglomerations, buildings and building complexes, industrial plants
and power generating plants, transport terminals, oil rigs,
aeroplanes, cars, trucks and trains, ships, satellites and
spaceships, micro-chips, nanotechnology structures, etc.
[0004] These objects are fabricated by assembling together small
units that in turn become parts to larger components. Fitting them
together involves complex interrelations of a great amount of
individual shapes. Furthermore, the fitting together of components
involves complex physical interactions which are dependent not only
on the components themselves, but also the topology of the overall
structure and the relative positions which the components occupy
within this topology.
[0005] Existing computer-aided design systems for fabricated
objects require the user to create constituent components of the
design in design files which for historical reasons emulate the
traditional design techniques that served the bottom-up approach to
building construction.
[0006] Components from the design file are then exported into an
overall space for the model, where each component is manually
placed into position so that the components fit together and
generate the topology of the overall model.
[0007] Accordingly, the design, placement and fitting of components
are separate tasks in existing systems.
[0008] By way of example, "Interactive Design of 3D Models With
Geometric Constraints" by van Emmerik M J G M in The Visual
Computer, Springer-Verlag, volume 7, 1991, pages 309-325,
XP009088118, presents an interactive graphical approach for the
design of parameterized part-hierarchies. Primitive solids can be
grouped into compound objects, and multiple instances of a compound
object can be used in further designs. Geometric relations between
primitives and instances are specified by geometric constraints
between their local coordinate systems.
[0009] These systems suffer from a number of problems, however.
[0010] In particular, considerable effort and time is required on
the part of the user to create the design in an existing system.
This defeats the purpose of computer support. For example,
variations in the components can only be introduced by redesigning
components in the design files and then placing them manually to
recreate the overall model. Also, the consistency of such designs
relies upon the designer's ability to check for and iron out
inconsistencies (such as objects which encroach upon each
other--that is, they occupy the same space). How real this problem
is shown by the fact that most existing systems provide so called
`interference checking` devices to check for inconsistencies such
as encroaching objects.
[0011] Such systems have therefore forced designers to create
regular-shaped fabricated objects, using repeatable design patterns
and compositions of copies of the same components, to the detriment
of functionality, all while the demand for increasingly articulate
and diversified large fabricated objects grows rapidly. In fact so
great is the problem, that any small improvement in the design
process which reduces the problem is hailed as a breakthrough.
[0012] A further problem is that a building component manufactured
according to a design from a system which designs, places and fits
the components as separate tasks is often not consistent with the
huge amount of other components that are to form the fabricated
object. As a result, skill-intensive labour is required to fit the
components together.
[0013] Experience of using components manufactured from a design
created by existing systems has given rise to the commonly held
belief that it is sometimes quicker and cheaper to fine tune the
fittings of components on site (or return them to the factory for
adjustment) than to spend the time that is required by existing
design systems to design components that will fit without
adjustment. Waywardly, the responsibility for fitting of components
is thus passed from the designer to the builder. This particular
problem in the design and construction of buildings defeats the
fundamental purpose of design which is that it should be complete
and consistent before the fabrication stage. With the growing
relevance of information technology, completeness and consistency
become requirements in rigorous (logical) terms. This makes the
problem even more acute.
[0014] For the same reasons, the synergy of industrial production
of components, relying on numerically controlled machines and
robots in production lines is hugely underemployed in building
construction. The cost of building components is out of step with
the cost of other industrial products that are no different in
terms of materials used or energy consumed in their production.
[0015] The present invention aims to address one or more of the
problems with existing computer-aided design systems.
[0016] In particular, the present invention aims to address the
problem of how to provide an apparatus for the design of a complex
three-dimensional object without using a design file environment,
and the problems which arise therein of how to provide
functionality to generate a design having three-dimensional content
objects which fit throughout the design and how to reduce the large
amount of data needed to define the design of a complex object.
[0017] According to the present invention, there is provided a
computer-aided design apparatus for the design of three-dimensional
objects, comprising:
a base generator operable to generate a topology for a design of a
three-dimensional object by generating a plurality of different
generations of bases, wherein each generation of bases comprises a
plurality of bases, each base comprising a local coordinate system,
and wherein the bases in the second and any subsequent generation
are arranged in a plurality of groups such that each respective
group is located in the local coordinate system of a different base
in a preceding generation; and a content generator operable to add
three-dimensional content objects to the topology defined by the
bases by applying the same mathematical procedure or procedures to
generate a three-dimensional content object in a plurality of the
bases located within different groups of a generation.
[0018] The present invention also provides a method of generating a
design for a three-dimensional object using a computer-aided design
apparatus, the method comprising:
generating a topology for a design of a three-dimensional object by
generating a plurality of different generations of bases, wherein
each generation of bases comprises a plurality of bases and each
base comprises a local coordinate system; and adding content to the
bases by using a single application of the same mathematical
procedure or procedures to generate a three-dimensional content
object in a plurality of bases comprising bases within different
groups of a generation.
[0019] In accordance with these features, the topology for the
design is generated first, with the bases arranged in groups within
a plurality of generations such that each group is located in the
local coordinate system of a different base in a preceding
generation. Three-dimensional content objects are then added to a
plurality of bases in different groups using the same mathematical
procedure or procedures. As a result, a large number of content
objects can be generated with a single application of the
mathematical procedure(s) such that the content objects vary to fit
the topology at different parts of the design (the parts being
defined by the different groups) in accordance with the
mathematical procedure(s).
[0020] Furthermore, by using the same mathematical procedure(s) to
generate a plurality of content objects, the amount of data
required to define the design is reduced because it is unnecessary
to store different data defining each content object and instead it
is only necessary to store data defining the mathematical
procedure(s).
[0021] The present invention also provides a computer program
product, embodied for example as a storage medium storing computer
program instructions or other physical product carrying computer
program instructions, for configuring a programmable apparatus as
an apparatus having the features set out above.
[0022] Embodiments of the present invention will now be described,
by way of example only, with reference to the accompanying
drawings, in which:
[0023] FIG. 1 schematically shows the components of an embodiment
of the invention, together with the notional functional processing
units into which the processing apparatus component may be thought
of as being configured when programmed by computer program
instructions;
[0024] FIG. 2 shows the components of the base generator in FIG.
1;
[0025] FIG. 3 shows the components of the content generator in FIG.
1;
[0026] FIG. 4 shows the processing operations performed by the
apparatus of FIG. 1;
[0027] FIG. 5 shows the processing operations performed at step
S100 in FIG. 4;
[0028] FIG. 6 shows the processing operations performed at step
S200 in FIG. 4;
[0029] FIG. 7 shows the processing operations performed at step
S300 in FIG. 4;
[0030] FIG. 8 shows the processing operations performed at step
S400 in FIG. 4;
[0031] FIG. 9 shows the processing operations performed at step
S500 in FIG. 4;
[0032] FIG. 10 shows the processing operations performed at step
S600 in FIG. 4;
[0033] FIG. 11 shows the processing operations performed at step
S700 in FIG. 4;
[0034] FIG. 12 shows the processing operations performed at step
S800 in FIG. 4;
[0035] FIGS. 13a, 13b, 13c and 13d show an example to illustrate
the generation of backbone bases at step S300 during the first
round of processing to generate a design model;
[0036] FIGS. 14a, 14b and 14c illustrate the addition of attributes
and connections to a graph for the model at step S400 in the first
round of processing;
[0037] FIGS. 15a, 15b and 15c illustrate the transformation of the
backbone bases at step S600 in the first round of processing;
[0038] FIGS. 16, 17, 18, 19a and 19b show an example to illustrate
the generation of ring bases at step S300 in a second round of
processing to generate the design model;
[0039] FIGS. 20, 21, 22, 23, 24 and 25 illustrate the addition of
attributes and connections to the model graph during the processing
at step S400 during the second round of processing;
[0040] FIGS. 26a and 26b show an example to illustrate the
processing performed at step S500 to insert content objects into
the ring bases during the second round of processing;
[0041] FIGS. 27, 28 and 29 illustrate the addition of attributes
and connections to the model graph for the content objects added at
step S500;
[0042] FIGS. 30a, 30b, 30c, 30d, 31a and 31b show an example to
illustrate the creation of new content objects at step S700 in the
second round of processing;
[0043] FIGS. 32, 33 and 34 illustrate the addition of attributes
and connections to the model graph for the content objects created
at step S700 in the second round of processing;
[0044] FIGS. 35a, 35b and 35c show the result of applying a sensor
function at step S800 in the second round of processing to divide
bases into two separate equivalence classes;
[0045] FIG. 36 illustrates the addition of an attribute to the
model graph defining the equivalence class of each ring base
determined at step S800 in the second round of processing;
[0046] FIGS. 37a, 37b, 37c, 37d and 38 show an example to
illustrate the generation of centre bases at step S300 in the third
round of processing;
[0047] FIGS. 39a, 39b, 39c and 40 illustrate the addition of
attributes and connections to the model graph for the centre bases
created at step S300 in the third round of processing;
[0048] FIGS. 41a and 41b show an example to illustrate the
insertion of content objects into the centre bases at step S500 in
the third round of processing;
[0049] FIGS. 42a, 42b and 42c illustrate the addition of attributes
and connections to the model graph for the content objects inserted
at step S500 in the third round of processing;
[0050] FIGS. 43a and 43b show an example to illustrate the
transformation of content objects at step S600 in the third round
of processing;
[0051] FIGS. 44a, 44b, 44c and 44d show an example to illustrate
the generation of content objects at step S700 in the third round
of processing;
[0052] FIGS. 45a, 45b and 45c illustrate the addition of attributes
and connections to the model graph for the content objects created
at step S700 in the third round of processing;
[0053] FIG. 46 shows the final design model for the illustrated
example after completion of the three rounds of processing;
[0054] FIGS. 47, 48, 49 and 50 illustrate the effects on the final
model of changing the parameter values and/or functions used to
generate the bases and/or content objects in the model;
[0055] FIGS. 51a, 51b and 52 show an example to illustrate how the
embodiment is operable to vary the shape of content objects in
dependence upon the index of the reference base into which the
content objects are inserted;
[0056] FIG. 53 shows the final model resulting from processing to
vary the shape of content objects as illustrated in FIGS. 51a, 51b
and 52;
[0057] FIGS. 54a, 54b and 54c illustrate an example to show how the
embodiment is operable to generate content objects so that they do
not encroach;
[0058] FIGS. 55, 56 and 57 show an example to illustrate the
execution of a sensor function to detect a property of the model
using the model graph;
[0059] FIGS. 58a and 58b show an example to illustrate how the
embodiment is operable to identify bases having a defined
relationship and to add different content objects thereto; and
[0060] FIGS. 59a, 59b, 60a, 60b, 60c, 61, 62, 63 and 64 show an
example to illustrate how the embodiment is operable to identify
bases and content objects having a defined relationship, to
identify content objects having a defined relationship, and to add
further content objects to the design in accordance with the
identified features.
[0061] Referring to FIG. 1, an embodiment of the invention
comprises a programmable processing apparatus 2, such as a personal
computer (PC), containing, in a conventional manner, one or more
processors, memories, graphics cards etc, together with a display
device 4, such as a conventional personal computer monitor, and
user input devices 6, such as a keyboard, mouse etc.
[0062] The processing apparatus 2 is programmed to operate in
accordance with programming instructions input, for example, as
data stored on a data storage medium 12 (such as an optical CD ROM,
semiconductor ROM, magnetic recording medium, etc), and/or as a
signal 14 (for example an electrical or optical signal input to the
processing apparatus 2, for example from a remote database, by
transmission over a communication network (not shown) such as the
Internet or by transmission through the atmosphere), and/or entered
by a user via a user input device 6 such as a keyboard.
[0063] As will be described in more detail below, the programming
instructions comprise instructions to program the processing
apparatus 2 to become configured to generate data defining a
three-dimensional computer model of a design for a
three-dimensional object to be fabricated. The design model
comprises bases and content objects. Each base is a local
coordinate system and acts as "place-holder" to accept further
bases and/or content objects.
[0064] Referring to FIG. 13d, the programmed apparatus is operable
to generate a plurality of first-generation bases C.sub.1-C.sub.8.
Each base comprises a local coordinate system, and in this
embodiment, the bases are positioned and orientated in accordance
with at least one mathematical function (although this could be
done by a user).
[0065] Referring to FIG. 18, the apparatus is then operable to
generate second-generation bases B.sub.R1-B.sub.R144 with a
respective plurality of these second-generation bases located in a
group in the local coordinate system of each first generation base.
Each second-generation base comprises a local coordinate system,
and the positions and/or orientations of the second-generation
bases are defined in accordance with at least one mathematical
function having the identities of the first generation bases as a
variable thereof, with the result that each second-generation base
has a position and/or orientation relative to the first-generation
base in which it is located which depends upon that
first-generation base. In this way, the positions and/or
orientations of the second-generation bases relative to their
containing first-generation base change in each first-generation
base in accordance with the mathematical function(s).
[0066] Thus, in the example of FIG. 18, the second-generation bases
have positions on circles around the first-generation bases such
that 18 second-generation bases are located in a group in the
coordinate system of each first generation base. The radii of the
circles (and therefore the positions of the second-generation bases
relative to the origin of the containing first-generation base) are
defined in accordance with a mathematical function such that the
radius of the circle is different for each first generation base.
As a result of this feature, variations in the positions and/or
orientations of the second-generation bases can be introduced
throughout the model in accordance with the defining mathematical
function(s), without the user having to introduce the variations by
positioning and/or orientating each second-generation base
manually.
[0067] Data defining the bases is stored in a graph. More
particularly, for each base, base data defining the base is stored
as a respective vertex in the graph, and connection data defining
interconnections between the bases is stored as directed edges
between the vertices in the graph. Thus, referring to FIGS. 23 and
24, base data is stored for each base which defines the base
itself, and connection data is stored which defines the adjacent
bases within the same group (defined by the "NEXT" and "PREV"
directed edges), and the corresponding bases in the adjacent groups
(defined by the "to" and "from" directed edges). In this way,
intra-group connections and inter-group connections are stored
linking the bases together.
[0068] The arrangement of bases in groups and the storage of base
data and connection data as described above provides a number of
important advantages. In particular, the relative positions of the
bases can be tracked in a reliable and efficient way even for a
complex design. As a result, bases having required relationships
for the addition of a further base or a further content object can
be readily identified. Furthermore, the stored base data and
connection data can be used to define bases within a mathematical
function. For example, bases to be used in a mathematical procedure
can be defined by defining a start base and then defining bases
relative thereto using the "NEXT", "PREV", "to" and "from"
connections. As a result, it is not necessary to specify each base
to be used by its base index value. This again provides
particularly important advantages in a complex design with may
bases.
[0069] The apparatus may add further generations of bases and/or
content objects to the model in accordance with mathematical
functions or procedures. In particular, the apparatus is operable
to add each generation of bases or content objects such that a
property thereof varies in accordance with the identity of the
existing base in which the new base/content object is placed.
[0070] However, one problem which arises in a complex model is how
to determine the positions at which the bases and/or content
objects should be added bearing in mind the large number of bases
within the complex design. To address this problem, functionality
is provided to identify bases having a required relationship for
the addition of a further base or content object. As a result of
this functionality, the locations for new bases and/or content
objects can be determined rapidly without considerable effort on
the part of the user.
[0071] FIGS. 30b-30d illustrate the generation of a content object
comprising a plane in the local coordinate system of each
second-generation base. The plane is defined by a mathematical
procedure which is the same for each second-generation base but
which depends upon the relative positions of a plurality of
adjacent second-generation bases. Accordingly, because the relative
positions of the second-generation bases change throughout the
model (because their positions depend upon the identity of their
corresponding first-generation base as described above), the planes
also change throughout the model (even though they were defined by
the same mathematical procedure).
[0072] The apparatus is operable to generate content objects in
adjacent bases using a mathematical procedure which is dependent
upon the positions and orientations of the adjacent bases so that
the content objects fit together. For example, referring to FIGS.
31a and 31b, the apparatus is operable to generate adjacent solid
objects W.sub.i and W.sub.N by a procedure which constructs planes
that are defined in dependence upon the positions and orientations
of the adjacent bases B.sub.Ri, B.sub.N, B.sub.NN, B.sub.T,
B.sub.NT and B.sub.NNT. By constructing content objects in this
way, the apparatus is operable to generate content objects
throughout a generation of bases using the same procedure such that
the content objects vary in accordance with the variations of the
bases but still fit together without gaps or overlaps.
[0073] The apparatus is therefore operable to generate a model such
that the process is staged into sequential generations of bases,
where denser placements of bases follow from earlier sparser
generations. In this way, the bases have a "tree" structure.
[0074] Because bases are positioned and orientated by at least one
mathematical function, a large number of bases can be generated,
enabling complex models to be generated.
[0075] The bases define the topology of the model. Variations and
patterns in the topology (positions and/or orientations of bases)
can be imparted by defining bases in one generation using a
mathematical function which varies in dependence upon the identity
of bases in a previous generation.
[0076] Content objects are added to the topology defined by the
bases. The content objects are defined by mathematical procedures
which may be dependent upon one or more bases, so that the content
objects vary in accordance with the variations in the topology of
the bases and/or impart further variations to the model.
[0077] Furthermore, content objects may be generated by a procedure
which is dependent upon the mathematically defined positions and/or
orientations of the bases that hold the content objects (they are
not produced and placed separately as in existing design file
systems). Therefore, content objects are matched to adjacent
content objects by the defined generation procedure. Furthermore,
the content objects automatically change to adapt to any changes in
the bases without changing the generation procedure. This is
because the generation procedure is defined to be dependent upon
the positions and/or orientations of the bases, and changes in
these positions and/or orientations merely result in different
values of the parameters to be used in the generation procedure.
Thus, content objects do not comprise finished objects, designed
separately, placed in the bases and expected to fit. Instead
content objects are created with the same procedure, taking into
account the positions and orientations of the bases, and resulting
in content objects which vary in accordance with the bases to fit
together.
[0078] In accordance with these features, and other features
described below, a complex and varied model can be built up, in
which content objects fit together and adapt to any changes in the
model.
[0079] When programmed by the programming instructions, processing
apparatus 2 can be thought of as being configured as a number of
functional units for performing processing operations. Examples of
such functional units and their interconnections are shown in FIG.
1. The units and interconnections illustrated in FIG. 1 are,
however, notional and are shown for illustration purposes only to
assist understanding; they do not necessarily represent units and
connections into which the processor, memory etc of the processing
apparatus 2 actually become configured.
[0080] Referring to the functional units shown in FIG. 1, central
controller 20 is operable to process inputs from the user input
devices 6, and also to provide control and processing for the other
functional units. Memory 30 is provided for use by central
controller 20 and the other functional units.
[0081] Input data interface 40 is operable to control the storage
of input data within processing apparatus 2. The data may be input
to processing apparatus 2 for example as data stored on a storage
medium 42, as a signal 44 transmitted to the processing apparatus
2, or using a user input device 6.
[0082] In this embodiment, the input data may comprise data for a
model (or part thereof) that has been previously generated (either
by the present system or a separate system of the same type) and is
to be amended/developed further by the present system.
[0083] Parameter definer 50 is operable to define the parameters to
be used in the creation of the model in accordance with user
instructions and/or by computation. In this embodiment, the
parameters fall into two groups, namely geometric parameters (such
as point, line, plane, solid object, etc) and all other types of
parameters (such as numbers, strings, etc). The parameters required
vary in accordance with the model to be produced, and examples will
be described later with reference to a specific example of a
model.
[0084] Reference object selector 60 is operable to select reference
objects. A reference object is an object that provides the
foundation on which new bases and/or new content objects are
created. The reference object may comprise a global coordinate
system (that is, a coordinate system that stands by itself without
reference to any other object), an existing base (local coordinate
system) or an existing content object.
[0085] Base generator 70 is operable to generate bases. Each base
comprises a local coordinate system (where a coordinate system is a
system of assigning a tuple of numbers to each point in an
n-dimensional space). Different types of coordinate system may be
defined by base generator 70, such as Euclidean, spherical, polar,
a coordinate system in Calabi-Yau space, etc.
[0086] Referring to FIG. 2, in this embodiment, base generator 70
comprises function selector 72, position calculator 74, orientation
calculator 76 and base builder 78.
[0087] Function selector 72 is operable to select one or more
mathematical functions to compute each base. For example, in the
case of a base comprising a Euclidean coordinate system, functions
to compute the position and orientation of the base are
required.
[0088] Position calculator 74 is operable to apply the function(s)
selected by function selector 72 to calculate the base position
(the origin of the base).
[0089] Orientation calculator 76 is operable to apply the
function(s) selected by function selector 72 to calculate the base
orientation (the direction of the coordinate axes).
[0090] Base builder 78 is operable to combine the position and
orientation calculated by position calculator 74 and orientation
calculator 76 to produce data defining a base.
[0091] Referring again to FIG. 1, graph manager 80 is operable to
generate, and maintain, a graph for each model created by the
system. A graph of a model is a directed and labelled multigraph.
The vertices of a graph represent indexed bases and content objects
from each generation in a model. Edges represent the relation
between two objects, and therefore represent relations between
pairs of bases, content objects or both. The directions of edges go
from the first vertex in a pair to the second vertex in a pair.
There can be more than one edge between any two vertices. All
vertices and edges have labels. For vertices, the labels are
attributes of underlying bases and content objects. For edges, the
labels represent the type of relation between two objects.
[0092] In this embodiment, there are two predefined relations which
have unique labels. An edge with a label SUBBASE represents the
relation between a reference base and a base `contained` in it. In
other words, if a reference base is a container for another base,
the other base in a pair is contained in this container. Similarly,
an edge with a label CONTENT represents the relation between a
reference base and a content object that lies in it. In the present
embodiment, when a reference base is transformed (moved and/or
rotated), all of the bases linked to it with relation SUBBASE and
all of the content objects linked to it with relation CONTENT are
transformed in the same way. Since every base can be a container
for the other bases, this relation is recursive and not
limited.
[0093] Graph manager 80 is operable to create a graph, insert
vertices into the graph representing each base and content object
within the model, assign values for different attributes of the
vertices, and add connections between the vertices.
[0094] Graph manager 80 is operable to assign the values for
attributes and connections between vertices in accordance with user
instructions or by calculation in accordance with a function or
procedure.
[0095] Content generator 90 is operable to insert content objects
into the model by inserting the content objects into the local
coordinate systems of bases generated by base generator 70. The
content objects may be of different types. For example, a content
object may be defined by content generator 90 to be invariant, with
the result that the content object cannot then be changed by the
system. A solid object is an object of bounded volume. A primary
object is a point, vector, line, curve, plane or planar
polygon.
[0096] Referring to FIG. 3, in this embodiment, content generator
90 comprises content importer 92 and content creator 94.
[0097] Content importer 92 is operable to input content objects
into the system from an outside source, such as an external CAD
application running on apparatus 2 or an external apparatus. In the
present embodiment only primary content objects and invariant
content objects can be imported.
[0098] Content creator 94 is operable to create content objects
within the system in accordance with mathematical procedures
defined in accordance with user instructions or in accordance with
pre-stored geometric modelling kernels. Each mathematical procedure
comprises one or a series of mathematical operations which create
and/or manipulate geometric components in order to create a content
object for the design. The operations may include the execution of
mathematical functions, transformations, logical (Boolean)
operations, conditional operations (where the operation to be
performed is dependent upon a condition), etc. For example, a
modelling kernel may be stored to create a solid object by Boolean
operation (union, intersection, difference) and a modelling kernel
may be stored to create a solid object from bounding planes. Many
other modelling kernels may be stored.
[0099] Content creator 94 is operable to use the same mathematical
procedure to generate a respective content object relative to each
of a plurality of bases. More particularly, the mathematical
procedure creates and/or manipulates a geometric component in
dependence upon base position and/or orientation so that the
resulting content objects vary in accordance with changes in the
position and/or orientation of the bases even though they were
generated using the same mathematical procedure.
[0100] Referring again to FIG. 1, transformation controller 100 is
operable to apply transformations to bases and/or content objects,
thereby enabling a plurality of bases and/or content objects to be
changed without defining changes for each one individually. In this
embodiment, transformation controller 100 is operable to apply the
following transformations (although others could be applied instead
or as well): [0101] changing origins and/or rotations of bases;
[0102] changing positions and/or rotations of content objects;
[0103] scaling and mirroring of content objects.
[0104] Transformation controller 100 is operable to define a
transformation to be applied in accordance with user instructions
or by computation. In particular, transformation controller 100 is
operable to compute a transformation to be applied in accordance
with one or more parameters used previously in the modelling. For
example, transformation controller 100 is operable to apply a
transformation to bases and/or content objects that is dependent
upon the identity of the reference base in which the base and/or
content object is located, so that the transformation applied
varies in accordance with the reference base identity. In this way,
bases and/or content objects in different bases are transformed in
different ways.
[0105] Transformation controller 100 is operable to apply a
transformation to every content object in each base, or to apply a
transformation selectively to some but not all of the content
objects in each base. For example, a transformation can be applied
to transform a content object with name POLYGON-1 in each base but
leave content objects with other names unchanged. The selection of
content objects to which a transformation is to be applied can be
based on different criteria, for example name, type, geometry data,
connections in a model graph, etc.
[0106] Sensor function executer 110 is operable to generate and
execute procedures to perform a mathematical test on a property of
an individual base or content object or on a plurality of bases
and/or content objects. More particularly, sensor function executer
110 is operable to identify each base (or content object) having an
attribute or connection in the graph maintained by graph manager 80
which satisfies a defined relationship. As a result, sensor
function executer 110 is operable to divide bases (or content
objects) into equivalence classes. Sensor function generator 110
permits new attributes or connections to be added to each base or
content object so that the value of the new attribute and/or
connection can be used to classify the bases or content
objects.
[0107] Model data manager 120 is operable to maintain the model
data generated by the system, and to write the data to, and
retrieve the data from, memory 30 as required. In this embodiment,
the model data comprises data defining the bases, content objects
and graph. Every base is represented by its logical data and
geometry data. The logical data contains at least a generation
index. The index may be an explicit value or may be implicit in the
order by which bases are arranged in computer memory. The geometry
data of a base comprises its origin and a rotation matrix in the
global coordinate system. A base may have additional attributes,
such as name, colour, group, etc., as described later.
[0108] A particular base in a model may be reached in three
different ways: [0109] by index in a list of bases and content
objects [0110] by matching values of additional attributes (by
name, level, etc.) [0111] by performing a search operation in the
graph (following connections in the graph)
[0112] Each content object has the following data: [0113] type of
content [0114] transformation [0115] attributes [0116] data
depending on type of content
[0117] The type content can be a type of three-dimensional object
(e.g. point, line, polygon, solid), or an operation on content
objects (e.g. intersection between line and plane, union of solids,
extrusion of a polygon in a direction).
[0118] The transformation orients the content object in relation to
a base in which the content object resides.
[0119] Attributes are from the same categories as attributes for
bases (name, colour, group, etc.).
[0120] The data part of the content object depends on its type. For
fixed types (point, line, polygon, solid, etc.), the data contain
actual geometry data (a point is represented by a list of three
coordinates, a line by two points, a solid by a list of vertices, a
list of edges and a list of faces, etc.).
[0121] When the type of content is an operation on content objects,
the data contain lists of content objects or references (pointers)
to content objects. In such case, the actual data are computed only
when needed: [0122] if another operation requires actual geometry
data [0123] for visualization of a model [0124] for export of data
from a model.
[0125] Display data generator 130, under the control of central
controller 20, is operable to generate image data for display
(including instructions to the user and images of a design created
using processing apparatus 2) and to control display device 4 to
display the image data.
[0126] Output data interface 150 is operable to control the output
of data from processing apparatus 2. In this embodiment, the output
data may comprise part or all of the model data generated by the
system, and may be output to other systems for different purposes,
such as analysis or manufacturing.
[0127] Output data interface 150 is operable to output the data for
example as data on a storage medium 152 (such as an optical CD ROM,
semiconductor ROM, magnetic recording medium, etc), and/or as a
signal 154 (for example an electrical or optical signal transmitted
over a communication network such as the Internet or through the
atmosphere). A recording of the output data may be made by
recording the output signal 154 either directly or indirectly (for
example by making a first recording as a "master" and then making a
subsequent recording from the master or from a descendent recording
thereof) using a recording apparatus (not shown). In particular,
output data interface 150 is operable to output data to a
manufacturing machine for the fabrication of an object according to
the design. In this case, data may be output for separate
components of the design, and the data may be output as CNC
(computer numerically controlled) machine-readable code, so that
the manufacturing machine can read the code directly, without
translation.
[0128] FIGS. 4 to 12 show the processing operations performed by
processing apparatus 2 to generate a design model in this
embodiment.
[0129] To assist understanding, these processing operations will be
described with reference to an example in which a model of a
building is produced comprising three generations of interacting
bases and two sets of final content objects. The generations of
bases within this example are referred to as backbone, ring and
centre generations. This requires three rounds of the processing
shown in FIG. 4--a first round to generate the backbone bases, a
second round to generate the ring bases and their content, and a
third round to generate the centre bases and their content. The
result of each round is a generation of bases (and possibly
content) added to the model.
[0130] It will, of course, be understood that the example described
is for illustration purposes only, and that different types of
objects to be fabricated (other than buildings) and/or different
numbers of generations of bases and/or different content objects
can be generated by the present embodiment.
First Round of Processing: Generating Backbone Bases (First
Generation Bases)
[0131] In the example to be described, a model is generated in a 3
dimensional Euclidean space. All of the values representing
coordinates are expressed relative to the global origin in the
standard basis of this space.
Step S100
[0132] Referring to FIG. 4, at step S100, parameter definer 50
defines global parameters for the model. In this example, the
backbone bases are the first objects in the model, and the global
parameters defined at step S100 are also used for the generation of
these bases and also some subsequent objects in the model (as will
be described later).
[0133] FIG. 5 shows the processing operations performed by
parameter definer 50 at step S100.
[0134] Referring to FIG. 5, at step S110, parameter definer 50
defines the number of bases. This may be done in accordance with
instructions from a user, by computing the number of bases using a
mathematical function, or deriving the number of bases from a
previous generation of bases.
[0135] On this round of processing, parameter definer 50 defines
the number of backbone bases in accordance with user instructions,
and in this example the number of backbone bases is defined to be
8.
[0136] At step S115, parameter definer 50 defines other global
parameters. These parameters and the values assigned in this
example comprise: [0137] floor height: 4.2 meters [0138] position
of first backbone base [0139] direction of X-axis of first backbone
base
[0140] The values for these global parameters are then stored as
initial global parameters 120.
[0141] It should be noted that, instead of defining the parameters
described above at step S110 and S115, the parameters could be
defined "in-place", that is, in the steps where the particular
function or procedure which uses the parameters is selected and
applied. For example, the parameter for the number of bases could
be defined at step 300. However, in that case, the parameter is
valid only for that particular function. In contrast, by defining
it at step S100, the parameter is an integral part of the model
data and therefore its value is subsequently accessible for the
processing in other steps.
Step S200
[0142] Referring again to FIG. 4, at step S200, reference object
selector 60 selects one or more reference objects to carry the
bases to be generated in the current round of processing. This is
performed by selecting on or more existing reference bases and/or
content objects.
[0143] In this example, each base must have a reference base--some
other base or a base that represents the orientation of a global
coordinate system (global base).
[0144] The reference base in the latter case is a virtual
base--that is, each base that does not have a previously-generated
base as its reference base is considered to have a global base as
its reference base. The reference base is important in this example
because all numeric quantities representing positions in space are
expressed relative to the position and orientation of the reference
base.
[0145] FIG. 6 shows the processing operations performed by
reference object selector 60 at step S200.
[0146] Referring to FIG. 6, at step S215, object selector 60
selects a reference coordinate system. Since backbone bases are the
first bases generated in the model in this example, object selector
60 selects, by default, a reference coordinate system on this round
of processing comprising the global Euclidean coordinate system
205. Although the global coordinate system (global base) is not a
real object, it is shown on some figures to help the viewer with
the orientation of objects on the figure.
[0147] FIG. 13a depicts the symbols used for a base in all of the
following figures, wherein: [0148] O=origin of the base [0149]
x=X-axis of the base [0150] y=Y-axis of the base [0151] z=Z-axis of
the base
[0152] Since there are no other objects at this stage of the
processing, none can be selected for parameters for functions or
procedures, and therefore step S220 in FIG. 6 is not performed on
this round of the processing.
Step S300
[0153] Referring again to FIG. 4, at step S300, base generator 70
performs processing to generate the number of bases previously
defined at step S110 (that is, 8 backbone bases on this round of
the processing) in the coordinate system(s) of the reference
object(s) selected at step S215.
[0154] FIG. 7 shows the processing operations performed at step
S300.
[0155] First, the origins (positions) of the bases are computed. As
part of this, at step S315, function selector 72 selects one or
more mathematical functions for computing the origins of the bases
in accordance with user instructions.
[0156] For this example, the following function is chosen:
Origins[i]={fx[i],fy[i],fz[i]}, {i, 1 to Number of backbone
bases}
fx[i]=A Sin [P+2Pi(i-1)F/Number of backbone bases]+1
fy[i]=B Sin [2Pi(i-1)/Number of backbone bases]
fz[i]=Floor Height(i-1)
[0157] The values of the parameters assigned in this example
are:
TABLE-US-00001 Number of backbone bases 8 FloorHeight: 4.20 A: 0.80
P: 10.00 F: 0.75 B: 0.60
[0158] The parameters Number of backbone bases and Floor Height
were defined previously in steps S110 and S115 respectively. The
other parameters are used only for this function.
[0159] At step S320, position calculator 74 uses the function and
parameter values selected at step S315 to calculate the origins of
the backbone bases. In this example, the positions P.sub.i of the
origins of the backbone bases are calculated as: [0160]
P1={0.56478311, 0.0, 0.0} [0161] P2={0.26519985, 0.42426406, 4.2}
[0162] P3={0.21328889, 0.6, 8.4} [0163] P4={0.42654739, 0.42426406,
12.6} [0164] P5={0.83309427, 0.0, 16.8} [0165] P6={1.29589853,
-0.42426406, 21.0} [0166] P7={1.65896699, -0.6, 25.2} [0167]
P8={1.79992353, -0.42426406, 29.4}
[0168] FIG. 13b shows the computed points P.sub.i in relation to
the global coordinate system G.
[0169] Bases are not just positions in space; each base also
represents a local coordinate system at that position. Accordingly,
a rotation matrix is needed for each base to be complete. This
matrix defines the amount of rotation needed to rotate the
coordinate axes of the reference base to the coordinate axes of the
generated base. In the present embodiment, orientation calculator
76 defines a default orientation for each base which is then
changed in accordance with user instructions. More particularly,
the default orientation is the same as the orientation of the
reference base (in this case global coordinate system G). This is
represented with the identity rotation matrix.
[0170] FIG. 13c shows bases B.sub.i positioned on the points
P.sub.i from FIG. 13b with each base having the default orientation
of the global coordinate system G.
[0171] At step S330, function selector 72 selects one or more
mathematical functions for additional rotation of each base. In
this embodiment, the rotation function(s) is selected in accordance
with user instructions. In the present example, the following
function is selected to compute a respective rotation matrix for
each backbone base:
R[i]=RotationAroundAxis[{0,0,1},(i-1).alpha.], {i, 1 to Number of
backbone bases}
Angle .alpha.=16.degree./(Number of backbone bases-1)
[0172] This function defines the rotation of each backbone base
B.sub.i as a function of the value of the backbone base index "i"
and rotation angle .alpha., so that the rotation of each backbone
base will be different.
[0173] At step S335, orientation calculator 76 applies the
function(s) selected at step S330 to compute a respective rotation
matrix for each backbone base, thereby generating a list 340 of
rotation matrices for the bases.
[0174] At step 345, base builder 78 puts together the base origins
generated at step S320 and the rotation matrices generated at step
S335 to define each base as a respective coordinate system
comprising a position and orientation.
[0175] As a result of this processing, data 350 defining the
backbone bases is generated and stored.
[0176] FIG. 13d shows the backbone bases C.sub.i positioned on
points the P.sub.i from FIG. 13b with applied function R[i] for
their rotation.
Step S400
[0177] Referring again to FIG. 4, at step S400, graph manager 80
inserts the bases generated at step S300 into a model graph and
records different attributes for each base.
[0178] FIG. 8 shows the processing operations performed by graph
manager 80 at step S400.
[0179] In the present example, 8 backbone bases were created as
objects at step S300. Therefore, at step S420, 8 new vertices are
inserted into the model graph. Actually, at this stage in the
processing, no model graph has previously been created, and
therefore graph manager 80 creates a model graph from scratch and
inserts the 8 vertices therein.
[0180] FIG. 14a shows the state of the model graph after step
S420.
[0181] At step S425, graph manager 80 assigns automatic attributes
to each vertex (base) in the model graph. In this embodiment, the
automatic attributes comprise:
TABLE-US-00002 Generation name: Name of the generation of bases. It
has the same value for all bases in the generation. Index: Every
base in a generation is assigned a consecutive number starting from
one for the first base created. The index is therefore a unique
identifier of the base within a particular generation. It should be
noted that the index of a base need not be explicitly defined.
Instead, for example, the index of a base may be implicitly defined
by the order in which the bases are generated or arranged in
computer memory. Name: This attribute is either unique for every
base or has the same value for all bases in a generation. Which
method is used depends on the context of a generation. For example,
bases that represent floors in a building might have distinct names
(e.g. floor1, floor2, . . . ). On the other hand, bases that
represent a type of windows might have the same name. Level: Used
for the purpose of visualization of a model. Usually it has the
same value for all bases in a generation. Colour: Used for the
purpose of visualization of a model. It defines the colour in which
a base will be rendered and displayed.
[0182] The attribute values assigned in this example comprise:
TABLE-US-00003 Generation: Backbone Index: 1-8 Name: base1-base8
Level: CENTERS Colour: 0 (white)
[0183] The combination of the attributes "generation" and "index"
(or "generation" and "name") define a unique identifier for each
base.
[0184] FIG. 14b shows the model graph after the automatic
attributes have been assigned at step S425.
[0185] Referring again to FIG. 8, additional attributes may be
selected and added at steps S430 and S435. However, in the present
example, there is no need for additional attributes for backbone
bases, so the next step is step S440, at which graph manager 80
adds automatic connections between vertices representing backbone
bases--referred to as intrageneration connections where
"intrageneration" means between vertices representing bases from
the same generation.
[0186] In the present example, there is only one automatic
intrageneration connection called "CREATION ORDER". This connection
connects the vertices in the order in which the bases were created
from first to last. Which one is first and which one last is
governed by the index "i" in all of the functions used at step
S300. This index always runs from 1 to the number of bases in the
current generation. Connections are represented as edges in the
model graph (that is, as pairs of vertices--actually indices of
vertices). The first vertex in a pair represents the starting point
of the connection and the second vertex represents the end point.
Graph manager 80 computes edges for the connection "CREATION ORDER"
with the following formula:
Edges={(I,I+1), {I,1 to number of bases in a generation-1}}
[0187] FIG. 14c shows the model graph after the processing at step
S440.
[0188] Referring again to FIG. 8, additional intrageneration
connections may be added at steps S445 and S450. However, in the
present example, there is no requirement for additional
intrageneration connections for backbone bases, and therefore the
processing at steps S445 and S450 is omitted during the current
round of processing.
[0189] At steps S455, S460 and S465, automatic intergeneration
connections and additional intergeneration connections may be added
to the model graph. However, the generation of backbone basis is
the first generation in a model, and therefore there are no
intergeneration connections to be defined at this stage in the
processing. Accordingly, steps S445, S460 and S465 are omitted on
this round of processing.
[0190] The model graph resulting from the processing at step S400
for this example is therefore as shown in FIG. 14c.
[0191] At the end of step S400, the model is in a consistent state.
As used herein, the term "consistent state" of the model means that
all of the data from bases, content objects, and attributes and
connections in the model graph are in accordance with each other
(that is, there is no base or content object without the required
attributes and connections). As a result, at step S475, the
designer and/or another user of the system has a chance to export
the model data to other systems for the purpose of visualization,
analysis, manufacturing, etc.
[0192] Which bases, content objects and other data are exported
depends on the purpose of the other system. Not all of the data
needs to be exported. For example, for quick visualization of the
model, data for only the last generation of bases need to be
exported.
[0193] Depending on the purpose of the export, data can be
formatted in different ways. For example, for visualization, only
the geometry and the attributes "Level" and "Colour" are needed.
For structural analysis, the geometry, information about the
material of content objects (contained in custom attributes--like
the attribute MATERIAL described later in this example) and
connections from the model graph are needed. For manufacturing, at
least the geometry, the material of the content objects and their
identification number (label) are needed.
Step S500
[0194] Referring again to FIG. 4, at step S500, content objects can
be inserted into the bases generated at step S300 in the current
round of processing.
[0195] In the present example, there is no need for content objects
in the backbone bases, and accordingly step S500 is omitted on this
round of the processing. Step S500 is, however, performed (and
described) for subsequent rounds.
Step S600
[0196] At step S600, additional transformations can be applied to
bases and content objects. This feature enables the present
embodiment to change the position and/or orientation of some, or
all, of the bases or some, or all, of the content objects using one
or more mathematical functions without re-defining each base or
content object individually.
[0197] In the present example, the backbone bases generated at step
S300 are reoriented in a series of transformations by
transformation controller 100.
[0198] The processing at step S600 is provided separately in this
embodiment from the processing at step S300 (at which bases were
generated and orientated) and the processing at step S500 (at which
content objects were generated and orientated) so that
transformations can be applied taking into account both the bases
and the content objects. For example, one or more content objects
added at step S500 may be used to compute a transformation to
transform bases and/or content objects.
[0199] FIG. 10 shows the processing operations performed by
transformation controller 100 at step S600.
[0200] Referring to FIG. 10, at step S630, transformation
controller 100 selects one or more functions for the transformation
of bases. In this embodiment, the transformation(s) are selected in
accordance with instructions from a user (although they could be
selected by computation).
[0201] At step S635, transformation controller 100 selects one or
more parameters to be used in the function(s) selected at step S630
for the transformation of bases. In this embodiment, the
parameter(s) are selected in accordance with user instructions
(although they could be selected by computation).
[0202] At step S640, transformation controller 100 selects one or
more functions for the transformation of content objects. In this
embodiment, the transformation(s) are selected in accordance with
user instructions (although they could be selected by
computation).
[0203] At step S645, transformation controller 100 selects one or
more parameters to be used in the function(s) selected at step S640
for the transformation of content objects. In this embodiment, the
parameter(s) are selected in accordance with user instructions
(although they could be selected by computation).
[0204] At step S650, transformation controller 100 applies the
transformation(s) selected at steps S630 and S640 using the
parameter(s) selected at steps S635 and S645, thereby generating
transformed bases and/or content objects.
[0205] The processing in FIG. 10 will be illustrated for the
present example in a case where all of the backbone bases are
transformed with the same transformation in such a way that origin
of the last base B.sub.8 lies directly over the origin of the first
base B.sub.1 (that is, the x and y coordinates of the origins of
bases B.sub.1 and B.sub.8 are the same). This transformation is
accomplished as set out below.
[0206] Consider the three points O.sub.1, O.sub.8 and O.sub.v where
O.sub.1 is the origin of base B.sub.1, O.sub.8 is the origin of
base B.sub.8 and O.sub.v is O.sub.1+{0, 0, 1}. Transformation
TR.sub.1 is a transformation needed to rotate vector
O.sub.8-O.sub.1 to vector O.sub.v-O.sub.1 through the point
O.sub.1. [0207] O.sub.1={0.56478311, 0.0, 0.0} [0208]
O.sub.8={1.79992353, -0.42426406, 29.4} [0209] O.sub.V=O.sub.1+{0,
0, 1}={0.56478311, 0.0, 1.0} [0210]
TR.sub.1=TransformationVectorToVector [O.sub.1, O.sub.8-O.sub.1,
O.sub.v-O.sub.1]
[0211] Transformation TR.sub.1 is applied only to the origins of
the backbone bases B.sub.i. The rotation part of the bases B.sub.i
is kept intact. [0212] B.sub.1=Base [T.sub.Bi, R.sub.Bi],
T.sub.Bi={x.sub.i, y.sub.i, z.sub.i} [0213] TR.sub.1=[T, R] [0214]
B.sub.i'=Base [T+RT.sub.Bi, R.sub.Bi]
[0215] After applying the transformation TR.sub.i, a correction to
each origin's z coordinate must be made. Accordingly, the Z
coordinates of the bases B.sub.i' are reset to the values of the
original bases B.sub.i. This step is needed in the present example
to preserve floor heights between backbone bases. [0216]
B.sub.i=Base [{x.sub.i, y.sub.i, z.sub.i}, R.sub.Bi] [0217]
B.sub.i'=Base [{x.sub.i', y.sub.i', z.sub.i'}, R.sub.Bi'] [0218]
B.sub.1''=Base [{x.sub.i', y.sub.i', z.sub.i}, R.sub.Bi']
[0219] FIG. 15a shows the bases B.sub.i before transformation
(illustrating that the origin of base B.sub.8 does not lie directly
over the origin of base B.sub.1) and the bases B.sub.i'' after
transformation controller 100 has applied transformation TR.sub.1
and correction to their z coordinates (illustrating that the origin
of base B.sub.8'' now lies directly over the origin of base
B.sub.1'').
[0220] A second transformation of the backbone bases turns them
upside down. This is achieved by applying a global rotation R.sub.1
to the bases B.sub.i''. Rotation R.sub.1 is defined as rotation
around global Y-axis {0, 1, 0} for 180 degrees: [0221]
R.sub.1=RotationAroundAxis [{0, 1, 0}, 180.degree.] [0222]
B.sub.i'''=R1B.sub.i''
[0223] Thereafter, a rotation R.sub.2 is applied locally--that is,
only on the rotation part of each backbone base B.sub.1'''. This is
meant to bring the X-axis of each backbone base to point again in
the direction it had before application of the global rotation
R.sub.1. [0224] R.sub.2=RotationAroundAxis [{0, 0, 1}, 180.degree.]
[0225] B.sub.i'''=Base [T.sub.Bi''', R.sub.Bi'''] [0226]
B.sub.i''''=Base [T.sub.Bi''', R.sub.2R.sub.Bi''']
[0227] The result of applying rotations R.sub.1 and R.sub.2 on
bases B.sub.i'' is shown in FIG. 15b (in which it will be seen that
base B.sub.8'''' is now the bottom base and B.sub.1'''' is now the
top base).
[0228] A final transformation TR.sub.2 transforms the backbone
bases B.sub.i'''' in such a way that the origin and orientation of
the bottom base (which, after applying rotations R.sub.1 and
R.sub.2, is now base B.sub.8'''' as described above) follows the
parameters specified in step S100. Their numerical values are:
[0229] Pos={2, -3.5, 0} [0230] X-axis direction vector
X.sub.dir={0.8, -1.25, 0}
[0231] Transformation TR.sub.2 is defined as follows: [0232]
TR.sub.2=[T, R] [0233] T=Pos [0234] X.sub.8=Direction of X-axis of
base B.sub.8'''' [0235] .alpha.=directed angle from vector X.sub.8
to vector X.sub.dir [0236] R=RotationAroundAxis [{0, 0, 1},
.alpha.] [0237] C.sub.i=TR.sub.2B.sub.i''''
[0238] The result of applying transformation TR.sub.2 on the bases
B.sub.i''''is shown in FIG. 15c.
Steps S700 and S800
[0239] Referring again to FIG. 4, at step S700, content generator
90 can add new content objects to the model, and at step S800,
graph manager 80 can perform processing to update the model
graph.
[0240] In the present example, the processing at steps S700 and
S800 is not performed during the current round of processing. More
particularly, because no new content objects are to be defined and
all of the attributes and connections have already been established
at step S400, then steps S700 and S800 are not necessary.
[0241] At this stage in the processing, the model is in a
consistent state, and therefore data can be exported to one or more
other systems, as described previously with reference to step
S475.
Step S900
[0242] At step S900, a check is performed to determine whether
another generation of bases is to be added to the model.
[0243] In the present example, the backbone bases comprise the
first generation of bases, and further generations of bases are to
be added. Accordingly, processing returns to step S100 for the next
round of processing, which will be described below.
Second Round of Processing: Generating Ring Bases (Second
Generation Bases) with Content Objects
[0244] The second generation of bases in the present example is a
generation of "ring" bases.
[0245] Each backbone base serves as a reference base (that is, a
containing base) for a specific number of ring bases to be arranged
in a ring on a plane around the backbone base.
[0246] The ring bases are generated by performing a second round of
the processing in FIG. 4, as will now be described.
Step S100
[0247] Referring to FIG. 5, at step S110, parameter definer 50
defines the number of bases for this generation of bases in
accordance with user instructions. For this example, the number is
18 new bases for each backbone base. This number is the same for
each backbone base, but it could be a different number for each
backbone base.
[0248] Parameter definer 50 then calculates the total number of
ring bases: number of backbone bases*number of bases per
ring=8.times.18=144.
[0249] At step S115, parameter definer 50 defines a value for a
specific global parameter comprising the depth of white blocks. As
will be described later, the parameter "depth of white blocks" is
used at step S700 for the creation of content objects.
[0250] In the present example, the parameter "depth of white
blocks" is set to the value 1.0.
Step S200
[0251] Referring to FIG. 6, at step S215, reference object selector
60 selects reference bases for the new ring bases. In the present
example, each backbone base is chosen as a reference base for 18
respective ring bases. The first backbone base serves as a
reference base for the first 18 ring bases, the second backbone
base serves as a reference base for the next 18 ring bases, and so
on up to the last backbone base, which serves as a reference base
for the last 18 ring bases. This relation is expressed with the
formula: [0252] I=index of ring base [0253] I.sub.ref=index of
reference backbone base
[0253] I.sub.ref [I]=Quotient [I-1, number of bases per ring]+1
[0254] Function Quotient(n, m) gives the integer quotient of n and
m
[0255] At the current stage of processing in the present example,
there are no content objects in the model, and therefore there is
no reference object to be used for parameters of functions.
Accordingly, the processing at step S220 is not required on this
round of processing.
Step S300
[0256] At step S300, base generator 70 generates the ring bases.
The number of ring bases is equal to the number of bases defined at
step S110 in this round of processing (that is, 144).
[0257] Referring to FIG. 7, at steps S315 and S320, the origins of
the bases are computed. The procedure for computing the origin of
each ring base in the present example will be described with
reference to FIG. 16.
[0258] Referring to FIG. 16, for each backbone base, the origins of
its 18 ring bases are positioned on a circle with a specific radius
in the XY plane of the backbone base. The origins are equidistantly
spaced around the perimeter of the circle, with the first origin at
0.degree. angle and the others following in the counter-clockwise
direction.
[0259] The positions of the origins of the ring bases are computed
as if they all lie in an XY plane with the global coordinate system
as a local coordinate system. After that each ring base is
transformed with appropriate transformation to lie in the same
position relative to its reference base (backbone base) as it is in
the global coordinate system.
[0260] More particularly: [0261] I=index of ring base, (runs from 1
to total number of ring bases) [0262] I.sub.ref[I]=index of
reference backbone base computed by formula from step S215 on this
round of processing
[0262] Angle .alpha.=-360.degree./number of bases per ring
Function for radii
R[I]=R.sub.fixed+(I.sub.ref[I]-1)(R.sub.2-R.sub.1)/(Number of
backbone bases-1)
Origins O[I]=R[I]{Cos [I.alpha.], Sin [I.alpha.],0}
[0263] From the function R[I] for radii, it will be seen that
I.sub.ref[I] is a variable of the function--that is, the radius of
the circle upon which the origins of the ring bases lie is
dependent upon the index I of the reference base (the backbone base
to which the ring bases belong). In other words, the radius changes
as the index I changes, so that the radius is different for each
backbone base. In FIG. 16, therefore, the radius R1 of the circle
of ring bases 1-18 is different from the radius R2 of the circle of
ring bases 19-36 and the radius R3 of the circle of ring bases
37-54. As a result, the positions of the second-generation bases
(which lie on the circles) change relative to their containing
backbone base from circle to circle. This feature of the present
embodiment enables variations in the ring bases to be introduced
throughout the model without having to define the ring bases
individually. This is particularly advantageous where a large
number of ring bases are to be defined for the model. The form and
extent of this variation is set in accordance with the mathematical
function having the index of the backbone base as a variable.
[0264] Similarly, from the function O[I], it will be seen that I is
a variable of the function. That is, the position of each
second-generation base upon its circle is dependent upon the value
of its index I. The variable I therefore acts as a variable feature
identification number which controls the position of each
second-generation base.
[0265] Although the mathematical functions R[I] and O[I] are
separate functions in the present example, it will be appreciated
that, in other examples, a single function having both I.sub.ref
and I as variables could be used to defined the position and/or
orientation of each second-generation base.
[0266] In the present example, the following values are assigned to
the parameters in the functions above:
TABLE-US-00004 number of bases per ring: 18 total number of ring
bases: 144 Number of backbone bases: 8 R.sub.fixed: 12.00 m
R.sub.1: 0.00 m R.sub.2: 3.00 m
[0267] The parameters "number of bases per ring" and "total number
of ring bases" were defined at step S100 in the current round of
processing, and the parameter "Number of backbone bases" was
defined at step S110 in the previous round during the generation of
the backbone bases.
[0268] To compute global coordinates of the origins of the ring
bases, each origin O.sub.i must be transformed with a
transformation TB[I] which is in reality a defining transformation
of the ring base's reference backbone base C[I.sub.ref [I]].
TB[I]=Transformation[C[I.sub.ref [I]]]
[0269] FIG. 17 shows the global positions of the origins O.sub.i of
the ring bases computed by position calculator 74 in accordance
with the equations above. In this figure, C.sub.i are the reference
backbone bases.
[0270] The origins of the backbone bases are computed locally to
their reference base and then transformed to the global coordinate
system. They could instead be defined directly in the global
coordinate system, but the functions used would be more complex. On
the other hand, a situation can be foreseen where functions for
computing the origins of the bases directly in the global
coordinate system would be less complex than computing them locally
(i.e., when there is no dimensional relation to the reference
bases).
[0271] When a ring base is created, its initial orientation is the
orientation of its reference base. The initial orientation of each
ring base B.sub.Ri is thus the same as is the orientation of its
reference backbone base C.sub.i. This situation is shown in FIG.
18.
[0272] At step S330, function selector 72 selects one or more
functions for additional rotation of the ring bases.
[0273] This will be described for the present example with
reference to FIG. 19a.
[0274] Referring to FIG. 19a, a function is selected to rotate the
Z-axis of each ring base so that the Z-axis points to the origin of
the ring base on the next ring which is expressed with the
following relation on the ring base indices: [0275] I=index of ring
base B.sub.Ri, [0276] I.sub.TO=index of ring base on the next
ring=I+number of bases per ring
[0277] This is achieved by applying following ransformation
T.sub.Ri on the ring base B.sub.Ri. [0278] O.sub.1=origin of ring
base B.sub.Ri, [0279] Z=Z-axis vector of base B.sub.Ri [0280]
O.sub.2=origin of ring base B.sub.R[I.sub.TO] [0281] C=origin of
reference backbone base C[I.sub.ref] [0282] P=plane from three
points O.sub.1, O.sub.2, C (order of points is important for
direction of plane's normal vector) [0283]
TR.sub.i=TransformationVectorToVector[O.sub.1, O.sub.1+Z,
O.sub.2]
[0283] B.sub.Ri'=TR.sub.iB.sub.Ri
[0284] Another condition in the present example is that the X-axis
of each ring base B.sub.Ri, should lie in the plane P that goes
through the origins O.sub.1, O.sub.2 and C (that is, the origins of
ring base B.sub.Ri, ring base B.sub.R[I.sub.TO] and reference
backbone base C[I.sub.ref]). This assures that the X-axis of the
ring base points in the general direction of the origin of its
reference base. Since the Z-axis of base B.sub.Ri' already lies on
this plane (it has been defined as the direction from origin
O.sub.1 to O.sub.2), the only thing required is to rotate base
B.sub.R1' around its Z-axis in such a way that its X-axis snaps to
the plane P. The amount of rotation R.sub.i needed is calculated
from the directed angle .alpha. between the X-axis of base
B.sub.Ri' and the plane P. [0285] X.sub.BRi'=direction of X-axis of
base B.sub.Ri', [0286] Z.sub.BRi'=direction of Z-axis of base
B.sub.Ri,
[0286] .alpha.=AngleBetween
[X.sub.BRi',(Z.sub.BRi'.times.NormalVector [P])]
[0287] As used herein, the directed angle between two vectors is
defined as follows: In general two non-parallel vectors v.sub.1 and
v.sub.2 fully define a plane. If the normal vector of this plane is
defined as a cross product of vectors v.sub.1 and v.sub.2
(n=v.sub.1.times.v.sub.2), the directed angle is then the angle
when travelling from vector v.sub.1 to vector v.sub.2 around normal
n in a counter-clockwise direction. (This means that the directed
angle is not necessarily the smallest angle between two vectors.)
[0288] R.sub.i=RotationAroundAxis [Z.sub.BRi', .alpha.]
[0288] B.sub.Ri=R.sub.iB.sub.Ri'
[0289] FIG. 19b shows the final ring bases B.sub.Ri'' after
applying transformation TR.sub.i and rotation R.sub.i.
Step S400
[0290] At step S400, graph manager 80 inserts the ring bases
generated at step S300 into the model graph and records different
attributes and connections for each ring base.
[0291] There are 144 ring bases in the present example. Therefore,
at step S420, 144 vertices are inserted into the model graph. FIG.
20 shows the model graph after the processing at step 420.
[0292] Automatic attributes are assigned to each vertex (base) by
graph manager 80 at step S425. In this example, the automatic
attributes are:
TABLE-US-00005 Generation: Rings Index: 1-144 Name: base 1-base 144
Level: RINGS Colour: 0 (white)
[0293] In the present example, at steps S430 and S435, an
additional attribute called "Ring Number" is selected and assigned
for each ring base. Ring bases are organized in rings. Within each
ring, the ring bases are characterized by the fact that they have
the same reference backbone base. Backbone bases are numbered from
1 onward and the index of each backbone base in the generation
"backbone" can therefore be considered as a ring number.
[0294] Based upon the value of the attribute "ring number", the
ring bases are partitioned into distinct non-overlapping groups
(also called equivalence classes). They can be selected separately
wherever a set of bases is needed throughout the generating
procedure. For example, when reference coordinate systems are
defined for a new generation of bases (step S215) or when content
objects are inserted (step S500) or created (step S700) in some of
the bases from the current generation of bases.
[0295] Additional attributes can be arbitrary, and thus their
values may be defined through the use of functions. For the
attribute "ring number", the function previously defined at step
S215 in this round of processing is used, which is a function for
calculating the index of the reference backbone base I.sub.ref from
the index of ring bases.
[0296] Part of the resulting model graph after assigning values for
the additional attribute "ring number" is shown in FIG. 21.
[0297] Referring again to FIG. 8, at step S440, graph manager 80
adds the automatic connection called "CREATION ORDER" between the
vertices representing ring bases. As noted previously, this
connection defines the order in which the vertices were created
from first to last. The resulting model graph is shown in FIG. 22,
in which the arrows show the creation order.
[0298] Additional intrageneration connections are selected and
defined in steps 445 and S450. They facilitate the use of the ring
bases as parameters in functions and procedures later on in the
course of the example. In the present example, four additional
connections are defined:
TABLE-US-00006 NEXT: Connects a ring base to the base adjacent to
it on the right, that has an index number greater by 1, except for
the last base on the ring which connects to the first base of the
ring TO: Connects a ring base belonging to a ring (see below) to
the analogue base on the next ring, that is, first base from ring
to the first base from the next ring, second base to the second
base from the next ring, and so on to the last base in a ring.
Because of the order of creation of the ring bases, the index of
the analogue ring base is defined as the index of the relevant ring
base plus the number of bases per ring. PREV: Reversed connection
NEXT FROM: Reversed connection TO
[0299] Ring is defined as a group of ring bases which have the same
reference backbone base, that is they have the same value of the
attribute "ring number", which is assigned in step S435 on this
round of processing. "Next ring" is thus a group of ring bases with
the consecutive value of attribute "ring number".
[0300] Functions for edges for these connections are: [0301]
n=total number of ring bases [0302] m=number of bases per ring
[0302] Edges NEXT={(I, Quotient[I-1,m]m+Mod [I,m]+1), {I,1 to
n}}
Edges TO={(I,I+m), {I,1 to n-m}}
Edges PREV={(I, Mod [I-1,m]+m(Quotient[I-1,m]-Sign [Mod
[I-1,m]]+1)), {I,1 to n}}
Edges FROM={(I,I-m), {I,m+1 to n}}
[0303] Indices of pairs are relative indices in the set of ring
bases.
[0304] Part of the resulting model graph is shown in FIG. 23
(showing the connections "NEXT" and "PREV") and FIG. 24 (showing
the connections "TO" and "FROM").
[0305] At step S455, graph manager 80 adds automatic
intergeneration connections. An intergeneration connection is a
connection that connects bases in different generations (a new base
generated in the current round of processing and an existing base
generated in a previous round of processing). In this example, a
connection called "SUBBASES" is added automatically from each
backbone base to every ring base that counts this backbone base as
its reference base. The formula for edges is: [0306]
I.sub.ref[I]=index of reference backbone base computed by formula
from previous step S215
[0306] Edges SUBBASES={(I.sub.ref[I],I), {I,1 to n}}
[0307] The first index in a pair refers to the backbone bases and
the second index refers to the ring bases. Part of the resulting
model graph is shown in FIG. 25.
[0308] In the present example, there are no additional
intergeneration connections for ring bases, and so the processing
at steps S460 and S465 is omitted.
[0309] At the end of this step, the model is in a consistent state;
therefore its data can be exported to other systems for various
purposes, as described previously.
Step S500
[0310] At step S500 in the present example, content generator 90
inserts a content object into each ring base generated at step
S300. More particularly, in this example, a point P is inserted
into each ring base in the same position relative to the ring
base's origin as its position to the global coordinate system G.
This relationship is shown in FIG. 26a.
[0311] Point P is the same for each ring base, and comprises an
example of a primary content object. In this example, the point's
coordinates {x, y, z} are defined by the user to be: P={0.4, 0.65,
0.3}.
[0312] It should be noted that, although the content object (point
P) in this example is inserted into every ring base, this need not
be the case, and instead the content object may be omitted from one
or more ring bases. Similarly, although the content object inserted
into each ring base is the same content object in this example,
different content objects could be inserted into different ring
bases. For example, each ring (that is, a group of ring bases with
the same value of the attribute "ring number") can have a different
point P.sub.r as its content object. In this case 8 (equal to the
umber of backbone bases) different content objects (points P.sub.r)
could be added to the ring bases, each point P.sub.r added only to
the ring bases which have the value of the attribute "ring number"
equal to r.
[0313] FIG. 9 shows the processing operations performed by content
generator 90 at step S500.
[0314] Referring to FIG. 9, at step S505, content importer 92
selects the external content object to be imported and its source.
In this embodiment, these processes are performed in accordance
with user instructions (although they could be performed
automatically by computation).
[0315] At step S515, content importer 92 imports the selected
content object into the system, and assigns a copy of the content
object (in this case point P) to each ring base generated at step
S300.
[0316] The points P are the first content objects in the model of
the present example. Their type is POINT and their data consist of
x, y and z coordinates. Each ring base B.sub.Ri gets its own copy
of point P. This is shown in FIG. 26b.
[0317] At step S530, graph manager 80 adds each content object
assigned at step S525 as a new vertex to the model graph. This is
performed in a similar way to the addition of a vertex for each
base at step S420 (described previously). FIG. 27 shows a part of
the model graph after step S530.
[0318] At step S535, graph manager 80 assigns the following
automatic attributes to each vertex in the model graph representing
a point P:
TABLE-US-00007 Index: 1-144 Name: bpoint Level: BPOINT Colour: 0
(white)
[0319] The combination of the attributes "index" and "name" (or the
combination "index" and "level") comprise a unique content object
identifier, from which each content object can be uniquely
identified.
[0320] FIG. 28 shows part of the model graph after step S535.
[0321] There are no additional attributes for the points P in the
present example, and so steps S545 and S550 are omitted on this
round of processing.
[0322] At step S555, graph manager 80 adds CONTENT connections to
the model graph for the content objects assigned at step S525. More
particularly, each point P has a reference ring base. The automatic
connection called "CONTENT" is added to the model graph to show
this relation for each ring base and its point. Part of the
resulting model graph is shown in FIG. 29.
[0323] In the present example, there are no additional connections
for the points P, and so steps S560 and S565 are omitted on this
round of processing.
[0324] At the end of step S500, the model is in a consistent state,
and therefore at step S575 its data can be exported to other
systems for various purposes, as described previously.
Step S600
[0325] In the present example, no additional transformations are
needed for the ring bases or their content objects (points P).
[0326] Accordingly, no processing is required at step S600, and
therefore this step is omitted on this round of processing.
Step S700
[0327] At step S700, content generator 90 creates new content
objects for the model using one or more mathematical
operations.
[0328] FIG. 11 shows the processing operations performed by content
generator 90 at step S700.
[0329] In the present example, a solid block (mesh) is inserted
into each ring base. To accomplish this, auxiliary objects are
created. Six planes are sufficient to fully bound a solid block of
the proposed shape, and a line is calculated to define two of the
planes. Each content object is created in every ring base according
to the same procedure.
[0330] The procedure for creating the content objects starts with
the creation of the line, then the planes and finally the solid
block. Although in reality steps S705 to S799 are executed 8 times
in sequence (a line, 6 planes and a mesh), the description of these
steps is made for all of the created content objects together.
[0331] At step S705, content creator 94 selects the type of each
new content object. In this embodiment, the selection is performed
in accordance with user instructions (although it could be
performed automatically). In this example, the object types are
LINE, PLANE and MESH. Lines and planes are primary content objects,
while mesh is in the category of solid content objects.
[0332] At steps S715, S720 and S730, content creator 94 selects
operations for the creation of the content object, the bases in
which the content object is to be generated and parameters for the
creation operations, respectively, with the selected operation
parameters being recorded at step S740. In this embodiment, these
selections are performed in accordance with user instructions,
although they could be performed automatically.
[0333] At step S745, content creator 94 executes the operations
selected at step S715 in accordance with the bases and parameters
selected at steps S720 and S730 to generate the same new content
object(s) in all of the bases selected at step S720. For every new
content object, the same generating procedure is executed in all of
the selected bases. This assures that if a procedure for creation
of a new content object is composed with actual data from a single
base, it can be replicated without change to all the selected bases
in the generation. The values of actual parameters may be different
for every base, but their composition (number and types of
parameters) is the same.
[0334] These processing operations will now be described in the
context of the present example.
[0335] Functions for the creation and manipulation of lines and
planes are defined directly in the programming language of the
system of the present embodiment. For meshes, an external geometric
modelling kernel is selected. In this example OpenCASCADE is
used.
[0336] The following functions are used for the creation of the new
content objects in this example:
TABLE-US-00008 Object name: Description of creation function:
Bisector Angle bisector between two directions from a given point
in space. Left plane, Oriented plane through line and point Right
plane Down plane, Oriented plane through three points Top plane
Front plane "Closest" oriented plane from 4 points (used method of
least squares to calculate closest plane) Back plane Moved and
inverted plane White block Mesh from oriented planes
[0337] FIG. 30a shows the construction of an angle bisector L in
ring base B.sub.Ri. Line L lies in a plane defined by points O,
O.sub.N and O.sub.p and bisects the angle between points OP-O-ON.
[0338] Point O=origin of ring base B.sub.Ri [0339] Point
O.sub.N=origin of ring base B.sub.Ri.fwdarw.NEXT (.dbd.Origin of
ring base B.sub.Ri+1) [0340] Point O.sub.P=origin of ring base
B.sub.Ri.fwdarw.PREV (=Origin of ring base B.sub.Ri-1) [0341] Point
O.sub.T=origin of ring base B.sub.Ri.fwdarw.TO (=Origin of ring
base B.sub.Ri+18) [0342] Point O.sub.NT=origin of ring base
B.sub.Ri.fwdarw.NEXT.fwdarw.TO (=origin of ring base B.sub.Ri+19)
[0343] Point O.sub.PT=origin of ring base
B.sub.Ri.fwdarw.PREV.fwdarw.TO (=Origin of ring base
B.sub.Ri+17)
[0344] As an aside, it should be noted that the following notation
is used herein: O.sub.end=<O.sub.start>.fwdarw.>edge 1>
[.fwdarw.<edge 2>.fwdarw. . . . .fwdarw.<edge N>
[{<attribute value>}]] shows selection of object O.sub.end by
following the connections in the model graph from object
O.sub.start to the object to which connection <edge 1>
points, from there to the object to which connection <edge 2>
points, and so on to the last object to which connection <edge
N> points. Since many connections (e.g., "SUBBASES", "CONTENT")
can have more than one value on the same object, a qualifier
(<attribute value>) has to be specified to select a
particular object. In the previous example notation,
B.sub.Ri.fwdarw.NEXT points to an object which can be selected by
following connection NEXT from object (base) B.sub.Ri. Since this
connection has only one value, no qualifiers are needed. From the
definition of the connection NEXT in step 400, the object at the
end of it is ring base B.sub.Ri+1.
[0345] FIGS. 30b, 30c and 30d show the construction of a plane from
4 points using 3 different subsets of 3 defining points. With four
points (O, O.sub.N, O.sub.NT, O.sub.T) and one of them fixed (O),
only three possible combinations of three different points are
possible: (O, O.sub.N, O.sub.NT), (O, O.sub.N, O.sub.T) and (O,
O.sub.T, O.sub.NT,). For each triplet, a different plane can be
constructed. These three different planes are depicted in FIGS.
30b, 30c and 30d, respectively.
[0346] FIGS. 31a and 31b show created content objects in two
consecutive ring bases. The labels used in these figures depict the
same objects as the labels in FIGS. 30a-30d with the following
additions: [0347] Base B.sub.N=ring base B.sub.Ri.fwdarw.NEXT
[0348] Base B.sub.NN=ring base B.sub.Ri.fwdarw.NEXT.fwdarw.NEXT
[0349] Base B.sub.T=ring base B.sub.Ri.fwdarw.TO [0350] Base
B.sub.NT=ring base B.sub.Ri.fwdarw.NEXT.fwdarw.TO [0351] Base
B.sub.NNT=ring base B.sub.Ri.fwdarw.NEXT.fwdarw.NEXT.fwdarw.TO
[0352] Base B.sub.P=ring base B.sub.Ri.fwdarw.PREV [0353] Base
B.sub.PT=ring base B.sub.Ri.fwdarw.PREV.fwdarw.TO [0354] Line
L.sub.i=angle bisector in ring base B.sub.Ri [0355] Line
L.sub.N=angle bisector in ring base B.sub.N [0356] Line
L.sub.NN=angle bisector in ring base B.sub.NN [0357] Plane
P.sub.L=plane from line L.sub.i and point O.sub.T [0358] Plane
P.sub.R=plane from line L.sub.N and point O.sub.NT [0359] Plane
P.sub.D=plane from points O.sub.PT, O.sub.T and O.sub.NT [0360]
Plane P.sub.T=plane from points O.sub.p, O and O.sub.N [0361] Plane
P.sub.F=plane from points O, O.sub.N and O.sub.T [0362] Plane
P.sub.B=inverted plane P.sub.F moved for distance d [0363] d=depth
of white blocks W.sub.i [0364] Solid block W.sub.1=mesh in ring
base B.sub.Ri [0365] Solid block W.sub.N=mesh in ring base
B.sub.N
[0366] Lines L.sub.i, L.sub.N and L.sub.NN are constructed by the
procedure illustrated in FIG. 30a in bases B.sub.Ri, B.sub.N and
B.sub.NN respectively.
[0367] Plane P.sub.L is constructed from line L.sub.i and point
O.sub.T. Line L.sub.i is represented with two points; therefore the
plane can be constructed from a line and an additional point. The
plane's normal vector lies in the same halfspace as the point
O.sub.P.
[0368] The example procedure above for creating planes shows the
importance of attributes and connection data stored in the model
graph. Using only an arithmetic function on the indices of the ring
bases would return incorrect ring bases for parameters for the
first and the last base on each ring. All of the parameters (points
needed for construction of a plane) are actually origins of ring
bases. But for the procedure to have appropriate origins of ring
bases for parameters for each ring base in which new content
objects (planes) are created, the connections NEXT, PREV and TO
must be used. The connections NEXT and PREV encode the information
about neighbouring ring bases of the relevant ring base on the same
ring, while the connection TO represents information about the
analogue ring base from the next group of ring bases.
[0369] Plane P.sub.R is constructed from line L.sub.N and point
O.sub.NT. The plane's normal vector lies in the same halfspace as
the point O.sub.NN.
[0370] Plane P.sub.D is constructed from three points O.sub.PT,
O.sub.T and O.sub.NT. The plane's normal vector lies in the
opposite halfspace as the point O.
[0371] Plane P.sub.T is constructed from three points O.sub.P, O
and O.sub.N. The plane's normal vector lies in the opposite
halfspace as the point O.sub.T.
[0372] Plane P.sub.F is constructed from three points O, O.sub.N
and O.sub.T. The plane's normal vector lies in the opposite
halfspace as the point O+X-axis [B.sub.Ri].
[0373] Plane P.sub.B is inverted plane P.sub.F, moved for distance
d in the direction of the normal vector of plane P.sub.B.
P.sub.B=MovePlane [InvertPlane [P.sub.F],d]
[0374] Solid block W.sub.i is a mesh constructed from planes
P.sub.L, P.sub.R, P.sub.D, P.sub.T, P.sub.F, P.sub.B. Each plane
divides a space into two halfspaces and one of them can be
considered full. By convention, the halfspace in which the normal
vector of the plane points is considered empty, the other half as
solid. Solid block W.sub.i is then constructed as an intersection
of six planes. The normal vectors of the six bounding planes are
oriented in such a way that they point outwards of the resulting
solid block.
[0375] From the above, it will be understood that each content
object is generated in accordance with a procedure comprising a
series of steps using at least one mathematical function.
Furthermore, the procedure for the generation of each content
object is dependent upon a plurality of ring bases (even though the
content object is defined in the local coordinate system of only
one base). Accordingly, because the arrangement of ring bases
varies throughout the model (because the ring bases were defined so
that they vary in accordance with the identity of the backbone base
to which they belong), then the content objects also vary
throughout the model in accordance with the variations of the ring
bases. However, it should be noted that the present embodiment does
not provide a separate definition of each content object in order
to achieve this variation--instead, a single definition is provided
using at least one mathematical function and a plurality of bases.
If the designer subsequently changes the arrangement of bases, then
the system will automatically regenerate the content objects in
accordance with the definition using the new arrangement of bases
and the mathematical function(s) for the definition of the content
objects. As a result, the system adapts the content objects to any
change in the bases.
[0376] In the present example, new content objects are not created
in all ring bases. More particularly, the definition of planes and
white block depends on the data of the ring bases from two
consecutive rings. However, each base on the last ring has no TO
connection, meaning that there are no more ring bases. Accordingly,
for bases on this ring (ring number 8), no new content objects are
created.
[0377] FIG. 31b shows the final solid blocks W.sub.i and W.sub.N,
belonging to ring bases B.sub.Ri and B.sub.N respectively. Block
W.sub.N is rendered in cross-section.
[0378] In the present embodiment, as well as geometric data,
content objects also keep information on object type, selected
creation function(s) and references to the bases and/or objects
that serve as parameters for the creation function(s). For example,
the object "White block" Wi stores following non-geometric
data:
TABLE-US-00009 Object type: Mesh Geometric modelling kernel:
OpenCASCADE Creation function: Mesh from oriented planes (from
OpenCASCADE) Pointers to reference objects: Base B.sub.Ri Planes
P.sub.L, P.sub.R, P.sub.D, P.sub.T, P.sub.F, P.sub.B Values of
reference parameters: Numeric parameter d
[0379] Representation of a content object with operation and
references to parameter objects for an operation enables the system
to keep track of the history of a content object. In addition, the
system can reevaluate the object anytime, possibly with altered
source object parameters.
[0380] After the creation of each content object, its validity is
checked by content creator 94 at steps S750 and S755. This
processing is performed in this embodiment because not all
combinations of input data can produce valid objects. For example,
a line is defined with two distinct points. If the points are the
same, then the line is not defined properly, it is not valid, and
cannot be used in other operations. Each type of object has its own
set of criteria that must be satisfied for successful validation.
Simple objects like points, lines, planes, can be easily checked.
More complex ones like meshes and other solid objects may need
special functions to be properly checked. In this embodiment, these
functions are provided by the geometric modelling kernel used for
computing the solid objects and are executed automatically (that
is, the creation function fails if the resulting object is not
properly formed). In the event that a validation function is not
provided automatically, the present embodiment allows for a
validation function to be selected by content creator 94 at step
S750 in accordance with user instructions.
[0381] In this example, the following validation checks are
performed: [0382] Line: check for points not to be coincident (line
vector must be non-zero) [0383] Plane: check for points not to be
collinear (normal vector must be non-zero) [0384] Mesh: validated
implicitly by geometric modelling kernel that performs the creation
function
[0385] After it is determined at step S760 that a created content
object has been validated, graph manager 80 adds the object as a
new vertex to the model graph at step S765.
[0386] In the present example, for each ring base, 8 new vertices
are inserted into the model graph. FIG. 32 shows part of the model
graph with new vertices for the content objects in ring bases with
indices I, I+1 and I+18.
[0387] At step S770, graph manager 80 assigns automatic attributes
to each new vertex in the model graph representing a new content
object. In the present embodiment, the automatic attributes
assigned by graph manager 80 to a content object comprise:
TABLE-US-00010 Index Name Level Colour I Bisector BISECTOR 0 I Left
plane PL-LEFT 0 I Right plane PL-RIGHT 0 I Down plane PL-DOWN 0 I
Top plane PL-TOP 0 I Front plane PL-FRONT 0 I Back plane PL-BACK 0
I White block BLOCK 0
[0388] At step S775, graph manager 80 selects any additional
attributes to be added for a content object in accordance with user
instructions, and at step S780, adds the additional attribute(s) to
the model graph.
[0389] In the present example, an additional attribute called
"Material" is selected and added for the object "White block". In
this example, the attribute has the same value for all White
blocks: STEEL
[0390] FIG. 33 shows the same part of the model graph as FIG. 32
with the attributes added at steps S770 and S780 for the present
example.
[0391] At step S790, graph manager 80 adds a CONTENT connection to
the model graph for each new content object.
[0392] In the present example each new content object has a
reference ring base. Accordingly, at step S790, the automatic
connection called "CONTENT" is added to the model graph to show
this relation between the reference ring base and the new content
object. Part of the resulting model graph is shown in FIG. 34.
[0393] At the end of step S700, the model is in a consistent state,
and therefore at step S799 its data can be exported to other
systems for various purposes, as described previously.
Step S800
[0394] Step S800 is the last step in the generation of ring bases.
In this step, sensor function executer 110 generates and executes
one or more so-called sensor functions to test a property of the
bases or content objects and to divide the bases or content objects
into equivalence classes in dependence upon the results of this
test.
[0395] In the present example, sensor function executer 110
classifies bases into two equivalence classes. As will be described
later, the system subsequently generates content objects such that
the content objects depend upon the equivalence class to which
their reference base belongs.
[0396] FIG. 12 shows the processing operations performed at step
S800.
[0397] Referring to FIG. 12, at step S805, sensor function executer
110 defines one or more attribute(s) and/or one or more
connection(s) on which a sensor function is to operate. More
particularly, sensor function executer 110 may select an existing
attribute or connection or instead may define a new attribute or
connection.
[0398] In the present example, the new attribute "CURVATURE" is
added to each ring base. This attribute may take one of two
possible values, "+" and "-" (which is calculated later), such that
bases with "+" CURVATURE fall within one equivalence class and
bases with "-" CURVATURE fall within another equivalence class.
[0399] At step S830, sensor function executer 110 defines a sensor
function, Sensor [I], to be used in calculating values of the
attribute(s) and/or connection(s) defined at step S805. If an
existing attribute or connection is selected at step S805 which
already has stored values, then step S830 is omitted.
[0400] In the present example, the following sensor function Sensor
[I] is defined: [0401] Base C [I.sub.ref [I]]=I-th ring base's
reference backbone base. [0402] Point O.sub.C=Origin of backbone
base C [I.sub.ref [I]] [0403] Base B.sub.Ri=I-th ring base [0404]
Point O.sub.Ri=Origin of base B.sub.Ri [0405] Point O.sub.F=Origin
of base B.sub.Ri.fwdarw.FROM (=Origin of base B.sub.Ri-18) [0406]
Point O.sub.T=Origin of base B.sub.Ri.fwdarw.TO (=Origin of base
B.sub.Ri+18) [0407] Plane PL1=PlaneFrom3Points [O.sub.F, O.sub.T,
O.sub.C] [0408] Plane PL [I]=plane orthogonal to the plane PL1 with
a normal vector pointing away from point O.sub.C. [0409] nrb=number
of bases per ring [0410] N=total number of ring bases
[0410] Sensor [I]=signed distance from plane PL[I], {I, nrb+1 to
N-nrb}
[0411] At step S835, sensor function executer 110 selects criteria
data to be applied to values computed using the sensor function
Sensor [I] in order to divide the bases/content objects into
equivalence classes.
[0412] In this example, the following criteria data are
selected:
CURVATURE [ I ] = { - , Sensor [ I ] < 0 + , Sensor [ I ]
.gtoreq. 0 ##EQU00001##
[0413] Broadly speaking, the sensor function Sensor [I] and the
criteria data define values of the attribute CURVATURE which
represent the curvature of the surface of the model in the vicinity
of a ring base. If the curvature in the vertical direction in the
immediate vicinity of a ring base is convex, then the CURVATURE
value is "+" for that ring base. On the other hand if the curvature
is concave, the value is "-".
[0414] At step S840, sensor function executer 110 selects objects
to which the sensor function Sensor [I] and criteria data are to be
applied.
[0415] In the present example, the sensor function is well defined
only for the ring bases on rings 2 to 7. This is because the ring
bases from the first ring (ring number 1) have no FROM connection
and the ring bases from the last ring (ring number 8) have no TO
connection. The values of the sensor function for ring bases on the
last ring are not needed because there are no "white blocks"
content objects in them. On the other hand, the ring bases from the
first ring should be classified and therefore the sensor function
should return an appropriate value for them. To achieve this, in
this example, the curvature of the ring bases from the second ring
is "continued" to the bases on the first ring:
Sensor [I]=Sensor [I+18], {I,1,nrb}
[0416] After, selecting the objects for processing, sensor function
executer 110 applies the sensor function Sensor [I] to the selected
objects and determines the value of the attribute CURVATURE for
each object in accordance with the sensor function value and the
criteria data selected at step S835.
[0417] Thus, in the present example, application of the sensor
function Sensor [I] and the criteria data above divides the ring
bases into two equivalence classes--that is, ring base having "+"
CURVATURE and ring bases having "-" CURVATURE.
[0418] FIGS. 35a, 35b and 35c show the distribution of these two
equivalence classes over the model of the present example. To
better see the difference between the convex and concave
curvatures, the white blocks generated in step 700 are shaded
differently according to the value of attribute "CURVATURE". FIGS.
35b and 35c show only blocks in ring bases having a value of the
attribute CURVATURE "+" and "-" respectively.
[0419] At step S845, graph manager 80 adds the attribute(s) and
calculated value(s) therefor to the model graph.
[0420] FIG. 36 shows part of the model graph with the values of the
attribute "CURVATURE" assigned to the vertices representing ring
bases.
[0421] At the end of this processing, the generator is in a
consistent state, and therefore its data can be exported to other
systems for various purposes at step S855, as described
previously.
Step S900
[0422] The generation of ring bases is the second generation of
bases in the example model. The generation of centre bases comes
next, and therefore processing returns to step S100 for another
round of processing to add these bases.
Third Round of Processing: Generating Centre Bases (Third
Generation Bases) with Content
[0423] The third and last generation of bases in the present
example is a generation of centre bases. As will be explained in
more detail below, each ring base on all but the last ring serves
as a reference base for a single centre base.
Step S100
[0424] At step S110 parameter definer 50 defines the number of
bases for this generation of bases in accordance with instructions
from the user.
[0425] In the present example, the number of centre bases is equal
to the total number of ring bases minus the number of ring bases on
the last ring, that is 144-18=126 bases:
Total number of centre bases=total number of ring bases-number of
bases per ring=126
[0426] The number of bases is the only initial global parameter for
this generation of bases in the present example, and therefore the
processing at step S115 is omitted.
Step S200
[0427] At step S215, reference object selector 60 selects reference
bases for the new centre bases. In the present example, each of the
ring bases with index 1 to 126 are chosen as a reference base for a
single centre base.
[0428] At step S220, reference object selector 60 selects existing
objects to be used for the definition of the centre bases.
[0429] For the creation of centre bases and then content objects in
them, references to existing generations of bases and content
objects are made. More particularly, at step S220 in the present
example, the following sets of bases and content objects are
selected:
TABLE-US-00011 Bases: ring bases Content objects (all from ring
bases): bpoint Left plane Right plane Top plane Down plane
Step S300
[0430] At steps S300 base generator 70 constructs the centre
bases.
[0431] First, the origins of the bases are computed at steps S315
and S320. More particularly, for the present example, the following
procedure is selected for computation of the base origins:
[0432] For each centre base C.sub.i, its reference ring base
B.sub.Ri with neighbouring bases and their content objects are
needed. Neighbouring bases are defined as bases following
connections in the model graph labelled NEXT, TO and NEXT.fwdarw.TO
from base B.sub.Ri. [0433] Base B.sub.Ri=reference base [0434]
Point O.sub.Ri=origin of base B.sub.Ri [0435] Point
P.sub.N=B.sub.Ri.fwdarw.NEXT.fwdarw.CONTENT {Name: bpoint} [0436]
Point P.sub.NT=B.sub.Ri.fwdarw.NEXT.fwdarw.TO.fwdarw.CONTENT {Name:
bpoint} [0437] Point O.sub.T=Origin of base B.sub.Ri.fwdarw.TO
[0438] The origin O of the I-th centre base C.sub.i is computed as
the arithmetic mean of points O.sub.Ri, P.sub.N, P.sub.NT and
O.sub.T:
I=(O.sub.Ri+P.sub.N+P.sub.NT+O.sub.T)/4
[0439] As a result, the origin O of each centre base is dependent
upon two existing bases (the origins O.sub.Ri and OT belonging to
these bases) and two existing content objects (the points P.sub.N
and P.sub.NT). The origin O of each centre base is therefore an
object that is dependent upon bases and content objects from
different groups of ring bases. More particularly, the origins
O.sub.Ri and OT are each from different (consecutive) rings (groups
of bases based upon the value of the attribute "ring number").
Similarly, the points P.sub.N and P.sub.NT are also each contained
in ring bases from consecutive rings.
[0440] FIG. 37a shows points from the definition above.
[0441] The initial orientation of centre base C.sub.i is the same
as the orientation of its reference ring base B.sub.Ri. This
situation is shown in FIG. 37b.
[0442] To define the final orientation of centre base C.sub.i,
additional rotations are computed at steps S330 and S335. Firstly,
functions for these rotations are defined at step 330. FIGS. 37c
and 37d show the designer's intent for the orientation of the
centre bases in the present example.
[0443] Referring to FIG. 37c, a first rotation rotates the X-axis
of the centre base C.sub.i around its Z-axis in such a way that it
points in the direction of a vector from point O.sub.Ri to point
P.sub.N. The functions for this rotation are therefore: [0444]
X.sub.Ci=direction of X-axis of base C.sub.i [0445]
Z.sub.Ci=direction of Z-axis of base C.sub.i [0446] dir=vector
P.sub.N-O.sub.Ri, [0447] .alpha.=AngleBetween [X.sub.Ci, dir]
[0448] R.sub.i=RotationAroundAxis [Z.sub.Ci, .alpha.]
[0449] The rotation R.sub.i is applied locally, that is, only on
the rotation part of base C.sub.i. [0450] C.sub.i=Base [T.sub.Ci,
R.sub.Ci] [0451] C.sub.i'=Base [T.sub.Ci, R.sub.iR.sub.Ci]
[0452] A second rotation orients the Z-axis of the centre base
C.sub.i vertically, as shown in FIG. 37d. This rotation is given
by: [0453] O=origin of centre base C.sub.i' [0454] Z=Z-axis vector
of base C.sub.i' [0455] v={0, 0, 1} [0456]
TR.sub.i=TransformationVectorToVector [O, O+Z, O+v]
[0456] C.sub.i''=TR.sub.iC.sub.i'
[0457] FIG. 38 shows final centre bases C.sub.i'' after applying
rotation R.sub.i, and transformation TR.sub.i.
Step S400
[0458] At Step S400, graph manager 80 inserts vertices representing
the centre bases into the model graph.
[0459] There are 126 centre bases in this example. Therefore, at
step S420, 126 vertices are inserted into the model graph. FIG. 39a
shows part of the model graph after the processing at step S420.
New vertices for the centre bases are shown in the ring bases with
indices I, I+1, I+18 and I+19. These centre bases have indices J,
J+1, J+18 and J+19 respectively. Indices I and J run from 1 to
number of centre bases.
[0460] At step S425, graph manager 80 assigns automatic attributes
for the centre bases. In this example, the automatic attributes
comprise:
TABLE-US-00012 Generation: Centers Index: 1-126 Name: centerbase
Level: BCENTERS Colour: 0 (white)
[0461] As before, the combination of the attributes "Generation"
and "Index" comprise a unique identifier for each centre base.
[0462] FIG. 39b shows the same part of the model graph as FIG. 39a
with the automatic attributes added for the centre bases.
[0463] There are no additional attributes for the centre bases in
the present example, and therefore the processing at steps S430 and
S435 is omitted on this round of the processing.
[0464] At step S440, graph manager 80 adds the automatic
intrageneration connection "CREATION ORDER" (described previously)
between the vertices of the model graph representing the centre
bases. Part of the resulting model graph is shown in FIG. 40.
[0465] In the present example, there are no additional
intrageneration connections between the centre bases, and therefore
the processing at steps S445 and S450 is omitted on this round of
the processing.
[0466] At step S445, graph manager 80 adds automatic
intergeneration connections. In the present example, the connection
called "SUBBASES" is added automatically from each ring base to the
centre base that has this ring base as its reference base. The
formula for edges is: [0467] index of reference ring base I=1 to
total number of centre bases [0468] index of centre base J[I]=I
[0468] Edges SUBBASES={(I,J [I]), {I,1 to total number of centre
bases}}
[0469] The first index in a pair refers to the ring bases and the
second index refers to the centre bases. Part of the resulting
model graph is shown in FIG. 39c.
[0470] In the present example, there are no additional
intergeneration connections for the centre bases, and therefore the
processing at steps S460 and S465 is omitted on this round of the
processing.
[0471] At the end of this step, the generator is in a consistent
state, and therefore its data can be exported to other systems for
various purposes at step S475.
Step S500
[0472] At step S500, content generator 90 inserts content objects
into each centre base generated at step S300. In the present
example, an invariant polygon F and points P.sub.L, P.sub.R,
P.sub.B and P.sub.T are inserted into each centre base at the same
positions relative to the base's origin as their positions relative
to the global coordinate system G. This relationship is shown in
perspective view in FIG. 41a.
[0473] More particularly, in the present example, content importer
92 performs processing at steps S505, S515 and S525 to import the
polygon F and the points P.sub.L, P.sub.R, P.sub.B and P.sub.T into
the system and assign a copy of each imported polygon and point to
each centre base.
[0474] Polygon F is a primary content object. In this example, the
polygon is created in an outside CAD system and its coordinates are
then transferred to the system through a plain ASCII file. The
coordinates of its points are: [0475] F={{-2.1, 0.0, -2.1}, {2.1,
0.0, -2.1}, {2.1, 0.0, 2.1}, {-2.1, 0.0, 2.1}}
[0476] Points P.sub.L, P.sub.R, P.sub.B and P.sub.T are also
brought in the system from the outside CAD system in the present
example. These content objects fall into the category of primary
content objects, meaning that they can be changed subsequently by
the system. Their coordinates are: [0477] P.sub.L={-0.4, 0.0, 0.0}
[0478] P.sub.R={0.4, 0.0, 0.0} [0479] P.sub.B={0.0, 0.0, -0.4}
[0480] P.sub.T={0.0, 0.0, 0.4}
[0481] Each centre base C.sub.i gets its own copy of these content
objects at step S525. This situation is shown in perspective view
in FIG. 41b.
[0482] At step S530, graph manager 80 inserts vertices
corresponding to the new content objects into the model graph. For
each added content object in each centre base, a new vertex is
inserted into the model graph. This means that a total of 630 new
vertices are added (126 centre bases times 5 content objects). FIG.
42a shows part of the model graph with added vertices.
[0483] At step S535, graph manager 80 assigns the following
automatic attributes to each new vertex:
TABLE-US-00013 Index Name Level Colour I Invariant INVARIANT 0 I
pleft POUT 0 I pright POUT 0 I pbottom POUT 0 I ptop POUT 0
[0484] FIG. 42b shows the same part of the model graph as FIG. 42a
with added automatic attributes for the content objects.
[0485] For the content objects imported in this step, there are no
additional attributes in the present example. Accordingly, the
processing at steps S545 and S550 is omitted.
[0486] At step S555, graph manager 80 assigns a CONTENT connection
(as described previously) to each content object.
[0487] Each content object has a reference centre base. The
automatic connection called "CONTENT" is added to the model graph
to show this relationship between each centre base and each of the
5 imported content objects for that centre base. Part of the
resulting model graph is shown in FIG. 42c.
[0488] In the present example, there are no additional connections
for the content objects imported in this step, and therefore the
processing at steps S560 and S565 is omitted on this round of
processing.
[0489] At the end of this step, the model is in a consistent state,
and therefore its data can be exported to other systems for various
purposes at step S575.
Step S600
[0490] At step S600, transformation controller 100 applies
additional transformations to the points P.sub.L, P.sub.R, P.sub.B
and P.sub.T imported at step S500, while keeping the centre bases
C.sub.1 unchanged.
[0491] More particularly, transformation controller 110 selects
functions for transforming each of the points P.sub.L, P.sub.R,
P.sub.B and P.sub.T at step S640 and selects parameters for the
functions at step S645 before applying transformations in
accordance with the selected functions and parameters at step S650.
In the present example, transformations for each point P.sub.L,
P.sub.R, P.sub.B and P.sub.T are computed by functions dependent
upon the index of the reference centre base for the point. The
functions differ from point to point in parameters only. The
definition of the transformation function will be explained with
reference to FIG. 43a.
[0492] Consider a circle in an XZ plane (that is, the same plane as
the added polygon F) with a centre A and radius r. Points on the
circle can then be computed with a formula: [0493] angle
.alpha..sub.s=start angle [0494] angle .alpha.=amount of rotation
in one step
[0494] P[I]=A+r{Cos [.alpha..sub.s+(I-1).alpha.], 0, Sin
[(.alpha..sub.s+(I-1).alpha.]}, [0495] I=1 to number of centre
bases
[0496] The parameters r, .alpha..sub.s and .alpha. are different
for each point P.sub.L, P.sub.R, P.sub.B and P.sub.T. The centre of
circle A is computed from each point by adding a displacement
vector d which is also different for each point.
[0497] The formulae selected at step S640 for computing the
translation of each point are as follows:
Transformed point P.sub.LTi=P.sub.L[I]+d.sub.L+r.sub.L{Cos
[.alpha..sub.SL+(I-1).alpha..sub.L],0, Sin
[(.alpha..sub.SL+(I-1).alpha..sub.L]}
Transformed point P.sub.RTi=P.sub.R[I]+d.sub.R+r.sub.R{Cos
[(.alpha..sub.SR+(I-1).alpha..sub.R],0, Sin
[.alpha..sub.SR+(I-1).alpha..sub.R]}
Transformed point P.sub.BTi=P.sub.B[I]+d.sub.B+r.sub.B{Cos
[(.alpha..sub.SB+(I-1).alpha..sub.B],0, Sin
[.alpha..sub.SB+(I-1).alpha..sub.B]}
Transformed point P.sub.TTi=P.sub.T[I]+d.sub.T+r.sub.T{Cos
[.alpha..sub.ST+(I-1).alpha..sub.T],0, Sin
[.alpha..sub.ST+(I-1).alpha..sub.T]}
[0498] The parameters selected at step S635 are:
TABLE-US-00014 Point D r .alpha..sub.S .alpha. P.sub.L {0, -2, 0}
1.7 0.degree. 45.degree. P.sub.R {0, -2, 0} 1.7 0.degree.
45.degree. P.sub.B {0, -2, 0} 1.7 90.degree. 45.degree. P.sub.T {0,
-2, 0} 1.7 90.degree. 45.degree.
[0499] Another transformation is carried out on polygon F and
points P.sub.LT, P.sub.RT, P.sub.BT and P.sub.TT, based on the
value of the attribute "CURVATURE" (previously calculated at step
S800 in the second round of the processing) of ring base B.sub.Ri,
which is a reference base for centre base C.sub.i, which in turn
holds these content objects. More particularly, if the CURVATURE
value is "-", the transformation TM is carried out: [0500]
B.sub.Rj=ring base for which value of attribute "CURVATURE" is "-"
[0501] C=centre base B.sub.Rj<SUBBASES {centrebase} [0502]
TM=MirrorTransformationThroughPlane [PlaneXZ [C.sub.j]]
[0502] mirrored polygon F.sub.j=TMF
mirrored point P.sub.LTj=TMP.sub.LT
mirrored point P.sub.RTj=TMP.sub.RT
mirrored point P.sub.BTj=TMP.sub.BT
mirrored point P.sub.TTj=TMP.sub.TT
[0503] As a result of applying the addition transformation in this
way, the polygon F and points P.sub.LT, P.sub.RT, P.sub.BT and
P.sub.TT have a final form which is different depending upon
whether their reference ring base B.sub.Ri has a "+" ve CURVATURE
or a "-" ve CURVATURE. In other words, the final form of the
polygons and points (content objects) is dependent upon the
equivalence class of their reference base previously determined at
step S800 in the second round of processing.
[0504] FIG. 43b shows the transformed and mirrored content objects
in base C.sub.j after transform controller 100 has applied the
transformations above at step S650.
Step S700
[0505] The next (and final) step in this round of the processing,
and consequently in this example, is step S700. In this step,
content generator 90 generates further content objects for the
model.
[0506] In the present example, the content object to be added in
this step is a solid block (mesh) inserted into each centre base.
Six planes as auxiliary objects are used for its creation. This
solid block is at the end trimmed with some of the planes created
at step 700 during the second round of the processing (that is, the
round to generate the ring bases). Each new content object is
created in each centre base according to the same procedure.
[0507] The procedure for creating each new content object starts
with the creation of planes, followed by the creation of a solid
block, which is then trimmed with planes created during the
processing of the second round. Although in reality steps S705 to
S799 in FIG. 11 are executed 8 times in sequence (6 planes, and two
meshes), the description of these steps will be made for all of the
created content objects together. At the end of the creation of
each content object (step S799), the model is in a consistent
state, therefore its data can be exported to other systems for
various purposes.
[0508] At step S705, content creator 94 selects the type of each
new object. In this example, the object types for the new objects
are PLANE and MESH.
[0509] At steps S715, S720 and S730, content creator 94 selects the
operation(s) for the creation of each new content object, the bases
in which the content object is to be generated, and parameters for
the operation(s) respectively, with the parameters then being
recorded at step S740.
[0510] In this example, the following functions are selected:
TABLE-US-00015 Object name: Description of creation function: All
planes Oriented plane through three points BIL Mesh from oriented
planes BIL cut Cut mesh with oriented plane
[0511] The functions "Oriented plane through three points" and
"Mesh from oriented planes" were described previously with
reference to step S700 in the second round of processing. The
function "Cut mesh with oriented plane" is a function that performs
a difference operation between a solid object represented as a mesh
and a solid halfspace defined with a plane.
[0512] For the creation of the auxiliary planes in centre base
C.sub.i, the following objects are needed. [0513] polygon F [0514]
point P.sub.LTi=transformed point P.sub.L from step S650 [0515]
point P.sub.RTi=transformed point P.sub.R from step S650 [0516]
point P.sub.BTi=transformed point P.sub.B from step S650 [0517]
point P.sub.TTi=transformed point P.sub.T from step S650
[0518] It should be noted that the positions of the points
P.sub.LTi, P.sub.RTi, P.sub.BTi and P.sub.TTi were calculated at
step S650 using a function dependent upon the index of the
reference base in which the points lie. Accordingly, by using these
points to generate content objects in this step, the content
objects themselves are also dependent upon the reference base
indexes.
[0519] These objects are shown in FIG. 44a. FIG. 44b shows the
definition of the auxiliary planes L, R, D, T, P and B. All of them
are defined by three points. The points F.sub.i represent the
vertices of the polygon F.
[0520] Plane L is constructed from three points P.sub.LTi, F.sub.1
and F.sub.4. The plane's normal vector lies in the opposite
halfspace to the point F.sub.2.
[0521] Plane R is constructed from three points P.sub.RTi, F.sub.2
and F.sub.3. The plane's normal vector lies in the opposite
halfspace to the point F.sub.1.
[0522] Plane D is constructed from three points P.sub.BTi, F.sub.1
and F.sub.2. The plane's normal vector lies in the opposite
halfspace to the point F.sub.3.
[0523] Plane T is constructed from three points P.sub.TTi, F.sub.3
and F.sub.4. The plane's normal vector lies in the opposite
halfspace to the point F.sub.1.
[0524] Plane B is constructed from three points F.sub.1, F.sub.2
and F.sub.3. The plane's normal vector lies in the opposite
halfspace to the point P.sub.LTi.
[0525] Plane P is constructed from three points P.sub.LTi,
P.sub.BTi and P.sub.RTi. The plane's normal vector lies in the
opposite halfspace to the point F.sub.1.
[0526] FIG. 44c shows different planes R versus R' and D versus D'
constructed from different positions of points P.sub.RTi v.
P.sub.RTj and P.sub.BTi v. P.sub.BTj. Points P.sub.RTj and
P.sub.BTj came from different centre bases C.sub.j and represent
the change imposed by the transformation functions from step 600
when the index of centre base changes from i to j.
[0527] FIG. 44d shows the final solid block S.sub.i, belonging to
centre base C.sub.i. Solid block S.sub.i is a mesh constructed from
the intersection of the six planes L, R, D, T, P and B.
[0528] The last operation in this example trims the solid block Si
with planes from ring base B.sub.Ri, which is a reference base for
centre base C.sub.i, which in turn holds solid block Si. [0529]
Base B.sub.Ri=reference ring base for centre base C.sub.i [0530]
Base C.sub.i=centre base B.sub.Ri.fwdarw.SUBBASES{centrebase}
[0531] Plane P.sub.L=plane B.sub.Ri.fwdarw.CONTENT{Left plane}
[0532] Plane P.sub.R=plane B.sub.Ri.fwdarw.CONTENT{Right plane}
[0533] Plane P.sub.D=plane B.sub.Ri.fwdarw.CONTENT{Down plane}
[0534] Plane P.sub.T=plane B.sub.Ri.fwdarw.CONTENT{Top plane}
[0535] Solid block W=mesh B.sub.Ri.fwdarw.CONTENT{White block}
[0536] The resulting solid block S.sub.C is constructed from solid
S.sub.i by subtracting inverted planes P.sub.L, P.sub.R, P.sub.D,
P.sub.T from it. This step assures that the final solid block
S.sub.C fits into the space bound by the solid block W, which was
constructed at step S700 in the second round of processing. This
assurance comes from the fact that the same planes are used in the
construction of solid blocks W and S.sub.C.
[0537] After the creation of each object at step S745, its validity
is checked at step S755. In this step of the present example, the
following validation checks are performed: [0538] Plane: check for
points not to be collinear (normal vector must be non-zero) [0539]
Mesh: used implicitly by geometric modelling kernel that performs
the creation function
[0540] At step S765, graph manager 80 adds new vertices to the
model graph corresponding to the new objects created at step S745.
In the present example, for each centre base, 8 new vertices are
inserted into the model graph. FIG. 45a shows part of the model
graph with the new vertices for the content objects in two
consecutive centre bases.
[0541] At step S770, graph manager 80 assigns the following
automatic attributes to each vertex representing a new content
object:
TABLE-US-00016 Index Name Level Colour I Left plane BIL-LEFT 0 I
Right plane BIL-RIGHT 0 I Down plane BIL-DOWN 0 I Top plane BIL-TOP
0 I Front plane BIL-FRONT 0 I Back plane BIL-BACK 0 I BIL BIL 2 I
BIL cut BIL-CUT 2
[0542] At steps S775 and S780, graph manager 80 assigns an
additional attribute for the objects BIL and "BIL cut" called
"Material". In the present example, this attribute has the same
value for all objects: GLASS
[0543] FIG. 45b shows the same part of the model graph as FIG. 45a
with the attributes added for the content objects.
[0544] Each new content object has a reference centre base. At step
S790, graph manager 80 adds the automatic connection called
"CONTENT" to the model graph to show the relationship between each
centre base and its new content object. Part of the resulting model
graph is shown in FIG. 45c.
Step S800
[0545] In the present example, step S800 is not necessary in the
current round of processing. This is because the content objects
created at step S700 are the last objects constructed in the
present example, and therefore no additional attributes or
connections to bases or objects in the model are needed.
Step S900
[0546] The generation of the centre bases is the last generation of
bases in this example.
[0547] FIG. 46 shows the resulting model after completion of all of
the steps in the three rounds of processing.
[0548] The ring bases, centre bases and solid objects named BIL are
shown. The resulting model is clearly divided into two distinct
regions A and B, which correspond to the partition of the ring
bases into two equivalence classes based upon the attribute
"CURVATURE" defined at step S800 in the second round of processing
(refer to FIG. 35a). Region A is based on the ring bases with
positive curvature and region B on the ring bases with negative
curvature.
[0549] Objects in region A have their tips pointing outwards, while
objects in region B have their tips pointing inward. On objects
from region A, the relative position of their tips against the
backplane of the object (made from polygon F; refer to the
description of steps S500 and S700 in this round of processing)
follow a distinct sinusoidal pattern. This effect is the result of
the parameters used to position the points P.sub.LT, P.sub.RT,
P.sub.BT and P.sub.TT (described at step S600 in the third round of
processing and shown in FIGS. 43a and 43b).
[0550] The influence of the backbone bases can also be seen on the
right edge of region B. If the backbone bases were vertically
aligned on top of each other, the edge of the region B would be
linear (albeit not vertical, because the radius of the ring bases
also changes from ring to ring; increasing from 12 m on the top
(first) ring to 15 m on the bottom (last) ring).
Amendment of Functions and Parameter Values
[0551] The present embodiment stores all of the mathematical
functions, mathematical procedures and parameter values used to
produce the bases and content objects in the model.
[0552] Furthermore, the embodiment allows the user to access the
stored functions, procedures and parameter values, and to amend
them to change the generated model.
[0553] In response to the user amending a function, procedure
and/or parameter value, the system automatically regenerates the
bases and/or content objects in accordance with the amendments and
any unamended functions, procedures and parameter values. As a
result, the effect of changes can be quickly seen by the user.
[0554] Some examples to illustrate amendments will now be
described.
[0555] In a first example, the value of a parameter in the
equations used to generate the backbone bases at step S300 in the
first round of the processing is changed.
[0556] Changing parameters that govern the position and/or
orientation of the backbone bases can have a major impact on the
final model, since all of the bases created in later steps are
dependent upon the backbone bases.
[0557] In this example the value of parameter F (defined with
reference to step S300 in the description of the first round of
processing) is changed from 0.75 to 3.0.
[0558] The result of this change is shown in FIG. 47.
[0559] Referring to FIG. 47, the centre bases and solid objects
named BIL are shown. The main difference in the model produced by
the parameter value change in this example is in the arrangement of
regions A and B, which correspond to the equivalence classes based
upon the attribute "CURVATURE". Rows 3, 5 and 7 from the top down
are clearly different from the model shown in FIG. 46, and after
thorough examination all of the other rows are also different, just
not so obviously. For example, in FIG. 47, the top row of shown
solid objects is moved slightly to the left in comparison to the
top row in FIG. 46. The objects labelled BIL.sub.I, BIL.sub.II and
BIL.sub.III are used for comparison with further examples
(described below).
[0560] By way of a second example, the values of four extra
parameters are changed in addition to the value of parameter F
already changed in example 1 above.
[0561] At step S600 in round 3 of the processing, the points
P.sub.L, P.sub.R, P.sub.B, P.sub.T inserted into the centre bases
were transformed into points P.sub.LT, P.sub.RT, P.sub.BT, P.sub.TT
according to a set of parameters (for detailed description of the
transformation see the description of step S600 in the third round
of processing). In this second example, the value of the parameters
.alpha..sub.L, .alpha..sub.R, .alpha..sub.B and .alpha..sub.T used
to transform the points is changed from 45.degree. to 120.degree.
(all of the parameters have the same value). The result of changing
the parameters F, .alpha..sub.L, .alpha..sub.R, .alpha..sub.B and
.alpha..sub.T in this way is shown in FIG. 48.
[0562] Referring to FIG. 48, the arrangement of regions A and B is
the same as in FIG. 47. The difference is in the directions in
which the tips of the solid objects named BIL point. More
particularly, the objects labelled BIL.sub.I, BIL.sub.II and
BIL.sub.III in FIG. 48 have their tips pointing in the opposite
direction to the objects with the same labels in FIG. 47. These
objects are respectively created in the centre bases with the same
indices in the model from example 1 and in the model from example 2
(object BIL.sub.I is created in a centre base with index I in both
models; the analogue statement is true for objects BIL.sub.II and
BIL.sub.III).
[0563] In a third example, the values of 12 extra parameters are
changed in addition to the value of parameter F already changed in
example 1 above.
[0564] At step S600 in the third round of processing, the points
P.sub.L, P.sub.R, P.sub.E, P.sub.T inserted into the centre bases
were transformed into points P.sub.LT, P.sub.RT, P.sub.BT, P.sub.TT
according to a set of parameters. In this third example, the values
for these parameters are changed to:
TABLE-US-00017 Point D r .alpha..sub.S .alpha. P.sub.L {-0.35, -2,
0} 1.0 0.degree. 22.5.degree. P.sub.R {0.35, -2, 0} 1.0 0.degree.
45.degree. P.sub.B {0, -2, -0.35} 1.0 90.degree. 90.degree. P.sub.T
{0, -2, 0.35} 1.0 90.degree. 180.degree.
[0565] The result of changing the values for the parameters above
is shown in FIG. 49.
[0566] Referring to FIG. 49, the arrangement of regions A and B is
the same as in FIG. 47. The difference is in the size and
directions in which the tips of the solid objects named BIL point.
In addition, FIG. 49 shows that the objects labelled BIL.sub.I,
BIL.sub.II, BIL.sub.III, BIL.sub.IV, and BIL.sub.V have tips of
different shapes and sizes.
[0567] A fourth example will now be described, in which a function
used to generate some of the bases is changed. More particularly,
an example will be described in which the function R[I] used at
step S300 in the second round of processing to calculate the radii
of the circles upon which the ring bases lie is changed.
[0568] Instead of linear enlargement of radii from floor to floor,
in this example, a more versatile function Sine is used to compute
the radii of the ring bases. The radius of I-th ring base R[I] is
adjusted by the value of the Sine function at each floor. The radii
thus oscillate around the fixed radius R.sub.fixed.
[0569] The function for the radii is changed to:
R[I]=R.sub.fixed+Sin
[2*Pi*arg*(Iref[I]-1)/NumberOfBackboneBases]
[0570] Values of parameters: [0571] NumberOfBackboneBases: 8 [0572]
R.sub.fixed: 12.00 m [0573] arg: 1.25
[0574] The parameter "NumberOfBackboneBases" was defined at step
S110 in the first round of processing (generation of backbone
bases). The parameter "arg" defines the number of full sine waves
produced from the top to bottom floors. In this example, one and a
quarter waves are applied from top to bottom.
[0575] When the function R[I] is changed by the user, the system
automatically reapplies the changed function and all previously
defined functions and parameters to regenerate the model. In this
way, the user can change some of the bases (the ring bases in the
present example) and the system automatically regenerates all bases
and content dependent thereon.
[0576] The result of changing the function for calculating the
radii of the ring bases is shown in FIG. 50.
[0577] As in FIG. 46, the ring bases, centre bases and solid
objects named BIL are shown. The main difference is in the
arrangement of regions A and B, which correspond to the equivalence
classes based upon the attribute "CURVATURE". The Sine function
introduces a bulge in the upper part of the model and a valley in
the lower part, and therefore the distribution of regions A and B
is clearly different from FIG. 46. The influence of a quarter of
the next sine wave can also be seen in the bottom right part of the
figure. The reason why not all of the bottom line belongs to region
B is the influence of the positions of the backbone bases.
Variation of Content Objects with Reference Base
[0578] In the example described previously, content objects were
inserted into the bases such that the content object was the same
for every base at the time of insertion. However, this need not be
the case, and instead processing can be performed by the system to
insert content objects so that a property of each content object
(such as its position, orientation and/or shape) varies in
accordance with the base into which the content object is
inserted.
[0579] For example, at step S500 in the third round of processing,
5 content objects were inserted into each centre base. More
particularly, four points P.sub.L, P.sub.R, P.sub.B, P.sub.T and a
polygon F were brought into the system from an outside source and a
copy of each object was assigned to each centre base. As a result,
polygon F was identical for each centre base.
[0580] However, the processing at step S500 may be performed
instead so that a property of polygon F changes in dependence upon
the centre base into which it is assigned.
[0581] An example will now be described in which processing is
performed so that the shape of each polygon F changes in dependence
upon the reference centre base of the polygon.
[0582] FIGS. 51a and 51b show the starting shape of the polygon
F.sub.S and the ending shape of the polygon F.sub.E, respectively.
Also shown are points P.sub.L, P.sub.R, P.sub.B, P.sub.T, which are
the same for each centre base. All objects are shown in the same
position relative to the centre base's origin as their position to
the global coordinate system G.
[0583] The coordinates of the vertices of the polygon are:
F.sub.S={{-2.1, 0.0, -2.1}, {2.1, 0.0, -2.1}, {2.1, 0.0, 2.1},
{-2.1, 0.0, 2.1}}
F.sub.E={{-1.788, 0, -1.788}, {-1.788, 0, -1.788}, {2.442, 0,
0.654}, {-0.654, 0, 2.442}}
[0585] The coordinates of the points P.sub.L, P.sub.R, P.sub.B,
P.sub.T are the same as those used at step S500 of the third round
of processing.
[0586] Content importer 92 inserts starting polygon F.sub.S into
the first centre base (i.e., into centre base with index 1 that
belongs to the first ring base) and inserts ending polygon F.sub.E
into the last centre base. All centre bases in between receive a
differently shaped polygon F.sub.i. These polygons are computed by
content generator 90 by the use of a mapping function M: [0587]
I--i-th element=index of centre base [0588] V.sub.S--starting
vertex [0589] V.sub.E--ending vertex [0590] N--number of
elements
[0590] M[I,V.sub.S,V.sub.E,N]=V.sub.S+I(V.sub.E-V.sub.S)/(N-1)
[0591] It will be seen from the above that the mapping function M
is a function of the variable I, and that I is equal to both the
number of the i.sup.th polygon and also the index of the base into
which the polygon is to be placed (as one polygon is placed in each
base so there is a 1:1 relationship). As a result, each polygon is
generated in accordance with the value of I of its containing
base.
[0592] The vertices V.sub.i1, V.sub.i2, V.sub.i3, V.sub.i4 of the
polygon F.sub.i are computed as follows: [0593] V.sub.S1, V.sub.S2,
V.sub.S3, V.sub.S4-- vertices of starting polygon F.sub.S [0594]
V.sub.E1, V.sub.E2, V.sub.E3, V.sub.E4--vertices of ending polygon
F.sub.E [0595] N.sub.CB--total number of centre bases (see the
description of step S100 for the 3.sup.rd round of processing)
[0596] V.sub.ij=M[i, V.sub.Sj, V.sub.Ej, N.sub.CB], {j=1, 2, 3,
4}
[0597] The mapping function M can be used for computation of
intermediate objects for any pair of objects that can be
represented solely by the same number of vertices.
[0598] FIG. 52 shows polygons F.sub.i and points P.sub.L, P.sub.R,
P.sub.B, P.sub.T distributed to the centre bases Ci.
[0599] From this point on, the processing procedure for the
generation of the model is the same as the procedure described
previously. The only change is in the shape of polygon F.sub.i in
each centre base C.sub.i.
[0600] The resulting model from this change is shown in FIG. 53,
which corresponds to the view of the model from FIG. 46. The
difference between the models shown in FIG. 53 and FIG. 46 is
clear. Even on the top row, where the differences between the
actual polygons F used for the creation of the solid objects BIL
are small, the solid objects have already started to rotate. This
rotation is brought about by the rotation of the top edge of
polygon F.
[0601] The changing of the polygon F from rectangular to triangular
shape also influences the slant of the side planes that govern the
creation of solid objects (see the description of step S700 in the
third round of processing). This change can be so big that the
small front plane on the tip completely disappears and becomes an
edge, like on objects BIL.sub.I and BIL.sub.II.
[0602] On the other hand, the arrangement of regions A and B, which
correspond to the equivalence classes based upon the attribute
CURVATURE, is the same as in the model in FIG. 46.
Generating Content Objects so that they Fit
[0603] The present embodiment provides facilities for a designer to
use to ensure that content objects fit together without gaps and
without encroaching upon each other (that is, two content objects
do not occupy the same space).
[0604] More particularly, content creator 94 provides means for a
user to define functions for the creation of a content object such
that, as part of the creation, the right side of the content in a
base and the left side of the content in the next base (or vice
versa) are cut with the same plane.
[0605] As a result, encroachment of content objects can be
eliminated because the cutting plane is shared between the content
objects of neighbouring bases and therefore no solid object cut
with this plane can encroach in the space intended for the other
base and its content objects.
[0606] These features of the content creator 94 will now be
illustrated with reference to the generation of a model using the
same procedure as described previously, but with different values
of some parameters. (Actually, the procedure for creating cut solid
objects is already described in the example of step S700 in the
third round of processing, where solid objects BIL are cut with
planes created at step S700 in the second round of processing. The
resulting trimmed solid object is named "BIL cut".)
[0607] In the section "Variation of Content Objects with Reference
Base" above, the mapping function M is used to change the shape of
polygon F. The same mapping function is used in this example, but
the difference is in the start and end polygons F.sub.S and F.sub.E
respectively. These polygons are shown in FIG. 54a and have vertex
coordinates. [0608] F.sub.S={{-4.0, 0.0, -4.0}, {4.0, 0.0, -4.0},
{4.0, 0.0, 4.0}, {-4.0, 0.0, 4.0}} [0609] F.sub.E={{0.0, 0.0,
-6.0}, {6.0, 0.0, 0.0}, {0.0, 0.0, 6.0}, {-6.0, 0.0, 0.0}}
[0610] The parameters that are also adjusted for this example
govern the creation of the backbone bases (see step S300 in the
first round of processing) and the transformation of points
P.sub.L, P.sub.R, P.sub.B, P.sub.T into points P.sub.LT, P.sub.RT,
P.sub.BT, P.sub.TT (see step S600 in the third round of
processing).
[0611] The new values for these parameters are: [0612] Parameter F:
3.0.
TABLE-US-00018 [0612] Point D r .alpha..sub.S .alpha. P.sub.L
{-0.35, -2, 0} 0.5 0.degree. 22.5.degree. P.sub.R {0.35, -2, 0} 0.5
0.degree. 45.degree. P.sub.B {0, -2, -0.35} 0.5 90.degree.
90.degree. P.sub.T {0, -2, 0.35} 0.5 90.degree. 180.degree.
[0613] FIG. 54b shows two adjacent solid objects. On the left are
BIL.sub.113 and BIL.sub.114 that encroach on each other, and on the
right are the same objects trimmed with planes, namely "BIL
cut.sub.113" and "BIL cut.sub.144".
[0614] The resulting model from executing the generating procedure
with the parameters above is shown in FIG. 54c. The trimmed objects
"BIL cut.sub.113" and "BIL cut.sub.114" are shown in their position
in the model.
Sensor Functions to Detect a Property of the Model Using the Model
Graph
[0615] At step S800 in the second round of processing described
previously, a sensor function was executed which divided bases into
equivalence classes in dependence upon the value of an attribute of
each base (that is, the attribute "CURVATURE").
[0616] However, sensor function executer 110 is also operable to
generate and execute a sensor function to divide bases into
equivalence classes in dependence upon connections to/from the
vertex representing that base in the model graph.
[0617] An example of such a sensor function will be described
below.
[0618] In this example, graph manager 80 adds two additional
connections to the model generated in rounds 1-3 of the processing
described previously, and sensor function executer 110 defines a
sensor function which divides the ring bases into new equivalence
classes.
[0619] These operations are performed at steps S400 and S800 in the
second round of processing.
[0620] More particularly, at step S450 in the second round of
processing, graph manager 80 defines two additional intrageneration
connections, namely LINE-1 and LINE-2.
[0621] Connections LINE-1 are produced by the following procedure:
A finite series of indices S is created by applying the following
rules: [0622] s.sub.0=starting index [0623] s.sub.i=s.sub.i-1+19
[0624] s.sub.i<=total number of ring bases
[0625] Series S is completely defined by its starting index. When
starting indices s.sub.0=1, 4, 7, 10, 13, and 16 are used, six
series of indices are created: [0626] L1-1={1, 20, 39, 58, 77, 96,
115, 134} [0627] L1-4={4, 23, 42, 61, 80, 99, 118, 137} [0628]
L1-7={7, 26, 45, 64, 83, 102, 121, 140} [0629] L1-10={10, 29, 48,
67, 86, 105, 124, 143} [0630] L1-13={13, 32, 51, 70, 89, 108, 127}
[0631] L1-16={16, 35, 54, 73, 92, 111, 130}
[0632] Connection LINE-1 is applied to each pair of consecutive
indices from each series L1-1 to L1-16 (that is, from series L1-1,
pairs (1, 20), (20, 39), (39, 58), (58, 77), (77, 96), (96, 115)
and (115, 134) are connected).
[0633] The connections LINE-1 in a model graph are shown in FIG.
55.
[0634] Connections from the second additional connection LINE-2 are
produced by the following procedure: A finite series of indices S
is created by applying the following rules: [0635] s.sub.0=starting
index [0636] s.sub.i=s.sub.i-1+Displacement[i] [0637]
s.sub.i<=total number of ring bases
[0638] Displacement[i] is a random series of whole numbers between
15 and 21. For this example following series is used: [0639]
Displacement [i]={19, 19, 21, 17, 20, 21, 15, 18, 21, 18, 19, 17,
17, . . . }
[0640] When starting indices s.sub.0=1, 5, 9 and 13 are used, four
series of indices are created: [0641] L2-1={1, 20, 39, 58, 77, 96,
115, 134} [0642] L2-5={4, 23, 42, 61, 80, 99, 118, 137} [0643]
L2-9={7, 26, 45, 64, 83, 102, 121, 140} [0644] L2-13={13, 32, 51,
70, 89, 108, 127}
[0645] Connection LINE-2 is then applied to each pair of
consecutive indices from each series L2-1 to L2-13.
[0646] The connections LINE-2 in a model graph are shown in FIG.
56.
[0647] At step S800 in the second round of processing, ring bases
are classified into 5 equivalence classes based upon the results of
a sensor function SG, which checks what connections are going out
of each node in a model graph.
[0648] These 5 equivalence classes are:
TABLE-US-00019 Equivalence class Description EQLN-0 ring bases
which lack both of connections LINE-1 and LINE-2 EQLN-1 ring bases
with connection LINE-1 only EQLN-2 ring bases with connection
LINE-2 only EQLN-3 ring bases with connections LINE-1 and LINE-2,
which connects to different end points EQLN-4 ring bases with
connections LINE-1 and LINE-2, which connects to the same end
point
[0649] The above classification is achieved with a sensor function
SG defined and executed by sensor function executer 110:
SG [ I ] = { 0 , ( SL 1 [ I ] = 0 ) and ( SL 2 [ I ] = 0 ) 1 , ( SL
1 [ I ] > 0 ) and ( SL 2 [ I ] = 0 ) 2 , ( SL 1 [ I ] = 0 ) and
( SL 2 [ I ] > 0 ) 3 , ( SL 1 [ I ] > 0 ) and ( SL 2 [ I ]
> 0 ) and ( SL 1 [ I ] .noteq. SL 2 [ I ] ) 4 , ( SL 1 [ I ]
> 0 ) and ( SL 2 [ I ] > 0 ) and ( SL 1 [ I ] = SL 2 [ I ] )
Index I = index of i - th ring base ##EQU00002##
[0650] Function SL1[I] returns the index of the end point of
connection LINE-1 from the ring base with index I. If there is no
connection LINE-1 from this base, function SL1[I] returns 0.
[0651] Function SL2[I] returns the index of the end point of
connection LINE-2 from the ring base with index I. If there is no
connection LINE-2 from this base, function SL2[I] returns 0.
[0652] Each value of the sensor function SG[I] defines one
equivalence class, which is represented with an additional
attribute "LINE NODE" on each ring base. Depending on the value of
function SG[I], the following values are assigned to the attribute
"LINE NODE":
TABLE-US-00020 Value of function SG[I]: 0 1 2 3 4 value of EQLN-0
EQLN-1 EQLN-2 EQLN-3 EQLN-4 attribute "LINE NODE"
[0653] FIG. 57 shows the graphical distribution of equivalence
classes over a model. On the figure, white blocks are shaded with a
different pattern according to the value of the attribute LINE
NODE. Also connections LINE-1 and LINE-2 are shown in the form of
lines.
Identifying Bases with Defined Relationships, and Adding Different
Content Objects
[0654] In this part, another use for equivalence classes is
described. The difference from the main example is only at step
S500 in the third round of processing, where content objects are
inserted in the centre bases.
[0655] At this step, content object polygon F is inserted in each
of the centre bases (FIGS. 41a and 41b). In the example below,
instead of the same polygon F, different polygons F.sub.1 and
F.sub.2 are inserted in the centre bases C.sub.i (FIG. 58a).
Polygon F.sub.1 is inserted in the centre bases where the value of
the attribute "CURVATURE" of its parent ring base R.sub.i is "-"
and polygon F.sub.2 in the centre bases where the value of the
attribute "CURVATURE" of its parent ring base R.sub.i is "+".
[0656] The coordinates of the vertices of the polygons F.sub.1 and
F.sub.2 relative to centre base in this example are: [0657]
F.sub.1={{-2.1, 0.0, -2.1}, {2.1, 0.0, -2.1}, {2.1, 0.0, 2.1},
{-2.1, 0.0, 2.1}} [0658] F.sub.2={{0.0, 0.0, -3.156}, {0.0, 0.0,
-3.156}, {2.733, 0.0, 1.578}, {-2.733, 0.0, 1.578}}
[0659] Subsequent processing is then carried on as in the main
example. The result of this change is shown in FIG. 58b.
[0660] Referring to FIG. 58b, the ring bases, centre bases and
solid objects named BIL.sub.CUT are shown. The main difference in
the model produced by the use of different polygons F.sub.i in this
example is in the shape of the solid objects BIL.sub.CUT in region
A in comparison to the objects in the same region A shown in FIG.
46. Objects in region B are the same in both FIGS. 58b and 46 since
the polygon F.sub.1 from this example used for construction of
objects BIL.sub.CUT is the same as polygon F from the main
example.
Identifying of Bases and Content Objects with Defined
Relationships, Identifying Content Objects with Defined
Relationships, and Adding Further Content Objects
[0661] At step S800 in the second round of processing described
previously, a sensor function was executed which divided bases into
equivalence classes in dependence upon the value of an attribute of
each base (that is, the attribute "CURVATURE").
[0662] An example will now be described of two additional sensor
functions executed at step S800 in the third round of processing.
First, sensor function SA[i] will compute a directed angle between
the X-axis direction of backbone base B.sub.Iref and the normal
vector of the plane in which polygon F.sub.i lies. Second, sensor
function LA[i] will compute a directed angle between the normal
vector of the plane PL.sub.i from ring base R.sub.i and the normal
vector of the plane in which polygon F.sub.i lies. Based upon
different criteria for each sensor, two attributes are assigned to
centre bases C.sub.i: "SIDE-ANGLE" depending on the values of
sensor function SA and "LOCAL-ANGLE" depending on the values of
sensor function LA. The result will be a generation of centre bases
partitioned into two sets of equivalence classes, one set of
equivalence classes per attribute.
Sensor Function SA[i]:
[0663] R.sub.i--i-th ring base C.sub.i--i-th centre base, contained
in ring base R.sub.i F.sub.i--Polygon F in centre base C.sub.i
B.sub.Iref--Reference backbone base for i-th ring base R.sub.i
(index I.sub.ref is [0664] computed by formula from step S215 on
second round of processing) x.sub.Iref--X-axis direction of
reference backbone base B.sub.Iref N.sub.Fi--Normal vector of plane
in which lies polygon F.sub.i
SA[i]=AngleBetween [x[I.sub.ref[i]], N.sub.Fi]
[0665] FIG. 59a shows objects involved in the computation of sensor
function SA for bases C.sub.i and C.sub.i+18.
[0666] The attribute "SIDE-ANGLE" for each centre base C.sub.i is
defined with the following function:
SIDE - ANGLE [ i ] = { EQSA - 1 , 0 .degree. .ltoreq. SA [ i ] <
120 .degree. EQSA - 2 , 120 .degree. .ltoreq. SA [ i ] < 240
.degree. EQSA - 3 , 240 .degree. .ltoreq. SA [ i ] < 360
.degree. ##EQU00003##
[0667] Since the angle is always between 0.degree. and 360.degree.,
all possible values for the function SA[i] are covered, thus
splitting the generation of centre bases C.sub.i into three
distinct groups (equivalence classes), each group identified by the
different values of the attribute "SIDE-ANGLE": EQSA-1, EQSA-2 or
EQSA-3. FIG. 61 shows the distribution of equivalence classes
EQSA-1, EQSA-2 and EQSA-3 across the model (the view of the model
is from the same position as that in FIG. 35a).
[0668] Different partitioning of the generation of centre bases can
be achieved by using the second sensor function LA.
Sensor Function LA[i]:
[0669] R.sub.i--i-th ring base C.sub.i--i-th centre base, contained
in ring base R.sub.i F.sub.i--Polygon F in centre base C.sub.i
PL.sub.i--Left plane in ring base R.sub.i (defined in step S700 on
second [0670] round of processing) N.sub.Fi--Normal vector of plane
in which lies polygon F.sub.i N.sub.PLi--Normal vector of plane
PL.sub.i
LA[i]=AngleBetween [N.sub.PLi, N.sub.Fi]
[0671] FIG. 59b shows the objects involved in computation of sensor
function LA for bases C.sub.i and C.sub.i+18.
[0672] The attribute "LOCAL-ANGLE" for each centre base C.sub.i is
defined with the following function:
LOCAL - ANGLE [ i ] { EQLA - 1 , 0 .degree. .ltoreq. SA [ i ] <
75 .degree. 285 .degree. < SA [ i ] < 360 .degree. EQLA - 2 ,
75 .degree. .ltoreq. SA [ i ] < 105 .degree. 255 .degree. <
SA [ i ] .ltoreq. 285 .degree. EQLA - 3 , 105 .degree. .ltoreq. SA
[ i ] < 285 .degree. ##EQU00004##
[0673] Since the angle is always between 0.degree. and 360.degree.,
all possible values for the function LA[i] are covered, thus
splitting the generation of centre bases C.sub.i into three
distinct groups (equivalence classes), each group identified by the
different values of the attribute "LOCAL-ANGLE": EQLA-1, EQLA-2 or
EQLA-3. FIG. 63 shows the distribution of equivalence classes
EQLA-1, EQLA-2 and EQLA-3 across the model (the view of the model
is from the same position as that in FIG. 35a).
[0674] By partitioning the centre bases into distinct groups of
bases, different content objects can be inserted into each group of
bases, as will now be shown.
[0675] After assigning attributes "SIDE-ANGLE" and "LOCAL-ANGLE" in
step S800, the processing procedure goes back to step S700 to add
new content objects to the model. A solid block FB will be created
in the centre bases C.sub.i from equivalence class EQSA-1 (having
value of attribute "SIDE-ANGLE" equal to EQSA-1), solid block FBM
will be created in the centre bases C.sub.i from equivalence class
EQSA-2, and shelled solid block FBS will be created in the centre
bases C.sub.i from equivalence class EQSA-3. The procedures for
creating these content objects are described below and shown in
FIGS. 60a, 60b and 60c.
[0676] Solid block FB is created from polygon F by an operation
"Thicken to solid" executed in the external geometric modelling
kernel. This operation thickens polygons on both sides and in the
direction of a supplied vector.
Making of Solid Block FB:
[0677] C.sub.i--Reference centre base C.sub.i F--Polygon F in
centre base C.sub.i d.sub.IN--Thickness of the solid FB on negative
side of polygon F (=0.15 m) d.sub.OUT--Thickness of the solid FB on
positive side of polygon F (=0.50 m) FB--Created solid block
[0678] The orientation of the polygon F and with it the labelling
of one side of the polygon as positive and the other as negative is
defined by the order in which the vertices on the polygon are
enumerated. In this case, the vertices are enumerated in such a way
that the positive side of polygon F points in the direction of the
negative Y-axis of the reference centre base C.sub.i. Before
thickening to solid, polygon F is scaled by a factor of 0.85 around
its centre, which, in this example, corresponds to the origin of
the reference centre base C.sub.i. The vector along which the
thickening is carried out is the Y-axis of the reference centre
base C.sub.i. FIG. 60a shows the relevant objects for the execution
of this operation.
Making of Solid Block FBM:
[0679] C.sub.i--Reference centre base C.sub.i [0680]
FBM.sub.1--Copy of solid block FB.sub.1 in new position relative to
the centre base C.sub.1 [0681] FBM.sub.N--Copy of solid block
FB.sub.N in new position relative to the centre base C.sub.N [0682]
v--Vector v represents path for translating solid blocks FBM.sub.1
from centre base C.sub.i
[0683] Solid block FBM.sub.i has the same shape as solid block
FB.sub.i. The difference is in its position relative to the
reference centre base C.sub.i. Each solid block FBM.sub.i is
created as a solid block FB.sub.i and then transformed with
transformation TRF[i].
FBM[i]=TRF[i]FB[i] 1
[0684] Transformation TRF[i] comprises translation TF[i] and
identity rotation matrix which are calculated relative to each
centre base C.sub.i. Translation TF[i] is defined as a move along a
vector v given relative to the centre base C.sub.1 for the amount
FBM.sub.DIST[i].
TF[i]=FBM.sub.DIST[i]v=(m.sub.1+(i-1)(m.sub.N-m.sub.1)/(N-1))v
m.sub.1=2.5 m m.sub.N=-2.5 m v={2.0, 1.0, 1.0} N=number of centre
bases
[0685] In other words, solid blocks FBM.sub.i are moved in a
straight line defined by vector v from the position occupied by the
solid block FBM.sub.1 to the position of the solid block FBM.sub.N.
This situation is shown on FIG. 60b.
[0686] Although index i runs for all centre bases C.sub.i, it
should be noted that the translated objects FBM.sub.i will be
created only in the centre bases C.sub.j that are part of the
equivalence class EQSA-2.
Making of Solid Block FBS:
[0687] C.sub.i--Reference centre base C.sub.i FB--Solid block
FBS--shelled solid block S.sub.F--front side of solid block FB
S.sub.B--back side of solid block FB shell thickness (=0.15 m)
[0688] Solid block FBS is derived from solid block FB by applying a
shelling operation on it. Shell is a standard operation for most
geometric modelling kernels (sometimes called offset) which takes
the surface of the solid and then thickens it by a specified amount
in the desired direction--in or out. Parameters for the shell
operation can also include a list of faces of the solid which must
remain open (actually they are removed before thickening).
[0689] In this example, the solid object FBS is created by applying
a shell operation on solid block FB, where front and back faces of
the solid FB must remain open. The orientation front/back is
defined by the relative position of the faces of the solid FB
against reference centre base C.sub.i: the face pointing in the
direction of the Y-Axis of the centre base C.sub.i is the front
face S.sub.F, and the opposite face is the back face S.sub.B. Shell
thickness "s" is applied toward the inside of the solid block FB,
meaning that the outer limits of solid blocks FB and FBS are the
same. FIG. 60c shows the initial solid block FB with front and back
face and the final shelled solid block FBS.
[0690] In step S700, solid objects FB, FBM and FBS are created in
the centre bases C.sub.i corresponding to the equivalence classes
EQSA-1, EQSA-2 and EQSA-3 respectively. Steps S705 to S799 are
executed three times in a row, for each content object once. Which
centre bases are used for a particular content object is determined
in step S720.
[0691] The solid objects FB must be created in the centre bases
belonging to the equivalence class EQSA-1, which is governed by the
value of the attribute "SIDE-ANGLE" (the procedure for making the
solid objects FB being as described above).
[0692] The solid objects FBM must be created in the centre bases
from the equivalence class EQSA-2 (the procedure for making the
solid objects FBM being as described above).
[0693] It should be noted that another way of producing the solid
objects FBM exists. Firstly, the solid objects FB are created using
the same procedure as for the solid objects FB for the equivalence
class EQSA-1 (basically, they are created in all of the bases from
equivalence classes EQSA-1 and EQSA-2). Secondly, their names are
changed to FBM in step S800 and, finally, they are transformed with
transformation TRF (described above) in the step S600.
[0694] The solid object FBS is then created in the centre bases
from equivalence class EQSA-3 (the procedure for making solid
objects FBS being as described above).
[0695] The distribution of the newly added content objects FB, FBM
and FBS to the model is shown in FIG. 62 (ring bases and centre
bases are also shown in this figure).
[0696] If the criteria for selecting the bases for creation of the
new content objects FB, FBM and FBS is based upon equivalence
classes EQLA-1, EQLA-2 and EQLA-3, such that the content objects FB
are created in the centre bases from equivalence class EQLA-1, the
content objects FBM in the centre bases from equivalence class
EQLA-2, and the content objects FBS in the centre bases from
equivalence class EQLA-3, a different distribution of content
objects FB, FBM and FBS is achieved. This distribution is shown on
FIG. 64 (ring bases and centre bases are also shown in this
figure).
Modifications and Variations
[0697] Many modifications and variations can be made to the
embodiment described above.
[0698] For example, at step S300 on the first round of processing,
base generator 70 calculated the position and orientation of each
backbone base in accordance with mathematical functions. This
enables a large number of backbone bases to be generated without
the user having to position and orientates each backbone base
individually. However, base generator 70 is operable to generate
the backbone bases in accordance with positions and orientations
input by a user (for example, if only a small number of backbone
bases are required).
[0699] In the embodiment described above, the generations of bases
are generated sequentially--that is, all of the first generation
(backbone) bases are generated, then all of the second generation
(ring bases) are generated, and then all of the third generation
(centre) bases are generated. However, base generator 70 is
operable to generate the bases in different ways. For example, base
generator 70 is operable to generate one first generation base and
all of its second generation bases, followed by a next first
generation base and all of its second generation bases, and so on
up to the final first generation base and all of its second
generation bases. In addition, base generator 70 is operable to
generate bases in other orders.
[0700] In the embodiment described above, base generator 70 and
content generator 90 are operable to generate bases and content
objects respectively using a mathematical function or functions
having base index values (base identification numbers) as a
variable of the function(s). In this way, the bases and content
objects change position, orientation and/or shape in accordance
with the base index value of the base in which they are located. In
the embodiment described above, the base index values used as the
variables in the function are the base index values stored in the
model graph, namely the base index values that were assigned when
the bases were created. However, instead, temporary base index
values (base identification numbers) can be used as the variables
in the mathematical function(s). For example, when reference bases
are selected to hold the new bases or content objects, each
selected reference base can be assigned a temporary base index
value which is independent of its actual base index value. For
example, if twenty four bases are selected as reference bases, then
temporary base index values 1 to 24 can be assigned to the selected
reference bases, irrespective of their actual base index values
stored in the model graph (which could be, for example, 25 to 48).
The temporary base index values would then be used as the variables
in the mathematical function(s) to generate the new bases and/or
content objects, with the same effects as those described in the
embodiment above.
[0701] In the embodiment described above, graph manager 80
generates and maintains a graph comprising a directed and labelled
multigraph. However, graph manager 80 may generate and maintain
other types of graph instead, such as a directed graph without
labels, with the labels being stored in separate notes connected to
the object nodes (that is bases and content objects).
[0702] In the embodiment described above, three-dimensional
coordinate systems and three-dimensional mathematics are used to
generate the design for a three-dimensional object. However,
coordinate systems and/or mathematics of dimensions greater than
three could be used to generate a design for a three-dimensional
object.
[0703] In the embodiment described above, the bases within each
generation have different respective positions and different
respective orientations. However, some or all of the bases within a
generation may have different respective positions but the same
orientation, or the same position with different respective
orientations.
[0704] In the embodiment described above, content creator 94
employs geometric modelling kernels that are pre-stored in
apparatus 2 in order to create content objects. However, in
addition or instead, content creator 94 may be arranged to download
modelling kernels from a separate apparatus, at the time when the
modelling kernels are required. Furthermore, content creator 94 may
be arranged to export all of the necessary data for content object
creation (instructions for operations and data for parameters)
either to a separate software application running on apparatus 2 or
to a separate processing apparatus, with the results (the created
content object) then being imported back. Similarly, sensor
function executer 110 may be arranged to export data to a separate
application or apparatus for the execution of a sensor function,
and to import the results. It will therefore be understood that an
embodiment may comprise multiple processing apparatus (which may
operate in series or in parallel), and that the term "apparatus"
used in the claims is not restricted to a single apparatus.
[0705] The nature of the bases and content objects described above
are specific to the example described, whereas base generator 70
and content generator 90 are operable to generate a wide variety of
bases and content objects. For example, in the example described
above, one backbone base is generated for each floor of the
building--in the centre of the floor with ring bases around it.
However, in the case of a square or rectangular building, base
generator 70 is operable to generate a backbone base at each corner
of each floor. Of course, other bases and content objects can be
generated depending upon the application and design.
[0706] Having thus described several aspects of at least one
embodiment of this invention, it is to be appreciated various
alterations, modifications, and improvements will readily occur to
those skilled in the art. Such alterations, modifications, and
improvements are intended to be part of this disclosure, and are
intended to be within the spirit and scope of the invention.
Accordingly, the foregoing description and drawings are by way of
example only.
* * * * *