DOTS Huge Build Sizes

[desertGhost]

First off, I really like the new DOTS subscene workflows / async conversion and build settings.

That being said I have run into an interesting problem with a test project I am working on. A built sample that I created has a massive build size with the streaming asset folder being 32.7 GB!

I placed 10,000 trees (3 unique tree prototypes, materials support GPU instancing) on a terrain and extracted them using an editor utility I wrote into 224 different subscenes (there are about 45 tree instances per subscene). These sub scenes are loaded async around the camera at a configurable distance.

Since there are only 3 unique tree prototypes (maybe 20 unique meshes at most), I would expect the build to be less than 2 GB.

Anyone have any ideas why such a large build is being generated?

Edit:
I am using the built in renderer.
Mesh optimization is turned on in the project settings.

My build settings are as follows:
ILCPP, release config
Standalone Windows 64, Develop, Hybrid Build Pipeline

[Joachim_Ante_1]

At the moment all assets are duplicated per scene. Packing controls & sharing optimisations is something we are working on.

For right now the only work around is to instantiate at runtime. Which may or may not be a better strategy for trees anyway.

GitHub - Unity-Technologies/DOTS-StreamingSamples: DOTS - Streaming samples

[desertGhost]

@Joachim_Ante_1

At the moment all assets are duplicated per scene. Packing controls & sharing optimisations is something we are working on.

For right now the only work around is to instantiate at runtime. Which may or may not be a better strategy for trees anyway.

https://github.com/Unity-Technologies/DOTS-ProceduralTileStreamingSample

Thanks. Good to know.

I just started on a system that was going to process cells of vegetation (cull it / select LODs / billboard based on proximity to camera and frustum using the job system) and render vegetation with Graphics.DrawMeshInstanced. I’ll modify this system to instantiate entities for the vegetation at runtime (instead of drawing with Graphics.DrawMeshInstanced) and see how it performs.

[Nyanpas]

Mr. Ghost:
I instantiate over 100 million shrubberies at runtime for my game using GPU-instancing and the Job system for culling. It works well as a system with great performance, except that currently WebGL does not seem to appreciate instancing that much. The game’s total size is under 30 mb.

Demo here:

789 by Colonthree Enterprises

Thread here:

Frustum/distance-culling of GPU-instanced objects with the Job System

[update] I managed to improve the culling jobs by using Unity.Mathematics. It was previously 1ms, now it is down to 0.5ms. I also tested twice the amount, as in 18 million objects, and still got the same result, except it takes a little longer to setup at start. Greetings, I have been looking at a way to handle large scale GPU-instancing (using Graphics.DrawMeshInstanced()) and found that using the Job System for culling worked well for my project. I am down to an average of 0.5ms thread-time…

The code is still WIP but I am planning on making it public at some point if people are interested.