月光林地

序

以静态模型举例, 物理材质是配置在两个地方, 两个地方跟检测方式有关

如果是复杂检测的, 那么物理材质配置在每个材质内, 这个比较精确, 但是开销是非常感人的, 特别是有些次世代模型动辄上百万面

如果是简单检测, 物理材质是统一跟着模型走的, 也就是一个模型不管你配置了多少个碰撞盒子, 物理材质都只有一个, 看下图

图中的正方体和球各自有自己的碰撞框, 如果一个是金属的,一个是橡胶的, 那么此套方案就行不同了

直接贴代码

序

本文从应用角度分析一下UE的碰撞和检测系统, 模型主要看静态模型即StaticMesh, 骨骼模型涉及到物理资产的使用和编辑, 本文暂不做分析

前言

本文通过源码对动画通知进行深入分析

前言

记录UE开发时常用的数学方法

前言

说到Root Motion, 通常会想到的是Root Motion Animation, 将位移量嵌在Animation中, 角色Tick Pose时会计算frame之间的root bone的偏移量, 換算成velocity与acceleration, 然后PerformMovement, 如此可以表现到角色位移上, 但是在多人游戏中, Root Motion Animation是个不安定因素, 在网络延迟不稳定时, 玩家就会发生被Server拉回矫正的情况

Paragon中使用了RootMotionSource(下面简称RMS)这个技术, 策略是动画单独播放, 程序控制位移

RMS是一个非常规性的RootMotion技术, 本质上已经脱离了动画, 通过程序模拟来实现每一帧的根骨骼位移. 相比较手动SetActorLocation等等的暴力方式, 好处是这套流程是在角色移动组件里的(下面会细讲), 不仅使用方便也满足于角色移动同步流程.

前言

角色移动相关的林林总总

QA

• Q: 角色移动来自哪里
• A:
  • 按键输入
  • 物理力(Force)
  • Launch
  • 动画RootMotion
  • RootMotionSource
  • RequestVelocity
  • Gravity

• Q: 角色的Z方向是速度是哪里处理的?
• A: MaintainHorizontalGroundVelocity, 而且不止调用了一次; Z速度比较复杂, 地面移动的Z速度不能通过重写这个函数来找回

• Q:刹车是怎么处理的
• A:刹车/制动

• Q:怎么判断角色处于Falling
• A:空中判断

• Q:怎么处理角色处于边缘的情况
• A:14.1.9 边缘检查

• Q:速度和加速度是哪里 计算的
• A:14.1.3 CalcVelocity

• Q:有没有处理撞墙(Hit)事件的逻辑
• A:相比于监听Capsule的Hit回调事件, 移动逻辑里有一部分相关代码也是类似情形, 大致在这里

前言

本文专门记录最近对动画优化的一些研究和思考

参考文献

官方文档

TGDC

前言

之前虽然写过一些动画节点和AnimInstance相关的逻辑, 但是对整体动画模块的逻辑路线还是不是很熟, 所以本文大致研究一下

前言

以前的动画debug要么肉眼看动画蓝图, 要么用控制台来Show DebugAnimation搞得全屏幕的天书无从下手, 自从4.25以后动画模块有了一个非常友善的可视化Debug工具, 之前略有所知但是没有深入使用, 今天来研究一番看看这个工具可以干啥