Generatig a medium-sized hexagonal grid with complex objects - Performance problems

So, I want to make a strategy game, which take place in the sky. Ground is represented by ~dozen of hexagonal grids on a different heights, with different environment, movement system and etc.

For each grid I have Blueprint “GridManager”, which generate and store an array of “Hexagon” Blueprints.
“Hexagon” will have a lot of different components in future: 6 static meshes with dynamic material instances on some of them. So I can change color and setting of each instance during gameplay, modify “landscape” at runtime and etc.
This way of things allows me to fast prototyping and advancing, but… After generating 500 hexes at the same time I’ve encountered this awful graphical glitch

I came to conclusion that I’m doing something horribly wrong!
Is it not okay to have so many dynamic material instances? It’s bad to spawn so many complex blueprints at the same time? Is my blueprint spawning way too heavy and I should choose some another way to spawn complex/modular objects?
I don’t plan to spawn a hundreds of thousands hexes, I need only 1-2k at maximum, but with buildings, extensibility, visual upgrades and etc.

I am afraid that all your worries may be true. I also had hopes for procedurally generated sandbox city, but Unreal is not there yet (at least blueprints are not).

You need to heavily optimize your way of doing things. While separate blueprints for each hex look nice, they are easy on your coding but quite heavy for unreal to handle. More, when you start spawning blueprints inside blueprints all that mess will get unstable very fast. I have almost finished random maze generating example (and its 10x10 cells), but for some reason child blueprints inside master bp do not work well. You need to dodge some bugs (or features).

So for you better approach would be making single blueprint for whole map. And that is quite complicated, so much that i would say, forget blueprints and code that thing in C++ as single object. Blueprints are great for small tasks, but they become unstable very fast when you try nested blueprints. And then you want your factory to be tiny bp that has animated gate, smoke lights (each of those is even smaller bp). They marketed UE4 as such, but it does not work (yet).

Some hints that could make it working for you:

  • make all those hex meshes are part of single blueprint. instead of static mesh make them all instanced meshes.
  • then for instanced mesh you have 2 options: all hexes same, you apply different material that is world coordinate mapped, or you have few versions of hex with different material.
  • make sure to turn off “create shadow” calculating shadows for so many dynamic meshes may be slow. For prototyping make all materials unlit with emmisive and no lights in level.

Try this first:

  • if any hex bp is reading other hex bp positions/rotations in construction script, dont! Not all hexes are spawned in construction time. Sometimes some of them read wrong values (first one created do not see ones created after them, and that order changes every time you move master bp). Variables inside other hexes work fine, its things like location, rot, transform that are messed during construction. Solution to this is to store all variables for those hex tiles inside parent blueprint. Or to spawn (just spawn) them all in construction, then at beginning of play fill their variables correctly (but that makes few seconds delay on begin play).

As Nawrot said, using blueprint actors for each individual hex is not the best idea.

I have been discussing this with , an unreal dev, and he lays out some pretty solid methods in my thread: Map Generator- Please Critique! - Blueprint - Epic Developer Community Forums!

Basically instance the hexes and use invisible collision hexes that carry all your data.

Thanks for answers!
I’ve found the roots of the graphical problem - I’ve changed mobility to static, turned off shadows, but kept complex mats and dynamic mat instances - I’ve got pretty nice results actually. 5k blueprints behave themselves nicely!

But generating this grid took about 10 seconds :frowning:
I’ll definetely implement some of mentioned ideas and optimize as much as possible, but I want to try to save “each cell = actor” approach, at least for now, I can’t describe how convenient for prototyping it is!

Indeed it is very nice for prototyping, but it is a tarp!

When you prototype and get to happy state, you will be forced to prototype it again in optimized way.
Its pain in a **** to rewrite all logic from your current approach to something with loops and arrays.

Looking pretty cool one more optimization you may want to add especially with so many instances would be some LOD Levels for your Hex platforms. I am sure some of those distant objects you might not need the same level of detail so far off.

Heya zeOrb,
That’s look pretty awesome! =) And your performance doesn’t seem terrible, is it just generation time?

Depending on what you’re wanting to do with your game, there are some other optimizations I can suggest, LOD’s like aeroastroarts mentions are a good start. However, the big optimization will break the nice variation you have going on using Dynamic Material Instances. Switching from Static Mesh Components to Instanced Static Mesh Components is a crazy good optimization (for both rendering and generation time), but since an Instanced Static Mesh Component is only a single mesh and a single material that you “add instances” to, they all will look the same (unless you don’t mind using the “per instance random” material node more below).

Anyway. So each hex is 6 meshes, let’s assume 6 different meshes for the moment. You could use Instanced Static Mesh Components to make the entire scene 6 draw calls (+extra material passes), however they’d all look the same, and they can’t move individually (outside of using world position offset in the shader).

