自定义博客皮肤VIP专享

*博客头图:

格式为PNG、JPG,宽度*高度大于1920*100像素,不超过2MB,主视觉建议放在右侧,请参照线上博客头图

请上传大于1920*100像素的图片!

博客底图:

图片格式为PNG、JPG,不超过1MB,可上下左右平铺至整个背景

栏目图:

图片格式为PNG、JPG,图片宽度*高度为300*38像素,不超过0.5MB

主标题颜色:

RGB颜色,例如:#AFAFAF

Hover:

RGB颜色,例如:#AFAFAF

副标题颜色:

RGB颜色,例如:#AFAFAF

自定义博客皮肤

-+
  • 博客(56)
  • 问答 (1)
  • 收藏
  • 关注

原创 实时渲染中如何处理带积分的光照方程

在离线渲染中我们可以使用蒙特卡洛积分加上重要性采样来处理光照方程的积分问题,但是这个计算量非常大,在实时渲染中是无法使用的。实时渲染中会根据具体的问题选择不同的方法来处理积分问题,这篇文章列举了实时渲染中常见的处理积分的方法,主要是希望通过这几个例子了解其背后解决问题的思想,实时计算积分,肯定会使用预计算,算是空间换时间吧。实时渲染光照方程约等式这个约等式非常重要,很多地方都会用到。为什么要这个约等式,因为它可以将复杂的积分拆分成多个简单的积分,这样我们可以各个击破。但是这个约等式其实是错误的,只有满

2021-07-16 23:16:21 481

原创 实时全局光照总结

全局光照只考虑一次间接光照,核心问题是怎么找出次级光源以及如何高效的计算全局光照。RSMshadow map中存储了次级光源的信息,这些次级光源被当作diffuse材质,可以像四面八方反射光线,简单理解就是把每一个shadow map中的像素当成是一个点光源,每一个渲染点都需要去找能影响它的点光源。关键的问题是次级光源太多,我们需要根据屏幕空间的法线,世界坐标,深度信息对次级光源进行筛选,但是因为次级光源没有遮挡关系,所以RSM无法表达全局光照的阴影。这个算法通常用到手电筒上,因为这样的shadow m

2021-06-27 14:31:35 770

原创 环境光照总结

所谓环境光照其实是因为光源的各种弹射让环境中的所有物体都可以看作是光源,它所表现的效果是一种全局光照,但是在实现的时候我们是把它当成直接光照处理的。球谐函数球谐函数是一组基函数,我们可以通过这组基函数来表达复杂的函数,比如光照方程。不是所有的函数都可以被球谐函数表示,只有定义域在球面上的函数才可以。球谐函数类似于傅里叶变换,它可以分成很多层,每一层表示不同频率的信号,通常我们会使用较低层次的基函数来还原光照方程,这样就意味着,我们只保留了低频信号。因为diffuse光照其实就是低频信息,所以球谐函数适合

2021-06-26 15:59:15 689

原创 动态实时阴影技术总结

Shadow map基本实现思路两遍Pass:1.光源做为相机渲染一遍场景保存深度信息2.正常渲染的时候将坐标转换到上面的坐标系进行深度比较,如果深度大于shadow map,则表明这个点被遮挡只要是shadow map就会有两个严重的问题,第一个是自遮挡,第二个是锯齿,这两个问题的本质是因为shadow map的分辨率太低。因为shadow map贴图的分辨率过低,阴影贴图的一个纹素会对应多个像素,而这些像素在shadow map空间中的深度是不同的,因此就会出现自己遮挡自己的情况。如果太阳刚好在

2021-06-25 20:06:42 490

原创 再谈RenderGraph

