Streaming World Tiles - Performance/Load

[tame anvil]

Hello,

I was wondering if anyone had any experience or knowledge on tile based terrain?

Specs:

Tile type / number per terrain chunk / x,z dimension
Standard Tiles: 3x (100x100) tiles.
Micro Tiles: 300x (10x10) tiles.
Cliff Micro: 500x (10x10) tiles.

I use three materials, parent micro tiles to an empty, ensure my tiles are static, and worst case looking at 25,000 tiles. Top end.

Based on if the user could see 49 (7x7) microtile terrain chunks, very unlikely use case.

Typically the user's isometric camera can see about 3x3 terrain chunks (27 standard tiles).

Micro tiles are used for cliffs, water edges, and usually have less detail/ vegetation density to help offset/balance those areas.

With Unity batching AI is saying batching should be around 150 draw calls. Again worst case scenario, target platform windows with laptops with dedicated GPU.

Am I setting myself up for a lot of heart ache and failure later on? If so why? or what other information would help you determine if this is a sound approach?

Thank you,

H

[hallow hatch]

Do a stress test. Spawn the max expected number of tiles and view the profiler. See if the frame time is within your budget.

[chrome perch]

150 draw calls is nothing. A modern CPU can easily handle 6000.

I'll be honest, I would not be surprised to find that any modern computer will just chomp through this problem without optimization.

[tame anvil]

Sorry, was in the process of stress test, lost the screenshot to share.

[chrome perch]

Try profiling in a build

[tame anvil]

But yes and this was in editor, and I know that a build runs smoother/cleaner.

[chrome perch]

My editor runs at around 28fps but it's locked to 75 (vsync) in a build 😄

[tame anvil]

I guess, I am more worried about, something that won't show up, up front by just throwing down 50 terrain chunks lol.

It isn't Call of Duty I am making, lol. So I don't anticipate hardcore parkour ❤️ 😄

[chrome perch]

Is every tile its own object?

[tame anvil]

Define it's own object?

[chrome perch]

GameObject

[tame anvil]

I have them nested

parented

[chrome perch]

So... yes?

[tame anvil]

Yes for the unity cubes

The other stuff is voxel models, (non terrain) rocks, vegetation, etc.

[hallow hatch]

You probably don't want to use separate GameObjects for each voxel/tile. That's definitely not gonna scale well. Voxel terrain games usually generate meshes for chunks that contain many voxels.

As for the stats, the shadow caster count is crazy. I bet it alone tanks the performance.

[tame anvil]

Surprisingly no.

That said I can turn them off later, I am purposefully being ignorant in the test/approach.

But yeah, all that is usually visible/rendered on screen with the isometric camera will be about (27 tiles), with a few edge cases, river, shore, etc.

[chrome perch]

It's still an okay amount actually

But on the high side

So yes, combine meshes if you can. Don't let the batcher do all the work.

[tame anvil]

Absolutely.

Micro tiles aren't for the majority of the terrain.

[chrome perch]

Maybe your shadow distance is just really high though

[hallow hatch]

Other than that, use the profiler. Ideally in a build. Unless you're trying to troubleshoot editor performance.

[tame anvil]

This is a more standard scene btw.

As you can see, not as abusive 😄

Still on the higher end of terrain complexity most of the time though.

I will look up how to use a profiler, I didn't know builds could show stats.

[chrome perch]

I don't understand how this is 2222 draw calls

[tame anvil]

I am not sure either.

I also didn't know that batches = draw calls.

[chrome perch]

Traditionally they were. It's more complex now.

You can use the frame debugger to see how draws are built up

It includes a "reason for batch", which allows you to see why they're not being combined

[sonic pebble]

How's the water(?) made
Voxel modeling programs tend to make every "pixel" of a patterned surface separate submesh

[tame anvil]

The water is made with a shader, and the voxel style is normal map

no reason to use real cubes on the water.

