皮皮网

1.【Unity3d FootIK】写一个最简单的骨骼骨骼IK（1）
2.UE4源码剖析——Actor蓝图之CDO与SCS
3.Spine界面与Unity组件代码直观对应（未完待续）
4.基于DOTS的大批量骨骼动画方案及实现
5.老师问问3DMAX骨骼的问题BOne骨骼怎样导出bip
6.DynamicBone（动态骨骼）MagicaCloth的优化策略（4）

【Unity3d FootIK】写一个最简单的IK（1）

       前言：

       历经无数次尝试与调整，终于找到了在Unity环境中实现FootIK的源码源码基本方法。整个过程虽然充满了挑战，绘制但学习到的骨骼骨骼知识与技巧却让我感到收获满满。

       预备设置：

       为了使用Unity内部的源码源码IK系统，我们需要进行以下步骤的绘制跨境购朔源码设置。

       1. 为FBX模型设置Humanoid Avatar，骨骼骨骼确保在Avatar设置界面中正确绑定骨骼。源码源码

       2. 创建并配置AnimatorController，绘制激活特定层级的骨骼骨骼IK Pass功能。

       3. 编写脚本，源码源码声明OnAnimatorIK方法，绘制用于处理IK解算。骨骼骨骼

       创建FootIK脚本：

       1. 定义脚本中的源码源码变量，这些变量将用于后续算法的绘制执行。

       2. 在FixedUpdate函数中获取骨骼信息，计算IK位置。

       3. 编写AdjustFeetTarget方法，获取脚部Transform的位置，并进行调整以避免模型穿模。

       4. 实现FootPositionSolver方法，使用Raycast检测地面位置，计算旋转角度。

       动画曲线设置：

       在动画中，脚部抬离地面时，需通过动画曲线调整IK目标的权重。通过在FBX Inspector中配置动画曲线，根据动画片段的不同阶段，设置合适的sysvinit源码权重值，以实现脚部自然抬起与落地的效果。确保在Animator面板中正确添加Float参数，以便在播放动画时动态调整。

       实践与原理：

       1. 整理脚本并将其应用到角色GameObject上，激活IK功能，通过设置目标层级，使角色能够在阶梯上自然行走。

       2. 讲解算法原理与流程，包括使用简单射线检测计算IK位置，以及在OnAnimatorIK方法中，通过动画曲线动态调整权重，影响骨骼位置。

       揭秘Unity IK本质：

       深入理解MoveFeetToIkPoint方法的工作原理，包括transform坐标变换、Animator的Getter与Setter机制。发现IK Goal实际上包含了与地面的偏移信息，并通过yVar变量进行动态调整，确保角色脚部贴合地面，防止穿模。了解Unity内部动画计算流程与IK应用顺序，揭示了为何增量赋值能有效控制角色行走。

       小结：

       通过解析Unity内置的IK系统，对功能插件的原理有了更深入的理解。展望未来，希望能够探索更多高级的IK实现方法，如Final IK与AnimationRigging，进一步提升角色动画效果。同时，fdm源码源代码的分享将为社区开发者提供参考与灵感，促进Unity生态的共同进步。

UE4源码剖析——Actor蓝图之CDO与SCS

       在UE的日常使用中，蓝图（UBlueprint）是我们接触最多的资产类型。每个蓝图在创建时需要选择一个父类，这决定了蓝图的类型，比如Actor蓝图、Component蓝图、Widget蓝图、动作蓝图等。以Actor蓝图为例，本文将深入探讨蓝图的基础架构，并学习如何通过代码读取蓝图资产在蓝图编辑器中的属性值。此外，本文还将重点介绍如何利用SCS框架管理新组件，并在运行时加载这些组件。

       在实际开发中，我们经常需要对蓝图进行处理，例如在大型项目中，制定一套资源规范并开发一套资源检测工具。这些工具往往需要遍历特定目录下的蓝图并执行某些条件判断和处理。本文将帮助大家了解如何实现这些功能。

       **实战需求**：

       1. **例1**：要求所有放置在“Buildings”文件夹下的蓝图必须包含`StaticMeshComponent`组件，且`StaticMesh`字段不能为空。

       2. **例2**：要求“Cars”文件夹下的所有蓝图的`SceneComponent`组件移动性必需为`Movable`。

       **蓝图的父类与Actor蓝图**：

       1. **蓝图的父类**：创建蓝图时，编辑器面板中选择的父类决定蓝图的类型，例如`TestActorChild2`的pplns 源码父类为`TestActorChild1`，而`TestActorChild1`的父类为`TestBlueprintActor`。

       2. **Actor蓝图**：若蓝图的父类层级链最顶层是`Actor 类`，则该蓝图为`Actor蓝图`。

       **蓝图产生类**：蓝图的`_C`后缀代表蓝图产生类，它用于在编译时生成C++类，包含蓝图中的信息。

       **蓝图类（UBlueprint）**：加载蓝图包时，通过`LoadObject`函数获取到的是`UBlueprint`类。

       **蓝图骨骼类（SkeletonGeneratedClass）**：以`SKEL_`前缀和`_C`后缀加载，表示蓝图的基础信息，通常在编辑器中修改时会重新生成。

       **蓝图产生类（GeneratedClass）**：仅以`_C`为后缀加载，用于在运行时创建蓝图对象。

       **前后缀声明**：`UBlueprint.h`中的`GetBlueprintClassNames`函数定义了这些前缀。

       **Actor蓝图产生类的实例化与阶段拆分**：

       1. **CDO的构建**：`ClassDefaultObject`是每个类的默认对象，用于提供默认属性值和行为。

       2. **SCS组件附加**：通过蓝图编辑器的组件面板添加组件，这些组件存储在`SimpleConstructionScript`中，用于在运行时添加组件。

       **CDO与SCS**：

       - **CDO**：存储默认属性值与行为，节省数据传输和存储，支持配置化。

       - **SCS**：简化组件添加过程，通过蓝图编辑器直观操作组件。

       **需求回顾与实现**：通过遍历CDO和SCS，判断组件属性值，实现特定条件的检测，如`StaticMeshComponent`的jqk源码`StaticMesh`字段是否为空。

       本文从实际需求出发，全面介绍了蓝图的基本概念、内部分类、构建流程以及如何利用SCS管理组件。希望本文内容能帮助开发者更深入地理解蓝图的工作原理，提高资源管理与组件处理的效率。

