EP1234281A2

EP1234281A2 - Three dimensional computer graphics drawing system

Info

Publication number: EP1234281A2
Application number: EP00973383A
Authority: EP
Inventors: Dent-De-Lion Du Midi; Steffen Toksvig
Original assignee: IDO SYSTEMS Inc
Current assignee: IDO SYSTEMS AS
Priority date: 1999-10-22
Filing date: 2000-10-20
Publication date: 2002-08-28
Also published as: AU1189501A; WO2001031585A9; WO2001031585A2; WO2001031585A3

Abstract

A computer graphics system is provided that is based on two fundamental primitives: a ball and a stick. These primitives may be combined to create simple or complex drawings, in accordance with eight specified rules regarding ball and stick geometry, manipulation and representation. The system may be used for education or entertainment as a drawing tool, but may also be used to organize, present and manipulate 3D diagrams ('information structures') representing information organized in a hierarchical manner. There is also provided a range of coordinated graphic user interface (GUI) controls, These controls enable realtime manipulation of ball and stick objects in 3D. The controls include facilities for 'extruding' a new ball and stick objects from an existing ball; 3D control 'widgets', in which 3D elements within the control are accessed and moved three dimensionally in order to operate the control; 3D color palates; transparent controls that are fully functional but do not hide the work which appears underneath; context-sensitive 'sub-cursors'.

Description

Three Dimensional Computer Graphics Drawing System

Background of the Invention

Field of the Invention

This invention generally relates to the field of computer graphics. More particularly, it relates to systems for three-dimensional (3D) drawing of ball and stick objects based on a well- defined set of graphics primitives and rules.

Description of the Related Art

Prior art computer-based drawing systems range from free-form "'paint" programs, to "drawing" and "charting" programs based on predefined shapes and objects which may be sized and dragged into position in a graphical work in process with a suitable interface device, such as a mouse, to professional computer-aided design (CAD) systems, where complex, precise drawings may be created in either two or three dimensions. There are also molecular modeling programs that have been developed for scientific applications, but these have been developed for the specific purposes of representing a relatively small range of graphic figures, and have not been adapted for general, free-form drawing purposes.

If one desires to create three-dimensional drawings with prior art tools, it is generally necessary either to use (i) a 3D CAD package, which is expensive, requires a relatively large amount of computing power, and difficult to learn and/or use; (ii) a paint program, which generally provides good low-level graphics functionality, but lacks the power to handle graphic abstractions and objects, particularly in 3D, or (iii) a drawing or charting program, which is generally designed for 2D drawings, and generally lacks a strong framework for producing 3D drawings with a coherent look or style. A typical nonprofessional user using any of these approaches (assuming the user could even afford a CAD system) would have a difficult time creating presentable 3D drawings. There is in fact a lack in the current state of the art of easy-to- use graphics software that promotes a coherent design style so as to enable the quick production of high-quality 3D drawings.

Brief Summary Of The Invention

The present invention was developed in accordance with the following objectives:

• to develop a system in which almost any user can work with 3D drawings in real time.

• To employ a predefined but visually versatile graphical "look" so as to promote the simple creation of attractive 3D graphics drawings. • To make such system as simple as possible, yet powerful.

• To make such a system usable by users of all ages (pre-school to adult).

• To provide specific graphic user-interface elements for this system to promote ease of use.

• To make such system internet-compliant.

• To make the system such that it provides fast, smooth 3D graphics in real time without expensive hardware.

• To make such system platform independent.

• To make the use of the system positive, fun, highly expressive and mind-opening.

The foregoing and other objects of the invention are accomplished by a computer graphics system based on two fundamental primitives: a "ball" and a "stick". These primitives may be combined to create drawings (each assembly of connected elements in a drawing is sometimes called a "model"). In accordance with the preferred embodiment, the following rules apply:

1. The structural elements of a model may consist only of ball objects and stick objects, the ball objects having a center; the stick objects having two ends and a longitudinal axis; and said ball and stick objects being of variable size.