Also Wolfos, I am in the Frame Debugger, what am I looking for to find what is causing the draw calls? sorry very new to this part of the editor.

[hallow hatch]

Probably several layers underground.

[chrome perch]

It's basically a huge list of draw calls and compute passes

Oh nvm this is probably URP:
it's basically a huge list of draw calls

[hallow hatch]

That looks about right for your setup.

Probably several shadow cascades cause increased shadow pass draw calls.

[hallow hatch]

Might want to expand render forward and have a look at a few batches.

[tame anvil]

Will scripted objects that can be hit by raycast cause dc?

such as the trees/rocks/ etc that can be searched by player with a right click?

[chrome perch]

No, this does not break batching in and of itself

[tame anvil]

Seems like processes eating up ram in windows 11, death by .1%s

XD

mainly shadows hitting tiles

[chrome perch]

Yeah, that looks like a lot of the same mesh

They should be batched

[tame anvil]

How do I batch, sorry>

?*

[chrome perch]

It should do that automatically, and the frame debugger shows the reason it's not happening for that call

[tame anvil]

shadows?

Doesn't provide details

I expanded the window, but they are blank.

oh!

the material

doesn't have gpu batching enabled

Must be in material settings yes? for each material?

found a little bool in the material settings going to update them and try it again

that dropped batches down to 450

So maybe you know this, why are settings for imported materials all greyed out? Does this mean I will have to manually create materials for all my model imports and then re-add so I can do GPU batching for vegetation?

Btw I wanted to say these replies are very helpful, I have never gotten into a project far enough to start worrying about these aspects before.

[chrome perch]

Imported materials are part of the 3D model asset, which Unity chooses not to modify because that's a whole can of worms

I would generally recommend not working with those, but creating them in Unity instead

[tame anvil]

Got it, and thank you!

[hallow hatch]

Might want to consider switching to urp for the Srp batcher.

[chrome perch]

Or the GPU resident drawer

[sonic pebble]

Thread tag says URP but SRP batching is not visible in the frame debugger there at least

If the tiles have more than one material per mesh, and don't share materials between different meshes, a lot of batches is expected

[hallow hatch]

They're using the standard shader though, so it's definitely BIRP.

Unless that's the wrong material

Ah, it would still be pink though.

[sonic pebble]

Afaik the only way to combine/optimize draw calls without SRP Batching is to use the same material for all meshes to start with, then it becomes possible to use the likes of static batching, gpu instancing or dynamic batching

Material variations can be achieved by material property blocks or by atlasing different texture and mask maps

SRP batching tends to be more efficient though, and way easier to use

[tame anvil]

Good morning! 🙂

So I read through the comments. and I rechecked by project. I do see the URP/URP Config in the project hierarchy. I also default use URP if I remember correctly it is designed for lower end hardware?

That said I also noticed in project settings under graphics, Default Render Pipeline is set to "none (render pipeline asset".
(if I click into the field there are no options to select)

I have been working on this project for a while and have during the process reloaded it from an external drive/reinstalled Unity, maybe even updated the project to a different editor version (not sure.)

Which may have disconnected some of URP features?

I am not sure where to look, what to look for, or how to safely reconnect all the URP stuff, and if this is what would help with batching?

When checking through material options I do find a lot of URP based options in the menu. Hopefully this is helpful?

[tame anvil]

I am curious how/where you are seeing that I am using a standard shader. This way I can make sure I don't have a mix of shaders, and yes from my experience any shader that isn't the proper type is pink.

[tame anvil]

Each "tile" within my terrain chunks are a single material for "grass" or another single material for "dirt" and the model is the Unity cube.

[tame anvil]

I am not sure what this is but I will do some digging to understand, thank you for introducing me to this term.

Also seems that the GPU resident drawer isn't typically exposed in URP projects, part of why I am unfamiliar with it?

P.s. thank you all again for more replies.

[sonic pebble]

