meta data for this page
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
vertexpacker [2021/03/15 09:36] – croft | vertexpacker [2023/04/03 18:40] (current) – steph.jorgensen | ||
---|---|---|---|
Line 1: | Line 1: | ||
- | ====== Vertex | + | ====== Vertex |
In export formats that support it (currently only STSDK, used with the SpeedTree SDK), vertex packing lets you have complete control over the data stored in each vertex in the exported file, which allows the file data to be loaded directly into render buffers at runtime. | In export formats that support it (currently only STSDK, used with the SpeedTree SDK), vertex packing lets you have complete control over the data stored in each vertex in the exported file, which allows the file data to be loaded directly into render buffers at runtime. | ||
Line 7: | Line 7: | ||
===== Description XML ===== | ===== Description XML ===== | ||
- | You define a vertex packer by placing an XML file describing it in the <app install>/ | + | You define a vertex packer by placing an XML file describing it in the <app install>/ |
+ | |||
+ | Vertex streams represent separate buffers of data that can be bound to the vertex shader separately (though most common use is to just use one). Each stream can contain multiple vertex attributes. A description of the format | ||
< | < | ||
<?xml version=" | <?xml version=" | ||
< | < | ||
- | Program=" | + | |
- | Force32bitIndices="false" | + | often named the same but with the .lua extension] |
- | > | + | Force32bitIndices=[true/false to always use 32bit indices, or allow the indices |
- | <Stream Name=" | + | to fall back to 16bit if there are fewer than 65k vertices] |
- | < | + | > |
- | < | + | < |
- | < | + | |
- | < | + | |
- | </ | + | < |
+ | | ||
+ | | ||
+ | | ||
+ | for instance a 0-255 ubyte will come into the shader as 0.0-1.0] | ||
+ | Description=[description of this stream, if wanted] | ||
+ | | ||
+ | ... | ||
+ | | ||
+ | ... | ||
</ | </ | ||
</ | </ | ||
+ | |||
+ | Showcasing the above format description, | ||
+ | |||
+ | < | ||
+ | <?xml version=" | ||
+ | < | ||
+ | Program=" | ||
+ | Force32bitIndices=" | ||
+ | > | ||
+ | <Stream Name=" | ||
+ | < | ||
+ | Description=" | ||
+ | < | ||
+ | Description=" | ||
+ | < | ||
+ | Description=" | ||
+ | < | ||
+ | Description=" | ||
+ | </ | ||
+ | </ | ||
+ | </ | ||
+ | |||
+ | ===== Packing script ===== | ||
+ | |||
+ | During vertex packing, the packing script specified in the description XML file is run for each vertex. This script is written in Lua. While this documentation cannot cover every aspect of the Lua language, you can find additional info at [[http:// | ||
+ | |||
+ | The input data available to use in the script covers all of the data available for a vertex. | ||
+ | |||
+ | ^ Variable^Description ^ | ||
+ | | in_anchor|(3 float array) - anchor position for node| | ||
+ | | in_offset|(3 float array) - offset from anchor| | ||
+ | | in_lod_offset|(3 float array) - lod offset from anchor| | ||
+ | | in_texcoord|(2 float array) - main UV| | ||
+ | | in_lightmap_texcoord|(2 float array) - lightmap UV, if available| | ||
+ | | in_normal|(3 float array) - vertex normal| | ||
+ | | in_binormal|(3 float array) - vertex binormal| | ||
+ | | in_tangent|(3 float array) - vertex tangent| | ||
+ | | in_vertex_color|(3 float array) - vertex color| | ||
+ | | in_vertex_alpha|(float) - vertex blend value| | ||
+ | | in_ambient_occlusion|(float) - ambient occlusion value| | ||
+ | | in_wind_branch_position|(3 float array) - position used for branch position in wind| | ||
+ | | in_wind_branch_direction|(3 float array) - growth direction for the branch in wind| | ||
+ | | in_wind_branch_weight|(float) - weight/ | ||
+ | | in_wind_ripple|(float) - wind ripple scalar| | ||
+ | | in_bone_id|(integer) - id of the bone attached to this vertex| | ||
+ | | in_two_sided|(boolean) - represents the two-sided flag on the material used on this vertex| | ||
+ | | in_geometry_type|(integer) - Geometry type: Branch=0, Frond, Leaf, FacingLeaf, Billboard| | ||
+ | | in_original_geometry_type|(integer) - Original geometry type before batching: Branch=0, SubDivBranch, | ||
+ | | in_tree_extents|(6 float array) - Tree extents: min xyz, max xyz| | ||
+ | |||
+ | Besides built-in Lua calls, the functions available to call in the script are as follows. | ||
+ | |||
+ | ^ Function^Parameters ^Description ^ | ||
+ | | set_attribute|< | ||
+ | | set_attribute_integer|< | ||
+ | | set_batch_type|< | ||
+ | | set_batch_priority|< | ||
+ | | kill| |Completely remove this vertex (and the polygon with which it is associated) from the final mesh.| | ||
+ | | print|< | ||
+ | |||
+ | === Saving vertex data === | ||
+ | |||
+ | To place any of the input vertex data into the final vertex attributes in the export file, you use the set_attribute function or the set_attribute_integer function (when strict adherence to integers is wanted). | ||
+ | |||
+ | The value you pass to these functions will get converted to the final data type as close as possible. In this fashion, you don't have to worry about packing a float into a half float or even a byte, as the set_attribute functions will attempt to do this for you. | ||
+ | |||
+ | |||
+ | === Batching control === | ||
+ | |||
+ | The geometry in the tree is as batched as much as possible, just like in other file formats. Without any further input, the tree will be batched into as few draw calls as it can, depending on the number of separate materials occur after atlassing. | ||
+ | |||
+ | However, from the vertex packing script, you have some control over this. The set_batch_type function can pull geometry out into a separate draw call. You might want to pull anything with a blend/alpha value other than 1.0 out into a separate draw call to avoid rendering the whole tree with alpha blending on, for example. | ||
+ | |||
+ | To do this, you can set any integer you wish to set_batch_type. What integer that is is up to you, and the default it 0. Any unique integer passed will cause a new draw call filled with all of the geometry set to that integer. The batch type value is available in the file and through the SpeedTree SDK to do with as you wish at run-time. You can encode all sorts of things into the batch type, and cause different rendering states or shaders to be used at runtime on that piece of geometry. | ||
+ | |||
+ | Polygons are made up of multiple vertices, and they may have different values for the code used in set_batch_type. You may want to make sure that a certain vertex value takes priority over the other vertices in that polygon. To do this, use set_batch_priority. With the previous example of pulling out polygons needing alpha blending, you would set the priority to 1 if blend/alpha is less than 1.0 and 0 otherwise. This ensures that any polygon needing to be put into the batch type of 1 will get that value. | ||
+ | |||
+ | < | ||
+ | -- LUA BATCHING EXAMPLES | ||
+ | |||
+ | -- batch by geometry type | ||
+ | set_batch_type(in_geometry_type) | ||
+ | |||
+ | -- batch by two-sided or not | ||
+ | if in_two_sided then | ||
+ | set_batch_type(1) | ||
+ | else | ||
+ | set_batch_type(0) | ||
+ | end | ||
+ | |||
+ | -- batch by needing blending | ||
+ | if (in_vertex_alpha < 1.0) then | ||
+ | set_batch_type(1) | ||
+ | set_batch_priority(1.0) | ||
+ | else | ||
+ | set_batch_type(0) | ||
+ | set_batch_priority(0.0) | ||
+ | end | ||
+ | |||
+ | -- batch by geometry type AND two-sided | ||
+ | if in_two_sided then | ||
+ | set_batch_type(in_geometry_type + 5) | ||
+ | else | ||
+ | set_batch_type(in_geometry_type) | ||
+ | end | ||
+ | |||
+ | </ | ||
- | ===== Packing Script ===== |