推荐一个支持定点数的物理引擎 Rapier，物理帧同步刚需

Creator 3.x
#84

哦哦 我说的是 rapier 创建了 rigidbody后 怎么和图片绑定一起。不然看不见

#85

你图片的spirte不是绑在节点上麻, 你控制节点世界坐标不就行了

#86

不太明白你的意思,你需要自己实现一套物理组件来替换引擎自带的rigidbody,各种collider,和图片没什么关系啊

#87

就是

      // 创建一个动态刚体
      const rigidBodyDesc = RAPIER.RigidBodyDesc.dynamic().setTranslation(
        0.0,
        1.0
      );
      const rigidBody: RigidBody = world.createRigidBody(rigidBodyDesc);

      // 为动态刚体创建碰撞器
      const colliderDesc = RAPIER.ColliderDesc.cuboid(0.5, 0.5);
      const curCollider: Collider = world.createCollider(colliderDesc, rigidBody);
      curCollider.setDensity(10);

我创建刚体后。 怎么和图片绑定。这样的刚体是看不见的。
和图片绑定后才可以看得见。就像 creator。有Sprite组件才能看得见。
也就是 这个rapier的刚体怎么和Sprite绑定。

#88

是不是只能在 update里 根据刚体的坐标 设置 当前Sprite的坐标

#89

你猜你的意思是希望刚体可视化， 可以在调试时看到吧？
如果是2d， 你用cc.Graphic 把所有刚体画出来
如果是3d， 可以用 几何渲染器（Geometry-Renderer）

#91

你这样当然也可以,但是还是应该有组件思维,自己在rapier基础上模仿引擎自带的组件API封装一套自己的物理组件

#93

那就只能引擎在脚本update 调用一次step然后再把step后的刚体与你相应节点同步， cc自带那理物理引擎也是帮你封装了而已， 但是如果你是网络多人游戏， 不可能把step调用放到脚本update里， 因为每个人的设备update不同导致帧数不统一， 一様会出现表现不一致

#94

你说的对 问的就是这个意思 。

#95

帧同步就是放 update 里面，只是根据同步状态可以跳过 update 而已

#96

参考引擎的物理组件API自己实现一套,这中间涉及很多细节的,不是一句两句能解决的,坑也很多的,中心思想就是已rapier 为核心来运行整个游戏,懂得一点就透,不懂的爱莫能助啊

#97

可能是这样的.

rapier2d
rapier2d600×525 2.61 MB

#98

不会放在脚本的update里， 一定是自己按服务器推来的消息来调，因为你要确保是所有设备的物理逻辑帧都是一致的， 不然a设备跑了 80帧， b设备cpu较差跑了78帧， 然后a认为在79发的碰撞在b这边认为是第78帧发生碰撞， 立马结果不一致。 放update 里的可能是你clone了一个物理世界作为渲染预测表现， 一切最终决定还是以基于服务端消息驱动的物理世界为准。

#99

当然是服务器驱动，但是你没实践过，如果按照你说的做，一秒30帧的情况下，网络延迟1帧玩家就会看到画面卡顿，所以必须缓存帧消息然后通过定时器驱动。我上个月刚做的帧同步游戏就是用的 cc.director.getScheduler().scheduleUpdate

#100

我之前用这物理引擎做了类比卡兵的1v1打球游戏， 基于服务器驱动下有插值运算， 以及一定的本地预测，你看像王者， 网络极差甚至去到断线， 会出现你自己还能动， 但其他对手可能一定走到撞墙或不动的情况。至于为甚麽我説不用脚本的update是因为脚本那个update可能会跟你屏幕刷新率变成高刷， 你最终还是要有自己的定时器来处理， 反正最基本都是有服务器逻辑帧与本地预测逻辑帧。但是发生碰撞事件， 这种必须是全端一致在相同服务器逻辑帧下触发， 不然只差一帧的碰撞整个物理演变都不一致

#101

在本地帧执行对应服务帧任务是最基础的，服务器驱动整个游戏进度，客户端用定时器驱动本地游戏逻辑，至于用什么定时器可以自己决定，我使用update就是因为和引擎的渲染同步

#102

那应该是你做的时候已经用了cc3.X版， update做好固定帧了， 但如果你是在2.x时做的， 在不特意宣告渲染帧率为31/61的情况下，cc的update 是跟刷屏率，导致了A手机90hz， B手机120hz，这时如果把物理step写在脚本update里的结果就是GG两边物理步完全无法一致

#103

不可能不同步，那是你自己帧逻辑没写对，正确的逻辑即使一边 update 快无数倍，帧逻辑也是同步执行，我之前也已经说过了

#104

只是根据同步状态可以跳过 update 而已

你自己都説了， 为甚麽要根据状态跳过update，不就是让物理引擎不要执行step更新世界， 不也是为了确保所有端触发碰撞都是在同一个物理step触发麻， 我一直想表达都是， 如果单纯把这个物理引擎的step 放到update里一定会gg， 如果物理世界a执行了5个step后拖加力， 和物理世界b在10个step后才施加力， 两就算所有参数一致， 物理渲变结果也会不一様， 最终要确保是双方都在同一个step下施加力

#105

你把 update 和 step 搞混了，update 次数并不影响帧 step 的目标次数，而且你的问题还在说对应本地帧没有执行对应服务器帧逻辑导致的问题，物理世界的 step 和本地逻辑帧 step 是同步的，而不是和引擎 update 同步