Metaverse – John Barrus, Stephan McKeown, Ilene B. Sterns, Mitsubishi Electric Research Laboratories Inc
Abstract for “3D virtual environment management and delivery system”
“A virtual reality environment creation modification and delivery system stores information that represents the virtual reality environment in an electronic database. This database allows for portions to be created, modified, or delivered without affecting any other parts. To allow records of the database to be updated individually without affecting others, it can be accessed over a network like a wide-area network. It is possible to access the entire virtual reality environment file without having to store it. A database can also be set to read out the version that is compatible with target machines based on the characteristics of the target machine.
Background for “3D virtual environment management and delivery system”
It will be noted that 3D virtual reality environments are stored in files. It is necessary to store, transmit, and download large files when working on a particular section of the virtual environment.
When one wants to manipulate, create and deliver a 3D virtual world file in real-time over the Internet, there are many issues. Problem areas include persistence, scalability and security, multiresolution problems, multiformat requirements, and version control.
Persistence, also known as persistence, refers to the ability of a 3D virtual environment to keep changing after a change is made. You can save changes if you rewrite the entire file. It is impossible to make permanent changes in browser-only authoring tools. It is possible to modify a small portion of a VMRL file without saving it. You will know that VMRL stands for Virtual Reality Modeling Language. This file format is used to store the content of a 3D virtual reality environment. To make changes to a file, you must first read the entire file and then save it. A VMRL file can be up to 10 megabytes in size, making it difficult for small changes.
Prior art file systems cannot be scaled to accommodate an increasing size of the 3D virtual world. This is because it is difficult to provide such capability. Most of the information is contained in one file or a small number of files. To scale up virtual reality environments, the number of files must be increased in ever increasing amounts. This creates a cumbersome and time-consuming method of managing virtual reality files. Even though VRML can be used to split larger files into smaller ones, this creates new problems in managing many small files and opens up new possibilities for errors or loss.
“In terms of security, you will appreciate that granting a security code to a single file grants access to the entire file for each user who might be attempting to edit it. It is impossible to allow access to only a portion of the file that is needed for editing while locking out the rest of the file.
“Moreover, it is difficult to divide the file into what is allowed to be seen and what is not. This allows one person to only edit a small portion of the file.”
Given the current state of the virtual environment, it is impossible to provide a multi-edit function that allows users to edit different parts of the environment simultaneously. A single file cannot provide multiple resolutions for the 3D Virtual Reality Environment. Multiple resolutions can be used to match the output file with the machine that is to receive it. Some machines can display the texture of a graphic object in detail, while others cannot. The ability to draw polygons is another important element in 3D graphics rendering. However, this ability varies from one machine to the next. It is currently impossible to create a single file with different resolutions. The entire file must be modified for each resolution. The same applies to a single file that records the 3D virtual environment. It is not possible to share the same content across multiple platforms. no crossplatform capability. One file storage approach for virtual reality environments prevents the provision of multiple formats. However, the same content can be made available in different formats.
Finally, if a single file is used for virtual reality, it is impossible to control version without duplicating the original file. For example, if a few bytes are changed in a 10 Megabyte file, it is possible to create two 10 Megabyte files to modify the version.
“In short, these problems in the creation and management of 3D virtual environments deprive present systems of the ability to manage multiple authors across multiple platforms. A system that can deliver content to different hardware devices with differing capabilities is needed. It is also important to ensure that only invited guests have access, and to allow the virtual environment grow without limits.
It is difficult to understand how the 3D environment can be made persistent and modifyable over time, allowing authors to take control of the objects in the environment and then release it at will. This is because the virtual environment is stored on one file.
A system for creating, modifying, and delivering a virtual environment is one that stores the scene or virtual reality environment in a database format. The database allows the environment to be divided and stored in different records. This allows multiple people to work in the same part of the virtual environment. It also allows for version control and allows you to save changes. Persistence, allows for scalability and security, format control, independence, and the ability to work on different parts of the virtual environment without disturbing others. Indexing allows for quick access to different parts of the environment through the use of the database.
There are advantages to prior art systems that allow individual records and objects to be changed without affecting any other records in the database. The virtual environment can be stored in a file. This allows for simultaneous changes to multiple records, such as by two or more creators. However, the changes made to other records are not affected or written over and only those records that have been modified can be updated. This greatly reduces the amount of network communication.
“The database allows you to solve problems such as persistence, scalability and multi-edit capability. Multi-resolution and multi-format version control are possible since different parts of the database can easily be queried, altered, and outputted without regard for other parts.
“It is important to note that persistence requires nonvolatile, permanent storage. This excludes RAM storage which can be volatile but includes high density disk storage which is both fast- and nonvolatile.
“It’s also important to permit access and locking in an easy-to-use manner, to encourage multiple users. If the locking granularity of the environment is too high, such as e.g. If there are not enough partitions, an author may be able to lock up large sections of the environment while modifiying only a small portion of it.
Storing the 3D environment in a database gives you persistence comparable to files on a hard drive. A database allows access to only a portion of the 3D environment, which makes modification faster than downloading and utilizing the entire file. Multiple authors can work simultaneously with concurrent access to the database and row or object locking.
“To achieve this, the database partitions are created so that the entire environment can be broken down into smaller, more manageable chunks. A “locales” approach in one embodiment is a good choice, as it allows for flexibility and scalability.
“Thus, the subject invention relates to a virtual reality environment creation and modification system. It stores information about the virtual reality environment in an electronic database that can be modified, delivered, or altered without affecting any other parts. To allow records of the database to be updated individually without affecting others, it can be accessed over a network like a wide-area network. It is possible to access the entire virtual reality environment file without having to store it. A database will also read out the version that is compatible with target machines based on the characteristics of the target machine. To accommodate different target machine characteristics, some aspects of the virtual environment, such as texture, may be stored in multiple formats. To illustrate, textures that are used in the virtual reality environment can be stored in a “high resolution, 24 bit format” for target computers with large amounts of texture memory. Target machines with less texture memory may store them in a “low resolution and lower bit depth format” while target machines with more texture memory have them stored in a “non-textured” format.
Virtual reality environments are increasingly being used. Computer games are one example of such environments. Many other applications are also being developed. A virtual reality environment could be used to train professionals in specific fields, such as medicine. For example, it might allow for the training of surgeons. Virtual reality environments allow for social interaction, allowing multiple people to connect to the environment via a network and interact with each other in the environment.
Virtual reality environments make use of a variety of resources on the target computer system that they were designed to run. The virtual reality environment will use the graphics and sound capabilities on the target computer system, for example.
Computers have a wide range of capabilities. Some high-end computers may display very detailed, textured graphics. A high-end graphics workstation may have 64 MB of texture storage. This memory is used to greatly enhance the virtual environment. Other target computers may not have texturing memory. While some target computers may be able to display 3-D graphics, others may only be able to display 2-D graphics. High-end computers may be able to produce high-fidelity sounds while lower-end systems may produce lower quality sounds. Further, network connections of computers systems can operate at different speeds in a networked environment. The network capabilities of the target machine may affect the virtual reality environment. For example, if multiple people are playing a networked video game, or if the virtual reality environment is stored on remote computers and transmitted to the target computer over the network.
“In an prior art method for distributing virtual reality environment contents to different target computers, each file contains the content such as the content of a high-end workstation as one file, and the content of a midrange workstation in a second file. The content for personal computers as a third or fourth file. A fifth file contains the content that is for a set top box.
The prior art method for creating the content for each target machine is to create each content separately and store it as a large file. Even if someone needs only a small portion of the virtual environment they still need to download the whole file. It is necessary to be able read and save 3-D virtual environments in different formats than the complete file. This allows you to download only a portion of the environment. Virtual environments that are targeted at different platforms or machines have an identical internal structure. This must be maintained for all of them. It is time-consuming and difficult to maintain multiple files in order to preserve the same internal structure.
“There are at least two additional issues that must be addressed when a portion of the content is to be changed. A change to the content of a high-end workstation will not have an impact on the content of a lower end workstation, such as a set-top box. Each file must be changed separately. A second reason is that even small changes in content require saving the whole file again. Large files can be created in virtual reality environments. It can take time to save the file, which can discourage you from making changes in the virtual reality environment.
As you will see, changing even a small portion of the virtual environment requires that the entire file be accessed. The file must also be saved to make the changes. This can lead to complicated situations. After the creator has installed the virtual reality environment on a client’s network, in Detroit, Mich. and is working remotely from California, the client requests to modify an aspect of the virtual environment. Even if the creator already has a copy on a local computer, once the requested changes have been made, the file must be sent to the client’s network. Due to the size of virtual reality environment files, it can take a long time to transfer the file to the client’s computer network. It is a requirement that a system can only work with a portion of a 3-D virtual environment file.
“But, further, the creator usually creates a virtual reality environment using a development machine. The machine used to develop the environment is usually a high-end machine. The environment will be shown using the capabilities of the high-end machine. However, it will need to be tested separately on a lower end target machine. This may result in repetitive testing, development and redevelopment. It is essential that a system can create content in multiple versions, so that different machines can view the same content.
“Virtual reality development and execution environments are needed to overcome these and other problems.”
“More specifically, the problem that must be solved is how to design a 3D environment that has multiple authors across different platforms. It is also necessary to be able deliver content to different hardware with differing capabilities. It is important that you can restrict access to content to only invited guests and allow only authorized authors to modify the environment. It is also important to allow virtual environments to grow freely despite having hard limits. For example, there must be a limit on how many polygons can be drawn per second. It is also important to keep the 3D environments flexible and adaptable over time. This allows authors to access and remove objects from the environment as they wish.
“Through the difficulties of creating, managing, and distributing 3D environments quickly, it is essential to be able bring persistence, scalability and security to real-time 3D virtual environments via the Internet. This includes multi-edit capability, multiformat for crossplatform performance capability and multi-resolution.
“Referring to FIGS. “Referring now to FIGS. It may be possible to edit the virtual scene so that a 16-pixel graphical object is located in the area indicated by dotted boxes 18. It is possible to access the portion of a relational data base that contains the specific location in which the graphical objects are located to alter the scene. In this instance, the object 16 is removed and a standing person is created.
Referring to FIG. 2 will show that to be able to edit a 3D scene, it must first be created, as shown at 20, with inputs like textures and sounds 22, primatives 24 and compositions including groups 26 and hierarchy of parts 26, and locales 28, which break up the scene into different chunks.
“The 3D environment creation is done by downloading to a granular 30 database. This database is used in the storage and editing of the 3D environments.
This allows multiple authors 32 to be able work on different parts of the virtual reality environment. As shown at 34, you can also restrict access to certain parts of the virtual reality environment. The version of the virtual environment that is selected depends on 38 hardware requirements. These requirements are set by the client using a client server system.
“Persistence can be guaranteed by the ability to modify various parts of the virtual environment without affecting others, as illustrated at 42. Scalability is provided by manipulation of the granular data at 44.
“Finally format 46 can be specified to the output of granular data to be able format or tailor it to the hardware involved, translate from different formats, or edit one primitive, as illustrated at 50.”
It will be appreciated that the term “granular” refers to the division of the virtual environment into separate parts, and the ability to work on each part separately.
FIG. 3. A virtual reality scene could include, for example, a table 300 and a cup 302, as well as a saucer304 and another saucer 306 (as an illustrative example, refer to FIG. These elements can be found within the virtual reality scene depending on their origin (0, 0, 0). You will see that the entire virtual reality scene can be stored in one file. This allows you to modify the individual items 300-306 without having to download the whole file. It is possible to extract saucer 306 from the virtual reality scene by using its location and edit it separately from the rest of the graphical objects. This is done by splitting the scene into locations, as shown by Locale A. File 400 shows that Locale A contains the table, the saucer, etc. while Locale B includes the condiment at position 10, 10, 0. It is evident that one can modify ever smaller portions of a virtual scene by using a relational database with a very fine granularity.
Referring to FIG. “4 refers to FIG.
“More specifically, and referring to FIG. 5A is an image 500 that depicts a scene on a screen in a virtual environment 502. This virtual environment includes a house 504, two buildings 506 & 508, a road 502., a landscape 512, and some grass 514, 516, 518, and 520. An image known as a “texture map” is displayed on the advertising billboard 522. This image is used to enhance the realism of virtual environments without increasing the number polygons that must be drawn by 3-D rendering hardware. The sounds of birds singing, wind blowing by the billboards, and houses are also audible but not visible.
“Each model (such as the house 504, shown at FIG. 5A is made up of a number of polygons. Each polygon can have specific colors assigned to them on a per-face or per-vertex basis. Each polygon may also have a “texture map” that allows it to display an image on it as if it were painting it as a detail.
Because each 3-D graphics hardware is limited in its ability to draw polygons on the screen, texture maps are essential for virtual 3-D environments. A fully detailed house may require many millions of polygons to draw accurately on the screen. However, textures can be used to replace a whole side of that house by a single rectangular polygon with an image that looks exactly like the detailed side. A 3-D graphics hardware that can draw 10,000 polygons per minute may still be capable of drawing several houses per frame at a respectable 10, 15 frames per second. These houses will still be identifiable as houses.
“Not all 3-D graphics hardware can display texture maps, but this is becoming a less common situation due to the importance of texture maps adding detail to scenes.”
“Even though most 3-D hardware supports texture mapping today, not all hardware treats textures the exact same. Some hardware supports transparent textures like glass and plastic. Some hardware requires that text images be square or at a specific size. For example, 128 pixels by 128 Pixels. One hardware is capable of storing 64 megabytes worth of texture images. This allows for the creation of richer 3-D environments.
A large virtual environment may still be possible to display if it has 4 megabytes of texture, even if there is limited memory. By reducing the number of textures in each direction by half, the total memory required by the textures will be only 1 megabyte. This would allow the textures to be displayed on a 1 gigabyte texture machine.
FIG. 5A on billboard 522, and on the side view of house 504, where a texture map was used to show the windows of the house. To display the traffic stripe, an additional texture is displayed on road 510.
“The grass 514-516, 518, 518, and 520 could all be displayed as a collection of polygons in shape of grass blades. However, typically the grass would only be one rectangular polygon with a partially transparent picture. The transparent part of the image would be colored green to represent growing grass.
Referring to FIG. “Referring now to FIG. 5B, you can see that the advertisement billboard 522′ still displays a texture map but the image has non-English lettering. Image 500′, which shows a view into the virtual world, has been created for a non-English speaker. Instead of using the original English billboard texture, it has been replaced with a texture in the native language of the viewer. You will see that there are many methods of determining the language spoken by the viewer. This includes asking them directly. If the language is known, you can substitute the image for the billboard texture map by assuming that the texture has been created in the appropriate language.
“It is also worth noting that the same substitute technique could be used for targeted advertising messages on the billboard depending upon the identity and specific interests of the person viewing it.”
There is no way to do this in the current systems. Most systems use one large file to represent the virtual world. To make any changes to this file, you will need to read the entire file and make small or large changes. Then you’ll have to save the file to your file system. It is not practical to read, modify, save, or save large files.
“It is also evident that although the overall structure of the virtual environment remains the same in all these examples, details of what is inside that environment can change depending on how the viewer views it. FIGS. FIGS. 5A and 5B will show that the grass 514, 516 and 518 are not visible in image 500?. This could be because the hardware rendering picture 500′ isn’t capable of showing partially transparent textures. The detail in House 504′ may not be as good as it could be because the hardware rendering of image 500′ cannot draw as many polygons per second than the hardware that rendered image 500.”
“In addition to the possibility that billboard 522′ might display a different image from billboard 522, but it might also be stored at a different resolution or in a different format from the image on billboard 522.
“Referring to FIGS. These figures, 6A, 6B and 6C, respectively, show a texture map similar to those used to build brick walls in virtual environments.
“FIG. “FIG. It is also stored at 24 bits per pixels to store the color information. It allows for the representation of over 16 million colors in an image. 24 bits per pixels is almost always better than one that has fewer bits. To be able for programs to access the colors, they must be stored in a certain way on non-volatile storage such as a hard drive. The most common storage formats are PNG, TIFF, and JPEG, which stand for Portable Network Graphics. Other formats such as TARGA and GIF are also available. Each refers to a particular way of storing pixel data for later use.
Each format has its own capabilities. The GIF format, for example, allows for lossless compression of image data but can only store 256 colors at 8 bits per pixels. GIF files are less effective than photographs stored in the original format. They take up less space than 24 bit images, however.
Consider also the fact that a scene with many megabytes of texture maps can take a while to download in remote environments. FIG. 6A shows an example of this uncompressed image. 6A will take approximately 10 minutes to transmit via a 28.8kbps modem, which is the industry standard. FIG. The download time for FIG. 6B is only 3 seconds. If the virtual environment contains only 30 images, it would take approximately one and a quarter minutes to download all the medium-resolution photos. It would take almost five hours to download the high-resolution ones.
“If the virtual reality environment was to be created for a CDROM-based computer, instead of the Web, and the hardware could display 30 1.7 megabyte textures per second, it would be clearly superior to that shown on the modem-based computer.”
It should be obvious that there are benefits to the ability to deliver different resolutions or formats of images in different situations, even though the overall structure of the virtual world remains the same.
Referring to FIG. “Referring to FIG. 7A, this figure illustrates a virtual environment scene that contains a landscape 702, house 704, tree 706, and cloud 708. FIG. FIG. 7B is a list of possible file systems that could contain the models and textures for landscape, house and tree.
“In a typical virtual world like the one in FIG. 7A shows the contents of the virtual environment. This includes landscape 702, tree 704, cloud 708 and house 704. 7C, or in several large files as shown at FIG. 7B. 7B. The file also includes a list of colors to indicate the color each vertex or polygon should be when rendered by hardware. The file also contains a list with textures that were used by those polygons, though the textures are rarely stored in the same file as the list.
“FIG. “FIG. 7A. 7A. The listing titled “TEXTURES? 712 actually contains all the texture map files used to render the scene in FIG. 7A might contain at most images of grasses, roofing materials, trees, and a nd pavement. Each texture file can be anywhere from 16 to 3 megabytes, depending on its resolution and depth.
“Alternatively, FIG. FIG. 7C illustrates another way where all the polygons and other information, except the texture maps, are stored in one large file called ALL.PLY 714. One large file can be used to transmit data for rendering virtual environments. This is because the author or designer of the environment doesn’t have to deal as many files as 7B. To make even small changes to the virtual environment, you will need to read in ALL.PLY 714 and then make the necessary changes, such as moving the tree slightly to the left or saving the entire ALL.PLY file. This means that only 12 bytes of the 4 megabyte file have been modified. The convenience of having only one polygon file around is overshadowed by the incontinence of reading and writing large files, even small ones.
“In addition, if you need to save an earlier version of the virtual world to keep track of changes, you will need to save another copy of the entire file. This would waste more than 4 megabytes disk space and result in a single 12 byte change.
To take this one step further, suppose that all elements of a virtual world are stored in smaller files. One object per file. This is similar to FIG. 7B is a more common and complex virtual environment. It becomes more difficult to identify files and keep track of which object is in each file as the number increases. While having only one object per file is a time saver for small changes, it becomes difficult to manage large numbers of files. The only information that the creator of the virtual world has is its size and date of creation. The file contains useful information such as the spatial limits of a model. This information is sometimes called the bounding boxes of the model. To find this information, one would need to read the file into memory and analyze it.
Referring to FIG. Referring to FIG. 6, it may be necessary to have two versions of the model available for different situations. For instance, a high-polygon count model to support high-end rendering hardware, and a low-polygon count model to support low-end PCs. In either case, the entire directory structure or its naming scheme must be duplicated. Each high-polygon count file must be replaced by its companion low-polygon count file. This can cause disk space to be excessively large in cases where there are only a few models with high- and low-polygon count counterparts.
It will be appreciated that the management of these directories and files must be done either manually or using a program. Hand managing files can be time-consuming, and it is easy to make mistakes. Programming is a more sophisticated skill that allows you to manage files from a program. Rarely will a programmer with the programming skills necessary to create a virtual environment that is beautiful and interesting also have the programming skills required to create scripts to manage the files and directories that contain that environment.
It is beneficial to have objects in the virtual environment accessible individually or in groups. It is possible to have access to all of the viewing environment at once. This is useful for viewing and transmitting virtual environments. However, it can be convenient to only access one object at a given time. It is clear that managing virtual environment objects via the file system can be difficult and inconvenient.
Referring to FIG. 8. A table 800 is shown, with a teapot 802, cone 804 and cube 806 supporting the table. The table is supported by four legs 808, 810 and 812 which are fixed to it. This image shows typical storage arrangements and requirements for virtual environments. Although this virtual environment is very small, it is an excellent example. Table 800 looks like wood, because it has a texture map that is drawn to resemble wood grain. This texture map file is stored in JPEG format. It takes up 96 kilobytes. A 32-kilobyte file contains the VRML description of the scene. This is a textual description of the scene. VRML is the Virtual Reality Modeling Language. It was developed to be a cross-platform language that allows for the description of virtual environments.
“FIG. “FIG. 8 in VRML format. To make the listing shorter, the data describing normals, vertices and colors have been replaced by \”——–DATA GOESHERE . The file contains descriptions of the table 800, teapot 802, cube 804, cone 804, four legs 808, 810 and 812 and 814. The file also contains general information about the scene including a description and attributes of the camera used to render it.
“Referring to FIG. “Referring now to FIG. These additional details are used to create a complete rendering. It is not necessary to explain the meaning of each set of numbers. Someone skilled in 3-D graphics and rendering will already be familiar with the terminology and the significance of each number. You can also read the VMRL2.0 Reference to find out the meaning of the entries. You can access the VRML Consortium’s VRML 2.0 reference material via the Internet.
Referring to FIG. 11 shows the locations of different bits of information required to create a complete virtual environment. FIG. FIG. 11. This box 1102 represents a model file. It will, in this example, end with the file name extension. Box 1104 represents an example image file. The extension of this file could be any of many depending on the storage format of the file. Box 1106 is a file containing animation information. The file’s extension could be.ANI in this example. All this information can be used in a virtual environment. The organization of this information, including how it is organized, when it appears, and how it’s used, is usually stored in programs like the cloud 1108. The program is usually written in C++ or C++ and then compiled into executables for specific machine types.
Imagine that an address book program was in development. A programmer could write the C code containing the name and address of all the people who are to be included in the address book program. The programmer would need to open the source file again, add or remove the name or address, then recompile it. Although this is a rigid way to develop an address book, it is similar to what is happening in virtual environments. It would be useful to have a database that contained specific fields. It is easy to add or delete names in a database, making it much easier to make changes.
“In the present invention, a similar approach to building virtual environments is described. The database structure allows for the creation of virtual environments. You can create a virtual environment by filling in rows or sets of data in the database. The models 1102, 1104, 1104, animation information 1106 and structure 1108 can all be stored in the same place. The data can be changed without any recompilation.
As you will see, the virtual environment no longer needs to be kept in one file. Although the file system isn’t the best place to store the virtual environment information it was used as it was easily accessible on all computers and could be modified, although not without difficulty.
“FIG. “FIG. 12” shows an example of a database design (or “schema”) that would allow for both the data as well as the structure of the virtual world to be stored in one database. Although the data is all stored in one location, it’s possible to query or extract small amounts of information from a single database. This allows for viewing and modification of the data. The schema in FIG. 12 is another example. 12 shows how to extract a complete virtual environment from a single file. However, texture maps must be extracted using VRML.
“The Locale Info Table 1200 contains information about a “locale”, which is a section of a virtual world that can be viewed separately but is often viewed together with the surrounding locales. The article “Locales: Supporting Large Multiuser Virtual Environments” by John Barrus and Richard Waters, November 1996, describes the locales in detail.
“The Locale Neighbors Table 1202 defines the relationships among Locales, allowing a virtual environments designer to create large-scale seamless virtual environments. These tables are used to describe the structure of a virtual ecosystem. They are usually stored in executable programs 1108.
“The Composition List table 1204 lists all compositions found in a given location. A composition can be a single part or an entire object, or it can include a number of parts. The hierarchy of objects and parts within a scene is determined by the combination of the Composition List Table 1204, the Node List Table 1206 and Parts List Table 1208.
The Parts table 1210 provides information about one object or part. Each part is composed of one or more primitives from the Primitives Table 1214. An audio file, or a list with polygons could be a primitive. The Texture table 1216 contains information regarding the texture maps. It may include the image, but the image could be stored in another location depending on which database was used.
“Table 1218 includes information about each creator, including the author’s names, ID numbers used to connect the Parts List and the Author Info. It also indicates which group the Author is in, as well as whether or not he/she is a supervisor.
This database structure allows you to store all information about large virtual environments in one place. It also makes it possible to modify single objects without affecting other objects. It is possible to restrict or allow certain viewers and authors to interact with the virtual environments, although it is not shown in this schema.
“It will be appreciated, FIGS. The 13-25th chapter describes one way to create a virtual environment in a database. Microsoft Access, a popular database from Microsoft Corp., Seattle Wash., is used in this example. It stores information in linked tables and is relational. This is only one way to store the information. There are many databases, such as object-oriented or object-relational that may be more efficient in certain situations. These descriptions will describe each table and explain how it is used.
“Referring to FIG. 13 is a table called Locale Info. The table 1300 includes a description of each location, which includes a readable name 1304, a ID number 1306, and a number 1308 that indicates the elevation of the terrain within the locale. There are also comments 1310 about the area. You can give locales any name, and they don’t have to be the same. However, the locale ID must be unique within one database. To indicate that an object is outside the designated locale, the height information 1308 is used. By simply adding a height to each flat polygon, you can use them to represent a 3-D volume. Anyone who is familiar with the concept should know that a 3-D volume must be defined to represent the interior of the locale to determine movement between adjacent locales.
“Note that there would be many locations in a typical database. Diamond Park, which was profiled in the Locales newspaper, contains over 60 locales. These include 5 large locales as well as many smaller ones that act as links between larger locales. A typical Locale Info table would have more than 100 locations with unique IDs.
“The second table 1302 is shown in FIG. 13 displays a list of compositions for all the locations in the database. The only thing that is different in this instance is the single locale ID 1312. This means that the locale IDs 1312 for each composition are identical. The CompositionList table only shows the top level of a composition’s hierarchy. If any compositions exist in a location that have children, this table will only show the root of the hierarchy. The children will be in another table.
“In FIG. 8. A table 800, a teapot 802 and a cone 804 is shown. The table’s legs 808, 810 and 812 are children of 800 and are therefore not included in the CompositionList Table 1302. The CompositionList 1302 also includes major and minor version numbers 1314, 1316.”
Computer programmers have been able to work incrementally for some time. This allows them to save both their current and past work by using programs like RCS (Revision Control System) or SCCS (Source Code Control System). These systems allow programmers to “check out” code and then after making revisions, “check in” the code. The new source is checked in and compared to the check-out copy. This allows the programmer to see the differences. These differences are identified with a version number, and kept with the current source. This system has the advantage that, if changes are not successful and cause software to stop working properly, one can revert back to an earlier version until the problem is fixed.
A similar capability would be extremely useful for content creators as well as 3-D authors. If one wanted to create a virtual environment that was brightly colored and then convert it to a pastel-colored environment, this could be difficult and time-consuming. The author could easily revert back to brightly colored environments due to version control. This example could be easily extended to include texturing and modeling changes, as well as color modification.
“The minor and major version numbers 1314, 1316 in CompositionList table 1302 provide a basic method for version control for content creators. Normaly, the environment would contain all the most recent versions of every composition, part, and primitive when it is extracted from the database to be viewed. On request, users can also extract older versions and view them. You can actually view a changing sequence by removing all versions of a component and displaying them side-by-side. The rest of table 1302 should be self-explanatory.
“Referring to FIG. 14 is the CompositionList Table 1400. This figure shows it for your convenience. The Node List Table 1402 shows the internal structure for hierarchies whose root nos are shown in CompositionList table 1400. Only composition IDs 0 1406 or 1408, which represent the top 800 of FIG. 8 has children. The composition ID 0 1406 and 1408, which represent the table top 800 in FIG. 8, does not have any children. Table 800 contains 4 children as shown in Node List table 1402. The Child ID 1410 can also be used in the Parts List Table 1404. It cannot be duplicated with any other composition ID in tables 1400 and 1404.
“Notice the columns Pos X 1412 and Pos Y 1414, as well as Pos Z 1416. These columns indicate the relative location of parts within the locality in relation to their parent compositions. The columns that follow Pos Z (including q1, q2, q3, q4 as well as Scale X and Y 1418) describe the relative orientation and scale of each part used in the hierarchy in this table 1402.
“Sometimes, transformations can be stored as matrices. Sometimes, it is more convenient to store these transformations in their components, which include x,y,z displacement, rotation, and x and y scaling. The database is shown to have the former. It would be trivial to store the matrices in the database instead. It is possible to store both components as well as matrices, with a flag to indicate which one to use. The components are clearly shown in this example so that you can easily see the changes in their positions.
“Table 1404 contains information about transformations. These transformations can be used to move parts in relation to the virtual environment as well as with respect to one another. It is possible to alter the transformations while the scene is being redrawn repeatedly for animation. The virtual environment will appear to move the sphere up or down by changing its X position over time. The rest position of the globe should be saved in the database. This will ensure that the virtual environment is correctly viewed when the user loads it into their computer.
“Transformations can only be performed with reference to an existing coordinate system. If an object is located in the Locale coordinate system, and a transformation has been applied, the object will be moved to a new coordinate system. The object that has an identity transformation (which means that the displacement is zero and scaling is one, and rotation is equal or greater than no rotation) will have its origin exactly at the same coordinate system as the locale’s coordinate systems. If the object is a child or a relative of a parent object, and the identity transformation has occurred, the object’s coordinate systems will align with the coordinates of the parent. This applies regardless of how the parent was transformed in relation to the coordinate system at the Locale. These transformations are widely used by people skilled in designing and rendering 3-D models with computers.
“FIG. “FIG. 8. This hierarchy corresponds to data in the database, as shown in FIG. 14, Tables 1400, 1402 & 1404. Table 1400 illustrates that Locale 0 1500 contains the cone 1502, the cube 1504 and the teapot 1506, respectively. Row 1426 also shows the table top 1508 and row 1422. The legs are not included in table 1400, as they are not at the top of the scene hierarchy. Take a look at FIG. 1402 (see table). 14 legs 1 through 4, shown in rows 1428, as well as the objects 1510-1512, 1514, and 1516 in FIG. 15 are the children of the tabletop composition 1508 shown row 1420.
“The Parts List table 1404 stores the transformations for each component of the compositions. This table associates the nodes with the individual parts. Each leg is drawn in a different location relative to the origin of table top’s 1420 or 1508 coordinate systems. Columns 1412, 1414, and 1416 show the displacements.
Summary for “3D virtual environment management and delivery system”
It will be noted that 3D virtual reality environments are stored in files. It is necessary to store, transmit, and download large files when working on a particular section of the virtual environment.
When one wants to manipulate, create and deliver a 3D virtual world file in real-time over the Internet, there are many issues. Problem areas include persistence, scalability and security, multiresolution problems, multiformat requirements, and version control.
Persistence, also known as persistence, refers to the ability of a 3D virtual environment to keep changing after a change is made. You can save changes if you rewrite the entire file. It is impossible to make permanent changes in browser-only authoring tools. It is possible to modify a small portion of a VMRL file without saving it. You will know that VMRL stands for Virtual Reality Modeling Language. This file format is used to store the content of a 3D virtual reality environment. To make changes to a file, you must first read the entire file and then save it. A VMRL file can be up to 10 megabytes in size, making it difficult for small changes.
Prior art file systems cannot be scaled to accommodate an increasing size of the 3D virtual world. This is because it is difficult to provide such capability. Most of the information is contained in one file or a small number of files. To scale up virtual reality environments, the number of files must be increased in ever increasing amounts. This creates a cumbersome and time-consuming method of managing virtual reality files. Even though VRML can be used to split larger files into smaller ones, this creates new problems in managing many small files and opens up new possibilities for errors or loss.
“In terms of security, you will appreciate that granting a security code to a single file grants access to the entire file for each user who might be attempting to edit it. It is impossible to allow access to only a portion of the file that is needed for editing while locking out the rest of the file.
“Moreover, it is difficult to divide the file into what is allowed to be seen and what is not. This allows one person to only edit a small portion of the file.”
Given the current state of the virtual environment, it is impossible to provide a multi-edit function that allows users to edit different parts of the environment simultaneously. A single file cannot provide multiple resolutions for the 3D Virtual Reality Environment. Multiple resolutions can be used to match the output file with the machine that is to receive it. Some machines can display the texture of a graphic object in detail, while others cannot. The ability to draw polygons is another important element in 3D graphics rendering. However, this ability varies from one machine to the next. It is currently impossible to create a single file with different resolutions. The entire file must be modified for each resolution. The same applies to a single file that records the 3D virtual environment. It is not possible to share the same content across multiple platforms. no crossplatform capability. One file storage approach for virtual reality environments prevents the provision of multiple formats. However, the same content can be made available in different formats.
Finally, if a single file is used for virtual reality, it is impossible to control version without duplicating the original file. For example, if a few bytes are changed in a 10 Megabyte file, it is possible to create two 10 Megabyte files to modify the version.
“In short, these problems in the creation and management of 3D virtual environments deprive present systems of the ability to manage multiple authors across multiple platforms. A system that can deliver content to different hardware devices with differing capabilities is needed. It is also important to ensure that only invited guests have access, and to allow the virtual environment grow without limits.
It is difficult to understand how the 3D environment can be made persistent and modifyable over time, allowing authors to take control of the objects in the environment and then release it at will. This is because the virtual environment is stored on one file.
A system for creating, modifying, and delivering a virtual environment is one that stores the scene or virtual reality environment in a database format. The database allows the environment to be divided and stored in different records. This allows multiple people to work in the same part of the virtual environment. It also allows for version control and allows you to save changes. Persistence, allows for scalability and security, format control, independence, and the ability to work on different parts of the virtual environment without disturbing others. Indexing allows for quick access to different parts of the environment through the use of the database.
There are advantages to prior art systems that allow individual records and objects to be changed without affecting any other records in the database. The virtual environment can be stored in a file. This allows for simultaneous changes to multiple records, such as by two or more creators. However, the changes made to other records are not affected or written over and only those records that have been modified can be updated. This greatly reduces the amount of network communication.
“The database allows you to solve problems such as persistence, scalability and multi-edit capability. Multi-resolution and multi-format version control are possible since different parts of the database can easily be queried, altered, and outputted without regard for other parts.
“It is important to note that persistence requires nonvolatile, permanent storage. This excludes RAM storage which can be volatile but includes high density disk storage which is both fast- and nonvolatile.
“It’s also important to permit access and locking in an easy-to-use manner, to encourage multiple users. If the locking granularity of the environment is too high, such as e.g. If there are not enough partitions, an author may be able to lock up large sections of the environment while modifiying only a small portion of it.
Storing the 3D environment in a database gives you persistence comparable to files on a hard drive. A database allows access to only a portion of the 3D environment, which makes modification faster than downloading and utilizing the entire file. Multiple authors can work simultaneously with concurrent access to the database and row or object locking.
“To achieve this, the database partitions are created so that the entire environment can be broken down into smaller, more manageable chunks. A “locales” approach in one embodiment is a good choice, as it allows for flexibility and scalability.
“Thus, the subject invention relates to a virtual reality environment creation and modification system. It stores information about the virtual reality environment in an electronic database that can be modified, delivered, or altered without affecting any other parts. To allow records of the database to be updated individually without affecting others, it can be accessed over a network like a wide-area network. It is possible to access the entire virtual reality environment file without having to store it. A database will also read out the version that is compatible with target machines based on the characteristics of the target machine. To accommodate different target machine characteristics, some aspects of the virtual environment, such as texture, may be stored in multiple formats. To illustrate, textures that are used in the virtual reality environment can be stored in a “high resolution, 24 bit format” for target computers with large amounts of texture memory. Target machines with less texture memory may store them in a “low resolution and lower bit depth format” while target machines with more texture memory have them stored in a “non-textured” format.
Virtual reality environments are increasingly being used. Computer games are one example of such environments. Many other applications are also being developed. A virtual reality environment could be used to train professionals in specific fields, such as medicine. For example, it might allow for the training of surgeons. Virtual reality environments allow for social interaction, allowing multiple people to connect to the environment via a network and interact with each other in the environment.
Virtual reality environments make use of a variety of resources on the target computer system that they were designed to run. The virtual reality environment will use the graphics and sound capabilities on the target computer system, for example.
Computers have a wide range of capabilities. Some high-end computers may display very detailed, textured graphics. A high-end graphics workstation may have 64 MB of texture storage. This memory is used to greatly enhance the virtual environment. Other target computers may not have texturing memory. While some target computers may be able to display 3-D graphics, others may only be able to display 2-D graphics. High-end computers may be able to produce high-fidelity sounds while lower-end systems may produce lower quality sounds. Further, network connections of computers systems can operate at different speeds in a networked environment. The network capabilities of the target machine may affect the virtual reality environment. For example, if multiple people are playing a networked video game, or if the virtual reality environment is stored on remote computers and transmitted to the target computer over the network.
“In an prior art method for distributing virtual reality environment contents to different target computers, each file contains the content such as the content of a high-end workstation as one file, and the content of a midrange workstation in a second file. The content for personal computers as a third or fourth file. A fifth file contains the content that is for a set top box.
The prior art method for creating the content for each target machine is to create each content separately and store it as a large file. Even if someone needs only a small portion of the virtual environment they still need to download the whole file. It is necessary to be able read and save 3-D virtual environments in different formats than the complete file. This allows you to download only a portion of the environment. Virtual environments that are targeted at different platforms or machines have an identical internal structure. This must be maintained for all of them. It is time-consuming and difficult to maintain multiple files in order to preserve the same internal structure.
“There are at least two additional issues that must be addressed when a portion of the content is to be changed. A change to the content of a high-end workstation will not have an impact on the content of a lower end workstation, such as a set-top box. Each file must be changed separately. A second reason is that even small changes in content require saving the whole file again. Large files can be created in virtual reality environments. It can take time to save the file, which can discourage you from making changes in the virtual reality environment.
As you will see, changing even a small portion of the virtual environment requires that the entire file be accessed. The file must also be saved to make the changes. This can lead to complicated situations. After the creator has installed the virtual reality environment on a client’s network, in Detroit, Mich. and is working remotely from California, the client requests to modify an aspect of the virtual environment. Even if the creator already has a copy on a local computer, once the requested changes have been made, the file must be sent to the client’s network. Due to the size of virtual reality environment files, it can take a long time to transfer the file to the client’s computer network. It is a requirement that a system can only work with a portion of a 3-D virtual environment file.
“But, further, the creator usually creates a virtual reality environment using a development machine. The machine used to develop the environment is usually a high-end machine. The environment will be shown using the capabilities of the high-end machine. However, it will need to be tested separately on a lower end target machine. This may result in repetitive testing, development and redevelopment. It is essential that a system can create content in multiple versions, so that different machines can view the same content.
“Virtual reality development and execution environments are needed to overcome these and other problems.”
“More specifically, the problem that must be solved is how to design a 3D environment that has multiple authors across different platforms. It is also necessary to be able deliver content to different hardware with differing capabilities. It is important that you can restrict access to content to only invited guests and allow only authorized authors to modify the environment. It is also important to allow virtual environments to grow freely despite having hard limits. For example, there must be a limit on how many polygons can be drawn per second. It is also important to keep the 3D environments flexible and adaptable over time. This allows authors to access and remove objects from the environment as they wish.
“Through the difficulties of creating, managing, and distributing 3D environments quickly, it is essential to be able bring persistence, scalability and security to real-time 3D virtual environments via the Internet. This includes multi-edit capability, multiformat for crossplatform performance capability and multi-resolution.
“Referring to FIGS. “Referring now to FIGS. It may be possible to edit the virtual scene so that a 16-pixel graphical object is located in the area indicated by dotted boxes 18. It is possible to access the portion of a relational data base that contains the specific location in which the graphical objects are located to alter the scene. In this instance, the object 16 is removed and a standing person is created.
Referring to FIG. 2 will show that to be able to edit a 3D scene, it must first be created, as shown at 20, with inputs like textures and sounds 22, primatives 24 and compositions including groups 26 and hierarchy of parts 26, and locales 28, which break up the scene into different chunks.
“The 3D environment creation is done by downloading to a granular 30 database. This database is used in the storage and editing of the 3D environments.
This allows multiple authors 32 to be able work on different parts of the virtual reality environment. As shown at 34, you can also restrict access to certain parts of the virtual reality environment. The version of the virtual environment that is selected depends on 38 hardware requirements. These requirements are set by the client using a client server system.
“Persistence can be guaranteed by the ability to modify various parts of the virtual environment without affecting others, as illustrated at 42. Scalability is provided by manipulation of the granular data at 44.
“Finally format 46 can be specified to the output of granular data to be able format or tailor it to the hardware involved, translate from different formats, or edit one primitive, as illustrated at 50.”
It will be appreciated that the term “granular” refers to the division of the virtual environment into separate parts, and the ability to work on each part separately.
FIG. 3. A virtual reality scene could include, for example, a table 300 and a cup 302, as well as a saucer304 and another saucer 306 (as an illustrative example, refer to FIG. These elements can be found within the virtual reality scene depending on their origin (0, 0, 0). You will see that the entire virtual reality scene can be stored in one file. This allows you to modify the individual items 300-306 without having to download the whole file. It is possible to extract saucer 306 from the virtual reality scene by using its location and edit it separately from the rest of the graphical objects. This is done by splitting the scene into locations, as shown by Locale A. File 400 shows that Locale A contains the table, the saucer, etc. while Locale B includes the condiment at position 10, 10, 0. It is evident that one can modify ever smaller portions of a virtual scene by using a relational database with a very fine granularity.
Referring to FIG. “4 refers to FIG.
“More specifically, and referring to FIG. 5A is an image 500 that depicts a scene on a screen in a virtual environment 502. This virtual environment includes a house 504, two buildings 506 & 508, a road 502., a landscape 512, and some grass 514, 516, 518, and 520. An image known as a “texture map” is displayed on the advertising billboard 522. This image is used to enhance the realism of virtual environments without increasing the number polygons that must be drawn by 3-D rendering hardware. The sounds of birds singing, wind blowing by the billboards, and houses are also audible but not visible.
“Each model (such as the house 504, shown at FIG. 5A is made up of a number of polygons. Each polygon can have specific colors assigned to them on a per-face or per-vertex basis. Each polygon may also have a “texture map” that allows it to display an image on it as if it were painting it as a detail.
Because each 3-D graphics hardware is limited in its ability to draw polygons on the screen, texture maps are essential for virtual 3-D environments. A fully detailed house may require many millions of polygons to draw accurately on the screen. However, textures can be used to replace a whole side of that house by a single rectangular polygon with an image that looks exactly like the detailed side. A 3-D graphics hardware that can draw 10,000 polygons per minute may still be capable of drawing several houses per frame at a respectable 10, 15 frames per second. These houses will still be identifiable as houses.
“Not all 3-D graphics hardware can display texture maps, but this is becoming a less common situation due to the importance of texture maps adding detail to scenes.”
“Even though most 3-D hardware supports texture mapping today, not all hardware treats textures the exact same. Some hardware supports transparent textures like glass and plastic. Some hardware requires that text images be square or at a specific size. For example, 128 pixels by 128 Pixels. One hardware is capable of storing 64 megabytes worth of texture images. This allows for the creation of richer 3-D environments.
A large virtual environment may still be possible to display if it has 4 megabytes of texture, even if there is limited memory. By reducing the number of textures in each direction by half, the total memory required by the textures will be only 1 megabyte. This would allow the textures to be displayed on a 1 gigabyte texture machine.
FIG. 5A on billboard 522, and on the side view of house 504, where a texture map was used to show the windows of the house. To display the traffic stripe, an additional texture is displayed on road 510.
“The grass 514-516, 518, 518, and 520 could all be displayed as a collection of polygons in shape of grass blades. However, typically the grass would only be one rectangular polygon with a partially transparent picture. The transparent part of the image would be colored green to represent growing grass.
Referring to FIG. “Referring now to FIG. 5B, you can see that the advertisement billboard 522′ still displays a texture map but the image has non-English lettering. Image 500′, which shows a view into the virtual world, has been created for a non-English speaker. Instead of using the original English billboard texture, it has been replaced with a texture in the native language of the viewer. You will see that there are many methods of determining the language spoken by the viewer. This includes asking them directly. If the language is known, you can substitute the image for the billboard texture map by assuming that the texture has been created in the appropriate language.
“It is also worth noting that the same substitute technique could be used for targeted advertising messages on the billboard depending upon the identity and specific interests of the person viewing it.”
There is no way to do this in the current systems. Most systems use one large file to represent the virtual world. To make any changes to this file, you will need to read the entire file and make small or large changes. Then you’ll have to save the file to your file system. It is not practical to read, modify, save, or save large files.
“It is also evident that although the overall structure of the virtual environment remains the same in all these examples, details of what is inside that environment can change depending on how the viewer views it. FIGS. FIGS. 5A and 5B will show that the grass 514, 516 and 518 are not visible in image 500?. This could be because the hardware rendering picture 500′ isn’t capable of showing partially transparent textures. The detail in House 504′ may not be as good as it could be because the hardware rendering of image 500′ cannot draw as many polygons per second than the hardware that rendered image 500.”
“In addition to the possibility that billboard 522′ might display a different image from billboard 522, but it might also be stored at a different resolution or in a different format from the image on billboard 522.
“Referring to FIGS. These figures, 6A, 6B and 6C, respectively, show a texture map similar to those used to build brick walls in virtual environments.
“FIG. “FIG. It is also stored at 24 bits per pixels to store the color information. It allows for the representation of over 16 million colors in an image. 24 bits per pixels is almost always better than one that has fewer bits. To be able for programs to access the colors, they must be stored in a certain way on non-volatile storage such as a hard drive. The most common storage formats are PNG, TIFF, and JPEG, which stand for Portable Network Graphics. Other formats such as TARGA and GIF are also available. Each refers to a particular way of storing pixel data for later use.
Each format has its own capabilities. The GIF format, for example, allows for lossless compression of image data but can only store 256 colors at 8 bits per pixels. GIF files are less effective than photographs stored in the original format. They take up less space than 24 bit images, however.
Consider also the fact that a scene with many megabytes of texture maps can take a while to download in remote environments. FIG. 6A shows an example of this uncompressed image. 6A will take approximately 10 minutes to transmit via a 28.8kbps modem, which is the industry standard. FIG. The download time for FIG. 6B is only 3 seconds. If the virtual environment contains only 30 images, it would take approximately one and a quarter minutes to download all the medium-resolution photos. It would take almost five hours to download the high-resolution ones.
“If the virtual reality environment was to be created for a CDROM-based computer, instead of the Web, and the hardware could display 30 1.7 megabyte textures per second, it would be clearly superior to that shown on the modem-based computer.”
It should be obvious that there are benefits to the ability to deliver different resolutions or formats of images in different situations, even though the overall structure of the virtual world remains the same.
Referring to FIG. “Referring to FIG. 7A, this figure illustrates a virtual environment scene that contains a landscape 702, house 704, tree 706, and cloud 708. FIG. FIG. 7B is a list of possible file systems that could contain the models and textures for landscape, house and tree.
“In a typical virtual world like the one in FIG. 7A shows the contents of the virtual environment. This includes landscape 702, tree 704, cloud 708 and house 704. 7C, or in several large files as shown at FIG. 7B. 7B. The file also includes a list of colors to indicate the color each vertex or polygon should be when rendered by hardware. The file also contains a list with textures that were used by those polygons, though the textures are rarely stored in the same file as the list.
“FIG. “FIG. 7A. 7A. The listing titled “TEXTURES? 712 actually contains all the texture map files used to render the scene in FIG. 7A might contain at most images of grasses, roofing materials, trees, and a nd pavement. Each texture file can be anywhere from 16 to 3 megabytes, depending on its resolution and depth.
“Alternatively, FIG. FIG. 7C illustrates another way where all the polygons and other information, except the texture maps, are stored in one large file called ALL.PLY 714. One large file can be used to transmit data for rendering virtual environments. This is because the author or designer of the environment doesn’t have to deal as many files as 7B. To make even small changes to the virtual environment, you will need to read in ALL.PLY 714 and then make the necessary changes, such as moving the tree slightly to the left or saving the entire ALL.PLY file. This means that only 12 bytes of the 4 megabyte file have been modified. The convenience of having only one polygon file around is overshadowed by the incontinence of reading and writing large files, even small ones.
“In addition, if you need to save an earlier version of the virtual world to keep track of changes, you will need to save another copy of the entire file. This would waste more than 4 megabytes disk space and result in a single 12 byte change.
To take this one step further, suppose that all elements of a virtual world are stored in smaller files. One object per file. This is similar to FIG. 7B is a more common and complex virtual environment. It becomes more difficult to identify files and keep track of which object is in each file as the number increases. While having only one object per file is a time saver for small changes, it becomes difficult to manage large numbers of files. The only information that the creator of the virtual world has is its size and date of creation. The file contains useful information such as the spatial limits of a model. This information is sometimes called the bounding boxes of the model. To find this information, one would need to read the file into memory and analyze it.
Referring to FIG. Referring to FIG. 6, it may be necessary to have two versions of the model available for different situations. For instance, a high-polygon count model to support high-end rendering hardware, and a low-polygon count model to support low-end PCs. In either case, the entire directory structure or its naming scheme must be duplicated. Each high-polygon count file must be replaced by its companion low-polygon count file. This can cause disk space to be excessively large in cases where there are only a few models with high- and low-polygon count counterparts.
It will be appreciated that the management of these directories and files must be done either manually or using a program. Hand managing files can be time-consuming, and it is easy to make mistakes. Programming is a more sophisticated skill that allows you to manage files from a program. Rarely will a programmer with the programming skills necessary to create a virtual environment that is beautiful and interesting also have the programming skills required to create scripts to manage the files and directories that contain that environment.
It is beneficial to have objects in the virtual environment accessible individually or in groups. It is possible to have access to all of the viewing environment at once. This is useful for viewing and transmitting virtual environments. However, it can be convenient to only access one object at a given time. It is clear that managing virtual environment objects via the file system can be difficult and inconvenient.
Referring to FIG. 8. A table 800 is shown, with a teapot 802, cone 804 and cube 806 supporting the table. The table is supported by four legs 808, 810 and 812 which are fixed to it. This image shows typical storage arrangements and requirements for virtual environments. Although this virtual environment is very small, it is an excellent example. Table 800 looks like wood, because it has a texture map that is drawn to resemble wood grain. This texture map file is stored in JPEG format. It takes up 96 kilobytes. A 32-kilobyte file contains the VRML description of the scene. This is a textual description of the scene. VRML is the Virtual Reality Modeling Language. It was developed to be a cross-platform language that allows for the description of virtual environments.
“FIG. “FIG. 8 in VRML format. To make the listing shorter, the data describing normals, vertices and colors have been replaced by \”——–DATA GOESHERE . The file contains descriptions of the table 800, teapot 802, cube 804, cone 804, four legs 808, 810 and 812 and 814. The file also contains general information about the scene including a description and attributes of the camera used to render it.
“Referring to FIG. “Referring now to FIG. These additional details are used to create a complete rendering. It is not necessary to explain the meaning of each set of numbers. Someone skilled in 3-D graphics and rendering will already be familiar with the terminology and the significance of each number. You can also read the VMRL2.0 Reference to find out the meaning of the entries. You can access the VRML Consortium’s VRML 2.0 reference material via the Internet.
Referring to FIG. 11 shows the locations of different bits of information required to create a complete virtual environment. FIG. FIG. 11. This box 1102 represents a model file. It will, in this example, end with the file name extension. Box 1104 represents an example image file. The extension of this file could be any of many depending on the storage format of the file. Box 1106 is a file containing animation information. The file’s extension could be.ANI in this example. All this information can be used in a virtual environment. The organization of this information, including how it is organized, when it appears, and how it’s used, is usually stored in programs like the cloud 1108. The program is usually written in C++ or C++ and then compiled into executables for specific machine types.
Imagine that an address book program was in development. A programmer could write the C code containing the name and address of all the people who are to be included in the address book program. The programmer would need to open the source file again, add or remove the name or address, then recompile it. Although this is a rigid way to develop an address book, it is similar to what is happening in virtual environments. It would be useful to have a database that contained specific fields. It is easy to add or delete names in a database, making it much easier to make changes.
“In the present invention, a similar approach to building virtual environments is described. The database structure allows for the creation of virtual environments. You can create a virtual environment by filling in rows or sets of data in the database. The models 1102, 1104, 1104, animation information 1106 and structure 1108 can all be stored in the same place. The data can be changed without any recompilation.
As you will see, the virtual environment no longer needs to be kept in one file. Although the file system isn’t the best place to store the virtual environment information it was used as it was easily accessible on all computers and could be modified, although not without difficulty.
“FIG. “FIG. 12” shows an example of a database design (or “schema”) that would allow for both the data as well as the structure of the virtual world to be stored in one database. Although the data is all stored in one location, it’s possible to query or extract small amounts of information from a single database. This allows for viewing and modification of the data. The schema in FIG. 12 is another example. 12 shows how to extract a complete virtual environment from a single file. However, texture maps must be extracted using VRML.
“The Locale Info Table 1200 contains information about a “locale”, which is a section of a virtual world that can be viewed separately but is often viewed together with the surrounding locales. The article “Locales: Supporting Large Multiuser Virtual Environments” by John Barrus and Richard Waters, November 1996, describes the locales in detail.
“The Locale Neighbors Table 1202 defines the relationships among Locales, allowing a virtual environments designer to create large-scale seamless virtual environments. These tables are used to describe the structure of a virtual ecosystem. They are usually stored in executable programs 1108.
“The Composition List table 1204 lists all compositions found in a given location. A composition can be a single part or an entire object, or it can include a number of parts. The hierarchy of objects and parts within a scene is determined by the combination of the Composition List Table 1204, the Node List Table 1206 and Parts List Table 1208.
The Parts table 1210 provides information about one object or part. Each part is composed of one or more primitives from the Primitives Table 1214. An audio file, or a list with polygons could be a primitive. The Texture table 1216 contains information regarding the texture maps. It may include the image, but the image could be stored in another location depending on which database was used.
“Table 1218 includes information about each creator, including the author’s names, ID numbers used to connect the Parts List and the Author Info. It also indicates which group the Author is in, as well as whether or not he/she is a supervisor.
This database structure allows you to store all information about large virtual environments in one place. It also makes it possible to modify single objects without affecting other objects. It is possible to restrict or allow certain viewers and authors to interact with the virtual environments, although it is not shown in this schema.
“It will be appreciated, FIGS. The 13-25th chapter describes one way to create a virtual environment in a database. Microsoft Access, a popular database from Microsoft Corp., Seattle Wash., is used in this example. It stores information in linked tables and is relational. This is only one way to store the information. There are many databases, such as object-oriented or object-relational that may be more efficient in certain situations. These descriptions will describe each table and explain how it is used.
“Referring to FIG. 13 is a table called Locale Info. The table 1300 includes a description of each location, which includes a readable name 1304, a ID number 1306, and a number 1308 that indicates the elevation of the terrain within the locale. There are also comments 1310 about the area. You can give locales any name, and they don’t have to be the same. However, the locale ID must be unique within one database. To indicate that an object is outside the designated locale, the height information 1308 is used. By simply adding a height to each flat polygon, you can use them to represent a 3-D volume. Anyone who is familiar with the concept should know that a 3-D volume must be defined to represent the interior of the locale to determine movement between adjacent locales.
“Note that there would be many locations in a typical database. Diamond Park, which was profiled in the Locales newspaper, contains over 60 locales. These include 5 large locales as well as many smaller ones that act as links between larger locales. A typical Locale Info table would have more than 100 locations with unique IDs.
“The second table 1302 is shown in FIG. 13 displays a list of compositions for all the locations in the database. The only thing that is different in this instance is the single locale ID 1312. This means that the locale IDs 1312 for each composition are identical. The CompositionList table only shows the top level of a composition’s hierarchy. If any compositions exist in a location that have children, this table will only show the root of the hierarchy. The children will be in another table.
“In FIG. 8. A table 800, a teapot 802 and a cone 804 is shown. The table’s legs 808, 810 and 812 are children of 800 and are therefore not included in the CompositionList Table 1302. The CompositionList 1302 also includes major and minor version numbers 1314, 1316.”
Computer programmers have been able to work incrementally for some time. This allows them to save both their current and past work by using programs like RCS (Revision Control System) or SCCS (Source Code Control System). These systems allow programmers to “check out” code and then after making revisions, “check in” the code. The new source is checked in and compared to the check-out copy. This allows the programmer to see the differences. These differences are identified with a version number, and kept with the current source. This system has the advantage that, if changes are not successful and cause software to stop working properly, one can revert back to an earlier version until the problem is fixed.
A similar capability would be extremely useful for content creators as well as 3-D authors. If one wanted to create a virtual environment that was brightly colored and then convert it to a pastel-colored environment, this could be difficult and time-consuming. The author could easily revert back to brightly colored environments due to version control. This example could be easily extended to include texturing and modeling changes, as well as color modification.
“The minor and major version numbers 1314, 1316 in CompositionList table 1302 provide a basic method for version control for content creators. Normaly, the environment would contain all the most recent versions of every composition, part, and primitive when it is extracted from the database to be viewed. On request, users can also extract older versions and view them. You can actually view a changing sequence by removing all versions of a component and displaying them side-by-side. The rest of table 1302 should be self-explanatory.
“Referring to FIG. 14 is the CompositionList Table 1400. This figure shows it for your convenience. The Node List Table 1402 shows the internal structure for hierarchies whose root nos are shown in CompositionList table 1400. Only composition IDs 0 1406 or 1408, which represent the top 800 of FIG. 8 has children. The composition ID 0 1406 and 1408, which represent the table top 800 in FIG. 8, does not have any children. Table 800 contains 4 children as shown in Node List table 1402. The Child ID 1410 can also be used in the Parts List Table 1404. It cannot be duplicated with any other composition ID in tables 1400 and 1404.
“Notice the columns Pos X 1412 and Pos Y 1414, as well as Pos Z 1416. These columns indicate the relative location of parts within the locality in relation to their parent compositions. The columns that follow Pos Z (including q1, q2, q3, q4 as well as Scale X and Y 1418) describe the relative orientation and scale of each part used in the hierarchy in this table 1402.
“Sometimes, transformations can be stored as matrices. Sometimes, it is more convenient to store these transformations in their components, which include x,y,z displacement, rotation, and x and y scaling. The database is shown to have the former. It would be trivial to store the matrices in the database instead. It is possible to store both components as well as matrices, with a flag to indicate which one to use. The components are clearly shown in this example so that you can easily see the changes in their positions.
“Table 1404 contains information about transformations. These transformations can be used to move parts in relation to the virtual environment as well as with respect to one another. It is possible to alter the transformations while the scene is being redrawn repeatedly for animation. The virtual environment will appear to move the sphere up or down by changing its X position over time. The rest position of the globe should be saved in the database. This will ensure that the virtual environment is correctly viewed when the user loads it into their computer.
“Transformations can only be performed with reference to an existing coordinate system. If an object is located in the Locale coordinate system, and a transformation has been applied, the object will be moved to a new coordinate system. The object that has an identity transformation (which means that the displacement is zero and scaling is one, and rotation is equal or greater than no rotation) will have its origin exactly at the same coordinate system as the locale’s coordinate systems. If the object is a child or a relative of a parent object, and the identity transformation has occurred, the object’s coordinate systems will align with the coordinates of the parent. This applies regardless of how the parent was transformed in relation to the coordinate system at the Locale. These transformations are widely used by people skilled in designing and rendering 3-D models with computers.
“FIG. “FIG. 8. This hierarchy corresponds to data in the database, as shown in FIG. 14, Tables 1400, 1402 & 1404. Table 1400 illustrates that Locale 0 1500 contains the cone 1502, the cube 1504 and the teapot 1506, respectively. Row 1426 also shows the table top 1508 and row 1422. The legs are not included in table 1400, as they are not at the top of the scene hierarchy. Take a look at FIG. 1402 (see table). 14 legs 1 through 4, shown in rows 1428, as well as the objects 1510-1512, 1514, and 1516 in FIG. 15 are the children of the tabletop composition 1508 shown row 1420.
“The Parts List table 1404 stores the transformations for each component of the compositions. This table associates the nodes with the individual parts. Each leg is drawn in a different location relative to the origin of table top’s 1420 or 1508 coordinate systems. Columns 1412, 1414, and 1416 show the displacements.
Click here to view the patent on Google Patents.How to Search for Patents
A patent search is the first step to getting your patent. You can do a google patent search or do a USPTO search. Patent-pending is the term for the product that has been covered by the patent application. You can search the public pair to find the patent application. After the patent office approves your application, you will be able to do a patent number look to locate the patent issued. Your product is now patentable. You can also use the USPTO search engine. See below for details. You can get help from a patent lawyer. Patents in the United States are granted by the US trademark and patent office or the United States Patent and Trademark office. This office also reviews trademark applications.
Are you interested in similar patents? These are the steps to follow:
1. Brainstorm terms to describe your invention, based on its purpose, composition, or use.
Write down a brief, but precise description of the invention. Don’t use generic terms such as “device”, “process,” or “system”. Consider synonyms for the terms you chose initially. Next, take note of important technical terms as well as keywords.
Use the questions below to help you identify keywords or concepts.
- What is the purpose of the invention Is it a utilitarian device or an ornamental design?
- Is invention a way to create something or perform a function? Is it a product?
- What is the composition and function of the invention? What is the physical composition of the invention?
- What’s the purpose of the invention
- What are the technical terms and keywords used to describe an invention’s nature? A technical dictionary can help you locate the right terms.
2. These terms will allow you to search for relevant Cooperative Patent Classifications at Classification Search Tool. If you are unable to find the right classification for your invention, scan through the classification’s class Schemas (class schedules) and try again. If you don’t get any results from the Classification Text Search, you might consider substituting your words to describe your invention with synonyms.
3. Check the CPC Classification Definition for confirmation of the CPC classification you found. If the selected classification title has a blue box with a “D” at its left, the hyperlink will take you to a CPC classification description. CPC classification definitions will help you determine the applicable classification’s scope so that you can choose the most relevant. These definitions may also include search tips or other suggestions that could be helpful for further research.
4. The Patents Full-Text Database and the Image Database allow you to retrieve patent documents that include the CPC classification. By focusing on the abstracts and representative drawings, you can narrow down your search for the most relevant patent publications.
5. This selection of patent publications is the best to look at for any similarities to your invention. Pay attention to the claims and specification. Refer to the applicant and patent examiner for additional patents.
6. You can retrieve published patent applications that match the CPC classification you chose in Step 3. You can also use the same search strategy that you used in Step 4 to narrow your search results to only the most relevant patent applications by reviewing the abstracts and representative drawings for each page. Next, examine all published patent applications carefully, paying special attention to the claims, and other drawings.
7. You can search for additional US patent publications by keyword searching in AppFT or PatFT databases, as well as classification searching of patents not from the United States per below. Also, you can use web search engines to search non-patent literature disclosures about inventions. Here are some examples:
- Add keywords to your search. Keyword searches may turn up documents that are not well-categorized or have missed classifications during Step 2. For example, US patent examiners often supplement their classification searches with keyword searches. Think about the use of technical engineering terminology rather than everyday words.
- Search for foreign patents using the CPC classification. Then, re-run the search using international patent office search engines such as Espacenet, the European Patent Office’s worldwide patent publication database of over 130 million patent publications. Other national databases include:
- European Patent Office (EPO) provides esp@cenet to access a network of Europe’s patent databases with access to machine translation of European patents.
- Japan Patent Office (JPO) – with access to machine translations of Japanese patents.
- World Intellectual Property Organization (WIPO) offers PATENTSCOPE with a full-text search of published international patent applications and machine translations for some documents, as well as a list of international patent databases.
- Korean Intellectual Property Rights Information Service (KIPRIS)
- State Intellectual Property Office (SIPO) with machine translation of Chinese patents.
- Other International Intellectual Property Offices with online patent databases include Australia, Canada, Denmark, Finland, France, Germany, Great Britain, India, Israel, Netherlands, Norway, Sweden, Switzerland, and Taiwan.
- Search non-patent literature. Inventions can be made public in many non-patent publications. It is recommended that you search journals, books, websites, technical catalogs, conference proceedings, and other print and electronic publications.
To review your search, you can hire a registered patent attorney to assist. A preliminary search will help one better prepare to talk about their invention and other related inventions with a professional patent attorney. In addition, the attorney will not spend too much time or money on patenting basics.
Download patent guide file – Click here