Jump to content
Sign in to follow this  
arno

Area() command...... Frame Rates

Recommended Posts

Guest

Hi guysAny thoughts!!Is it considered efficent, through the use of loops/Sub-Routines, to reduce the number of Area() commands that are used in the code structure.I would appreciate your commentsRegardsDave

Share this post


Link to post
Share on other sites

I don't know if anybody has figures to support it, but I would say YES. It seems more efficient to place more RefPoints and thus objects into one Area block.But, as I said, I don't know if anybody has some figures to proof it, it's just my feeling at the moment :).Arno


Member Netherlands 2000 Scenery Team[link:home.wanadoo.nl/arno.gerretsen]Arno's FlightSim World for scenery design hints, tips and other tricks...

Arno

If the world should blow itself up, the last audible voice would be that of an expert saying it can't be done.

FSDeveloper.com | Former Microsoft FS MVP | Blog

Share this post


Link to post
Share on other sites
Guest

Thanks ArnoI agree with you, its seems to make sense and be logicalI guess their would be only one may to find outI might have a go at this, to compare, unless as you say, someone knowsRegardsDave

Share this post


Link to post
Share on other sites

Hi Dave.I agree that this might be something to explore.I looked at "ohare_placement.bgl", the MS default for Chicago's O'Hare International.301 separately placed objects! All with their own Area.They are sorted by Latbands. That would save memory. And they are sub-sorted by v1... perhaps for convenience. And possibly they are then sub-sub-sorted by v2. Some v2's as low as 8 meters. Common v1's are 500 meters, 2000 meters, and 0 ( unlimited to the ceiling of about 22km (?) ). I think that's a good idea in a project... to organize them this way and to use standard v1 ranges... but I'm not sure the sim really benefits by using standard v1s, or this organization.Some objects used ShadowCalls, but most did not... and I'm guessing ShadowCalls are redundant in FS2002, as we can turn them off in our display properties. I recall FS2000 did not have shadows at first (?)... but the patch added them.----------------------Why would all these need their own Areas? I think they were probably created individually, then combined within Latbands... finally latbanded bgls merged. There might be some savings of framerates, as long as similar Areas were kept within thin ( 512 meter (?) ) Latbands.From the FS2000 Scenery SDK:"Latbands are the most common way that BGL files are spatially sorted. Latbands define a band of latitude all the way around the global. Bands are in steps of 512 Meters. These bands can be as thin as 512 Meters to the entire global. Within each section that latbandsare used they can be duplicated, over-lapping, and in any order. The most efficient usage of latbands is to have many narrow latbands. Latbands are used in VOR/ILS data, NDB data, object data, and miscellaneous data sections."Then later:"If other objects were in close proximity, they would fall within the same latitude range and we would still only need one entry in this list. If, however, the database included another object that was at a vastly different latitude, we would add a second LATBAND_REL instruction to the list."That's pretty much it for Latbands... but MS used them for O'Hare's many objects... and they were not VASTLY separated objects, as the SDK later advised. They were narrow Latbands.. apparently for efficiency of display.Dick

Share this post


Link to post
Share on other sites

Hi all.Regarding O'Hare...I decompiled the "ohare_placement.bgl", with BGLAnalyze, and then recompiled with SCASM. This eliminates the Latbanding ( LatRange ), as SCASM doesn't support multiple LatRanges ( dirctly ), and BGLAnalyze lumps everthing together in a single LatRange. Assuming everything else is the same, FPS decreased for me from about 38FPS over the terminal, to 33 ( about a 15% decrease ).I then eliminated ShadowCalls, as I believed them unnecessary.. but they aren't.. we do need shadowcalls for these objects.I eliminated the Perspective command, and CrashIndirect. Essentially no FPS difference with placing these many objects... the objects display correctly, and crashing works fine. But I can see no advantage to leaving out the code!I'll try some Area manipulation as Dave indicated above, and see if that makes a difference.Dick

Share this post


Link to post
Share on other sites
Guest JR Morgan

>>This eliminates the Latbanding ( LatRange ), as SCASM doesn't support multiple LatRanges ( dirctly ),<<>>, FPS decreased for me from about 38FPS over the terminal, to 33 ( about a 15% decrease ).<<*** Darn-it!.... 'Sounds like BGLC wins the election here..>>I'll try some Area manipulation as Dave indicated above, and see if that makes a difference.<

Share this post


Link to post
Share on other sites

