Low fps with gmax objects even if...

[arno 1]

Hi Vincent,It's hard to say something about this. For example how many objects have you added (and how big is the area you have added them to)? And how big is the framerate difference caused by adding them?Adding extra detail will always have an influence on the performance. You can't expect your more detailed scenery to have the same framerates as the default scenery.Saying if extra hardware helps is always hard, as even with the same hardware users get different framerates in FS. It just depends on many different parameters.

[Guest vinnysibbs]

Hi ArnoI understand what you are saying but it was Dicks implication that the FPS is only dependant on Polygon numbers within scenery that I was questioning.If that were the case then throwing hardware at the problem would almost certainly do the trick.My own experiments lead me to believe that the amount of objects (however polygon friendly)has an equal if not greater importance to just the polygon numbers.When there are thousands just keeping track of the ref points must add an enourmous amount of cpu calculations. What I am wondering though is if there is another limitation within the program (not hardware or tweak configurable) that means full population with objects is just not possible within FS9?I'll send you some details of my project on your own site Arno and you'll see why this question is so important for me to answer.( perhaps I am attempting the impossible).warm regardsVincent

[rhumbaflappy 113]

Hi Vincent.The number of polygons is increased by the number of objects. And the texturing of those polys adds to the complexity.Could the problem be solved by quicker CPUs, wider pipelines and more/quicker memory? Yes... but such hardware does not yet exist.Where is the 10 Ghz CPU with access to 20Gb memory? It's in 2011.Dick

[Guest vinnysibbs]

Hi Dick:-) Perhaps I am misunderstanding something,I thought that polygon count is only relevent to the visable objects on screen and therefore mostly GPU dependant,using simplified models (as in my experiment )should by definition improve performance,it did not.All the objects that remain outside the field of view only their posistions kept track of,stored in memory and constantly checked ready to be called as soon as they come into view.Only then do the polygon numbers become relevant( I mean if we are using the same library object over and over again) Is this not correct.Vincent

[arno 1]

Hi Vincent,Yes that sounds correct. The only problem is that we no longer exactly know what the visible distance is. The scenery engine determines it automatically now, so maybe it is a lot bigger then we think?

[Guest vinnysibbs]

Hi againSo consider what would happen if we conducted this experiment....1:Create a simple gmax object such as a non textured box.2:Apply a distance check of say only 50 meters.3:compile into a library bgl.4: Place thousands of the object in the Sim by use of the autogen xml and annotator.What will be the resulting impact on FPS when you consider only the objects within a 50 meter radius are visible and adding polygons to the scene?I can tell you that FPS will plummit, even though the sim only has a small number of polygons to draw at any one time and the objects are all placed in the same.... I assume frame friendly manner that MS uses to fill the landscape with autogen.Under these circumstances what is responsible for the fall in frames?Is it solely the load on cpumemory cross checking position or is there another problemlimitation under the hood of the scenery engine itself?I am very interested to know your thoughts on whether real world object density is a possibility with todays hardware and todays flightsim.Vincent:-sun1

[Guest aqui]

I agree with you. Low fps affects all objects that aren't autogen trees or autogen buildings. In fact I have designed a big scenery with thousand and thousand of autogen trees and buildings, but the fps is very high! If I upgrade this scenery with some gmax objects the fps goes too low. RegardsAQUI

[arno 1]

