What is a efficient way to spawn physical static nanite meshes?

So first I came along this example Nanite Mesh Spawner posted by anonymous | blueprintUE | PasteBin For Unreal Engine . But turns out Instanced meshes do no support physics. So I ended up with something like this (don’t mind some parts, just and experiment).

And this turns out to be super slow. Spawning 32^3 cubes with Nanite on, takes around a minute, without burning my cpu or gpu. And the quality is awful (check the video with blinking cubes) and fps drops to 30.

It’s on high quality.
Sdf generation is turned on.
The mesh is most simplest form of a cube, imported from blender with scale 0.25.

I think the best you can hope for is instancing as many as you can and changing the ones closest to you to have physics - if you need physics on all of them it’s just going to be slow.

You can create them once procedurally and save them in your level - that’s slightly faster…

I did not even get to the physics part/problems. As you can see in my bp, its unchecked. Currently it’s more of a slow spawning problem and render quality-performance problem.

Saving is not an option, because my project is about procedural creation at runtime.

Then yes, that just leaves making as many possible instances… Creating instances is much much faster - in some tests I’ve done, just using a BP creation loop I was able to create 150K instances in 200ms - and it runs at very good framerates - there’s no way spawning actors could get anywhere close to that.

I built Actor Spawning into a c++ plugin (so I could spawn on construction) - even in c++ it’s not really any faster than spawning in Blueprints.

Converting a small amount of instances back to Actors and enabling physics takes very little time - so that’s the path I’ve gone…

How do one convert instances to actors with physics?

It’s not so much a conversion - more you just delete the index (you need to have either the indexes stored in a way you can find the ones close by, or do line traces that return the instance index, or some such) and create an actor in it’s place (the transform is stored in the HIMSC using the index as, well - an index)

Hmm, I did a test like this

Took ~2 minutes to generate all the 64^3 = 262,144 cubes. So I am doing something wrong?

Fps is good, but stuff is still blinking like in the video.

My cpu:

2022-12-31_120225

And gpu is rtx 3060

That will be because you’ve got collision enabled, try:

image

Regarding the blinking - it almost looks like there are multiple instances in the same places with some z-fighting going on…

Ok it looks like the editor it self is eating up lot of resources, its much faster in play mode. So I am left with questions:

  1. I was given a error: “infinite loop”. Yet it isn’t infinite, how can I fix this. Is there some limit in Unreal settings. And/Or I can do some sleep between the loops? So it generates over multiple frames? Any advice on that?

  2. The awful blinking, like in my video. Can I some have fix that? The should be no z-fighting. Unless I don’t understand the loops. Setting GI to Epic quality, helps a bit.

  1. you can control when that error occurs in your Project Settings->General Settings->Blueprint->Maximum Loop Iteration Count

  1. My guess is either it’s z-fighting or it’s UE5 lumen’s GI doing it’s crazy things…

Yeah I think is lumen. Setting GI to epic helped a bit, and also assigning material to the cube, but its still blinking. Sometimes I also get this

Sometimes not.

Z fight would mean, I am generating cubes in same place and my blueprint is bugous. But its not, right?

I wouldn’t have thought so - but I was thinking about your infinite loop - that happens usually when the blueprint has iterated over 1 million times - but your blueprint should only be iterating 64^3 times which is less than 1/4 of that - something isn’t adding up…

Most likely a bug, in loop count detection. I added a smart print thingy, and its not really going over million and is correct in general.

1 Like