| Home >> All >> com >> [ trapezium Javadoc ] |
Page 1 2
| • | com.trapezium.attractor.* (13) | • | com.trapezium.bean.* (2) | • | com.trapezium.cdk.* (6) |
| • | com.trapezium.chisel.* (154) | • | com.trapezium.edit.* (9) | • | com.trapezium.factory.* (14) |
| • | com.trapezium.html.* (1) | • | com.trapezium.humanoid.* (7) | • | com.trapezium.javascript.* (1) |
| • | com.trapezium.parse.* (9) |
• com.trapezium: Javadoc index of package com.trapezium.
Package Samples:
• com.trapezium.attractor
• com.trapezium.bean
• com.trapezium.cdk
• com.trapezium.chisel
• com.trapezium.chisel.cleaners
• com.trapezium.chisel.codeveloper
• com.trapezium.chisel.condensers
• com.trapezium.chisel.gui
• com.trapezium.chisel.help
• com.trapezium.chisel.mutators
• com.trapezium.chisel.reducers
• com.trapezium.chisel.reorganizers
• com.trapezium.edit
• com.trapezium.factory
• com.trapezium.html
• com.trapezium.humanoid
• com.trapezium.javascript
• com.trapezium.parse
Classes:
• SpaceStructure: The SpaceStructure keeps track of vertices, edges, and faces in a somewhat fluid manner. There are three sets of objects, corresponding to vertices, edges, and faces, but these sets can be mixed, and relationships created between these sets. This is done to allow transformations of one type into another. A SpaceEntitySet represents a set of SpacePrimitive objects used by a particular space structure. The Strategy field "primitiveHandler" indicates the current visualization of a space entity and its surrounding entities. Relationships between the sets are created as needed, only r1 is known at the ...
• IndexInfo: Tracks association between index, perVertex, and value fields. The IndexInfo is used to track associates between related fields. The technique used repeatedly in the VRML 2.0 spec is centered on coord and coordIndex. The coord is a Node, coordIndex is not. This means coord values can be DEFfed and USEd, but index values cannot. The second technique is associations between coord and texCoord, color, and normal fields. This assocation is implicit in the data. If the texCoord, color, or normal nodes exist, and there is no texCoordIndex, colorIndex, normalIndex, then these three nodes (texCoord, color, ...
• AttractorPolygonReduction: Abstract base class for all attractor reduction chisels. Attractor polygon reduction chisels use one IFS (the attractor) to reduce a second IFS (the floater). It does this by warping the first IFS onto the second. The result has the same basic polygon count as the first IFS, but the same shape as the second IFS. Actually, the resulting polygon count is the same as triangulating all faces of the attractor IFS by placing a vertex in the center of the face and connecting it to the surrounding vertices. The reduction takes place in two phases. First, the floater IFS is partitioned into sets of coordinates. ...
• VRML97parser: Main class for parsing a VRML 2.0 file. A Scene is the root of a VRML element hierarchy. This is a simple hierarchy where each VrmlElement may or may not have children. Much of the additional functionality required is implemented by using the "Visitor Pattern" on this hierarchy. This pattern encapsulates features in the visitor objects. Within the SceneRule factory, the above parameters eventually turn into a Token enumerator, and the Scene is constructed as follows: TokenEnumerator tokenEnumerator = ... Scene scene = new Scene( fileUrl, tokenEnumerator ); VRML97parser parser = new VRML97parser(); ...
• TokenEnumerator: Converts an InputStream into a sequence of tokens used by parsing. 1.0 architecture had Token objects, this replaced in 1.1 with less elegant, but more memory efficient byte array with run-length-encoding of initial spaces to store VRML file in memory. Each token still contains the same information as previously, except is now represented as an "int", and is accessed only through the TokenEnumerator. The information associated with each token is: line number offset in line of start of token size of token (number of characters it contains) type of token Quoted strings are implemented with two token ...
• PROTORule: Creates the scene graph component for a PROTO declaration. Grammar handled by "Build" method: proto ::= PROTO nodeTypeId [ interfaceDeclarations ] { protoBody } ; interfaceDeclarations ::= interfaceDeclaration | interfaceDeclaration interfaceDeclarations | empty ; protoBody ::= protoStatements node statements ; protoStatements ::= protoStatement | protoStatement protoStatements | empty ; Note: the implementation of the "protoBody" portion of above grammar is done through the SceneRule, followed by a check that the body consists of at least one node. This check (and possible error mark) is done ...
• PROTOcollector: The PROTOcollector resolves conflicts introduced when one scene graph is merged into another. It collects infomation about all conflicts, then provides information about those conflicts. The method "resolveConflicts" resolves those which can be handled in-place. Otherwise, it has methods for extracting the information token by token. In-place conflict resolution handles DEF/USE/PROTO naming conflicts, but does not handle moving PROTOs to new locations in the file. Conflict resolution is one of two ways: the DEFNameFactory in the destination scene is used if it exists, otherwise an algorithm of ...
• VrmlElement: A VrmlElement is the base class for any object in the VRML 2.0 object hierarchy. Specific subclasses get created as a ".wrl" file is parsed. The grammar determines which type of element to create during parsing. Each VrmlElement contains zero or more children, which are also VrmlElement. The object hierarchy for this is very simple. The root level object is a Scene, with children that are Nodes or ROUTEs. Node children are fields. This object hierarchy parallels the VRML syntax. The VrmlElement implements the visitor pattern, which allows the object structure to be traversed after it is created. ...
• TokenFactory: Assigns a range of characters within a line to a token of a particular type. Adapted from initial 1.0 strategy of creating Token objects. This approach abandoned due to OutOfMemory exception, tokens now managed within TokenEnumerator with arrays. The optimization that required this has complicated the code, since it was not initially designed this way. The TokenFactory is a single class that has taken the place of several classes in the previous architecture. The port from one architecture to the other was very straightforward, but has resulted in what appears to be very unusual and messy class ...
• Scene: Scene graph component representing an entire VRML file, or the body of a PROTO. The only difference between the PROTO body and a Scene is that the PROTO body is required to have at least one node. This restriction is not part of the Scene, and is a check performed by the grammar package during parsing. The Scene has a single Declaration for each child element. The Scene gives the name scope for PROTO and DEF nodes. As a file is processed, any PROTO and DEF nodes are registered with the Scene. Name uniqueness is forced during this registration by appending "_1", "_2", etc.
• NodeStatementRule: Creates the scene graph component for a node This is the only part of the grammar other than the VRML97parser that is publicly accessible. This is necessary because SFNodeValue and MFNodeValue in the com.trapezium.vrml.fields package use an instance of this to create node scene graph components. Grammar handled by "Build" method: nodeStatement ::= node | DEF nodeNameId node | USE nodeNameId ; The portion "DEF nodeNameId node" is handled by DEFRule.java The portion "USE nodeNameId" is handled by USERule.java
• Chisel: Main class for Chisel. The Chisel class manages the data, the processing of the data, and the user interface. Data is contained in an array of ProcessedFile objects. Processing is controlled by an array of chisel descriptors. The user interface is implemented in an interior class called FrontEnd, which owns gui components created by ComponentFactory. Chisel also is the central hub for event traffic. Commands from any source are dispatched by Chisel. The ChiselFileTable handles all events from file processing, and forwards some of these to Chisel.
• ComplexityData: Information related to complexity of a scene graph. This is used to accumulate error and polygon count information during the processing of files. The ComplexityVisitor contains a ComplexityData element where it stores its information. If several files are being processed, a single global ComplexityData object is used to contain the sum of their information. Each time a ComplexityVisitor completes its traversal of the scene graph, it updates the global ComplexityData with the data from that single traversal (see the "addInfo" method).
• SpecNodeRule: Process the file we are using to generate built in node classes. This is similar, but not identical to ".wrl" file processing. The "Spec" object is built as follows: Spec s = new Spec(); SpecRule.Build( v, s ); The spec grammar is: spec: specNode specNode: Category categoryName { interfaceDeclarations* } nodeType { interfaceDeclarations* } When the "Spec" object has been created, we create a visitor to visit each node, and generate code based on the interfaceDeclarations and the embedded controls (tips, etc.)
• KeyValueRemover: The KeyValueRemover removes keys and corresponding keyValues if the following conditions are encountered: 1. a key of the form: ... a a a .... ^ this middle value (one or more) and corresponding keyValue entries are removed. 2. a keyValue of the form ... a a a .... ^ this middle keyValue (one or more) and corresponding key entries are removed.
• ChiselAWTAction: class ChiselJAction extends DefaultAction implements ActionImpl { ActionListener owner; public ChiselJAction(ActionListener owner, String name) { super(name); this.owner = owner; } public void actionPerformed(ActionEvent e) { owner.actionPerformed(e); } public String getName() { return getText(NAME); } public void setName(String name) { setText(NAME, name); } }
• ScriptGutRule: Creates the scene graph component for the internals of a Script node. This is much different than other built in nodes because Script nodes allow user defined interface (field) extensions. Grammar handled by "Build" method: scriptGut: nodeGut restrictedInterfaceDeclaration eventIn fieldType eventInId IS eventInId eventOut fieldType eventOutId IS eventOutId field fieldType fieldId IS fieldId
• BehaviorBean: The BehaviorBean contains the set of DEFs and associated ROUTEs for a particular behavior. At the moment, it uses an "ultimate" root, which is the first ROUTE in a chain of ROUTEs. This might not be appropriate, since this might be some sort of sensor with associated geometry. An alternate approach, which might be better in other cases is to just use the first TimeSensor encountered as the "ultimate" root.
• InterfaceDeclarationRule: Creates an interface field scene graph component. The "interfaceDeclaration" handles exposedField, field, eventIn, and eventOut interface declarations. field, eventIn, and eventOut declarations are handled by the RestrictedInterfaceDeclarationRule. Grammar handled by "Build" method: interfaceDeclaration: restrictedInterfaceDeclaration exposedField fieldType fieldId fieldValue
• IFS_DupCoordDetector: Detects and removes unnecessarily duplicated values in a coord, texCoord, color, or normal node. These are not removed if the Coordinate/TextureCoordinate/Color/ Normal node are DEFfed and USEd by a ROUTE. This is based on the assumption that the ROUTE changes the values, therefore editting these affects the corresponding "index" field, which exists for ROUTEd values and not for the pre-existing values.
• PROTONodeRule: Creates the scene graph component for a PROTO instance. Grammar handled by "Build" method: protoNodeTypeId { nodeGuts } Note: the PROTOInstance "copyBaseNodeInfo" method does not copy all nodes in the PROTO declaration body, and substitute values as indicated by IS. When this is done, PROTO checking can be done for PROTO interface fields passed through IS.
• PROTOInstance: Scene graph component for a PROTO instance. The PROTOInstance has field values which are explicitly declared, and are part of the PROTO interface. It has node values which are copied from the PROTO declaration, with actual values from the instance substituted where indicated by IS fields. Note: The above level of PROTOInstance construction is not complete. USE nodeNameId
• TitleBar: A title bar control for a movable window. The title bar displays a title, moves the window which owns it. By default it assumes its parent is the window to move, but any ancestor can be specified. The title bar can also contain up to three buttons (minimize, maximize and close) as specified in the style parameter. The default is a maximize and a close button.
• Spec: The scene graph component for a Spec node. Spec nodes were used to generate source files in package com.trapezium.vrml.node.generated. Re-architecture due to OutOfMemory problem made generated nodes much less complex, probably should eliminate these eventually. Note: spec nodes & code generation no longer works. Probably need to drop this altogether.
| Home | Contact Us | Privacy Policy | Terms of Service |