当前位置:   article > 正文

使用点云数据在Unity中渲染场景_calculatefrustumcorners

calculatefrustumcorners

使用点云数据在Unity中渲染场景

在博客园看到这篇博文,觉得好有用,转载过来以备留用。谢谢博客园大神: tiancaiKG
原文链接:使用点云数据在Unity中渲染场景

最近接触了一个用点云数据渲染的方案, 非常给力, 几乎就是毫秒级的加载速度, 特别是在显示一些城市大尺度场景的时候,简直快的没法形容, 之前的城市场景用了很多重复模型, 并且大量优化之后加载一个城市不仅时间很久, 10分钟级的, 而且内存消耗巨大, 10G级别的, 运行时CPU裁剪都能耗掉40ms, 几乎没有任何意义了…

这个方案好的地方在于它的SDK提供的返回是 ColorBuffer + DepthBuffer, 在任何引擎上都能很快实现它的渲染, 这就是所谓的"云场景"方案了吧.

因为它提供的Demo跑起来效率不高, 也就在30帧左右, 所以做了一些优化, 发现优化之后能上1000帧, 记录一下.

未优化的帧数:
  在这里插入图片描述
  优化后的帧数:
  在这里插入图片描述
  其实方向很简单, 第一个是SDK提供的方法并不需要在主线程中去调用, 可以通过多线程进行请求, 虽然会造成丢帧之类的, 可是本来点云数据就是远程数据, 不可能有本地数据返回的实效性, 所以可以直接放线程里, 然后跟主线程就像是线程排队的例子一样, 主线程提供相机信息, 然后工作线程获取返回buffer, 通知主相机渲染, 大概跟下图一样:
  在这里插入图片描述
  这样1,2,3,4…是本地渲染帧, 请求返回的是远程渲染帧, 可以看到比如第一帧的请求, 在第四帧返回, 那么如果相机一直在动的话, 渲染叠加在一起是偏移的, 非常明显的就是地平线相对天空的偏移, 很难看.
  解决的方法也简单, 把本地和远程同步起来就行了, 也就是延后本地的渲染, 先记录发送远程请求时的相机信息, 在请求未返回时, 本地的相机修改先做记录, 不进行修改, 等到远程返回后, 把记录的相机信息同步给主相机, 然后同步渲染远程数据, 这样本地就和远程渲染同步了, 然后再把记录下来的操作作为下次远程渲染的信息发送请求, 这样本地渲染就被远程同步了, 并且本地逻辑不受渲染的影响, 这样就把逻辑跟渲染分离出来了.
  大概如下 :
  在这里插入图片描述
  这样就可以同步渲染了, 原Demo直接在相机渲染中等待远程返回, 所以帧数受到很大影响.
  顺便记录一下中间一些过程…

一. 通过深度图获取世界坐标.

这次用的 Unity2019, 相机有个获取视锥顶点的函数 Camera.CalculateFrustumCorners , 不知道是什么时候开始有的, 这样获取相机视锥射线就简单了:

 var nearInv = 1.0f / cam.nearClipPlane;
    cam.CalculateFrustumCorners(new Rect(0, 0, 1, 1), cam.nearClipPlane, Camera.MonoOrStereoscopicEye.Mono, _frustumCorners);
    for(int i = 0; i < _frustumCorners.Length; i++)
    {
        var worldSpaceRay_interpolation = cam.transform.TransformVector(_frustumCorners[i]) * nearInv;
    }
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6

CalculateFrustumCorners 获得的是相机的本地坐标系中的位置, 将它转换为世界坐标系(TransformVector), 就如下图所示:
在这里插入图片描述
它是近裁面上的视锥点, 除以近裁面之后就是单位长度的向量了(基于深度的单位长度, 不是向量的单位长度), 或者把cam.nearClipPlane换成1.0的深度.

然后是怎样对视锥向量插值来获得每个像素对应的视锥向量, Shader的顶点过程可以获取顶点Index的信息, 然后测试看看屏幕后处理的顶点跟相机视锥顶点的关系:

struct appdata
    {
        float4 vertex : POSITION;
        float2 uv : TEXCOORD0;
        uint index : SV_VertexID;
    };
    struct v2f
    {
        float2 uv : TEXCOORD0;
        float4 vertex : SV_POSITION;
        float4 ray : TEXCOORD1;
    };

......

    v2f vert (appdata v)
    {
        v2f o;
        o.vertex = UnityObjectToClipPos(v.vertex);
        o.uv = v.uv;
        o.ray.w = v.index;
        return o;
    }
    fixed4 frag (v2f i) : SV_Target
    {
        if (i.ray.w < 0.5) 
        {
            return float4(1, 0, 0, 1);
        }
        else if (i.ray.w < 1.5) 
        { 
            return float4(0, 1, 0, 1); 
        }
        else if (i.ray.w < 2.5)
        {
            return float4(0, 0, 1, 1);
        }
        else if (i.ray.w < 3.5)
        {
            return float4(1, 1, 1, 1);
        }
    }
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40
  • 41
  • 42

根据颜色来看顶点:
在这里插入图片描述
可以看到顺序跟编辑器下相机的顶点顺序是一样的, 左下红, 左上绿色, 右上蓝, 右下白, 因为平台时PC所以就没问题了. 所以核心代码简化如下:

