Ogre next learning notes - Day 8
After N days, I almost forgot. Let's recall it first.
Take a look at the descriptions of several cache s in hlms
-
mRenderableCache
This cache contains all the attributes set to the Renderable class and can be evaluated in advance when a data block is allocated to the Renderable class (that is, inside Renderable:: setDatablock). Contains properties such as whether the material has a normal map, whether the mesh has a UV set, and whether the material needs tangents for normal mapping. The main function responsible for populating this cache is Hlms:: calculateHashFor -
mPassCache
This cache contains information about each pass, such as how many lights are in the scene, whether this is a shadow mapping process, and so on. The main function responsible for populating this cache is Hlms:: preparepasphash -
mShaderCodeCache
Contains a unique shader cache (from Hlms template - > actual valid shader code) based on attributes merged from mRenderableCache and mPassCache. However, the two shaders may be identical and therefore may be repeated, which may occur if two attribute combinations eventually produce identical code. Microcode (GPU Program Manager: setsave microcode tocache) can help solve this problem -
mShaderCache
Cache containing PSO. The difference between this and mShaderCodeCache is that PSO requires additional information, such as hlmsmacroblock and hlmsblendblock. For more information required, see HlmsPso
It can be seen that when it comes to the properties of renderable objects, such as pass, shader and PSO (pipeline state object), it is basically the same as the whole rendering pipeline.
It is conceivable that this part is very complex, but as an introduction, the goal is as long as it can distinguish what these objects do and how they come from.
Start with the code and find several cache objects,
typedef vector<HlmsCache*>::type HlmsCacheVec; typedef vector<PassCache>::type PassCacheVec; typedef vector<RenderableCache>::type RenderableCacheVec; typedef vector<ShaderCodeCache>::type ShaderCodeCacheVec; PassCacheVec mPassCache; RenderableCacheVec mRenderableCache; ShaderCodeCacheVec mShaderCodeCache; HlmsCacheVec mShaderCache;
All vector s, there must be a push_back, find these places, add breakpoints and debug.
Found that,
GraphicsSystem::loadHlmsDiskCache called mRenderableCache / mPassCache
LoadHlmsDiskCache is used to speed up loading. We don't use the entire attribute here.
The loadHlmsDiskCache is controlled by the variable mUseHlmsDiskCache. Set this variable to false.
Didn't you find the place? Then delete the file. According to the previously known resource location search method, find the resource location and delete hlmsdiskcache1 bin
Debugging, discovery
Renderable::setDatablock calls mrenderablecache push_ back. It is known that datablock is the material of hlms
Hlms::compileShaderCode calls mshadercodecache push_ back,
The other two are not called? Then search directly.
Hlms::createShaderCacheEntry calls mshadercache insert( it, retVal ); (addshadercode)
Hlms::preparePassHashBase calls mpasscache push_ back( passCache );
At this point, I found it difficult to continue the analysis, involving code details. The several functions involved here are not in the flow chart analyzed before.
In that case, it's time to jump out and no further analysis.
Take a moment and review. After analyzing the general process, I know how to use hlms.
At this time, try to look at the document [Ogre 2.1 Porting Manual].
Look at the catalog first
1. Legal 2. Changes:Objects, Scene & Nodes And ogre1.x Differences 3. Technical Overview Overview of technologies used 4. Compositor I don't know how to translate this thing 5. Instancing GPU instance 6. Threading Multithreading 7. Performance Hints optimization 8. HLMS:High Level Material System HLMS 9. AZDO changes (Aproaching Zero Driver Overhead) I don't know what 10. The Command Buffer gpu command buffer
It is necessary to read this document completely.
The following is a part of the general content. You can read it for yourself.
1 2. Modifying: objects, scenes, and nodes 2.1 The name is now optional The name no longer needs to be unique and optional. You cannot find objects by name, otherwise there will be bug. 2.2 How to debug MovableObject(Node)Data All relevant data to be updated in each frame are displayed in SoA Form (array structure) storage, not AoS(Structure (array). For example, suppose there are four objects A,B,C,D,The data structure is based on A B C D = {A.x B.x C.x D.x,A.y B.y C.y D.y, A.z B.z C.z D.z } It is stored in a format, not ordinary A B C D ={A.x, A.y, A.z} {B.x, B.y, B.z} {C.x, C.y, C.z} {D.x, D.y, D.z} This is because it uses SIMD(Single Instruction, Multiple Data / Single instruction multiple data). In this way, the properties of four objects can be calculated at one time, which can improve performance. be similar to gpu. However, debugging is troublesome because it is not one-to-one and needs to be passed index To find its data. annoying! The null pointer is replaced by a pseudo pointer. Due to the special data storage format, in mParents See in null Maybe bug? 2.3 Attach and visibility stay Ogre 1.x When an object is attached to the final parent node root When the scene node is selected, the object"In the scene". Therefore, the detached entity is never displayed, and when attached, it is called setVisible(false)It will be hidden. stay Ogre 2.x Objects are always in"In the scene". Nodes only save position information and can be animated, And can inherit the transformation from its parent node.When an entity is no longer associated with a node, It hides itself (implicitly called) setVisible(false)To avoid rendering without location. Multiple entities can share the same location and therefore have the same nodes. In addition/Separate to/separate SceneNode Time, MovableObject::getVisible The previous value of will be lost. Also, called at detach time setVisible( true ) Is illegal and can cause a crash. 2.4 connect/Separation is more expensive than hiding because Ogre 1.x In traversal SceneNodes(also called Scene Graph)The speed is very slow, Some users recommend detaching their objects or deleting them from their parents SceneNode, Instead of calling setVisible(false);Unless otherwise stated in the official documents. stay Ogre 2.x In, we made great efforts to keep updating and iterating as quickly as possible. This may in turn increase the number of additions/The cost of deleting nodes and objects. Therefore, use setVisible Hiding objects is orders of magnitude faster than destroying them (unless they must be hidden for a long time) 2.5 All movable objects require one SceneNode(Lights and cameras) No more nodeless lights exist. 2.6 Get derived transform For performance reasons, location dirty Flag deleted( debug Exists for assertion only), So it is called directly after setting the position sceneNode->_getDerivedPosition();. The data obtained may be wrong. Unless you modify the engine!! If you do not want to change, you can call * Node:_getDerivedPositionUpdated * Node:_getDerivedOrientationUpdated * Node:_getDerivedScaleUpdated Forced updating of data is slow, and it is not recommended to use it in large quantities. MovableObject's world Aabb & radius It's the same design. 2.7 Static scene/Dynamic scene MoableObject and Node When creating, there is a mark to indicate whether it is static, Static represents objects that are not updated or are not updated frequently. The setting properties of static objects will not be automatically updated and need to be called SceneManager: : notifyStaticDirty. Changing a single static object causes multiple static objects to be modified at the same time. Can pass setStatic Change state at run time, except InstancedEntity. 2.8 Ogre Assertion in debug mode mCachedAabbOutOfDate or mCachedTransformOutOfDate If "mCachedAabbOutOfDate"or"mCachedTransformOutOfDate" Assert, They mean AABB Not updated, but attempted to use, or the derived transformation is obsolete and attempted to use it; 2.9 Custom classes derived from renderable or movable objects stay Ogre 1.x Medium and advanced users can directly RenderQueue Submit or inject RenderQueue, Without MovableObject. Because of redundancy (both classes copy the same data), perhaps Renderable Using virtual functions from MovableObject Query data (Advanced users can reload to submit this data directly instead of relying on MO). because Ogre 2.x; Renderable There must be one MovableObject Link to it, because RenderQueue of addRenderable The function requires two arguments, One for MovableObject,The other is for Renderable. Provide null pointer as MovableObject May cause a crash. Multiple renderable objects can still share the same MovableObject,And the implementation does not have to derive from both. For objects that are part of the scene, Ogre 1.x Use visitor mode to query MovableObject Contains all renderable objects. stay ogre 2.x In, this mode has been deleted. Implementation from MO Derived from its own class Ogre User must fill in MovableObject::mRenderables vector; SceneManager This channel is accessed directly to add renderable objects to the RenderQueue. The reason behind this change is performance. Visitor mode is too expensive for this task. 2.10 How to start a new v2 Mesh Class? 2.11 How do I set the element offset, the source of the vertex buffer, and the index? 2.12 My scene looks too dark or dull! Check if gamma correction is being used Switch to PBS It is a common misconception that the pipeline does not expect everything to work as is. Material parameters may need to be carefully adjusted. 2.13 Gamma correction is activated, but GUI The texture is gone HlmsTextureManager Diffuse textures with gamma correction will be loaded to avoid this problem. However, if you load them externally (that is, using the regular TextureManager;for example CEGUI),. They need to be loaded explicitly and gamma corrected. 3. Technical overview 3.1 summary ArrayMemoryManager Is used for processing SoA The basic abstract system of memory. 3.1.1 SIMD uniformity use SSE2 Single precision, OGRE Typically, four nodes are processed at a time/Entity. However, if there are only 3 nodes;We need to allocate memory for four of them 3.2 Memory manager usage mode ArrayMemoryManagers Use the concept of slots. When a node requests a transition, it requires a slot. stay SSE2 In this version, four slots form a block. How many slots are needed to make a block depends on the macro ARRAY_PACKED_REALS Value of. 3.2.1 clear 3.3 Memory pre allocation 3.4 Configure memory manager 3.5 RenderTarget::update Where? Why am I here Viewports Error received in? Advanced users may be accustomed to low-level operations of rendering targets. Therefore, they are used to setting up their custom viewports and calling RenderTarget: : update. This is too low. Instead, users are now encouraged to set up compositor nodes and multiple workspaces to perform multiple RT Rendering of, Even if it's for your own custom content. The new synthesizer is much more flexible than the old one (which has been deleted). For more information, see the section about compositor. Viewports are no longer associated with cameras because they are now stateless (they are used to cache the camera currently in use), And many settings they have saved (such as background color, clear setting, etc.) have been moved to the node. see also CompositorPassClearDef and CompositorPassClear. RenderTarget::update Disappeared because the render scene update has been divided into two phases: culling and rendering. If you still insist on using low levels, see CompositorPassScene::execute Code on, Learn how to prepare RenderTarget And render it manually. But again, we insist that you should try synthesizer. 3.6 1.x Migrate to 2.x 3.7 From 2.0 Migrate to 2.1
It's too long to write.
From these contents, we can know that the contents in the document are very important. You should read it carefully.
Don't want to translate, lazy!