Spine界面与Unity组件代码直观对应（未完待续）

       对于不太熟悉Spine制作流程的开发者，理解源码可能会感到困惑。下面，我们将通过直观的和代码对应来帮助理解。

       首先，让我们看下Spine的层级结构图，它清晰地展示了整个骨架的组织层次，就像一个树状结构，每个骨骼（Bone）都有多个子骨骼。

       在代码中，骨骼与Spine中的槽（Slot）概念相对应。槽记录了其关联的骨骼，它们之间的关系在代码中体现得一目了然。

       至于骨骼上的视觉元素，"占位符 + 带网格的"在代码中表现为MeshAttachment，它是图形数据的承载者。

       动画控制是Spine的核心部分。面板中的所有动画动作都集中在这个区域。动画动作由多个Timeline构成，这些Timeline记录了美术设计的每一帧关键帧，控制着对象属性的变化过程。

       举个例子，如果美术在动画中对网格顶点位置进行了关键帧设计，那么在代码中对应的子类就是DeformTimeline，它专门负责处理这类几何变形的动画变化。

基于DOTS的大批量骨骼动画方案及实现

       本文主要探讨如何基于Unity的DOTS（Data-Oriented Technology Stack）实现大规模骨骼动画的高效绘制。传统Unity骨骼动画依赖于SkinnedMeshRenderer，然而其在绘制大批量角色时，GPU绘制效率不高，主要瓶颈在于CPU将绘制数据提交给GPU。SkinnedMeshRenderer不支持静态合批、动态合批、GPU Instancing，导致无法有效解决此问题。

       已有方案如将动画烘焙为纹理并使用GPU Instancing来绘制骨骼动画，但这种方法存在局限性，如实现动画淡入淡出（Cross Fade）较为复杂且效率低下。而DOTS提供的解决方案虽在GitHub示例中已有提及，但其功能尚不完整，需要自行实现一套骨骼动画系统以满足项目需求。Unity Roadmap已经预告了Animator的开发，但具体发布时间尚不可知。

       本文基于官方的DOTS示例，构建了一个最小可用的骨骼动画播放系统，并在项目中应用。系统源码使用Entities版本为1.0.，推荐使用Unity .3.5f1c1打开。以下为系统构建步骤。

       1. 骨骼动画基本原理

       回顾骨骼动画原理，程序实现时，所有骨骼初始位于模型坐标系原点，便于计算。每一帧AnimationClip保存对应骨骼的变换矩阵，标记为[公式]。动画播放时，读取对应骨骼的变换矩阵与顶点初始坐标[公式]相乘，得到顶点最终坐标[公式]。

       若程序直接实现骨骼蒙皮动画，美术人员将反对，因所有骨骼置于模型坐标系原点，模型无法观看。因此，美术在模型制作软件中需正常摆放骨骼，初始姿势命名为BindPose，人型模型类似字母“T”，称为T-Pose。模型导出时需连同“从BindPose转换回局部空间的变换矩阵”一同输出。动画播放时，顶点位置需从“BindPose位置”变换至“相对于模型局部空间原点的位置”，再变换至“动画当前帧的位置”。

       2. 搭建Deformation底层

       本文基于Unity官方的DOTS示例进行开发，首先移植示例代码。主要实现步骤包括：

       Deformation数据：通过Package Manager安装com.unity.entities.graphics包后，运行时自动为SkinnedMeshRenderer生成Entity。组件中重要的是SkinMatrix，用于存储当前帧蒙皮变换后的矩阵，通过PushSkinMatrixSystem提交到GPU。

       Deformation蒙皮数据烘焙：将SkinnedMeshRenderer数据烘焙成Entity可访问的组件数据。最终生成组件包括SkinMatrix、AnimationRequest（用于接收动画请求的DynamicBuffer）、BindPose逆矩阵等。

       Deformation骨骼数据初始化：在数据烘焙完成后，单独一个System初始化每根骨骼的Entity组件数据，包括SkinMatrix等。

       计算变换矩阵：准备数据后，通过CalculateSkinMatrixSystemBase计算最终变换矩阵。

       Shader：直接访问由CPU端传入的二进制byte数据，通过解析ByteAddressBuffer在Shader中使用SkinMatrix数据。实现GPU骨骼蒙皮算法。

       3. 动画控制

       实现动画播放器，包括以下功能：

       - 自定义动画格式：通过ScriptableObject定义SkinnedMeshAnimationClip，包含位置和缩放曲线、旋转曲线。

       - 动画控制逻辑：接收动画播放请求，加载动画片段数据，通过BakedCurve转化为运行时数据AnimationCurveCache，最终设置到骨骼上。

       4. 调用播放动画接口

       实现接口，通过两步操作让指定角色播放动画。利用Frame Debugger观察，+个角色只有一个Batch，实现了高效绘制。

       5. 总结

       本文构建的DOTS骨骼动画系统，在满足基本功能的基础上，实现了大规模骨骼动画的高效绘制。这套系统在DOTS中补充了基础系统，为使用DOTS制作3D游戏的开发者提供了基础设施，满足了特定项目需求。