2. Each stick object is connectable to a ball object at the respective ends of the stick, at the surface of the ball.

3. Stick objects may exist only between balls.

4. Ball objects cannot intersect.

5. Stick objects may (but need not) touch each other at or about the point of connection to a ball, but otherwise cannot intersect.

6. The longitudinal axis of each stick object points toward or approximately toward the respective centers or approximate centers of the balls attached to its respective ends.

7. The ball objects either have a solid color, are transparent, or have text or texture.

The system is preferably implemented using a portable 3D graphics library, so as to promote platform independence. Currently, the OPEN GL® library is used, and implementations J exist for the Apple® iMac™ (currently most preferred) and Windows® 98/NT platforms (in the latter case, preferably with hardware support for OPEN GL graphics, such as a 3 Dfx® or similar game or graphics-oriented video processor). The system may be readily ported to other systems that implement OPEN GL and/or ported so as to use other 3D graphics libraries.

In addition to representational drawings, the system is readily adapted to creating abstract depictions of any system in which elements are organized hierarchically (or more generally, as a "network" or a "graph"), resulting in 3D informational structures. Information from conventional information structures (for example, a large tree-structure directory) may be directed into a corresponding 3D structure and then manipulated in accordance with the facilities provided by the invention. The system provides professional quality facilities for modeling such information systems.

In addition to the graphic facilities, the system also provides a range of coordinated graphic user interface (GUI) controls, most of them being themselves 3D objects. These facilities are used for (among other purposes) providing realtime manipulation of ball and stick objects in 3D. The included controls provide facilities for "extruding" a new ball and stick from an existing ball; 3D control "widgets," in which 3D elements within the control are accessed and moved three dimensionally in order to operate the control; 3D color palates; transparent controls that are fully functional but do not hide the work which appears underneath; and context- sensitive "sub-cursors."

The system is currently adaptable as an entertainment/learning program for pre-schoolers and K-5 children; a 3D drawing program for family use; and as a 3D drawing environment for professional modeling. The system can also render musical notation and may be used in connection with composing and scoring. The ball and stick figures generated by the system can also be used as designs for toys, furniture, playground equipment and architectural objects.

The manner in which the invention achieves these objects is more particularly shown by the drawings enumerated below, and by the detailed description that follows.

Brief Description Of The Drawings

The following briefly describes the accompanying drawings:

Figures 1A - 1M show a set of thirteen representative drawings created with the system. Figure 2 shows a ball and stick model in accordance with the present invention, depicting an animal-like figure, entitled "Chamelion".

Figure 3 shows a ball and stick model in accordance with the present invention, depicting two bicycle riders, entitled "Bicycle".

Figure 4 shows the information for a tree-structured hierarchical file directory which has been exported to a 3D ball and stick model in accordance with the present invention.

Figure 5 is an illustration showing extrusion of a new ball and stick structure from an existing ball object.

Figure 6 shows a color palate control in accordance with the present invention.

Figure 7A shows a 3D slider control as implemented in the present invention, and Figure 7B shows a "special effects" control showing control "transparency^" in accordance with the present invention.

Figure 8 shows an example of a context-sensitive "sub cursor" as provided by the present invention.

Figure 9 is a software block diagram of the invention.

Figure 10 is a block diagram showing the current structure of the "Development Kit" developed in connection with the invention.

Figure 11 is a diagram showing the object model employed in connection with the invention.

Detailed Description Of The Preferred Embodiment

The following describes the various functional aspects of the preferred embodiment, and its implementation. While the following focuses on one particular embodiment, the claims appended to this application should not by any means be inteφreted as limited by the particular details disclosed in connection with that embodiment.

Drawings Created by the System

The invention as implemented in the preferred embodiment may be most readily understood by reference to the types of 3D drawings that can be created with it. Figures 1A - 1M show a dozen examples of these drawings. Figures 2 and 3 are larger-scale example drawings which have been entitled "Chamelion" and "Bicycle". Each and every graphic element in these drawings (and all of the others) is either a ball or a stick (textured backgrounds are possible options, but are not preferred). All of the drawings in Figures 1, 2 and 3 conform to the following rules:

