- 博客(677)
- 资源 (119)
- 收藏
- 关注
RSS订阅原创 游戏引擎学习第310天:利用网格划分完成排序加速优化
方案优点缺点增加 count 字段简洁直观，内存友好，兼容现有结构只适合处理连续片段，灵活性较差引入链式结构支持非连续组，适应性强内存访问不友好，遍历成本高，结构更复杂实现简单，结构直观；不需要改动现有复杂的排序逻辑；为手动排序需求提供了明确控制力；保持结构统一，避免类型分裂；可拓展性强，未来可以进一步结合排序组（SortSpriteBounds）做更高级的分层策略。当前已经完成渲染链式机制的基础结构搭建。
2025-05-26 11:17:55
211
原创 游戏引擎学习第309天:用于重叠检测的网格划分
使用屏幕宽高除以网格划分数计算出单元格尺寸。直接使用网格划分数除以屏幕宽高计算出倒数尺寸。利用倒数尺寸将任意输入矩形快速映射到网格坐标范围。所需的屏幕宽高可以从渲染命令中直接获取，无需额外计算。至此，我们的网格空间划分逻辑已经具备了完整的结构准备，可以进入下一步的功能实现阶段。使用整型坐标更高效，矩形裁剪判断通过交集函数完成。构建完整屏幕矩形用于判断。将所有计算所需参数整合并传入统一函数中，保持函数结构清晰。交集检查能过滤掉屏幕外无效矩形，避免浪费性能。
2025-05-24 09:40:10
879
原创 游戏引擎学习第308天:调试循环检测
循环检测机制已经成功激活，并能对多数明显的循环结构进行可视化提示；修复了关键逻辑漏洞后，系统具备了基本的错误反馈能力；发现新的疑点与异常分布，有助于后续深入排查排序依赖结构中的隐藏问题。循环检测工具可以工作了，但结果显示出一些新问题。下一步建议深入排查图的构建与遍历路径，确认是否存在节点遗漏或排序规则异常。已简化场景，确认问题确实与复杂场景无关，而是出现在某些动态行为过程中；循环触发机制存在异常，看似只在特定状态或位置才会激活；有可能图结构构建时引入了错误的依赖；
2025-05-23 19:13:42
892
原创 游戏引擎学习第307天:排序组可视化
上次结束后，很多人都指出代码中存在一个拼写错误，因此这次我们一开始就知道有一个 bug 等待修复，省去了调试寻找错误的时间。今天的任务就是修复这个已知 bug，然后继续排查其他潜在的问题。如果短期内没有更多 bug，我们就要着手解决我们算法中的 O(N²) 部分，因为这个性能瓶颈迟早会带来问题。接下来就正式开始今天的开发流程。
2025-05-23 17:00:51
1204
原创 游戏引擎学习第306天:图结构排序的调试
在游戏渲染过程中，发现了一个意外的现象：在某些特定情况下，剪裁矩形（clip rect）列表为空，而这不符合之前对渲染流程的预期逻辑。我们仔细检查了整个流程，发现正常情况下，在开始渲染组（）时，都会默认压入一个剪裁矩形。无论是透视（perspective）视角还是正交（orthographic）视角，系统设计上都会调用对应函数，并在其中执行一次剪裁矩形的压栈操作，因此理论上应当始终存在至少一个有效的剪裁区域。
2025-05-23 10:54:26
1117
原创 游戏引擎学习第305天:在平台层中使用内存 Arena 的方法与思路
我们现在通过引入，将渲染数据预处理（如排序、裁剪矩形线性化等）从主渲染命令中剥离，形成清晰的两阶段渲染体系。这样一来，渲染流程更整洁、逻辑更清晰、接口更统一，未来拓展、调试、优化都将更加方便。平台解耦：不同平台都用同样的入口函数，不再处理准备细节；逻辑清晰：职责划分明确，渲染命令构建与数据准备完全分开；更易维护：排序和准备工作封装在一处，代码集中易于修改；扩展灵活：未来添加更多的中间处理步骤也能统一放进中处理；复用性高：通用的排序、裁剪转换等逻辑可以跨平台共享。
2025-05-22 13:54:21
1240
原创 游戏引擎学习第304天:构建与遍历图
明确了不需要新建额外的图节点结构，复用已有；为图添加了链式边结构用于快速遍历；选择使用索引来表示边连接目标，兼顾效率和易实现；结构设计紧凑，便于后续的遍历、排序和循环检测等操作。下一步是开始实际编写代码，实现图的构建逻辑。我们先从一组结构出发；遍历所有节点对，判断它们是否相交并确定遮挡关系；通过交换保证所有边的方向都是从前置节点指向后置节点；为每个节点维护一个边链表，存储指向它后置节点的边；使用边池管理边的存储；这样我们就构建了一张有向图，表示了精灵间的遮挡顺序关系。
2025-05-22 09:21:18
920
原创 游戏引擎学习第303天:尝试分开对Y轴和Z轴进行排序
我们实现了两个合并排序逻辑，分别基于Y轴最小值（ymin）和Z轴最大值（zmax）；通过这种分开排序，再进行最终合并的方式，我们可以获得一种较为稳健的绘制顺序；当前的实现虽然冗长重复，但可以先确保逻辑清晰和正确；后续可以通过函数模板或策略模式优化代码结构，避免重复逻辑；这种排序方式避免了Z-buffer的复杂性和控制困难，适合需要自定义绘制顺序的半2D场景渲染逻辑。分离精灵使用一块足够大的临时缓冲区；将Z精灵移动到Temp，Y精灵保留在原缓冲区；各自排序Z精灵使用zmax降序合并排序。
2025-05-21 22:50:04
1171
原创 游戏引擎学习第302天:使用精灵边界进行排序
我们最终确认，仅以三维点到摄像机的距离作为排序依据，是不充分的，无法涵盖遮挡的复杂情况。正确做法是引入基于屏幕空间遮挡关系的图结构排序机制。通过构建一个图结构并使用拓扑排序，我们可以在保持正确遮挡的前提下，合理组织精灵的渲染顺序。这种方式虽然实现更复杂，但从根本上解决了遮挡判断不准确的问题，确保渲染结果符合预期的空间层次。我们计划先写个基础版本，暴力遍历所有精灵对，检测重叠并建立遮挡关系的有向边，生成一个精灵遮挡图。这个图之后可以用来做拓扑排序，确定渲染顺序。
2025-05-21 17:47:28
1095
原创 游戏引擎学习第301天:使用精灵边界进行排序
我们目前的策略是在系统中引入一个更清晰、更职责单一的结构（如降低使用复杂度；避免不必要的冗余字段传递；减少编译器优化上的不确定性；提升后续排序、渲染调度的可维护性。未来我们还可以考虑进一步封装排序规则，让调用层几乎不需要理解排序细节，只需关注其渲染表达的语义。目前的目标是将外部渲染调用过渡到新的排序系统。面临的问题是缺乏完整的排序所需边界数据。利用 transform 中的“upright”字段来初步区分排序方式；使用位图尺寸推算 Y 方向的边界值；
2025-05-21 15:55:20
778
原创 游戏引擎学习第300天:从排序键更改为排序规则
不重叠时，直接按 Y 坐标排序；重叠时，比较 Y 精灵最高点和 Z 精灵高度决定谁在上；不处理精灵穿透或自动裁剪，这类特殊情况由其他系统处理。对于 Y 精灵与 Y 精灵的重叠，大多数情况下我们只需按照 Y 坐标排序即可；装配类结构（如角色身体各部分）需特殊处理，作为整体排序；除非出现特殊需求，否则不将 Z 维度纳入常规排序逻辑；目前来看，没有发现常规情况下不能用 Y 排序的例外情况，因此我们倾向于将 Y 重叠问题简化为按 Y 坐标排序处理。
2025-05-21 10:59:25
1248
原创 游戏引擎学习第299天:改进排序键 第二部分
我们会现场编写完整的游戏代码。回顾上周发现自己对游戏中正确的排序规则并没有清晰的理解。主要原因是我们更擅长三维游戏开发，缺乏二维游戏和二维游戏技术的经验，对于二维精灵排序、模拟三维效果的最佳方案等没有太多技巧和经验。因此，今天的目标是专注于研究和理清二维游戏中的Z轴排序问题。我们希望通过深入思考，理解各种排序方案的权衡，找到在大多数情况下能够产生最佳效果且最少依赖临时解决办法的规则。
2025-05-20 23:34:32
1416
原创 游戏引擎学习第298天:改进排序键 - 第1部分
对齐关键点（Alignment Point）这是用于确定位图在空间中旋转和缩放的参考点。例如当进行旋转或缩放操作时，该点保持不动，其余部分围绕它变化。类似于“锚点”或“中心点”，影响图像的视觉变换方式。排序关键点（Sorting Point）这是用于在渲染队列中确定图像前后关系的点。一般反映图像“落在地上的位置”或“遮挡基准”，用于决定绘制顺序。该点对渲染顺序敏感，但对几何变换（如旋转）没有直接影响。用于旋转/缩放的对齐点；用于渲染排序的排序点；
2025-05-20 23:10:18
1068
原创 游戏引擎学习第297天:将实体分离到Z层中
我们实现了一个临时剪裁矩形机制，使剪裁状态的切换更加可靠和自动化，并基于此设计思路初步验证了通过预设多个 clip rect 来实现不同 slice 的分离渲染。下一步我们准备将模拟与渲染逻辑解耦，进一步清理渲染结构，使其更便于扩展和维护。这个机制为后续实现类似多楼层、深度雾效、独立透明度等视觉效果打下基础。我们将渲染与更新实体的逻辑提取到一个新函数中，并理清了所有参数的来源与用途。剪裁矩形的管理暂时使用简化逻辑，后续可进一步优化为可查询的结构。
2025-05-20 18:29:08
1167
原创 游戏引擎学习第296天:层的雾效和透明度
通过使用统一的全局参数和global_t，我们实现了灵活控制颜色混合（雾化）和透明度渐隐（fade）的方法。该设计清晰、易于扩展，便于后续在渲染管线中增加更多图层处理或特效控制逻辑。当前的核心问题出在 alpha 的预乘未被正确实现，导致 fade 效果表现异常。必须在 shader 或渲染流程中修复这一点，并统一所有相关逻辑中的 t 值使用与混合方式。同时，需要从逻辑定义和底层渲染两个层面同时处理，才能保证颜色与透明度的混合行为符合预期。移除预乘逻辑在中原本执行的预乘处理被去除。
2025-05-20 11:12:47
1352
原创 游戏引擎学习第295天:堆叠房间用于Z层调试
我们已经构建了垂直结构的基础，通过强制房间之间总是存在一个向上的通道（门），配合已有的高度跳跃逻辑，能够实现角色从一个房间向上跳跃并进入另一个更高层房间的效果。这标志着空间设计从平面布局向立体布局迈出了关键一步。后续将进一步测试房间切换、碰撞检测以及渲染一致性等方面的表现。此处的问题本质上是绘制指令未正确继承渲染管线中的透明度状态，属于渲染系统中常见的细节疏漏。通过将全局 alpha 正确应用到局部绘制颜色上，问题已顺利解决。这一改动不仅提升了视觉一致性，也为后续更多 UI 与空间元素的分层渲染打下了基础。
2025-05-19 16:40:03
821
原创 游戏引擎学习第293天:移动Familiars
PD 控制器基于当前误差进行快速调节，适用于快速趋近目标并抑制振荡；加速度由位置误差和速度误差共同决定，分别由比例项和导数项控制；名称中的“导数”本质上可以理解为“差值”，因此也可类比为“比例差值控制器”；PI 控制器通过累积误差强化调整力，适合纠正长期误差，但响应速度较慢；实际应用中常使用 PID 控制器（比例-积分-导数）结合多种优势。我们将在熟练体的运动控制中采用 PD 控制机制，使其运动过程既能迅速趋近目标，又能抑制震荡和来回漂移，提升整体行为的稳定性和自然感。
2025-05-18 20:01:08
1213
原创 游戏引擎学习第292天:实现蛇
我们在设计脑槽（brain slot）时遇到的问题是，需要一个常量来表示槽的位置，但如果把槽索引作为函数参数传入，就不再是常量了。为了解决这个问题，提出了“带索引脑槽”（indexed brain slot）的方案，思路是给脑槽结构加一个索引成员，然后在访问时自动把索引加上偏移量，这样就能动态访问对应的槽位。实现时发现可以用一个更简单的方法，就是调用普通的脑槽访问函数时，把索引作为一个额外的偏移量参数传入，函数内部在计算具体内存地址时直接把索引加进去。
2025-05-18 11:14:38
926
原创 游戏引擎学习第291天:跳跃的怪物与占据的树木
目前我们其实已经有点不记得今天具体该做什么了。上次我们当时实现了“脑子”（Brains）系统，让角色可以跳来跳去。我们还做了一个的实验，有人问我们是否可以将自己的头部与附近其他东西进行交换，那部分还挺有趣的。虽然现在没法很明确地说今天要实现哪些功能，但有很多方向我们可以继续深入。与其做一个提前准备好的流程介绍，不如直接打开代码库看情况。现在感觉最有价值的方向，是继续完善“脑子（brain）”相关的逻辑，也许是让怪物动起来，比如之前提到过的小蛇状怪物，能自由移动一类的，也挺有意思。
2025-05-18 08:46:30
1319
原创 游戏引擎学习第290天:完成分离渲染
行为、控制、渲染、运动的完全解耦；支持跨实体控制的复杂逻辑；组合自由和复用能力的显著提升；后续可扩展性和错误防范能力增强。这是一项从结构上提升整个系统灵活性和表达力的重大进展。我们可以说——直播编程绝不是一种更轻松的工作方式，相反它让一切变得更困难。注意力被分散；心流难以维持；模块切换频繁；节奏受限，思路难以连贯。虽然我们仍坚持以这种形式推进工作，但每一次都是在比正常更艰难的条件下完成系统的搭建与逻辑实现。brain_slot提高类型安全性，避免手动错配 type/slot。
2025-05-17 20:02:18
1123
原创 游戏引擎学习第289天:将视觉表现与实体类型解耦
控制器成功识别输入，值正确。关键问题出在加速度没有从控制器状态传播到实体 DDP 的目标变量ddp_to上。一旦赋值修复为，实体应能按预期响应方向控制。本轮调试发现了导致实体无法获得加速度的根本问题：控制器输出的加速度变量没有被正确传递到实体逻辑中。修复方式为：明确将的值赋给实际用于计算的目标变量。这是当前最紧急的问题，修复后预计能恢复基本移动能力，后续将继续清理和改进整体结构。
2025-05-17 15:13:37
1135
原创 游戏引擎学习第288天:继续完成Brains
成功初始化了实体与大脑的绑定；已能通过大脑控制逻辑影响实体状态（如放置位置）；清理了一些无用遗留代码；下一步将重构实体移动系统，从“立即移动”改为“延迟执行”，由物理系统统一处理；为后续添加更复杂 AI 行为（如路径规划、状态机）奠定基础。整体思路正在朝模块化、解耦、数据驱动的方向稳步推进，后续还需逐步完善大脑与物理系统的接口设计和调度流程。我们目前进入了物理系统与大脑控制系统整合的关键阶段。
2025-05-17 11:10:34
1277
原创 游戏引擎学习第287天:加入brain逻辑
每个实体通过控制器类型、插槽编号和控制器实例 ID 进行动态组合；所有结构在模拟区域加载时按需拼装，无需静态绑定或生命周期管理；系统更加有机、模块化、无状态，允许实体被自由组合、断裂和重组。接下来将继续推进代码实现，通过先行编写具体控制器逻辑（例如 Hero Controller）进一步验证这一机制的实际效果。实体仅为物理/逻辑组件，没有固有类型；控制器承担逻辑聚合、行为协调和状态分发；结构变化实时同步、自动响应；彻底摆脱传统面向对象实体建模中“类型中心论”的束缚；
2025-05-16 21:57:07
906
原创 游戏引擎学习第286天:开始解耦实体行为
范数是数学中用于衡量“向量大小”或“距离”的一种方式，在编程和图形系统中也非常常见。我们平时常用的向量长度计算，其实就是范数的一种具体形式——2范数（Euclidean Norm）。范数是度量一组数值整体大小的方式。不同范数根据实际需求使用，其中 1 范数和 2 范数最为常用。∞ 范数提供的是最大单个分量的值，适用于某些特殊场景。了解这些范数的定义和几何含义，有助于我们在设计系统时选择合适的度量方式。
2025-05-16 18:05:23
1192
原创 游戏引擎学习第285天:“Traversables 的事务性占用”
这一阶段完成了从“直接写入占用信息”到“事务式、安全验证”的过渡，实现了实体之间空间互斥的基础设施。避免多个实体占据同一位置；清晰管理占用和释放逻辑；为未来AI路径判断、阻挡检测提供了清晰入口；提高系统健壮性，避免非法访问和状态错误。接下来可进一步考虑将此机制融入移动控制器、导航系统中，实现完整的路径判断和动态调度能力。没有区分“移动中”与“占用中”；“头部”是否占用与逻辑模型不一致；解包操作引发副作用；“占用”机制需要被更精确地建模为一个状态机。
2025-05-16 14:56:23
1090
原创 游戏引擎学习第284天:重新组织头部和身体代码
我们正在进行游戏开发，当前阶段是在完善世界构建中的最终实体设计。昨天我们结束时，设定了主角能够站在某个可移动物体上的基本概念。现在需要完成这个过程。游戏中的每个实体，特别是那些需要行走、移动或跳跃的角色，必须明确占据地面上的特定点位。这类似于棋盘游戏的规则：每个角色占据一个方格，并且该方格只能被一个实体占据。我们必须准确地理解每个实体所处的位置，也就是占据哪个方格。昨天已经实现了这套定位系统的初步部分，但还未完成后续的逻辑。当前主角的跳跃机制还在正常工作，除了渲染方面略有调整，一切还算顺利。之前的目标是验证
2025-05-16 09:30:57
788
原创 游戏引擎学习第283天:“让‘Standing-on’成为一个更严谨的概念
无论将来我们如何细化规则、调节体验、做视觉反馈，只要底层是基于事务性占格模型构建的，就能避免“无法落地”或“站位冲突”等根本性Bug；这样一来，即便我们未来引入各种特殊敌人行为、复杂连击、多人抢位、连锁反应等系统，也都能在这一机制下良好运作；它是整个格子控制系统的根基。所以，我们当前所需做的，是在底层建立起一个清晰、严格、永远可靠的事务性占格逻辑系统，并将所有移动、攻击、滑动、投射等行为构建在这个框架之上。这样我们才有信心面对游戏玩法扩展与未来所有复杂情况的挑战。事务性格子占用。
2025-05-15 19:49:10
1400
原创 游戏引擎学习第282天:Z轴移动与摄像机运动
我们目前正在进行一个游戏开发项目。昨天，我们实现了基于房间的角色移动系统，并且加入了摄像机的跟随滚动功能。这是我们首次进入“游戏逻辑设计”阶段，也就是说，我们开始构建游戏本身的行为和玩法，而不仅仅是底层引擎的开发。我们当前的任务是整理并清理已有的代码，使结构更清晰，并为下一步开发奠定基础。现在，角色已经可以在房间之间移动，这种移动方式非常流畅且快速，对于一款节奏明快的动作类游戏而言，这种迅速的转换可能是合适的。尽管如此，我们之后仍然可以根据需要调整移动的节奏。
2025-05-15 17:20:25
1008
原创 游戏引擎学习第281天:在房间之间为摄像机添加动画效果
摄像机的控制不应影响玩家的方向感与操作判断力；避免画面切换时的突变，尤其在存在危险因素时尤为重要；引入迟滞机制，设置非对称的切换门槛，避免摄像机频繁抖动；结合视觉动画，实现房间之间的平滑过渡，提高体验连贯性；重视玩家感知路径，从视觉接收、控制反应、逻辑判断的完整链路出发优化系统设计。我们将基于这些理念，继续优化摄像机控制系统，确保最终游戏体验既舒适，又具备预期一致性和稳定的可控性。一个系统的当前状态不仅取决于输入值本身，还取决于它是如何达到该输入值的过程。也就是说，它不是“时间无关”的，而是具有。
2025-05-15 12:47:31
1141
原创 游戏引擎学习第280天:精简化的流式实体sim
模块说明添加标准房间实体，位置接近原点(0,0,0)，摄像机应该能看到负责将实体打包进世界的某个 chunk，位置正确，chunk 会被创建或复用实际完成实体数据写入，内存块分配、地址偏移、数据拷贝都执行正常begin_sim启动仿真区域模拟，尝试加载周围 chunk 中的实体，但未正确读取出来问题点说明chunk 的实体计数器未被正确维护在 pack_entity_into_chunk 时没有递增该值，导致系统认为 chunk 是空的当前逻辑依赖该值判断 chunk 是否有效。
2025-05-15 10:27:57
1127
原创 游戏引擎学习第279天:将实体存储移入世界区块
特性AOSSOA数据访问效率低（带入大量无用字段）高（只处理关心的字段）缓存友好性差好并行化/向量化能力差（字段不连续）强（字段紧凑对齐）系统解耦能力一体化，难以分离优化易于对特定子系统独立优化适用场景小规模、快速迭代原型大型复杂模拟，性能敏感逻辑因此，如果我们遇到需要对某些属性进行大量计算、优化或者独立模拟的场景，选择SOA 是一种更好的架构方案。但在其它属性变化不大、逻辑简单的场合，使用 AOS 也完全合理。
2025-05-14 14:23:23
1122
原创 游戏引擎学习第278天:将实体存储移入世界区块
当前的核心改动是通过固定数据块大小（64KB）来简化实体数据的存储和管理，并通过记录数据块的实际使用大小，而不是实体数量，来提升灵活性。虽然这个方案暂时没有过多的细节约束，但它为后续的优化和调整奠定了基础。我们完成了实体系统向更现代、类型安全的数据流动架构的初步转型，主要包括实体标识统一、构建流程明确、去除删除操作和打包入世界块的准备。虽然还有部分未完成的系统，但基础框架已经搭建完毕，为后续系统整合和优化奠定了良好基础。
2025-05-14 10:20:42
841
原创 游戏引擎学习第277天:稀疏实体系统
通过将每种属性存储在独立的表格中，行为反应模型避免了传统面向对象方法中可能出现的继承复杂性，并且通过分离关注点，可以更灵活、有效地处理游戏中的状态变化和复杂交互。单一继承：简单且高效，适用于简单的对象关系。多重继承：提供了更大的灵活性，但也引入了指针调整问题，导致访问内存时需要额外的复杂性。动态修改继承结构的局限性：C++ 不支持在运行时修改继承结构，这使得在运行时动态添加功能变得困难，特别是在多重继承的复杂情况下。
2025-05-13 18:31:56
1034
原创 游戏引擎学习第276天:调整身体动画
键盘输入逻辑更接近最终游戏行为，输入更连贯且合理；操作行为更具容错性，能正确处理按键组合与释放的复杂情况；避免了输入状态卡住或角色原地停顿的状况；对未来整合美术资源及进一步优化动作系统打下坚实基础；“吸附机制”目前搁置，以维持操作自然性为优先。整体来说，我们对当前控制系统的状态感到满意，后续将继续在此基础上进行美术集成、碰撞检测等方面的进一步开发。居中吸附延迟机制已完成基本实现；输入触发、定时器更新和逻辑判断等流程已整合完毕；
2025-05-13 17:25:06
922
原创 游戏引擎学习第275天:将旋转和剪切传递给渲染器
准确表达玩家真实操作意图；避免因物理模拟造成的视觉抖动或翻转；视觉效果更加自然连贯；提高游戏操作的响应性与流畅感。这是一次重要的结构优化，我们将朝向控制的权力还给了输入控制系统，而不是物理系统，从而更好地服务于游戏的“可控性”与“手感”。头部移动与回弹效果我们已经实现了头部可以在角色运动时略微脱离身体，并通过一个“弹簧”机制（spring）将其拉回。这种效果带来了更自然的动态表现，尤其在角色快速变向或突然停止时有不错的惯性反馈感。头部朝向控制。
2025-05-13 12:35:07
1110
原创 游戏引擎学习第274天:基于弹簧的动态动画
构建了基于位置差和速度差的恢复力；将其应用于头部的速度更新；加入了“是否正在被控制”的判定机制，避免弹簧干扰正常控制；建立了头部与身体之间的引用关系，便于获取目标位置；不断调节弹簧系数，以找到合适的回弹强度；留下了后续优化空间（例如重构能量系统、完善状态管理等）。这样就实现了一个具备自然回弹的角色头部控制系统。通过这些改进措施，当前的头部恢复力系统可以得到更精确的控制。具体而言，添加速度阻尼和方向性偏移后，系统的稳定性和头部运动的自然性将得到增强。
2025-05-11 23:28:06
1419
原创 游戏引擎学习第273天:动画预览
动画的本质是构建“时间到状态”的映射函数 F(T)。B 样条是一种广泛使用且直观易控的函数构造方式，适合美术和动画设计师直观地调节动画曲线。但我们也完全可以脱离样条，使用任何数学函数只要它能根据 T 输出我们想要的动画状态即可。B 样条之所以常见，是因为它通用、灵活且对非程序人员也友好。这就是动画中 B 样条的完整结构与思维方式，既是强大工具也是一个思维框架。动画的本质是F(T) → 状态向量。状态向量自由设计，包含所有必须信息，用于渲染。
2025-05-11 16:55:38
1178
原创 游戏引擎学习第272天:显式移动转换
目前需要解决的问题是 Z 轴的处理一直存在一些问题，现在已经意识到它应该如何调整。接下来需要对 Z 轴进行一些调整，以确保它能够按照预期工作。
2025-05-11 12:04:56
992
Practical Algorithms for 3D Computer Graphics, Second Edition.pdf
2018-06-17
OpenCV Computer Vision Application Programming Cookbook Second Edition.pdf
2018-06-17
OpenCV 3 Blueprints.pdf
2018-06-17
OpenCV 2 Computer Vision Application Programming Cookbook
2018-06-17
Learning Image Processing with OpenCV.pdf
2018-06-17
A Practical Introduction to Computer Vision with OpenCV.pdf
2018-06-17
OpenCV Computer Vision with Python.pdf
2018-06-17
Arduino Computer Vision Programming.pdf
2018-06-17
OpenGL Programming Guide, 8th Edition
2018-06-17
OpenGL ES 3dot0 Cookbook
2018-06-17
OpenGL Data Visualization Cookbook
2018-06-17
OpenGL 4 Shading Language Cookbook, Second Edition
2018-06-17
Real-Time C++, 2nd Edition.pdf
2018-06-17
Procedural Content Generation for C++ Game Development.pdf
2018-06-17
Learning Boost C++ Libraries.pdf
2018-06-17
Functional Programming with C++
2018-06-17
Data Structures & Algorithm Analysis in C++, 4th Edition.pdf
2018-06-17
Data Clustering in C++.pdf
2018-06-17
OGLPG-9th-Edition.zip OpenGL编程指南代码(包括资源文件)
2019-10-23
OpenGL 4.5 Reference Pages API + GLSLangSpec.4.60 + glspec46.core
2019-10-22
OGRE 3D 1.7 Application Development Cookbook.pdf
2019-04-20
UNIX网络编程卷1：套接字联网API（第3版） (1).pdf
2019-04-14
Multicore and GPU Programming An Integrated Approach.pdf
2019-03-21
Game Programming Using QT.pdf
2018-06-17
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人