How To Get Started With DOTS (第 5 篇)

警醒与鞭策

已于 2022-04-30 22:47:48 修改

阅读量544

点赞数

CC 4.0 BY-SA版权

分类专栏： Unity3d 文章标签： unity 游戏引擎 DOTS Batch

于 2022-04-30 15:42:55 首次发布

原文链接：https://blog.youkuaiyun.com/Game_jqd/article/details/124510379

Unity3d 专栏收录该内容

158 篇文章

订阅专栏

本文探讨了Unity的DOTS渲染系统中动态批处理的工作原理，指出只有拥有相同材质和网格的实体才能进行动态批处理。当网格不同但材质相同时，即使顶点和三角形相同，也会产生额外的绘制调用。作者建议使用GPU实例化以提高性能，并提供了创建独特实例的方法，包括利用ComputeBuffer和DrawMeshInstancedIndirect。此外，还提到了SRP批处理器的作用和限制，以及如何利用HybridRenderer V2实现更快的渲染。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

/////////////////////////////////////////////////////

Instantiated Entities Dynamic Batching in DOTS

It seems that dynamic batching only works for instantiated entities. Entities with the same material in their RenderMeshes but with different Meshes do not seem to dynamically batch.

Entity boxEntity = CreateUniqueBoxEntity(blockSize, new float3(-2, 0, 0), blockMass, blockMaterial, blockVelocity);
for (int j=0; j<rows; j++)
{
for (int i = 0; i < columns; i++)
{
float3 blockPosition = new float3(j + 1.5f, i * 1f, 0);
if (uniqueBlockMeshes)
{
// GENERATE A UNIQUE MESH
CreateUniqueBoxEntity(blockSize, blockPosition, 2, blockMaterial, blockVelocity);
}
else
{
// INSTANTIATE
var tmpEntity = entityManager.Instantiate(boxEntity);
entityManager.SetComponentData(tmpEntity, new Translation() { Value = blockPosition });
}
}
}

Here is Full Code:

