可以参考Erin Catto的这个talk，从2D的角度出发对这个方向做了入门介绍。 https://box2d.org/files/ErinCatto_ContactManifolds_GDC2007.pdf “碰撞点”在物理模拟里更准确的说法应该是碰撞流形，具体的接触形状会随着时间演变。模拟中我们不可能像真实世界每个接触的分子都去计算，所以会选取等效的特征点来计算后续如何施加冲量、施加摩擦力。例如一个box平放在平面上，理论上整个一条底边都和平面接触，为了离散计算方便，最终使用的是两端两个顶点作为“碰撞点”。后续使用次序冲击法（Sequential Impulse）迭代求解的时候就是在这两个“碰撞点”上依次调整冲量。这部分Erin Catto的物理模拟系列talk（https://box2d.org/publications/）都有讲到，希望对物理模拟有深入了解建议系统学习一下，104讲到的部分仅仅把一些核心概念做了阐述，不足以作为实现整个物理模拟求解的参考。

利用GJK做碰撞检测之后怎么获取碰撞点

赞 1

评论 1

评论于 480 天前

Olorin

评论于480 天前

“ 可以参考Erin Catto的这个talk，从2D的角度出发对这个方向做了入门介绍。 https://box2d.org/files/ErinCatto_ContactManifolds_GDC2007.pdf “碰撞点”在物理模拟里更准确的说法应该是碰撞流形，具体的接触形状会随着时间演变。模拟中我们不可能像真实世界每个接触的分子都去计算，所以会选取等效的特征点来计算后续如何施加冲量、施加摩擦力。例如一个box平放在平面上，理论上整个一条底边都和平面接触，为了离散计算方便，最终使用的是两端两个顶点作为“碰撞点”。后续使用次序冲击法（Sequential Impulse）迭代求解的时候就是在这两个“碰撞点”上依次调整冲量。这部分Erin Catto的物理模拟系列talk（https://box2d.org/publications/）都有讲到，希望对物理模拟有深入了解建议系统学习一下，104讲到的部分仅仅把一些核心概念做了阐述，不足以作为实现整个物理模拟求解的参考。

利用GJK做碰撞检测之后怎么获取碰撞点

赞 1

评论 1

单纯注掉红框中的代码是会出问题的，那一行是和上面构造world_transform时加上的 0.1f * Vector::UNIT_Z 呼应的。判断角色控制器是否贴地时首先将当前位置向上偏移了 0.1m构造后续查询请求用的 world_transform，使用胶囊碰撞体向下扫掠 0.105m 检查是否贴地，然后再将 world_transform的偏移复原（向下偏移 0.1m，位置回到原来的 current_position）。如果要去掉红框中的代码需要对称去掉构造 world_transform 时向上的偏移，否则每一帧移动时都会强行把当前位置往下拉 0.1m。作为这部分代码的reviewer，我努力回想了一下一年前该作者实现这个作业时的想法：检查贴地时当时实现的第一个版本使用的场景请求是从胶囊碰撞体底部发射射线检测 raycast；射线检测存在的最大的问题是：如果起点已经穿插进入一个碰撞体，检测时该碰撞体会被忽略。于是考虑到浮点数精度或者初始位置可能导致的轻微穿插的情形，为了得到符合直觉的贴地检测结果，便先将射线检测的起点回撤了 0.1m，然后检测的射线多延长了 0.1m；后来测试又发现如果只是胶囊靠近底部其他部分接触到碰撞体而射线发射点悬空时，贴地检查又无法返回符合直觉的结果；最后将场景请求修改为胶囊体扫掠，而当时为了解决射线检测初始穿插问题的代码就留下了。而你很敏锐地发现了这一奇怪的做法，我也重新测试了一下，确实对称取消这个偏移功能依然是正常的。 PS：从这个开发过程也可以看到，游戏开发最大的难点在于，如何使用理性的代码去逼近人类微妙的直觉。

有人知道小引擎里CCT的move函数中这行代码是干嘛的么

赞 2

评论 1

评论于 560 天前

Olorin

评论于560 天前

