Class TIndexedFaceSetNode_1

Unit

Declaration

type TIndexedFaceSetNode_1 = class(TIndexedFacesOrTrianglesNode_1)

Description

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

Common base class for VRML 1.0 indexed polygon nodes (IndexedFaceSet and IndexedTriangleMesh).

Hierarchy

Overview

Methods

Public procedure InternalCoordPolygons( State: TX3DGraphTraverseState; PolygonHandler: TIndexedPolygonHandler); override;
Public function InternalTexCoord(State: TX3DGraphTraverseState; out ATexCoord: TX3DNode): boolean; override;
Public procedure CreateNode; override;
Public class function ClassX3DType: String; override;
Public class function ForVRMLVersion(const Version: TX3DVersion): Boolean; override;
Public procedure SetRadianceTransfer(const Value: array of TVector3); overload;
Public procedure SetRadianceTransfer(const Value: TVector3List); overload;

Properties

Public property FdRadianceTransfer: TMFVec3f read FFdRadianceTransfer;

Description

Methods

Public procedure InternalCoordPolygons( State: TX3DGraphTraverseState; PolygonHandler: TIndexedPolygonHandler); override;

This item has no description. Showing description inherited from TAbstractGeometryNode.InternalCoordPolygons.

Splits coordinate-based node into polygons.

Indexes in PolygonHandler point to CoordIndex, if assigned, or directly to Coord. The ordering of generated polygons is correct, so what pointed CCW in the node field, will still point CCW according to generated PolygonHandler indexes.

In this class this does nothing. Some, but not all, coordinate-based nodes (the ones when InternalCoord returns True) override this. So currently, whether this is implemented is coordinated with CastleInternalNormals and such internal needs.

Public function InternalTexCoord(State: TX3DGraphTraverseState; out ATexCoord: TX3DNode): boolean; override;

This item has no description. Showing description inherited from TAbstractGeometryNode.InternalTexCoord.

Node's texture coordinates. Returns False if node cannot have texture coordinates.

Returns True and sets ATexCoord to a node defining texture coords. ATexCoord may be set to TAbstractTextureCoordinateNode descendant or to TTextureCoordinate2Node_1 (latter one only for VRML <= 1.0). ATexCoord can also be set to Nil in this case, which means that this node has a field for texCoord, but it's empty right now.

In base TAbstractGeometryNode class this looks at TexCoordField, eventually returns False.

Public procedure CreateNode; override;

Create node fields and events.

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.

Public procedure SetRadianceTransfer(const Value: array of TVector3); overload;

This item has no description.

Public procedure SetRadianceTransfer(const Value: TVector3List); overload;

This item has no description.

Properties

Public property FdRadianceTransfer: TMFVec3f read FFdRadianceTransfer;

Internal wrapper for property RadianceTransfer. This wrapper API may change, we advise to access simpler RadianceTransfer instead, if it is defined (TODO: for now, some field types do not have a simpler counterpart).


Generated by PasDoc 0.16.0-snapshot.