Hi J.R.Multiple LatRanges are very possible with SCASM. You just need to compile separate BGLs for the different LatRanges you'd like to use, then SCLINK the BGLs all together.( a merging of BGLs ).I think a lot more testing would need to be done to decide if narrow LatRanges really are of any value in FS2002.More disturbing to me, is that I tried several times to combine all the separate o'hare Area() commands into one Area... The BGL compiles, after setting some SCASM buffers larger, but I cannot get any type of Area to make sense... and BGLAnalyze spits back garbage at me. x( So, I'll leave narrow LatRange verification to others... and abandon Area combining as well. I was surprised that ShadowCalls were needed, as I thought I had shown they were not before. I do believe CrashIndirect and Perspective don't need to be used... but there appeared to be no Framerate increase... and possibly this is right.Just because we compile commands for display, it doesn't mean the commands are simply executed one after another. Perhaps "display" tables are built internally in the sim, and once built, execute at the same speed regardless of the unnecessary code we add. That would make sense to me. And if that is true, then combining objects under the same Area() is a waste of time, as the table is displayed at runtime, not the actual commands we use.LatBanding ( or LatRanging in SCASM ) might save time, as it may reorganise the internal display "tables" efficiently. Gerrish Gray might have some knowledge of this.. or perhaps Christian Stock.LWM and VTP code has been found to be in a datastream, and that is controlled by not only the order within the BGL, but filenames ( alphabetically ) in the same 'scenery' folder, and Scenery Library order, too.More traditional BGLs don't require that strict ordering. Note that a library can be anywhere, as long as it's active.I think conservative use of polygons, using multiple LODs in objects, conservative v1 values, possibly use of the newer FP commands will have a greater effect on display speed than trying to trick the flightsim. For example, at 20000 meters, we don't need a baggage cart displayed! And even at 500 meters, we don't need to see the wheel spokes... perhaps just a very few polys need to be used. I like eye-candy too, but if it would be out of range or details compressed because of distance, why waste framerates?... at 1000 meters a cube with simple textures will display as a baggage cart very nicely. At 500 meters, people look like dots. At 200 meters people start looking like ants.Dick

Share this post


Link to post
Share on other sites
Guest

hi Dicksome of your comments are very thought prevoking and interestingI'm affraid that the Lat bands are a little beyound me at the moment, but your experiment with the Area() command is interestingWhat leads me to this orginal question, is my own scenery design and its impact on Frame Rates, see pic belowI would consider my Type of airfield as simple, yet it introduces a 34% drop in Fpm, and yet Gary summons work of EGBB(uk) medium size Airport, can Achieve 25 Fpm, which is exactly comparable with my own designI am in the process of eliminating the culprit which may be causing such a large impact, but this takes timeI use a Library File for most Objects and use DXT textures alsoI realise you can answer the cause, but thought you may be interested, given the discussion

Share this post


Link to post
Share on other sites

It's all about polygons.Reduce the number of polygons, and the framrates increase. By displaying much more simple shapes at greater distances, you reduce polygons the videocard needs to render.In your above picture, Are those static planes? Notorious for having many polys. I see the tower, on top of the building, has transparent windows... but do I need to see that from this distance and speed? A simple blocky shape with 1 texture wrapping the shape would probably work as well. At what distance do we need to see the trees around the airfield... and what different colored shapes could you use at different distances? Lots of times, a simple shape, with a complex texture, will save a lot of time... instead of drawing windows, fake them with the building's texture, and reduce the polys. I see many airfields we design are not bad, regarding framerates, as we taxi around. But when we get in the air, the framerates drop. Switch to another window view, and the rates increase. Why? Because the field of vision no longer contains all those polygons... so they don't need to be drawn. Do we need a light post at 200 meters? No. At night we might see a light, but not the post, and during the day, the post might not even be visible from that distance.MS seems to set standard distances at which objects will appear. Why not disassemble the Oshgosh scenery, or O'Hare, and see how MS controls what shows at various distances. See how simple their static plane shapes are.Control of v1 and v2, as well as using different levels of detail at different distances ( even if we need to use a different, simpler object, at different distances ). Those things preserve framerates.Dick

Share this post


Link to post
Share on other sites
Guest

Hi DickThanks for your thoughts aboveIn particular, Gerrish had helped me with my building designs, and they are simple blocks, with the detail in the texture. The transparancy in the control tower, is actually though the texture, although as you say, it is visable from far to far away.The trees are only visable from, a mile or less, certain only from where visableI must admit, your idea of substituting a texture for a colour, from a certain distance, is a good idea, but this is beyond me at present. I think some of your thoughts are a good indication to the advantages of programming with Scasm, rather than just using Graphical Front End programs. I think airport 2.6, goes a long way to merging and introducing the user to scasm, which can't be said about the program I started out with less than 12 months ago.The static aircraft are from FS98 Mdl files, and its interesting the comments you make, yet large Airports have such a tremendos amount of detail, which mistifies me!!!Heres some of the figures that my 34% figure was based on!!!!-----------------------------------------------------------------------------------------------All frame rates are taken from a fluctuating figure and I have disregarded any high's or lows They were also measured as a constant comparision, with regard to Programs that were running inthe background and represent, more the difference and effect of different parts in my sceney-----------------------------------------------------------------------------------------------Scenery Displayed with Gerrish Tree Library-----------------------------------------------------------------------------------------------Virtual Cockpit 22.1 - 26.6 Spot view 22.5 - 27.7cockpit view 23.8 - 25.6-----------------------------------------------------------------------------------------------Scenery Displayed without Gerrish's Tree Library, but Library still in Memory-----------------------------------------------------------------------------------------------Virtual Cockpit 21.0 - 25.6 Spot view 23.8 - 26.3cockpit view 23.8 - 25.6-----------------------------------------------------------------------------------------------Scenery Displayed without Gerrish's Tree Library, with Library removed from Memory-----------------------------------------------------------------------------------------------Virtual Cockpit 23.8 - 27.7 Spot view 23.8 - 27.0cockpit view 23.8 - 27.0-----------------------------------------------------------------------------------------------Scenery Not Displayed (Welshpool)-----------------------------------------------------------------------------------------------Virtual Cockpit 35.6 - 40.0 Spot view 35.6 - 40.4cockpit view 35.6 - 40.0-----------------------------------------------------------------------------------------------Scenery Displayed without Pylons (total No of 8 pylons from Library file)-----------------------------------------------------------------------------------------------Virtual Cockpit 34.4 - 40.0 Spot view 23.8 - 26.3cockpit view 24.3 - 26.3-----------------------------------------------------------------------------------------------Scenery Displayed with Pylons (total No of 8 pylons from Library file)& 2 Hangers removed-----------------------------------------------------------------------------------------------Virtual Cockpit 23.8 - 26.6 Spot view 23.8 - 26.3cockpit view 24.3 - 26.6-----------------------------------------------------------------------------------------------please excuse my formattingThe only noticable change that the figures point out, are when my scenery is un-installed, also note the Virtual cockpit increase when the pylons are removed, but not the other views.I really expected a leap in Fpm after removing gerrish's Trees's, your in the clear Gerrish!!!!!Any other analysis in the figures, is niether here nor there. but my analysis is not finnishedwatch this spaceDave

Share this post


Link to post
Share on other sites

Hi Dave.I think you've got the right idea... break the scenery down into the discreet elements... and see where your framerate loss comes from.Also, when testing the different elements, restart the sim for each test.Arno, Gorchi and I have found results sometimes are inaccurate regarding autogen, unless we restart the sim for each test... and that could also affect your framerate results... Full autogen cuts my framerates by 1/3.I'm not surprised Gerrish's tree library is FPS friendly... that was one of his goals.You've got a 'baseline' of scenery not displayed at 35-40 FPS.. so you should be able to narrow down the components, one by one, to see who is actually the culprit(s). :)Dick

