Class TShapeHintsNode_1

Unit

Declaration

type TShapeHintsNode_1 = class(TAbstractChildNode)

Description

This item has no description. Showing description inherited from TAbstractChildNode.

Abstract node type that indicates that the node may be used as a child of a grouping node, e.g. inside TAbstractGroupingNode.FdChildren.

Hierarchy

Overview

Methods

Protected function ParseNodeBodyElement(Lexer: TX3DLexer; Reader: TX3DReaderNames; const APositionInParent: Integer): boolean; override;
Public procedure CreateNode; override;
Public class function ClassX3DType: string; override;
Public class function ForVRMLVersion(const Version: TX3DVersion): Boolean; override;

Properties

Public property FdVertexOrdering: TSFEnum read FFdVertexOrdering;
Public property FdShapeType: TSFEnum read FFdShapeType;
Public property FdFaceType: TSFEnum read FFdFaceType;
Public property FdCreaseAngle: TSFFloat read FFdCreaseAngle;
Public property CreaseAngle: Single read GetCreaseAngle write SetCreaseAngle;

Description

Methods

Protected function ParseNodeBodyElement(Lexer: TX3DLexer; Reader: TX3DReaderNames; const APositionInParent: Integer): boolean; override;

This item has no description. Showing description inherited from TX3DNode.ParseNodeBodyElement.

Parse VRML node body element. Usually, this is a field. May also be VRML 1.0 style child node. May also be VRML 2.0 Script node interface declaration, etc. — see VRML 2.0 grammar spec.

This should be overriden to parse special features within particular nodes. While generally VRML is very clean and there's no need to override this, there's one use for this currently:

  1. Since we handle a couple of VRML flavors (at least Inventor, VRML 1.0 and VRML 97), sometimes the same node has different fields to express the same things in various VRML flavors. So it may be useful to parse a field and copy it's value into other fields.

    Example: TShapeHintsNode_1 in Inventor parses "hints" field, and copies it's value to other fields as appropriate. "hints" field is not exposed in TShapeHintsNode_1 interface, so everything is clean in the interface, and under the hood TShapeHintsNode_1 can "magically" handle "hints" field for Inventor.

When overriding, always check inherited result first, and exit if inherited handled successfully. Otherwise either read your stuff and return True (Lexer should advance to the position of next "nodeBodyElement"). Or return False without changing Lexer position.

Public procedure CreateNode; override;

This item has no description. Showing description inherited from TAbstractChildNode.CreateNode.

Automatically generated node properties.

Do not edit this file manually! To add new properties: - add them to the text files in tools/internal/x3d-nodes-to-pascal/nodes-specification/ , - and regenerate include files by running x3d-nodes-to-pascal

Public class function ClassX3DType: string; override;

This item has no description. Showing description inherited from TX3DNode.ClassX3DType.

Node type name in VRML/X3D, for this class. Normal VRML/X3D node classes should override this to return something non-empty, and then X3DType automatically will return the same value.

Empty for classes that don't have a hardcoded VRML/X3D node name, like a special TX3DUnknownNode. Such special classes should override then X3DType to return actual non-empty name there.

You usually should call X3DType. The only use of this method is that it works on classes (it's "class function"), without needing at actual instance.

Public class function ForVRMLVersion(const Version: TX3DVersion): Boolean; override;

This item has no description. Showing description inherited from TX3DNode.ForVRMLVersion.

Some nodes are present only in specific VRML/X3D version. This functions decides it.

For example some nodes can only work in VRML < 2.0, some others only in VRML >= 2.0. There are even some pairs of nodes: for example TConeNode_1 works with VRML < 2.0, TConeNode works with VRML >= 2.0.

NodesManager will use this.

Default implementation of this function returns always True. Generally, I don't try to set this too aggresively — in other words, for all cases when it's sensible, I allow nodes to be used in every VRML/X3D version, even when official specification doesn't. This means that when reading VRML 1.0 files actually a large part of VRML 2.0 is allowed too, and also while reading VRML 2.0 many constructs from VRML 1.0 (officially no longer present in VRML 2.0) are allowed too. I'm trying to support what I call a "sum of VRML 1.0 and 2.0".

In practice I only use this function when various VRML/X3D versions specify the same node name but

  • With different fields.

    For example Cone and Cylinder have slightly different fields, due to the fact that VRML 2.0 resigned from using TSFBitMask fields.

  • With different behavior.

    For example definitions of Sphere for VRML 1.0 and 2.0 are practically equal. However, the behavior from where to take texture and material info is different — in VRML 1.0 we take last Texture2, Material etc. nodes, while in VRML 2.0 we look in parent Shape's "appearance" field. So once again two different Sphere classes are needed.

Properties

Public property FdVertexOrdering: TSFEnum read FFdVertexOrdering;

Internal wrapper for property VertexOrdering. This wrapper API may change, we advise to access simpler VertexOrdering instead.

Public property FdShapeType: TSFEnum read FFdShapeType;

Internal wrapper for property ShapeType. This wrapper API may change, we advise to access simpler ShapeType instead.

Public property FdFaceType: TSFEnum read FFdFaceType;

Internal wrapper for property FaceType. This wrapper API may change, we advise to access simpler FaceType instead.

Public property FdCreaseAngle: TSFFloat read FFdCreaseAngle;

Internal wrapper for property CreaseAngle. This wrapper API may change, we advise to access simpler CreaseAngle instead.

Public property CreaseAngle: Single read GetCreaseAngle write SetCreaseAngle;

This item has no description.


Generated by PasDoc 0.16.0.