I am procedurally spawning a maze, i spawn a bp cell with a back wall, left wall column and floor. Everything has nanite turned on, they are all also hism components. I also set the culling start and end distance to 3000.
So why when i spawn a 40x40 grid is my fps 12 with 80ms… i dont get it. Am I not doing this properly???
10 x 10 grid
20 x 20 grid
40 x 40 grid
You can even see in the screenshots that everything has nanite and no matter what the grid size, the same amount of cells are being rendered… so why the difference? I am clearly lacking a crucial piece of information here regarding performance optimisation with nanite and HISM
This is showing the nanite instances, there really arent that many. Am i crazy or should this not be 120fps??
The SM’s arent even high poly…
Honestly I would have thought that by using Nanite and HISM and culling them i would have been able to create any size maze and the performance would always be the same. I must be doing something wrong.
HISM will only cull based on distance. To cull it also needs to have the meshes in separate groups. It unfortunately does not cull based on occlusion. So if you have many hism elements only in a tight single group then you will only get a boost from the draw call instancing.
Unreal will not hide the occluded meshes so it will still need to draw every object.
Im not sure i understand, what do you mean specifically by “group”? From the screenshots it looks like culling by distance is working fine, they get culled after 3000 like i set it and the nanite only renders where im looking. But it must still be processing the others even though they are not visible after the cull… is that what you’re saying?
Is there perhaps a different way I should approach this to achieve the desired effect (the engine only spawning meshes within a certain distance to save performance thereby allowing me to have a potentially endless maze because its only spawning a limited amount of instances of the same 4 nanite meshes at any given time)?
@ClockworkOcean @Everynone You guys usually have the answers! Any ideas? 
My take on this would be: Use Nanite, or use all the other stuff.
You’re probably working various engine systems against each other.
Nanite is supposed to take all this bother away.
If you think it’s crap, turn off Nanite, and go back to LODs, ISM / HISM and low poly models.
If the player is in the maze ( and not flying over it ), you don’t need this much stuff in the world at once. That’s one way to get around it. Make them spawn when the player is near.
If you want to continue with Nanite, then combining it with World Partition might be a way to go… ( just put the whole lot in, in one go, and let WP deal with it ).
If you just make them mesh components in blueprints and keep the number of blueprints down, that would work. I’ve found that replacing ISMs and HISMs with blueprints is almost always a performance improvement, actually. As long as there’s not too many.
Well, I gave world partition a try
Made sure to set everything to that grid including children etc.
I even made sure my character was the streaming source
However it doesn’t seem to do anything, I think perhaps because everything is being spawned at runtime. This I think will make this difficult, which is annoying, I definitely want them just to spawn when the player is near (I thought thats what the hism culling would do) so I’m back to square 1 with a problem that seems like it shouldn’t be a problem.
The structure is this:
Blueprint A: Spawns a grid of Blueprint B’s 40 x 40 and sets some logic per BP
Blueprint B: Executes the logic per BP (destroying various components in the cell to generate the Maze)
Inside Blueprint B: There are 4 HISM, each mesh also has nanite turned on.
This is basically the system, if you or anyone else has an idea of how i can achieve only spawning Blueprint B’s near a player and destroying them after a specified distance let me know.
The trouble I suppose is that each Blueprint B has various logic executed which would need to be stored somewhere? This is where it will go from complicated to ridiculous.
I would do it with BPs, frankly.
If it’s all spawning at runtime, why are you trying to place so many? The ones that are already there, can just make more as the player leaves them. I think you only need 9 at a time, to make the player feel like they’re in a maze.
If you really want to scatter them all over the map, you can code the BPs so they are empty, until the player overlaps, then they draw the meshes. Something like that.
What’s your use case exactly? Do you need hundreds in the world at once?
My maze generator bp works so that it is a perfect maze with a worked out ‘correct’ path and end cell. This all happens at begin play, im not sure if i can some how spawn them 1 at a time and maintain the cell parameters for each one
Couldn´t you create some sort of map (like a tilemap), that contains all the infos for your segments, where which segment needs to be to create your path and start and end, but your actual maze meshes spawn only in close range to the player, based on that map?
What kind of hardware is that running on? It doesn’t look like many objects at all - you should be able to get a good framerate with nanite/lumen/vsm combination at that.
What scalability is it? (don’t try and use Cinematic from the editor)
As ClockworkOcean ocean said - there may be some set up that’s not right - try profiling it to try and find what the bottleneck is.
Ok, so how about the empty BP concept?
They’re all empty ( but know what they will contain ), and only add the needed components on overlap. ( Far enough away to the player is unaware ).
Actually - yeah all those components are what’s slowing it down - each of your BPs creates its own HIMCs by the looks - you need to convert all your components and multiple actors all into just HISMs all added by just a single BP - the only components there should be is your interactive BPs and the HISMCs - one per type of mesh. You should see a huge performance increase by doing that.
I couldn’t see any lights in there which is good - if you do have lights, replace them with emissive materials too - lights are very slow with Lumen.
Rtx 3090
I like the idea but im not sure i can make the blueprints for it, ill give it a go but already im unsure how i would store the info maybe a data table hmmm ill gibe it a go and see where i get