using UnityEngine;
using Unity.Collections;
using Unity.Collections.LowLevel.Unsafe;
using Unity.Entities;
using Unity.Transforms;
using Unity.Rendering;
using UnityEngine.Rendering;
using Unity.Mathematics;
using Unity.Physics;
using Collider = Unity.Physics.Collider;
using Unity.Physics.Extensions;
public class TestEntityGenerator : MonoBehaviour
{
public Mesh mesh;
public UnityEngine.Material blockMaterial;
public UnityEngine.Material projectileMaterial;
public float rows = 10;
public float columns = 10;
public float blockMass = 2;
public Vector3 blockSize = Vector3.one;
public float projectileMass = 10;
public Vector3 projectileSize = Vector3.one;
public bool uniqueBlockMeshes = true;
EntityManager entityManager;
EntityArchetype blockArchetypeype;
// Start is called before the first frame update
void Start()
{
// ENTITY MANAGER
entityManager = World.DefaultGameObjectInjectionWorld.EntityManager;
// BLOCK_ARCHETYPE
ComponentType[] dynamicComponentTypes = new ComponentType[11];
dynamicComponentTypes[0] = typeof(RenderMesh);
dynamicComponentTypes[1] = typeof(RenderBounds);
dynamicComponentTypes[2] = typeof(Translation);
dynamicComponentTypes[3] = typeof(Rotation);
dynamicComponentTypes[4] = typeof(LocalToWorld);
dynamicComponentTypes[5] = typeof(PhysicsCollider);
dynamicComponentTypes[6] = typeof(PhysicsVelocity);
dynamicComponentTypes[7] = typeof(PhysicsMass);
dynamicComponentTypes[8] = typeof(PhysicsDamping);
dynamicComponentTypes[9] = typeof(Damage);
dynamicComponentTypes[10] = typeof(OriginalTransform);
blockArchetypeype = entityManager.CreateArchetype(dynamicComponentTypes);
// CREATE STACKED BLOCKS
PhysicsVelocity blockVelocity = new PhysicsVelocity();
Entity boxEntity = CreateUniqueBoxEntity(blockSize, new float3(-2, 0, 0), blockMass, blockMaterial, blockVelocity);
for (int j=0; j<rows; j++)
{
for (int i = 0; i < columns; i++)
{
float3 blockPosition = new float3(j + 1.5f, i * 1f, 0);
if (uniqueBlockMeshes)
{
// GENERATE A UNIQUE MESH
CreateUniqueBoxEntity(blockSize, blockPosition, 2, blockMaterial, blockVelocity);
}
else
{
// INSTANTIATE
var tmpEntity = entityManager.Instantiate(boxEntity);
entityManager.SetComponentData(tmpEntity, new Translation() { Value = blockPosition });
}
}
}
// CREATE PROJECTILE
float3 projectileLaunchPoint = new float3(-120, 40, 0);
PhysicsVelocity projectileVelocity = new PhysicsVelocity() { Linear = new float3(80f, 0f, 0f) };
CreateUniqueBoxEntity(projectileSize, projectileLaunchPoint, projectileMass, projectileMaterial, projectileVelocity);
}
/// <summary>
/// Creates a box entity by generating a simple cube Mesh and a RenderMesh .
/// </summary>
/// <returns>The box entity.</returns>
/// <param name="size">Size.</param>
/// <param name="trans">Trans.</param>
/// <param name="mass">Mass.</param>
/// <param name="material">Material.</param>
/// <param name="physicsVelocity">Physics velocity.</param>
private Entity CreateUniqueBoxEntity(Vector3 size, float3 trans, float mass, UnityEngine.Material material, PhysicsVelocity physicsVelocity)
{
// CREATE A UNIQUE MESH
mesh = BoxMesh.CreateBoxMesh(size.x, size.y, size.z);
RenderMesh renderMesh = new RenderMesh()
{
castShadows = ShadowCastingMode.On,
layer = 1,
material = material,
mesh = mesh,
receiveShadows = true,
subMesh = 0
};
BlobAssetReference<Unity.Physics.Collider> boxCollider = Unity.Physics.BoxCollider.Create(new BoxGeometry()
{
BevelRadius = 0f,
Center = new float3(0, size.y/2, 0),
Orientation = quaternion.identity,
Size = new float3(size.x, size.y, size.z)
}, CollisionFilter.Default);
return CreateEntity(renderMesh, boxCollider, mass, trans, physicsVelocity);
}
/// <summary>
/// Creates an entity from scratch.
/// </summary>
/// <returns>The entity.</returns>
/// <param name="renderMesh">Render mesh.</param>
/// <param name="_collider">Collider.</param>
/// <param name="mass">Mass.</param>
/// <param name="trans">Trans.</param>
/// <param name="physicsVelocity">Physics velocity.</param>
unsafe Entity CreateEntity(RenderMesh renderMesh, BlobAssetReference<Collider> _collider, float mass, float3 trans, PhysicsVelocity physicsVelocity)
{
Unity.Entities.Entity entity = entityManager.CreateEntity(blockArchetypeype);
entityManager.AddSharedComponentData (entity, renderMesh);
entityManager.SetComponentData (entity, new RenderBounds { Value = renderMesh.mesh.bounds.ToAABB() });
entityManager.AddComponentData (entity, new Translation { Value = trans });
entityManager.SetComponentData (entity, new Rotation { Value = Quaternion.Euler(0f, 0f, 0f) });
entityManager.SetComponentData (entity, new PhysicsCollider { Value = _collider });
Collider* colliderPtr = (Collider*)_collider.GetUnsafePtr();
entityManager.SetComponentData(entity, PhysicsMass.CreateDynamic(colliderPtr->MassProperties, mass));
entityManager.SetComponentData(entity, physicsVelocity);
entityManager.SetComponentData(entity, new PhysicsDamping()
{
Linear = 0.01f,
Angular = 0.05f
});
return entity;
}
}

The UnityEngine.Object references have to match in order for it to use instancing. Even if the meshes are otherwise identical, if they are separate objects, Unity treats them as such for performance reasons. If you need custom UVs, you should really be looking at customizing the scale and offset of the UVs per instance rather than the full set of UVs. Not only is this a lot less memory to upload to the GPU, but it also can use DOTS instancing so you can specify your scale and offset as an IComponentData and let the Hybrid Renderer take care of it for you.

It is also worth noting that a draw call in SRP Batcher is not the same as a draw call in the built-in renderer. Assuming you aren't working with a mobile device with crappy graphics drivers, most modern devices can support thousands of draw calls per frame by the purest definition of "draw call". However, a built-in renderer "draw call" does a bunch of other stuff which prevents it from getting anywhere near the device limits. SRP batcher aims to solve that. It isn't perfect. But it does a lot better than built-in. But really if you can instance things with custom per-instance properties, that's way better.

