ogre-next 学习笔记 - Day 8

最新推荐文章于 2024-05-16 09:43:47 发布

頖╃縌 ①oO%

最新推荐文章于 2024-05-16 09:43:47 发布

阅读量2.2k

点赞数 1

分类专栏： # ogre-next 学习笔记文章标签： ogre 游戏引擎 ogre-next

本文链接：https://blog.csdn.net/weixin_43859510/article/details/122527118

版权

ogre-next 学习笔记专栏收录该内容

8 篇文章 8 订阅

订阅专栏

ogre-next 学习笔记 - Day 8

时隔N天，都忘得差不多了，先回忆一下。

看看 hlms 几个cache的描述

mRenderableCache
此缓存包含设置给可渲染类的所有属性，并且可以在为可渲染类分配数据块（即在Renderable:：setDatablock内部）时提前对其进行计算。包含诸如材质是否具有法线贴图、网格是否具有UV集、材质是否需要切线进行法线贴图等特性。负责填充此缓存的主要函数是Hlms:：calculateHashFor
mPassCache
此缓存包含每个pass的信息，例如场景中有多少灯光，这是否是阴影贴图过程等。负责填充此缓存的主要函数是Hlms:：preparePassHash
mShaderCodeCache
包含基于从mRenderableCache和mPassCache合并的属性的唯一着色器缓存（来自 Hlms模板->实际有效着色器代码）。然而，两个着色器可能完全相同，因此可能会重复，如果两个属性组合最终生成完全相同的代码，则可能会发生这种情况。 Microcode（GpuProgramManager:：setsavemicrocodetocache）可以帮助解决这个问题.
mShaderCache
包含PSO的缓存。这与mShaderCodeCache之间的区别在于，PSO需要额外的信息，例如HlmsMacroblock, HlmsBlendblock。有关所需的更多信息，请参阅HlmsPso

可以知道的是涉及到可渲染对象属性，pass，shader, PSO（管线状态对象），也就基本等同与整个渲染管线了。

这部分可以想象的是很复杂，但是，作为入门，目标只要能分清这几个对象是干嘛的，怎么来的就可以了。

从代码入手，找到几个cache对象，

    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;

都是vector，必然就有 push_back，找到这几个地方，并加入断点，调试。
发现，
　GraphicsSystem::loadHlmsDiskCache 里调用了 mRenderableCache / mPassCache.
　LoadHlmsDiskCache 为了加快加载速度。在这里我们就不使用整个属性。
在 loadHlmsDiskCache 由变量 mUseHlmsDiskCache 控制。将这个变量设置为false。
竟然没有发现设置的地方？那就把文件删掉吧。按照之前已知的资源位置查找方法，找到资源位置，删除 hlmsDiskCache1.bin
调试，发现
　　Renderable::setDatablock 调用 mRenderableCache.push_back。已知datablock就是 hlms的材质.
　　Hlms::compileShaderCode 调用 mShaderCodeCache.push_back，
其他两个没有调用？那就直接搜索吧。
　　Hlms::createShaderCacheEntry 调用 mShaderCache.insert( it, retVal );(addshadercode)
　　Hlms::preparePassHashBase 调用 mPassCache.push_back( passCache );

到这里，发现继续分析已经很吃力了，涉及到代码细节。这里涉及的几个函数，都没有在之前分析过的流程图中。

既然如此，就该跳出来了，不再深入分析。

花点时间，回顾一下。分析过大体流程，知道了如何使用 hlms。

这个时候，尝试去看一看文档【Ogre 2.1 Porting Manual】。

先看看目录

Legal
Changes:Objects, Scene & Nodes
与ogre1.x不同之处
Technical Overview
使用的技术概述
Compositor
这玩意儿不知道咋翻译
Instancing
GPU instance
Threading
多线程
Performance Hints
优化
HLMS:High Level Material System
HLMS
AZDO changes (Aproaching Zero Driver Overhead)
不知道啥玩意儿
The Command Buffer
gpu command buffer

很有必要把这个文档完全看一遍。

以下是一部分大致内容，完整的各位自己看了。

1
2 修改：对象、场景和节点