The “per instance random” material node can add a single random float to a material for the instances within the Instanced Static Mesh Components. So you could color shift stuff, or shift UV’s around (I actually have a material that does this, it’s at work so I can’t post it at the moment), or really anything you want to do with a random number. But it is a random number. Meaning, if you were to use Random Streams to use a “seed” to define your random numbers in your Blueprint, so that the same seed would generate the same hex layout, well, the material wouldn’t be the same.

As far as I know, there’s no other way to mess with the material on an instance level of a Instanced Static Mesh Component.

and MonsOlympus in this thread have run into the same stuff, and are now seeing really good performance returns using the Instanced Static Mesh Components.

Of course, that’s all really extreme. But, you can work a system to reduce your draw calls by combining like hexes using Instanced Static Mesh Components to squeeze out more performance, but it really depends on what your goals are. How many units do you want on screen? VFX? Sound? AI? Interface? Platform? Etc… all play into it. If you want the hexes to float around, Instanced Static Mesh Components really won’t help you there, and LOD’s + limiting map size/limiting how much of the map you can see at once, will be your best bet
Know what? I keep talking about Instanced Static Mesh Components, I should really see about getting a doc page written up… and I should find out if they work on mobile if they really are video card voodoo… =)

Thanks for mentioning trick with uv shifting and “Per instance random” node, it is invaluable tool _ I think I will use static meshes for “active” part of the game and will generate instanced static meshed grid for unplayable “background”
Actually it’s pretty fun to jump around, probably I should think about random-generated platformer after strategy game :smiley:

Lol that looks insane.

Awesome! What did you end up doing to generate that field?

I want like a grappling hook or jet pack to zoom around in there =)

It is instanced static mesh and material with color driven by “Per instance random”!(No fps drops at all, by the way!)

What about game itself - I’ve changed my approach and discarded idea “One hexagon = One Blueprint”. Now I have a “Hex Manager” Blueprint, which is responsible for particular hex grid. Hex manager have an array of custom structs “Hexagons”, each struct contains static mesh, material, grid coords and everything else about particular hexagon.
And I have “Hex Manager” array in my GameMode blueprint, where my BP communicate with each other.

However, now I’m thinking about another improvement - my system treat every hex as a part of other structure(Like circular field, square field and etc). It limits ability to build hexagons on the fly- I can’t add them one by one :frowning: But it helps calculate some stuff(Each circular grid have axial coordinate system and simple grid have simple coordinate system)
I’m thinking about building a single giant invisible grid, where I can build hexagons one by one PLUS have ability to spawn circular grids and other pre-determined grids. The problem is, I have no idea how to store this sub-grids within my mastergrid ._.
Any thoughts, guys?

How to make separate Blueprints via Construction Scripts

How do you do, guys!
Trying to solve almost same problem with Construction Scripts.

And haven’t found any working example yet.
You posted some kind of recipe above. But I’m only started to learn UE4 and only have primitive understanding of what you was talking about.

Could you share some skeleton example of How to make separate Blueprints via Construction Scripts or other solution that you think can be suitable for my example??

Take a look at my video:

And suddenly all hitbox problems with InstancedStaticMesh fixed in 4.4

Yeah I saw that. I probably won’t make use of it anytime soon though since I already got everything working pretty well with collision volumes.

How is your project coming along? :slight_smile:

Not as good as yours! :frowning:

My “second pilot” abandoned me due to new cool gamedev job and I can’t finish project like this all by myself >.>
I’m a 3d artist and I’m afraid my 3d skills becomes blunt if I will spend most of my time to blueprinting… So I decided to start another project, where I can utilize my own skills better!

That sucks but it happens. Pretty much why I am working solo on my project in my free time. Maybe one day when this thing is playable I will be able to bring on extra people to help complete it. That or I will just buy all the assets I need.

What is your new project? Prepping for the marketplace launch in a couple weeks?

i am not “the great blueprint maker” but as i worked a bit on procedural and followed some of your works (where i learned a lot) if i can help with working on some blueprint to help finish or at least make progress, i’ll be please to give a hand (but the left one, the right is now working a lot on behavior tree and a ai panel of reactions setup)


I am Numen, or Johan for friends. I was wondering if you are willing to share this project? Me and two friends want to create a game with the same principles. We are mostly C++ and vb .net coders and our graphical skills are limited. We were going to create something like your project, or frankly exactly the same thing but decided to look if somebody already did. (since this is 2016 and the world has already invented everything basically). I would not mind continueing your project, or have a look at how you did things, for i assume we will run into the same and similar problems as you did otherwise.

let me know what you think!