Solution for simple/performant mobile flat terrain painting?

Unity Engine
, , ,
1

Hello,

I’m looking for a good/matching terrain solution for my game. Some key data:

  • mobile tycoon game
  • 3d, URP
  • isometric view
  • medium sized levels (some camera panning but no huge world, similar like Hay Day, Township, etc)
  • flat terrain

I’m looking for a simple solution to do in-editor terrain painting to give areas different color shades.
E.g. light grass, dark grass, sand, etc.
May be textured, but just colors could also be interesting.

Would also be great if resizing the world plane plane didn’t create too much effort.

Was thinking about using Unity’s Terrain oder Polybrush - but both may come with an unjustifyable overhead for my use case?

2

The terrain system is slow performing so if you’re mobile it’s just going going to slow down performance overhead that would better spent elsewhere.

Polybrush might work. You could also sculpt your terrain per usual and then convert to it to to an optimized mesh. That is pretty much always going to be more performant. Just make a copy of the terrain before you convert it in case you need to make changes. Isometric levels tend to be pretty flat compare to free camera fps or third person anyways.

3

Hello @ron-bohn,
thank you for your reply!

In my case I really wouldn’t need to sculpt anything… the terrain would be really completely flat.
I just would like to paint on it… sand, grass, etc.

:slight_smile:

4

Ok cool! Vertex colors will certainly be good for build size since you are targeting mobile. Textures eat disk space among other things.

If it doesn’t meet all your needs, let me know and I can refer you to terrain to mesh conversion tools as a fallback. These tend to work by converting the traditional terrain painting into a splatmap shader.

The best overall way to go (the way I’d personally do it) would be to make a kit of smaller prefabs of a dozen or so terrain variations that snap to a grid, are color palette atlased. This way your mobile build only has load the disk space usage for that small handful of prefabs that would ultimately comprise your whole world and you could still get lots of variation this way…it would also force some visual consistency which can be a good thing also. I would also put my trees, rocks and such on the same atlas material. For the visual appearance similar to vertex color, you can get away with this texture being really small like 64x64. I would then combine the meshes at runtime when the level starts, assuming they are mostly flat and very low poly vertices. This would most likely result in the lowest build size AND runtime performance. I say this only because I haven’t used polybush in a long time so I’m not well versed in it’s specific out-of-box performance.

5

Hello again @ron-bohn and thanks again for your reply,

I was really “just” looking for a neat way to paint on my flat terrain from within the editor.
With a workflow like… “oh, a mountain here would be nice, let’s put one there, paint a bit of dirt around it and let the dirt blend into grass after a few meters”.

Still not entirely sure if this is feasible with little effort and if I can use Polybrush with a neglectable performance loss or should rather code my own tool or look for one in the AssetStore.

Thanks for your performance hints… didn’t think about baking the environment.
A lot of it would be dynamic but I’m sure there are parts I could bake.
Thanks for the idea!

1 Like
6

@MartyMcFly , I’ve thought about this a little more and I have a few ideas and questions. I understand you are doing a city builder type game and that involves placing and removing a lot of objects. A city builder type game on mobile presents some unique and difficult optimization challenges.

  1. The flat terrain is going to be the most simple thing to optimize compared to all the dynamic objects. The more I think about everything you might run into, I really think that using seperate prefab squares for grass, sand, etc might be the best way to go. you can have roads and mesh prefabs vs painting gives you the option to set waypoints and spawners and such along things like a road. This way you would also hit 2 birds with one stone because you can parent your spawning and despawning city builder gameplay under each terrain block. Having the terrain easy to paint is the least of your worries for a city builder.

  2. If you keep each individual object low poly enough you can use dynamic batching…for everything both buildings and"terrain parts".

  3. If you specify an “edit mode”, this could allow you more simple options for combining and uncombining meshes at runtime. “baking” in unity usually refers to baking lighting, not mesh combining just to make sure there’s no confusion there. However, baked lighting also would be ideal. Using small mesh tiles would open the possibility to bake lighting on a prefab basis. “Bakery” asset does this. Might be possible in newer versions of unity also. “Mesh Baker” is a tool you can use for runtime mesh combine.

  4. How many different buildings are you going to have? This is a big one option-wise and can potentially open the possibility of using static batching…yes for your objects that otherwise would be “dynamic”. The player won’t know the difference. If you only have 10-20 buildings or so, you could have a single “building brain” game object under each game tile (each tile would be the size of a building). This “building brain” prefab could be parented under each terrain tile. This would allow you to simple enable/disable each game object allowing you to use static batching as dynamic batching limit your vertices per game object and might not be enough for some of your buildings. This would involve your code using setActive vs instantiation and make runtime batching easiest. Darn it, now I want to make simple city builder to see if I’m right lol. I do think this is generally good advice though.

