Description
Translation from Ogre 1.81 Manual, without prejudice to the understanding of the case, to reduce the time of reading and translation of the workload
This is done only by removing the modified part of the text, and does not reduce any of the knowledge points in the original document, which can be used as the equivalent reference manual
In addition to some difficult to understand the parts have been modified, or by "attached" to do the labeling
If you find a difficult to understand part, you can reply, I will make the original changes or reply
Note: The original writing time in the third quarter of 2006, has been close to 10 years
So the old graphics card is already antique, the advanced graphics card is also an old video card.
3 scripts
Many of the features of Ogre can be scripted-driven for easy setup. Scripts are simple text files that can be edited using any standard text editor. The script takes effect immediately after editing and does not require recompilation. Facilitates rapid prototyping creation
Ogre supports the following scripts:
Materials, synths, particles, layers (overlay), font definitions
3.1 Material
Material scripts provide the ability to define complex materials through scripting. At the same time, you can still set materials in your code through classes such as material and texture, but that's a bit more stupid. Instead, you can define the material in a text file and load it as needed.
Script loading
The material script is loaded when the resource group is initialized, and Ogre finds the '. Material ' extension file under all resource locations (root::addresourcelocation) and resolves it. If you need to parse the file manually, you can use Materialserializer::p arsescript ().
It is important to note that the material is not fully loaded during parsing, meaning that only the definitions are loaded, textures, or other resources are not loaded. This is because the material library is usually very large, and in reality most of the scenes only use a relatively small subset, completely loading all the materials in the script will result in unnecessary memory consumption. You can access a delayed-loaded material (Materialmanager::getsingleton.getbyname ()) in the usual way, but you must call the Load method before you use it. Ogre do this automatically when you set up a material using entyity, and so on.
In addition, the material name must be unique across all scripts in the system, because materials are identified by name.
Format
You can define multiple materials in a single script. In pseudo C + + format, each segment is qualified with curly braces ' {} ', comments using '//' (no nested annotations are allowed, no Chinese annotations are allowed before 1.8). Cases:
This is a comment
Material WALLS/FUNKYWALL1
{
First, preferred technique
Technique
{
First Pass
Pass
{
Ambient 0.5 0.5 0.5
Diffuse 1.0 1.0 1.0
Texture Unit 0
Texture_unit
{
Texture Wibbly.jpg
Scroll_anim 0.1 0.0
Wave_xform scale sine 0.0 0.7 0.0 1.0
}
Texture Unit 1 (This is a multitexture pass)
Texture_unit
{
Texture Wobbly.png
Rotate_anim 0.25
Colour_op add
}
}
}
Second technique, can be used as a fallback or LOD level
Technique
{
// .. And so on
}
}
The material must have a name, the name must be unique, and the name can contain a path character '/', which can be used to logically divide the material and help avoid duplication, which is not handled by the engine according to the tree structure. If the material name contains spaces, enclose them in double quotation marks
Note: The colon ': ' is used to specify a material copy (inheritance) and cannot be used as a name
Materials can be inherited from previously defined materials by using ': ' After the material name, followed by the inherited material name. You can only inherit part of other materials, refer to "Script inheritance", you can also use variables in inheritance, refer to "script variables"
Materials are made up of multiple technologies (3.1.1 technique), and technology is a way to get the results you want. You can provide multiple techniques to provide an alternative implementation when the hardware does not support the best technology, or you want to use a low LOD (level of detail) version of the material when the object is far away to save rendering power.
Technology consists of multiple channels (pass), which divides the entire rendering of an object into several times to achieve a combination effect. When the number of textures used in a channel exceeds the maximum number of hardware support, Ogre automatically divides it into multiple channels at run time (only when no fragment shader is used). Each channel has some top-level properties such as ambient light. Refer to 3.1.2 Pass
Each channel can contain 0 to more texture units, reference 3.1.3TextureUnit. Defines the textures used, optional blending operations (multi-texture), and texture effects
You can reference vertices, fragment shaders, and specify a set of program parameters in the channel. The shader is declared in a separate. program script file. Reference: 3.1.4 declaring vertex/fragment programs, 3.1.9 using vertex/geometry/fragment programs in channels
The material has the following properties:
Lod_strategy
Set the LOD policy name that is used, which includes the following policy names:
' Distance ' calculates LOD based on camera distance
' Pixelcount ' calculates LOD based on the number of pixels in the screen space
Format: Lod_strategy <name>, default distance
Lod_distances (discarded)
Use Lod_values instead
Lod_values
Specify a set of values from the high Lod to the low LOD, indicating that the material switches to the next LOD location Point, which defines the value that the material changes Lod. Setting this property indicates the technique used to select a material based on the camera's distance or approximate screen coverage. Implicitly, LOD 0 is activated when it is less than the first value (you do not need to specify 0 at the beginning). You need to ensure that each value corresponds to a lod_index at least one technology (if you specify three values, you need multiple techniques for LOD 0 1 2 3 respectively). You must set at least one technology for LOD 0.
Format: Lod_values <value0> <value1>., default None
Example: Lod_values 300.0 600.5 1200, set 4 LOD,LOD0 to 0-300,lod3 for more than 1200.
Receive_shadows
Sets whether an object using this material accepts shadow casts
Format: Receive_shadows <on|off>, default on
Whether the object accepts shadows is controlled by a number of factors, refer to: 7 shadows. Note: Transparent objects never accept shadows, this option is for opaque objects only
Transparency_casts_shadows
Controls whether transparent objects cast shadows
Format: Transparency_casts_shadows <on|off>, default off
Whether the object accepts shadows is controlled by a number of factors, refer to: 7 shadows. The option controls whether transparent material is allowed to cast shadows, otherwise it is not projected. For example, when rendering a texture shadow, a transparent material usually does not render to a shaded texture because it does not block the light. This tag can override this method of handling
Set_texture_alias
To set texture alias associated textures
Format: Set_texture_alias <alias name> <texture name>
Used to set the texture used by a texture cell that inherits from another material. Reference: 3.1.12 Texture aliases
3.1.1 Techniques Technology
The technology in the material script defines a rendering of the object. The simplest material definition contains only one technology, but because of the variety of hardware capabilities, doing so requires ensuring that your target hardware has the capabilities required by the technology. In addition, if you want to use material LOD, techniques can be used to define a simpler way of rendering materials, which means that objects of long distances use simpler, less-demanding technologies.
When the material is used for the first time, it needs to be compiled first. This includes scanning all technologies and tagging all current rendering APIs and hardware-supported technologies. If no technology is supported, the material will be rendered blank. The compilation process examines the following:
L number of each channel texture
If the number of textures exceeds the number supported by the graphics card, the technique is still available as long as the fragment shader is not used. In this case, Ogre will divide the channel with too much texture into multiple channels to support low-performance graphics cards, while multi-texture blending will also be converted to multi-channel blending
L whether vertex, geometry, fragment coloring programs are used
L Other effects such as cube mapping, DOT3 mixing
L Whether the vendor name meets the user's specific settings
In the material script, the technology needs to be ranked in the order of performance. The preceding technique takes precedence over the use of the technology behind it. This means that you should put the most advanced technology ahead of the line.
To clearly identify the technology, you can assign a name to the technology (optional). Technology without a name uses a technical index number as its name. The first technical index is 0 and the name is "0". The technology name must be unique, otherwise the final technology will be a mixed result of all technology with the same name, and Ogre.log will record a warning. Technology that specifies a name helps to modify existing technologies when material is inherited
Technology has the following properties:
Scheme
Set the scenario to which the technology belongs. Material schemes are used to switch from one set of technologies to another. For example, you can define a high school low of three levels in the material to allow users to choose performance/quality. Or, for example, you use all HDR pipelines on high-end machines, render all objects with shaders, and use only simple pipelines under other hardware conditions. These can all be achieved through the program. The currently active scenario is typically at viewport level control (Viewport::setmaterialscheme), and the default scheme is ' defaults '
Format: scheme <name>, example: Scheme HDR
Lod_index
Set the LOD (level of detail) index of the technology detail
Format: Lod_index <int>, default 0
All techniques correspond to a LOD, which defaults to 0, which is the highest LOD. Increasing the index means a lower LOD. You can (most of the time) specify the same LOD for multiple technologies, which means that Ogre will pick the best technology in the same LOD. For readability, it is recommended that you arrange your technology in the order of Lod and performance, although only the latter is necessary (ogre depends on the order of which one is best). You need to have at least one LOD 0 technology.
LOD application Distance According to the lod_distances setting of the material
Shadow_caster_material
When using texture shading, you can specify an alternative material to render an object to a shaded texture. This is like the advanced version of Shadow_caster_vertex_program, note that you must render the shadow in one channel, and only the first channel.
Shadow_receiver_material
When using texture shading, you can specify an alternative material when performing a Shadow receive channel. Note that the explicit receive channel here applies only to non-integrated texture shadows, where shadow rendering is handled separately (by adjusting the channel or the Light Overlay channel). This is like the advanced version of Shadow_receiver_vertex_program/shadow_receiver_fragment_program, note that you need to render shadows in one channel, and only the first channel.
Gpu_vendor_rule/gpu_device_rule
While ogre can detect hardware compatibility and support technology based on this setting, occasionally some graphics cards have special behavior beyond the necessary detection range, and you can match special rules to make the technology available/unavailable on a specific vendor graphics card, or when matching device name mode is available/not available
Format: Gpu_vender_rule <include|exclude> <vender_name>
Gpu_device_rule <include | Exclue > <device_pattern> [case_sensitive]
The include indicates that the technology is available at the time of the match, Esclude indicates that a mismatch is available, and you can specify multiple rules. The effective Vendor_name currently includes: Nvidia\ati\intel\s3\3dlabs. Deviec_pattern can be any character, you can also use the wildcard character ' * '. Cases:
Gpu_vendor_rule include Nvidia
Gpu_vendor_rule include Intel
Gpu_device_rule Exclude *950*
That is, the technology only supports NVIDIA and Intel-made graphics cards with a device name that does not contain 950
Note: These rules are used only to mark the technology as not supported when hardware compatibility is judged. The technology that passes the rule verification still adapts to the common hardware compatibility verification.
3.1.2 Pass Channel/pathway
A channel is a rendering of related geometry, one render API call in a set of render states. A technology can contain between 1 and 16 channels, and the more channels the technology contains, the higher the cost of rendering.
The channel can specify the name, and the channel name without the specified name defaults to the channel index. For example: The first channel index of the technology corresponds to 0, then the name is "0". The channel name in a technology must be unique, otherwise the final channel will be a mixed result of all channels with the same name. In this case, Ogre.log will record a warning message. Assigning a name to a channel helps to modify an existing channel when the material is inherited.
The channel includes the following properties and 0 to more texture cell texture_unit, as well as optional vertex/geometry/Fragment coloring programs:
Ambient
The ambient light reflection property corresponds to the reflectance of the red, green, and blue components of the ambient light at the vertex. You can use Vertexcolour to specify the vertex colors that are defined in the grid (mesh). The default color is white. This setting is not valid when the light is off (lighting off) or any texture layer has the ' colour_op replace ' property set. This property is not valid when using ASM\CG\HLSL, and OpenGL material properties can be read in the shader when using GLSL
Format: Ambient (<red> <green> <blue>[<alpha>]) | Vertexcolour, Default: Ambient 1.0 1.0 1.0 1.0
Example: Ambient 0.0 0.8 0.0 or ambient vertexcolour
Diffuse
The diffuse light property that corresponds to the reflection scale of the red, green, and blue components of the diffuse light, which is created in the scene. You can use Vertexcolour to specify the vertex colors defined in the grid. The default color is white. This setting is not valid when the light is off (lighting off) or any texture layer has the ' colour_opreplace ' property set. This property is not valid when using ASM\CG\HLSL, the OpenGL material property can be read in the shader using GLSL
Usage: Diffuse (<red> <green> <blue>[<alpha>]) | Vertexcolour, Default: Diffuse 1.0 1.0 1.0 1.0
Example: Diffuse 0.0 0.8 0.0 or diffuse vertexcolour
Specular
Specular light properties, corresponding to the specular (light class instance highlighting) The red, green, and blue components at the vertex reflectance ratio. You can use Vertexcolour to specify the vertex colors defined in the grid. The degree of specular highlight is determined by the parameter shininess, the larger the shininess the sharper the more sharp, shininess take 0-1 when the mirror light will be applied to the entire surface, the best value range is 1-128. This setting is not valid when dynamic light is off or any texture layer uses ' colour_op replace '
Usage: Specular (<red> <green> <blue>[<alpha>]) | Vertexcolour <shininess>
Example: Specular 1.0 1.0 1.0 1.0 128
Default: Specular 0.0 0.0 0.0 0.0 0.0
Emissvie
Object self-illumination properties. You can use the keyword Vertexcolour to specify the vertex color defined in the grid.
Usage: emissive (<red> <green><blue> [<alpha>]) | Vertexcolour
Example: Emissvie 1.0 0 0
Scene_blend
Sets how the channel mixes with the scene's existing content. The blending of textures (reference 3.1.3texture_unit) is used for blending between texture layers, and channel blending sets the end result of the entire channel and the blending of content already present in the render target. Mixed support for transparency and other effects. There are two formats: one that is predefined for common blending, and another that directly sets the source, Target factor.
Format One:scene_blend<add|modulate|alpha_blend|colour_blend>
This is the simple form of enumerating common mixed types through a parameter:
Add render color overlay to scene. For explosions, fireworks, lighting, ghosts, equivalent to ' scene_blend one One '
Modulate render colors multiplied by the scene. Rendering also darkens the scene. Suitable for smoked glass, translucent and so on. Equivalent to ' scene_blend dest_colour Zero '
Colour_blend colors The scene according to color, not darken the scene. Equivalent to ' Scene_blendsrc_colour one_minus_src_colour
Alpha_blend uses alpha to blend scenes, equivalent to ' scene_blend src_alpha one_minus_arc_alpha '
Format two: Scene_blend <src_factor><dest_factor>
This version allows full control of the hybrid operation, and the final result is =textue*sourcefactor+scene_pixcel*destfactor, and the effective factors include:
One constant 1
Zero constant 0
Dest_colour Target Color
Src_color source Color
One_minus_dest_colour 1-dest_colour
One_minus_src_colour 1-src_colour
Dest_alpha Target Alpha
Src_alpha Source Alpha
One_minus_dest_alpha 1-dest_alpha
One_minus_src_alpha 1-src_alpha
Default: Scene_blend one zero opaque
Separate_scene_blend
Similar to Scene_blend, you can specify the blending of color components and alpha components, respectively. This option is only meaningful if the render target has an alpha channel, so that subsequent alpha channels, such as render to texture, can be used.
Format one: separate_scene_blend<simple_colour_blend> <simple_alpha_blend>
Same as Scene_blend format
Format two: separate_scene_blend<colour_src_factor> <colour_dest_factor> <alpha_src_factor><alpha_ Dest_factor>
Same as Scene_blend format two
Scene_blend_op
Change the source of the default scene blending equation, the last mixed expression operator of the target ingredient, which defaults think ' add '/' + ', that is, the mixed equation defaults to:
Source*srcfactor ' + ' dest*destfactor.
Format:scene_blend_op<add|subtract|reverse_subtract|min|max>
Separate_scene_blend_op
Similar to Scene_blend_op, the difference is that the mixed-expression operators that set the color and alpha components separately
Format: Separate_scene_blend_op <colourOp><alphaOp>
Default value: Separate_scene_blend_op add add
Depth_check
Whether to conduct an in-depth check, refer to Depth_func for more advanced configuration
Default: Depth_check on
Depth_write
Whether to write in depth
Default: Depth_write on
Depth_func
Set depth comparison function
Format: Depth_func Always_fail | Always_pass | Less |less_equal | Equal | not_qual | greate_equal | Greater
Default: Depth_func less_equal is less than equals when passing a test
Depth_bias
Depth offset, which is used to move it to the other side when Coplanar.
Format: Depth_bias <constant_bias>[<slopescale_bias>]
Final depth value = depth-(Constant_bias *minobservabledepth + maxslope * slopescale_bias)
Depth_bias 1 indicates that the depth value moves one tick forward. When two polygons are vertices, depth_bias 1 moves them to the top. If not, the accuracy of the data results in a deviation in the depth of the calculation (the higher the depth deviation from the camera, the same distance difference corresponds to a large depth difference when the camera is close), in which case at least Depth_bias 2 2 can be moved to the upper layer.
Iteration_depth_bias
When used for multiple iterations of a channel, set an additional offset value. If you need to iterate three times, the first offset is Depth_bias, the second time is depth_bais+ Iteration_depth_bias, and the third is depth_bais+ iteration_depth_bias*2
Format: Iteration_depth_bias <bias_per_iteration>
Alpha_rejection
Sets the way the channel discards pixels by its alpha value for handling objects that have only transparent, opaque states, such as leaves.
Format: alpha_rejection <always_fail | Always_pass |less | less_equal | Equal | not_qual | greater_equal | Greater> <value>
Example: Alpha_rejection greater_equal 128, theoretically value can use any value between 0-255, but for hardware compatibility it is best to limit it to 0-128.
Alpha_to_coverage
Sets whether texture edges are multi-sampled based on texture alpha for better integration with the background, typically only for graphics cards after 2006 years. Apply to plant leaves and link fence style textures.
Format: Alpha_to_coverage <on|off>
Light_scissor
Sets whether rendering of the current channel is limited to the screen space clipping rectangle calculated from the light falloff range
Format: Light_scissor <on|off>
This option is usually useful only if the current channel is a light overlay channel, and is at least the second or more channel in the technology. That is, the setting does not render the area outside the current light influence. If more than one light is passed to the channel, the crop area is defined as the screen space that covers all the lights. This option is ignored because the directional light is infinitely large.
Use standard lights to overlay shadows without specifying this option, because this is the default behavior. If you use the integrated texture Shadow custom channel, you need to specify.
Light_clip_planes
Sets whether the triangle assembly is limited to the clipped body of the light overlay. Directional lights ignore this option, the point light clip body is defined as a cube calculated from light attenuation, and the spotlight clipping body is a pyramid shape based on the illumination angle and the light falloff range.
Format: Light_clip_planes <on|off>
This option is only valid if there is only one point light or spotlight, and if more than one light source or directional light is not valid. If there is no light, all objects are not rendered.
With standard overlay shadows (template overlays, texture overlays), you can turn on cropping with scenemanager::setshadowuselightclipplanes, regardless of the channel settings (because it is rendered individually). This option is turned off by default because using the clipping plane is not necessarily faster, depending on the range of scenes covered by the light. In general, the smaller the light range, the more likely the benefits are to be greater than the performance loss of the crop itself. You can use this option to set each channel if you do not use a shadow or use an integrated texture shadow to customize the channel mode.
When using OpenGL, it is important to note that all custom cropping planes are not valid when using the ARB vertex program. Custom cropping is only available when using GLSL with Gl_clipvertex in shader, detailed reference GLSL documentation. Custom cropping is always available in Direct3D.
Illumination_stage
When the overlay lighting model is used (template overlay, texture overlay), the scene is divided into 3 separate stages for rendering. Ambient (ambient light), Per-light (Light Shadow Overlay), decal (decal). Typically ogre can automatically classify channels, but some effects require the lighting properties to be manually specified. For example, in the default rendering sequence, the texture is applied at the last decal stage, which darkens the effect of the specular light. As a workaround, you can apply textures to the per-light stage to overlay the specular light after the texture is pasted, instead of providing a separate decal stage.
If you set the illumination stage of a channel, you need to set all the channels in the technology at the same time, otherwise the settings are not valid. Each category can have more than one channel and cannot be swapped in order. That is, all ambient channels are rendered before the Per_light channel, and all per_light channels are rendered before the decal channel, while the channels within each cluster are also rendered sequentially.
Format: Illumination_stage <ambient | Per_light |decal>
Normalize_normals
Whether to automatically normalise each vertex normal
Format: Normalise_normals <on | Off>, default off
Scaling an object causes normal scaling, which can cause lighting calculations to be incorrect. By default, Scenemanager automatically detects and re_normalizse the normals of all scaled objects, which has some performance costs. If you prefer to control manually, you can call Scenemanager::setnormalisenormalsonscale (false) and use this option in materials that are sensitive to normal scaling.
Transparent_sorting
Sets whether transparent textures are sorted by depth
Format: transparent_sorting <on | Off | Force>, default on
By default, all transparent objects are rendered from far to near according to the camera distance. This is the usual practice, but in some cases, depth sorting is not required. For example, the current frame and the next frame must be rendered in the same order. In this case, you can set off to block sorting.
Force ordering can also be set through the forces. This is usually done when the channel is transparent (the target color participates in the calculation) and requires deep writing or reading, indicating that the unordered order cannot be rendered reliably. By setting ' Force ', you can make ogre mandatory for sorting, regardless of other circumstances.
Cull_hardware
Set up hardware cropping methods
Format: CULL_HARDWARE<CLOCKWISE|ANTICLOCKWISE|NONE>, default clockwise
Note: Ogre default to OpenGL, all in the right-hand coordinate system, and Direct3D opposite
Cull_software
Set up software cropping methods
Format: Cull_software <back|front|none>, default back
In some cases, the engine will crop the geometry before it is sent to the hardware. Software clipping is based on the normal direction of the surface (most of the time it can be estimated and not necessarily the same as the ogre default), unlike the hardware's vertex order based on the triangular polygon. If you use the appropriate scene manager, you can crop it entirely using the software based on the surface normal direction by turning off hardware cropping.
Lighting
Sets whether the light is valid. When the light is off, all objects corresponding to the channel will be fully illuminated. This option is not valid when using vertex programs.
Format: Lighting <on|off> default on
All ambient\diffuse\specular\emissive and Shading properties are not valid when the light is turned off. When the light is turned on, the object calculates the Diffuse\specular and the global ambient\emissive according to the vertex normals
Shading
Set the channel dynamic light shading type
Format: Shading <flat | Gouraud | phong> default Gouraud
When the light is on, lighting is used to calculate the color of each vertex. This option defines how the surface difference is based on the computed vertex color.
Flat no difference, using the first vertex color of the surface
Gouruand the linear difference of the vertex color based on the surface
Phong the surface difference based on the vertex normals, and then calculates the pixel color (per pixel illumination). You can get more natural lighting, but it's much more expensive, and it works better in high tessellation, but not all hardware supports it.
Polygon_mode
Polygon Rasterization, whether to fill or draw only edges or vertices
Format: Polygon_mode <solid | wireframe | Points>, default solid
Polygon_mode_overrideable
Sets whether the polygon_mode of the channel can be degraded by the polygon_mode of the camera.
Format: polygon_mode_overrideable <true|false> default True
Fog_override
Set No to reload the scene fog settings. Note: Only the fixed pipeline fog is affected, the original scene fog parameters are still passed through the Fog_params parameter to the shader
Format: fog_override <override> [<type><colour> <density> <start> <end>], false by default
Example: Fog_override true exp 1 1 1 0.002 100 10000
Colour_write
Whether to write color
Format: Colour_write <on|off> default on
You can use to initialize the depth buffer by turning off the color write and minimizing other settings. This can significantly improve performance on newer graphics cards, especially when a complex fragment shader is used, because the fragment shader is no longer required to run after a deep check fails.
Start_light
Set the first light used by a channel
Format: start_light <number> default 0
Can be used to specify multiple different channels to handle different light sources individually. can also be used in conjunction with the Iteration option
Max_lights
Set the maximum number of available lights for a channel
Format: max_lights <number>, default 8
The largest available light based on a fixed pipeline is determined by the rendering system, typically 8. A programmable pipeline relies on a corresponding program.
Iteration
Set the channel iteration mode, which is run multiple times
Format 1:iteration<once | once_per_light> [Lighttype]
Format 2:iteration<number> [<per_light>[lighttype]]
Format 3:iteraion<number>[<per_n_lights><num_lights>[lighttype]]
The default channel runs only once. However, if you use a programmable pipeline, or if you want to exceed the number of lights that are normally supported, you need to use the once_per_light option. In this case, only the light index 0 is used and the channel is executed multiple times, each time the different lights are set to the lamp index 0 in turn. This can make the channel expensive, but this is probably the only way to achieve some effect, such as a pixel-wise illumination effect that supports 1-n lights.
Use number instead of once to set the channel to execute multiple times after setting the render state. Because the render state is not changed after the initial setup, it is very fast to repeat calls every time, which is ideal for using a shader program and needing to iterate over multiple iterations in the same rendering state, such as: hair, motion blur, and so on.
If you use Once_per_light, you need to add ambient channels in front of the channel, otherwise objects not in all light ranges will not render. This is important even when the scene has no ambient light, because you might want to show the outline of the object.
The Lighttype parameter is only valid when using Once_per_light\per_light\per_n_lights, and is used to restrict the channel from running to a type of light source: Point\directional\spot. This is useful when writing vertex \ Fragment shaders, as it is assumed that the light source type is much easier. And at least point light and directional light can be processed in the same way
Note: The Shader channel index number and iteration index number can be told by automatic parameter Pass_number\pass_iteration_number
GLSL Simple Fur
Vertex_program Glsldemo/furvs GLSL
{
SOURCE Fur.vert
Default_params
{
Param_named_auto Lightpositionlight_position_object_space 0
Param_named_auto Eyepositioncamera_position_object_space
Param_named_auto Passnumber Pass_number
Param_named_auto Multipassnumberpass_iteration_number
Param_named furlength Float 0.15
}
}
Point_sprites
Whether to render the point as a quad, default off. Turn on Point_sprites to set point_size to the appropriate size or turn on point_size_attenuation at the same time, otherwise render the 1 pixel-size point by default
Example:
Point_spriteson
Point_size 5
Point_size_attenuation on 0 10 0
Point_size
Point elf render size, default value 1.0, is a pixel size, when point_size_attenuation is turned on relative size, corresponding to the entire screen height. The point sprite needs to be turned on, and the maximum/minimum size is controlled by Point_size_min\point_size_max. Example: Point_size 32
Point_size_attenuation
Whether the point sprite size is attenuated by distance, formula = Pointsize * 1/(constant + linear * dist + quadratic * dist^2)
You need to set constant linear quadratic three parameters, default 0 1 0, which is falloff by perspective. Need to turn on the Point wizard, point Maximum/minimum size is controlled by Point_size_min\point_size_max
Usage: Point_size_attenuation < (on [constant linearquadratic]) |off>
Example:
Point_sprites on
Point_size_attenuation on 1 2 0.1
Point_size_min
Point elf Minimum size, default to 0:point_size_min 0
Point_size_max
Point elf maximum size, default 0, represents the maximum size supported by the graphics card
Point_size_max 0
Ogre Reference Manual (ii) 3.1.1-3.1.2 material, technology, channel