Board index FlightGear Development

Model optimization

FlightGear is opensource, so you can be the developer. In the need for help on anything? We are here to help you.
Forum rules
Core development is discussed on the official FlightGear-Devel development mailing list.

Bugs can be reported in the bug tracker.

Model optimization

Postby fmg » Thu Aug 19, 2021 3:18 pm

Johan G wrote in Wed Aug 18, 2021 2:28 pm:
fmg wrote in Tue Aug 17, 2021 9:32 pm:One invisible part was to optimize some older models for better performance.

In your experience, what are some good was to do that? And also some bad ways to avoid?

I was asked in my EDDI-thread (viewtopic.php?f=5&t=15378&start=120#p390704) what I do for performance optimization of my models. Because I think it's better to make new thread to discuss this I opened this one. Not sure where to put it, since it not only affects scenery work, but modeling in general. So I tried here. If there is a better place for this please move it to there.

First I won't claim me an expert on this. I only applied all the recommendations I found over the years in the forum and in the Wiki for this (e. g. here: https://wiki.flightgear.org/Modeling_-_ ... erformance ). But therefore I think that this could be interesting for all of us, especially for beginners and hope for a fruitful discussion and eventually for some hints what to do better.
Also it isn't a great effort to do things right from the beginning, but could become unpleasant if you have to fix a lot of files afterwards.

When I started modeling I wasn't aware of all of them. So it comes that in my old models I made things not always in the recommended way.
If you ask for my experience, it's hard to say if there is a benefit that you can directly see or feel from all that. In the EDDI scenery there are hundreds of objects and it's nearly impossible to tell if there is and effect if you optimize let's say 20 of them.

When I started performance was always good and without any drop in fps because the scenery was pretty empty. But now I have a heavy scenery and an old machine, so that becomes an issue. Unfortunately it's hard to find out for me what really counts, because if you have one or few not ideal models around it normally wan't drop you fps to much. Also it is hard to tell what are the bad guys out there or if there are also other circumstances that leads to a bad performance. Therefore I came to the conclusion it's best practice to make everything as good as possible. Even if one disadvantageous model won't hurt to much overall it becomes bad if you have maybe 90 % of them in a crowed scenery. The other way round, if you have 90 % good ones you will hopefully have a better experience.
Normally the EDDI scenery with a heavy plane runs here on this old machine with about 15 fps in short final, which is not great but sufficient for me.
But sometimes the sim dropped to around 3 or 4 fps even with the UFO. I couldn't find a reproducible reason for this yet and I doubt that is because of a specific model. So far as I can tell it only happened when there was other programs running beside FG. But if I working on FG projects and want to try things out I often have at least the web-browser running beside FG just to have excess to documentation or so. Guess that the browser uses a lot resources. If this happens frame rate mostly will go up in the 20ties or more if you look in another direction. I made some testing and rotated the UFO degree for degree to see if I could so find a bad model that causes the drop. But I never found a apparent hint to one model. Sometimes you have all the models in view and it runs with 23 fps and then with 3 with the same models in view. So I guess that it could be down to something outside FG also.

I'm not a programmer that can tell what is the best way to render things. So I rely on the tips given for that, not sure how much they really help.

Things I've done to make the performance as good as possible so far:

1. Vertices & faces
Cleaning up the models and avoid unnecessary surfaces or vertices. And there might be many even if you think you have already done that. E. g. if I made an object by rotating a path often it's not closed on the rotating axis and you have lots of vertices instead of one there and you have to really close to see it in the application. These I welded together as one. In the beginning I was not aware of this since it looks like one in normal view.
Guess this makes sense anyway, but in some testing I had to admit that I couldn't see any effect. The first model I made for FG was the EDDI taxiway lamp. I made it way to detailed, but the scenery was empty and so I never saw any drop in performance. Now while the scenery is full the fps goes down. So I did a test with a reduced version of the taxiway lamp (surfaces: 1176 vertices: 1318 versus surfaces: 576 vertices: 682 per lamp). Since I had about 233 of them in the scenery I hope this would made a difference. But it did not.
Some say, that vertices count isn't really an issue, but on the other hand I in one case I found an drastically effect by replacing the fences. In the beginning I used a given model of a fence, where every wire was modeled. Later I made my own with a texture with an alpha-channel, and this was a huge progress. Doubles the fps after that. I was a bit astonished by that because normally it was said, that alpha-channels are bad for the performance and I also had a bit large texture file (475 KB IIRC, see: viewtopic.php?f=5&t=15378&sid=662944f9ac39cc2f21bc7a0215a1b4ea#p155126).
So hard to say how bad the vertices really are. But in the old fence the wire was made of a line between two vertices. No real 3D element. Looks like this is something to avoid. At least it looks odd in the sim because these lines get scaled up the greater the distance gets. If you use a real 3D object instead this will be drawn correctly.

2. One-sided surfaces
Advice was: Use only one-sided surfaces instead of double-sided. Here I never noticed any difference, but may be I had to less double-sided surfaces for that in the scenery. I tried to avoid double-side surfaces but it drives me crazy while modeling. You are never sure if there is an object if you can't see it or if you selected the right one and so on. So I still used double-sided surfaces when I needed them. Now I found, that it's probably the best way to make them one-sided in the end, when everything is finished and make a duplicate for the other side.
Also use flat shaded surfaces if possible. Always done this but with buildings you mostly don't need smooth shading anyway.

3. Merge elements
Merge as much parts of the model to one as possible, because it is better for the renderer to handle fewer objects, even if they are larger. I never done this in the beginning, so there is plenty room for improvement on my older models and I did this now. But to be honest I never see a huge difference after that. Not so easy to do. Therefore you have to sort the stuff in your model. Only combine elements with the same texture file and shading/surface type. Takes some time to get into this back again in a complex model you made years ago.

4. Transparency
Sort all transparent elements to the end in your models elements list. because it is best for the renderer to draw these at last. Never done this in the past, but done it now. Would like to know if it makes an difference between transparent color or texture with an alpha-channel and if this should be done with light emitting elements too to where to place them?

5. Colors
Use as few colors in the model as possible. Quite easy if you have a texture file. Then you need only white and may be some transparent color. But without a texture file you have to define all colors in the model.
Would like to know how the renderer handles that? Couldn't find information therefore yet. Does it makes sense to merge only elements with one color together or doesn't it matter? Currently I merge all elements with the same shading together, no matter what color, since I have no information on this.

6. Textures
Use as small as possible texture-files. In my experience this does make a difference. There I have several approaches. The buildings next to the runway I like to have as detailed as possible, since you come pretty close to them and will also have them on screenshots while take off an landing or taxiing. Buildings more far away I make not as accurate with a more generic texture and less details, since under normal circumstances you only see them from a greater distance.
If I need alpha I made a small extra texture for it and it looks like keeping this small is a good idea. Sometimes you have areas where you can/must/should use an repeating texture. Then I also make an extra one for this purpose instead of hugely enlarge the normal texture file.
I always used textures with power of 2 dimensions, but this alone isn't sufficient. It has also has to be with pixel counts like 64, 128, 256, 512, 1024, 2048, 4096. Otherwise the renderer has recalculate up or down in the sim.

Another approach I tried is to use a small repeating texture in grayscale and change the color in the model.
But I have no idea if this really pays or if it's a bad approach. Here you cure one disadvantage with another. At EDDI there are lots of long row houses, and each with a different color. If I would do this via texture I would need huge files for this. So I assumed that I would be the best way to keep the texture file small and tolerate the more colors in the model instead.
Example given here:
Image
As you can see it have needed a rather huge file to do this with all color in a texture.
I really like to know what would be the best solution for this. Maybe one of the developers or a more experienced modeler can tell what's the best option here?

7. ?
1 - 6 was what I have done, but maybe there is more one could do that I still didn't know or have forgotten here?

Best regards

f-)
User avatar
fmg
 