In conclusion, I really think that the individual tiles for everything is the way to go. Outside of prototyping, and, the more I think about it, I wouldn’t figure on using the terrain system or polybrush for the final build at all. As I said before, the terrain is really the easiest thing to optimize for this type of game. If it were me, I’d make everything tile-based, including the terrain. This would be beneficial as described for various optimization options, but also simplify the structure of your development, future extensibility, and just seems like the cleanest/most logical way way to build that type of game. It would also allow you lots of flexibility and could even potentially allow the player to be able to spend money to modify the terrain…like to flatten a hill or convert a terrain tile to “steppe” style terrain tile so that the player can plant crops, certain types of buildings or whatever you need.

7

Hello again @ron-bohn !
Thanks for helping to think this through.

  1. An example probably helps. This is a game I like to look at as a reference: https://youtu.be/yfSD983d4Bs?feature=shared
    Again: I just would like to keep the terrain flat.
    But looking at that and evolving that a bit, I thought that painting would be a good idea to get these areas around a mountain and have different touches of deeper or lighter green here and there.
    .
    What you describe is what I pretty much did in my old game and… well.
    I was looking for something cleaner this time than putting quads everywhere. :slight_smile:

  2. Dynamic Batching: Well, we’re getting away here from the original topic. Still, I’d like to say that I see dynamic batching as a very mixed bag these days. My old game had lots of very low poly objects and in the end I disabled dynamic batching because it actually made my game 20% slower. The CPU overhead was just too big - I guess, there’s a reason why it’s disabled by default (at least it is today in URP, as I see). Also you can find a warning in the current documentation: “Note : Dynamic batching for meshes was designed to optimize performance on old low-end devices. On modern consumer hardware, the work dynamic batching does on the CPU can be greater than the overhead of a draw call. This negatively affects performance.”

  3. I actually even own a Mesh Baker license as I once had to optimize some assets. So, I think I know what you mean with baking in this case. :slight_smile: Though again - we’re getting pretty far away of the original topic here. I plan to use dynamic lighting and a day-night-cycle. At least I want to explore, if I can pull it off in a convincing way on mobile. So light baking is more an afterthought. Also I want to be able to rotate my buildings which is also why I don’t think too much about light baking at the moment.

  4. Crazy idea. Maybe you find the time to try it out one day. But like with dynamic batching I also was never successful making use of static batching. It’s a well known best practice, I know, but I just never got more fps out of it - just more memory usage due to the giganto-mesh. I also was met a very savy tech artist who proposed that I should consider static batching. When I asked him “Did you ever gain performance benefits from it?”, he was thinking for a second and then replied: “No.”
    I’m sure there are use cases for it… else it wouldn’t be a thing. But it’s anything but a no-brainer to use.

If you look at the example video above, you’ll see that I’m looking for a more organically looking game world. So, yes, it would be tile-based… but the player shoudn’t see any tiles.

8

Hi @MartyMcFly

1.2 I checked this out. It’s pretty in line with what I was thinking with the combination of what you mentioned initially. When I mentioned flat tiles, I’m not saying they all have to be quads. I use tiles or honeycombs for a lot of world optimization. Keep in mind that day-to-day I’m working on levels and assets that account for 3-5 mile vistas shorter on modile of course. What you did in your first game sounds like a wise choice. Just because you use “tiles” for optimization and logic, does not mean the player will see actually visual tiles. Again, non of your original examples showed visable tiles, so I wasn’t shooting from the hip there!

By the way, that’s a big train for that little shed. There’s an impressive round-a-bout in there lol. I was wiaitng for even more train parts to come out of there like a clown car situation lol !!

2.2 Unity’s notes sound like they maybe haven’t got dynamic batching working great in URP. In fairness, their “optimization” documentation has been not always so accurate historically. There is also the SRP batcher which I believe is what they are pushing for URP and HDRP. There are indeed situations, where batching is not going to improve performance. If you are talking about thousands of objects on mobile, I’d say that would be one example. Top down for any platform is significantly easier to optimize than the types of assets. I could see that in a fixed camera top-down on a very small map. You need to find out the exact ceiling for the vertices of combined objects for your target device, along with other info like that if you really want accurate feedback. I’m doing my best based on what you’ve provided (and that has been edited and changed during the conversation lol). If you know you’re stuff fairly well, then good lord lead with the info you know I need. I just found out your were using URP for example.