1. The structural elements of the drawing may consist only of ball objects and stick objects, the ball objects having a center; the stick objects having a longitudinal axis and two ends; and said ball and stick objects being of variable size.

2. Each stick object is connectable to a ball object at the respective ends of the stick, and at the surface of the ball.

3. Stick objects may exist only between balls.

4. Ball objects cannot intersect.

5. Stick objects may (but need not) touch each other at the point of connection to a ball, but otherwise cannot intersect.

6. The longitudinal axis of each stick object points toward the respective centers of the balls attached to its respective ends.

In addition, a background of arbitrary color or texture may be provided (but backgrounds are not preferred). It should also be noted that some variation in the foregoing is possible within the scope of the invention. Thus, balls may be polyhedral or any generally round object with or without precise spherical symmetry, the "center" of which may be approximate; sticks may be any generally elongate object, the longitudinal axis of which may be only approximate; intersection points may be at or about the points indicated in accordance with the foregoing rules; "solid" colors may be substantially solid, shaded, etc.; "transparent" objects may be substantially transparent or translucent, etc. Sticks may be of solid color, but may also have dynamic coloring to indicate that there is a flow of information going through the sticks (i.e. change of color, movements in the color). Though described as three dimensional objects, the balls and sticks of the present invention may of course be rendered on a substantially two dimensional computer display.

The system of the present invention may be used to create the following types of drawings (sometimes referred to as "models"), among others: • Human forms

• Animal forms

• Vehicles

• Toys

• Musical instruments

• Various information structures, such as family trees, calendar/planners, and musical notation.

The preferred embodiment described herein generally enforces a series of "rules," as enumerated above, with respect to the creation of drawings. The invention does not, however, require adherence to the rules. Though not presently preferred, additional elements outside these rules may be incorporated in the drawings or figures created with the invention, so long as elements complying with the rules are included.

Information Structures

Figure 4 shows a hierarchical file directory structure that has been exported to the ball and stick structure of the present invention. Many formats are available for the treatment of such an information structure. For example, each level of the directory may be viewable as a 3D object and rotated, resized and otherwise manipulated in accordance with the other features of the invention. Each such level may be assigned a characteristic color. Each level may be viewed from, for example, above or underneath, providing some variety from the usual conceptual or two dimensional tree representation.

Since the ball and stick structure of the present invention corresponds with the "edges" and "nodes" of network or graph theory, the ball and stick structures of the present invention may be readily used to model not only hierarchical information, but any information that is logically presentable in network or graph form. Similarly, algorithms that are employed to traverse such structures, such as, for example, depth-first or breadth-first or similar traversal algorithms that are well known in the art, may be used to import information into a ball and stick representation in accordance with the present invention. As the traversal algorithm proceeds, a stick is added to the representation for each edge encountered in the data structure, and a ball is added for each node encountered. In this manner, the entire ball and stick structure for the information may be generated automatically, effectively importing it into the ball and stick model. Model Construction and Manipulation

A drawing is started with a dog-bone shaped element called from a model library, consisting of one stick and two balls. Thereafter, new elements may be added by a process called "extrusion". In order to extrude a new ball and stick, the mouse is positioned on any ball, the mouse button is clicked, and a new ball and stick may be dragged out of the surface of the existing ball. This is shown in Figure 5, where new ball 522 on the end of new stick 521 has just been extruded from existing ball 501. Mouse cursor 531 is shown on ball 522, which it is "dragging" away from ball 501, thereby lengthening stick 521.

An object is "selected" with the mouse, using the "select tool". It is then highlighted by a wire-frame rendering composited over the 3D ball.

The new extruded ball and stick may be either left attached to the structure from which it was extruded, or the ball (or more complex object ending with a ball) separated from it, in which case the joining stick may be deleted. In addition, that ball and stick (if left attached), or indeed any attached ball and stick element, may be moved, and the stick lengthened or shortened, or made thinner or thicker. Balls may be expanded or collapsed in diameter, under either menu and/or mouse control.

