Board index FlightGear Development Aircraft

Polygon Limits

Questions and discussion about creating aircraft. Flight dynamics, 3d models, cockpits, systems, animation, textures.

Polygon Limits

Postby mr. f-2 » Fri Oct 09, 2015 3:15 am

Hello its nice to be here. I wanted to get some information for an aircraft I was working on, specifically I wanted to ask about polygon limits. These days sims like DCS, FSX, and X-plane have extremely high polygon models, 300-600,000 being common and X-plane has a few over a million! now I understand, Polygons don't make the model, the artist does and a good artist could make anything really nice. However I was sort of interested in simply seeing what the engine could do, maybe making a "Tech Demo" craft simply to show off what flightgear could look like on a good, but maybe not great computer. What kind of numbers would we be talking? i've hear someone say 150,000 is doable and I must say some of the aircraft in flightgear like the IAR-80 and the A330-200 look amazing (not that the others look bad at all, just not as high end). I would really like to do something crazy like the Su-33 in this fmv but that might be a bit silly https://www.youtube.com/watch?v=TlU344ZE4Zs

anyway thanks and sorry to bother anyone
mr. f-2
 
Posts: 2
Joined: Fri Oct 09, 2015 3:03 am

Re: Polygon Limits

Postby lanbo64 » Fri Oct 09, 2015 6:53 am

Actually you can try to do such experiment. The most simple way to try is to buy a tremendously high polygon model from a 3D movie studio. Then convert to *.ac format and import to FlightGear.

Technically, OpenGL can handle large 3D project without any problem. Scientists even do that in super computer. However, I haven't tried it in FlightGear. Personally, I believe that FlightGear can handle a Tech Demo, but it may not be very flyable.

Bo
lanbo64
 
Posts: 269
Joined: Tue Nov 25, 2014 6:45 am

Re: Polygon Limits

Postby Thorsten » Fri Oct 09, 2015 7:04 am

What is a too high polygon count depends on your graphics hardware, how the polygons are to be rendered technically (single draw vs. multiple draws) and how much else is in the scene.

For comparison, the GPU on my old computer would render everything up to ~400.000 vertices fine and then framerate would collapse, my new computer manages about 4 million vertices without hard framerate drop and has still delivered acceptable results with 12 million vertices.

So if you put a single million polygon model into the scene, it's not a massive problem for modern graphics cards, but it doesn't scale - if others get to see your model over MP (because you are perhaps not providing a lowres version) and there are ten such planes in the scene, it's misery for everyone. Likewise, if you happen to meet a user with a low performance GPU in MP, he is going to suffer.

The rule is hence that a plane in FG should use as high polygon count as needed, not more.

Beyond some point (usually well below 100.000) vertex count doesn't influence visual impression much any more, rather detailed texturing, normal maps, reflection effects and good interaction with the scene light become the dominating factors. So in my view, there is simply no point to drive vertex counts up to the millions, other than to impress users who are impressed by large numbers. A gifted modeler can achieve the same visuals with good design and other techniques which render much faster.
Thorsten
 
Posts: 10492
Joined: Mon Nov 02, 2009 8:33 am

Re: Polygon Limits

Postby abassign » Fri Oct 09, 2015 4:16 pm