Hi Vincent,I did a quick test. I made an array of 101x101 (10201) objects, placed something like 50 meters apart from each other. For the moment I used a very simple cube as test object.When I loaded this scenery with the cube right away from GMax the framerates indeed dropped very much when I had almost the entire array in view (I got around 4 frames in that case). When only part of the array was in view the frames were better (around 10 going up to 20 near the border of the array).The next test I did was add a distance check to the MDL object, causing it to only be displayed when you are at a distance of 500 meters or less of the cube. Reloading this scene I got around 17 frames all the time now). And of course less objects were drawn on the screen.So I think adding a distance check (or maybe also LOD, didn't test that yet) certainly helps in improving the performance. The fact that the frames were that low with all objects visible indicates that we should not try to reproduce the density of the real world yet :).

[Guest aqui]

Hi Arno!We can have a scenery with the real density only if we use autogen trees and buildings. The limit is this: 300 buildings per square kilometer, 600 trees per square km, 595 buildings self made (bglcomp objects) per 25 square km. Actually my scenery has about 50000 trees per 25 square km and 5400 building per square km.Aqui

[Guest tdragger]

Are you using an LOD scheme to reduce the triange count when objects appear very small? This is a common issue. Unless you include lower poly-count LODs FlightSim will render all the geometry no matter how small the object appears on screen.

[Guest Horst]

Hello all,interesting discussion!Is their a relationship in your tests, when you changing the upper_frame_rate value?Will the frames be better?Or any influence with this value?ThanksKind regardsHorst

[Guest The_Sarge]

(Following comments from my own experience)1. With regard to "what is visible" when adding scenery objects: doing macro placements with XML, I learned that one part of the line of code for each macro contains a value which FS9 uses to begin drawing the object. The default distance is 15,000m and it makes no difference whether you are flying towards, away from, parallel to, or perpendicular to the object. If it is within that distance from your aircraft, FS9 grabs the resources it needs to draw the number of polygons for that object. If there are 100 objects within that distance, FS9 will use resources to draw each and every polygon for all 100 objects, whether you can "see" them or not. If the macro does the ShadowCall, that's a REAL framerate killer, and the impact is severe as the number of objects to be rendered increases. (If possible, edit that call out of the macro code.)2. With regard to polygon impact: FS9 will use far fewer resources to draw 10 polygons than it will use to draw 10,000 polygons. It doesn't matter how many objects are in the scenery; for 1 or 100 objects, FS9 has to draw ALL of the polygons required for that number of objects. The more polygons it has to present, the more resources it grabs, leaving fewer and fewer resources to maintain framerates.3. AI traffic density can be a framerate buster as well. Figure (for argument's sake) that you are using AI models that are 1,500 polygons each. If you have selected a high density of AI traffic and 30 aircraft are at the airport waiting to take-off or landing, that's 45,000 polygons FS9 has to present -- just for your AI aircraft! If there are 50 in the scene, it's 75,000 polygons it needs resources for.4. All settings at max? Framerate impact. Real-time weather with high detail clouds and 15-minute downloads? Framerate impact. VC cockpit? Framerate impact.Now put all of that together and consider what you are asking FS9 to do with what is available on the system. At some point, FS9 starts shunting work to the CPU which is already running FS9, the OS, whatever background routines are running. Can you say "bottleneck"? Since you've (in essence) selected quality over performance by using max settings and high density and real-time weather and high volume AI, FS9 drops performance (framerate) into a much lower priority.It's a trade-off. High quality? Less than maximum performance. High performance? Less quality. You have to make decisions on what you want and be willing to accept less in some areas. It's like the real-world A-10: it can carry a max armament load, it can fly at max speed, it can fly to it's max range -- but it CANNOT do all three at the same time. Max load/max speed = reduced range. Max load/max range = lower speed. Max speed/max range = lower load. FS9 is no different.Max quality, max performance -- pick one, and only one; or settle for somewhere in between.Back to the macro issue -- delete unneeded polygons (if the object sits on the ground, why have a bottom polygon? Get rid of it, no one can see it anyway, so why have FS9 draw it?). Use simple objects (boxes = 5 polygons, top/left/right/front/back) and save the complex macros where it's really going to make a difference. For example: I'm re-opening KPSM (Pease AFB) as a true military airbase, not the "International Tradeport" in FS9. Ops and maintenance facilities are simple boxes; the munitions storage igloos and the "mole hole" are complex macros, with the ShadowCall edited out and the distance-to-draw lowered to 1,000m instead of the default 15,000m. Plus, by exporting the macro as an SCA file and placing my own macros in a LibraryObjects file with GUID, I can call out dozens of copies of a single macro via XML (which is then compiled by SCASM into a single BGL); using that method, FS9 only "draws" the polygons for one call-out, keeps it in memory, and then simply echos that one set of polygons (not draws them again and again, just "echos" the original drawing) in the other locations. For a 50-polygon macro placed 10 times, FS9 only holds 50 polygons in memory for display, not 500 polygons.

[Guest aqui]

>(Following comments from my own experience)>>1. With regard to "what is visible" when adding scenery>objects: doing macro placements with XML, I learned that one>part of the line of code for each macro contains a value which>FS9 uses to begin drawing the object. The default distance is>15,000m and it makes no difference whether you are flying>towards, away from, parallel to, or perpendicular to the>object. If it is within that distance from your aircraft, FS9>grabs the resources it needs to draw the number of polygons>for that object. If there are 100 objects within that>distance, FS9 will use resources to draw each and every>polygon for all 100 objects, whether you can "see" them or>not. If the macro does the ShadowCall, that's a REAL>framerate killer, and the impact is severe as the number of>objects to be rendered increases. (If possible, edit that>call out of the macro code.)>>2. With regard to polygon impact: FS9 will use far fewer>resources to draw 10 polygons than it will use to draw 10,000>polygons. It doesn't matter how many objects are in the>scenery; for 1 or 100 objects, FS9 has to draw ALL of the>polygons required for that number of objects. The more>polygons it has to present, the more resources it grabs,>leaving fewer and fewer resources to maintain framerates.>>3. AI traffic density can be a framerate buster as well. >Figure (for argument's sake) that you are using AI models that>are 1,500 polygons each. If you have selected a high density>of AI traffic and 30 aircraft are at the airport waiting to>take-off or landing, that's 45,000 polygons FS9 has to present>-- just for your AI aircraft! If there are 50 in the scene,>it's 75,000 polygons it needs resources for.>>4. All settings at max? Framerate impact. Real-time weather>with high detail clouds and 15-minute downloads? Framerate>impact. VC cockpit? Framerate impact.>>Now put all of that together and consider what you are asking>FS9 to do with what is available on the system. At some>point, FS9 starts shunting work to the CPU which is already>running FS9, the OS, whatever background routines are running.> Can you say "bottleneck"? Since you've (in essence) selected>quality over performance by using max settings and high>density and real-time weather and high volume AI, FS9 drops>performance (framerate) into a much lower priority.>>It's a trade-off. High quality? Less than maximum>performance. High performance? Less quality. You have to>make decisions on what you want and be willing to accept less>in some areas. It's like the real-world A-10: it can carry a>max armament load, it can fly at max speed, it can fly to it's>max range -- but it CANNOT do all three at the same time. Max>load/max speed = reduced range. Max load/max range = lower>speed. Max speed/max range = lower load. FS9 is no>different.>>Max quality, max performance -- pick one, and only one; or>settle for somewhere in between.>>Back to the macro issue -- delete unneeded polygons (if the>object sits on the ground, why have a bottom polygon? Get rid>of it, no one can see it anyway, so why have FS9 draw it?). >Use simple objects (boxes = 5 polygons,>top/left/right/front/back) and save the complex macros where>it's really going to make a difference. For example: I'm>re-opening KPSM (Pease AFB) as a true military airbase, not>the "International Tradeport" in FS9. Ops and maintenance>facilities are simple boxes; the munitions storage igloos and>the "mole hole" are complex macros, with the ShadowCall edited>out and the distance-to-draw lowered to 1,000m instead of the>default 15,000m. Plus, by exporting the macro as an SCA file>and placing my own macros in a LibraryObjects file with GUID,>I can call out dozens of copies of a single macro via XML>(which is then compiled by SCASM into a single BGL); using>that method, FS9 only "draws" the polygons for one call-out,>keeps it in memory, and then simply echos that one set of>polygons (not draws them again and again, just "echos" the>original drawing) in the other locations. For a 50-polygon>macro placed 10 times, FS9 only holds 50 polygons in memory>for display, not 500 polygons.How can I create a macro for one object? What is a macro?

[Guest aqui]

Anyone knows what is a macro and how create it?THX!!!

[arno 1]

As this is a very old discussion, I can't remember the exact context of your question (and I am too lazy at the moment to read everything back), so hopefully this is a useful answer :).A macro, or API object, is a text file that contains code to draw an object in your scenery. Some parameters, like the position, rotation, scale, etc are not yet entered in this code. The program that places the API macro can provide these values. So in this way you can easily place the same object at different places (and with some different settings if you want).Common tools to create API macros are FSDS2, NovaSim, EOD. But you can also write them manual in notepad (if you know a bit of SCASM). It also depends on what you expect from the API of course, which program suits you best.One warning, API macros can not create scenery according to the Fs2004 standards. So it is most likely an object format that is "dying". If you have the choice, it is better to use the Fs2004 techniques.