koobas.hobune.stream
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 - link 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?
$$anonymous$$egaShapes is really cool, thanks! but there's so many polygons in one time... i'm newbie in mobile developing, but in my opinion it's bad. Yes, maybe it's right to create prefabs with a pieces of track, but there will be many restrictions to visualize music... audiosurf is awesome in this plan
This may increase number of polygons in scene, when there are to many Little Blocks. I want to improve perfomance, not simplify code:)
"In audiosurf, there is NO relation between the $$anonymous$$USIC and the SHAPE OF THE TRAC$$anonymous$$" - in audiosurf this is the main feature! Look at this - http://www.youtube.com/watch?v=ZnPNTPSzRtA - and before you start the game you can see the entire track, which is generated on the basis of a song.
There is another programmer in my startup, who is engaged in connecting third party library to find beats and tone of the music. I get the X$$anonymous$$L file from him, process it in the Unity and generate track:) I was testing a second week in the mesh generation on iPhone, so I judged so strictly :)
http://www.youtube.com/watch?v=WCY97OZ9HFQ This is the second game in which the entire route is generated and displayed almost entirely on phone display... track here is quite simple and does not depend on the music, but all the same it is showing almost full on the screen and I do not understand how they achieved this performance...
FWIW ......... Who the heck voted this question down ?!?!! Good grief !
I don't understand vote system on this forum, so I'm afraid to ask questions now))
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.}
Well...you know...the Unity terrain system actually does exactly that (building meshes at runtime), and fairly big chunks at that, depending on what you're looking at. It's not super-mega-fast on mobile hardware, but it does run. Something a little less demanding would run even better. It's more a matter of optimizing properly. Saying it's "not possible" is just untrue.
I'm sorry that I can not "like" this answers, I newbie here and do not know how:) And I do not see all the comments under this post, that were sent to me by mail...
Now I generated the whole track by Bezier spline at game start. I got 45k vertices (written in Unity - Stats). It took about 3-5 seconds UnityEditor. On IPhone3gs and iPod it took about a $$anonymous$$ute(!). I understand that this is the worst option - 45k vertices, but the road does not look quite smoothly yet... and I tried to generate $$anonymous$$esh during the game - the game moves jerkily... so yes - to generate on the fly is not correctly.
I used the example of Extrude $$anonymous$$esh from Unity Procedural Example, but I do not create new vertices myself - for me it makes a script from Example, I just move the object by the scene, and the script connects old vertices with the new vertices of the object - that's they call Extrude (in Example:). Therefore, I have to write my own simple script that generate $$anonymous$$esh, to write something useful here! I hope we will return to this issue in a couple of days!!
Object to extrude - is simple (12 vertices) cross-section made by modeler.
Also I tested simple script generating mesh in android (600$$anonymous$$Hz AR$$anonymous$$v6 OpenGL es2.0). There are 1000-1400 vertices in generated object and game goes more slowly... fps down.
@Fattie, I'm add new 2 vertices per frame to object and when there are 1400 verts fps is down. I already knew that this is wrong:) thanks)
@Eric5h5, 120k for maze? No, You probably wanted to say - Instantiate from prefab, that is another story:) But I create only ONE object and generate mesh in it. In the case of large number of objects in the scene - they can be hide when they are not visible on the screen, and ONE object is drawn and is calculated at all times - that my problem. So, I will try to divide the track into pieces to achieve performance.
I want so much to say, but poor knowledge of English in my way, I'm sorry guys!:)
"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: http://www.youtube.com/watch?v=7_E1G193TsE
Yes, I made a number of separate objects with his own mesh, so they may be hided in game, before we come to them close enough.. just set the camera clipping plane, or occlusion culling in UnityPro for dynamic objects)
i see, it works O$$anonymous$$ for dynamic objects. and how many pieces is your track about 10-20 ?? Cheers
number of pieces depend on length of the music track) I have not tried it yet) Regardless of the number of objects, game will not slow down)I guess..
mesh.Optimize();
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!: :-)
To summarise some of the many many issues raised here, jeronima,
it would seem your extrusion method is completely and totally wrong here
it would seem one can have far more tris in a scene, than you are thinking
it would seem that the "T/km" for track is tremendously less that you are thinking
in fact the T/km for track is about 100-300 at the most
the actual generation of mesh is nothing computationally, the problem is...
actually "re-importing" mesh is slow
because of 6, as a rule 3D games do not make LARGE items from fresh mesh actually during gameplay - other than small items.
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 ! :)
PS @jeronima your English is very good, NP! yeah like I say if you are seeing 45k verts for a track that is totally wrong. It is out by 100x. it should be 500 or so for your track. A very, very, very smooth track would be 1 or 2 thousand.
Oh, this is the best answer I ever seen!:) There are a few things you should understand: I do not add a simple mesh, but the "elevation" (section?) of the object for extrude with thickness - not the actual top area of the track, but its side walls to be visible thickness at the turn of track. -- Oh, I hope you understand me:) So I needed more vertices to extrude, than only for road..
Thanks for the answers! I will continue to experiments and I'll write the results here!
Hiya @jeronima - sure, I totally forgot about that, sorry! Doh!
BTW when you do a track, you very often have "invisible walls" to stop the driver going to the beach. Almost every track in a race game has this.
Now, I do nto actually know if you mean "invisible walls," or, if you mean "walls you can see".
(For example, there could be a "fence", "brick wall" or a "large concrete kerb".) ($$anonymous$$erb, curb, same thing.)
In either case, I guess the problem is similar, I added some info about it in the answer. Cheers!
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 :-) )
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 :)
haha!)) great poster! looks almost the same as our artists have painted)) Yes, that's right, left to try in practice. I was referring to the wall under the road - so they can be seen during a turn, as in AudioSurf - road up in the air: http://postimage.org/image/3qa2896q1/
ok . so in fact your left, and right, WALLS, it looks like they WILL HAVE some texture on them.
fair enough.
fortunately for the "department of making triangles," it is not harder or easier, to make the triangles, if you have texture or not.
(Of course, you do have to make the UV correctly - unfortunately the UV is hard work .... same as for the road.)
BTW inspector Cleuseau says ... you must be in Russia or speak Russian?? $$anonymous$$y computer says something about "we supply your laptops and your software!" :-) So, no need to spend 15 years studying the world's great languages, now we have the internet. Just give me tr.google and Dostoyevski
UV is simple actually. Especially for a road, which would be a repeating texture. You probably wouldn't even have to do any calculations, just use the same UV coords for each segment.
Yes, I've worked with UV and I know how it should look:)
Also, I will not use Bezier Spline. I used to think that it will be more smoothly, but they have a lot of calculations and problems. A smoothness I can achieve in other ways. (The problem there was that hard to find the length of the spline and divide it into equal parts, too many calculations, integrals, and others).
In fact, now I do not see any problems, after our discussion, for which many thanks to you)) is only one problem: I'm away from the computer, the working week starts tomorrow, so I will see results in a few days)
Yes, I am from Russia. English seems to me easy, so I'd better translate from GoogleTranslate, ins$$anonymous$$d you read Dostoyevsky :) Especially now that a lot of people in Russia do not speak Russian well, a lot of words borrowed from English and many badwords)) However, in English, a lot of strange phrases and abbreviations ... but in general, I know what you mean, almost always)
there is 510 T/km with walls.
yes, I generate it all at the start, and make slices of full road with approx. 300 triangles per slice(object) to use occlusion culling:)