Vector3[] _frustumCorners = new Vector3[4];
    Matrix4x4 _frustumCornerVecs = Matrix4x4.identity;
    cam.CalculateFrustumCorners(new Rect(0, 0, 1, 1), 1.0f, Camera.MonoOrStereoscopicEye.Mono, _frustumCorners);
    for(int i = 0; i < _frustumCorners.Length; i++)
    {
        _frustumCornerVecs.SetRow(i, cam.transform.TransformVector(_frustumCorners[i]));
    }
    _material.SetMatrix("_FrustumCornerVecs", _frustumCornerVecs);
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
struct appdata
    {
        float4 vertex : POSITION;
        float2 uv : TEXCOORD0;
        uint index : SV_VertexID;
    };
    struct v2f
    {
        float2 uv : TEXCOORD0;
        float4 vertex : SV_POSITION;
        float4 ray : TEXCOORD1;
    };

    uniform float4x4 _FrustumCornerVecs;    
    sampler2D _CameraDepthTexture;
    
    v2f vert (appdata v)
    {
        v2f o;
        o.vertex = UnityObjectToClipPos(v.vertex);
        o.uv = v.uv;
        o.ray.xyz = _FrustumCornerVecs[v.index].xyz;
        o.ray.w = v.index;
        return o;
    }
    fixed4 frag (v2f i) : SV_Target
    {
        float depthCam = tex2D(_CameraDepthTexture, i.uv).r;
        float depthEye = LinearEyeDepth(depthCam);
        float3 worldPos = _WorldSpaceCameraPos.xyz + (i.ray.xyz * depthEye);
        ......
    }
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32

视锥计算应该在Vert阶段也是能计算的才对, 只要有相机的Fov以及屏幕的宽高比就行了, 找了一下应该从内置变量中都能找到:

_ProjectionParams

float4 x is 1.0 (or –1.0 if currently rendering with a flipped projection matrix), y is the camera’s near plane, z is the camera’s far plane and w is 1/FarPlane.
_ScreenParams

float4 x is the width of the camera’s target texture in pixels, y is the height of the camera’s target texture in pixels, z is 1.0 + 1.0/width and w is 1.0 + 1.0/height.

还差一个FOV不知道在哪, 可能从变换矩阵中可以弄出来吧. 这样就可以摆脱C#代码了.

二. 在不同生命周期中的特殊处理

现在主要的两个渲染路径 Forward 和 Deferred 生命周期有很大不同, 并且数据都不同, 比如我想在绘制远程数据的时候(ColorBuffer+DepthBuffer), 如果在 Forward 路径中的话, 可以选择在 BeforeForwardOpaque 中绘制, 然后写入颜色和深度, 因为它属于地形这种大面积的东西, 所以很多在它之后绘制的Unity物体可以被遮挡(并且可以不渲染深度贴图), 这在有 Early-Z 的情况下能提升性能呢, 可是在 Deferred 路径就没有什么用, 它直接渲染GBuffer了, 并且在渲染前会清空一次(Color+Z+Stencil), 在它之前没有什么意义, 在它之后也没有什么意义(性能上), 所以为了简便, 直接使用后处理了, 这样在两种路径中都有同样的生命周期…

三. CommandBuffer.Blit的问题

已经不知道怎么描述了, 没有文档, 只能看运行结果了:

1. 使用一个简单Shader材质进行Blit, 在天空盒之前获取屏幕截图

public RawImage raw;
    void Start()
    {
        CreateCommandBuffer();
    }
    private void CreateCommandBuffer()
    {
        var rt = new RenderTexture(Screen.width, Screen.height, 24, RenderTextureFormat.Default, RenderTextureReadWrite.Linear);
        raw.texture = rt;
        var cmd = new CommandBuffer();
        cmd.name = "TestBlit";
        var drawMaterial = new Material(Shader.Find("Test/RuntimeTest"));    // 简单Shader
        cmd.Blit(BuiltinRenderTextureType.CameraTarget, rt, drawMaterial);
        cmd.SetRenderTarget(BuiltinRenderTextureType.CurrentActive);
        Camera.main.AddCommandBuffer(CameraEvent.BeforeSkybox, cmd);        // 天空盒之前
    }
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
......
fixed4 frag (v2f i) : SV_Target
{
    fixed4 col = tex2D(_MainTex, i.uv);
    return col;

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6

在这里插入图片描述
在这里插入图片描述
向前渲染, 不使用DHR/MSAA时得到空白贴图…
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
???

当我不使用材质进行Blit时, 更奇怪的事情来了:

private void CreateCommandBuffer()
    {
        var rt = new RenderTexture(Screen.width, Screen.height, 24, RenderTextureFormat.Default, RenderTextureReadWrite.Linear);
        raw.texture = rt;
        var cmd = new CommandBuffer();
        cmd.name = "TestBlit";
        cmd.Blit(BuiltinRenderTextureType.CameraTarget, rt);  // 不用材质了还不行吗
        cmd.SetRenderTarget(BuiltinRenderTextureType.CurrentActive);
        Camera.main.AddCommandBuffer(CameraEvent.BeforeSkybox, cmd);
    }
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10

在这里插入图片描述
在这里插入图片描述
它为什么形成了套娃??? 这时候它的相机渲染包含了UI的渲染??? 为什么上下颠倒了???

然后把相机的HDR或MSAA打开, 又正常了:

在这里插入图片描述
在这里插入图片描述
然后回到套娃的设置下, 把UI关了, 看看图片它不套娃了…在这里插入图片描述

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/凡人多烦事01/article/detail/89629
推荐阅读
相关标签
  

闽ICP备14008679号