做影视后期应该关注哪些网站,oa网站模板,网站运营教程,上海建筑公司排名回顾并为今天的工作做准备
我们今天继续昨天开始的工作#xff0c;现在我们要回到渲染中处理 Z 值的最终环节。我们目前已经有一个我们认为还算合理的排序方式#xff0c;虽然可能还需要在接下来的过程中进行一些调整#xff0c;但总体上已经有了一个明确的方向。
我们已经…回顾并为今天的工作做准备
我们今天继续昨天开始的工作现在我们要回到渲染中处理 Z 值的最终环节。我们目前已经有一个我们认为还算合理的排序方式虽然可能还需要在接下来的过程中进行一些调整但总体上已经有了一个明确的方向。
我们已经开始草拟出一些接下来的任务这很可能会是我们下周的主要工作。不过今天也不能浪费时间能推进多少就推进多少。昨天我们已经开始试着实现现在可以开始真正深入推进把自己放在一个更好的位置为下周的完成打下基础。
接下来的过程其实没有什么特别神奇的东西。我们只是要根据现在对 Z 值处理的明确认知把之前为了摸索而写下的内容进行整理和清理。之前的做法比较杂乱是因为艺术风格、代码实现等多方面因素影响了我们对 Z 值如何工作的判断。但现在我们已经清楚地知道了 Z 值的职责是什么也知道了我们希望它如何发挥作用。
因此我们要做的是整理整个渲染流程中的 Z 值处理逻辑确保它是清晰、统一且健壮的。否则后续继续在这种不稳定的系统上构建会出现很多潜在的问题比如表现不一致或者难以调试的问题。我们希望最终能达到这样一种状态对于 Z 值的使用我们有清晰的理解和信心不再出现“为什么会这样”的疑惑。
过去在开发过程中我们多次调整 Z 值的处理方式尝试不同的策略遇到问题就修改然后再试。这些过程是必要的学习阶段是摸索方向的一部分。但现在我们已经走出了那个阶段进入到需要把所有东西整理清楚、稳定下来的时候了。
我们要做的就是清理原本那些零散、不一致的处理方式让整个 Z 值系统在渲染层是干净、明确、可预期的。这样在后续开发中我们就不必反复质疑其行为或逻辑也不会被过去的临时实现困扰。我们需要的就是一个可靠的基础系统然后就可以毫无顾虑地在其上构建更多功能。
运行游戏查看当前进展
我们现在继续昨天的工作主要是处理和楼梯相关的渲染问题。可以看到在处理楼梯间时通往上层的楼梯并没有被正确地包含在底层的渲染中。这说明我们在处理 Z 值的时候整个流程还不够一致和清晰。
问题的根源在于我们没有系统地跟踪 Z 值。我们并没有从逻辑上根据所在区块来计算 Z 值。我们已经决定Z 轴上的区块chunk应该对应于每一层楼——也就是说同一层楼的所有内容应该处于同一个 Z chunk 中。这样渲染的时候才能将同一层的元素作为一个整体进行处理。
接下来要做的第一件事就是让每个 chunk 的 Z 值真正被用在渲染中。当前我们虽然有传递 chunk 的概念但实际上渲染系统中并没有用这些 Z 值进行层级划分。我们需要修复这一点让 chunk 的 Z 值真正参与渲染逻辑使得每一层楼被当作一个独立的渲染切片slice处理。
此外当前的渲染系统只是把所有东西混在一起然后依赖排序规则进行排列。而我们的排序规则本身也并没有设计成处理这种多楼层的情况。这种混合处理是不对的我们需要明确地区分不同层的数据并作为单独的切片传入渲染流程中。
我们要做的第二件事就是让渲染系统开始认识这些不同的切片让它们分层传入并进行单独处理而不是像现在这样全部混在一起后依赖排序算法“勉强”处理。
总体思路如下
首先修正 chunk 的 Z 值处理确保每一层楼被正确分配一个 chunk且 chunk 的 Z 值能被渲染系统识别并利用。然后让渲染系统以“切片”的形式分别接收这些按层划分的数据。最终要让排序系统明确知道这些层级是怎么工作的避免不明确或错误的层间混合渲染。
通过这些步骤我们就能让渲染流程在处理多楼层内容时更合理、更清晰、更可靠。现在我们开始动手。
修改 game_entity.cpp停止 UpdateAndRenderEntities() 调用 ConvertToLayerRelative()改为按昨天讨论的方法计算 RelativeLayer
我们现在在处理广义相对性的位置转换逻辑也就是之前一直使用的 ConvertToLayerRelative。这个方法之前用于确定某个物体在 Z 轴上的位置。但现在我们不再想沿用这种基于相机视角差异来决定图层的方式因为我们不再对图层做透视变换所以这种依赖相机 Delta 的方式已经不适用了。
我们真正需要的是基于“chunk Z 值”的图层逻辑。我们已经开始在代码中明确了这一点比如写下了注释说明现在我们关注的是 chunk Z 值的差异它决定了图层的高低而不再关注相机的位置偏移。
问题在于目前我们在执行重新打包repack之前还无法准确知道某个实体的 chunk Z 值。也就是说WorldPosition 这个值在当前阶段并不可信因为我们还没确定目标位置在哪个 chunk。换句话说我们移动了某个实体但在进行重新打包之前我们还不知道它的新 chunk Z 值应该是多少。
虽然在重新打包的阶段我们是可以计算出来的比如在打包函数中我们会根据实体的位置重新计算对应的 chunk这时候我们确实能够知道 Z 的差异。但是我们现在还没进入这个阶段。
因此我们必须审视代码的执行顺序尤其是在区域数据region内的行为。我们可以看到当我们真正进行“打包实体进世界”这个操作时比如调用 PackEntityIntoWorld 的时候代码中确实传递了实体的 WorldPosition也就是位置信息。
进一步查看可以发现 PackEntityIntoWorld 是在 EndSim 的时候被调用的意味着在模拟结束阶段我们会把所有实体重新打包。并且在 PackEntityIntoWorld 中会根据实体的位置来计算它所在的 chunk这个计算过程包括图块映射与坐标平移。
虽然这种做法会导致在某些地方重复计算 chunk 的代价略高但当前阶段我们还没有更好的解决方案。当然也可以考虑将计算出来的 chunk 信息缓存到实体中以便后续重用这部分我们可以留个 TODO将来优化时考虑。
总的来说当前任务核心内容如下
不再使用基于相机 Delta 的 ConvertToLayerRelative 方法图层信息应当由 chunk Z 值来决定这样才能与我们每层楼一个 chunk 的设计相匹配当前在重新打包实体前无法得知它准确的 chunk Z需要等待进入打包流程才能得出PackEntityIntoWorld 是我们当前依赖的处理过程它在 EndSim 阶段执行内部根据 WorldPosition 计算 chunk尽管存在一定的计算重复但可以通过后续缓存优化当前阶段的目标是让逻辑流程保持清晰让每个实体的图层归属可以通过 chunk Z 来可靠判断为后续渲染处理打下基础。 修改 game_entity.cpp让 UpdateAndRenderEntities() 通过 MapIntoChunkSpace() 获取 WorldPos 来计算 RelativeLayer
我们现在考虑的问题是如何在已知某个 chunk例如 chunk C的情况下获得实体在该 chunk 中的相对位置entity P。实际上我们并不一定需要保存这个转换的结果仅仅在需要计算时进行一次转换就足够了。
举个例子我们可以简单地调用一次 MapIntoChunkSpace直接将实体的世界位置转换为 chunk 空间下的位置。虽然从逻辑上讲我们可以不保留中间结果但实际上我们很可能还是需要知道这个转换所产生的偏移量offset因为后续我们可能要利用这个偏移量做进一步处理所以我们可能还是会保留这个值。
因此我们可以这样处理将世界位置 WorldPosition 传入 MapIntoChunkSpace这时就能获得在 chunk 空间下的位置例如 WorldPoster从而得知实体当前所处 chunk 的 Z 值。在物理模拟步骤之后实体已经被移动到新位置此时再执行这一转换操作就能知道它的新图层relative layer。
这样我们就可以获得准确的图层索引这是非常重要的信息。
不过接下来还有其他问题需要考虑。我们还需要为这个实体设置用于渲染的“身份变换矩阵”identity transform用于对 Z 值进行合适的偏移处理以确保实体在 Z 轴上被正确地渲染。因此虽然我们现在已经可以正确计算出相对图层但对于后续渲染的处理还需要额外的步骤。
我们知道实体最终会被绘制在某个具体的位置而这个位置会受到 chunk Z 值的影响所以最终渲染的位置不仅取决于逻辑坐标还取决于图层处理逻辑。我们目前还没有把这些都建立起来因此这部分工作还得继续完善。
目前我们先暂时把这部分逻辑放一边因为其他依赖的部分还没准备好但这显然是我们接下来必须推进的方向。
此外还发现一个小问题我们当前代码中似乎没有 World 的定义或引用看起来像是漏掉了。可能是因为相关模块引用时没有传递 World 实例或者有些代码根本没有用到它所以没人注意。我们推测可能是 WorldMode.World 之类的结构只是没有在当前作用域里建立本地引用。
这个问题虽然不影响当前的主逻辑构思但之后处理实体或渲染环境时还是需要修正确保我们能正确访问世界状态信息。
总结
可以通过 MapIntoChunkSpace 获取实体在 chunk 空间下的位置从中获得 chunk 的 Z 值从而确定实体所在的图层物理模拟之后再执行该计算确保使用的是实体的新位置后续还需要设置 identity transform以处理 Z 偏移实体最终在画面中出现的位置依赖于 chunk Z 的正确处理当前 World 对象没有被本地引用需要检查并修复接下来的重点工作是建立完整的图层渲染流程包括位置变换和正确排序机制。
运行游戏确认状态明显改善
现在整体情况已经明显好转。楼梯间的处理已经完成并且每一层楼的楼梯部分都已经准确地归类到了对应的楼层中位置也符合预期。这是一个重要的进展因为这意味着基础结构已经开始变得清晰和有序。
虽然仍然存在楼层切分的问题目前还没有进行楼层的切片处理因此相关的错误依然存在但这只是下一步需要解决的问题。当前的主要成果是楼层中的元素已经被正确地分配到了各自应在的楼层不再出现混乱或归类错误的情况。
这是第一次整理楼层内容的初步结果虽然还不完整但方向正确。整个结构开始表现出一定的连贯性楼层之间的关系也更为合理不再像之前那样杂乱无章。接下来需要进一步处理的是将每层楼进行实际的切分从而彻底消除现有的切片错误。但总的来看目前取得的进展令人满意已经迈出了关键的一步。
考虑在渲染中引入图层 Z 和实际 Z 值的概念
接下来需要重点处理的是 Z 轴方向的转换部分也就是 z transform 的另一部分这是接下来工作中最复杂的部分之一。因此我们必须开始收紧思路对整个实现方案有一个非常清晰、明确的概念设计特别是在渲染阶段的错误处理、图层管理和 Z 值之间的关系上。
我们需要处理图层layer和实际的 Z 值的关系。具体来说目前的 chunk dim z即每块在 Z 方向上的维度需要作为一个绝对的排序标准被渲染系统感知并使用。为了解决当前的问题可以临时采用一种折中的方案把 Z 层的信息直接嵌入到 sort key排序键中让排序系统以此为依据来进行精确排序。
这种方式虽然是可行的权宜之计但并不一定是最终推荐的做法因为当前的 sort key 结构已经变得非常庞大承载了过多逻辑。虽然目前我们可以继续在其中添加信息来满足开发需求但这并不是一个长久之计迟早我们需要面对复杂度上升所带来的系统开销和维护负担。
目前的重点是先把各部分如何组合的问题理清楚让整个流程跑通。在实现阶段可以允许排序逻辑暂时承担更多的责任比如在 sort key 中嵌入 Z 层信息让排序过程自动把不同层级的数据区分出来。
不过等到最终版本的渲染阶段时我们很可能需要更聪明、更高效的方案。可能会采用将不同图层的数据预先分配到独立的 buffer 中从而避免后期再进行统一排序。这种方式可能在性能和逻辑清晰度上更具优势因此在之后的设计中需要重点考虑是否转向这种结构优化的路径。
修改 game_render.h在 sprite_bound 结构体中添加 ChunkZ
目前虽然还不确定最终方案应该怎么设计但在现阶段由于排序系统已经搭建完成因此可以先提出一个临时性的处理思路。
具体来说可以引入一个类似于 chunk z 的机制。这个 chunk z 会作为一个具有绝对优先级的排序因素存在它的优先级甚至高于人工设定的排序顺序。这意味着在排序过程中只要涉及到 chunk z它就会主导排序行为把相关元素从通用排序逻辑中“抽离”出来优先进行分组排序。
这个机制的核心思想是将 chunk z 作为一种强制的排序层级存在把它看作是一种“排序组”的概念。凡是具有相同 chunk z 值的元素会被归为一组然后在这组内部再根据其他标准进行细致排序。这种方式可以有效地将整个场景在 Z 轴维度上划分成结构清晰的分区使得渲染或处理逻辑能够优先考虑 Z 轴上的分布而不是完全依赖人工设定的顺序或其他混杂条件。
虽然这是一种暂时性的“吸附式”hoover up的解决方案但在当前阶段非常实用可以让系统在没有复杂 buffer 管理和最终结构优化之前依然维持较高的逻辑清晰度和排序准确性。这样既能保证结构分层正确也为后续的优化和系统演化打下良好基础。
修改 game_render.cpp让 IsInFrontOf() 测试 ChunkZ
接下来在实现“是否在前方”的判定逻辑时需要在已有逻辑的基础上引入一个额外的判断条件。这个处理的关键在于排序对比过程中我们现在要处理的是一种更复杂的场景而不仅仅是简单的几何对比。每当我们在进行对象之间的排序比较时逻辑复杂度就会上升因此这部分的设计也变得更加关键。
目前的做法是在排序判断阶段我们可以加入一个新的逻辑分支。这个分支基于 chunk z 的值来进行判断。具体操作是如果参与比较的两个对象其对应的 chunk z 值不相等那么我们就可以直接根据这个值来判断前后关系。也就是说chunk z 值较大的对象会被视为“在前方”从而在渲染中获得更高的显示优先级。
这样一来chunk z 就成为了一个天然的分层依据相当于在所有其他排序逻辑之上先进行一个大范围的分组。只要两个对象处于不同的 chunk z 区域就不需要再进行更细致的空间对比可以直接通过 chunk z 的大小关系来决定谁在前谁在后。
这种分层判断的方式虽然让排序逻辑变得更复杂但它也是必须的。尤其是在对象数量增加、场景变得更加复杂的情况下必须提前意识到哪些部分可能成为性能瓶颈或系统负担点。虽然目前系统中并不会出现成千上万个对象同时出现在屏幕上的情况这在一定程度上给予我们一些“宽容度”但从长远看识别和标记这些潜在风险点仍然是必要的。
总之这种基于 chunk z 的预分层策略能够有效简化部分排序判断同时在逻辑上也有助于构建一个更清晰的图层结构。通过将其视作一种在其他所有排序标准之上的“层级规则”我们就可以自由地将对象归入更宽泛的类别之中从而提高整体系统的可维护性和可扩展性。
修改 game_render_group.h在 object_transform 结构体中添加 ChunkZ
关于渲染分组的实现其实在代码架构层面上并不复杂这部分的逻辑设计非常直接也容易实现。真正让人产生顾虑的并不是实现难度而是更高层次上的系统整体性与性能代价问题。
当前采用的策略虽然可行也能满足现阶段的需求但在心里还是会有所担忧——不是说这条路径是错误的而是担心在系统发展到更复杂或性能要求更高的阶段时这种方案可能存在瓶颈可能会拖慢整体的效率或者变得不易维护。
也就是说现在的实现方案虽然暂时能跑通也逻辑清晰但未来在更高负载或者更大规模的渲染场景中我们可能需要对这些结构重新审视寻找更高效、更优雅的方式。不是说当前不能继续推进而是要有一个心理准备当系统进入后期阶段、功能趋于稳定或规模扩大之后可能必须回头对某些设计做出优化和重构。
因此这些担忧更像是一种预警机制一种对未来可能问题的预留意识。当前阶段继续使用这些方法是可以接受的不存在阻碍开发的风险。但同时也需要在心中标注这些点防止在后续版本中它们演化成更严重的系统问题或对性能产生难以忽视的影响。这样可以避免到时候措手不及而是能够有计划、有节奏地进行调整和优化。
修改 game_render_group.cpp让 GetBoundFor() 设置 ChunkZ
现在我们所做的事情非常简单主要是为了处理手动排序manual sort相关的逻辑。具体来说我们要做的只是确认当前数据中是否存在某个元素并将其关联的 chunk z 值提取出来用于后续的排序判断。
操作上我们所做的就是当找到某个需要排序的对象时直接从对象中提取其对应的 chunk z 值并将这个值用于标记或记录作为后续排序流程中的一部分。这一步确保了我们能够明确地知道这个对象在 Z 轴维度上属于哪个逻辑分层为后续判断“是否在前方”以及具体渲染顺序提供了基础依据。
这种做法本身非常直接目的也很明确就是为后续排序打好基础把对象在 chunk z 上的归属清晰地表达出来避免后续处理时出现混淆或不一致。通过这个操作我们就能确保在进行手动排序时能够与 chunk z 的自动分层逻辑相兼容不会发生矛盾或逻辑冲突。整体流程简单但关键是排序系统和渲染系统保持一致性的必要步骤。
运行游戏确认修改没有影响现有表现
理论上来说这个改动不应该对现有的排序结果产生任何影响因为我们并没有对任何值进行修改或重新设置。执行这部分代码时排序逻辑依旧保持原样所以在实际运行时仍然会看到之前那种奇怪的排序现象。
通过观察可以确认排序结果和之前完全一致说明目前的改动只是做了数据的读取和确认没有改变排序行为本身。这也意味着当前的处理流程正常运行没有引入新的错误同时保留了之前的排序状态方便后续继续调试和优化。
修改 game_entity.cpp让 UpdateAndRenderEntities() 设置 ChunkZ
现在的问题是如果我们主动去修改渲染代码使其真正设置排序键sort key和实体entity会发生什么情况。之前只是读取和确认数据但没有实际更改排序键这次打算尝试把手动排序部分真正生效也就是说让排序键被赋值并用于渲染排序。
通过这样做可以直接观察手动排序对整体渲染顺序的影响验证这种修改是否能够按预期改善或者改变排序结果。这个实验能让我们更直观地看到当前排序机制的实际表现判断这种修改是否可行以及是否需要进一步调整和优化排序逻辑。总之这是一个动态测试用来验证手动设置排序键后系统的反应和效果。
查看该修改如何影响排序
手动排序的部分当我们将实体的变换信息entity transform中的 chunk z 和世界坐标world pos作为排序依据时就形成了一种自动排序机制这个机制会自动生效。经过这种处理后可以直观地看到 Z 轴的排序效果几乎是“免费”实现的整体画面变得更加合理、层次分明排序看起来非常自然物体之间的遮挡关系也更清晰。
不过这里也出现了一个潜在的问题具体影响还不太确定后续版本还需要进一步观察和评估。问题主要出现在楼梯的场景里比如当角色走上楼梯时出现了渲染遮挡上的小瑕疵比如角色应该显示在楼梯顶部某些部分的前面但实际表现上可能没有达到预期。
这部分问题可能并不需要通过改变排序逻辑来解决而更合理的做法可能是在角色移动到楼梯上某个区域后主动将角色的 chunk z 调整到更高的层级。换句话说当角色跨越楼梯的不同“块”时可以将其归类到上一个 chunk从而保证其在视觉上显示在正确的位置。这种策略比较合理也容易实现能够较好地解决角色与楼梯层级的遮挡关系问题。
总的来说自动排序机制基本工作正常带来了良好的层次效果但对于角色与复杂几何体之间的细节遮挡可能需要通过动态调整 chunk 归属来进一步完善。这个方案看起来是个比较合理且可行的解决思路。 修改 game_entity.cpp让 UpdateAndRenderEntities() 扩展 traversables 的边界使其绘制时像真实的瓦片
现在我们尝试的目标是想扩展一下可通行区域的边界bounds以便观察会发生什么变化。说实话对这部分的绘制细节已经没有太多印象了甚至一开始都不确定是哪个部分负责渲染这些可通行区域。看了一下确认是这段代码在处理这些 traversable 区域的绘制。
如果希望让这些区域在视觉上更接近实际游戏中的瓦片tile样式那么我们可以尝试稍微扩展它们的显示方式。这样就能够在角色移动过程中更清楚地看出每一个 tile 的作用和可行走性。
在实际运行中也能更清晰地看到游戏中的可通行结构以及角色在其中的移动轨迹。这个过程中也开始逐渐呈现出一个更接近真实游戏的视觉效果。
但与此同时也发现了一个新的问题在某些地方出现了排序闪烁sorting flicker这可能意味着在渲染过程中出现了深度排序冲突。初步判断这种问题极有可能是由循环依赖导致的排序错误也就是多个对象之间的排序形成了闭环系统无法稳定判断前后关系。
为了验证这一点有必要重新引入调试工具用于确认排序逻辑中是否真的存在循环冲突。同时还需要将调试信息放入一个独立的 chunk 中这样它们在渲染层级上可以总是处于最上层方便观察和调试。
这不仅可以帮助修复当前的排序闪烁问题同时也能为后续可能遇到的类似问题提供一个清晰可控的观察入口。总之当前阶段的改动虽然小但却暴露出系统中深层次的排序逻辑挑战需要进一步验证并加以优化。 运行游戏思考场景切换问题
现在可以明显看到出现了严重的排序循环问题cycling导致画面中出现非常糟糕的闪烁现象。这种问题很可能是由于当前的重叠检测逻辑过于宽泛判定了许多实际并不真正重叠的对象之间存在遮挡关系。
虽然这些元素之间的重叠非常微弱但在当前的系统中哪怕是边缘上的极小接触也会被判定为存在深度关系从而被强行纳入排序比较中。这就导致了一种“伪重叠”的排序逻辑最终形成大量不必要的图元之间的排序关系进一步引发了闭环依赖和排序循环。
考虑到这一点或许一个改进的方向是在进行重叠检测之前适当缩小物体的边界范围。也就是说不使用实际的完整边界进行比较而是对每个物体的包围盒略微进行收缩从而避免那些仅仅在边缘轻微重叠的对象被误判为存在遮挡关系。
从直觉上来说这应该是一个非常有效的优化策略因为许多目前被系统判定为需要参与排序的对象在视觉上其实并没有真正发生可感知的遮挡。如果能过滤掉这些“几乎不重叠”的情况就可以大幅减少排序系统中的无效比较从而降低循环发生的概率提高整体排序的稳定性和效率。
另外也注意到在某些角度比如角色靠近一些树木或场景边缘的时候会出现树木闪烁的问题可能也是由于同样的循环排序导致的遮挡不确定性。这种现象一旦出现就意味着当前排序图中存在大量的环路。实际上令人惊讶的是在存在如此多的排序环时系统仍然能在大多数情况下保持运行稳定说明基础排序机制具有一定的鲁棒性但这种状态显然是不可持续的。
因此下一步应当重点考虑对重叠检测逻辑进行优化从“边界缩小”入手有望在不大幅更改排序结构的前提下显著提升渲染表现和用户体验。
修改 game_render.cpp在 BuildSpriteGraph() 中缩小传入 RectanglesIntersect() 的尺寸
现在我们开始关注排序过程中的重叠检测overlap test尤其是“矩形相交”的部分rectangles intersect思考它在逻辑层面上的实际行为以及我们是否可以通过某种方式改进它以减少排序错误或循环的出现。
具体来说我们对当前的重叠判断逻辑产生了兴趣想了解当我们在执行矩形相交检测时若对矩形进行一些缩小操作比如将其边界收缩4个像素最终会产生怎样的效果。这是出于一种优化直觉通过略微收紧物体边界过滤掉那些边缘接触的伪重叠从而减少不必要的排序干扰。
当前的矩形相交逻辑是集中在平台相关的谓词模块platform-specific predicates中定义的所以得去那里查看或修改这部分的代码。
接下来尝试性的思路是在进行碰撞或重叠检测之前先人为地将两个待比较的矩形边界收缩比如每边收缩4个像素。这相当于人为设置了一个“容差”或“安全缓冲区”排除了那些几乎看不见的边缘接触情况。
这样做的潜在好处是显而易见的
可以显著减少那些在视觉上没有实际遮挡效果的对象之间的排序参与减少排序比较数量降低生成排序图时的复杂度减小排序循环cycle的可能性提升最终的排序结果稳定性减少渲染过程中的闪烁现象。
这个方向的尝试并不需要大幅改动系统结构仅仅是修改了相交检测的边界条件却有可能带来非常直接且明显的排序行为改进因此是一个性价比非常高的优化思路。
因此当前我们着手的重点是将已有的矩形交叉检测逻辑包装进一个带有可控“缩放”参数的版本并实际应用到排序过程中的重叠判断中观察是否能显著改善排序闪烁与环路问题。这个实验将对我们后续优化方向提供重要参考依据。 修改 game_debug.cpp让 DEBUGStart() 设置调试元素的 ChunkZ
我们现在考虑的是是否可以彻底移除排序偏移量sort bias这一机制。
起因是我们目前已经引入了 chunk_z它作为一个明确的、全局性的排序参考值已经足以承担起排序中的层级判断功能。之前 sort bias 是一种临时手段主要用于手动调整物体的前后关系使其在渲染顺序中有所区别但现在随着 chunk_z 的引入与正式使用它已经具备更明确、更绝对的优先级判断意义。
因此我们着手进行了如下思考与操作
直接查看当前是否还有地方在使用 sort bias判断其是否还会对排序产生任何实际影响初步结论是有了 chunk_z 之后再保留 sort bias 显得多余且冗赘于是决定将 sort bias 从系统中完全移除同时在调试系统中也进行相应修改确保不会再引用这个字段后续验证移除 sort bias 后系统的排序行为是否依旧正常特别是可视化效果、物体遮挡关系等是否如预期一致。
总的来说这是一次对系统历史遗留机制的清理优化也是对当前排序逻辑简化和集中化的积极举措。通过移除多余的权重叠加方式我们可以进一步减少系统中的潜在歧义来源使排序系统更清晰、更统一、更易维护。未来如果发现仍有特殊情况需要精细微调排序可以考虑以更通用的方式引入而不是依赖旧的、命名模糊的机制。 运行游戏切换调试组显示
我们现在验证了调整后的调试覆盖显示确实变得更加清晰、美观了。
通过在重叠判断中排除那些只是边缘接触的元素即只“轻微接触”的物体我们成功避免了不必要的排序判断也大幅减少了因排序循环产生的视觉闪烁问题。这种处理逻辑非常合理因为那些几乎没有实质重叠的对象本就不该强行介入排序关系的比较中。实际效果也印证了这个优化的价值 —— 排序更加稳定调试信息也更易观察。
我们当前的系统状态令人满意有几个积极的结果
排除边缘接触的重叠元素后排序循环问题明显减轻原本的视觉闪烁尤其是在 tile 边界处已经被有效解决排序结构整体更加智能化不再因为轻微接触而生成无意义的复杂比较图测试中通过启用 debug group 显示能清楚看到排序关系的调整结果便于确认逻辑正确性排序系统也更具鲁棒性即使存在大量复杂结构也仍能较好维持预期行为。
此外我们也注意到未来仍需处理一项重要问题 —— X轴方向的倾斜skew。当前存在一些非法状态即某些元素发生了不允许的 X 方向倾斜这会导致排序逻辑失效因为现有的排序规则并不能正确处理这种偏斜后的空间投影关系。因此在继续推进系统前还需要对这些异常状态进行清理和纠正确保所有渲染实体都符合排序系统的假设前提。
最后我们还观察了一些高度跳跃判断的逻辑发现系统会自动选择不那么陡峭的落点也就是说它会优先选择下落距离不太大的区域作为落点这一点看起来也是符合预期的。
总之当前我们对系统所处的状态感到满意排序逻辑基本成立调试工具正常工作错误和异常现象显著减少。下一步将集中精力解决倾斜问题并确保后续逻辑构建在一个更清晰、稳定的排序结构之上。
思考如何利用渲染器中的层数据
我们目前通过引入 chunk_z 实现了将所有渲染实体分组的能力完成了对场景中各个对象的层级划分。这为后续的渲染排序奠定了基础。但是到目前为止渲染系统本身还没有真正利用这些分组信息这才是目前的主要问题。
我们早前在渲染管线中实现了剪裁矩形clip rects机制理论上这些剪裁矩形可以用来关联不同的渲染组例如用来处理透明图层alpha group的叠加效果。但目前的结构中各种逻辑交织在一起导致渲染系统还无法真正基于这些剪裁区域或图层信息来合理地处理复杂的渲染层级尤其是透明层。
理想情况下我们希望能将透明层alpha group中的内容单独渲染到一个离屏缓冲区offscreen buffer中最终再将该缓冲区合成回主画面。这就需要渲染系统具备更高层次的上下文感知能力理解哪些对象处于透明图层、哪些不在但目前的架构还不足以支撑这一点。
不过有一个方面我们可以先着手处理那就是**雾效fog**的绘制逻辑。雾效本质上是对不同深度图层的透明度处理而这部分逻辑其实可以从主渲染流程中剥离出来单独处理。我们只需要在绘制时判断当前是否处于 alpha 渐隐层alpha fade layer以及当前层的透明度级别而不必让整个渲染系统理解所有的分组细节例如目前存在的六个 chunk_z 层级。
也就是说大部分这些分组和图层结构其实只是为雾效服务的并非渲染必须要深入理解的内容。所以我们可以优化思路 把雾效处理从渲染器中抽离出来由更高层负责提供 alpha 衰减信息 渲染器只需要关心两件事 当前对象是否属于 alpha 衰减层当前 alpha 层的透明度等级是多少 这样一来渲染系统只需处理“是否做渐隐”和“做多少”的简单问题而不是陷入复杂图层结构的处理。
通过这种方式渲染器逻辑可以保持简单、独立同时我们仍然能够实现正确的层级显示、透明度控制和雾效渲染。这是目前较为理想的解耦路径也有助于未来优化透明图层合成与性能。
修改 game_entity.cpp简化 UpdateAndRenderEntities()只关注 alpha 和雾层级别
我们现在开始处理的问题是简化并改进原先用于雾效fog和透明层alpha layer处理的机制目标是去掉不必要的复杂结构比如 clip_rects并用更直接的方式控制图层效果。
首先我们决定统一使用一个叫做 fog_amount 的变量来表示当前图层的雾效程度。这个值决定了某个层中绘制元素的透明程度fog_amount 0 表示完全不透明fog_amount 1 表示完全透明。这种方式比使用复杂的剪裁矩形和分组结构要直观得多。
我们发现原先的渲染流程中使用了多个剪裁矩形clip rects每个图层一个但其实这些剪裁区域并没有真正被利用起来。事实上渲染逻辑并没有按剪裁层级处理而是根据图层的深度排序。因此我们决定彻底移除与 clip rect 相关的逻辑和数据结构。这些代码虽然存在但并没有带来实质作用反而增加了复杂性。
在实际修改过程中我们进行了以下关键步骤
去除 clip rects 和相关结构包括清理 clip_rect_effects、剪裁层设置、相关计算和使用逻辑保留关键控制参数我们保留了 fog_amount 和 test_alpha但 test_alpha 也准备后续移除重构透明度计算使用 clamp_map_to_range 函数简化透明度的处理逻辑并将它直接映射到 fog_amount统一处理流程只使用一个默认剪裁区域不再有复杂的分层裁剪保持雾效一致性通过直接控制透明度值雾效仍然得以实现但实现方式更清晰、更易维护。
最终效果是原本零散而复杂的图层处理系统被浓缩为一个由 fog_amount 控制的简单机制渲染逻辑也变得更清晰。现在的系统只关注“当前图层的透明度是多少”而不需要关心任何额外的图层裁剪信息。这不仅提升了代码可维护性也为后续优化透明图层的渲染效率打下基础。 修改 game_entity.cpp关闭 Alpha
我们现在开始处理的目标是将实体的色彩处理color blending 或称色盲渲染调整整合到更系统化的流程中而不是像之前那样手动进行操作。
当前我们已经可以设置每个实体的 colorblend 值这个值会影响所有渲染出来的内容。也就是说我们已经有了让实体根据某种设定改变其颜色的机制不过这个机制目前还是手动控制的。
手动控制带来一些问题比如
渲染逻辑不清晰因为是手动指定的有时不容易看清楚具体颜色是怎么被最终决定的一致性差不同部分可能采用不同的色彩处理方式容易出错维护困难每次想要修改整体色彩表现都需要手动找对应代码效率低下。
为了解决这些问题我们考虑将 colorblend 值直接作为变换transform的一部分属性处理。这样一来在颜色校正rectification阶段统一处理实体的颜色调整逻辑就不需要在后续渲染流程中手动应用了。这种方式也和之前曾经试过的方案类似但这次希望将其做得更加干净彻底。
我们开始尝试这个重构思路的初步验证
首先将手动颜色调整部分如 piece_colors 的相关逻辑移除颜色混合的逻辑被整合到了变换流程中在颜色被“修正”或转换的时候统一应用然后通过设置 colorblend 属性来观察最终效果发现上方图块还没有变透明说明 alpha 值并未降为 0这与我们的预期一致因为现在是从统一变换中推导出来的而不再依赖额外的手动透明处理逻辑。
通过这一系列更改
色彩控制逻辑被统一放入实体变换的属性中移除了原先混乱的手动颜色处理代码渲染结构更加清晰、可控色彩的处理更加一致后续实现色盲模式、风格变换等视觉模式也更方便。
目前系统已经能够通过实体自身的属性统一控制其在渲染中的颜色变化达成了更清晰和高内聚的设计目标。后续可继续拓展类似 fog、alpha 等效果进入这种机制实现完全自动化和数据驱动的渲染控制体系。 修改 game_render_group.cpp让 StoreColor() 接受 object_transform 指针并修改其它相关函数以接受指针参数
目前我们正在对渲染系统中的颜色处理方式进行一次结构性优化目的是将颜色混合如色盲适配、透明度处理等从全局状态转移到每个对象的局部变换transform中以实现更清晰、模块化的渲染逻辑。
以下是详细的处理与重构思路 整体目标
将 store_color颜色存储与混合逻辑绑定到每个对象的 transform 上而非使用全局变量优化 transform 的传递方式改为以指针形式传递避免结构体过大造成的低效清理原有的全局状态和不再使用的片段统一使用更简洁、更清晰的方式处理颜色保证 debug 构建时性能仍保持较优方便调试与跟踪。 具体操作与逻辑说明 将颜色混合逻辑从全局移入 transform 原先使用全局状态来控制颜色比如色盲值或 alpha 值现在我们将其作为 object_transform 的一部分每个对象的颜色混合状态将与其变换状态一起传递与生效更加逻辑一致实际渲染过程中在调用 store_color 时改为读取 object_transform 中的相关属性。 使用指针方式传递 transform 结构体 鉴于 object_transform 较大为避免频繁复制改为指针传递所有涉及 transform 的调用如 render_layered_scene()、reserve()、default_flat_transform() 等函数中均改为传递指针这样也便于动态修改其状态或扩展更多临时渲染控制信息。 清除原本全局变量及杂乱逻辑 统一去除旧有的全局混合状态变量去掉在 store_color 或其他与颜色相关函数中曾依赖的外部设置逻辑保持 transform 成为唯一权威的颜色变换数据源。 考虑编译器优化与 debug 构建表现 虽然现代编译器可能足够聪明处理值传递但为了避免 debug 模式下编译器不优化导致低效手动选择更直接的方式保持调试时可以准确查看 transform 状态避免因结构内联或优化丢失调试信息即便是在非 release 构建下也追求良好的可维护性和执行效率。 代码推进与修改方式 在具体推进时采用系统性的替换策略将原来传值的地方一律替换为地址传递大量是“体力活”类型的重复劳动但为了系统干净性这一步是必要的借此也表达出对现代开发工具的不满调侃意义因为这类操作本该由 IDE 或构建工具自动完成。 当前状态总结
渲染中的颜色混合不再依赖全局状态而是绑定到每个对象的变换信息结构体传递方式更高效也更适合进行渲染阶段的临时调整调试流程变得更清晰每个对象的颜色逻辑一目了然下一步可基于此机制拓展其他类型的 per-object 渲染控制如模糊、反射、特殊 shader 效果等。
整个过程虽繁琐但极大提升了渲染系统的模块化与可维护性为后续开发打下了坚实基础。 修改 game_entity.cpp让 UpdateAndRenderEntities() 设置顶层和远处雾的 Color 和 tColor
目前我们完成了颜色信息从全局状态迁移到每个实体的 transform 中的改造使得渲染流水线中的所有颜色处理包括透明度、颜色混合等都能在每个实体级别进行控制。接下来我们继续完善这套机制使其能自动响应不同图层的雾效处理。 当前系统的状态
每个实体的 transform 中已可设置颜色信息渲染管线中颜色计算已正确沿着 transform 信息传播雾效处理现在也将在 transform 中控制而非全局控制。 接下来的处理逻辑
1. 每个图层的处理方式根据其相对层级不同而不同 若为最顶层即最大层级索引 该图层属于 alpha 渐隐层此时只处理 alpha 混合不改变颜色因此设置 tcolor临时颜色时只影响 alpha 通道不必指定具体颜色值。 若为非最顶层普通图层 该图层需要参与雾效混合此时需要将背景颜色设置为混合基底并根据该图层的雾效强度设置 tcolor 的 alpha 值从而实现逐层雾效递增的视觉效果。
2. 实现逻辑中的变量准备 fog_amount 根据图层索引直接查表或计算获取用作 tcolor.a透明度的输入表示当前层级的雾化程度0 为无雾1 为完全雾化 背景颜色blend to color 为雾效混合的目标色应设置为全局统一背景色以保证层叠一致性 流程示意伪代码形式
if (relative_layer_index max_layer_index) {// 顶层图层只处理透明度渐隐transform-tcolor vec4(1.0, 1.0, 1.0, computed_alpha);// 不设置背景混合色
} else {// 雾化层混合背景色与实体色transform-blend_to_color background_color;transform-tcolor vec4(1.0, 1.0, 1.0, fog_amount_for_layer);
}实现意义
我们现在可对每个实体单独指定颜色与混合方式无需依赖全局状态渲染过程更清晰逻辑分明便于维护和调试雾效与 alpha 混合统一由 transform 控制避免状态污染和错乱不同图层可以实现独立视觉效果如逐渐远去的层次感或前景透明渲染。 整个重构过程确保了从数据结构到渲染逻辑的高一致性和高内聚性为后续扩展更多视觉特效如光照、遮罩、焦距模糊等打下了稳定基础。 运行游戏进入 UpdateAndRenderEntities() 并检查 EntityTransform 的值
目前我们完成了颜色混合逻辑的接入和实体 transform 内部的颜色状态设置理论上来说渲染阶段应该可以正确处理这些颜色值。然而实际运行时并未如预期生效接下来我们针对这个问题进行排查和修正。 当前问题描述
已经设置了 tcolor 值代表当前层的颜色混合信息渲染器应当在写入颜色时应用该值但屏幕上并未看到预期的颜色变化效果初步怀疑可能是默认的 transform 初始化没有设置正确值或颜色值未被正确传递。 排查过程与发现
1. 默认 transform 初始化问题
默认的 transform 初始化可能将所有字段设为 0包括 tcolor、blend_to_color 等关键字段如果未显式设置可能导致颜色全为黑或 alpha 为 0最终不渲染出任何内容因此必须确保在创建 transform 时为这些字段赋合理初值。
2. 测试 alpha 值的问题
当前用于控制图层渐隐的 test_alpha 值看起来出现了逻辑反转原先的设计是 alpha 趋近于 0 时越透明但现在呈现出相反效果推测是在混合计算中进行了 1 - value 之类的变换导致计算方向反了需确认tcolor.a fog_amount 的方向是否与 shader 中 alpha 混合一致。 修正方向
1. transform 初始化中设置默认值
transform-tcolor vec4(1.0f, 1.0f, 1.0f, 1.0f); // 默认完全不透明
transform-blend_to_color vec4(0.0f, 0.0f, 0.0f, 0.0f); // 默认无混合背景确保所有创建的 transform 都拥有合理默认值避免后续未显式赋值时出现渲染异常。
2. 修正 test_alpha 值方向
如果目标是从完全不透明 → 渐隐为透明那么应确保 alpha 1 - fade_value 或在 shader 中明确使用该关系如果已在 CPU 端计算 tcolor.a则避免重复反转。
例如若当前计算为
float fade compute_fog_fade(layer_index);
transform-tcolor.a 1.0f - fade; // 若 fade 为 0.0 ~ 1.0表示雾的强度那就必须确认渲染端是否也是用相同方向的 alpha 混合。 进一步建议
可在调试时设置断点确认渲染前每个实体 transform 的 tcolor 值在 shader 内部打印或用特殊颜色验证是否 alpha 正常传入添加日志机制或可视化辅助线以便快速发现混合结果异常区域若调试麻烦可考虑先将雾效设置为固定值验证整体渲染路径是否通畅。 综上所述当前问题主要是由默认初始化和 alpha 值方向反转共同造成的。在修复这些细节后颜色混合应可按预期工作渲染效果也将回归正常。整个系统将更具可控性和可维护性后续扩展更加灵活。
修改 game_entity.cpp让 UpdateAndRenderEntities() 反转 TestAlpha 的计算
目前整体渲染流程已经趋于正常颜色混合部分尤其是 ti_color 的应用已回归预期状态。我们在渲染阶段可以看到颜色值的正确生效说明渲染管线中的颜色数据传递与应用逻辑是连通的。 当前工作状态总结 test_alpha 逻辑回退至之前旧版本实现方式 当前的 test_alpha 值处理方式已回归先前设计这意味着它与旧逻辑保持一致性并能在渲染输出中产生正确的 alpha 混合效果渲染输出中可以观察到颜色与透明度的变化符合预期。 渲染阶段颜色混合逻辑正常运行 通过检查 render 内部流程可以看到 ti_color 的设置已经传递到对应的渲染路径整体颜色混合效果如预期工作说明颜色变换和混合已修复完成。 雾效部分已具备初步效果 当前雾效fog已开始在画面中可见可视区域中出现了因图层高度而造成的颜色混合与渐隐雾效的起作用区域依赖于图层高度和 fog 混合逻辑判断是否处于最大图层范围。 下一步操作建议 增加图层以测试更多雾效变化 当前层数可能不足以完全观察雾效在远距离的混合过程建议手动创建更多层级使视野可以进一步穿透验证雾效在不同层高下的效果。 观察并确认雾效是否随高度正确变化 确保随着相机视角或对象高度提升雾效的混合程度正确改变检查 fog_amount 在每一层的计算是否平滑过渡确认背景颜色是否正常混合进画面未出现全黑或未初始化状态。 记录当前雾效效果基线 当前实现状态已经可作为一个稳定基线若后续需调整 fog 的参数如浓度、渐变速率等可基于当前结果进行微调建议加注注释标记雾效使用的位置和关键点方便日后维护与扩展。 总结
渲染通道已建立正确的颜色混合流程test_alpha 和 ti_color 的设置在各个 transform 上被成功传递与应用雾效部分也开始在多图层结构中产生可视化表现。接下来可通过增加图层并进行视觉验证确保整个雾效系统在纵深方向上具备平滑、合理的渐隐效果至此整个渲染系统的雾效处理进入一个稳定的阶段。 修改 game_world_mode.cpp让 AddStandardRoom() 生成多层房间
我们目前将所有相关逻辑整合到了 world_nerd 模块中。接下来通过调用 add_standard_room 接口可以批量添加多个房间堆叠在一起从而测试雾效、图层渲染、透明度混合等功能在多层空间结构中的表现是否正常。 当前状态详细总结如下 逻辑已集成至 world_nerd 内部 所有与图层、颜色混合、transform、透明度相关的逻辑现已内聚在 world_nerd 中这样做简化了系统结构使后续调试和扩展更清晰。 通过 add_standard_room 可连续添加多个房间 可以一次性堆叠多个房间结构形成多层地图或立体场景每个房间都被放置于不同图层从而形成高度差异用于雾效等视觉效果的验证。 支持雾效深度渐变测试 多层房间结构可以直接用来测试雾效随图层变动的渐隐与颜色融合可验证 fog_amount 与 test_alpha 的混合是否随着高度合理过渡同时可以确认颜色在不同层之间的混合是否与 ti_color 设置保持一致。 渲染路径完整运行 添加房间后相关实体 transform 颜色参数设置已完整接入渲染流程渲染系统能够正确响应图层信息并绘制透明度、雾效、背景颜色等。 建议进一步操作
尝试构建超过三层以上的房间结构观察不同高度下雾效变化在每层房间内加入视觉锚点如高对比度贴图以便验证颜色混合是否平滑可考虑对 add_standard_room 增加位置偏移参数构造复杂场景布局后续如需更复杂雾效非线性渐变、基于视角等可在此基础上继续扩展。 总结
当前我们已成功将雾效与图层透明度逻辑整合进主流程并通过堆叠房间机制实现了对渲染管线的测试准备。add_standard_room 接口作为核心测试手段可以灵活创建多层场景为进一步优化视觉表现提供良好基础。下一阶段可专注于雾效表现细节的调整与性能测试。 运行游戏观察多层房间效果并查看性能分析器
目前我们注意到在堆叠更多房间时出现了一些有趣的现象尤其是在与房间渲染和调试模式表现相关的部分。以下是详细情况整理 当前观察到的关键现象和问题 close_traversable 与 buildsberry 表现差异明显 close_traversable 是目前少数未使用基本空间分区basic partition结构的系统相比之下buildsberry 已启用基本分区并承担更多空间管理逻辑两者在运行负载上出现明显差异。 buildsberry 在 debug 模式下表现不佳 当前 buildsberry 承担了较大的计算压力在 debug 模式中性能下降尤为严重可能存在较多断言检查、未优化的内存访问等问题导致调试体验较差尤其在堆叠多个房间后更明显。 需要验证优化编译下的表现差异 初步判断debug 模式的低性能并不能准确反映最终表现因此计划在优化编译optimized build下进行快速测试以确认系统是否能在实际使用中维持性能拍照或快照操作也计划进行以便对比渲染输出或用于后续验证。 其他补充
多房间堆叠测试中也可能揭示基础数据结构如分区管理、实体变换、颜色混合潜在的问题如果 close_traversable 在未使用空间分区下表现更流畅可能提示我们需要重新评估 buildsberry 的分区策略或其调试代码复杂度图层管理、雾效处理等逻辑已能正确响应不同房间高度变化进一步支持这类分析。 建议后续操作
在优化模式下运行 buildsberry 并记录性能指标比较其与 close_traversable 的帧率、内存使用和响应速度分析 debug 模式下哪些部分导致性能瓶颈考虑是否能局部优化或加以屏蔽若有必要构建可视化工具追踪房间堆叠与渲染开销的关系。 总结
当前我们已观察到 buildsberry 在 debug 模式下因压力过大表现不佳而 close_traversable 结构相对简单、无分区逻辑运行更轻盈。这一对比有助于分析空间分区和调试模式的性能影响接下来将在优化模式下进一步验证系统在真实运行时的表现以确定是否需要调整相关模块的架构设计。
“我的天啊为什么有这么多头在跟着我”β
目前我们观察和测试了一些关键渲染特性特别是与雾效、图层、Z轴偏移和渲染分层相关的内容。以下是当前工作的详细总结 渲染和雾效状态确认
雾效在底层区域渲染结果正确这意味着颜色混合、图层透明度、视距遮蔽等逻辑基本正常。当前我们主要关注的目标之一就是验证这些雾效在特定图层深度下是否呈现正确目前结果令人满意。 屏幕内容混乱与设计目标偏离
当前画面中存在大量元素例如多个“头部”实体围绕玩家移动视觉效果令人不适且不是预期效果。虽然暂时不会优先处理但这可能需要后续设计优化例如减少视觉噪声、压缩敌人数量或行为频率。 图层与 Z 值的问题 我们现在拥有两个关于 Z 位置的概念 图层Layer的位置索引实体在该图层内的实际 Z 偏移。 为了实现正确的遮挡、渲染顺序和深度感需要对 Z 值的处理逻辑进行整合与调整。 目前尚未处理该问题但已经明确必须要完成此步骤才能确保系统稳定性和正确性。 图层渗透与可见性异常
目前观察到有一些图层渗透的现象例如本应被遮挡的生命条health rectangles在不应出现的图层中露出理论上完全不应透过主图层但由于所有元素目前都被统一添加到了渲染图graph中导致可能存在渲染周期或依赖冲突如果图中出现循环依赖cycles可能导致渲染顺序错误或渲染结果不符合预期当前做法违反了最初设计意图因此将来必须将不同种类的元素如HUD、实体、背景等划分为不同的渲染阶段或通道passes。 后续改进思路 明确分离不同类型的渲染元素例如 实体渲染 PassHUD 渲染 Pass后期处理 Pass 避免将所有元素直接插入单一渲染图结构以免形成复杂依赖导致渲染次序错乱 在分层渲染基础上增加独立的遮挡检测或剪裁策略。 时间限制与开发安排
当前仅剩大约 12 分钟开发时间本阶段不打算深入实现 Z 处理或分层 Pass 管理但上述两者已被确认为后续必做的重点开发项。 其他探索
未来计划尝试一些“技巧型”处理方式简化图层渲染依赖或通过批次遮挡策略解决局部问题这些技巧并不能取代系统级架构调整但在短期开发周期内可暂时缓解部分问题。 小结
目前雾效与图层透明处理已基本正确但仍存在图层渗透与Z轴错位的问题未解决。图层与实体的渲染顺序及结构划分需进一步完善并通过多 Pass 渲染架构重构以彻底解决依赖错误和遮挡异常等潜在渲染问题。虽然当下开发时间有限但整体方向已清晰接下来的工作将集中在图层渲染逻辑与Z位置处理的完善上。 考虑始终用实体最初的 ChunkZ 来渲染
我们正在探索一种优化渲染顺序的策略核心思想是在进行渲染排序时始终使用实体在本次模拟开始时所处的 chunk Z 值而不是他们最终移动结束后的 chunk Z 值。 背后的动机与好处
实体是在按 chunk 分块的结构中流式加载的因此它们天然已经是按照 chunk Z 值有序排列的如果我们始终使用它们起始时的 chunk Z 值进行渲染排序就能完全避免重新排序的开销对于大多数静止或微小移动的实体这种排序方式不会造成任何视觉错误整体上这是一个性能友好型方案能够极大减少排序逻辑的复杂度和运行时负担从使用感受上来看这种机制“感觉很好”具有非常吸引人的简洁性和稳定性。 潜在问题
当实体正在跨越两个 chunk 边界时例如从一个 chunk 移动到另一个 chunk由于使用的是起始位置的 chunk Z 值会造成某一帧的渲染顺序错误这意味着在极少数帧中某些实体可能出现在错误的深度上从而影响遮挡关系不确定这种“错一帧”的视觉错误是否可接受但初步判断问题可能比较小尤其是在场景复杂度较高、动作频繁时用户感知不强。 屏幕空间排序的问题
屏幕空间排序的情况无法直接使用相同优化方式屏幕空间错误一旦发生其可见性和影响非常明显会造成严重的错位或遮挡混乱因此屏幕空间排序仍然需要更加精确的实时更新与处理逻辑不能使用类似的“起始状态缓存”方法。 当前结论
对于 chunk 层级的 Z 值排序使用模拟开始时的 chunk Z 是一个“几乎白送的优化”拥有显著优势即使存在某一帧的错序风险其实际影响也可能是可以接受的暂时决定采用该方法以换取性能与逻辑上的清晰性屏幕空间排序方面仍需保持精确的实时处理。 后续可能探索
对“移动中实体”的特殊处理机制比如在跨 chunk 时标记其状态特殊处理渲染顺序对于屏幕空间排序是否存在某种“近似”优化方式的深入测试与实验可视化调试支持帮助开发中观察是否出现明显的错帧渲染错误。 整体来说这是一个兼具工程效率和运行效率的优化策略适合当前架构在性能和复杂度之间找到平衡点。
黑板讨论排序障碍物
我们正在提出一种改进渲染排序流程的方案目标是在不影响排序逻辑正确性的前提下大幅减少排序的开销并提升组织性。核心构想如下 基本思路
当前我们已经将渲染条目slices以一定的顺序写入渲染缓冲区render buffer。现在我们设想通过在这些切片之间插入屏障标记barrier token来实现**局部排序bucket sort**的能力。每一组条目每一个逻辑层级在渲染缓冲区中由一个屏障标记分隔。排序时只需要在两个屏障之间做本地排序即可。 渲染排序流程的改造
我们希望在构建渲染图build spray graph时像这样处理
渲染条目会按照逻辑层级layer顺序写入在每个层之间插入一个特殊标记表示这一层的终止点排序器sort_entries在处理时遇到此标记立即对当前段内条目执行排序然后开始新一段这个屏障标记可以使用特殊的 key 值manual key来实现标记其为 barrier 类型。
这样整个渲染排序就会像分段流水线一样处理而不是整个一次性排序。 优势
减少无效排序不需要将全部渲染条目都丢到一个排序器中处理提升可控性每个逻辑层级内部排序彼此隔离方便调试与分层渲染提高性能局部排序在数据量较小的范围内完成排序开销更小简化实现逻辑上很容易实现只需添加对特殊 key 的判断逻辑。 初步实现构想
在 sort_entries 或 sort_right_bounds 这类排序函数中实现如下逻辑
for (int i 0; i entry_count; i) {if (is_barrier_key(entries[i].manual_key)) {sort_current_bucket(start, i);start i 1;}
}其中is_barrier_key() 判断是否为插入的特殊标记sort_current_bucket() 对当前段执行排序。 实际收益场景
渲染层级特别多时减少全局排序代价动态场景频繁变化时提升帧稳定性调试或设计工具中提供更清晰的结构化渲染输出。 下一步计划
这个机制暂时不会立即实施而是作为后续的改进方向先行构思出来待到下次继续开发例如下周时再投入实现。 总体来说这是一个低成本、高回报的渲染排序架构改进方案能带来更强的灵活性与性能表现。
修改 game_render.h定义 SPRITE_BARRIER_OFFSET_VALUE
我们考虑在渲染排序流程中引入一个“精灵屏障值”sprite barrier value的机制用于优化渲染条目的分段排序。这个屏障值将作为一个特殊标记用来区分渲染缓冲区中不同逻辑分区的边界从而实现分段式的排序处理。以下是详细构想 精灵屏障值机制
设想创建一个特殊的屏障标识符比如称作 sprite_barrier_value其作用是
表示排序边界一旦渲染队列遇到这个值就意味着到达了当前排序块的末尾不参与排序本身这个值仅作为排序触发点排序逻辑不会把它视为普通渲染项使排序块分割清晰不同层或不同逻辑区域被隔离开每段单独排序。 实现层面考虑
在构建渲染节点时我们将该值插入到指定位置作为逻辑层之间的“锚点”
遍历输入节点时记录 input_nodes_count在合适位置如每个逻辑分层结束之后插入 sprite_barrier_value在排序阶段判断当前条目是否是该特殊值如果是则触发排序操作并重置段的起始位置这个特殊值可以是一个不会出现在实际实体中的保留数值例如负值或特定 bit pattern。 示例逻辑
排序函数伪代码
for (int i 0; i node_count; i) {if (entries[i].manual_key SPRITE_BARRIER_VALUE) {sort_range(start, i - 1); // 排序当前段start i 1; // 下一段开始}
}系统集成逻辑
在 build 阶段处理 input_nodes 并在适当时机插入 barrier在排序函数中根据 manual_key 判断是否为屏障在渲染时跳过渲染此特殊条目确保它不被绘制。 意义与优势
排序粒度优化更高效地控制排序块大小避免全局排序渲染结构清晰渲染逻辑上更易组织与维护性能提升小范围排序速度远快于整体排序支持扩展后续可扩展为图层隔离、特效区分等更多用途。 总之这一机制将显著提升渲染排序流程的清晰度与效率是针对当前层级排序瓶颈所设计的切实可行的解决方案。
修改 game_render.cpp让 BuildSpriteGraph() 接收并返回 NodeIndexA由 SortEntries() 传递
我们现在需要做的事情是在构建渲染排序系统时引入一个控制排序分段起点的机制避免全局排序带来的开销。目标是更灵活地控制每段排序的开始与结束位置。以下是详细内容 核心目标
不再从 0 开始遍历所有输入节点 (input_node_count)而是
接收一个明确指定的起始值通过该值控制每次排序从哪里开始实现排序逻辑的分段式执行。 实现步骤 设定起始值 在外部控制逻辑如构建精灵图的函数中设定一个初始的 first_index 值初始为 0 int first_index 0;
while (first_index total_count) {first_index build_sprite_graph(..., first_index);
}在 build_sprite_graph 中处理 barrier 在遍历过程中判断当前节点是否是“排序屏障”若是则提前返回当前索引表示本轮排序终止点 for (int i start; i count; i) {if (offsets[i] SPRITE_BARRIER_OFFSET_VALUE) {return i 1; // 下次从这里继续}// 处理正常节点
}将屏障值放入 offsets 中 为避免污染 manual_key 字段使用 offsets 来存储特殊屏障值如 -1 或其他非法偏移 if (offsets[i] SPRITE_BARRIER_OFFSET_VALUE) {// 不进行排序处理
}测试机制 在测试阶段可以插入伪 barrier 值用于验证分段是否正确 if (offsets[i] SPRITE_BARRIER_OFFSET_VALUE) {// 停止本轮排序测试分段是否有效
}效果和意义
支持多轮分段构建排序图每次从上次 barrier 后开始处理显著提高排序效率避免无意义的全量排序逻辑清晰可控通过 barrier 分隔各个图层或区域屏障信息存储更合理利用 offsets 避免干扰 manual_key 等核心字段。 这个方案使我们可以灵活地构建图层隔离、优化渲染处理流程同时也方便后续扩展例如支持动态图层、区域遮挡裁剪等。通过精确控制每段渲染数据的边界进一步优化性能并降低维护复杂度。 运行游戏确认没有变化
现在运行的话基本上处于稳定阶段暂时不需要做任何改动系统应该一切正常。但接下来我们可以回头对之前的方案做出调整和完善这部分工作计划在周一进行。到时候会根据目前的情况把之前的改动落实并优化使整体流程更加合理和高效。
问答环节
那些召唤兽都从哪儿来的
突然出现了很多随从我们完全不清楚它们是从哪里来的。每个层级都会生成一个随从具体原因不明。观察了随从的行为它们似乎只是简单地沿直线移动代码里它们只检查目标位置是否被阻挡其他情况似乎没有判断。这些随从行为怪异让人觉得有点诡异。既然没有更多疑问我们可以提前结束了。
蛇看起来坏掉了
蛇的表现很奇怪只有一节身体出现像是爬上了楼梯到更高的层级但其他蛇都正常没有出现这种情况这个bug挺诡异的。之前好像没见过这种情况。虽然蛇爬楼梯本身没问题只要它能及时避开其他物体但这只蛇跳到了顶层我们根本不知道它是怎么做到的。估计是代码里关于z轴跳跃高度的逻辑有问题没对爬升做限制导致它能直接选择高楼层。场景里还有些断头随从漂浮画面显得怪异虽然这些代码不是我们主要关注的但整体行为怪异让人感觉诡异和不安。