I would go a step further and say that if there's any particular case you're worried about, use GPU instancing and be done with it. It's much easier to manually force GPU instancing (DrawMeshInstancedIndirect)
on one specific case than fighting with the SRP batcher. In my experience, SRP batcher is only good for static geometry, and even then often does more draw calls than it should because of front-to-back sorting/overdraw prevention (which is good if you're GPU-bound but not so good if CPU-bound).

Does this mean that if the vertices and triangles are the same on two meshes, but the uvs are different, it will still be an additional draw call?

Yes. If the UVs are just offset from each other or otherwise predictable, you can try doing that in the vertex shader.

You wouldn't add RenderMesh at all, just add something to do the rendering directly (eg a system in PresentationSystemGroup). The idea would be to extract those transforms into a NativeArray (eg using a job), set them on a compute buffer with Unity - Scripting API: ComputeBuffer.SetData and finally call DrawMeshInstanedProcedural or DrawMeshInstancedIndirect .

Now, whether or not that's a good idea depends on a lot of factors. In particular, this only works with certain shaders, and is a huge pain in the [body part], so only worth it if you *know* this is a bottleneck.

On the left, you will notice that there is a property named _uv0_st. That is the "display name" of the property. You can call it whatever you want for any shader graph. The "Reference" is what really matters. By default, it will be some garbled mess of characters. Name it to something meaningful, as you will use that name in the code.

I have set the default values to (1, 1, 0, 0). As you will see in the graph, the first two values represent the tiling factors which is just inverse scale. The offset are the last two values. And lastly, you will notice a little checkbox that is checked. That's a checkbox for the Hybrid Renderer. Magic happens there.

The final step is to define an IComponentData which represents this material property. You might do it like this:

[MaterialProperty("_uv0_st", MaterialPropertyFormat.Float4)]
public struct MaterialUV0TileOffset : IComponentData
{
public float4 tileOffset;
}

Note the name of the string has to match the "Reference" above. That's what connects the IComponentData to the property. You can name the IComponentData and the members inside it whatever you want. I also believe this would work if you used 4 individual floats instead of a float4 in the struct. The hybrid renderer just memcpys the whole struct without paying much attention to its type.

Anyways, you can attach this component to any entity which has a RenderMesh with a material that uses that "Reference" as a property. The same "reference" and IComponentData can be used for multiple shader graphs. Whatever value is in an instance of the IComponentData when the hybrid renderer executes is what gets used when rendering during that frame.

The SRP batcher isn't removing any draw calls it just makes them a lot cheaper.

I would refrain from going the DrawMeshInstanced(Indirect/Procedural) route nowadays. The new opt-in HybridRendererV2 is hellishly fast. The full pipeline including culling, sorting, shadow culling is around 2-3 times faster than calling DrawMeshInstanced with known-to-be-visible geometry. It's simply supported by ShaderGraph, manual shaders are similar easy to write as instanced shaders, it supports most features already (GI, transparency sorting, shadows + separate per instance culling) and will support everything else in the near future (eg occlusion culling is WIP, URP lighting is WIP).

DMI is still relevant if you aren't using SRP or are having troubles getting URP to play nice atm. Also if you need to prefix your instance data with a compute shader, HRV2 isn't a good fit yet. But for everything else, HRV2 is holding up strong. Shader Graph instance data is an incredibly powerful graphical feature. If you are clever with it, you can make a world composed of millions of unique-looking objects.

In this test, I varied the color randomly between lighter and darker Color inputs (I will add texture tiling and scaling next). In this image, 5000 blocks are collapsing, each with one of 5000 different shades. In the editor, the frame rate never dropped below 60 and in the build it was well over 120 FPS on a 2018 MacBook Pro. This test is using HybridRendererV1 and URP in 2020.1.

In addition to the ShaderGraph with"_StoneColor" as a parameter, I created an IComponentData:

using System;
using Unity.Entities;
using Unity.Mathematics;
using Unity.Rendering;
[Serializable]
[MaterialProperty("_StoneColor", MaterialPropertyFormat.Float4)]
public struct StoneColor : IComponentData
{
public float4 Value;
}

And added this line to my CreateEntity function from the code above:

entityManager.AddComponentData(entity, new StoneColor { Value = (Vector4) Color.Lerp(lighterColor, darkerColor, UnityEngine.Random.Range(0.0f, 1.0f)) });

for introducing me to DrawMeshInstanceIndirect. I will keep it in mind in the future, but for now I am glad that I will not have to maintain lists of of different meshes (since they will be generated in random sequences) be for being passed to DMII per mesh type.

Dynamic batching is basically the same as static batching updated each frame for visible objects. As that is pretty expensive it is limited to small meshes. You could replicate that but I wouldn't do that.

The fastest way to render multiple distinct procedural meshes would be to make the GPU render multiple at once. You would execute one procedural draw with the full primitive count and some buffers containing the data to lookup per tile geometry and instance data. This could be executed extremely fast with DOTS for culling and buffer updates and you would end up with a single draw call per frame for all your tiles.

Out of the box DOTS rendering isn't well suited for this use case. It will waist a lot of memory as all chunks are nearly empty and have one draw call per mesh. I would expect using BatchRenderGroup directly with SRP batcher still being pretty fast thought.

Is the vertex count the same for all variations?

I was under the impression, that as soon as I was working with a multitude of similar objects I might get a more tidy result datawise by using DOTS.

The current DOTS rendering using RenderMesh automatically stores objects that can be batched by putting them in chunks by RenderMesh data. That is really really great for most use cases in games but it's not when each entity has a unique RenderMesh.

DOTS itself isn't the problem and you can implement good solutions to your problem using it.

///////////////////////////////

////////////////////////////////////////