A way to make them more batching friendly would be to have one material with one texture that contains both grass and dirt, with two different cube meshes which are UV mapped to use either grass or dirt
This would be the "texture atlasing" method

[tame anvil]

using a texture Atlas makes a lot of sense, but is that possible with Unity cubes?

[sonic pebble]

Not practically
There are some automatic texture atlasing assets which can generate new UVs for meshes
But shifting a cube's UVs for atlasing purposes is trivial from modeling point of view

[tame anvil]

I also read, years ago that Unity cubes aren't as resource friendly as standard imported mesh cubes? Is this true/still true, if ever?

To me they should be the same/similar.

based on number of verts/faces

[sonic pebble]

No idea how they could be worse than an identical cube from another source
In some pretty rare situations a smooth-shaded cube can be used instead which would share vertices for each face

In your case a cube may not be perfect for ground tiles anyway since most of the faces will never be visible, especially where you have more than one cube stacked

[tame anvil]

Fair, and yeah, no idea either.

That said, I am trying to go a more middle path. As the Isometric camera constrains helps limit how much needs to be rendered vs. FPS/ Third person views. I don't need perfection, just to hit maybe x% of optimization so the project doesn't run like dog 💩 . 😄

I worry that getting so stingy with faces/cubes/stacking, while would make sense for a lot of projects, would require either a system to manage it that is beyond my technical expertise to develop. Exponentially more manual workload slowing down progress.

Hopefully I am not far off in mindset of... what is easy for me, what doesn't hurt the user, even if not 100% is good enough that no one knows. aka enjoy the plate, don't look at the kitchen, haha.

[sonic pebble]

What kind of a "system" are you picturing here

[tame anvil]

I have seen some videos where people use some pretty advanced looking / mathy (to me) script/code something that seems only display the faces visible to the camera, but hides anything that would be blocked to the camera. seems redundant to occlusion culling. I am not sure why URP isn't already occlusion culling, because the cubes below the surface cubes shouldn't be rendered since not visible to the camera directly right? Kinda the point of occlusion culling yes?

[sonic pebble]

The simple answer with occlusion culling is that figuring out what not to render is usually more expensive than simply rendering it

But occlusion culling is not exactly what I'm talking about

Even when only a face of a cube is visible, all the vertices are still processed
And when you've got two cubes on top of each other, they're processed as two separate mesh renderers even when they could just as well be one

Merging them into one and deleting the never-seen faces would be very simple
But it'd still be a tradeoff of effort spent because with simple cubes there's not that many wasted vertices ultimately
But they may add up depending on how much detail you want or how many tiles will be visible so it's something to keep in mind

[tame anvil]

Yes, so max is 25,000 cubes, and this is a number that leans worst scenario.
So a multi-layer cliff canyon or cliff's meeting beach with Mesa's tightly packed together. ( 500 cubes per terrain chunk)

More realistic flat planes (27 cubes per terrain chunk) mid would be a cliff meets plain ( 300 or less cube per terrain chunk)

Only the closest 49 terrain chunks at most would be visible loaded by the world streaming system I have ( and that exterior ring one or two rings of terrain chunks is off camera, really the primary camera view is the internal 3x3 grid (9 terrain chunks), once again being super careful.)

So while it has been stress tested to 25,000 cubes with 60 fps in editor, the actual level designs in a build should be much better.

Some areas you could be looking at as few as 27 cubes for the terrain.

[sonic pebble]

If you can test that it won't be an issue with the target minimum spec, there's not much point optimizing it further

60 fps with that level of detail doesn't sound great to me, but it depends obviously on what you tested it with and how well the test represents the actual game

URP's SRP Batching is pretty magical though, particularly to someone who doesn't want to spend the effort learning how to use other batching methods

Porting the stress test scene to a URP project could be worth the time it takes to see how big the difference is

(But some things to note are that URP by default enables expensive post processing effects like SSAO, and there is no converter to get to BiRP from URP so a separate project or version control software is recommended)

[tame anvil]