第一次听说RenderGraph(FrameGraph)感觉很高级,现在来看在新一代图形API面前,RenderGraph是一个必须的基础模块。RenderGraph处理的功能实际上在Dx12之前是由DX来帮我们完成的。我们在渲染的时候是要保证资源的依赖关系,而RenderGraph就是用来处理这种依赖关系的框架。在单线程渲染的时候这种依赖关系DX是可以推导出来的,但是DX需要跟踪全部的资源来进行正确的序列号,这对DX来说是一笔不小的开销。现在环境变了,当我们在处理多线程渲染的时候DX会很无力,比如跟踪资源

2021-06-19 16:50:00 1701

原创 再谈ECS架构

还是从我最开始接触游戏的时候说起,那时候的客户端架构使用了很多继承,这种设计的思路是“继承了基类也就意味着继承了基类的能力”,如果我们不从语言的角度来讨论继承和组合,只从框架逻辑来说,继承相当与组合的一种特例,继承是静态的组合,也就是说一旦你继承了基类,就无法进行替换或删除这种能力,继承和组合相当于UML中的聚合和组合的关系。这种继承关系将会使子类变的很臃肿。举个例子,比如移动模块,我们可以在天空中飞行,陆地上行走,河水中游泳,每一种移动所需的逻辑和数据是不同的,因此我们我们将移动模块抽象成三个类分别是fl

2021-06-19 00:30:28 1152

原创 再谈GPU-Driven Rendering Pipelines

距离上次写GPU-Driven Rendering Pipelines的文章已经块一年了,当时有一个疑问,问什么要把mesh拆分成固定拓扑结构的Cluster,带着这个疑问,再次出发,发现之前写的文章只是GPU-Driven Rendering Pipelines的皮毛,这次想写一些进阶的知识,其实后续还有很多问题需要处理,先不急一步一步来。在说GPU-Driven Rendering Pipelines之前先聊聊合批技术,毕竟GPU-Driven Rendering Pipelines有一个口号是一个

2021-04-18 19:31:43 6616 2

原创 D3D12之资源管理

D3D12的资源管理已经移交到上层应用了,为此我们需要自己做资源管理,我们先来看一下一个资源从创建到销毁需要经过哪些步骤:磁盘的文件读取,不同的资源有自己的文件格式,其中还可能涉及文件的压缩,因此一个文件首先要从磁盘加载到内存,然后解压缩,解析,最后再转换成显卡识别的内存布局。 申请上传堆或者默认堆的内存空间,也就是创建ID3D12Resource资源。 接下来使用memcpy函数将资源上传到驱动内存(cpu和gpu共享的内存)。 将资源通过PCIE总线上传到默认堆。 创建资源的View,也就是

2021-03-26 09:47:47 354

原创 D3D12之多线程渲染

游戏引擎的设计是随着硬件的迭代而迭代的,当然硬件的迭代也需要考虑软件的功能需求,目前硬件有两大功能需要我们花精力去处理:CPU-多核,现在的CPU都是多核的,为了充分利用硬件资源,我们需要使用多线程渲染。 GPU-异步,GPU的硬件设计是有功能区分的(CPU每一个核都一样),比如处理VS阶段的硬件和处理PS阶段的硬件是不统一的,如果一个任务集中在PS阶段比如后处理,那么VS的硬件就会被浪费掉,因此异步计算是充分利用GPU的一种手段,比如后处理可以使用Compute Engine来处理,然后Graphi

2021-03-23 17:35:19 805 1

原创 D3D12之CopyEngine

D3D12支持三个引擎分别是渲染引擎,计算引擎和复制引擎,这篇文章主要是对Copy引擎的总结,先上一张MSDN官方图片:这张图片可以说明很多问题,首先可以看到D3D12对多线程渲染的支持,每一个线程都可以操作三种引擎,每个引擎是通过Command Queue来顺序执行指令的,每个引擎有自己独立的Queue,因此它们三个是可以并行操作的。渲染队列可以操作三个引擎,计算队列可以操作计算和复制引擎,而复制队列只能操作复制引擎。既然渲染和计算队列都可以支持Copy操作,为什么还要单独弄出一个复制引擎呢?

2021-03-18 21:32:56 950 1

