My levels will be constructed of intersecting primitives (cones, cuboids, spheroids, etc.). But since those would be rather large levels (think scale of average SM64 level or Banjo-Kazooie), I’d like to know how much it would affect performance. Average count of primitives per level (not counting enemies/player himself which are very lowpoly, like early 90s lowpoly) would be about 1000-2000 although it’s hard to judge at this point.
So how such approach to levels would affect performance and what are ways to improve it?
If it’s static geometry, you can create the primitives procedurally and put them all in the same mesh. I’m walking through a procedurally generated block world right now and there’s many thousands of cubes everywhere being generated and deleted. They’re part of large meshcolliders built from their collective triangles.
The thing is, I’m doing it this way only because I absolutely, and I mean absolutely, suck at procedural mesh generation and trying it would just make for another failed project. It’s mostly about flipped normals, and Unity doesn’t have “recalculate normals outside” functions like one Blender has (ctrl+n I believe), which works 99% of the time. And yes, I know I should do indices counter clockwise, the problem is that I can’t see it as mesh in my head when I only see list of indices and vertices. So I don’t exactly know which way is “counter-clockwise”.
Anyway, if not for that issue, my game would have level building system similar to one used in Notch’s failed 0x10c. Seen Notch’s streams when he was making it and even could replicate the basic working of it using 8 spheres (“vertices”) that drew “model” between them using GL_Lines.
But unfortunately I can’t wrap my head around procedural mesh code unless I would have function similar to Blender’s “recalculate normals outside”, which obviously isn’t going to happen, so I need other ideas.
Also, while primitives would be technically “static” geometry, some of them would act like Doom’s and Doom’s II “sectors” in that they could have different actions linked with them and could, among the others, become invisible, become passable (by disabling collider), be deleted altogether, change color (game uses flat-shaed polygons as art style because level designers will be able to scale, move and rotate objects at will, anyway most of them and with textures it’d be hard to adjust UVs to such changes and texture would quickly get blurry/too big/not tiling properly) and so on.
Smoke test it. Randomly spawn similar assets or dupe them in editor.
Well, most of these assets aren’t done properly (=with all scripts that would normally be there attached, models are there though), so I’ve figured it that until I do this, I’ll ask here as there are probably at least some people that worked with system like this and may have few tricks for optimization in case (future) smoke test fails.