Class TX3DFileItem

Unit

Declaration

type TX3DFileItem = class(TPersistent)

Description

Base class for any item within X3D file: a node, a field, a route, a prototype etc. We need a common base class for all such things to store PositionInParent.

Hierarchy

  • TObject
  • TPersistent
  • TX3DFileItem

Overview

Methods

Public constructor Create;
Public procedure SaveToStream(Writer: TX3DWriter); virtual; abstract;
Public function SaveToXml: TSaveToXmlMethod; virtual;

Properties

Public property PositionInParent: Integer read FPositionInParent write FPositionInParent default -1;

Description

Methods

Public constructor Create;

This item has no description.

Public procedure SaveToStream(Writer: TX3DWriter); virtual; abstract;

Save to stream.

Public function SaveToXml: TSaveToXmlMethod; virtual;

How is this saved to X3D XML encoding. This determines when SaveToStream is called. It also cooperates with some SaveToStream implementations, guiding how the item is actually saved. By default it is sxChildElement.

Properties

Public property PositionInParent: Integer read FPositionInParent write FPositionInParent default -1;

Position of this item within parent VRML/X3D node, used for saving the VRML/X3D graph to file. Default value -1 means "undefined".

For normal usage and processing of VRML graph, this is totally not needed. This position doesn't dictate actual meaning of VRML graph. If you're looking to change order of nodes, you probably want to rather look at something like ReplaceItems within TMFNode or such.

This field is purely a hint when encoding VRML file how to order VRML items (nodes, fields, routes, protos) within parent node or the VRML file. Reason: VRML allows non-unique node names. Each DEF XXX overrides all previous ("previous" in lexical sense, i.e. normal order of tokens in the file) DEF XXX with the same XXX, thus hiding previous node name "XXX". This means that when saving VRML file we have to be very careful about the order of items, such that e.g. all routes are specified when appropriate node names are bound.

This is a relative position, relative to other PositionInParent value of other TX3DFileItem items. So it's not necessary to keep all PositionInParent different or successive within some parent. When saving, we will sort everything according to PositionInParent.

See e.g. ../../../demo_models/x3d/tricky_def_use.x3dv for tests of some tricky layout. When reading such file we have to record PositionInParent to be able to save such file correctly.


Generated by PasDoc 0.16.0-snapshot.