Experience in using hardware buffers and buffer locks at, September 18
1: Because the fastest and best buffer is naturally created through the hbu_static_write_only type, no backup cache is created, and only one hbl_discard Lock operation will never be performed on the buffer.
2: When we need to frequently update the buffer, we can use hbu_dynamic_write_only to create it. If we do not want to create a backup cache, we will use hbl_discard to lock it. If we do not want to update all the data, we will use hbl_no_overwrite.
3: If we have to read data from the buffer, we can create a backup buffer and lock it with hbl_read_only. If possible, try to declare the buffer as static.
4: When we need to use different modes for different elements of the vertex, we should not update all the vertex structures of the buffer through a large number of pointers. We should update them in parts. For example, if we only need to update the texture cursor information frequently, we should save the texture coordinate information in a separate buffer zone, other infrequently updated elements are split and stored in the hbu_static_write_only buffer.
· Vertex buffer
Vertexdata has several important members:
· Vertexstart vertex start position
· Vertexcount vertex count
· Vertexdeclaration: a pointer to the number of vertex data
· Vertexbufferbinding a pointer pointing to the vertex buffer binding
In the vertex type description, we need to emphasize a sequence problem. To support versions earlier than DX9, We need to declare and save data in the following order:
1: vertex position information
2: vertex binding weight
3: vertex normal information
4: vertex ambient light color information
5: vertex mirror color information
6: vertex texture coordinate information
In addition to the above sequence, we also need to note that there is absolutely no gap in the vertex buffer.
After we create a vertex buffer, we also need to bind it to the specified resource.
The format is as follows: verterbufferbinding-> setbinding (0, vertexbuffer );
Then, we bind the vertex buffer during the runtime, and update and fill in the information cyclically. The Ogre provides the length of the interval and the starting point between the adjacent points, so that we can update the data.
· Index Buffer
It is basically the same as the vertex buffer. Update after creation. The only difference is that some attributes are different during creation.
· Pixel Buffer
Here we save the texture pixel information. However, unlike the vertex buffer and index buffer, we cannot manually create a pixel buffer. The Pixel Buffer is automatically created only when we create a texture.
Texture Types supported in the Pixel Buffer:
Tex_type_1d one-dimensional texture, indexed by 1D texture coordinates
Tex_type_2d texture, Which is indexed by 2D Coordinate
Tex_type_3d 3D texture, Which is indexed by 3D Coordinate of Arts and Sciences
Tex_type_cube_map Cube Six surface textures of the object, which are indexed by 3D textures.
Memory Allocation format of the Pixel Buffer
The image data information in ogre is encapsulated in pixelbox objects. Note that pixelbox itself is stored in the GPU, but the real textures are saved in the memory, not in GPU. The pixelbox In the GPU stores the description of the pixel format and location information in the memory. However, pixelbox does not have the memory management function. It can only operate data through the stored memory pointer. The pixel box provides a method to index pixels by depth, height, and width. If one-dimensional textures have no height or depth, fill in the parameter 1. As follows: (width, 1, 1), two-dimensional texture (width, height, 1)
Pixel Buffer update
Ogre provides two methods to update the pixel buffer.
1: manually create a texture and put an image into the texture. We can: Code Image IMG; img.load(“xxx.jpg "," General "); texture ptex = texture: getsingleton (). createmanual (.... ); Ptex-> getbuffer (0, 0)-> blitfrommemory ();
2: Lock a Pixel Buffer and read and write it.
Buffer-> lock (harewarebuffer: hbl_discard );
Const pixelbox & Pb = buffer-> getcurrentlock (); // process the lock
For (INT I = 0; I <Pb. getwindth (); ++ I)
{
For (Int J = 0; j <getheight (); ++ J)
{
Static_cast <unit32 *> (PB. Data) // obtain the data and process it as needed.
}
}
Buffer-> unlock (); // remember to unlock it.
6: External texture source
· Definition.
We read a texture, usually from a graph file in the format of .jpg.png.bmp, but sometimes we need to read from Avi. MPEG and other movie format files, FLV files, read textures from the source generated by real-time rendering. These channel sources are called external texture sources.
· Process external texture sources.
How do we deal with external texture sources? Ogre itself is not written. However, it provides method interfaces so that we can write out the required plug-ins.
· Compilation of external texture source plug-ins
The plug-in we built must inherit from the externaltexturesource class. It provides a general framework. In addition, you can use the functions in the externaltexturesourcemanager class to obtain the external texture source. Typical functions can be as follows: advancetexturemanager: getsingleton (). getcurrentplugin ()
-> Createdefinedtexture (smaterialname );
· External texture source script
Material example/myvideoexample
{
Technique
{
Pass
{
Texture_unit
{
Texture_source video
{
Filename mymovie. Avi
Play_mode play
Sound_mode off // Note: These attributes are different and different depending on the plug-in.
}
}
}
}
}
7: Shadow
· Start shadow
1: by default, the shadow is disabled. To use the shadow, the Shadow must be valid, and this operation must take precedence over the shadow. Whether to enable the shadow will affect the model reading method. For example:
M_scenemgr-> setshadowtechnique (shadowtype_stencil_additive); // enable a template shadow.
2: Disable some light sources that do not support shadow. (Some light sources do not support projection)
Light: setcastsshadow (false)
3: close objects that do not require shadow. (Some transparent objects may not need projection)
Movableobject: setcastsshadow (false)
4: set the maximum distance of the projection. (For performance considerations, you need to set)
5: close objects that do not need to accept shadows. (Transparent materials, self-emitting materials are usually not capable of receiving projections)
Material: setreciveshadow (false)
8: Animation
By default, ogre supports four types of script animation.
1) bone animation. Use a skeleton structure to define grid data.
A) the bones and animation information of ogre are saved in the script file of. Skeleton.
B) when performing an animation operation, we need to create an object called the animation state to control the animation state. We can use entity: getanimationstate () to obtain a pointer to the animation state. Then, we can use the animation state pointer to update the animation in the framestarted time.
2) vertex animation. Store the vertex snapshot to determine how the grid data changes.
3) scene node animation. Based on the pre-defined path, the object attached to the scene node is moved to produce an animation.
A) we can create a corresponding nodeanimationtrack for each scenenode.
4) numeric animation. Use the animableobject class of the Ogre interface to inherit the extension. In this way, you can customize its object attributes.