“ 单纯注掉红框中的代码是会出问题的，那一行是和上面构造world_transform时加上的 0.1f * Vector::UNIT_Z 呼应的。判断角色控制器是否贴地时首先将当前位置向上偏移了 0.1m构造后续查询请求用的 world_transform，使用胶囊碰撞体向下扫掠 0.105m 检查是否贴地，然后再将 world_transform的偏移复原（向下偏移 0.1m，位置回到原来的 current_position）。如果要去掉红框中的代码需要对称去掉构造 world_transform 时向上的偏移，否则每一帧移动时都会强行把当前位置往下拉 0.1m。作为这部分代码的reviewer，我努力回想了一下一年前该作者实现这个作业时的想法：检查贴地时当时实现的第一个版本使用的场景请求是从胶囊碰撞体底部发射射线检测 raycast；射线检测存在的最大的问题是：如果起点已经穿插进入一个碰撞体，检测时该碰撞体会被忽略。于是考虑到浮点数精度或者初始位置可能导致的轻微穿插的情形，为了得到符合直觉的贴地检测结果，便先将射线检测的起点回撤了 0.1m，然后检测的射线多延长了 0.1m；后来测试又发现如果只是胶囊靠近底部其他部分接触到碰撞体而射线发射点悬空时，贴地检查又无法返回符合直觉的结果；最后将场景请求修改为胶囊体扫掠，而当时为了解决射线检测初始穿插问题的代码就留下了。而你很敏锐地发现了这一奇怪的做法，我也重新测试了一下，确实对称取消这个偏移功能依然是正常的。 PS：从这个开发过程也可以看到，游戏开发最大的难点在于，如何使用理性的代码去逼近人类微妙的直觉。

有人知道小引擎里CCT的move函数中这行代码是干嘛的么

赞 2

评论 1

热门排序需要调整，目前任何评论更新都会直接置顶，容易被挖坟

欢迎大家提意见

赞 2

评论 2

评论于 625 天前

Olorin

评论于625 天前

“ 热门排序需要调整，目前任何评论更新都会直接置顶，容易被挖坟

欢迎大家提意见

赞 2

评论 2

页面顶端的发帖按钮并不能一眼知道是用来发帖的，建议加上发帖两个字

欢迎大家提意见

赞 1

评论 1

评论于 625 天前

Olorin

评论于625 天前

“ 页面顶端的发帖按钮并不能一眼知道是用来发帖的，建议加上发帖两个字

欢迎大家提意见

赞 1

评论 1

创作等级LV1

会员等级 P1

6

获得点赞

5

获得评论

0

获得收藏

创作等级LV1

会员等级 P1

6

获得点赞

5

获得评论

0

获得收藏

可以参考Erin Catto的这个talk，从2D的角度出发对这个方向做了入门介绍。 https://box2d.org/files/ErinCatto_ContactManifolds_GDC2007.pdf “碰撞点”在物理模拟里更准确的说法应该是碰撞流形，具体的接触形状会随着时间演变。模拟中我们不可能像真实世界每个接触的分子都去计算，所以会选取等效的特征点来计算后续如何施加冲量、施加摩擦力。例如一个box平放在平面上，理论上整个一条底边都和平面接触，为了离散计算方便，最终使用的是两端两个顶点作为“碰撞点”。后续使用次序冲击法（Sequential Impulse）迭代求解的时候就是在这两个“碰撞点”上依次调整冲量。这部分Erin Catto的物理模拟系列talk（https://box2d.org/publications/）都有讲到，希望对物理模拟有深入了解建议系统学习一下，104讲到的部分仅仅把一些核心概念做了阐述，不足以作为实现整个物理模拟求解的参考。

利用GJK做碰撞检测之后怎么获取碰撞点

赞 1

评论 1

评论于 480 天前

Olorin

评论于480 天前

“ 可以参考Erin Catto的这个talk，从2D的角度出发对这个方向做了入门介绍。 https://box2d.org/files/ErinCatto_ContactManifolds_GDC2007.pdf “碰撞点”在物理模拟里更准确的说法应该是碰撞流形，具体的接触形状会随着时间演变。模拟中我们不可能像真实世界每个接触的分子都去计算，所以会选取等效的特征点来计算后续如何施加冲量、施加摩擦力。例如一个box平放在平面上，理论上整个一条底边都和平面接触，为了离散计算方便，最终使用的是两端两个顶点作为“碰撞点”。后续使用次序冲击法（Sequential Impulse）迭代求解的时候就是在这两个“碰撞点”上依次调整冲量。这部分Erin Catto的物理模拟系列talk（https://box2d.org/publications/）都有讲到，希望对物理模拟有深入了解建议系统学习一下，104讲到的部分仅仅把一些核心概念做了阐述，不足以作为实现整个物理模拟求解的参考。

