A rendering path is a rendering in a geometric issue; a rendering API with a complete set of rendering attributes is called at a time. One technology can include 1 to 16 rendering paths. Of course, the more rendering paths are used, the higher the overhead of the technology during rendering.
To clearly identify which rendering path is used, the rendering path is often named. Of course, the name is not required. The rendering path without a name in the script will be named after the rendering path index number. For example, in a technology, the index number of the first rendering path is index 0, so if the script does not name it, its name is "0 ". The name of a rendering path in a technology must be unique. Otherwise, the result of the last rendering path will be the fusion of the effects of all rendering paths with the same name. If this happens, a warning message is sent to ogre. log. In addition, the named rendering path also helps to copy materials and modify existing rendering paths: (for details, see 3.1.11.
Material copy part)
The rendering path has a set of global attributes (as described below), 0 or multiple Texture unit entries, (see section 3.1.3 Texture unit), and optional references to vertex programs or fragment programs (see section 3.1.9 ).
Use vertex programs and fragment programs in rendering paths ).
The following describes some attributes that can be used in the "rendering path" section of the. Material script:
Attribute details
Ambient
Sets the reflection coefficient of the surrounding environment in this rendering path. This attribute is invalid when ASM, CG, and HLSL (high level Shader Language advanced rendering language) are used. When used together with glsl (), the Renderer can read the OpenGL material status.
Format: ambient (<red> <green> <blue> [<alpha>] | vertexcolour) values range from 0.0 to 1.0. Example: ambient 0.0 0.8 0.0
The Basic Color of the rendering Path depends on the amount of reflection of the red, green, and blue light on each vertex. This attribute determines how much ambient light is reflected (global light with no targets ). You can also use the vertexcolour keyword instead of the color value as defined in the grid to track the vertex color with the Environmental reflection coefficient. The default value is completely white, meaning that the entire object is completely illuminated. If you want to see the effect of scattering and mirror reflection, you need to reduce the correlation value of this attribute, or change the color mixture to make the object have a base color that is not white. If'Lighting off'The property is turned off for dynamic lighting or any texture layer has'Colour_op
Replace'Property, the "ambient" property is invalid.
Default Value: ambient 1.0 1.0 1.0
Diffuse
Set the diffuse reflection coefficient in this rendering path. This attribute is invalid when ASM, CG, and HLSL (high level Shader Language, advanced rendering language) are used. When used with glsl (OpenGL's Shader Language, OpenGL's rendering language), The Renderer can read the OpenGL material status.
Format: diffuse (<red> <green> <blue> [<alpha>] | vertexcolour) values range from 0.0 to 1.0. Example: diffuse 1.0 0.5 0.5
The Basic Color of the rendering Path depends on the amount of reflection of the red, green, and blue light on each vertex. This attribute determines how much four astigmatism is reflected (from the light of the illumination instance in the scenario ). The vertexcolour keyword can also be defined as in the grid, instead of the color value, so that the scattered reflection coefficient traces the vertex color. The default value is full white, which means all white light received by the object reflection. If'Lighting off'Property will be turned off for dynamic lighting or any texture layer has'Colour_op replace'Property, the "ambient" property is invalid.
Default: diffuse 1.0 1.0 1.0 1.0
Specular
Sets the reflection coefficient of the mirror reflection color in this rendering path. This attribute is invalid when ASM, CG, and HLSL (high level Shader Language, advanced rendering language) are used. When used with glsl (OpenGL's Shader Language, OpenGL's rendering language), The Renderer can read the OpenGL material status.
Format: specular (<red> <green> <blue> [<alpha>] | vertexcolour) <shininess> the value range is between 0.0 and 1.0. Shininess can be any value greater than 0. Example: specular 1.0 1.0 1.0 12.5
The Basic Color of the rendering Path depends on the amount of reflection of the red, green, and blue light on each vertex. This attribute determines how much mirror light is reflected (from the highlights of illumination instances in the scenario ). The vertexcolour keyword can also be defined as in the grid, instead of the color value, so that the mirror reflection coefficient can track the vertex color. The default value is no mirror reflection. The highlight of the mirror reflection depends on the color parameter and the size of the shining value. The higher the shining value, the more dazzling the highlight. Be careful when shining between 0.0 and 1.0, because this will cause the highlight color to be applied to the entire plane with this highlight attribute material. In this way, when the angle of the plane changes, it will be particularly disgusting to flash. When the shining value is between 1 and 128, it performs well in DirectX and OpenGL Renderer. If'Lighting
Off'Property will be turned off for dynamic lighting or any texture layer has'Colour_op replace'Property, the "ambient" property is invalid.
Default Value: specular 0.0 0.0 0.0 0.0
Emissive
Sets the amount of self-illumination of an object. This attribute is invalid when ASM, CG, and HLSL (high level Shader Language, advanced rendering language) are used. When used with glsl (OpenGL's Shader Language, OpenGL's rendering language), The Renderer can read the OpenGL material status.
Format: emissive (<red> <green> <blue> [<alpha>] | vertexcolour) values range from 0.0 to 1.0. Example: emissive 1.0 0.0 0.0
If an object is self-emitting, it does not need external light to illuminate it. Whether it is ambient light or other light, it is like having its own ambient light. However, in fact, this attribute is not, as the name implies, the object is not a light source for other objects in the scene (if you want to make it a light source, you need to create a light source and place it in the center of the object ). You can also define the vertexcolour keyword instead of the color value in the grid to track the vertex color. If'Lighting off'Property will be turned off for dynamic lighting or any texture layer has'Colour_op
Replace'Property, the "ambient" property is invalid.
Default Value: emissive 0.0 0.0 0.0 0.0
Scene_blend
Set a method for mixing the rendering path with the existing content in the scenario. The texture blending operation seen at the Texture unit entry is seen as a mixture between texture layers, which combines the output results of this rendering path with the content of the current rendering target. Therefore, this mixture allows the object to be transparent and other special effects. There are two forms to choose from: one is to use a pre-defined hybrid form; the other is to use a custom method, the source and target factors have your own DIY.
Format 1: scene_blend <add | modulate | alpha_blend | colour_blend> example: scene_blend add
This is a relatively simple form. The common mixed form is enumerated by a parameter. The available mixed form parameters are as follows:
Format 2: scene_blend <src_factor> <dest_factor> example: scene_blend one one_minus_dest_alpha
This format allows you to completely control the hybrid operation by setting the source and target factors. The color result of the final rendering target is (texture * sourcefactor) + (scene_pixel * destfactor ). The optional values of the two parameters are as follows:
Default Value: scene_blend one zero)
Depth_check
Set whether the deep buffer Detection Status of this rendering path is on or off.
Format: depth_check <on | off>
If the deep buffer detection is on, when a pixel needs to be written to the image buffer, the deep buffer detection checks whether the pixel is higher than the pixel at that point. If not, this pixel will not be written. If the depth buffer detection is disabled, This pixel is written regardless of the rendering results. For more advanced configurations, seeDepth_func
Default Value: depth_check on
Depth_write
Set whether to enable or disable deep buffer write for this rendering path.
Format: depth_write <on | off>
If the depth buffer write is on, the depth buffer will update the depth value of that pixel whenever a pixel wants to write to the screen buffer. Therefore, if a pixel is behind this pixel in the future, this will affect future rendering operations. If this attribute is disabled, the pixel will not update the depth buffer. In general, this attribute is open, but it can also be closed when you render a static background or a series of transparent objects located at the back of the scene so that they can overlap correctly.
Default Value: depth_write on
Depth_func
When deep Detection is enabled, set the function used to compare the depth value.
Format: depth_func <func>
If the depth detection is on (see depth_check), the depth value of the pixel to be written will be compared with the depth value of the existing content in the buffer. In general, this comparison is less than or equal to. For example, the pixels to be written are closer (or equal) to the existing content ). Possible functions are as follows:
Default Value: depth_func less_equal
Depth_bias
Set the bias of the Depth value of this rendering path. It can be used to place one of the common Polygon on the other. For example, print a pattern.
Format: depth_bias <constant_bias> [<slopescale_bias>]
The depth bias value is ultimately determined by the constant_bias * min observed depth (minobservabledepth) + Max slope (maxslope) * slopescale_bias. Slope bias is related to the angle from polygon to the lens to form a corresponding bias value. However, in some earlier hardware, this is ignored. The bias constant is a factor that forms the minimum depth value. Therefore, the value of 1 lies in the slow advance of depth at 1.1 points.
Alpha_rejection
Set this item to use Alpha as a threshold so that the rendering path rejects pixels from the pipeline.
Format: alpha_rejection <function> <value> example: alpha_rejection greater_equal 128
As shown in the preceding example, reject all pixels whose Alpha value from the pipeline is greater than or equal to 128. Function parameters can be set in the parameter list of the depth_function attribute. In theory, the value parameter can be any number between 0 and 255, but considering hardware compatibility, it is best to limit it to 0 to 128.
Default Value: alpha_rejection always_pass
Cull_hardware
Set the hardware cropping mode for this rendering path.
Format: cull_hardware <clockwise | anticlockwise | none>
A typical method of cropping triangles using the hardware rendering engine is based on the sequence of triangle vertices. The sequence of vertex surround is also related to the vertex transfer and serial direction in the rendering operation. What we see in the lens may be clockwise or counterclockwise. If 'ull _ hardware clockwise 'is selected, all triangles in clockwise order from the lens are trimmed by hardware. Apparently, 'anticlockwise 'is used to crop the triangle in the counterclockwise order. 'None' is used to disable hardware cropping, that is, rendering all triangles (used to render bilateral roads ).
Default Value: cull_hardware clockwise
The default value is the same as the default value of OpenGL, which is opposite to the default value of direct3d (because ogre and OpenGL use the right-hand coordinate system as well ).
Cull_software
Set the software cropping mode for this rendering path.
Format: cull_software <back | front | none>
In some cases, the engine also performs software pruning before sending the ry to the hardware rendering. This setting takes effect only when the scenario Manager uses it (because it is best to use a large number of world ry planes, rather than moving ry, because the price for moving objects will be high ), however, it can still be used if it can be effectively cropped before being sent to the hardware. In this case, the cropping is based on whether the back of the triangle or the front of the lens is oriented-this definition is based on the surface method (I .e: A vector perpendicular to the polygon plane and marking the positive direction ). Because the Ogre plane is expected to be positive in the clockwise direction, the software cropping 'cull _ software back' is equivalent to the hardware cropping 'cull _ hardware clockwise 'setting, which is also the reason for these two settings as the default settings. Although the names of cropping methods are different, most of the time, the surface direction is calculated in advance and not necessarily the expected way of ogre, therefore, if you have a scenario manager that uses your custom surface method, you can also set 'cull _ hardware
None' and then crop the software completely based on your method.
Default Value: cull_software back
Lighting
Set whether to enable or disable dynamic lighting. If the light is off, all objects using this rendering path will be fully illuminated.If a vertex program is used, this attribute is invalid.
Format: Lighting <on | off>
Disabling dynamic light will make any environment light, diffuse light, mirror light, radiant light, and shadow attributes redundant. When light is turned on, the object is illuminated according to the vertices.
Default Value: lighting on
Shading
Sets various shadow forms used in this rendering path to express dynamic illumination.
Format: shading <flat | Gouraud | Phong>
When dynamic illumination is enabled, the effect generates a color value at each vertex. Whether these values are completely inserted (how to insert) depends on this attribute setting.
Default Value: shading Gouraud.
Polygon_mode
Set how polygon should be rasterized. For example, they should be drawn after being filled, as points (only vertices), and line (only outer borders.
Format: polygon_mode <solid | wireframe | points>
Default Value: polygon_mode solid
Fog_override
This attribute tells the rendering path whether to cancel the fog settings of the scene, and forces its own settings of this rendering path. Other objects in the scene are obscured by fog, which is useful when you do not want fog to affect some objects. And vice versa. Note that this only affects the fixed function fog-the original scene fog parameter is still sent to the Renderer and bound with the fog_params parameter (this allows you to disable the fixed function fog and then calculate it in the Renderer; if you want to disable shadow fog, you can disable it using the shadow parameter .)
Format: fog_override <override?> [<Type> <color> <density> <Start> <End>] default value: fog_override false
If you specify the first parameter as true and provide other parameters, it indicates that you want to tell the rendering path if you select between these fog settings and the scenario settings, these fog settings are preferred. If the first parameter is true but no other parameters are provided, it indicates that you want to tell the rendering path not to use any fog settings, regardless of the scenario. The following describes the parameters:
Example: fog_override true Exp 1 1 1 1 0.002 100 10000
Colour_write
Set whether to enable or disable color writing for this rendering path.
Format: colour_write <on | off>
If the color write is disabled, no visible pixels in the rendering path are written to the screen. You may think this is useless, but If you disable color writing and use other small rendering settings properly, you can use this rendering path to initialize the depth buffer before executing the subsequent rendering path that fills the color data. This can greatly improve the effect, especially when you use a complex piece program, because if the deep detection fails, the piece program will not run at all.
Default Value: colour_write on
Start_light
Set the first light source used by this rendering path.
Format: start_light <number>
You can use this property to set the start position of the light source for this rendering path. In other words, if you set start_light to 2, the first light source to be processed is the third light source in the actual list. For example, you can use this option to process several light sources in the first group using different rendering paths, or use itIterationOption collaboration, which starts iteration from the given point in the list (for example, process the first two light sources in the first rendering path, and then repeat the two light sources each time from then on)
Default Value: start_light 0.
Max_lights
Set the maximum number of light sources used by this rendering path.
Format: max_lights <number>
The maximum number of light sources is set by the rendering system, usually 8, which is often used for rendering fixed functional materials. When you want to use a programmable pipeline (see 3.1.9 for details)
Use vertex programs and fragment programs in the rendering path). This restriction depends on the programs you want to run. If you use 'iteration once_per_light '(see iteration below), its validity is limited to the number of rendering paths you want to use. However, no matter which method you use, you must apply the max_lights restriction.
Default Value: max_lights 8
Iteration
Set whether the rendering path is iterated and repeated multiple times.
Format 1: iteration <once | once_per_light> [lighttype] Format 2: iteration <number> [<per_light> [lighttype] format 3: iteration <number> [<per_n_lights> <num_lights> [lighttype]
Example:
By default, the rendering path is executed only once. However, if you use a programmable pipeline or you want to exceed the supported light source quantity limit, you may want to use the once_per_light option. In this case, only the light source 0 is used. Each time a different light source is used as the light source 0, the rendering path is executed multiple times. Obviously, this will make the rendering path very expensive, but considering the illumination effect per pixel of 1 to n light sources, this may be the only way to achieve this effect.
Replace "once" with numbers to indicate more than one iteration of the rendering path after the rendering State is established. The rendering State does not change after initialization. Therefore, for programmable rendering that requires multiple iterations of the same rendering state, repeated drawing calls are extremely fast and ideal. For example, rendering of fur, blurred motion, and special filters.
If you use once_per_light, you should also add an environmental rendering path in the technology before this rendering path. Otherwise, it will not be rendered when there is no light source near this object; this is important even if there is no ambient light in your scenario, because you still want to display the outline of an object.
This property applies only when you use once_per_light, per_light, or per_n_light. It also limits the running of a single type of light source ('spot light source', 'direction light source', or 'spot light '). As shown in the following example, this rendering path will be executed once for each electrical source. This is useful if you can estimate the type of light source to be processed, because it is easy to write a vertex/fragment program. At least one method can be used to process the point light source and the direction light source.
Default: iteration once
Example: A simple fur rendering material script that contains 10 iterations in the second rendering path is used to generate a fur
// GLSL simple Furvertex_program GLSLDemo/FurVS glsl { source fur.vert default_params { param_named_auto lightPosition light_position_object_space 0 param_named_auto eyePosition camera_position_object_space param_named_auto passNumber pass_number param_named_auto multiPassNumber pass_iteration_number param_named furLength float 0.15 }} fragment_program GLSLDemo/FurFS glsl { source fur.frag default_params { param_named Ka float 0.2 param_named Kd float 0.5 param_named Ks float 0.0 param_named furTU int 0 }} material Fur{ technique GLSL { pass base_coat { ambient 0.7 0.7 0.7 diffuse 0.5 0.8 0.5 specular 1.0 1.0 1.0 1.5 vertex_program_ref GLSLDemo/FurVS { } fragment_program_ref GLSLDemo/FurFS { } texture_unit { texture Fur.tga tex_coord_set 0 filtering trilinear } } pass grow_fur { ambient 0.7 0.7 0.7 diffuse 0.8 1.0 0.8 specular 1.0 1.0 1.0 64 depth_write off scene_blend src_alpha one iteration 10 vertex_program_ref GLSLDemo/FurVS { } fragment_program_ref GLSLDemo/FurFS { } texture_unit { texture Fur.tga tex_coord_set 0 filtering trilinear } } } }
Note: Use the GPU program's automatic parameters pass_number and pass_iteration_number to tell the vertex or fragment program the number of rendering paths and iterations.
Point_size
This setting allows you to change the vertex size when rendering a point column or a point sprites column. The Interpolation of this command depends on the point_size_attenuation option-if it is disabled (by default), the dot size is the size of the screen pixel; if it is enabled, it is represented by standardized screen coordinates (the screen height is 1.0 ).
Note: Some devices have an upper limit on the size of supported points-different application interfaces for the same video card may be different! Don't trust the dot size, because those large dots on the screen may be limited to some graphics cards. The maximum pixel range ranges from 64 pixels to 256 pixels.
Format: point_size <size> default value: point_size 1.0
Point_sprites
This setting specifies whether the hardware point sprites rendering of this rendering path is enabled. If it is enabled, it means that a dot column is rendered as a triplet column instead of a column dot rendering. This option is useful if you have used a billboard set and you only need to use points of the same size based on the announcement board. You can also use this attribute in any other DoT column rendering.
Format: point_sprites <on | off> default value: point_sprites off
Point_size_attenuation
Determines whether the point size degrades based on the increase in the visual space distance, and how it degrades. This option is especially useful when you use point sprites because it defines how to reduce the size when away from the lens. You can also disable this option to make point sprites a constant screen size (like a dot), or enable this option to change with distance.
If you enable this option, you only need to provide the last three parameters. The attenuation equation is the point size multiplied by 1/(constant + linear * Dist + quadratic * d ^ 2). Therefore, disabling this option is equivalent to (constant = 1, Linear = 0, quadratic = 0) and standard perspective reduction is (constant = 0, Linear = 1, quadratic = 0 ). The latter assumes that you have specified to enable this option, but the last three parameters are not provided.
Note that the attenuation result should be between the minimum and maximum values of the point size (see the following description ).
Format: point_size_attenuation <on | off> [constant linear quadratic] default: point_size_attenuation off
Point_size_min
Set the minimum value of point attenuation (see point_size_attenuation above. For details, see point_size.
Format: point_size_min <size> default: point_size_min 0
Point_size_max
Set the maximum value of point attenuation (see point_size_attenuation above. For details, see point_size. The value 0 indicates that the maximum value is set to the maximum value supported by the current video card.
Format: point_size_max <size> default: point_size_max 0
Start building with 50+ products and up to 12 months usage for Elastic Compute Service
1 on 1 presale consultation
24/7 Technical Support 6 Free Tickets per Quarter Faster Response
Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.
A comprehensive suite of global cloud computing services to power your business
Payment Methods We Support