原创 D3D12之Sync Point

说到Sync point,这块的知识点比较杂,但是对于渲染引擎来说又特别重要,因此想写一篇文章把这两天学到的知识点总结一下,要不然时间久了肯定就忘记了。先从视觉暂留说起,我们的眼睛在看到影像以后,会将影像暂留一段时间,因为眼睛的这个特性,我们就可以把连续的影像变为离散的,只要影像切换的足够快,给人的感觉就是连续的,这就是电影的原理。显示器,手机屏幕,都有一个叫刷新率的参数,比如每秒60Hz,每秒144Hz。这个刷新率就代表屏幕一秒可以刷新多少次,也就是屏幕一秒可以切换多少帧。屏幕帧的切换并不像P

2021-03-17 15:54:17 888 1

原创 PBR渲染之数学篇

渲染方程从方程上可以看出某一点的渲染可以归结为该点的自发光加上所有的反射光组成。正在上传…重新上传取消正在上传…重新上传取消正在上传…重新上传取消是p点的出射光亮度。

2021-03-10 16:23:56 470 1

原创 深入理解D3D12资源状态转换

D3D12将资源状态管理从图形API层移交到应用层,迫使我们自己来管理资源的状态,我们不仅要正确的使用资源状态转换,还要保证转换的性能,这就需要我们深入的了解D3D12资源状态转换的一些规则。让我们先来看看D3D12都有哪些应用场景。Transition barrier最常用的资源状态转换,比如RT->SRV。RT是写状态,SRV是读状态,因此我们需要建立一个转换屏障,保证写操作完成后再去读取资源。 Aliasing barrier D3D12允许一块堆内存被多个资源占用,这可以提高内存的利用.

2021-01-26 19:07:33 1954

原创 再谈渲染引擎架构

这几天写了一个DX12描述符管理系统,写着写着就思考到渲染层的架构上了。。。之前也总结过渲染层的架构,现在回头看发现思路很混乱。今天思路狂飙,对渲染层架构有了新的认识,因此想再写一篇文章,把这些思路记录下来。我之前写过很多遍game player的架构,对于什么是好的架构,我的理解是,一个易于多人维护及扩展的代码结构,就是好的架构。对于一个好的框架,感性的认识就是,当你添加一个新功能时,你可以很容易的找到我应该把这个功能添加在哪里,我会专注功能的实现,而不必担心会不会影响其他模块的功能,或被其他模块影响

2020-12-28 18:34:47 967 1

原创 ECS架构之并行处理的思考

在思考ECS架构并行处理之前,我先思考了一下ECS架构对游戏业务逻辑的影响,游戏能否使用纯ECS架构?我参考了最为普通但是最重要的业务逻辑角色控制。角色控制包括角色的创建,角色的更新,角色的销毁,这三个主要业务逻辑。通常我们会从服务器获得创建角色的消息,传统游戏架构会在处理这个消息的时候创建一个角色。基本上会有一个PlayerManager的单例来创建这个角色。创建角色的同时会创建角色需要的组件,比如AI组件,移动组件,动画组件,声音组件以及一系列角色数据。如果用ECS思想去实现角色创建,我们不

2020-12-16 20:42:02 970

原创 C++ ECS架构ForEach实现