Two models may be joined together, by extruding a ball and stick object from one model to the other, in which case the extruded ball will disappear into the targeted ball of the second model, leaving a stick junction between the two models.

Once initially created, ball and stick objects can be manipulated in three dimensions, including sideways, up-and-down and in and out spatial translation; rotation around any axis; and resizing.

Model color is controlled with a "colorpicker" color control which has itself been developed in accordance with the principles of the present invention. As shown in Figure 6, the control is a normal ball and stick model with a center ball 601 and ball and stick control elements 602, 603 attached. A color gradient 605 exists on the surface of center ball 601. The mouse is pointed (621) at one of the controls to move it over the surface of center ball 601. and as it moves, it takes on the color of the surface of the ball to which the control is attached. The center ball 601 may be rotated to access colors on its entire surface, such as underneath or on its "back" side. Using a "paint bucket" metaphor, the cursor may be clicked on a control of the desired color 625 and applied to an on-screen model element 635. The colorpicker control and other controls for manipulation and modification of models are unique to the invention. As was the case with respect to the color palette, controls are for the most part constructed using ball and stick constructs in accordance with the "rules" of the invention. For example, Figure 7A shows a slider control 701 constructed in such a manner. Figure 7B shows a "special effects" control 711, which has a "transparency" feature shared by some of the other controls. That is, the panels of the control are semi-transparent. Thus, a user can work with special effects control 711, yet still see those portions of the work 712 that lies behind the control. This is in contrast to the usual situation, where the control often obscures the object being worked on with the control.

Another way in which objects may be manipulated on screen is with a mouse (or other pointing device). The usual pointing, clicking and dragging provided by prior art graphical user interfaces is supplemented in the present invention through the use of "sub cursors" — context- sensitive cursor icons that change appearance and function based on the surrounding on-screen visual context and provide textual messages as to what the cursor can "do" in each such situation.

As shown in Figure 8, a cursor 801 comprises a principal cursor 802 and a sub cursor 803, that move with the mouse in a unitary manner. Principal cursor 802 indicates a principal type of function that may be performed as the cursor is moved around the screen, such as moving, painting, etc. In certain positions, the cursor 801 performs the function of principal cursor 802, and sub cursor 803 is not visible. For example, when positioned on a ball, cursor 801 may be used to click and drag the ball to a new position. In other positions, the sub cursor 803 becomes visible, indicating that while at such location, cursor 801 will perform a different function. For example, when moved off the ball and stick object, sub cursor 803 appears in cursor 801. The effect of clicking and dragging while the cursor is in this state is to rotate the figure in the 3D environment, rather than effect linear translation.

Animation is provided for ball and stick models constructed in accordance with the invention through a process known as "inverse kinematics." Inverse kinematics is a process of calculating joint angles for figures by working backward mathematically from the desired end point or position for an articulated figure. See "Introduction to Inverse Kinematics" at http://www.tc. cornell.edu/Visualization/contnb/cs490-96to97/hoffman/ IK. html (accessed September 14. 1999), incorporated herein by reference. Controls are provided for creating and playing back the animation effects. Movement may also be applied to the ball and stick models of the invention through a process of motion capture. For example, to capture the motion of humans, special markers are placed over their joints, and then hardware is employed to sample the position and/or orientation of the markers in time to generate a set of motion data, also known as motion curves. This technique is explained at http://www.visqraf. impa.br/Proiects/mcapture/intro.html (accessed September 14, 1999), incorporated herein by reference.

Implementation of the Invention

The invention has been implemented with a set of building blocks which have been incoφorated in a development kit (the "IDK"). The IDK may be used for further development of the system, and also to extend it.

The basic requirements of the architecture reflected in the IDK are as follows:

• The graphics should be real-time and interactive

• The audio should be an integral part of the experience

• All model files should be usable in all applications based on the System

• The IDK should clearly separate the platform dependent features into as few places as possible in order to facilitate easy porting. Where platform dependent code or technologies are used, wrapper layers should be written that abstracts this from the main bulk of the IDK

