|
|
RxNodeDefinitionCloneCreate returns a pointer to a node to clone packets and send them down certain branches of a pipeline. This node, for each incoming packet, caches the contents of that packet and sends 'clones' of the packet down several outputs. It can operate in several modes, these being defined in the private data of the node. The private data, for the RxPipelineNode referencing the RxNodeDefinition output by this function, should be set up after the containing RxPipeline has been unlocked by passing RxPipelineNodeCloneDefineModes the same RxNodeCloneInitData struct as is passed to this function. Each mode specifies, in order, the outputs that the cloned packets are sent to. If you run RxPipelineNodeCloneOptimize on the same RxPipelineNode, it will set up some extra private data to optimize its operation such that it only sets cluster flags to EXTERNAL when it absolutely has to. (This is all but the last time a cluster is used in an outgoing packet, see RxPipelineNodeCloneOptimize for further details.) If you don't run RxPipelineNodeCloneOptimize on it, it will be less precise and set cluster flags to EXTERNAL in all but the last clone of each packet (which could result in unnecessary copying of data).
|
|
|
RxNodeDefinitionCloneDestroy destroys a node definition created by RxNodeDefinitionCloneCreate
|
|
|
RxNodeDefinitionGetAtomicEnumerateLights returns a pointer to a node to enumerate lights illuminating an atomic This node works out which lights in the world illuminate the atomic from which each packet was spawned. It then puts pointers to each of these lights in an RxLight cluster (the RxLight struct is just a pointer to an RpLight). Global lights flagged as lighting atomics will affect all atomics. Local lights flagged as lighting atomics can only affect atomics if they are in (that is their region of influence overlaps with) at least one of the world sectors which the atomic is in (those whose bounding box overlap the atomic's bounding sphere). The node has one output, through which the packets pass with their new RxLight cluster. The input requirements of this node:
|
|
|
RxNodeDefinitionGetAtomicInstance returns a pointer to a node to instance an atomic RpGeometrys are split into RpMeshes when RpGeometryUnlock is called. There should be one mesh per material used in the geometry. It is a requirement of the new flexible pipeline scheme that packets of geometry be entirely self-contained and this has the following ramifications: vertices at material boundaries within an RpGeometry must be duplicated and vertices in the geometry's vertex array must be sorted on material, so that the runs of vertices for each material are contiguous and mutually disjoint. This arrangement of geometries is currently guaranteed by all RW exporters as well as RpGeometryStreamWrite. If you procedurally generate geometry in your application and have more than one material assigned to that geometry, be careful that you comply with the above requirements. If possible, generate the geometry once, save it to disk and load it up at the beginning of the app rather than re-generating it every time the app is run. The node will instance the geometry into a RwResEntry (a block of memory in the resources arena) so that hopefully it can be cached in this ready-to-render format and reused for several frames. This RwResEntry will be big enough to hold all the object-space vertices and triangles for all the meshes in the geometry. When parts of the geometry's data change, these will need to be reinstanced. Sometimes this involves modifying only vertex data (say vertex colors or texture coords) but sometimes it involves reinstancing triangles or the entire RwResEntry. If the geometry has more than one RpMorphTarget then vertex positions and normals will need to be reinstanced every frame the animation progresses - interpolation between RpMorphTargets is performed here. Depending on the flags of the RpGeometry, an appropriate size of object-space vertex is chosen. If the geometry is not textured, a smaller vertex can be used (we basically truncate the vertex since we have put UVs at the end). If it also has no normals (is not lit) then an even smaller vertex can be used. The size of the appropriate vertex is used as the stride of the object-space vertex cluster. If the geometry is pre-lit, we copy pre-lighting values into the object-space vertices, otherwise we initialize them to {0, 0, 0, 255}. If the geometry is textured, we copy in RxUVs. If the geometry has normals (is lit), we copy in normals. Indices are currently created as triangle lists even if the geometry was originally formed of triangle strips. When we have a comprehensive set of nodes that can handle triangle-strip-indexed geometry, this will change. The object-space vertex cluster and indices cluster of each packet references the vertex/index data in the RwResEntry and hence these clusters are marked as rxCLFLAGS_EXTERNAL. The mesh state cluster is created on the RxHeap for each packet, and its initialized with a pointer to the RpMaterial of the packet's associated mesh in the SourceObject entry, the material's color in MatCol, its texture (if any) in Texture and a pointer to its material pipeline in Pipeline. The primitive type is currently set to triangle list as mentioned above. The Obj2Cam and Obj2World matrices are initialized from the atomic's frame and the current camera's frame. The surface properties are set from those of the geometry and the flags of the geometry are also copied in to the mesh state. The NumVertices and NumElements (number of triangles) values are set to the appropriate value for this mesh and the CliFlagsAnd and ClipFlagsOr values are both initialized to zero. The render state cluster is initialized to the default render state and then the texture settings are overridden if the mesh's material has a texture. If the material's alpha value is not 255 then vertex alpha is enabled in the render state's flags. The node has one output, through which the instanced geometry passes. The input requirements of this node:
|
|
|
RxNodeDefinitionGetClipLine returns a pointer to a node implementing line clipping in custom pipelines. This node clips lines to the frustum of the current camera (as defined by the camera's ViewWindow, ViewOffset and Projection type - parallel or perspective). This node is meant to be used after a transform node, so that the camera space and (un-clipped) screen space vertices will contain valid data. It clips all values associated with the lines/vertices (that is, position, texture coordinates and RGBA values) in 3D camera space so that the results of perspective-correct interpolation by the rasterizer will be correct. Generally, any values you want clipping need to be in the camera-space vertices before this node, with the exception of color which needs to be in the screen-space vertices. This means that if lighting is performed, the lighting nodes should come before this node, because they set up the post-lighting color in the screen-space vertices. Any new vertices generated during clipping are projected (so that both camera-space and screen-space positions and texture coordinates are correct) and added to the ends of the vertex arrays, and the mesh state cluster's NumVertices and NumElements members are updated as appropriate. If the render state cluster is not present (or contains no data) then the node assumes that the packet's render state is the default render state, obtained through RxRenderStateVectorGetDefaultRenderStateVector(). This is used in this case to determine if lines are to be Gouraud shaded (hence color should be interpolated when lines are clipped) or flat shaded. If all the lines in a packet are completely clipped away (they all lie entirely offscreen) then the packet is sent to the node's second output (which is usually left disconnected, resulting in the packet's destruction. In some cases, however, it may be desirable to connect this output to subsequent nodes if the geometry's extent is known to be modified further down the pipeline if, for example, vertex normals are added, to be rendered as lines), but otherwise packets are sent to the node's first output. The node has two outputs. Packets in which all triangles are clipped away are sent to the second output. The input requirements of this node: RxClCamSpace3DVertices - required RxClScrSpace2DVertices - required RxClIndices - required RxClMeshState - required RxClRenderState - optional The characteristics of the first of this node's outputs: RxClCamSpace3DVertices - valid RxClScrSpace2DVertices - valid RxClIndices - valid RxClMeshState - valid RxClRenderState - no change The characteristics of the second of this node's outputs: RxClCamSpace3DVertices - valid RxClScrSpace2DVertices - valid RxClIndices - invalid RxClMeshState - valid RxClRenderState - no change
|
|
|
RxNodeDefinitionGetClipTriangle returns a pointer to a node implementing triangle clipping in custom pipelines This node clips triangles to the frustum of the current camera (as defined by the camera's ViewWindow, ViewOffset and Projection type - parallel or perspective). This node is meant to be used after a transform node, so that the camera space and (un-clipped) screen space vertices will contain valid data. It clips all values associated with the triangles/vertices (that is, position, texture coordinates and RGBA values) in 3D camera space so that the results of perspective-correct interpolation by the rasteriser will be correct. Generally, any values you want clipping need to be in the camera-space vertices before this node, with the exception of color which needs to be in the screen-space vertices. This means that if lighting is performed, the lighting nodes should come before this node, because they set up the post-lighting color in the screen-space vertices. Any new vertices generated during clipping are projected (so that both camera-space and screen-space positions and texture coordinates are correct) and added to the ends of the vertex arrays, and the mesh state cluster's NumVertices and NumElements members are updated as appropriate. The interpolants cluster which is output is used to accelerate multipass rendering. If the triangles being rendered are to be submitted more than once, with different UV coordinates (or RGBA values and possibly a different texture) after the first time, then it is not necessary to clip the triangles a second time. The interpolant values can be used to interpolate UV values (or RGBAs) for clipped triangles. UVInterp.csl uses this cluster, see that for further details. If the render state cluster is not present (or contains no data) then the node assumes that the packet's render state is the default render state, obtained through RxRenderStateVectorGetDefaultRenderStateVector(). This is used in this case to determine if triangles are to be gouraud shaded (hence color should be interpolated when triangles are clipped) or flat shaded. If all the triangles in a packet are completely clipped away (they all lie entirely offscreen) then the packet is sent to the node's second output (which is usually left disconnected, resulting in the packet's destruction. In some cases, however, it may be desirable to connect this output to subsequent nodes if the geometry's extent is known to be modified further down the pipeline if, for example, vertex normals are added, to be rendered as lines), but otherwise packets are sent to the node's first output. The node has two outputs. Packets in which all triangles are clipped away are sent to the second output. The input requirements of this node: RxClCamSpace3DVertices - required RxClScrSpace2DVertices - required RxClIndices - required RxClMeshState - required RxClRenderState - optional RxClInterpolants - don't want The characteristics of the first of this node's output's: RxClCamSpace3DVertices - valid RxClScrSpace2DVertices - valid RxClIndices - valid RxClMeshState - valid RxClRenderState - no change RxClInterpolants - valid The characteristics of the second of this node's output's: RxClCamSpace3DVertices - valid RxClScrSpace2DVertices - valid RxClIndices - invalid RxClMeshState - valid RxClRenderState - no change RxClInterpolants - invalid
|
|
|
RxNodeDefinitionGetCullTriangle returns a pointer to a node implementing triangle culling in custom pipelines. This node removes triangles from the indices cluster if they are back-facing with respect to the current camera. This node is assumed to be used after a transform node, so that the screen-space and camera-space vertex clusters have been filled with valid data and the clip flags of the camera-space vertices have been set. For triangles wholly onscreen (the clip flags are used to determine when this is the case), or parallel-projected, 2D back-face culling is performed, otherwise 3D culling is performed (the former is faster). Triangles wholly offscreen are also deleted - this case is detected conservatively if the bitwise AND of the clipflags of all three vertices of a triangle is non-zero (it means that all three vertices lie beyond the same one or more planes of the frustum). Triangles found to be culled are deleted from the triangles cluster (the way this is done changes the order of the triangles, which is assumed to be unimportant). If all the triangles in a packet are culled then the packet is sent to the node's second output (which is usually left disconnected, resulting in the packet's destruction. In some cases, however, it may be desirable to connect this output to subsequent nodes if the geometry's extent is known to be modified further down the pipeline if, for example, vertex normals are added, to be rendered as lines), but otherwise packets are sent to the node's first output. The node has two outputs. Packets in which all triangles are culled are sent to the second output. The input requirements of this node: RxClCamSpace3DVertices - required RxClScrSpace2DVertices - required RxClIndices - required RxClMeshState - required The characteristics of the first of this node's outputs: RxClCamSpace3DVertices - no change RxClScrSpace2DVertices - no change RxClIndices - valid RxClMeshState - valid The characteristics of the second of this node's outputs: RxClCamSpace3DVertices - no change RxClScrSpace2DVertices - no change RxClIndices - invalid RxClMeshState - valid
|
|
|
RxNodeDefinitionGetFastPathSplitter returns a pointer to a node to route packets down a fast path in the current pipeline, where the current RpWorldSector's bounding box lies fully within the view frustum and hence need not be processed by a clipping node. The node has two outputs. Packets are sent through the second output if all vertices lie within the view frustum and hence the clipping stage of the pipeline can be skipped. The input requirements of this node:
|
|
|
RxNodeDefinitionGetImmInstance returns a pointer to a node to initialize a packet with vertices passed in to RwIm3DTransform This node creates and initializes a packet such that its RxObjSpace3DVertex cluster points to the vertices passed in to RwIm3DTransform. It also sets up an appropriate mesh state cluster. The object-space vertices are obtained through the (void *)data pointer of the node. RwIm3DTransform passes in a pointer to a rwIm3DPool struct through this parameter. This struct contains the number of elements (vertices), a pointer to the vertex array, the stride of said array, the object-to-world transformation matrix of the vertices (if they have one) and flags determining whether UV values need be present in the vertices. The node has one output, through which initialized packets pass The input requirements of this node: RxClObjSpace3DVertices - don't want RxClMeshState - don't want RxClRenderState - don't want The characteristics of this node's first output: RxClObjSpace3DVertices - valid RxClMeshState - valid RxClRenderState - valid
|
|
|
RxNodeDefinitionGetImmMangleLineIndices returns a pointer to a node to convert indices into the format required for RwIm3D line render pipelines, on the basis of primitive type. This node converts a cluster of RwImVertexIndexes into a cluster appropriate for the packet's primitive type. It currently expands indices for polylines into line list indices and changes the primitive type to line list. It also generates indices if none are passed in. When there is a comprehensive set of nodes available to deal with unindexed geometry or geometry indexed in polyline order then this will be changed. This node is the second node in the default generic RenderWare RwIm3D line render pipelines. The node has one output. The input requirements of this node: RxClMeshState - required RxClIndices - optional The characteristics of this node's first output: RxClMeshState - valid RxClIndices - valid
|
|
|
RxNodeDefinitionGetImmMangleTriangleIndices returns a pointer to a node to convert indices into the format required for RwIm3D triangle render pipelines, on the basis of primitive type. This node converts a cluster of RwImVertexIndexs into a cluster appropriate for the packet's primitive type. It currently expands indices for triangle strips and fans into triangle list indices and changes the primitive type to triangle list. It also generates indices if none are passed in. When there is a comprehensive set of nodes available to deal with unindexed geometry or geometry indexed in triangle strip or triangle fan order then this will be changed (clipping and culling triangle strips and fans is quite difficult, hence these nodes are not yet available). This node is the second node in the default generic RenderWare RwIm3D triangle render pipelines. The node has one output. The input requirements of this node: RxClMeshState - required RxClIndices - optional The characteristics of this node's first output: RxClMeshState - valid RxClIndices - valid
|
|
|
RxNodeDefinitionGetImmRenderSetup returns a pointer to a node to set up packets in an Im3D render pipeline. This node sets the primitive type of packet (in its mesh state cluster), adds indices to the packet (those passed in to the RwIm3D render function, if any), sets the render state cluster to that set up by the prior RwIm3D transform pipeline or to the current driver state if none was set previously. This is first node of the default generic Im3D render pipeline. It expects to receive a pointer to an _rwIm3DPoolStash struct through its (void *)data parameter. This contains the primitive type, rwIM3D flags, an (optional) RwMatrix, the number of indices and vertices, pointers to indices, object-space vertices, optionally (not on platforms utilising hardware transformation) camera-space and screen-space vertices, an RxMeshStateVector and optionally an RxRenderStateVector. This node has two outputs. Packets with indices pass through the first output and packets without indices pass through the second output. The input requirements of this node: RxClObjSpace3DVertices - don't want RxClCamSpace3DVertices - don't want RxClScrSpace2DVertices - don't want RxClMeshState - don't want RxClRenderState - don't want RxClIndices - don't want The characteristics of this node's first output: RxClObjSpace3DVertices - valid RxClCamSpace3DVertices - valid RxClScrSpace2DVertices - valid RxClMeshState - valid RxClRenderState - valid RxClIndices - valid The characteristics of this node's second output: RxClObjSpace3DVertices - valid RxClCamSpace3DVertices - valid RxClScrSpace2DVertices - valid RxClMeshState - valid RxClRenderState - valid RxClIndices - invalid
|
|
|
RxNodeDefinitionGetImmStash returns a pointer to a node to store the results of the current Im3D transform pipeline for use in Im3D render pipelines. The contents of the incoming packet (all the clusters listed below) are 'stashed' in global state such that packets can be reconstructed in subsequent Im3D render pipelines by the RxNodeDefinitionGetImmRenderSetup node. This state is a _rwIm3DPoolStash struct which contains the primitive type, rwIM3D flags, an (optional) RwMatrix, the number of indices and vertices, pointers to indices, object-space vertices, optionally (not on platforms utilising hardware transformation) camera-space and screen-space vertices, an RxMeshStateVector and optionally an RxRenderStateVector. This node has no outputs. Incoming packets are destroyed after their contents have been stashed. The input requirements of this node: RxClObjSpace3DVertices - optional RxClCamSpace3DVertices - optional RxClScrSpace2DVertices - optional RxClMeshState - optional RxClRenderState - optional
|
|
|
RxNodeDefinitionGetLight returns a pointer to a node which lights geometry with any relevant (i.e nearby) RpLights in the world, accumulating lighting values in the camera-space vertices. For every light in the RxLights array (the RxLight struct merely holds a pointer to an RpLight), the appropriate lighting function (ambient, point, etc.) is applied for all vertices in the packet. If either the mesh state's ClipFlagsAnd is non-zero or there are no lights in the RxLight cluster, then the packet is passed on unmodified. Lights are transformed into object-space so that lighting can be performed as efficiently as possible (vertex normals need not be transformed). This node accepts an optional RxVStep cluster. This cluster may have been generated by a prior node, such as a back-face culling node. If present, this cluster is used to skip vertices which belong only to back-face culled triangles (per-vertex operations like lighting and transformation are wasted on such vertices). See RxVStep for details of the use of the RxVStep struct. The node has one output, through which the lit vertices pass. The input requirements of this node:
|
|
|
RxNodeDefinitionGetMaterialScatter returns a pointer to a node to distribute packets to material pipelines on the basis of the pipeline pointer in their MeshState cluster. This node requires as optional many standard clusters such that, if they are present in the pipeline, they will propagate from this pipeline to the material pipeline. For any other clusters which you want to propagate to the end of an object pipeline and then to material pipelines, use RxPipelineNodeRequestCluster during pipeline construction (before unlocking the pipeline) to change the requirements of the terminal MaterialScatter.csl RxPipelineNode. If the mesh state of a packet has its material pipeline pointer set to NULL then the packet will be sent to the default material pipeline, which is accessible through RxMaterialGetDefaultPipeline. The node has no outputs, all packets pass from it to other pipelines. The input requirements of this node:
|
|
|
RxNodeDefinitionGetPostLight returns a pointer to a node to apply post-lighting calculations to geometry This node first of all clamps color values in the camera-space vertices to the range [0,255] and then copies these values into the screen-space vertices. If the material color of the geometry is not {255, 255, 255, 255} then the lighting value for each vertex is multiplied by the material color (normalized by 1/255) before the clamping and copying is performed. Note that the camera-space vertices contain a RwRGBAReal struct for the accumulation of light values and that unlike elsewhere in RW, the values in this struct are meant to be in the range [0,255] and not [0,1]. This node accepts an optional RxVStep cluster. This cluster may have been generated by a prior node, such as a back-face culling node. If present, this cluster is used to skip vertices which belong only to back-face culled triangles (per-vertex operations like lighting and transformation are wasted on such vertices). See RxVStep for details of the use of the RxVStep struct. The node has one output, through which the post-lit vertices pass. The input requirements of this node:
|
|
|
RxNodeDefinitionGetPreLight returns a pointer to a node to apply pre-lighting calculations to geometry. This node initializes the light-accumulation value in camera-space vertices prior to lighting. The node copies the pre-light color values from the object-space vertices to the camera-space vertices. If the geometry is not 'pre-lit' then it is assumed that these values will have been set to {0, 0, 0, 255}, for all object-space vertices, by the instancing node. Otherwise, pre-lighting values should have been copied from the RpGeometry or RpWorldSector into the object-space vertices by the instancing node. This node accepts an optional RxVStep cluster. This cluster may have been generated by a prior node, such as a back-face culling node. If present, this cluster is used to skip vertices which belong only to back-face culled triangles (per-vertex operations like lighting and transformation are wasted on such vertices). See RxVStep for details of the use of the RxVStep struct. The node has one output, through which the pre-lit vertices pass. The input requirements of this node:
|
|
|
RxNodeDefinitionGetRGBAInterp returns a pointer to a node to fill screen-space vertices with a new set of correctly clipped colors. This node takes an RxCluster holding RwRGBAReal's, which is assumed to be parallel to the packet's screen-space vertices as they were PRIOR to clipping, clips them as if they had been in the vertices during clipping and then overwrites the colors of the screen-space vertices with the resulting values. This node can optionally make use of an RxCluster holding RxInterp values in order to perform its task. This contains information generated by the clipper which allows the node to interpolate subsequent sets of colors. For every vertex generated by the clipper, there is an associated RxInterp value which holds the index of that vertex in the vertex array (hence this process is sensitive to changes in the order of the vertices inbetween clipping and interpolation), its two 'parent' vertices (it was generated by clipping the edge between these two vertices) and the interpolation value (where it is on the original edge between its parent vertices - if it is zero, it is at the first parent vertex, if it is one it is at the other end and values inbetween zero and one are inbetween, linearly distributed). This process will cause the number of elements in the RwRGBAReal cluster to increase by the number of vertices generated by clipping. If this node does not receive any RxInterp values then it will simply copy the color values straight into the screen-space vertices (this case occurs when none of the triangles in the current mesh have been clipped). When the packet is output from this node, after interpolation, the RwRGBAReal cluster's values will be valid (i.e in synch with the post- clipping screen-space vertex cluster that they have been copied into) and so are safe to inspect or reuse further down the pipeline. Note that the colors of offscreen screen-space vertices were never valid and still aren't. This node has a private data struct. This contains a boolean 'rgbaInterpOn' which if set to FALSE will cause the node to effectively be skipped - it will just pass packets on to its second output and do nothing else. This second output will not invalidate the RwRGBAReal or RxInterp clusters, because there may be subsequent nodes (e.g a UV interpolation node as returned by RxNodeDefinitionGetUVInterp) that need them. The private data struct also contains an RxRenderStateVector which is used to overwrite the packet's renderstate, so that the renderstate of each submitted pass of triangles can be set to whatever the user desires (usually in terms of texture and blending modes). The node's second output will also be used if the RwRGBAReal cluster is missing or empty (this may occur if, say, no lights are currently impinging on the object being rendered). RxPipelineNodeReplaceCluster may be used to make this node interpolate any one of many RwRGBAReal clusters, such that multiple instances of this node within a single pipeline can enable you to render objects with more than two textured passes. The node has two outputs. The second output will be used if the rgbaInterpOn RwBool in the node's private data is set to FALSE, or if the RwRGBAReal cluster is missing or empty. The input requirements of this node: RxClScrSpace2DVertices - required RxClRenderState - don't want RxClInterpolants - optional RxClRGBAs - optional The characteristics of this node's first output: RxClScrSpace2DVertices - valid RxClRenderState - valid RxClInterpolants - no change RxClRGBAs - valid The characteristics of this node's second output: RxClScrSpace2DVertices - no change RxClRenderState - no change RxClInterpolants - no change RxClRGBAs - no change This node has a private data struct of the following form:
struct RxNodeRGBAInterpSettings
{
RwBool rgbaInterpOn;
RxRenderStateVector state;
};
The RxInterp struct has the following form:
struct RxInterp
{
RxVertexIndex originalVert;
RxVertexIndex parentVert1, parentVert2;
RwReal interp;
}
|
|
|
RxNodeDefinitionGetScatter returns a pointer to a node to multiplex data down certain branches of a pipeline or to other pipelines. This node scatters packets down certain branches of a pipeline, based either on data in each packet's (optional) RxScatter cluster, or on this node's private data (itself an RxScatter struct). The node's private data, if set, will override the data in an RxScatter cluster in packets. If packets do not contain an RxScatter cluster and the node's private data is not set, the packets are by default passed on to the node's first output. The RxScatter cluster contains a pipeline pointer (NULL meaning not set) and a pointer to a pipeline node (within the current pipeline, NULL meaning not set). These should never both be set at the same time. The node has 32 outputs (the maximum allowed) to facilitate extreme branching of the pipeline. None need actually be connected. The input requirements of this node: RxClScatter - optional The characteristics of all this node's outputs: RxClScatter - no change
|
|
|
RxNodeDefinitionGetSubmitLine returns a pointer to a node to submit lines to the rasterizer. This node submits lines to the rasterizer (it submits 2D lines defined by RxScrSpace2DVertex'es and RxIndicess, through the RwIm2D interface). The node as it is currently only supports submission of line lists (indexed or unindexed). Currently, polylines are assumed to be expanded into line lists earlier in the pipeline (this occurs in the Im3D node ImmManglelineIndices.csl). Direct support for polylines will be added later. If the render state cluster is not present (or contains no data) then the node assumes that the packet's render state is the default render state, obtained through RxRenderStateVectorGetDefaultRenderStateVector. This is used in this case to set render states prior to rasterization. The node has a single output and packets pass unchanged through this. The purpose of this is to allow packets to be modified and submitted again later on in the pipeline to perform multipass rendering. The node has a single output, through which packets pass unchanged. The input requirements of this node: RxClScrSpace2DVertices - required RxClIndices - optional RxClMeshState - required RxClRenderState - optional The characteristics of this node's first output: RxClScrSpace2DVertices - no change RxClIndices - no change RxClMeshState - no change RxClRenderState - no change
|
|
|
RxNodeDefinitionGetSubmitTriangle returns a pointer to a node to submit triangles to the rasteriser This node submits triangles to the rasteriser (it submits 2D triangles defined by RxScrSpace2DVertexes and RxTriangles, through the RwIm2D interface). The node as it is currently only supports submission of triangle lists (indexed or unindexed). Currently, triangle strips and fans are assumed to be expanded into triangle lists earlier in the pipeline (this occurs in the standard atomic and world sector instancing nodes and also in the Im3D node ImmMangleTriangleIndices.csl). Direct support for triangle strips (and possibly fans) will be added later. If the Triangles cluster is not present or contains no data then the vertices will be submitted as if they form an unindexed triangle list. This is the most efficient way to render a sequence of unconnected triangles - which, for example, is usually the case with particle systems. If the render state cluster is not present (or contains no data) then the node assumes that the packet's render state is the default render state, obtained through RxRenderStateVectorGetDefaultRenderStateVector(). This is used in this case to set render states prior to rasterisation. The node has a single output and packets pass unchanged through this. The purpose of this is to allow packets to be modified and submitted again later on in the pipeline to perform multipass rendering. The node has a single output, through which packets pass unchanged. The input requirements of this node: RxClScrSpace2DVertices - required RxClIndices - optional RxClMeshState - required RxClRenderState - optional The characteristics of this node's first output: RxClScrSpace2DVertices - no change RxClIndices - no change RxClMeshState - no change RxClRenderState - no change
|
|
|
RxNodeDefinitionGetTransform returns a pointer to a node to transform vertices into camera space. This takes object-space vertices and transforms them into camera space, generating camera-space and screen-space vertices. It performs clipping and projection in accordance with the current camera's view frustum (as defined by the camera's ViewWindow, ViewOffset and Projection type - parallel or perspective). The object vertices are transformed into camera space by the Obj2Cam matrix which should have been set up in the mesh state cluster by an instancing node (this is done by the standard Im3D in the Im3D transform pipeline and the atomic and world sector instancing nodes in the atomic and world sector object pipelines). This node sets color values in the camera-space vertices to zero if the incoming vertices are not prelit or to the prelighting color of each vertex if they are. This means lighting can be perfomed after this node without needing to use PreLight.csl (which is included because some platform-specific transform nodes don't do this color initialization and so that developers can use PreLight.csl as a independent unit). The screen-space vertices also have their color initialized to the prelighting color if present, the vertex color if present or, if neither are present, the material color. This means that if no lighting is performed (i.e Light.csl and PostLight.csl are omitted, for example with Im3D vertices during Im3D rendering or with atomic/world-sector geometry which is not lit) the screen-space vertices will still end up with valid and sensible colors. After transformation, all generated camera vertices are tested to detect if they lie outside of any or all of the current camera's clipping (frustum) planes. The clip flags of the camera vertices are updated accordingly. Camera-space vertices are only projected to generate valid screen-space vertices if they are not clipped (screen-space vertices are allocated space in their cluster and their color is filled in regardless). The clip flags of all camera-space vertices are OR'd together to generate a ClipFlagsOr value which is stored in the mesh state cluster. Similarly a ClipFlagsAnd value is generated and stored by ANDing all the clipflags together. These two values are useful in determining the bulk clipping properties of the packet's vertices. For example, if ClipFlagsAnd is non-zero, then all of the vertices have been clipped by the same one (or more) frustum plane(s). If ClipFlagsOr is zero then all of the vertices are onscreen. If ClipFlagsAnd is non-zero then all the vertices are clipped by one (or more) frustum planes, so the geometry is entirely offscreen. In this case, the packet is sent to the node's second output (which is usually left disconnected, resulting in the packet's destruction. In some cases, however, it may be desirable to connect this output to subsequent nodes if the geometry's extent is known to be modified further down the pipeline if, for example, vertex normals are added, to be rendered as lines), but otherwise packets are sent to the node's first output. Note that all triangles or lines represented by the geometry may still be offscreen even if ClipFlagsAnd is zero (some vertices may be culled by one frustum plane and some others by another). The node has two outputs. The input requirements of this node: RxClObjSpace3DVertices - required RxClCamSpace3DVertices - don't want RxClScrSpace2DVertices - don't want RxClMeshState - required The characteristics of this node's first output: RxClObjSpace3DVertices - no change RxClCamSpace3DVertices - valid RxClScrSpace2DVertices - valid RxClMeshState - valid The characteristics of this node's second output: RxClObjSpace3DVertices - no change RxClCamSpace3DVertices - valid RxClScrSpace2DVertices - valid RxClMeshState - valid
|
|
|
RxNodeDefinitionGetUVInterp returns a pointer to a node to fill screen-space vertices with a new set of correctly clipped texture coordinates. This node takes an RxCluster holding RxUV's, which is assumed to be parallel to the packet's screen-space vertices as they were PRIOR to clipping, clips them as if they had been in the vertices during clipping and then overwrites the UVs of the screen-space vertices with the resulting values. This node can optionally make use of an RxCluster holding RxInterp values in order to perform its task. This contains information generated by the clipper which allows the node to interpolate subsequent sets of texture coordinates. For every vertex generated by the clipper, there is an associated RxInterp value which holds the index of that vertex in the vertex array (hence this process is sensitive to changes in the order of the vertices inbetween clipping and interpolation), its two 'parent' vertices (it was generated by clipping the edge between these two vertices) and the interpolation value (where it is on the original edge between its parent vertices - if it is zero, it is at the first parent vertex, if it is one it is at the other end and values inbetween zero and one are inbetween, linearly distributed). This process will cause the number of elements in the RxUV cluster to increase by the number of vertices generated by clipping. If this node does not receive any RxInterp values then it will simply copy the texture coordinates straight into the screen-space vertices (this case occurs when none of the triangles in the current mesh have been clipped). When the packet is output from this node, after interpolation, the RxUV cluster's values will be valid (i.e in synch with the post- clipping screen-space vertex cluster that they have been copied into) and so are safe to inspect or reuse further down the pipeline. Note that the texture coordinates of offscreen screen-space vertices were never valid and still aren't. This node has a private data struct. This contains a boolean 'uvInterpOn' which if set to FALSE will cause the node to effectively be skipped - it will just pass packets on to its second output and do nothing else. This second output will not invalidate the RxUV or RxInterp clusters, because there may be subsequent nodes (e.g an RGBA interpolation node as returned by RxNodeDefinitionGetRGBAInterp) that need them. The private data struct also contains an RxRenderStateVector which is used to overwrite the packet's renderstate, so that the renderstate of each submitted pass of triangles can be set to whatever the user desires (usually in terms of texture and blending modes). RxPipelineNodeReplaceCluster may be used to make this node interpolate any one of many RxUV clusters, such that multiple instances of this node within a single pipeline can enable you to render objects with more than two textured passes. The node has two outputs. Packets are sent unmodified to the second output if the 'uvInterpOn' RwBool in the node's private data is set to FALSE. The input requirements of this node: RxClScrSpace2DVertices - required RxClRenderState - required RxClInterpolants - optional RxClUVs - required The characteristics of this node's first output: RxClScrSpace2DVertices - valid RxClRenderState - valid RxClInterpolants - no change RxClUVs - valid The characteristics of this node's second output: RxClScrSpace2DVertices - no change RxClRenderState - no change RxClInterpolants - no change RxClUVs - no change This node has a private data struct of the following form:
struct RxNodeUVInterpSettings
{
RwBool uvInterpOn;
RxRenderStateVector state;
};
struct RxInterp
{
RxVertexIndex originalVert;
RxVertexIndex parentVert1, parentVert2;
RwReal interp;
}
|
|
|
RxNodeDefinitionGetWorldSectorEnumerateLights returns a pointer to a node to enumerate the lights illuminating a world sector This node works out which lights in the world illuminate the world sector from which each packet was spawned. It then puts pointers to each of these lights in an RxLight cluster (the RxLight struct is just a pointer to an RpLight). Global lights flagged as lighting world sectors will affect all world sectors. Local lights flagged as lighting world sectors can only affect a world sector if they are in (that is their region of influence overlaps with) that world sector. The node has one output, through which the packets pass with their new RxLight cluster. The input requirements of this node:
|
|
|
RxNodeDefinitionGetWorldSectorInstance returns a pointer to a node to instance a world sector RpWorldSectors are split into RpMeshes when created by an exporter. There should be one mesh per material used in the world sector. It is a requirement of the new flexible pipeline scheme that packets of geometry be entirely self-contained and this has the following ramifications: vertices at material boundaries within an RpWorldSector must be duplicated and vertices in the world sector's vertex array must be sorted on material, so that the runs of vertices for each material are contiguous and mutually disjoint. This arrangement of world sectors is currently guaranteed by all RW exporters. The node will instance the world sector into a RwResEntry (a block of memory in the resources arena) so that hopefully it can be cached in this ready-to-render format and reused for several frames. This RwResEntry will be big enough to hold all the object-space vertices and triangles for all the meshes in the world-sector. When parts of the world-sector's data change, the entire world sector is reinstanced. Depending on the flags of the RpWorld which is the parent of the world sector, an appropriate size of object-space vertex is chosen. If the world sector is not textured, a smaller vertex can be used (we basically truncate the vertex since we have put UVs at the end). If it also has no normals (is not lit) then an even smaller vertex can be used. The size of the appropriate vertex is used as the stride of the object-space vertex cluster. If the world-sector is pre-lit, we copy pre-lighting values into the object-space vertices, otherwise we initialize them to {0, 0, 0, 255}. If the geometry is textured, we copy in RxUVs. If the geometry has normals (is lit), we copy in normals. Indices are currently created as triangle lists even if the world sector was originally formed of triangle strips. When we have a comprehensive set of nodes that can handle triangle-strip-indexed geometry, this will change. The object-space vertex cluster and triangles cluster of each packet references the vertex/triangle data in the RwResEntry and hence these clusters are marked as rxCLFLAGS_EXTERNAL. The mesh state cluster is created on the RxHeap for each packet, and its initialized with a pointer to the RpMaterial of the packet's associated mesh in the SourceObject entry, the material's color in MatCol, its texture (if any) in Texture and a pointer to its material pipeline in Pipeline. The primitive type is currently set to triangle list as mentioned above. The Obj2Cam matrix is initialized from the current camera's frame and the Obj2World matrix is set to the identity. The surface properties are set from those of the owning RpWorld and the flags of the world are also copied in to the mesh state. The NumVertices and NumElements (number of triangles) values are set to the appropriate value for this mesh and the CliFlagsAnd and ClipFlagsOr values are both initialized to zero. The render state cluster is initialized to the default render state and then the texture settings are overridden if the mesh's material has a texture. If the material's alpha value is not 255 then vertex alpha is enabled in the render state's flags. The node has one output, through which the instanced geometry passes. The input requirements of this node:
|
|
||||||||||||||||
|
RxPacketCacheClone creates a new RxPacket from an RxPacketCache. After you have create an RxPacketCache using RxPacketCacheCreate, you can use this function to create RxPacket clones of your original packet. The last clone that you create from an RxPacketCache should be treated differently, so pass in TRUE for the lastClone parameter. For all clusters in the original packet that were active and had data when the cache was created, it is necessary for them to have their cluster data flagged as rxCLFLAGS_EXTERNAL in the cases of the original packet and all but the last clone created. This is because the clusters in the clone packets will reference the original data, so in order to preserve the premise that clone packets contain the same data as the original packet, any modifications to data further down the pipeline must be made to make a copy of the data before modifying it (this is what rwCLFLAGS_EXTERNAL does - see RxClusterSetExternalData for details), or else the data will be different for subsequent clones. In the case of the last clone, the data is free to change since there are no subsequent clones for this to affect.
|
|
||||||||||||||||
|
RxPacketCacheCreate creates a RxPacketCache from an RxPacket which can be used to clone that packet. Owing to the nested pipe execution mechanism (see RxPipelineExecute for details), only one packet can exist at a time. The RxPacketCache structure makes it possible to create clones of a packet within a pipeline node and dispatch these, possibly to different outputs of the node. To use the RxPacketCache, you should first create it using this function. Then, dispatch (or destroy, though it seems unlikely you would want to do this) the original packet. Finally, repeat this procedure as many times as you wish: create a clone of the original packet using RxPacketCacheClone, modify that packet as desired (or not) and then dispatch it.
On creating a cache, it is assumed that you will be using it to create clones of the original packet, so RxPacketCacheCreate takes steps to modify the flags of clusters within the original packet to make this possible. For the original packet and all but the last created clone (see RxPacketCacheClone), the flags of all clusters within them (that were active and contained data in the original packet at the time of cache creation) must be set to rxCLFLAGS_EXTERNAL if they are not already set thus - because all packets will reference the same data, any modifications to cluster data futher down the pipeline must cause the data to be copied rather than changing the original data and invalidating the premise that the content of cloned packets is identical to that of the original. See RxClusterSetExternalData for further details on external data. An exception to the above rule is clusters with data marked as rxCLFLAGS_EXTERNALMODIFIABLE - this data is in a fixed location for some (we assume) important reason, so moving it somewhere else will break things. Hence, this data may change from clone to clone.
|
|
||||||||||||
|
RxPacketCacheDestroy Destroys an RxPacketCache as created by RxPacketCacheCreate.
|
|
||||||||||||||||
|
||||||||||||
|
RxPipelineNodeCloneOptimize optimises a Clone pipeline node's operation by calculating which clusters propragate down which outputs of the pipeline node, thus allowing it to specify rxCLFLAGS_EXTERNAL as few times as possible (it can result in data copying and does not need to be specified for each cluster the last time it is output in a packet from the Clone pipeline node). This function should be called after unlocking the containing pipeline to that cluster propagations is fixed in its final state. The clone node needs to ensure that for each packet in which it dispatches a cluster, the outgoing data is the same (i.e it is a true clone of the original data). This requires that for all but the last dispatch of each cluster, it flags the cluster with rxCLFLAGS_EXTERNAL because this ensures that if any subsequent nodes edit the cluster's data, it is copied rather than modified in-place.
|
© 1993-2003 Criterion Software Limited. All
rights reserved. Built Tue Apr 22 12:46:54 2003. Send Feedback
| Converted from CHM to HTML with chm2web Pro 2.85 (unicode) |