em7’s VRDev tm
Guide to the API for VRML development
� 1998 Electrohouse, Inc. ALL RIGHTS RESERVED
Adding VRDev to a VB Project Interfaces The VRMLFactory Object Field objects Node objects Assigning a DEF name to a node object
Routing The Traversal Objects Retrieving the string value for a scene branch
EXTERNPROTO Expansion Packs Techniques Create classes which contain small VRML scenes
The difference between USE and CopyValue in the SFNode field
As a scripted language, VRML seems relatively simple.
All the VRML developer needs to do is write a simple ASCII file, and entire worlds can be virtually built.
Unfortunately, any VRML scene of significance requires an extraordinarily long file, which most developers just do not have the resources to create… or the patience to type by hand. And, once a VRML developer moves past the simple primitive shapes offered by the language, they find themselves faced with the task of creating more complex shapes to fit the needs of their scenes.
Many developers simply have a difficult time generating the numbers required by VRML’s IndexedLineSet, IndexedFaceSet and Extrusion nodes to make the shapes they need. Populating these nodes by hand is exhausting at best.
Meeting these challenges, several VRML authoring applications have become available in the marketplace that allow a designer to place objects into a scene and to edit them in place, in a WYSIWYG style.
Unfortunately, these VRML world authoring tools are "designer-oriented" and provide little help for application programmers who want to create VRML objects or scenes which are dependent on things such as:
Developers need a "developer-oriented" application building tool set that automatically creates complex, interactive, data-driven VRML scenes.
That’s why we built VRDev™!
VRDev is a set of Microsoft COM classes that allow a developer, who is not a VRML expert, to create VRML content with their favorite programming language.
With the VRDev classes, a developer can construct an arbitrarily complex VRML scene tree, set all of the properties of the VRML objects, integrate with data sources and then export the result to a VRML file for view in browsers. All without writing a single line of VRML code, checking braces, or counting brackets!
VRDev makes it easy for VRML non-experts to code in their preferred programming language… Visual Basic, Java, Delphi or C/C++.
Here are some of the benefits of using VRDev :
This document describes the usage of the VRDev package for application developers.
A description of the interfaces on the VRDev classes, and how objects interact to build a scene tree, is discussed in detail. Several examples are given to aid the text.
The methods and properties on all of the classes follow the VRML 2.0 standard, so they will not be discussed in detail (a VRML book will describe their uses).
VRDev is available as an ActiveX control, or OCX.
To add the VRDev OCX component to your Visual Basic project, select ‘Project | Components’ from the main menu bar. This will bring up a list of all of the ActiveX controls that can be added to your toolbar.
Scroll through the list and select the entry labeled "VRDev components" by clicking on it’s check box. If you have the 30 day demo, the label will read "VRDev 30 Day Demo".
Once you select it, you will see a small red ‘em7’ logo in your toolbox.
If you click on it to select it, you place it on a form. The VRDev OCX works similarly to the Common Dialog OCX. It may not be resized and is invisible at run time. Any of the VRDev ProtoPac expansion packs may be inserted into a project in the same way.
If you view the Visual Basic object browser (by pressing F2), you will see a list of all library references in your project in the top left corner of the object browser area. Select the VRDev line from the drop down, and the object list will be populated with the objects contained in VRDev.
This will allow you to view all of the classes, method declarations, properties and types.
It is important to note that all classes are "Public / Not Creatable".
This means that you can access VRDev objects, but you cannot create any of them with the Visual Basic ‘New’ keyword. Instead, the VRDev OCX offers a single property called "Factory" which returns the active instance of the VRDev object factory.
The VRDev Factory class implements the IVRMLFactory interface, but supports no methods or properties of it’s own, so make sure that any variable which refers to this object is of type IVRMLFactory. This is explained further in the VRMLFactory section.
Most of the classes provided by VRDev implement multiple interfaces (see a Microsoft COM reference for more information on interfaces).
Briefly, an interface exposes the functional capability of an object.
A COM interface is a predefined declaration of methods and/or properties that an object must impliment if it wants to support that particular interface. Interfaces also allow for polymorphism among COM objects.
Two different objects that both support the same interface may be referenced by a pointer of that interface type. However, only the methods and properties of that interface may be called while using that same interface pointer.
Here is an example :
IName
Public Property Get Name ()
Class First
Implements IName
public sub SayHello (
MsgBox "Hello from First"
)
public Property Get IName_Name (
IName_Name = "First"
)
Class Second
Implements IName
public sub SayHello (
MsgBox "Hello from Second"
)
public Property Get IName_Name (
IName_Name = "Second"
)
Main
Dim firstRef as First
dim secondRef as Second
Dim nameRef as IName
Set firstRef = new First
Call firstRef.SayHello
(Message box appears saying "Hello from First")
Set secondRef = new Second
Call secondRef.SayHello
(Message box appears saying "Hello from Second")
Set nameRef = firstRef
MsgBox nameRef.Name
(Message box appears saying "First")
Set nameRef = secondRef
MsgBox nameRef.Name
(Message box appears saying "Second")
When we set the ‘firstRef’ variable to a new instance of ‘First,’ the only method it could call on it was ‘SayHello.’
The ‘Name’ property is not visible from this reference.
The same is true of the ‘secondRef’ variable. Then, when the ‘nameRef’ variable was set to the ‘firstRef’ value, ‘nameRef’ could only access the ‘Name’ property... the ‘SayHello’ method was not in this variables scope.
The same was true when the ‘nameRef’ was set to the ‘secondRed’ variable’s value. This example demonstrates how the same pointer (‘nameRef’) can access two separate class types (First and Second).
The ‘nameRef’ pointer can, however, only access the properties or methods defined for that particular interface (the ‘Name’ property).
VRDev supplies an object for each VRML type, such as SFBool or MFRotation.
IVRMLField is the interface supported by all VRML field objects in VRDev. The following methods and properties are defined for this interface:
Typically, the user will not be declaring new instances of the field objects.
Whenever a node object is used, all field objects used by the node are created inside the node and may be retrieved or set through the Get/Set properties on those nodes.
The specific fields and their interfaces are discussed later in this document.
All nodes in the VRDev package support the IVRMLNode interface.
The following methods and properties are defined for this interface :
All objects in a scene tree which are capable of being traversed support the ITraversable interface.
Supporting this interface makes them accessible to a traversal object that supports the ITraverser interface. Traversers and traversable objects communicate to each other through these two interfaces.
As a note, this interface is used exclusively by the traversal objects and should not be accessed by developer. It’s methods are listed here for documentation purposes only.
The following methods are defined for this interface :
- Traverse (Method) : instructs the object to report it’s contents to the traversing object. This method passes the traversing object itself as a parameter, so that the traversed objects can communicate back to them.
- RegisterProtos (Method) : instructs all extern protos to register themselves so that when the VRML nodes are traversed, all headers can be collected at the beginning of the VRML. Extern proto headers are written or printed once to the file or string per type of extern proto, regardless of the instance count.
This interface is implemented by a traversal object and is used to recieve communications back from the nodes being traversed. This interface will not be used by the developer.
This interface is the main object factory for the VRDev package.
The only object that supports this interface currently is the VRMLFactory object (used for creating instances of VRDev objects from string references). An instance of this object may be created through the VRDev OCX’s Factory property. Any object may be created through this interface.
The following methods and properties are defined:
This interface will be used heavily in the section that deals with the ExternProto extensions to VRDev.
VRDev enables new node objects to be made with the ExternProto VRML structure and this interface provides a way to integrate ExternProtos into the scene tree. Any node represented as an ExternProto in the VRML file must support this interface.
The following methods and properties are defined for this interface :
The VRMLFactory Object is the main creation point for all of the VRDev expansion pack objects (VRDev ProtoPacs).
The VRMLFactory Object implements the IVRMLFactory interface, but it provides no methods of it’s own, so all references to a factory object must be of type IVRMLFactory. Active factory objects are retrieved through the VRDev OCX’s Factory property.
An object of any VRML field type may be retrieved through the CreateField method (except for SFImage).
By passing the name of the field type, for instance "SFFloat" or "SFNode", an object of that type will be created in the factory and returned to the calling code. The same is true for VRDev node creation. By passing a VRML 2.0 node name, for instance "Appearance" or "Shape" to the CreateNode method, that object will be created and returned. Be aware that the arguments are case sensitive. The CreateField method supports all of the VRML 2.0 nodes (except for PixelTexture).
A traversal (string or file) object may be retrieved through the CreateTraverser method. . Valid values here are "VRMLFileTraverser" and "VRMLStringTraverser". Finally, a RouteCollection may be retrieved through the CreateRouteCollection method.
Some sample code might look like this :
Dim objGroup as VRDev.Group
Dim factoryRef as IVRMLFactory
Set factoryRef = Form1.VRDevCtl1.Factory
Set objGroup = factoryRef.CreateNode("Group")
There is a VRDev object for each of the standard VRML data types (with the exception of SFImage).
All of the VRDev field objects support two interfaces; IVRMLField and ITraversable. Most likely, the developer will not need to use either.
The following is a list of the methods and properties supplied by each of the VRDev field objects. Note : each object supplies either a CopyValue or CopyValues method.
In each object, these methods take the same type of object as a parameter and do a straight copy of its contents into the parameter object. Calling this method does not cause any sharing dependencies between two field objects.
SFBool :
SFFloat :
SFInt32 :
SFString :
SFTime :
SFNode :
SFColor :
SFVec2f :
SFVec3f :
SFRotation :
The following are the objects that represent the MF VRML types.
Each maintains an internal array that is accessible only through the exposed methods. Each array begins at index 1, and it’s highest index is the current value count. If a method is called which requires an index, and that index is not in the range [1..count], then an exception is thrown.
MFFloat :
MFInt32 :
MFString :
MFColor :
MFVec2f :
MFVec3f :
MFRotation :
MFNode :
VRDev support the complete set of VRML 2.0 standard nodes (with the exception of Script and Proto).
Because the interfaces on the node objects are the same, each particular of the node interface will not be discussed (a description of the functionality of each field can be found in any VRML 2.0 text book).
This section will describe various techniques for generating and assembling complex VRML scenes with VRDev and how the nodes objects can be used most effectively in an application.
Each node has one or more fields, each of which is implemented as Get properties on the particular node object.
These field properties are all built from the VRDev VRML field objects. Due to naming conflicts, each field property has the word "Field" appended to the end (for instance, the "string" field of the Text node conflicts with the string data type).
As an example, the VRDev Transform node has a property called "TranslationField" which is a Get property of type SFVec3f. It is very important to remember that, when you reference any of a node object’s field properties, a value is not being returned. Instead, an object of that field is returned which contains the actual value.
For example :
Assume the following code :
Dim objMat as Material
Dim factoryRef as IVRMLFactory
Set factoryRef = Form1.VRDevCtl1.Factory
Set objMat = factoryRef.CreateNode("Material")
objMat.TransparencyField = 0.5 ‘ WRONG!
objMat.TransparencyField.Value = 0.5 ‘ RIGHT!
In the first call (labeled WRONG), the expression on the left hand side of the equals sign evaluates to an SFFloat object. Trying to assign the literal value 0.5 is, thus, incorrect.
The SFFloat object’s Value property should be properly referenced, as in the second call (labeled CORRECT). Here, both sides of the equal sign evaluate to a ‘float’ value.
The field properties are implemented only as GET properties for this reason. The properties themselves serve only to retrieve the VRML field object, which in the example above, was an SFVec3f object.
If the contents of one field are to be assigned to another field, the CopyValue(s) method can be used, ensuring that the types are correct and also that no sharing dependencies are generated.
Fields that accept a VRML node are implemented with the SFNode class, so there is no type checking of nodes assigned to these fields.
Unfortunately, in VRML, there are restrictions such as this.
For example, only a Material node may be assigned to an Appearance node’s material field. It would seem simple enough to implement the SFNode type fields to only accept nodes of a particular type.
However, the oversight becomes clear when the EXTERNPROTO node is introduced to a scene.
With the EXTERNPROTO node, VRML developers can create their own nodes. To extend our example, let’s assume that a developer wants to make a new type of material called SeeThroughMaterial. When implemented as an EXTERNPROTO, the developer can make SeeThroughMaterial act exactly like a regular Material node.
However, the SeeThroughMaterial node does not have to support any of the fields that the regular material node does.
In COM terms, this is equivalent to saying, "SeeThroughMaterial and Material may be referenced by the same variable, yet they share no common interface." This is a direct contradiction of the way that COM works.
Therefore, they node type checking is left to the developer for the sake of being able to make EXTERNPROTOs available as VRDev extensions.
Assigning a DEF name to a node object
If the user wants to assign a DEF name so that the node can be later USEd in the VRML scene, the code would look like this. Let’s assume that we have two Appearance nodes and one material node, and we want to DEF the Material node for use in the second Appearance. The code is as follows:
Dim objApp1 as Appearance
Dim objApp2 as Appearance
Dim objMat as Material
Dim nodeRef as IVRMLNode
Dim factoryRef as IVRMLFactory
Set factoryRef = Form1.VRDevCtl1.Factory
Set objApp1 = factoryRef.CreateNode("Apppearance")
Set objApp2 = factoryRef.CreateNode("Apppearance")
Set objMat = factoryRef.CreateNode("Material")
Set nodeRef = objMat ‘ get the IVRMLNode interface
nodeRef.DEF = "COMMON_MATERIAL"
objApp1.MaterialField.Value = objMat
objApp2.MaterialField.USE = objMat
Here, the three objects are created and a second variable of type IVRMLNode is set to objMat. This retrieves the IVRMLNode interface on the objMat object.
Using this reference, we can set the DEF name for the node to "COMMON_MATERIAL".
When objApp1 is exported to file or string, it will contain the verbose objMat node text with the DEF name, and objApp2 will contain the USE keyword referencing the DEF objMat node.
The most important part of assembling a VRML file is building the scene tree.
Typically, this involves nesting several nodes inside of a grouping node, then nesting several grouping nodes inside another grouping node and so on, until a natural node (scene) tree is established.
Establishing a parent / child relationship between two nodes is done through the SFNode and MFNode fields.
Any node which supports a field of type SFNode or MFNode qualifies to be a parent node. Any node which supports the IVRMLNode interface qualifies to be a child node (note that all VRML node objects support the IVRMLNode interface).
Simple parent / child relationships exist when a node supports a field of type SFNode. An example of this is the Text node, which has the "fontStyle" field. It is not a grouping node because the fontStyle field can only reference a single node (typically the FontStyle node).
More complex parent / child relationships exist through the grouping nodes, such as Group, Transform and LOD. Here, arrays of nodes may be stored under the grouping node and each will inherit some quality from the node that groups it.
For instance, nodes grouped under a transform are all subject to certain spatial qualities (transforms, rotations, etc.) which are dictated by the Transform node under which they are grouped. When grouping nodes become nested in more grouping nodes, a VRML scene tree in naturally created.
When a node is exported to a file or converted to a string with VRDev, it carries with it all of the nodes which lay on it’s lower branches.
If a Group node is exported to a file, al of it’s children are exported and all of it’s children’s children are exported and so on. Therefore, an important concept when using VRDev is that of having a root node, which will usually be a grouping node.
This node will group all top-level nodes in the VRML scene.
To make this clearer, imagine taking a standard VRML file and wrapping the whole scene with a single Group node. This has no effect on the scene itself, except that now the scene has a single root under which the whole scene exists.
This is also a key concept when using the VRML EAI.
Once a root node has been established, the scene tree may be constructed underneath it. When the scene tree is ready to export to file or string, the root node will provide the single point of entry for the scene.
This is the standard way that scene tree building is done with VRDev.
The routing which builds event circuits in a VRML scene is an essential final step for the developer using VRDev.
Without event routing, all of the animate and interactive nature of VRML 2.0 is lost. In order to provide routing in the VRML scene, VRDev provides two simple classes that will provide your scene with event routing; the Route class and the RouteCollection class.
The interface to these classes are as follows :
Route :
RouteCollection :
The Route class manages a single route in the VRML scene.
The RouteCollection class provides a high level interface for managing a list of route objects. Routes can be added to a RouteCollection in two different ways.
The first way to add a route to a RouteCollection is to create a Route object, populate it’s data and then add it to the RouteCollection using the AddRoute, InsertRoute or Set1Route methods.
The second way is to call the AddRouteValues method on the RouteCollection, which creates a Route object internally and populates it with the passed parameters.
Routes can be retrieved from the collection using the Get1Value method. When a Route object has been either created or obtained from the RouteCollection, it’s properties can be set.
VRDev enables the developer to maintain Multiple RouteCollection, allowing a scene is to be exported to several different files, each using the same scene tree, but having different routing schemes.
In a VRML scene, the following type check must be satisfied, otherwise the VRML route is invalid.
All of these type checks are done at run time.
Therefore, if you have written an application that will produce a faulty VRML file, it may compile, but it will generate an exception at run time.
Here is how each of the four type checks are made.
1. To perform DEF name checking, whenever a node is assigned to a Route’s SourceNode or DestinationNode properties, the node is checked for containing a DEF name that consists of at least one character. If the DEF name is an empty or space filled string, an exception is thrown. Although this check is made, no check is made on the correctness of the DEF name (for instance, you could assign the DEF name "Text" to a node and no exception would be thrown, however, this is illegal in a VRML scene because it is a keyword). For a description of what makes a DEF name legal, consult a VRML 2.0 book.
2. Whenever a node is assigned to a Route’s SourceEventOut property, the Route object retrieves the EventOut collection object from that node through the IVRMLNode interface. If this eventOut does not exist, an exception is thrown. Furthermore, the VRML type of the eventIn is checked, and if the eventOut that was set is not of that type, an exception is thrown. As a rule, however, if the DestinationNode is still null, this type check is not performed. The SourceNode property must also be set before the SourceEventOut property is set, otherwise, the existence of the eventOut cannot be checked. If the SourceEventOut property is set when the SourceNode property is null, an exception is thrown.
3. Similarly, the same check is done on the DestinationEventIn property when it is set, except the Route node checks for it’s existence through the EventInCollection supplied through the IVRMLNode interface.
4. The fourth check is described in checks 2 and 3.
Although this type checking seems rigid, VRDev will ensure that the routing is correct before the scene tree is exported to a file.
One of VRDev’s strongest features is the ability to export the scene tree to a VRML file in one call. The same may be done for exporting the scene tree as a string. This is done through the VRMLFileTraverser and VRMLStringTraverser objects. When the scene tree is to be exported, the a traversal does a two pass tree traversal. First, it scans for EXTERNPROTO references, which must be declared at the beginning of the VRML. Then it does a second pass for the node contents. The result is a file or string which is produced very fast, almost instantaneous, that is ready for use with any VRML 2.0 compliant browser.
Retrieving the string value for a scene branch
Retrieving a string representation of a scene branch can be done with the VRMLStringTraverser object. The following is the definition of the VRMLStringTraverser object.
VRMLStringTraverser :
This is useful if there the application is communicating with an embedded VRML browser which supports the standard EAI createVrmlFromString() function. The VRMLStringTraverser object prints from a root node, down through all of it’s contents. Therefore, it is best to manage your scene tree objects so that all base level nodes are contained in a root grouping node (such as the Group node). This grouping node can then be exported to a file and the whole scene tree will be included.
Finally, when the scene tree has been turned into a string, a RouteCollection can be turned into a string and concatenated to provide the event routing that appears at the end of the VRML file. However, since routing is not always used, exporting a RouteCollection is optional.
If we wanted to get the string for an Appearance node which had a Material node assigned to it, the code might look like this :
Dim objApp as Appearance
Dim objMat as Material
Dim appString as String
Dim factoryRef as IVRMLFactory
Dim stringTrav as VRMLStringTraverser
Set factoryRef = Form1.VRDevCtl1.Factory
Set objApp = factoryRef.CreateNode("Apppearance")
Set objMat = factoryRef.CreateNode("Material")
objApp.MaterialField.Value = objMat
Set stringTrav = factoryRef.CreateTraverser("VRMLStringTraverser")
Call stringTrav.ExportString(objApp, Nothing)
This will return a string with the VRML text for the Appearance node (including the Material node) just as you would see it in a VRML file. There is a slight warning, however. The strings contain no carriage returns and if there are nested nodes, the strings can get very long.
Exporting the scene branch to an ascii file
The following is the definition of the VRMLFileTraverser object.
VRMLFileTraverser :
The VRMLFileTraverser object prints from a root node, down through all of it’s contents (see above).
The following is an example of some code to export a VRML file from a Group node root, using the VRMLFileTraverser object.
Dim objGroup as Group
Dim fileTrav as VRMLFileManager
Dim factoryRef as IVRMLFactory
Set factoryRef = Form1.VRDevCtl1.Factory
Set objGroup = factoryRef.CreateNode("Group")
‘ some code in here which builds a scene tree
Set fileTrav = factoryRef.CreateTraverser("VRMLFileTraverser")
Call fileTrav.ExportToFile(App.Path & "\test.wrl", objGroup)
This code will print the Group node and all of it’s branches. If a RouteCollection had been created, it would have been specified as the third parameter to the ExportToFile call, and the routes would have been appended to the end of the VRML file.
When the file is printed, the following is automatically guaranteed :
It is our belief that EXTERNPROTOs are the key to creating quality VRML with minimal file size.
That’s why we created VRDEV ProtoPacs.
Through the use of EXTERNPROTO nodes wrapping Script nodes, EM7 has introducing several expansion packs (VRDEV ProtoPacs) which extend the use of VRML 2.0 efficiently and with very little file size overhead. The VRML extensions are available in the following four VRDev products:
To accompany these EXTERNPROTO expansion packs from EM7, VRDev incorporates several new nodes.
The VR_UI expansion pack allows the user to add several user interface components, typically found in a windowing environment, to a VRML scene.
With the use of these nodes, an element of user interactivity is added to a scene that the standard VRML nodes don’t provide. The components in this package include the following:
The VR_NAV expansion pack allows the developer to add many different navigation aids which will give the viewer greater involvement with a VRML scene.
Being able to navigate through a scene is one of the most challenging aspects for most new VRML users. This package allows the user to give complete freedom to the viewer, or help them through the scene intuitively. Along with these tools are a few more visual widgets for use in a VRML scene.
The components in the VR_NAV expansion pack include the following:
The VR_GRAPH expansion pack allows the user to construct graphs and charts like never before.
With the use of these nodes, "Next Generation" charts can be produced quickly and efficiently. Furthermore, new compound charts types can be created just by mixing types in the same charts to convey more data. Because you are working with chart shapes, the look of the chart is entirely up to the developer. The components in this package include the following:
The VR_DB expansion pack gives the developer read access to any database which is connectable through ODBC. Only ODBC is currently supported, and there is no support for write queries (other media than VRML may be better suited for data entry).
VR_DB was designed to provide very high-level, easy-to-use, record management within a VRML scene. Unlike the low-level ‘SQLexec’ node proposed by Oracle Corporation, VR_DB SQL PROTOs correspond directly to the VRML data types, and there are various ways that these PROTOs may be used to get full database reading capabilities.
The usefulness of these nodes is in their interface.
VR_DB SQL PROTOs are structured to resemble a standard bi-directional SQL resultset, such as one would see use with VB or JDBC (although JDBC is forward only). Though the two are different, the PROTOs attempt to be a cross between these two models. Furthermore, because there is a SQL node for each VRML field type, type matching is simple.
This package also introduces the idea of a "flattened" 2D array of floats (or MFFloat). The query is built to retrieve an unbound 2D array, but the result comes back flattened, or serialized, for use in the ElevationGrid node, Surface or ElevationWireframe expansion nodes.
The components in this package include the following :
- SQLSFBool : This node is used for retrieving values from a boolean column in a database. The result set values are exported row by row through an SFBool eventOut which is triggered when the query is executed or when the cursor moves.
- SQLSFFloat : This node is used for retrieving values from a floating point column in a database. The result set values are exported row by row through an SFFloat eventOut which is triggered when the query is executed or when the cursor moves.
- SQLSFInt32 : This node is used for retrieving values from an integer or long column in a database. The result set values are exported row by row through an SFInt32 eventOut which is triggered when the query is executed or when the cursor moves.
- SQLSFString : This node is used for retrieving values from a string column in a database. The result set values are exported row by row through an SFString eventOut which is triggered when the query is executed or when the cursor moves.
- SQLSFColor : This node is used for retrieving values from a multiple floating point columns in a database. The result set values are exported row by row through an SFColor eventOut which is triggered when the query is executed or when the cursor moves.
- SQLSFVec2f : This node is used for retrieving values from a multiple floating point columns in a database. The result set values are exported row by row through an SFVec2f eventOut which is triggered when the query is executed or when the cursor moves.
- SQLSFVec3f : This node is used for retrieving values from a multiple floating point columns in a database. The result set values are exported row by row through an SFVec3f eventOut which is triggered when the query is executed or when the cursor moves.
- SQLSFRotation : This node is used for retrieving values from a multiple floating point columns in a database. The result set values are exported row by row through an SFRotation eventOut which is triggered when the query is executed or when the cursor moves.
- SQLMFFloat : This node is used for retrieving values from a floating point column in a database. The result set values are exported through blocks of rows (with a definable size) through an MFFloat eventOut which is triggered when the query is executed or when the cursor moves. The cursor may move row by row or block by block.
- SQLMFInt32 : This node is used for retrieving values from an integer or long column in a database. The result set values are exported through blocks of rows (with a definable size) through an MFInt32 eventOut which is triggered when the query is executed or when the cursor moves. The cursor may move row by row or block by block.
- SQLMFString : This node is used for retrieving values from string column in a database. The result set values are exported through blocks of rows (with a definable size) through an MFString eventOut which is triggered when the query is executed or when the cursor moves. The cursor may move row by row or block by block.
- SQLMFColor : This node is used for retrieving values from multiple floating point columns in a database. The result set values are exported through blocks of rows (with a definable size) through an MFColor eventOut which is triggered when the query is executed or when the cursor moves. The cursor may move row by row or block by block.
- SQLMFVec2f : This node is used for retrieving values from multiple floating point columns in a database. The result set values are exported through blocks of rows (with a definable size) through an MFVec2f eventOut which is triggered when the query is executed or when the cursor moves. The cursor may move row by row or block by block.
- SQLMFVec3f : This node is used for retrieving values from multiple floating point columns in a database. The result set values are exported through blocks of rows (with a definable size) through an MFVec3f eventOut which is triggered when the query is executed or when the cursor moves. The cursor may move row by row or block by block.
- SQLMFRotation : This node is used for retrieving values from multiple floating point columns in a database. The result set values are exported through blocks of rows (with a definable size) through an MFRotation eventOut which is triggered when the query is executed or when the cursor moves. The cursor may move row by row or block by block.
- SQLFlattenedMFFloat : This node is used for retrieving values from multiple floating point columns in a database. However, unlike the other MF types, the number of columns which may be retrieved from is unbound. When the query is performed, the result set for the particular query is retrieved, and the column values are serialized in the order in which they are specified in the node interface. For instance, if three columns were being retrieved, "A", "B" and "C", the values in column "A" would be first, the values of column "B" would be appended to those of "A", and then the column values of "C" would be appended to those of "A" and "B", making one long array of values out of what was originally a two dimensional result set. The result set values are exported through blocks of rows (with a definable size) through an MFFloat eventOut which is triggered when the query is executed or when the cursor moves. The cursor may move row by row or block by block. This node is particularly useful for nodes like the ElevationGrid, which uses serialized 2D arrays of floats (in the form of MFFloat) for the height values.
While the interface and usage of VRDev is rather straightforward, there are some techniques which will make it much more powerful and extensible.
VRDev eases the task of creating VRML scenes, but that does not mean that applications that use it cannot break down into spaghetti code once the code size starts increasing. Some of the techniques to make VRDev code more understandable are described below.
As mentioned before, it is always important to start from a single root VRML node.
Not only is this important for exporting to a file or to string, but this will also help maintain readability and clarity of the code you write.
Create classes which contain small VRML scenes
It is a wise strategy to create classes that encapsulate small branches of the larger VRML scene.
These objects can then be reused anywhere in your code. This is much more powerful than using the DEF/USE keywords, because you can create objects with individual properties (like making an EXTERNPROTO).
The best way to manage these objects is to encapsulate all of the VRML behind methods and properties, and then expose the root node of this class through a Get property.
When it is time to add that branch to the tree, just add that root node property. Your code will become much more elegant using this method.
The difference between USE and CopyValue in the SFNode field
It is important to understand the difference between VRML USE and CopyValue in the SFNode field. Here is an explanation of exactly what each does :
Although the CopyValue call seems dangerous, there can be many times when it is useful. For instance, if a set of Shape nodes are to all have the same Appearance, the three appearance SFNode fields can all share a single Appearance node. Any change to the appearance of any of the shapes and the change is seen by all.