新的点选系统

[cloudwu]

目前引擎支持从屏幕上的一个点找到选中的那个对象，它是通过 GPU 完成的。方法是给需要被点选的 entity 赋予一个独立的 id 。然后通过渲染流程，找到屏幕上那个点对应的 entity 的 id 。

最近我发现，另外一种需求也很常见：鼠标点中屏幕后，需要知道对应点在 3d 空间中的坐标，而不关心点中了什么。

这里可以有很多假设：需要点击的物件是静态的、简单的、不需要跟着场景变化。比如，在第三人称上帝视角的游戏中，我们可能只关心点击了地图的那块地板。

有了这些假设，实现会非常简单高效。

所以，可以有这么一个模块：

场景中有一个（或多个）用于处理鼠标点选的 entity ，它不参与渲染。运行期间可以把若干模型（以 prefab 的形式）添加到这个 entity 的内部数据中。而它内部的数据是由三角形构成，不区分物件。即，每次添加都拆解成若干三角形合并进内部 buffer 。

当需要点选时，传入一个屏幕坐标和摄像机的状态（默认为场景主摄像机），返回选中的点的 3d 空间的位置。

---

如果需要处理的只是平的地板，那么用两个三角形就可以描述；如果地板有起伏，则需要根据高度图换算成三角形，但不需要和场景中用于渲染的地表模型共用数据。

如果三角形不多，那么用简单的依次遍历的方式实现就很简单，性能应该也不错。毕竟，点选需求并不是每帧都要做的。如果以后遇到更复杂更多三角形的情况，可以考虑用复杂一点的空间结构组织内部的数据，把 O(n) 的过程优化为 O(log N) 。

[kentzhang-geek]

3d坐标直接取深度反算？entity独立id可以考虑直接并入材质系统或者gbuffer？但感觉实际还是不划算，N帧才会使用1次。或者可以考虑先用surface area启发式的bounding box ray tracing过滤出需要的object，然后单独绘制计算，输出1个点就行了，这样可能适用于手机。PC的话直接走一个cpu ray tracing得了。如果面数不高或者有lod并且可以牺牲一点点精度的话，手机CPU ray tracing应该都行。

[kentzhang-geek]

那么设计上我觉得应该是：

• depth reading
• double precision matrics, view and projection
• material override
• scene objects filter by ray and bounding box
• off screen render invoke entry, maybe integrate with frame graph?
• texture read back
• GPU&CPU sync framework

[kentzhang-geek]

哦是了，entity id可以并入材质id或者gbuffer之类的东西，然后需要的时候用shader开关去转换，如果是forward的话，就没有办法只能走CPU或者单独加速。

[cloudwu]

不要把问题想复杂了。我认为这个问题应该和场景分离开作为独立问题处理。

这个问题本质上：

1. 结果是屏幕像素根据摄像机的方向，向 3d 空间上投射的射线上的一个点。所求是单个距离值。
2. 需要找到会阻挡这条射线的模型中最近的一个或几个（如果有重叠）
3. 找到具体和射线相交的三角形，求交后取得交点。

大多数情况下：

1. 需要接收屏幕点选的模型并不多也不复杂，甚至和用于渲染的模型不是同一个。比如，如果只有一个平坦的地面，只是想获取鼠标点击地面上的位置。那么只需要构建两个三角形就够了。而用于渲染地面的网格可能有几千个三角形。
2. 用于计算点选位置的模型是不变的，不需要跟着场景变化。所以不需要和用于渲染的场景耦合在一起。甚至不需要以模型网格为单位。也可以有独立的空间划分方法（如有性能优化的必要）。
3. 点选只在鼠标点击时发生一次。

所以，即使在 GPU 中有潜在的性能收益。但和实现复杂度相比，未必划算。

[kentzhang-geek]

单独考虑，按你说的情况去考虑那取id就是这种搞法了。取坐标的话用screen depth就很耿直，而且够用。

[cloudwu]

取坐标的话用 screen depth 精度往往不够，尤其距离较远的会偏差非常大。

[kentzhang-geek]

取坐标的话用 screen depth 精度往往不够，尤其距离较远的会偏差非常大。

还是可以尝试的，用python就能够做一些实验，主要是看depth空间能不能搞一些优化，以及较远的object的坐标精度问题。
我知道的两个depth空间操作：

• 根据场景bounding box去计算projection matrix的near和far，这样可以减少一些depth数值上的浪费
• 非线性depth，看过眼但是没仔细看……应该很多书上都会有
  这两个操作弄下来之后，depth空间上的数值映射应该就是比较均匀的了，误差足够小。如果near值足够大，far值足够小，非线性深度都可以不用的。

较远坐标的精度问题，我尝试过全双精度渲染，手机上肯定不行，台式机上也需要小心处理，会有一个vertex attribute超过192bit或者256bit然后性能急剧下降的问题，这个是实验出来没有很确切的线索。但是双精度在坐标值大的情况下肯定得用，这上面的技巧是用双精度浮点把误差在CPU阶段解决，到GPU阶段只是单精度就足够了，甚至可能半精度都足够

• project matrix，view matrix这两个直接用双精度，不放入GPU
• GPU shader里面的position不使用世界坐标（太大）
• 坐标值大的item，一定要拆分出model matrix（双精度），剩下的vertex position单精度就足够
• CPU阶段直接结合project, view, model这三个双精度matrix，误差就能解决，转换成单精度放进shader就可以了
  这样干的话，深度冲突解决，深度精度按理来说应该也是能够支撑点选坐标……虽然我之前好像是暴力双精度buffer取值……
  cesium的3d-tiles标准里面引用过一篇文章专门讲精度问题，好像有3个solutions我这里提到的是2种……搞GIS之类的肯定会遇到这种问题……

[julywind168]

mmo 游戏，非常需要这个东西 ～

[Tianze-Chen]

我觉得这可以理解成一种“不渲染的Mesh”
比如说“空气墙”，“碰撞体积”等等，这些都可以理解为“mesh”，但它们并不会被传递到gpu，不会用来渲染。

基于ecs架构来做这部分数据的设计会非常舒适，假如这样设计：

Entity	Component-Mesh	Componenent-Render	Component-Touchable	Component-AirWall
entity1	✅	✅	❌	❌
entity2	✅	❌	✅	✅
entity3	✅	✅	✅	✅

很显然，mesh被绑定到entity的时候我们并不在乎它具体是用来做什么的，而我们对应的system也只需要 select 出自己关心的那部分数据（比如 "mesh:in touchable:in"？）
而当我们想要在游戏界面中查看mesh(可点击区域)的设置是否错误，只需要如表格中的entity2绑定一个简单的render组件就可以了