• The IDK is written in standard C++

• The component technologies used (e.g. COM on the PC) are added as wrapper classes - they are separate from the main IDK

The architecture of the system has been designed to supply enough functionality to make it comparatively easy to make applications and at the same time be flexible enough to allow application developers to use their existing tools and frameworks.

Figure 9 is a block diagram (itself a 3D graphic "information structure" in accordance with the invention) showing at a high level the architecture of the software for the invention.

The Object Model 901, discussed in further detail below, is central to the invention. The Object Model represents the set of possible objects that may be created and destroyed by the system. The items in Figure 9 that are "connected" to the Object Model, i.e.. the Window Manager 940, Graphics Engine 915, Audio Engine 905, File Format element 910, and Scripting Engine 950, reflect methods encapsulated in the various objects that may be created by the system.

The Audio Engine 905 generates sounds, drawing upon the native sound and Direct Sound™ APIs. As indicated, native sound APIs 906, Direct Sound™ 907 or MIDI 908 may be used.

The File Format element 910 is described in further detail below.

The Graphics Engine 915 generates the displays for graphical figures of the invention, and makes calls to OpenGL 920, Direct3D™ 925 or other renderer 930 that may be specific to the run-time platform (or the application).

The Window Manager 940 manages creation, display and destruction of windows, calling on the Open GL Utilities Toolkit (GLUT) 941 (which provides a portable API for Open GL), and on the native window API 942, as necessary and as supported on the specific run-time platform and/or application.

The Event Manager 945 manages asynchronous events such as mouse and keyboard actions.

The Scripting Engine 950, described in further detail below, supports high-level script- based programming of the invention.

Figure 10 is a block diagram of the "Development Kit" created in connection with the invention. This architecture employed in such development consists of 4 distinct layers (from the bottom up):

• The OS layer 1010 - This is the OS services native to the supported platform. These services are still available to an application, of course.

• The IDK layer 1020 - This layer is the direct C++ interface to the services. AN application can use these services for maximum speed and/or build their own wrapper layers on top of it.

• The Scripting layer 1030 - This is built on top of the IDK to support easy p-code scripting in the Python programming language. Doing this will enable the saving of scripting behavior in files across platforms, for instance. • The Application layer - This is the actual application. A typical application will use something from each layer.

The first three of these layers is described in further detail below.

The OS layer 1010

The operating systems desired to be supported are very diverse. The Macintosh and Windows 32 operating systems are in some respects similar, in that most of the services supplied on one of them can be found, in some variation, at least, on the other. But the need to support real-time platforms such as the Sony PlayStation® and other console operating systems introduce additional complexity, because the level and types of services that the operating system supplies are very different between a desktop operating system and a console operating system.

The IDK Layer 1020

Several different types of services are made available to the application in this layer:

• File Services 1021 - These services help the application to save and load files in the system's file format. If the application needs to define new entities that should be persistent, the File Services supply mechanisms to do this in a consistent way.

• Network Services 1022 - It is the aim of the IDK that as many of the services as possible should be network transparent, i.e. the application programmer shouldn't have to do anything special in order to make the code work across a network. However, it may not be possible to make it 100% transparent, so the network support library is made available to the application.

• Object Model Services 1023 - These are the core services that handle system objects such as balls, sticks, assemblies and "worlds." In summary, the object model is as shown in Figure 11:

Universe 1110

The Universe is the main object that every application instantiates. Here lies all the functionality of the rendering and audio subsystems, and the handling of networking. In a Universe can be any number of Worlds.

World 1120 A world is the conceptual space where all the action in the system takes place. A World is isolated from all other worlds, but many users and many assemblies can exists here.

Assembly 1130

An assembly is a collection of Elements owned by a User with a transformation matrix attached. An assembly can't be connected to other assemblies.

User 1140

A user is the representation of an actor in the system. A user can own assemblies and move assemblies and/or elements around, create and destroy objects.

Element 1150

An element is the atomic unit of the system, generally a ball. Events don't originate from a lower level than this. Elements can be connected to other elements by sticks (bonds).