I very carefully craft and test assets for free camera vistas on a daily basis. Many other developers’ assets are NOT well designed for mobile or anything realtime really. In recent years, I focus more on desktop, console and VR, but if you want to see an asset with MAXIMUM usage of vertices for efficiency check out this kit I made about 10 years ago: https://assetstore.unity.com/packages/3d/environments/sci-fi/optimo-sci-fi-city-2-156685 …maybe not the style of your game, but the way I modeled it the buildings, uses like 1/10 of the vertices of some popular “toon mobile” assets available. It’s still as fast as you can get for today’s mobiles or any platform really. It’s a legacy kit and only $5. I can give you a voucher if you’d like to see how mobile models should really be made. I strongly suspect that a lot of your tests and conclusions might not be taking into consideration the assets being used and possible obnoxiously high vertices counts. Me knowing things like your familiarity with 3D modeling in general would be really helpful. I don’t intend to or want to talk down to you in any way whatsoever, but the type of level you are talking about is like one of easiest things to optimize compared to stuff I usually work on.

Tell me your exact specs and ceilings for your target device range, and I could not only go into exact detail. Just to be clear everything I’m saying I can build from scratch if I personally needed to. Enough on that though.

3.2 Yeah let’s not call combining meshes “baking” that is way too confusing and other people who are likely to read this thread.

Respectfully, I think you might of missed what I was saying here. I bake lights, custom luts, and all kinds of things into the textures themselves before Unity lighting (of any kind) even comes into play. AND use real-time on top of it. You really should look into this practice, especially for mobile; even if you have a dynamic daynight cycle.

By the way, I think you should just fake your day/night as much as possible if you’re doing fixed camera top down. For real-time, a simple rotation script on a directional light while controlling a reasonable frame update would be way faster than a lot of popular systems for this which have way more than you would need. Feel free to ask me about this if you are interested.

4.2 Yeah so as I’ve said, I do this everyday. The ironic thing about your “find the time” comment is that I don’t find time for much else besides the things we are talking about. Everything I mentioned to this point in all of my posts is intertwined and nothing I’ve said is anywhere remotely off-topic, in my opinion. They are important considerations.

The actual models you are using affect everything we are talking about. As for the terrain, it’s just not smart to use the terrain system for performance, especially for what you’re doing on mobile. So, that means we are actually talking about making 3d models.

“never made successful use of static batching” ….on anything? Ever? Maybe you didn’t mean it like I’m hearing that. If that’s the case, there’s got to be some kind of error in either the way you are doing things or in the assets themselves. Or you might be talking about specifically for fixed camera top-down micro maps, in which case I could see this as a viable assessment. Going to give you the benefit of doubt and assume it was the latter :slight_smile:

I don’t really know what else to say without having more detailed specifications or specific case profiler data. I am very astute when it comes to optimization though and the type of level you are optimizing is pretty easy compared to the extreme worlds that I usually build.

It sounds like you have a good foothold on profiler use. If you know your target specs then that would be really helpful.

What’s your vertices budget total?
What is your vertices budget per game object? 64 per object? 300 per object? 2,000 per object? Even higher? Nothing I see in your examples, should take more than 300-500 vertices for even the most vomplicated buildings.

Total game objects visable at once? Static? Dynamic?

Intended build size? 10bm, 50mb, 100mb, 1gb?
-Texture budget?
-Audio budget?

Batches ceiling?

Set-pass call ceiling?

And just to be clear, though I’m ridiculously good at optimization, I’m still capable of learning myself. I improve my processes all the time. I’ve been working with changes in technology and performance impacts for almost 25 years now, full-time. 21+ years at often very high levels There might be things about your project and personal experience studying performance that could help me be better moving forward. I’ve definitely put in over 10,000 hours in real-time modeling with an emphasis on optimization though, so I’ve definitely taken the time. I could optimize the level you are talking about in my sleep lol. I just might not be the best at communicating my knowledge and experience without exact specs. I’m not a sorcerer lol

If you want to contact me directly to discuss exact details that you don’t want to share publicly about your upcoming release you can email me ronbohn (at) bohnstudios.com

There’s a pretty wide disparity in terms of experience on these forums, and again, I hope none of my previous messages came off as condescending. I made some assumptions based on the type of info you initially provided.

Sorry for the wall of text. But yeah I’m down to roll up my sleeves and get this done. I’m sure there’s plenty I can learn from your experience, especially in this type of game. Stick with the tiles, just don’t let the player see the seems. You had it right the first time and it’s a crucial concept that applies to other camera angles as well…I promise!