This is a urp project.

A curious thing I am noticing though cause I opened a blank scene just a camera and light and it is around 55-60 fps and I wonder if it isn't my GPU optimizer (Nvidia/omen) capping frame rate vs. actually unity performance?

guessing the tris/verts coming from the unity skybox being rendered as there are no game objects in scene.

[sonic pebble]

Are you totally sure? the material inspector was showing a BiRP material and the frame debugger didn't seem to have any references to URP rendering either

[sonic pebble]

Better check that unity is excluded from being optimized in that way
It could also be game window vsync
The statistics window can be very inaccurate in some situations, so it's important to use the profiler instead (preferably in a build when measuring frame time matters)

[tame anvil]

#1468505038237339799 message
I posted above about this, not sure what is going on. This link will go directly to the post about that portion of the conversation.

[sonic pebble]

Ah, I don't know how I missed that
Since you have no render pipeline asset assigned, and your materials are standard, that means your project for all intents and purposes is on BiRP
Maybe never was on URP if you don't have any URP Assets in your Assets directory

[tame anvil]

Ah I see now, sorry I was trying to figure out where everyone was seeing it was Birp/standard/etc.

But yeah I may have converted from URP to standard cause a URP limitation I was running into, which is why I have URP stuff in my project hierarchy but my materials are standard shaders.

That said, not really wanting to go to the hassle of converting back to URP and risk breaking a lot of stuff in the project at this point.

I think it may have been due to some customer shader limitations such as the water I have.

Also some room/wall/interior transparency stuff.

BiRP isn't a problem though right @sonic pebble ? Just different approaches to optimization?

[sonic pebble]

Yes

[hallow hatch]

Materials are basically a collections of properties for shaders. So each material must have a shader assigned. You can see the selected shader at the top of the material.

[hallow hatch]

It is a problem in the sence that the optimization techniques available in BIRP out of the box are considerably more "primitive" compared to URP/Hdrp, limiting whta you can do.

[tame anvil]

I have batching Sub 200 in the scene. Made a copy of the project going to try to see what gains I get if I convert the project to URP.

[hallow hatch]

Statistics window can be inaccurate in URP/HDRP. Check the profiler.
And anyways check the profiler to see what the bottleneck is.

Also, it seems like this scene is quite a bit heavier than what you shared in BIRP previously.

[tame anvil]

First time I have seen all of this. Thank you for the patience, didn't realize I had to activate the build profile to get this to go with the build.

[hallow hatch]

Looks good. Seems like you still have some extra frame budget to work with.

[tame anvil]

How do you see this? Sorry there is a lot of information here.

[hallow hatch]

Well, you can see that your frame time is around 16.6ms which corresponds to 60fps. And 9ms are coming from vsync to preserve 60 fps framerate. So you still have these 9ms to use however you want.

You can see the timing in the timeline and the color labels on the left.
You can change the profiler to "hierarchy" mode(click the "timeline" dropdown) to see more.

[tame anvil]

Converted to URP + GPU Resident Drawer

The scene that was being profiled.

Significantly reduced shadow casters.

[tame anvil]

So I imported my terrain stress test and added in 1200 trees and rocks to the point of density so thick the player can't walk through the scene.

There are approximately 25,000 cubes in the scene for the terrain as well.

That said that is the result I have attached in the screenshot. "Despite it showing scripts" it seems to be Unity managed C# rendering code for the URP as the most costly aspect in the last result.

Obviously I won't be building my scenes out this dense. How does this look as a worst case scenario?

[hallow hatch]

That's for you to answer. Is 3 ms enough for all your remaining logic with 60fps target?

Should probably be profiling a build too. It might be quite a bit faster.

[chrome perch]

Yes, build will be faster. Plus you have vsync

So even if it isn’t faster that’s still ~5ms you can grab

I wish the render pipeline left me with that much

[chrome perch]

Make sure to build with IL2CPP, the render pipelines get much faster that way.