Stick (or "Bond") 1160

The stick (sometimes called a "bond") is a connection between two elements. It has a diameter and can collide with elements and other sticks.

• Rendering Services 1024 - To make it easier to integrate the IDK with other graphics and audio frameworks and tools, the rendering (both audio and graphics rendering) engine methods are exposed in this layer.

• Actor Services 1025 - This layer implements a user abstraction that can be actual human users or autonomous agents or anything in between that (cyborgs, e.g.). What distinguishes actors from the other objects in the system is that actors can manipulate the object model. This layer also contains the methods that deal with ownership in a networked environment and personalization.

The Scripting Layer 1030

The scripting layer is a layer written on top of the IDK layer that implements a text-based scripting language (Python) and exposes the IDK services in a scripting framework. This makes it possible to dynamically attach behavior to objects and save them across platforms. If all behavior were C++ code-based, there is no way to save a model's evolved characteristics in a file and load it on another platform later, and no means to transmit it across a network. Moreover, having a scripting layer makes it possible to make the IDK much more flexible.

Python is used in the scripting layer because it is a well-established, mature and open- source object-oriented scripting language that is available on a wide variety of platforms that can be easily embedded in a C++ application.

IDOFF - The System 's File format

The file format used for drawings created with the system of this invention is a tag-based file format, like the Interchange File Format used on the Amiga and the Macintosh.

General structure - An IDOFF file consists of a sequence of tags. A tag is an arbitrary amount of binary data prefixed with a tag header. The tag header is 4 characters that identify the tag-type and 4 bytes that signify the tag length, in bytes. The assignee of the present application, defines all tags.

Endianess (data alignment) - The length and all other data fields are in little-endian format as opposed to the IFF-format where all data is big-endian. Since PC's and PlayStations are both little-endian, approximately 90% of the machines that will read the system^'s files will be little-endian and there is no need to impose a conversion penalty on most applications. The IDK handles the conversion transparently, but where it is necessary to convert, there will be a small performance impact.

Compression - The file header contains a flag signifying whether the file is compressed or not. If this flag is set, then the rest of the file is compressed using a stream based compression algorithm.

Encryption - The file header contains a flag signifying whether the file is encrypted or not. If this flag is set. the rest of the file is encrypted using a stream cipher, e.g. RC4. If both compression and encryption is to be used the compression is done first. The reason is that encryption tends to make the data look like uniformly distributed, random data. This compresses very poorly or not at all.

Compliance - A reader for system files must skip any unknown tags. This is done by reading the first 8 bytes, checking them and skipping the length forward. To be a compliant file reader a program must support the following tags: IDOH. COMM, AUTH. SKIP and LIST Basic data types - The basic data types used by the system's file-format are defined below.

IDOH - Header tag (mandatory) - This must be the first tag in a file.

A UTH - Author tag - This tag contains information on the person who originated the file.

BALL - Ball tag - A recurring and important tag.

BOND - Bond (stick) tag - This tag specifies how two balls are joined together with a stick.

LIST - A list of items - This tag is a way to ensure that a long list of tags of the same type doesn't have to include redundant header information.

COMM - the comment tag - The comment tag is used to insert comments into the file.

SKIP - the skip tag - This tag is used to implement optional tags in the file format. Instead of a data length, the tag header contains a skip count telling the reader how many tags to skip ahead. It works as follows. If a reader encounters a tag that it doesn't recognize, it skips it by using the length field to determine where the next tag begins. So if the length field contains a length that is not the data length, but the skip length, a reader that doesn't understand the tag will skip beyond any tags between the end of the current tag and the skip length.

By way of example, consider the following sequence of tags:

If a reader that supports NBAL reads this sequence, it will read the "nbal data" and then read the SKIP tag and skip the BALL tag at offset 36. If a reader that doesn't support the NBAL tag reads this sequence, the reader will skip directly to the BALL tag at offset 36. In this way, a writer can write alternate representations of the same data to a file.

Coding guidelines

Coding guidelines for the system of this invention are as follows:

• Standard C++

• Use modern C++ as defined in the standard

• Use as few macros as possible

• Use constant declarations • Instead of factory macros use template functions and members

Error handling

A single exception class called ido::error that inherits from std::runtime_error in the <stdexcept> package. This is used as the base exception for all system exceptions thrown. Exceptions are not used to signal normal behavior. Also, exceptions are not thrown in order to return a 'not found' value; return values are used for that puφose.

Use namespaces

All code in the IDK is enclosed in a namespace called "ido". This makes name clashes much less likely. It is suggested that the "using" clause be used at the lowest possible level, "using namespace" should only occur inside a function or method body.

Example: void SomeClass : : doStuff ( ) using namespace std; using namespace ido; // interesting code follows .. }

Identifiers

Variables are named in the Java style, i.e., they begin with a small letter and any following words in the name are capitalized, without underscores. Hungarian notation is not used, since modern tools will help the programmer to tell the type of variables and parameters in other ways. The only exception is when a variable instance is a pointer. In that case, the name begins with a small p (e.g. pSomeType).

Methods are named in the same style, but always beginning with a verb.

Classes begin with a capital letter, but no special character to signify that it is a class (no C). The only exceptions are pure virtual classes, which should be prefixed with a capital I (for Interface), so as to facilitate distinguishing the two types of classes while programming.

Internet-Related Features

Drawings created with the present invention can be easily transmitted in low bandwidth systems, and are "internet ready" and "internet friendly." That is because the models are defined by simple mathematical relations and not heavy 2D graphics files. Other Applications

It is believed that the drawings created in accordance with the present invention have a unique and distinctive look. No other computer-based application is known that can consistently create free-form drawings having the characteristics described herein. These drawings may be used as the basis for constructing real three-dimensional useful objects, such as snap- or stick- together ball and stick toys, as well as ball and stick furniture and playground equipment, and ball and stick architectural objects such as buildings, all having the distinctive appearance of the drawings created with the present invention.

While the present invention has been described by reference to a particular implementation, it is well known to those skilled in the art that conceptually, numerous other systems now existing or under development or to be developed have or will have hardware or software facilities for dealing with 3D information, and that the systems and methods of the present invention may be readily adapted to any of such environments and will perform correspondingly well in each of them.

For example, a version of the system could readily be implemented in Java, or as a set of Microsoft® ASP controls, and distributed in whole or in part over the internet. Graphics libraries other than OPEN GL could be used by adapting or translating the existing system, which has been initially developed for, but is in no way limited to, OPEN GL. The system could be provided through set-top boxes and used in connection with conventional or high-definition television, or other hardware yet to be developed.

Conclusion

It is apparent from the foregoing that powerful and versatile systems and methods have been developed for providing 3D drawing functionality in a consumer-accessible package, based on a minimal set of primitives and rules. It will be apparent to those skilled in the art that the principles of the invention are readily adaptable to systems other than those herein described without departing from the scope and spirit of the invention, as defined in the following claims.

Claims

I claim:

1. A system for representing three dimensional entities comprising: central processor means; display means; memory means; operating system means capable of loading and executing a program; said program being characterized by the enforcement of the following rules: the structural elements of such representations may consist of generally round ball objects and generally extensional stick objects, said ball objects having a center or approximate center, said stick objects having two ends and a longitudinal axis or approximate longitudinal axis, and said ball and stick objects being of variable size; each stick object is connectable to a ball object at the respective ends of the stick, and at or about the surface of the ball; stick objects may exist only between balls; ball objects cannot intersect; stick objects may (but need not) touch each other at or about the point of connection to a ball, but otherwise cannot intersect; the longitudinal axis of each stick object points toward or approximately toward the respective centers or approximate centers of the balls attached to its respective ends; and ball objects have visual characteristics chosen from the following group: at least substantially solid color, at least substantially transparent, or having text or texture.