Posts: 565
Joined: Tue Jun 29, 2010 6:13 pm
Location: EDDI
Callsign: fotomas
Version: 2
OS: Mac OS X 10.6.8

Re: Model optimization

Postby fmg » Fri Aug 20, 2021 8:35 am

Well - of cause there was a 7.
But it belongs more to 1.
Never have surfaces with more than 4 vertices. Sometimes I've read that everything should only be triangles But this will double the number of faces. So I made a test, also with the taxiway lamp. A version with quads and one with triangles. Also no difference. So I stay with quads, if possible. But only if the are flat. Twisted one's I split in triangles.
But I only tested with the frame rate and have no idea how to use the more sophisticated tools for measuring performance.
Maybe someone can tell more about that?
User avatar
fmg
 
Posts: 565
Joined: Tue Jun 29, 2010 6:13 pm
Location: EDDI
Callsign: fotomas
Version: 2
OS: Mac OS X 10.6.8

Re: Model optimization

Postby merspieler » Fri Aug 20, 2021 8:42 am

Quads (or any other polygon) vs Triangels makes actually no real performance difference as at loading time, the polygons will be split into triangles anyway.
Nia (you&, she/her)

Please use gender neutral terms when referring to a group of people!

Be the change you wish to see in the world, be an ally to all!

Join the official matrix space
merspieler
 
Posts: 2242
Joined: Thu Oct 26, 2017 11:43 am
Location: Wish to be in YBCS
Pronouns: you&, she/her
Callsign: you&, she/her
IRC name: merspieler
Version: next
OS: NixOS

Re: Model optimization

Postby S&J » Fri Aug 20, 2021 9:40 am

Yes but the advantage of using triangles is that as the modeller you have the choice of how they're arranged. When quads are split into triangles at load time you've no idea how they're going to be arranged and as such you could end up with 'star points' where 5 or more faces have a vertices at the same point. This inhibits the renders smoothing and creates lumps or bumps. Examples can be seen around cockpit windows and wing roots.
"Stay away from negative people.They have a problem for every solution." - Albert Einstein
S&J
 
Posts: 794
Joined: Wed Aug 26, 2020 7:31 pm


Return to Development

Who is online

Users browsing this forum: No registered users and 6 guests