So after some experimentation I found out that the ‘Random Integer’ node is not so random. It is pretty predictable.
I’ve put everything inside a spreadsheet and I’m still adding results. For now, I have a test with 3 Material Instances put into an Array. There is a random int. node connected to set a cube’s material to Red, Green or Blue. To make sure that it is operating normal, the cube Spawn SceneComponent gets removed on CubeSpawn.
The fixed val. for the amount of cubes is 442 for 1 chunk. There are 18 chunks. That means that 7956 cubes need to spawn. If everything spawn correct there should be 8000 Actors in the Scene (including the gamemode etc, and the Minimal_Default stuff!).
I also noticed some Cubes not spawning, EVEN if they have to ignore collisions.
The Random Number Generator is pretty good in my testing; it just comes down to how you are seeding that value as well as making sure you use the same RandomStream rather than constantly resetting it (which would give the predictable behaviors you’re seeing).
I’d play with seeding that value with the current tick count, tick count * some prime number, etc. Worse comes to worse, you can always write your own PRNG and compare results.
Do NOT spawn thousands of separate objects at once, ever. If you are making “infinite” blockworld and not just testing random - you’ll have to look into procedural mesh generation to get usable performance, there is no way around. Or you could try to go with hierarchical instanced static mesh components for small scale blockworld with very limited block types and world size. And do spread spawning actors over time as it’s not cheap operation at all.
Cubes are for example. They only give me the info I need. The cube spawn issue was a bug with the cubes setting them to false for every color. Is fixed with an extra delay.