最近参考unity的ecs架构,想写一个C++版本给自己的demo使用。在写到ForEach的时候,发现要想实现类似unity的ForEach还是要花点功夫的,因此写一篇文章记录一下。先看一下unity版本这个接口怎么用。Entities .WithStoreEntityQueryInField(ref query) .ForEach( (ref RotationQuaternion rotation, in RotationSpeed speed) => {

2020-12-14 17:56:57 571

原创 ECS架构之内存布局

ECS架构是面向数据编程的代表,面向数据编程的意义就是让我们关注数据编程,从而提高程序的性能。数据的处理一般分为数据的读取以及数据的计算。数据读取我们需要尽可能的使用高速缓存来提高运行效率,不仅仅针对内存,磁盘的读取在游戏开发中也是非常重要的。数据的计算cpu端SIMD计算,以及gpu的CUDA计算都是为了提高数据的计算能力。无论是提高缓存的命中率还是SIMD及CUDA计算,SOA式的内存布局都要比AOS更加友好。但这也不是绝对,准确的说应该是我们尽量保证数据的局部性。说到局部性,无

2020-12-07 10:34:57 1219

原创 ECS架构的思考

最近在整理Demo代码,遇到一个设计问题,这个问题是transform组件到底放到哪里比较合适?我们都知道逻辑,物理,渲染模块都会用到transform组件。比如渲染模块会将transform数据转换到instance buffer中。通常渲染模块做为底层模块会提供一个接口供上层的逻辑模块调用,也就是说将transform放到了逻辑模块中。但是对于渲染模块来说提供这个接口会影到渲染模块的设计。比如将instance buffer放到ResourceNode中(FrameGraph架构),而ResourceN

2020-12-04 18:33:13 1164 1

原创 C++编译器自动生成的特殊函数

C++编译器会在需要的时候自动为我们创建一些特殊函数,这些特殊函数是类的核心函数,我们必须了解这些特殊函数的创建规则,让我们先从C++98开始说起。搜先这些特殊函数是在被需要的时候(被调用)被编译器创建出来的。C++98会为我们自动创建四个特殊函数分别是:默认构造函数 复制构造函数 复制赋值函数 析构函数class Empty { public: Empty() {...} Empty(const Empty& rhs) {...}

2020-11-26 21:55:41 287

原创 Modern C++之别名声明

我们在编写代码的时候经常会使用类型别名,比如定义自己的内置类型(跨平台)或者为了简化某种很长的类型。在C++ 98时代我们会使用typedef来完成这个工作。typedef std::unique_ptr<std::unordered_map<std::string, std::string>> UPtrMapSS;C++11以后增加了别名声明,它使用using关键字。using UPtrMapSS = std::unique_ptr<std::unordere

2020-11-26 15:46:26 319

原创 DX12描述符管理

最近一直在研究图形学方面的知识,学得头疼,恰好现在的Demo需要一个描述符管理系统,因此转向DX12的学习,换换脑子。对于资源描述符,描述符堆,描述符表,根参数,根描述符等等这些基本概念,我就不介绍了,网上一抓一大把。我先先谈谈为什么DX12要引入描述符的概念,先看一下msdn的说明,以下加粗字体,来源于msdn。Directx12 绑定背后的主要设计决策之一是将其与其他管理任务分离。这对应用提出了一些要求,以管理某些潜在的危险。D3D12 绑定模型的主要优点是,它使应用能够经常更改纹理绑定,.

2020-11-07 18:31:30 1012 2

原创 超大地形纹理系统总结

近期学习了虚拟贴图的基本原理,希望能够对之前学的知识点做一个总结,因此使用DX12实现了一个超大地形的纹理系统。经过思考与验证个人觉得传统的虚拟贴图技术并不适合地形系统,原因如下:1.为了提高地形的像素密度,以及降低磁盘的IO读取,地形的纹理贴图是通过CS实时计算获得的。计算的思想基于clipmap,以相机所在位置为中心渲染多张地形纹理,离相机越近的位置像素密度越高,反之越低。使用clipmap就无需feedback过程,以及indirect map索引。2.可以很好的支持各种贴图采样,包括各向异性

2020-10-24 16:30:37 712

原创 虚拟贴图地形系统之概要设计

之前学习了虚拟贴图的理论知识,接下来该实践了,准备使用DX12写一个自适应虚拟贴图,在动手之前先把思路搞搞清楚,写写概要设计。需求就按照Far cry 4的标准吧:1.地形大小10km*10km2.像素密度10pixel/cm首先我们先算一下满足上面的需求,虚拟贴图的尺寸是多少,10*1000*100*10 = 10000000,一个维度就1千万个像素。。。没办法老板要求的。我准备使用硬件虚拟贴图,也就是说每一个page的尺寸是64KB,贴图使用32bpp,算下来每个page的尺寸就是128

2020-10-10 18:27:35 387

原创 虚拟贴图理论之贴图压缩

虚拟贴图无论对内存带宽还是显存带宽,都造成了巨大的压力,因此我们需要使用压缩格式的文件。从工程的角度来说我们需要了解各种压缩算法的压缩比,解压速度以及压缩速度,从而选择最佳方案。为了能够更好的使用压缩格式,我这里简单的了解了三种压缩格式,分别是代表贴图压缩的jpg格式,代表纹理压缩的dxt格式,以及代表通用压缩格式的zip。...

2020-09-28 20:23:57 598

原创 虚拟贴图理论之Feedback Rendering

在游戏中我们经常会更换贴图来换装,或者使用细节贴图去增强模型的表现效果,在不使用虚拟贴图的情况下,这些效果实现都是很自然的事情,比如换装直接更换材质的贴图,细节贴图就是在PS中读取多张贴图。现在如果我们使用了虚拟贴图技术,那么就会有一个问题摆在我们面前。在PS中...

2020-09-26 21:20:48 419

原创 虚拟贴图理论篇之Texture Filtering

贴图的Filtering通常我们在引擎或者是图形API中根据具体的需求设置即可,但是对于虚拟贴图,由于每一个物理Page的地址不连续。导致硬件的Filtering无法使用,因此我们需要特殊处理,搞清楚Texture Filtering的原理基本上就知道该怎么处理这些问题了。Texture Filtering有四种:1.点采样2.线性采样/双线性采样3.三线性采样4.各向异性采样接下来我分别介绍每一种Filtering的基本原理及虚拟贴图中遇到的问题。点采样点采样又叫邻近过滤,

2020-09-24 22:57:01 3267

原创 虚拟贴图理论之寻址

虚拟贴图第一个需要解决的问题就是寻址问题。我们需要将虚拟贴图的uv坐标转换到对应的物理缓存中。我们使用一张Indirect texture贴图存储了转换相关的数据。如下图:每一个虚拟Page都会对应indirect texture中的一个像素,通过像素中存储的参数,我们可以将虚拟地址转换到物理地址。接下来我们就探讨一下indirect texture中存储的参数到底是什么?首先我们必须先了解一个概念,虚拟Page代表的是一块uv坐标,这块uv坐标中的所有坐标变换使用相同变换参数,如下图:A点

2020-09-22 19:10:05 537 1

原创 虚拟贴图理论之概述

我之前做的项目基本上对资源管理做的工作很少,有一个硬性要求,游戏运行占用的内存不要超过手机内存的一半,这是为了防止游戏因为内存不足而崩溃。大部分的游戏都是会切场景的,在切场景的过程中释放和加载新的资源,这样做基本上可以满足项目的需求。为了追求高性能和降低内存的使用,我们通常会使用一些策略来进行资源管理,因为接下来我要分享的是虚拟贴图,所以先简单整理一下手游中经常使用的贴图管理策略,比较乱,想到什么说什么。UI资源1.首先UI资源追求精度,所以不能使用压缩格式的贴图。2.为了合并批次,UI资源会被

2020-09-21 15:17:38 2222

原创 理解游戏中使用的贴图资源

贴图资源是游戏中最常用的一种资源,做为游戏引擎的开发者,我们不仅要了解如何使用这些贴图,还要考虑运行性能,内存,磁盘空间,网络流量等一些产品化的东西。通常我们需要考虑以下几个因素:贴图读取的时间 内存占用及创建,销毁的次数 网络流量 磁盘空间占用 对美术开发是否友好贴图格式与纹理格式纹理格式是为显卡设计的,对于显卡来说,贴图资源就是一块显存,cpu需要按照纹理格式在内存中将纹理数据准备好,然后通过图形API告诉gpu这块数据的格式,是否使用了mipmap以及mipmap的层数等等,最后

2020-09-08 18:57:58 1494

原创 DX12之手撸GPU Driven Pipeline

使用DX12手撸了一个GPU Driven Pipeline,前前后后大概花了一个月的时间,效率有点低,先总结一下为什么效率不高。1.图形API不熟悉,很多东西虽然概念上理解了,但在实际编写的时候你会很困惑,为了实现这个功能,该怎么使用这些API。因此我需要花费精力去熟悉DX12,主要的学习途径就是MSDN以及各种示例代码,龙书可以做为入门书籍,对dx12有一个大概的了解。2.调式困难,引擎开发最常遇到的两个问题崩溃和效果不对,崩溃往往都是和内存相关的问题。一旦崩溃很难定位,使用DX12开发功能是一

2020-08-31 11:20:56 2085 1

原创 Modern C++ 型别推导

本文是对《Effective Modern C++》第一章型别推导的总结。针对模板推导过程如下:template <typename T>void func(ParamType param);func(expr);上面的伪代码是一个函数模板,我们通过实参expr对模板形参T以及函数形参ParamType进行推导。根据ParamType的三种情况,推导情况各不相同。情况1: ParamType是个指针或引用,但不是个万能引用推导规则如下:若expr具有引用型别,先将

2020-07-30 11:47:21 172

原创 C++ 右值引用的由来

与C++语言分手好多年,重识C++发现它变了,变得陌生,变得犀利,然而又变得臃肿。C语言的美在于质朴,编译器不会为了支撑OO默默做一些经常令我们抓耳挠腮的工作。C#语言的美在于简单,不需要关心那些细节问题,编译器都为我们做好了。C++语言很尴尬,效率不如C,易用性不如C#。只有那些既追求运行效率又要使用OO的项目才会使用C++,比如游戏引擎。即便如此C++依然是我最爱的语言,因为它充满挑战,就像一匹桀骜不驯的野马,越是难以征服,越想征服它。与C++相识是在C++98年代,如今已经是C++

2020-07-27 10:04:14 211

原创 渲染引擎开发之框架搭建

本来只是想学习一下最新的图形API,并在基础上做一些图形相关的技术尝试。但是后来发现,要想深入学习这两块知识,必须自己动手搭建一个渲染引擎,渲染引擎大部分的工作其实和图形技术无关,更多的是合理的规划资源以及对图形API的封装,用以支撑一个复杂的渲染场景。而图形相关的技术是在渲染引擎的基础上实现各种期望的效果。渲染引擎是基础,尝试开发一个渲染引擎并在自己的引擎上尝试各种渲染效果,才是学习的正确打开方式,戒骄戒躁,不要被各种高级渲染效果迷乱了双眼,基础才是最重要的。这篇文章是设计文稿,并不是对代码的总结,而且本

2020-07-12 11:57:37 1967 1

原创 DirectX12之代码中的流水线

今天看到一篇文章,讨论技术总监需不需要了解细节,我个人觉得技术总监了不了解细节不重要,重要的是遇到别人解决不了的问题,你行不行。技术无管理,至少管理对于这个岗位要求的并不高,毕竟我们程序员都是很简单的人。//***************************************************************************************// color.hlsl by Frank Luna (C) 2015 All Rights Reserved.//

2020-07-06 23:27:38 707

原创 坐标变换之相机空间之后的事情

3D游戏中的坐标变换一直都是基础中的基础,了解了坐标变换,你就了解了一个3d模型是如何转换到2D屏幕中的。模型空间->世界空间->相机空间->...->屏幕空间,这篇文章主要是介绍相机空间之后的事情。先来简单回顾一下模型空间到相机空间的转换,首先世界空间的变换矩阵是由缩放矩阵,旋转矩阵,平移矩阵组成的,缩放和旋转都是线性变换,因此它们可以用一个3乘3的矩阵表示,但是平移矩阵不是线性变换,为了能够把它融入到矩阵乘法中,我们需要使用齐次空间,就是将空间升维到4维空间,因此世界空间

2020-07-04 13:22:29 848

原创 游戏场景管理(六)BVH

BVH和空间划分技术不同,它并不是通过切割空间来管理场景中的物件。它是通过将物体分堆,然后在其上面包裹一层BV,达到管理场景的目的。树的根节点是一个能够包裹全部物体的BV,而树的叶子节点可能只是一个物件的BV,如下图:BV可以选择AABB,OBB,包围球等等,往往包裹性越好的BV,相交测试越复杂,但是包裹性好可以减少相交测试的次数。这个世界有阴就有阳,计算机的二进制码也是0和1,我们生存的世界是不是也是一个虚拟的程序呢,哈哈跑题了。父节点的包围体无需包裹子节点的包围体,但是需要包裹所有物体的BV

2020-07-03 13:35:04 1520

原创 DirectX12的初始化

初识DX12,感觉API接口不仅晦涩难懂,而且其数量还不少,所以一边记录一边理解这些API,此次只是初始DX12,对DX的初始化有一个简单的理解,很多API的参数只有到了具体功能使用的时候才会深刻理解,所以这里就不详细介绍每个API的参数含义了。话不多说,上代码。#if defined(DEBUG) || defined(_DEBUG) // Enable the D3D12 debug layer.{ ComPtr<ID3D12Debug> debugController; T

2020-07-02 20:35:07 1356

原创 MSAA那些事

先看一下百度的解释:超级采样抗锯齿(Super Sampling Anti-Aliasing)的原理是把当前分辨率成倍提高,然后再把画面缩放到当前的显示器上。这样的做法实际上就是在显示器尺寸不变的情况提高分辨率,让单个像素变得极小,这样就能够大幅减轻画面的锯齿感。不过由于对整个显示画面的放大,因此它消耗的显示资源也是非常大的。不过MSAA是寻找出物体边缘部分的像素,然后对它们进行缩放处理。由于只是物体的外层像素进行缩放处理,忽略掉了不会产生锯齿的内部像素,所以显卡不会像处理SSAA那样需要庞大的计算量,

2020-07-02 13:45:28 919

原创 游戏场景管理(五)空间划分

一 前言空间划分算法有很多,比如均匀网格,四/八叉树,k-d树,Bsp树,每一种算法都有自己的优缺点,我们需要从理论上理解这些算法,然后在实际项目中进行灵活的运用。游戏中经常使用空间划分算法来优化碰撞,视锥体剔除,邻近查询,因此每当我们讨论一个算法的时候都会从这三方面进行探讨。另外我们还将考虑静态对象和动态对象对算法的影响,主要体现在空间节点的快速更新能力,以及对象快速变更节点的能力。二 均匀网格算法我们可以把游戏场景均匀的划分成一个个小的网格如下图:我们先做一个约定如果游戏场景中每

2020-06-30 17:25:47 4385

原创 游戏场景管理(四)遮挡剔除

1.画家算法早期的gpu是没有z-buffer的,为了得到正确的图像,必须使用画家算法,也就是从后往前绘制几何体。几何体每帧都需要根据摄像机的位置进行排序,进而实现从后往前的绘制。画家算法不仅低效,还有一些无法解决的问题,比如几何体循环重叠:2.BSP树为了解决画家算法带来的问题,前辈大神们创建了bsp算法。bsp树可以根据相机的任意位置,快速的获得排序后的渲染几何体。而且在生成bsp树的时候可以对重叠的物体进行切割,从而解决循环重叠的问题。生成bsp树是一件很费时的事情,为了获得一棵相对平

2020-06-24 13:53:03 3242 1

空空如也

TA创建的收藏夹 TA关注的收藏夹

TA关注的人

提示
确定要删除当前文章?
取消 删除