2. A method for representing three dimensional entities in a computer system having central processor means, display means, memory means and operating system means for loading and executing a program, said method comprising any sequence of construction in accordance with the following: employing structural elements consisting of ball objects and stick objects, said ball objects having a center or approximate center, said stick objects having two ends and a longitudinal axis or approximate longitudinal axis, and said ball and stick objects being of variable size; connecting stick objects to ball objects only at the respective ends of the stick, and at or about the surface of the ball; employing stick objects only between ball objects; displaying ball objects only in a non-intersecting manner; arranging stick objects so that they never intersect (although stick objects may (but need not) touch each other at or about their point of connection to a ball); orienting the longitudinal axis of each stick object so that it points toward or approximately toward the respective centers or approximate centers of the balls attached to its respective ends; and visually representing the ball objects with one or more visual characteristics chosen from the following group: at least substantially solid color, at least substantially transparent, or having text or texture.

3. A structure comprising a three dimensional representation or rendition of a compound object comprised of ball and stick objects, which has been constructed in accordance with the method of claim 2, the elements of which have been stored in a memory device, and are displayable on a graphical display device.

4. A structure created as described in claim 3, wherein a ball represents a graphical object selected from a group comprising: a sphere-like object, a connector point, an atom, atomic objects, or a molecular group.

5. A structure created as described in claim 3, wherein a stick represents a graphical object selected from a group comprising: a stick, a physical connector, an information pathway, or an abstract relationship.

A method for adding to a ball and stick structure as described in claim 3, said method comprising: selecting a portion of a preexisting ball object within said structure; pulling and causing to be extruded from said ball object a ball and stick extension thereto connected by the stick portion thereof to said preexisting ball object.

7. In a computer system comprising graphical user interface means, graphic user interface controls represented as three-dimensional objects having attributes represented three- dimensionally, in which said attributes are accessed and moved three dimensionally in order to operate the control.

8. A three-dimensional graphic user interface control as described in claim 7 which has been adapted so as to provide a three-dimensional color pallet comprising a convex three dimensional surface on a central ball object having on said surface a color gradient, whereupon control elements comprising further ball and stick elements are attached, which control elements are movable on the surface of said central ball, have the color defined at the point on said convex surface of the central ball to which they re attached, and wherein said color may be copied and applied to a computer graphic.

9. A graphical user interface control for use in conjunction with the system of claim 1, wherein the surfaces of the control are substantially transparent such that the user may see structures located behind the control as viewed on the display means.

10. A three dimensional ball and stick structure in accordance with claim 3 visually representing information that is interrelated in accordance with a logical graph structure.

11. The process of importing information into a structure as described in claim 10 from information logically structure in graph form, comprising: traversing said graph of said information in accordance with a graph traversal algorithm; creating a stick object for each edge developed in the course of such traversal; and creating a ball object for each node encountered in the course of such traversal.

12. An improvement in a cursor for performing operations on a graphical computer display, wherein said cursor comprises a first icon, said icon moveable on said display, which icon visually indicates the general functionality of the cursor, wherein the improvement comprises a sub cursor in association with said cursor, in the form of a second icon positioned in proximity said first icon, the movement of said second icon tracking the movement of said first icon, which second icon becomes visible when active, and invisible when inactive, and which second icon visually indicates the action performed by the cursor when said sub cursor is active, which action is related to but different than the action performed by said cursor when said sub cursor is inactive.

13. The improved cursor of claim 12, wherein a plurality of different sub cursors as described in claim 12 are associated with said cursor.

14. Items of furniture, such as chairs, sofas, tables and desks, comprising a frame comprised of ball and stick elements constructed in accordance with the method of claim 2.

15. A set of toys comprising interlocking ball and stick elements, including balls of varying diameters, and sticks of varying lengths, and means for attaching the ends of said sticks to said sticks, for creating ball and stick structures in accordance with the method of claim 2.

16. Playground equipment such as jungle bars, swings, seesaws, slides and the like whose structural elements are comprised of ball and stick structures constructed in accordance with the method of claim 2.

17. Architectural objects for enclosing spaces, said objects having as structural elements ball and stick structures constructed in accordance with the method of claim 2.