Generating mesh - performance issues?

I’m going to make a game similar to AudioSurf for iOS, and implement in it ‘generate of route to certain parameters’.

I used the example of Extrude Mesh from Unity Procedural Example and this answer on question - 2 But in iOS there is considerable lag in the extrusion of the object, and if the whole route extrude early in the game - it takes a lot of time, it also has a display problem of the track, consists of a large number of polygons…

Can you advise me how to display the generated route or what is the best way to generate route?

“you can build the entire track AT THE BEGINNING of a level, and then play it. But you WOULD NOT BE able to literally build the track AS THE PERSON IS PLAYING. Why? Because it takes too long to UPDATE mesh in the 3D pipeline (the problem of you actually calculating the mesh, is irrelevant - the problem is 're-importing” the new mesh", thanks to @Fattie !

I generated mesh easier than it is shown in “Unity Procedural Example” and also cut the mesh into small pieces to use Occlusion Culling. Mesh generation of 90k vertices is less than a second. This is my example: - YouTube

Basically putting new mesh in to a scene is … slow !

it just takes a long time to cycle in the new mesh. That’s that really.

To be clear …

(A) completely building an entire scene on the fly, at the beginning of the game, or at the beginning of a level. NO PROBLEM. it takes “a few seconds” to stuff the mesh in to the pipeline, so, it’s no problem.

(B) building something large on the fly, DURING GAMEPLAY … NOT POSSIBLE. it takes “a few seconds” to stuff the mesh in to the pipeline, so, it is not possible in real time during gameplay.

So: A is no problem. B is not possible.

{You can certainly make SMALL changes to the mesh, in realtime, during gameplay - but nothing big.)

To be clear. In both cases the time TO BUILD THE MESH is not an issue.

The problem is stuffing new mesh in to the pipeline (essentially, you are “importing it” to the scene). It takes too long.

Mesh build time is irrelevant.

Mesh IMPORT time is the problem.

IN YOUR SITUATION:

you can build the entire track AT THE BEGINNING of a level, and then play it. But you WOULD NOT BE able to literally build the track AS THE PERSON IS PLAYING. Why? Because it takes too long to UPDATE mesh in the 3D pipeline (the problem of you actually calculating the mesh, is irrelevant - the problem is 're-importing" the new mesh.)

{Note - the small blocks you mention. They are nothing. They are just like putting “cars” on the track, say, or bullets in a scene, or whatever. You can trivially do those on the fly as the game is playing, or if you prefer, do them all at the beginning of the level before gameplay begins.}

So jeronima it occurs to me this question raises many different issues!

One problem seems to be “how many verts can you have in a scene” - note Eric has given a superb example of this in the comments.

Another issue it seems is “how many verts in typical racetrack mesh”

OK so I dug up a PGR (“pretty good racetrack!”) and drew a few. Here are the figures.

So FYI, number of triangles 294
So FYI, meters length is 903

So FYI, number of triangles 892
So FYI, meters length is 2224

So FYI, number of triangles 506
So FYI, meters length is 1774

So FYI, number of triangles 422
So FYI, meters length is 1574

So FYI, number of triangles 446
So FYI, meters length is 1467

Interestingly, it’s pretty much 300 triangles per km. We can define a new unit “T/km” tris per kilometer! Over many typical tracks it comes out to about

330 T/km !!

I did not reaalize this before, I’ve never tried to quantify it !

Now those are is absolutely typical tracks with a typical number of turns, just like your example tracks or any human racetrack. It is smooth-to-very-smooth mesh. You would only use smoother mesh (more tris) in a really tight simulation. The examples you linked to would have less T/km (I’d probably guess about 200) and mariokart would also have less (I guess somewhere in 200-300).

(Interestingly it gives a measure of how curvy your track is. Of course, curves and hairpins need more tris. I have been able to draw really straight soft ovals with as little as 180 T/km, whereas a track full of hairpins is as much as 600 T/km. To repeat, this is visually smooth to very smooth track, many well-known titles use much less “T/km”, it would appear.)

(If you’re wondering about verts, on a track 300 tris will be between 300 verts and 900 verts depending on the layout used and whether they are shared. Generally it’s the same, 300 tris leads to 300 (shared) verts - just draw a diagram to see.)

So now you know!

If your musical track is going to be say 3 or 4 km long, it is going to have - at the most really - 1000 triangles.

The bottom line is: it is very unlikely you will need more than about 500-1000 tris to create the type of track seen in the two example videos.

I hope this helps!

Thank you for asking this question, I never quantified this before. If before today someone had asked me 'well how many tris in a typical track" I would have at first thought it was obvious, and then drawn a blank at the actual figure even within an order of magnitude.

The answer is about 300 T/km for typical good to very good track smoothness. Considerably less than that for anything “chunky, kiddy or fun looking” and probably a bit more (500? but certainly no more than 700,800) for a few simulation.

IMO if I a producer of the project you describe would be saying "OK guys, we need about 150-200 T/km here! No, let’s go to lunch!: :slight_smile:

To summarise some of the many many issues raised here, jeronima,

  1. it would seem your extrusion method is completely and totally wrong here
  2. it would seem one can have far more tris in a scene, than you are thinking
  3. it would seem that the “T/km” for track is tremendously less that you are thinking
  4. in fact the T/km for track is about 100-300 at the most
  5. the actual generation of mesh is nothing computationally, the problem is…
  6. actually “re-importing” mesh is slow
  7. because of 6, as a rule 3D games do not make LARGE items from fresh mesh actually during gameplay - other than small items.
  8. because of 5, completely generating mesh at the beginning of a scene, is no problem at all and commonplace in games

To be clear, if you’re having a problem with (7) - that’s because it can’t be done. Heh! But if you’re having a problem with (8), that’s something you’re doing wrong. Possibly you are using way, way too many tris for your track (my guess, that extrusion system is utterly wrong here).

One point, I am glibly saying “oh you generate track…” Of course, everything is relative, but generating objects out of mesh is of course quite difficult or at least, a specialist discipline. ie, “if you worked at Autodesk on writing Maya for a few years” then it’s easy to generate track - heh!!!

So I hope this helps - you now quantitatively know the T/km value for your track ! 210 ! :slight_smile:

I have just made another answer here because the editing system does not work well, @jeronima

Sorry I forgot about the “invisible wall” ! Sure in very many situations you would have an invisible wall, just as you say. (In your case, you may even have a “roof”.)

the drawing shows the LEFT invisible wall, you would probably have one LEFT and RIGHT.

I guess, it multiplies the value T/km by about three.

So if you have 200 T/km for the track surface, maybe you have 600 T/km for the track with the LEFT and RIGHT invisible walls.

I guess the roof would be quite similar to the surface, so another 200 T/km for the roof.

(If you have extremely sharp “corners” up/down at the bottom or top of a hill … it is possible that the roof is NOT identical to the floor. Or imagine your track is one big loop-the-loop … then the roof is not identical to the floor. You see what I mean? But then, these sort of annoying problems happen all the time in 3D. Usually you can just ignore it and hope the extreme circumstance does not happen :slight_smile: )

it is quite hard to build the side walls. if you do it on an “actual track” it is hard, because usually it does not touch the track but rather the nearby ground because actually you can drive off the track a little on to the grass. if you do it touching the track (like the diagram) it is hard because it’s a bit painful to do it in tight corners. But then again “just” building the track is quite hard, and for that matter - programming anything is quite hard!!! Heh!

Note that in my example diagram the programmer has very simply matched the track, i.e. just use the same verts along the side to make walls going up

Don’t forget that it LOOKS easy but that’s only because I drew a flat section. You can see there are more problems if you are at the start or end of a hill. Life is tough :-/

Note I’ve realised the human figure is too large. He is like 4m tall! That is actually an advertising poster by the track, not a real human :slight_smile:

mesh.Optimize();