老师问问3DMAX骨骼的问题BOne骨骼怎样导出bip

       3dmax骨骼常见的有默认BONE骨骼CS骨骼 CAT骨骼

       其中 CS和CAT骨骼 都有自带的绑定姿态配置文件 以及动作文件

       比如 CS骨骼的姿态配置文件为.FIG在开启绑定编辑姿态按钮后点保存和读取按钮 输入命名保存读取即可在关闭绑定编辑姿态后 相同位置的按钮 保存读取的是.BIP动画文件

       CAT骨骼一样在 不点击开启 动画状态(加入任意动画层 并且按下 绿色向右箭头按钮) 的时候就是编辑状态 编辑完毕可以点主骨骼在修改面板进行预设保存 以后也可以从那里读取 开启后则可以将动画层的数据进行保存 复制 粘贴操作

       由此 CS CAT骨骼都是可以直接在一个文件做好以后 用配置文件在其他场景操作即可

       唯有例外就是默认骨骼是个例外默认骨骼需要进行群集定义以后才能有上诉功能

DynamicBone（动态骨骼）MagicaCloth的优化策略（4）

       首先，让我们跳过官网链接，直接进入MagicaCloth（MC）的优化策略探讨（4）。

       一、MC的延时策略

       在Unity Chan示例工程中，当我们导入MC包并调整MagicaPhysicsManager配置时，Update的设置至关重要。默认情况下，UpdatePerSeccond为帧/秒，UpdateMode设为Unscaled Time，这意味着无论游戏帧率如何变化，物理引擎都会执行。然而，这可能导致一帧内计算多次，影响性能。

       将UpdateLocation设为After Late Update，意味着模拟会在Unity的LateUpdate后进行。在原有配置下，运行游戏并进行性能分析，切换到Delay Unscaled Time模式后，可以观察到主线程在JobHandle的Complete调用前不再阻塞，从而优化了计算顺序。

       二、MC的更新控制

       MC巧妙地利用了延迟更新机制，通过MagicaPhysicsManager.cs中的代码，将模拟更新推迟到AfterRendering执行。即时更新时，会阻塞主线程；延时更新则在渲染后才完成模拟。这种设计确保了骨骼动画的正确同步，同时节省了等待时间。

       三、PlayerLoopSystem的深入理解

       Unity的Update并不止于Start、Update等，PlayerLoopSystem提供了更细致的时序控制，允许开发者在引擎子系统之间插入自定义更新点。MC通过自定义PlayerLoopSystem，将更新时机插入到AfterRendering，实现了精细的Job调度。

       总结

       通过源码解析，JobSystem和PlayerLoopSystem的结合使得MC的性能优化显著。虽然本人尚不足以深入理解其复杂设计，但对MC的创新设计深感佩服。DB系列研究至此告一段落，期待更多高手在此领域发挥创意。