- 1 Tool Pipeline
- 1.1 COM Interfaces
- 1.1.1 Tool
- 220.127.116.11 (1) SDK: ILxTool interface
- 18.104.22.168 (2) SDK: ILxTool interface
- 22.214.171.124 (3) SDK: Declarations
- 126.96.36.199 (4) SDK: Declarations
- 188.8.131.52 (5) SDK: ILxTool interface
- 184.108.40.206 (6) SDK: ILxTool interface
- 220.127.116.11 (7) SDK: Declarations
- 18.104.22.168 (8) PY: Tool method
- 22.214.171.124 (9) SDK: Declarations
- 126.96.36.199 (10) SDK: Declarations
- 188.8.131.52 (11) SDK: Declarations
- 184.108.40.206 (12) SDK: Declarations
- 1.1.1 Tool
- 1.2 ILxTool1 (Legacy Interface)
- 1.2.1 (13) SDK: ILxTool1 interface
- 1.2.2 (14) SDK: Declarations
- 1.2.3 Attribute Sequence
- 1.2.4 Tool Operation
- 1.1 COM Interfaces
- 2 ToolVector
- 2.1 (24) SDK: Declarations
- 2.2 Standard Tool Packets
- 2.2.1 Subject Packet
- 2.2.2 Action Center Packet
- 2.2.3 Axis
- 2.2.4 Transform Packet
- 2.3 Object Tool Packets
- 2.3.1 (31) SDK: Declarations
- 2.3.2 Falloff Packet Interface
- 2.3.3 Symmetry Packet Interface
- 2.3.4 Subject Packet Interface
- 2.3.5 Texture Packet Interface
- 2.3.6 Element Axis Packet Interface
- 2.3.7 Element Center Packet Interface
- 2.4 Path and Particle Generator Object Packets
- 2.4.1 Path Generator Packet Interface
- 2.4.2 Path Generator: Nodes and their data
- 220.127.116.11 (62) SDK: LXtPathKnot struct
- 18.104.22.168 (63) SDK: Declarations
- 22.214.171.124 (64) SDK: ILxPathGeneratorPacket interface
- 126.96.36.199 (65) SDK: ILxPathGeneratorPacket interface
- 188.8.131.52 (66) SDK: ILxBagGenerator interface
- 184.108.40.206 (67) SDK: Declarations
- 220.127.116.11 (68) User Class: BagGenerator method
- 18.104.22.168 (69) PY: BagGenerator method
- 2.4.3 Path Generator: Walking the Path
- 22.214.171.124 (70) SDK: ILxPathStep interface
- 126.96.36.199 (71) SDK: ILxPathStep interface
- 188.8.131.52 (72) SDK: ILxPathStep interface
- 184.108.40.206 (73) SDK: Declarations
- 220.127.116.11 (74) User Class: PathStep method
- 18.104.22.168 (75) PY: PathStep method
- 22.214.171.124 (76) SDK: ILxPathGeneratorPacket interface
- 126.96.36.199 (77) SDK: Declarations
- 188.8.131.52 (78) SDK: ILxPathGeneratorPacket interface
- 184.108.40.206 (79) SDK: Declarations
- 220.127.116.11 (80) User Class: PathGeneratorPacket method
- 18.104.22.168 (81) PY: PathGeneratorPacket method
- 22.214.171.124 (82) SDK: Declarations
- 2.4.4 ILxPathStep Wrapper
- 2.4.5 Particle Generator Packet Interface
- 126.96.36.199 (84) SDK: LXtPGenParticle struct
- 188.8.131.52 (85) SDK: Declarations
- 184.108.40.206 (86) SDK: ILxParticleGeneratorPacket interface
- 220.127.116.11 (87) SDK: ILxParticleGeneratorPacket interface
- 18.104.22.168 (88) SDK: ILxParticleGeneratorPacket interface
- 22.214.171.124 (89) SDK: Declarations
- 126.96.36.199 (90) User Class: ParticleGeneratorPacket method
- 188.8.131.52 (91) PY: ParticleGeneratorPacket method
- 184.108.40.206 (92) SDK: Declarations
- 2.4.6 ILxParticleGeneratorPacket1
- 2.4.7 Preset Content Packet
- 2.4.8 2D Drawing Style Packet
The primary API for all tools, internal and external, must be the COM ILxTool interface, and the other COM interfaces supported by tools. This assures that external tools are not limited in scope or functionality, and can blend seamlessly into the tool workflow.
The basic interface for tools is ILxTool. This has a set of methods that manage the state of the tool, and query the fundamental tool properties.
|The Reset method sets the tool attributes back to their initial/default state.|
|This method applys the tool, recursively applying any hierarchy of sub-tools. Naturally, it validates the tool state upon completion.|
|This method returns the tool vector type, describing the vector packets required for processing.|
|Specifies the order in the pipe, by returning an Ordinal string.|
|Specifies the type of task performed by the tool.|
|This method uses the attribute sequence object given to store the tool's complete state by generating the sequence of attribute changes needed to reproduce that exact state. A tool whose state is expressed entirely by its attributes may return LXe_NOTIMPL from this method, and let the system build the sequence directly from the attribute list.|
(1) SDK: ILxTool interface
LXxMETHOD( void, Reset) ( LXtObjectID self); LXxMETHOD( void, Evaluate) ( LXtObjectID self, LXtObjectID vts); LXxMETHOD( LXtObjectID, VectorType) ( LXtObjectID self); LXxMETHOD( const char *, Order) ( LXtObjectID self); LXxMETHOD( LXtID4, Task) ( LXtObjectID self); LXxMETHOD( LxResult, Sequence) ( LXtObjectID self, LXtObjectID seq);
It is often desirable to perform incremental updates to meshes, rather than simply evaluating a tool from scratch, every time an attribute changes. This is performed using a tool operation. A tool operation is spawned for every mesh the tool is expected to edit, and is used to perform an initial edit to the mesh. When a tool attribute changes, the tool operation is compared against the current state of the tool. If the tool operation is still valid, it will be updated to use the new tool attributes and re-evaluated to perform an incremental update to the previous evaluation.
Tool Operations also are used in a procedural context. When a tool has been auto converted into a procedural tool item, it's tool operation is evaluated as part of the procedural modeling system to perform initial and incremental edits to a procedural mesh.
This set of functions is used to get the tool op, compare it against tool state and update the tool operation if the tool state is still valid.
|The GetOp method is used to spawn a Tool Operation interface that can be used for evaluation and re-evaluation of a mesh edit. The tool is expected to spawn and return a new tool operation every time this function is called. The tool should store any user data in the tool operation before returning. The flags argument is used to pass various flags that specify the context in which the tool is being evaluated; as part of the tool pipe, or procedurally. In future, more flags may be supported.|
(2) SDK: ILxTool interface
(3) SDK: Declarations
|When tool attributes change, a previous tool operation could potentially still be compatible, and could be used to perform incremental updates to a previous evaluation. This function is called to check if a previous tool operation is compatible with the current state of a tool. If it is, then the convert function will be called to update the state of the tool operation, with the latest attributes associated with the tool. The ReEvaluate function on the tool operation will then be called to perform an incremental update to the tool. If the function specifies that the tool operation is incompatible, then the previous result will be discarded, and evaluation will start from scratch with a new tool operation.|
(4) SDK: Declarations
(5) SDK: ILxTool interface
|If the CompareOp function specifies that a previous tool operation is compatible with the current state of the tool, then this function will be called to copy updated attributes and user data from the tool, to the previous tool operation. The tool operation will then be re-evaluated using this updated data.|
(6) SDK: ILxTool interface
If a tool provides an ILxToolOperation interface, using the GetOp functions. Then it should present the following server tag. This will result in the Tool Operation being used to evaluate the tool. If this server tag is not present, then the standard Evaluate function will be used to evaluate the tool. The value of this tag doesn't matter, the presence of it is enough to signal that a tool operation will be spawned to handle evaluation.
(7) SDK: Declarations
#define LXsTOOL_USETOOLOP "tool.useToolOp"
Empty Tool Python user class.
(8) PY: Tool method
The standard task codes are for: snapping tools, action center and axis, weight (falloff) modification tools, constraint tools, path and particle generators, and the main action tools (like primitives, transforms or mesh edits).
(9) SDK: Declarations
#define LXi_TASK_SNAP LXxID4 ('S','N','A','P') #define LXi_TASK_ACEN LXxID4 ('A','C','E','N') #define LXi_TASK_AXIS LXxID4 ('A','X','I','S') #define LXi_TASK_WGHT LXxID4 ('W','G','H','T') #define LXi_TASK_CONS LXxID4 ('C','O','N','S') #define LXi_TASK_ACTR LXxID4 ('A','C','T','R') #define LXi_TASK_SIDE LXxID4 ('S','I','D','E') #define LXi_TASK_PATH LXxID4 ('P','A','T','H') #define LXi_TASK_PTCL LXxID4 ('P','T','C','L') #define LXi_TASK_EFFR LXxID4 ('E','F','F','R') #define LXi_TASK_BRSH LXxID4 ('B','R','S','H') #define LXi_TASK_NOZL LXxID4 ('N','O','Z','L') #define LXi_TASK_PINK LXxID4 ('P','I','N','K') #define LXi_TASK_CONT LXxID4 ('C','O','N','T') #define LXi_TASK_POST LXxID4 ('P','O','S','T') #define LXi_TASK_STYL LXxID4 ('S','T','Y','L') #define LXi_TASK_WORK LXxID4 ('W','O','R','K') #define LXi_TASK_SYMM LXxID4 ('S','Y','M','M')
It's helpful to represent the tool tasks as strings for use in contexts such as procedural modeling.
(10) SDK: Declarations
#define LXs_TASK_SNAP "SNAP" #define LXs_TASK_ACEN "ACEN" #define LXs_TASK_AXIS "AXIS" #define LXs_TASK_WGHT "WGHT" #define LXs_TASK_CONS "CONS" #define LXs_TASK_ACTR "ACTR" #define LXs_TASK_SIDE "SIDE" #define LXs_TASK_PATH "PATH" #define LXs_TASK_PTCL "PTCL" #define LXs_TASK_EFFR "EFFR" #define LXs_TASK_BRSH "BRSH" #define LXs_TASK_NOZL "NOZL" #define LXs_TASK_PINK "PINK" #define LXs_TASK_CONT "CONT" #define LXs_TASK_POST "POST" #define LXs_TASK_STYL "STYL" #define LXs_TASK_WORK "WORK" #define LXs_TASK_SYMM "SYMM"
Default ordinals place these kinds of tools into their canonical order. These shouldn't be changed without good reason since new ones can be inserted indefinitely.
(11) SDK: Declarations
#define LXs_ORD_WORK "\x30" #define LXs_ORD_SYMM "\x31" #define LXs_ORD_CONT "\x38" #define LXs_ORD_STYL "\x39" #define LXs_ORD_SNAP "\x40" #define LXs_ORD_CONS "\x41" #define LXs_ORD_ACEN "\x60" #define LXs_ORD_AXIS "\x70" #define LXs_ORD_PATH "\x80" #define LXs_ORD_WGHT "\x90" #define LXs_ORD_PINK "\xB0" #define LXs_ORD_NOZL "\xB1" #define LXs_ORD_BRSH "\xB2" #define LXs_ORD_PTCL "\xC0" #define LXs_ORD_SIDE "\xD0" #define LXs_ORD_EFFR "\xD8" #define LXs_ORD_ACTR "\xF0" #define LXs_ORD_POST "\xF1"
The ILxTool Interface is accessed via the LXu_TOOL unique ID, or its human-readable alias, LXa_TOOL.
(12) SDK: Declarations
ILxTool1 (Legacy Interface)
This interface was retired in modo 901, and was replaced with an updated one that adds a few more methods.
(13) SDK: ILxTool1 interface
LXxMETHOD( void, Reset) ( LXtObjectID self); LXxMETHOD( void, Evaluate) ( LXtObjectID self, LXtObjectID vts); LXxMETHOD( LXtObjectID, VectorType) ( LXtObjectID self); LXxMETHOD( const char *, Order) ( LXtObjectID self); LXxMETHOD( LXtID4, Task) ( LXtObjectID self); LXxMETHOD( LxResult, Sequence) ( LXtObjectID self, LXtObjectID seq); LXxMETHOD( int, ShouldBeAttribute) ( LXtObjectID self, LXtID4 task);
(14) SDK: Declarations
The ILxAttrSequence interface is intended to complement attribute lists by capturing the sequence of attribute edits required to create a specific state within an object which implements the ILxAttributes interface. An attribute list is a minimal snapshot of an object's exposed data, which may not fully describe the internal state of the object. This would be the case if attribute changes had a cumulative effect on the object (e.g. adding elements to a list). Preserving this state is accomplished by using the ILxAttrSequence interface to 'record' the necessary attribute changes for some host, which can then regenerate the object state by 'playing back' the edits.
|Use this method to record a change to an integer type attribute by specifying the attribute name and the new value.|
|Use this method to record a change to an floating point attribute (a double).|
|Use this method to record a change to an string attribute.|
|Use this method to record a change to an attribute using a generic ILxValue.|
(15) SDK: ILxAttrSequence interface
LXxMETHOD( LxResult, Integer) ( LXtObjectID self, const char *name, int value); LXxMETHOD( LxResult, Float) ( LXtObjectID self, const char *name, double value); LXxMETHOD( LxResult, String) ( LXtObjectID self, const char *name, const char *value); LXxMETHOD( LxResult, Value) ( LXtObjectID self, const char *name, LXtObjectID value);
Empty AttrSequence Python user class.
(16) PY: AttrSequence method
The ILxAttrSequence Interface is accessed via the LXu_ATTRSEQUENCE unique ID.
(17) SDK: Declarations
#define LXu_ATTRSEQUENCE "F54FEF16-223F-439D-8593-6F350783993E"
(18) User Class: AttrSequence method
A Tool Operation is a special interface that allows tools to be incrementally evaluated. The tool spawns and returns a Tool Operation interface. This tool operation interface is then used for evaluation and re-evaluation of the tool.
|Once a tool has spawned a tool operation, this function will be called to perform an initial evaluation.|
(19) SDK: ILxToolOperation interface
|Subsequent evaluations of the tool operation will be performed using the ReEvaluate function. The tool will test the tool operation to see if it is still compatible. If it is, it's state will be updated and then ReEvaluate will be called to perform an incremental update.|
(20) SDK: ILxToolOperation interface
(21) SDK: Declarations
(22) User Class: ToolOperation method
Empty Tool Operation Python user class.
(23) PY: ToolOperation method
The evaluation/execution of the tool pipeline uses a GenVector-like paradigm in which the elements all declare what packets they need to read and alter. The combined result of all these packets is a ToolVector, which is evaluated to operate the tool.
(24) SDK: Declarations
#define LXsCATEGORY_TOOL "tool"
Standard Tool Packets
We define here some of the most standard tool packets.
The subject packet as a mesh, a vmap and the selection type to operate on.
(25) SDK: LXpToolSubject struct
LXtMeshID mesh; LXtMeshMapID vmap; LXtID4 type; LXtMeshID base;
Action Center Packet
The action center will be mostly used by transform tools like scale and rotate. The packet is set by action center tools, like the mouse (Auto) action center tool which converts the 2D position into a 3D position.
(26) SDK: LXpToolActionCenter struct
This packet is set by axis tools, like the Auto-Axis tool which sets the axis using a principal axis chosen by the event translation object. The axis is a unit vector which will often be along a principal axis. In this case, the 'axIndex' will have the index for that axis. Otherwise, axIndex will be -1. The axIndex should be treated as a hint, so a tool setting this packet should assure that a correct axis vector is set even if a principal axis is selected and the index is set. A tool reading this packet should be prepared to use the axis vector, since the index may be set to -1 even though the vector happens to lie along a principal direction. The axis vector is also the 'forward' vector. The 'up' vector is a unit vector perpendicular to the axis, which is nominally in the 'up' direction. The 'right' vector is the last vector to form the basis. The 'm' matrix is the matrix formed by the 3 basis vectors and 'mInv' is its inverse.
(27) SDK: LXpToolAxis struct
Tools may be transformed by other tools. For instance, a construction plane tool will apply the plane's transformation to the following tools in the pipe. The construction plane tool can do that by setting the Xfrm packet matrix and position vector. Tools which set this packet may provide an inverse transform matrix, to save redundant or more difficult inversions downstream.
(28) SDK: LXpToolXfrm struct
LXtVector v; LXtMatrix m; LXtMatrix mInv; int flags; int handedness; unsigned int marks;
The Xfrm packet flags can provide hints to tools about the state of the transform. LXiTVXFMf_OFFSET should be set if the position vector 'v' is non-zero. LXiTVXFMf_MATRIX should be set if the matrix is NOT the identity matrix, as an indication to tools that this transformation is necessary. LXiTVXFMf_INVERSE should be set if there is a valid inverse transform matrix in 'mInv'. Transforms that have no bits from LXiTVXFMf_USEFUL set are identity transformations, and can be skipped.
(29) SDK: Declarations
(30) SDK: Declarations
Object Tool Packets
(31) SDK: Declarations
Falloff Packet Interface
The falloff packet is set by falloff tools. It is a COM object with the ILxToolFalloff interface.
(32) SDK: ILxFalloffPacket interface
(33) SDK: ILxFalloffPacket interface
(34) SDK: Declarations
#define LXu_FALLOFFPACKET "D0F8CF5D-1BB5-4002-810B-0E7EF34B7867"
(35) User Class: FalloffPacket method
Empty FalloffPacket Python user class.
(36) PY: FalloffPacket method
Symmetry Packet Interface
The symmetry packet provides interfaces to tools about the state of the symmetry.
|This function returns the activity of the symmetry.|
|This function fills the axis vector of the symmetry and the offset value, and it returns the axis number (0-2) for XYZ, otherwise 3 for arbitrary axis.|
|This function returns the symmetric vertex for the given vertex. If there is none, null is returned.|
|This function returns the symmetric polygon for the given polygon. If there is none, null is returned.|
|This function returns the symmetric edge for the given edge. If there is none, null is returned.|
|This function takes any position and fills the symmetric position. If the position is on the symmetric plane, it returns zero, otherwise nonzero.|
(37) SDK: ILxSymmetryPacket interface
LXxMETHOD( int, Active) ( LXtObjectID self); LXxMETHOD( int, Axis) ( LXtObjectID self, LXtFVector axvec, float *offset); LXxMETHOD( LXtPointID, Point) ( LXtObjectID self, LXtMeshID mesh, LXtPointID vrx); LXxMETHOD( LXtPolygonID, Polygon) ( LXtObjectID self, LXtMeshID mesh, LXtPolygonID pol); LXxMETHOD( LXtEdgeID, Edge) ( LXtObjectID self, LXtMeshID mesh, LXtEdgeID edge); LXxMETHOD( int, Position) ( LXtObjectID self, const LXtFVector pos, LXtFVector sv); LXxMETHOD( int, BaseSide) ( LXtObjectID self); LXxMETHOD( void, SetBase) ( LXtObjectID self, const LXtFVector pos); LXxMETHOD( int, TestSide) ( LXtObjectID self, const LXtFVector pos, int useBase);
(38) SDK: Declarations
#define LXu_SYMMETRYPACKET "F13F6933-1289-4EFC-9CE1-D5C4F13EE7D8"
(39) User Class: SymmetryPacket method
Empty SymmetryPacket Python user class.
(40) PY: SymmetryPacket method
Subject Packet Interface
The subject packet provides a wrapper around the layer service, allowing a layer scan object to be allocated for accessing geometry.
|This function allocates a layer scan object, which can be used for accessing and enumerating meshes in the scene. The flags passed to the flag argument should be the same as the flags passed to the ScanAllocate function in the Layer Service.|
|This function returns the current selection type.|
(41) SDK: ILxSubject2Packet interface
(42) SDK: ILxSubject2Packet interface
(43) SDK: Declarations
#define LXu_SUBJECT2PACKET "CA342D92-26C8-4A25-AD27-0163AD54730D"
(44) User Class: Subject2Packet method
Empty Subject2Packet Python user class.
(45) PY: Subject2Packet method
Texture Packet Interface
The texture packet is similar to the falloff packet. It does essentially the same thing which is to compute a value given a 3D position/mesh elemement. The difference with the falloff packet is that the texture packet may compute different data types: scalar, color or vectors, unlike the falloff function which only returns scalar values.
(46) SDK: ILxTexturePacket interface
(47) SDK: Declarations
#define LXu_TEXTUREPACKET "851271E5-F4F4-444D-A87A-563B9E1E6EFB"
(48) User Class: TexturePacket method
Empty TexturePacket Python user class.
(49) PY: TexturePacket method
Element Axis Packet Interface
Elements are groups of vertices (or polygons) linked by virtue of their interconnections. The element axis packet has one method to compute the local axis given the mesh and one vertex in the element. For faster updates, the method also precomputes the direct and inverse transformation matrices.
(50) SDK: ILxElementAxisPacket interface
(51) SDK: Declarations
#define LXu_ELEMENTAXISPACKET "292A47BF-3CF5-492D-AAFD-AE761092A782"
(52) User Class: ElementAxisPacket method
Empty ElementAxisPacket Python user class.
(53) PY: ElementAxisPacket method
Element Center Packet Interface
Likewise, the element center packet compute the element center given the mesh and a vertex in the element.
(54) SDK: ILxElementCenterPacket interface
(55) SDK: Declarations
#define LXu_ELEMENTCENTERPACKET "5221C415-073A-4610-BCB6-F820F8D7F6D0"
(56) User Class: ElementCenterPacket method
Empty ElementCenterPacket Python user class.
(57) PY: ElementCenterPacket method
Path and Particle Generator Object Packets
Generators are object packets which produce and manage data expressed by downstream Effector tools. At the moment there are two classes of generators, Path Generators and Particle Generators. Path Generators generally maintain and edit some parametrized 3D trajectory, while Particle Generators produce a list of discrete state-vectors algorithmically. Paths are sets of connected segments forming a continuous curve through 3D space, particles are discrete sets of values located and oriented in 3D space. A particle generator can easily be created by sampling a continuous path, but the converse is not necessarily true, as continuity of tangents is not guaranteed for the path.
Path Generator Packet Interface
A path generator packet delivers access to a continuous path through 3D space defined by a parametric curve. For some paths, the tangents may not be continuous.
The curve implementation is not exposed. Instead the position in 3D along the path at a given parameter value is returned by the "Value" method.
(58) SDK: ILxPathGeneratorPacket interface
|Evaluates curve at parameter value 't' (0 <= t <= 1), putting the results in 'pos'.|
It is often useful to get things like the path length, or the tangent at a given point. Since some implementations can deliver these quantities without doing annoying numerical derivatives (or integrals?), the path packet will handle these calculations internally, and provide simple access.
(59) SDK: ILxPathGeneratorPacket interface
(60) SDK: ILxPathGeneratorPacket interface
(61) SDK: ILxPathGeneratorPacket interface
|Returns the path length from parameter t=0 to the given t (<1).|
|Returns the tangent vector at the given parameter value. For uninitialized or zero-length curves, this function returns an LXe_OUTOFBOUNDS error, making it a useful way for the object to dcelare, and for a client to check if the curve is valid.|
|Returns the source polygon for the path.|
Path Generator: Nodes and their data
Most paths are defined by a series of control points (knots). These knots are characterized by a position, a parameter value on the path, some tangents, and flags which tell, among other things, wether the tangents are continuous. It is expected that all discontinuities in a path are represented by knots.
(62) SDK: LXtPathKnot struct
The flags determine if the tangents are equal or not.
(63) SDK: Declarations
#define LXf_PATHKNOT_BROKEN 1
(64) SDK: ILxPathGeneratorPacket interface
|Returns the number of nodes in the path. It will return 0 for an uninitialized or empty sequence, or a synthetic, continuous path which happens to have no nodes. A synthetic path with discontuities should have the courtesy to mark them with nodes.|
|Fills in the LXtPathKnot for the knot at 'index'.|
|Returns the index of the 'current' knot, or -1 if there is none. This will allow downstream tools to build lists of extra per-knot data, and display/edit the appropriate values in the UI.|
For many applications, a downstream client tool of the path generator will want to attach some data to the each knot. Because the knots are created and destroyed by undoable actions, maintaining that data would be difficult for a client. Adding an optional client-defined bit of encapsulated data (baggage) should help. The interface for this is the ILxBagGenerator which clients will provide to create, copy and release their custom data.
(65) SDK: ILxPathGeneratorPacket interface
|This function sets the optional per-knot data generator. Use it to set the value of the LXtPathKnot clientData element.|
The Bag generator interface is a simple way for clients to attach data to dynamic objects like path nodes. The 'bag' pointer returned by Generate() should be passed to Dispose() when it is no longer needed.
(66) SDK: ILxBagGenerator interface
|This method allocates new client data. For convenience some node-specific data may be passed in to the generator. If the cloneMe pointer is non-NULL, it is assumed to point to suitable client data, and it will be copied into the new bag exactly.|
|This frees the bag and its contents.|
(67) SDK: Declarations
#define LXu_BAGGENERATOR "9A368FAA-7576-42B9-9B6A-C2F8D34612F0"
(68) User Class: BagGenerator method
Empty BagGenerator Python user class.
(69) PY: BagGenerator method
Path Generator: Walking the Path
In many cases, travelling the along path can also be done more efficiently internally. The Path Generator thus provides a method for scanning the entire curve with a client-supplied ILxPathStep.
(70) SDK: ILxPathStep interface
The step function can end the walk at any time by returning a non-zero value.
(71) SDK: ILxPathStep interface
(72) SDK: ILxPathStep interface
(73) SDK: Declarations
#define LXu_PATHSTEP "B9F58563-FBA0-4CA2-866B-1DD64174A277"
(74) User Class: PathStep method
Empty PathStep Python user class.
(75) PY: PathStep method
(76) SDK: ILxPathGeneratorPacket interface
|This function 'walks' along the path, invoking the supplied ILxPathStep's step() at each step with the curve parameter and the 3D position. It returns the number of steps taken, which is determined by the angle argument. The angle (in radians) is the maximum angle allowed between adjacent linear divisions. For convenience, Coarse, Medium, and Fine presets (corresponding to 6, 5, and 3 degrees, respectively) are defined.|
(77) SDK: Declarations
(78) SDK: ILxPathGeneratorPacket interface
|Returns the bank angle at the given parameter value.|
(79) SDK: Declarations
(80) User Class: PathGeneratorPacket method
Empty PathGeneratorPacket Python user class.
(81) PY: PathGeneratorPacket method
(82) SDK: Declarations
#define LXsP_TOOL_PATHGEN "tool.pathGenerator"
For convenience, a basic implementation of the ILxPathStep interface is provided. It will call a client callback at each step. The callback must be in this not unfamiliar form:
(83) SDK: Declarations
typedef void PathWalkerFunc (void *data, double t, LXtVector pos);
Particle Generator Packet Interface
A particle generator object manages an ordered sequence of particles, or transforms, each defined by its own position, rotation and scale. While the scale and orientation could be combined in a single matrix, they will be preserved separately for the convenience of working with orthonormal matrices. A
(84) SDK: LXtPGenParticle struct
|Particle position in space|
|A vector of scaling factors for each of the particle coordinates|
|The particle coordinate system, defined by an orthonormal transformation matrix.|
|The 'connect' flag tells clients that the particle is part of a continuous series by indicating that this particle is connected to the one following it. If this is the last particle, it is this flag means that the particle is connected to the first, closing the sequence. The 'absSize' flag tells clients that the particle size is absolute. In many cases the size is relative, depending on what the effector is dealing with. The 'mirror' flag is a special mode to make mirrored particles based on the scale vectors. "curve" flag is set by curve like generator which requires a duplication at the initial particle position.|
(85) SDK: Declarations
(86) SDK: ILxParticleGeneratorPacket interface
|Returns the number of particles in the sequence. It will return 0 for an uninitialized or empty sequence, or 1 if only the InitialParticleSet method has been used to set initial conditions for the generator.|
|Fills in the LXtPGenParticleID for the particle at 'index'.|
The generator has to be responsive to the requirements of the effector. For example, the sweep effector which is the "bit" for the lathe and extrude tool composites has to be able to provide the generator with a start location. This allows the radial generator to put its first particle at the location of the source data, and have the other particles spiral out from there.
(87) SDK: ILxParticleGeneratorPacket interface
(88) SDK: ILxParticleGeneratorPacket interface
|Set the initial state of the particle generator. The state of particle supplied will be copied and used as the 0th particle.|
|This is an optional method for InitialParticleSet. Set the bounding box and the initial orientation when it defines the initial particle.|
|Set the initial state of the particle generator. The state of particle supplied will be copied and used as the 0th particle. This version will use the supplied mesh instead of scanning global layers.|
(89) SDK: Declarations
(90) User Class: ParticleGeneratorPacket method
Empty ParticleGeneratorPacket Python user class.
(91) PY: ParticleGeneratorPacket method
(92) SDK: Declarations
#define LXsP_TOOL_PARTGEN "tool.partGenerator"
This packet interface has been deprecated and replaced by ILxParticleGeneratorPacket.
(93) SDK: ILxParticleGeneratorPacket1 interface
LXxMETHOD( int, Count) ( LXtObjectID self, LXtObjectID vts); LXxMETHOD( LxResult, Particle) ( LXtObjectID self, LXtObjectID vts, int index, LXtPGenParticle *part); LXxMETHOD( LxResult, InitialParticleSet) ( LXtObjectID self, const LXtPGenParticle *part); LXxMETHOD( LxResult, HintBoxSet) ( LXtObjectID self, const LXtBBox *box, const LXtPGenParticle *part);
(94) SDK: Declarations
Preset Content Packet
The Preset Content Packet holds the name, type and commonly used attributes for content preset files. It should be written to be TASK_CONT type tools, and read-only for tools downstream. The flags are used for boolean attributes, and may be interpreted differently for each type of content.
(95) SDK: LXpToolContent struct
const char *path; const char *type; double scale; LXtVector axis; LXtVector offset; int axIndex; int flags; void *data; /* * Temporary changes to ensure the content browser works correctly when running as a toolop. * We cannot store pointers to strings owned by toolops in the same way we would for non-procedural tools. * because the toolop data is not guaranteed to still exist when the packet is read by the next tool. * We should replace this structure with a COM object as soon as possible. */ char pathBuffer; char typeBuffer;
(96) SDK: Declarations
#define LXsP_TOOL_CONTENT "tool.content"
2D Drawing Style Packet
This packet holds common style attributes for vector composition elements.
(97) SDK: LXpToolStyle struct
(98) SDK: Declarations
#define LXsP_TOOL_STYLE "tool.style"