The problem is very interesting, because for the G91R4 (3D design unfortunately currently still) I had discussions with the person who did the 3D model. 3D modelers often lose a lot of time in an attempt to maximize the number of vertices, but actually I think it's more important to spend their time on other things, such as the optimization of the surfaces, as they often appear to be "edgy" with an effect really far from reality.
I wanted to do a test with a sphere generated with the "wings-2.0.1". Initially the ball had 512 vertices, then, by pressing the [s] (smoothing) I increased the vertices.
Any increase export vertices in OBJ format and then, using Blender them esportavo format .ac (It's a pity, for FGFs, do not use a more common format).
I have included the files generated .ac, in the folder UFO / Models. I positioned the UFO in a point of the scenario (I was interested in making a test in real conditions) and I activated the advanced weather, trees value 5, highest possible quality with ALS active.

These are the results:

My system is:
GPU GeForce GTX 870M with 6GB RAM Video
Linux 3.13
KDE 4.13
Intel core i7-4700 @ 2.4 GHz

Sphere with 1920 vertices -> 56 fps (memory = 3,854,916 KB) Note: Instant loading - file size = 165 KB
Image

Sphere with 32720 vertices -> 55 fps (memory = 3,860,028 KB) Note: Instant loading - file size = 2.7 MB
Image

Sphere with 122880 vertices -> 57 fps (memory = 3,945,024 KB) Note: Instant loading - file size = 11.1 MB
Image

Sphere with 491520 vertices -> 41 fps (memory = 4,256,856 KB) Note: about ten seconds for loading - file size = 45.7 MB
Image

Sphere with 1966080 vertices -> 18 fps (memory = 5,826,128 KB) Note: several tens of seconds for loading - file size = 187.9 MB
I understand that the system working at the limit, as the presents interruptions especially during the change the image magnification (FOV).
Image

From these tests, and other tests that I did, I have the impression that the maximum number of vertices that can be used with a modern graphics card (4.6 GB Video RAM) is 120,000 to 200,000, with no great delays (.ac file size: 7-15 MB)
abassign
 
Posts: 763
Joined: Mon Feb 27, 2012 5:09 pm
Location: Italy (living 5 Km from airport LIME)
Callsign: I-BASSY
Version: 2018.3
OS: Linux Mint 19. x

Re: Polygon Limits

Postby Crashpilot » Fri Oct 09, 2015 5:48 pm

Thorsten wrote in Fri Oct 09, 2015 7:04 am:Beyond some point (usually well below 100.000) vertex count doesn't influence visual impression much any more, rather detailed texturing, normal maps, reflection effects and good interaction with the scene light become the dominating factors. So in my view, there is simply no point to drive vertex counts up to the millions, other than to impress users who are impressed by large numbers. A gifted modeler can achieve the same visuals with good design and other techniques which render much faster.


Sure, it does not make sense to increase vertex count to a level where it does not add to the model anymore. But on the other hand it is hard to estimate at what point it is not adding any more. Effects like bump mapping are debunked immediately when looked at them with a VR-Helmet, which allows real depth perception and unusal camera positions at once. VR-Gear means higher quality demands to the model than good old plain displays. This VR stuff will (most likely) become more and more popular in the near future (2 years).
Crashpilot
 
Posts: 28
Joined: Tue Jan 29, 2008 9:38 pm
Location: Cologne

Re: Polygon Limits

Postby mr. f-2 » Fri Oct 09, 2015 5:57 pm

wow thanks everyone! this has been very good information.
mr. f-2
 
Posts: 2
Joined: Fri Oct 09, 2015 3:03 am

Re: Polygon Limits

Postby Johan G » Fri Oct 09, 2015 6:16 pm

Slightly off topic:
Crashpilot wrote in Fri Oct 09, 2015 5:48 pm:Effects like bump mapping are debunked immediately when looked at them with a VR-Helmet, which allows real depth perception and unusal camera positions at once.

I think that might be dependent on the implementation. :wink: It could very well be a flat surface with shadows of bumps, but it could also be more like normal mapping (is that the right term in this context?) with a rough surface, or it could be done some other way.
Low-level flying — It's all fun and games till someone looses an engine. (Paraphrased from a YouTube video)
Improving the Dassault Mirage F1 (Wiki, Forum, GitLab. Work in slow progress)
Johan G
Moderator
 
Posts: 5361
Joined: Fri Aug 06, 2010 5:33 pm
Location: Sweden
Callsign: SE-JG
IRC name: Johan_G
Version: 3.0.0
OS: Windows 7, 32 bit

Re: Polygon Limits

Postby Hooray » Fri Oct 09, 2015 6:28 pm

abassign wrote:I wanted to do a test with a sphere generated with the "wings-2.0.1". Initially the ball had 512 vertices, then, by pressing the [s] (smoothing) I increased the vertices.
Any increase export vertices in OBJ format and then, using Blender them esportavo format .ac (It's a pity, for FGFs, do not use a more common format).
I have included the files generated .ac, in the folder UFO / Models. I positioned the UFO in a point of the scenario (I was interested in making a test in real conditions) and I activated the advanced weather, trees value 5, highest possible quality with ALS active.


You may want to get in touch with hamzaalloush, who's been working on similar tests:

Subject: How to tell if you are CPU or GPU limited (split)
hamzaalloush wrote:I used the generic "playback" protocol with a good degree of consistency, i used the --fdm=external command, wouldn't this prevent any FDM from actually executing, since it just follows a recorded path?

i did four tests, no scenery as a baseline, and then scenery at graphics levels 0 through 2,

for the sake of inspecting consistency, i plotted the four data series of FPS against Time(a benchmark consisting of exactly 70 seconds), stacked on top of each other, apparently the less limited i was in rendering capability, the more some bottle-necks were pronounced:

Image

and here is the actual average FPS for each case, calculated by averaging /sim/frame-rate, and /sim/frame-rate-worst (which i assume is the worst possible frame rate, given the highest latency frame) for the full run:

Image

The test were done on an Acer notebook, with a modest GT540, on Ubuntu with the latest proprietary stable driver, i could have done the test on a more capable system, but that wouldn't have been representative of most systems.



We do have some fairly heavy/complex models, some unnecessarily so - i.e. in areas that add little to the overall realism (e.g. 777 or extra500).

To see for yourself, you could dump the scene graph to a file using the debug menu, and inspect the whole thing in osgviewer. Which is also a good way to see how much of this is due to FlightGear itself.

To see the impact of your model in relation to scenery/terrain etc, you can use the draw masks /sim/rendering/draw-masks and the minimal startup profile: http://wiki.flightgear.org/Troubleshoot ... up_profile

To see the impact of enabling/disabling Rembrandt, you would obviously have to re-do the test accordingly.
But overall, this should give you a fairly good idea for your hardware, especially in conjunction with using the osg stats: http://wiki.flightgear.org/Howto:Use_th ... reen_stats
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11309
Joined: Tue Mar 25, 2008 8:40 am

Re: Polygon Limits

Postby hamzaalloush » Fri Oct 09, 2015 9:17 pm

Thanks Hooray, yes if you want get in touch with me if you want to come up with all sorts of tests, but mainly use the generic playback protocol, that's what i found the most consistency with, since it doesn't depend on an FDM (and/or autopilot and FCS gimmics that interfer) so you can replay with an aircraft like the ogeL, without any Nasal, and test your graphics(even without its model and/or the terrain), also there are lots of "gotcha" moments that i learnt over time from others(Emilian Huminiuc on Flightgear's IRC channel has been a huge help) as well as from my testing, like having a sample rate for recording double your frame rate, while you need a frame rate cap/limit that your system can hold steady all over the test.

you can also use GNUPlot to have a live plot using pause(pause bieng double the interval for you log file), reread, what i'm also thinking about is using --log-level=debug to signal from stdout "events" that correlate to dips in the frame rate/latency, but i haven't found time to do the latter yet.

other then that, your next best friend is the OSG on screen display, this requires some knowledge to read, but its basically unified OSG stats/perfs so you can find it also used on other software and information about how to read it.

edit: fix name
Last edited by hamzaalloush on Sat Oct 10, 2015 7:57 am, edited 1 time in total.
hamzaalloush
 
Posts: 632
Joined: Sat Oct 26, 2013 9:31 am
OS: Windows 10

Re: Polygon Limits

Postby Hooray » Fri Oct 09, 2015 9:25 pm

Frame-rate throttling is documented/explained on the wiki, and IIRC, also exposed via the UI.

Also, it should be pretty straightforward to extend the SG_LOG() macro so that it also dumps the output of running SGTimeStamp::now() - we could then post-process the log file to match such "events" against the rest of the run-time stats and visualize things in the diagram accordingly.

Those OSG on screen stats could also be exposed via properties and/or dumped to a log file fairly easily using "the OSG StatsHandler".

I guess it would be a good idea for people interested in this to team up and help maintain the wiki article(s) relating to benchmarking/profiling FG, so that we can document the necessary steps/tools and grow a suite of tests over time.

@abassign: we also have an experimental patch/branch that exposes additional run-time stats, such as RAM/VRAM and CPU utilization for the fgfs process (for details, refer to the wiki)

(in fact, we could expose the unix timestamp as a property and then use that for all log files to match different events, because gnuplot supports "timestamps" and event plotting out of the box)
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11309
Joined: Tue Mar 25, 2008 8:40 am

Re: Polygon Limits

Postby hamzaalloush » Fri Oct 09, 2015 10:49 pm

on the topic subject, from what i learn from Emilian, you can find the limit by established openGL extensions that will expose the vertices limit for your hardware, example, i i feel to share this for the rest:

Code: Select all
glxinfo -l | grep GL_MAX_ELEMENTS_VERTICES


so for every OSG drawable that exceeds this limit of vertices, you will get a penalty, so depending on HW as well, i tell you this guy is gold :)

edit: fix name
Last edited by hamzaalloush on Sat Oct 10, 2015 7:58 am, edited 2 times in total.
hamzaalloush
 
Posts: 632
Joined: Sat Oct 26, 2013 9:31 am
OS: Windows 10

Re: Polygon Limits

Postby hamzaalloush » Fri Oct 09, 2015 10:58 pm

@Hooray, i blame the tilemgr for something, i have not yet established proof, but i have evidance/data coorelating jump in a tilemgr subsystem that happens to always cause a FPS dip . latency increase with a mean value larger then other points(i also have SGLOG entries for it that happens even without the terrain, that happens just right before 20% decrease of mean value), in the same time i read as it stand the tilemgr uses prototype osg datapager thingies that i dont understand quite well, but have read on the ML that it is still very well under developing, maybe i will invoke this for James Turner to look at, i just have to collect lots of info. and i luckily have the proper standard test.
Last edited by hamzaalloush on Fri Oct 09, 2015 11:18 pm, edited 1 time in total.
hamzaalloush
 
Posts: 632
Joined: Sat Oct 26, 2013 9:31 am
OS: Windows 10

Re: Polygon Limits

Postby Hooray » Fri Oct 09, 2015 11:08 pm

I would suggest to be careful about drawing conclusions too prematurely - i.e there are a bunch of subsystems that may trigger the Nasal GC, including the scenery/terrain system, so before blaming any SG/OSG code - simply because such issues are much more likely to be due to C++ code at the FG level (with Nasal being one of the main culprits).

In other words, it would make sense to integrate the Nasal GC stats first, to see if things are really unrelated to the GC or not.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11309
Joined: Tue Mar 25, 2008 8:40 am

Re: Polygon Limits

Postby hamzaalloush » Fri Oct 09, 2015 11:21 pm

I'm not talking about Nasal limits either, and yes the C++ side of things :wink: this is where that subsystem lives, although yes, there are drawbacks of Nasal that are well established, but that was not my argument, but if you like, yes, people tend to associate a lot of drawbacks due to Nasal at its current state, i observed things that might not be appropriate to say in this topic, might belong in another Nasal related thread, but i'm not ready to go there yes, so.. we have the mechanism with which to allow for further research, mainly the patches about GC, but as i said, my post above does not blame that yet.

edit: i just re-read your post, your saying the opposite, as in don't blame SG/OSG just yet, and investigate Nasal first.
hamzaalloush
 
Posts: 632
Joined: Sat Oct 26, 2013 9:31 am
OS: Windows 10

Re: Polygon Limits

Postby Thorsten » Sat Oct 10, 2015 6:07 am

Effects like bump mapping are debunked immediately when looked at them with a VR-Helmet, which allows real depth perception and unusal camera positions at once.


There's bump, normal, parallax and heightmaps (in ascending order of quality), and the idea behind goes from generating a shadow as if the surface were non-flat to displacing the pixel as if it were on a different position using ray optics, i.e. a parallax map and a heightmap are generating real depth perception.

Everyone can see that a bump-map isn't truly non-flat when looking closely, so the technique would only be used for surfaces you don't look at closely. Just like 2d sprites are used for objects you see in the distance (say for houses in the background of racing games) and would look silly when seen from close up.

So while it is possible to mess up the visuals of a model by using the wrong techniques in the wrong place, this doesn't have to be so.

Another advantage of visual effects vs. high vertex count is that they naturally scale with number of pixels seen - your million polygon model seen from 10 km distance as a single pixel will still generate a million polygon load for the vertex shader - but a model using heightmaps for the surface will generate hardly any load for a single pixel.
Thorsten
 
Posts: 10492
Joined: Mon Nov 02, 2009 8:33 am

Next

Return to Aircraft

Who is online

Users browsing this forum: No registered users and 3 guests