Frustum Testing -- Bounds/Point/Occlusion

测试一个特定的渲染物体是否在一个特定的相机视锥中:

1  //returns true if renderer is within frustum
2     public static bool IsRedererInFrustum(Renderer renderer,Camera cam)
3     {
4         Plane[] planes = GeometryUtility.CalculateFrustumPlanes(cam);
5         return GeometryUtility.TestPlanesAABB(planes, renderer.bounds);
6     }

GeometryUtility.CalculateFrustumPlanes 得到的是相机视锥的六个平面(上下、左右以及前后) 我将其各自的法线画出来了:

不难理解这里这六个平面

经过测试 渲染的物体 无论是部分还是全部在视锥中,该结果均为true

测试某一特定的点是否在相机视锥中:

 1 //returns true is the point in the frustum
 2     public static bool IsPointInFrustum(Vector3 point,Camera cam,out Vector3 viewPortLocation)
 3     {
 4         Bounds B = new Bounds();
 5         B.center = point;
 6         B.size = Vector3.zero;
 7
 8         //construct frustum planes from camera
 9         Plane[] planes = GeometryUtility.CalculateFrustumPlanes(cam);
10
11         bool isVisible = GeometryUtility.TestPlanesAABB(planes, B);
12
13         viewPortLocation = Vector3.zero;
14
15         if (isVisible)
16         {
17             viewPortLocation = cam.WorldToViewportPoint(point);
18         }
19         return isVisible;
20     }

可以考虑点为上一种渲染物体的特殊情况,其边界大小为0

考虑物体在相机之中,并且测试没有occlusion时 :

 1  public static bool IsVisible(Renderer renderer,Camera cam)
 2     {
 3
 4         //whether is in  camera frustum
 5         if (IsRedererInFrustum(renderer, cam))
 6             return !Physics.Linecast(renderer.transform.position, cam.transform.position);      //whether there‘s no objects between the two objs..
 7
 8
 9         return false;
10     }

判断条件除了物体在相机视锥中,并且与相机之间有无其他物体挡住

通过二者之间的物理射线检测来实现

//适用: 第三人称角色扮演   检测控制的角色是否到被场景遮挡的地方

//--另行补充--

时间: 2024-10-11 14:56:35

Frustum Testing -- Bounds/Point/Occlusion的相关文章

Unity3d游戏场景优化杂谈(4)

首先介绍下draw call(这个东西越少你的游戏跑的越快): 在游戏中每一个被展示的独立的部分都被放在了一个特别的包中,我们称之为“描绘指令”(draw call),然后这个包传递到3D部分在屏幕上呈现出来.这就和你希望你的亲友收到准备好的圣诞礼物需要包装好然后穿过城市准时放在他应该出现的地方一样没什么不同.你的CPU来完成包装和传递他们的活,同时会消耗很多的带宽,所以最终分配好这些关键性资源很重要.目前,真正可怕的事情是从描绘指令消耗远景开始,每一个独立的飞溅到地板上的血迹和一个角色或者一具

outdated: 44.3D Lens Flare With Occlusion Testing

这样的光晕如何实现? 其实也就是几个贴图.变着法贴,比如,变大变小贴,变着颜色贴,变着透明度贴,换着距离贴. 下面为代码,其中用到了一些很简单的数学知识. #ifndef AFX_GLFONT_H__F5069B5F_9D05_4832_8200_1EC9B4BFECE6__INCLUDED_ #define AFX_GLFONT_H__F5069B5F_9D05_4832_8200_1EC9B4BFECE6__INCLUDED_ #include <Windows.h> #include &

Hierarchical Z-Buffer Occlusion Culling

While I was at GDC I had the pleasure of attending the Rendering with Conviction talk by Stephen Hill, one of the topics was so cool that I thought it would be fun to try it out.  The hierarchical z-buffer solution presented at GDC borrows heavily fr

关于Depth Bounds Test (DBT)和在CE3的运用

Depth Bounds Test (DBT) Depth Bounds Test(深度范围检测),是Nvdia GeForce 6系列以后显卡的特性(GPU Programming Guide GeForce 8 and 9 Series),并不是DirectX的特性.所以在例如Nsight和Pix的图形分析工具里,是看不到它的设置的. Depth Bounds Test的功能是允许程序员在blend render target前进行额外的像素Discard.这个扩展增加了一个新的逐个frag

Libgdx New 3D API 教程之 -- Libgdx中的3D frustum culling

This blog is a chinese version of xoppa's Libgdx new 3D api tutorial. For English version, please refer to >>LINK<< 我要偷懒了,好久没看LibGDX,也很久没看3D,新教程的题目我就不懂了.不过看了课程的内容,相信你们都会理解. 正文: 当渲染一个3d场景时,其中真正可见的对象通常都比总对象数少很多.因此渲染全部的物体,包括那些根本看不到的,即浪费了富贵的GPU时间,

Occlusion Culling遮挡剔除理解设置和地形优化应用

这里使用的是unity5.5版本 具体解释网上都有,就不多说了,这里主要说明怎么使用,以及参数设置和实际注意点 在大场景地形的优化上,但也不是随便烘焙就能降低帧率的,必须结合实际情况来考虑,当然还有透明物体问题和动态物体的剔除等等都将详细说明. 首先说一下烘焙的关系 因为unity摄像机自带视椎剔除(Frustum Culling),所以如果都是动态物体,那么只有视椎剔除,可以在bake过后通过camera的occlusion culling里面的visualize看出,其实不baked话也是有

iOS开发UI基础—手写控件,frame,center和bounds属性

一.手写控件 1.手写控件的步骤 (1)使用相应的控件类创建控件对象 (2)设置该控件的各种属性 (3)添加控件到视图中 (4)如果是button等控件,还需考虑控件的单击事件等 (5)注意:View Contollor和view的关系 2.注意点 在OC开发中,Storyboard中的所有操作都可以通过代码实现,程序员一定要熟练掌握代码布局界面的能力! 设置控件监听方法的示例代码如下: [btn addTarget:self action:@selector(click:) forContro

Objective-C日记-Bounds和Frame

今天在学习有关UIView时,关于Bounds和Frame的问题困扰多时,今日研究了一翻,有所收获,遂记之. 一.问题来源 网上有关bounds和frames的比较的文章主要就是一篇:http://blog.csdn.net/mad1989/article/details/8711697,核心思想是bounds的坐标系是相对于自己而言,而frames的坐标系是相对于父视图,主要的演示代码如下: UIView *view1 = [[UIView alloc] initWithFrame:CGRec

Automating CSS Regression Testing

The following is a guest post by Garris Shipon . We've touched on the four types of CSS testing here before. Regression testing is the hardest. It's the type where you're trying to test if a change you made to CSS resulted in any unexpected visual pr