[求助]中彈判斷

coolpay64

某最近在想這個問題，如果在一個3D/2D彈幕／第一身射擊遊戲當中
經常要判斷體是否和玩家接觸／是否中彈
除了使用r^2=x^2+y^2+z^2
看看物體和玩家的距離是否在一定數值下決定是否中彈外
但每個物件也這樣偏，FPS少過10也是不奇的
還有沒有其他的方法作判斷呢?
某是用C/C++的，年資尚淺，希望大大們指教

shawind

我看现在别人作碰撞，都是利用一些数据结构来加速碰撞检测。
其中最典型的就是OCTree（八叉树），把整个游戏世界中的物件分到八个区域中去。
位于不同区域中的物体肯定是不会碰撞的。
这样计算量就小多了（一般来说是减少90％左右）。
CPU全开是10FPS的话，CPU负荷减90％左右，30FPS以上就不成问题了。
更具体的，我也不是太懂。（3D编程也还在继续学习中。）

ps.也有偷懒的办法，就是利用别人现成的物理引擎，来做碰撞检验。

coolpay64

現成的好像有點兒那個。。。
但分成Octree好像也還是返回畢定理的原點呢
而且多數物體還是會集中在Player身次的區域吧，STG的話

shawind

3D stg 的话，一般来说，不可能有50％以上的子弹集中在的主角面前的1/8区域吧。
这样玩家就无法体验到飞行的乐趣了。（没地方可飞-_-!）

多集中在player身边的是2D式stg吧，这就不用OCTREE了。
还有就是碰撞的精度到底要多精确的问题了。
玩2D stg的人都会发现，子弹擦过自机的机翼时，往往不会出现击中判定（碰撞）。
而击中机身中间等区域才会有碰撞。
这是因为实际用来进行碰撞检验的是一个处于飞机图形内部的规则矩形。
用规则的矩形，圆形来作碰撞检验，速度是非常快的。（AABBs碰撞检测）

用现成的物理引擎不是很常见么？（有很多可无偿用在任何软件中的，如ODE）
毕竟不是所有人都精通物理，数学的。
有时候，自己去实现一个，不但是重复发明轮子，
而且自己做的老爷车，怎么可能跑得过别人开发出来的BMW呢？
（特别是对于像我这样的非专业人士 OTL）

coolpay64

那先下了ODE的說明先看，謝過大大~

duzhi5368

八叉树多是开放空间地图拣选,预读使用的.
在射击类游戏中对射击判断,使用八叉树的实在少见.还望楼上那位大大给个例子看看.
射击碰撞检测都是将当前场景的所有模型投影到深度缓冲中,根据射线原理,获得子弹在模板缓冲中的2维坐标,来进行判断的.
简单一句话,就是相当于3D游戏中的鼠标拣选.演算之后其实还是2D判断.

shawind

似乎没人说八叉树可以直接进行碰撞检验。
但把八叉树用于优化碰撞检验的例子很多，你可以GOOGLE一下。

mocilol

弹幕碰撞检测一般不需要优化，假设屏幕上1000个对象，全部和2位主角检测一遍也只是2000次，没有多少消耗。

需要优化的情况是所有物体都会互相碰撞，比如子弹和子弹间的碰撞，这样就必须优化

h5nc

首先，最好制作基本稳定的FPS，然后检查别的方面有没有问题，计算方面的开销远远小于渲染，10FPS的话，除非是显卡问题，否则就是每颗子弹都用了特效而且数量上万。
如果确认不是这方面的问题，那么以3d弹幕为例，首先AABB筛去本帧不会相撞的子弹，使用循环遍历子弹的时候，子弹行动后对Player进行检测，这一步骤就是判断x，y，z三个轴是不是均大于判定半径+子弹半径，这样可以消除屏幕上绝大部分的子弹。

在AABB内的才开始计算圆的公式，但即便是3d情况下你也只需要检测2d碰撞（一个切面的判断），正圆就是最简单的半径平方的计算，这段时间几乎可以忽略。

椭球体的话，想法依旧相同，你需要子弹相对于坐标系的运行角度，这个应该在你的速度矢量中得到了。目前我采用的椭圆判定方法是坐标变换，也许会有更好的办法，但是这已经足够速度了。首先将原点想象为椭球横切面的中心，长短轴作为x，y轴，然后算出Player中心在这个坐标系的x，y位置，然后满足椭圆公式，其中用到了同一个角度的sin和cos，同时平方和乘法的效率几乎忽略的话，耗费仍旧是一个三角函数的时间，最多大约需要170个CPU周期（没记错的话）

10FPS是不正常的数值，不要告诉我你用GDI做的……