名称现在是可选的
名称不再需要是唯一的，并且是可选的。不能通过名称查找对象，否则会有bug。
如何调试MovableObject(Node)的数据
每帧需要更新的所有相关数据都以 SoA 形式（数组结构）存储，而不是 AoS（结构数组）.
例如，假如有4个对象的A，B，C，D，数据结构是以
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 }
的格式存放，而不是普通的
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}
这是因为它使用了SIMD（Single Instruction, Multiple Data / 单指令多数据）.
通过这种方式，一次性可以计算4个对象的属性，可以提高性能。类似于gpu。
但是调试起来就麻烦了，因为不是一一对应的，需要通过index来找到它的数据。好烦！
通过伪指针代替空指针。由于特殊的数据存放格式，在 mParents里看到null可能是bug？
附加和可见性
在 Ogre 1.x 中，当一个对象附加到最终父节点是 root 的场景节点时，该对象"在场景中"。因此，分离的实体永远不会显示，并且在附加时，调用setVisible（false）将隐藏它。
在 Ogre 2.x 中，对象始终位于"场景中"。节点仅保存位置信息，可以进行动画处理，并且可以从其父节点继承转换.当实体不再与节点关联时，它会隐藏自身（隐式调用 setVisible（false）以避免在没有位置的情况下呈现。多个实体可以共享同一位置，因此具有相同的节点。在附加/分离到/分离 SceneNode 时,MovableObject::getVisible 的先前值将丢失。此外，在分离时调用 setVisible（ true ）是非法的，并且会导致崩溃.
连接/分离比隐藏更昂贵
由于 Ogre 1.x 在遍历 SceneNodes（又名 Scene Graph）时的速度很慢，
一些用户建议分离其对象或从其父级中删除 SceneNode，
而不是调用 setVisible（false）;尽管官方文件另有说明。
在 Ogre 2.x 中，我们付出了巨大的努力来尽可能快地保持更新和迭代。
这可能反过来增加了添加/删除节点和对象的开销。
因此，使用 setVisible 隐藏对象比销毁对象快几个数量级（除非它们必须隐藏很长时间）
所有可移动对象都需要一个 SceneNode（灯光和摄像机）
不再有无节点灯光存在。
获取派生变换
为了性能考虑，位置的 dirty 标志被删除（debug存在，只用来断言），所以设置完位置直接调用 sceneNode->_getDerivedPosition（）；获取的数据可能是错的。除非自己修改引擎！！如果非要更改可以调用
- Node:_getDerivedPositionUpdated
- Node:_getDerivedOrientationUpdated
- Node:_getDerivedScaleUpdated
强制更新数据，速度慢，不建议大量使用。
MovableObject’s world Aabb & radius 是一样的设计。
静态场景/动态场景
MoableObject和Node在创建时都有一个标示是否是静态的，静态的表示不会更新或者不会经常更新的对象。静态对象的设置属性不会主动更新，需要调用 SceneManager::notifyStaticDirty。更改单个静态对象会导致多个静态对象同时被修改。
可以通过setStatic在运行时改变状态，除了 InstancedEntity。
Ogre 在调试模式下断言 mCachedAabbOutOfDate 或 mCachedTransformOutOfDate
如果 “mCachedAabbOutOfDate"或"mCachedTransformOutOfDate” 断言，
它们意味着AABB没有被更新，但被尝试使用，或者派生的转换已经过时并尝试使用它;
从可渲染或可移动对象派生的自定义类
在 Ogre 1.x 中，高级用户可以直接向 RenderQueue 提交或注入 RenderQueue，而无需 MovableObject。因为存在冗余（两个类都复制了相同的数据），或者 Renderable 使用虚拟函数从 MovableObject 查询数据（高级用户可以重载以直接提交此数据，而不是依赖于 MO）。

由于 Ogre 2.x; Renderable 必须有一个 MovableObject 链接到它，因为 RenderQueue 的 addRenderable 函数需要两个参数，一个用于 MovableObject，另一个用于 Renderable。
提供空指针作为 MovableObject 可能会导致崩溃。多个可渲染对象仍然可以共享相同的MovableObject，并且实现也不必同时从两者派生。对于属于场景一部分的对象，Ogre 1.x 使用访客模式来查询 MovableObject 包含的所有可渲染对象。在ogre 2.x中，此模式已被删除。实现从 MO 派生的自己的类的 Ogre 用户必须填充 MovableObject::mRenderables vector;SceneManager将直接访问该通道，以将可渲染对象添加到 RenderQueue。

此更改背后的原因是性能。访问者模式对于此任务来说成本太高。
如何从新的 v2 Mesh 类中获取顶点信息？
如何设置元素偏移量、顶点缓冲区的源和索引？
我的场景看起来太暗或沉闷！
检查是否正在使用伽马校正
切换到PBS管道并期望所有内容仍按原样工作是一个常见的误解。材质参数可能需要认真调整。
激活了伽玛校正，但GUI纹理不见了
HlmsTextureManager 将加载具有伽玛校正的漫反射纹理以避免此问题。
但是，如果您通过外部方式加载它们（即使用常规的TextureManager;例如CEGUI），.
则需要显式加载它们并进行伽马校正。

3 技术概述

概述
ArrayMemoryManager 是用于处理 SoA 内存的基本抽象系统。
- SIMD一致性
  使用SSE2单精度，OGRE通常一次处理4个节点/实体。但是，如果只有3个节点;我们需要为其中4个分配内存
内存管理器使用模式
ArrayMemoryManagers使用插槽的概念。当节点请求转换时，它要求一个槽.在 SSE2 版本中，4 个插槽构成一个块。制作一个块需要多少个槽取决于宏ARRAY_PACKED_REALS的值。
- 清理
内存预分配
配置内存管理器
RenderTarget::update在哪里？为什么我在Viewports中收到错误？
高级用户可能习惯于渲染目标的低级操作。因此，他们习惯于设置其自定义视口并调用 RenderTarget：：update。这太低了。相反，现在鼓励用户设置合成器节点和多个工作区以执行对多个RT的渲染，即使它是针对您自己的自定义内容。新的合成器比旧的合成器（已被删除）灵活得多。有关详细信息，请参阅有关合成器的部分。

视口不再与摄像机相关联，因为它们现在是无状态的（它们用于缓存当前正在使用的摄像机），并且它们曾经保存的许多设置（如背景颜色，清晰设置等）已移至节点。请参阅CompositorPassClearDef和CompositorPassClear。

RenderTarget::update已消失，因为渲染场景更新已分为两个阶段：剔除和渲染。如果您仍然坚持使用低级别，请参阅CompositorPassScene::execute上的代码，了解如何准备 RenderTarget 并手动渲染它。但同样，我们坚持认为您应该尝试合成器。
1.x 移植到 2.x
从2.0移植到2.1