Share this post


Link to post
Share on other sites

I think I'll give it a try and see if I can see the differences.I have already done the same with seperate RefPoints or not for a set of airport polygons. When I change my converter a little bit I must be able to test the same for seperate Area commands or not.As I indicated before, my feeling is that it should be better. This is because I made my sceneries before with Airport. That uses one Area and RefPoint for each polygon. After that I switched to GroundMaker and one of the changes is that it places more then one RefPoint in one Area command. Sceneries made with GroundMaker seem to give better framerates and I expect the Area thing to contribute for that (but it is just guessing).Arno


Member Netherlands 2000 Scenery Team[link:home.wanadoo.nl/arno.gerretsen]Arno's FlightSim World for scenery design hints, tips and other tricks...

Arno

If the world should blow itself up, the last audible voice would be that of an expert saying it can't be done.

FSDeveloper.com | Former Microsoft FS MVP | Blog

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

  • Tom Allensworth,
    Founder of AVSIM Online


  • Flight Simulation's Premier Resource!

    AVSIM is a free service to the flight simulation community. AVSIM is staffed completely by volunteers and all funds donated to AVSIM go directly back to supporting the community. Your donation here helps to pay our bandwidth costs, emergency funding, and other general costs that crop up from time to time. Thank you for your support!

    Click here for more information and to see all donations year to date.
×
×
  • Create New...