I was wondering if anyone has found a way to force the terrain engine to batch terrain details into larger chunks, when sending them to the graphics card? For now they are bathced in patches covering sizes equal to the resolution of the detail control textures, which is a little sad. It means I have LOTS of draw calls (with very little actual info) because I have a resolution of 0.50.5 meters(units). And when the actual detail amount on each of these squares aren’t that big, I would like to batch them in MUCH bigger chunks, say 55 meter(unit) pathes.
Hoping for some magic info from a wise guy(or girl!) out there…
it batches the chunks usefully or better as there is not much to batch: has them in optimal sizes
keep in mind, the max is 65k, more vertices can’t be in a single mesh.
also geometry is really your least problem with the terrain. pixels to render and passes of the terrain shader (1 pass per 4 textures), as well as the significant cost for vegetation are the impacthing things, not the batching of the mesh
Well, that doesn’t seem to be the case. No matter how many details I cover a given area with, the actual draw calls are exactly the same (exactly). The only thing that can bring drawcalls down, is changing the placement resolution.
And I asure you it’s not very optimized at the moment. Each of the patches sent to the graphics card contains no more than 4-6 billboards (<24 vertices). I have checked this by changing the shader to one that reveils the actual pathes to me. And I need this high placement resolution (1024 px on an area covering 500 meters/units) to be able to place the details as I want to, without too much blockiness.
I want to have the batching seperated from the resolution, if it’s possible…
EDIT: Also, having the grass taking up 500 draw calls by itself seems to me to be a subject of concern -Even though lots of other stuff are importend also.
above posting is towards the terrain, not foliage.
aside of unity iphone there is no batching in unity at the time (batching as in distinct meshes result in 1 dynamically combined mesh, see gui as another example). the only thing that does kind of batching is the particle system with 1 mesh per emitter.
Ok, sorry for not being clear enough in my initial post I’m just so used to just say “details” to mean foliage, as that is what they are called within the terrain tools.
As to your other statement, if that’s the case, why are the drawcalls connected to the placement resolution, and not the amount of details actually placed? They seems very batched to me. And my modified shader shows the details in chunks of sizes equal to the resolution of the texture. But I could be wrong, I am so very often…! Sadly…
thats possible that it partially batches there but there is no general batching, sorryl
That it only batches over a single placement texture makes sense at least to me, as batching for more than just local area would be worhtless (lots of over work given that details are meant to vanish after the close surrounding)
but perhaps I’m missunderstanding you.
also with the shaders available its potentially possible to ramp up against it
The terrain system does batch stuff. It would be silly (and slow) if every tree, detail mesh, and grass mesh resulted in a draw call. Having a lower pixel error value increases draw calls, at least for the terrain mesh.
I don’t think it makes sense at all. To have an even grass cover 60 units out (my case), needs about 10-16 grass imposters per square meter. I think it would make sense to have the two concepts seperated.
Btw, I just meassured again, and it may be my batches are actually bigger than my resolution. But still rather small. My bad for initial (maybe) wrong info, even though I still need bigger pathes, no matter the actual sizes. I will come back with updated info, if I find the true relation ship between the different settings.
Yeah, I use that a lot to bring it down. Have found a good value around 30-35. It may actually be connected to the details as well, gotta check it out tomorrow.
too large imposters are no option, because you will get massive alpha sort issues if you have too large alpha objects and thats the primary thing you definitely don’t want
an imposter that covers a few 3d units (meters etc are all hot air measures, as they relate to exactly nothing outside your modelling applications) are fine, imposters that cover tens of 3d units will start to cut through objects / be cut by objects that are visually behind/front of the object while appearing exactly the opposite way
No, TOO large imposter chunks are no option, for several reasons. Larger imposter chunks are, though. I’m just talking about the ability, not about taking that ability, and turn it into a misuse, making one big chunk of detail geometry per terrain
And as the batch sized are not balanced with physical size in the world in mind, but alone are defined by the detail placement texture resolution, sorting ability shouldn’t change just because I made chunks bigger.
But I have an update: The chunk size ARE directly related to the resolution of the placement texture, and not the actual amount of detail objects per physical square unit. They are related like this:
Batched chunk size width and height (they are squares) = (Terrain physical size / detail placement resolution) * 8.
That’s it. No ideal batching size algorithm going on. That means the larger your resolution, the smaller your actual chunks will be. And as the resolution of my placement texture (which alone should increase my ability to place the details where I want them) gets higher, I would need less and less detail objects on a given reolution pixel of that texture, to actually make a dense appearance of, say, grass. But my chunks are getting smaller as well, rendering the final relationship reversed of what would actually make sense, optimization wise.
I will put less actual billboards on each of my placement pixels than if I had a smaller resolution, which would cover a larger area.
A better relation ship would be this:
Batched chunk size width and height = whatever you want it to be. Defined by a slider. That’s it.
Then you would make sure you would batch approximately the same amount of actual vetex data into each chunk, no matter the resolution of the placement texture, which alone should make the placement more precise.
But I have to calculate a little to make sure what settings will give me the best/most optimized result. Thanks for your answers anyways, made me actually go in and find the exact relation ship, instead of my initial guess work.
Update: Made a script that can change my detail resolution without losing the actual detail placement, or the density (amount of details placed in all). So that’s cool, and very much needed. Been so frustrating to have to know for certain what resolution is needed before painting one single detail object, and never been able to change the resolution without losing all detail placement work.
As for performance gain, this gave me 300-400 less drawcalls per frame, and an overall fps gain around 50% (from 55 fps to 80). We are not talking about less vertices/tris sent to the graphics card. But instead of batching my details in chunks of size; (terrainSize/detailResolution) *8 = (500/1024)*8 = 3.9 units squared, Unity now batches in chunk size; (500/512)*8 = 7.8 units squared
I think that speaks for itself. We need better batching algorithms in unity, which doesn’t take the placement precision into acount, but alone work on how much detail geometry is actually placed on the terrain. My graphics look exactly the same (lesser placement precision obviously), same grass density, but my performance is SO much better.
I hope this will get implemented in future installments!
-Even though lots of other stuff are importend also.
I’m just so used to just say “details” to mean foliage, as that is what they are called within the terrain tools.