利用GJK做碰撞检测之后怎么获取碰撞点

赞 1

评论 1

单纯注掉红框中的代码是会出问题的，那一行是和上面构造world_transform时加上的 0.1f * Vector::UNIT_Z 呼应的。判断角色控制器是否贴地时首先将当前位置向上偏移了 0.1m构造后续查询请求用的 world_transform，使用胶囊碰撞体向下扫掠 0.105m 检查是否贴地，然后再将 world_transform的偏移复原（向下偏移 0.1m，位置回到原来的 current_position）。如果要去掉红框中的代码需要对称去掉构造 world_transform 时向上的偏移，否则每一帧移动时都会强行把当前位置往下拉 0.1m。作为这部分代码的reviewer，我努力回想了一下一年前该作者实现这个作业时的想法：检查贴地时当时实现的第一个版本使用的场景请求是从胶囊碰撞体底部发射射线检测 raycast；射线检测存在的最大的问题是：如果起点已经穿插进入一个碰撞体，检测时该碰撞体会被忽略。于是考虑到浮点数精度或者初始位置可能导致的轻微穿插的情形，为了得到符合直觉的贴地检测结果，便先将射线检测的起点回撤了 0.1m，然后检测的射线多延长了 0.1m；后来测试又发现如果只是胶囊靠近底部其他部分接触到碰撞体而射线发射点悬空时，贴地检查又无法返回符合直觉的结果；最后将场景请求修改为胶囊体扫掠，而当时为了解决射线检测初始穿插问题的代码就留下了。而你很敏锐地发现了这一奇怪的做法，我也重新测试了一下，确实对称取消这个偏移功能依然是正常的。 PS：从这个开发过程也可以看到，游戏开发最大的难点在于，如何使用理性的代码去逼近人类微妙的直觉。

有人知道小引擎里CCT的move函数中这行代码是干嘛的么

赞 2

评论 1

评论于 560 天前

Olorin

评论于560 天前

“ 单纯注掉红框中的代码是会出问题的，那一行是和上面构造world_transform时加上的 0.1f * Vector::UNIT_Z 呼应的。判断角色控制器是否贴地时首先将当前位置向上偏移了 0.1m构造后续查询请求用的 world_transform，使用胶囊碰撞体向下扫掠 0.105m 检查是否贴地，然后再将 world_transform的偏移复原（向下偏移 0.1m，位置回到原来的 current_position）。如果要去掉红框中的代码需要对称去掉构造 world_transform 时向上的偏移，否则每一帧移动时都会强行把当前位置往下拉 0.1m。作为这部分代码的reviewer，我努力回想了一下一年前该作者实现这个作业时的想法：检查贴地时当时实现的第一个版本使用的场景请求是从胶囊碰撞体底部发射射线检测 raycast；射线检测存在的最大的问题是：如果起点已经穿插进入一个碰撞体，检测时该碰撞体会被忽略。于是考虑到浮点数精度或者初始位置可能导致的轻微穿插的情形，为了得到符合直觉的贴地检测结果，便先将射线检测的起点回撤了 0.1m，然后检测的射线多延长了 0.1m；后来测试又发现如果只是胶囊靠近底部其他部分接触到碰撞体而射线发射点悬空时，贴地检查又无法返回符合直觉的结果；最后将场景请求修改为胶囊体扫掠，而当时为了解决射线检测初始穿插问题的代码就留下了。而你很敏锐地发现了这一奇怪的做法，我也重新测试了一下，确实对称取消这个偏移功能依然是正常的。 PS：从这个开发过程也可以看到，游戏开发最大的难点在于，如何使用理性的代码去逼近人类微妙的直觉。

有人知道小引擎里CCT的move函数中这行代码是干嘛的么

赞 2

评论 1

热门排序需要调整，目前任何评论更新都会直接置顶，容易被挖坟

欢迎大家提意见

赞 2

评论 2

评论于 625 天前

Olorin

评论于625 天前

“ 热门排序需要调整，目前任何评论更新都会直接置顶，容易被挖坟

欢迎大家提意见

赞 2

评论 2

页面顶端的发帖按钮并不能一眼知道是用来发帖的，建议加上发帖两个字

欢迎大家提意见

赞 1

评论 1

评论于 625 天前

Olorin

评论于625 天前

“ 页面顶端的发帖按钮并不能一眼知道是用来发帖的，建议加上发帖两个字

欢迎大家提意见

赞 1

评论 1