37 replies to this topic

[IBtheSarge]

Just finished designing/placing the new Control Tower for KPSM (Pease AFB NH):

Only have three more fence sections to place (to complete enclosure of the alert ramp), a fire/crash/rescue station (already designed, just need to site it), a maintenance hangar for the ARRS helicopters, and a couple of transient cargo maintenance hangars.  All 3rd party macros have been replaced with my own.

Owing to the Microsoft layout, it was impossible to remove all of the existing Tradeport objects.  I think enough have been removed to allow placement of the historic recreation of key elements of Pease AFB so those who were actually stationed there can recognize their former Strategic Air Command home.  

The system on which this redesign was created is a P4 3.2gHz with 2.0gB DDR dual channel and Radeon 9550 256mb video; with FPS locked at 30.0, framerates rarely dropped below 28.9 and were most often recorded at 29.8/29.9 except during really weather.  If your system is lower-ended, you will experience lower fps and the opposite if your system is higher-end.

Anticipated test date is 15 November 2005.

NOTES:
1.  The default KPSM (AP929160.bgl) will have to be moved from the {FS9}\Scenery\Name\Scenery folder to prevent conflicts between the redesign and the default.  Place it in a neutral folder somewhere that FS9 doesn't "read" to avoid having flashing runways, taxiways, and terrain surfaces trying to bleed through the new objects.

2.  Unless you alter your AI traffic, civilian traffic will still be in the area and may/may not try to land at KPSM.  It will time-out as there are no civilian parking spots.  (Whether using default AI traffic or UT or other, to remove civilian traffic simply open the traffic.bgl -- or whatever it's named -- and search for KPSM and delete those line entries.)  Pease AFB, when it was active, had NO authorized private/commercial landings and take-offs.

3.  All parking spots are military aircraft, primarily FB-111A and KC-135 spots.  There are other spots assigned for cargo aircraft, med-evac's, trainers, and helicopters.  No matter what kind of military aircraft you use for the test, you will be directed to parking.  If you use a civilian aircraft, there will be no ATC directions to parking; you will simply need to ignore ATC after landing.  After landing, if you wish to taxi to/park in the secured alert area, there is only one entry/exit through the fenceline -- it's on the SW corner of the southern most ramp.  For this test, crash detection on the fenceline has been turned off.

Edited by sarge, 12 November 2005 - 04:52 PM.

[IBtheSarge]

Just to clarify .... scavers, mul, and Taz are the current Beta Testers for Check Six! Designs.  Will PM scavers and mul NLT 14 Nov; Taz already in the loop.

[IBtheSarge]

Last 3 fence sections placed; helo maintenance hangar to be placed today; SP guard tower in the alert area may have to be in a later update (problems with the texturing/alpha channel for the finalization of that object -- awaiting reply from another designer on that).

Over the next few days I will be alpha testing on my system to clear out any easily identifiable bugs before releasing to the beta Test Team, plus doing a bit of clean-up on a couple of things.

[IBtheSarge]

Second Flight (first since February initial flight):







(Notice fenceline around alert area, single entry/exit upper left corner near taxiway)

Grainy shots caused by reducing to 512 pixels wide .... but I think these are good enough to get the general picture.  Plus the wx went to while turning for the inbound pass (low clouds and fog).

[ucantcme]

Very nice Sarge....great job!

[SargeJr3]

Amazing sarge, can't wait to test it

[PiP]

Is this going to be avalible for testing trough SargeUSA. I can test it on a lapop for you.

[IBtheSarge]

PiP, on Nov 5 2005, 09:48 PM, said:

Is this going to be avalible for testing trough SargeUSA. I can test it on a lapop for you.

Well, PiP .... open mouth, insert foot, close mouth.    You've just been added to the list of the beta Test Team, Laptop Specialist.  

I'll PM you at the same time as scavers and mul about where to pick up the beta package.  Let me reiterate, however -- you will have to move the file {FS9}/Scenery/Name/Scenery/AP929160.bgl to a directory that FS9 does not access.  This is the only way to prevent conflicts between the default airport and the newly designed Pease AFB.  You'll know you've got it right after installing the beta package if, when typing "KPSM" into FS9 to goto the base, you see it identified as "Pease AFB (SAC)" instead of "Pease Intn'l Tradeport" (the default airport).

[IBtheSarge]

ucantcme, on Nov 5 2005, 08:42 PM, said:

Very nice Sarge....great job!

Thank you, thank you, thank you.  It'll get better, too.  I'm going to be starting a crash course on creating textures in PSP 9.0 to include making light maps (for the night textures) and alpha channels (for transparencies).  No more relying on other designers' textures and having to wait days (or even weeks) for permission to use their textures.

[IBtheSarge]

scavers, on Nov 5 2005, 08:51 PM, said:

Amazing sarge, can't wait to test it

Found a few taxiway signs that need to be repositioned so the aircraft don't run over the top of them.  Helo hangar goes in tomorrow up on the north extension.  Monday begins full alpha testing of NAVAIDS and ATC comm freqs, plus the appearance of the correct data in FS9's Facility Information window.  Next weekend I plan to add some military AI (KC-135's) to see what the fps impact is.

Around the 15th I should have the modified tails for the Pease KC's and the reserve unit's KC's.  End of the month should see some Pease textures for the Australian-produced F-111 AI aircraft, and possibly the paints for T-37's used for ongoing aircrew proficiency training.

[ucantcme]

sarge, on Nov 5 2005, 09:41 PM, said:

ucantcme, on Nov 5 2005, 08:42 PM, said:

Very nice Sarge....great job!

Thank you, thank you, thank you.  It'll get better, too.  I'm going to be starting a crash course on creating textures in PSP 9.0 to include making light maps (for the night textures) and alpha channels (for transparencies).  No more relying on other designers' textures and having to wait days (or even weeks) for permission to use their textures.

You still in need for Beta Testers??

[Skydvdan]

Hey Sarge,

I justhad a question about your last screenshot.  In real life would you be able to see a fence from that distance?  Maybe adjust the distance that it is visible?  Just a thought though.

[IBtheSarge]

Skydvdan, on Nov 6 2005, 10:07 AM, said:

Hey Sarge,

I justhad a question about your last screenshot.  In real life would you be able to see a fence from that distance?  Maybe adjust the distance that it is visible?  Just a thought though.

The enclosed area is approx 4000' x 1000' .... and from real life experience flying patterns over/around/through military bases, I can guar-on-tee that you'll be able to see that fenceline (at about that exact resolution) from 2,000' AGL.

Just to reassure everyone:  All V1 distances in the API and SCA files for each object are adjusted for realistic presentation.  For some reason (heretofore "unknown" and likely to remain "unknown" into the foreseeable future) the default V1 = 15000, and that's just ridiculous.  What object on an airdrome (civilian OR military) can be seen from 15,000 meters (a tad over 9 miles)?  And that's the distance from the object that FS9 loads the polygons and textures into memory and starts drawing them.  Can you say "framerate killer", boys and girls?  

The ILS transmitters I place are set to appear (be drawn) when the sim'er is 1,500m from them (a little less than a mile).  Hangars and other substantially sized structures are set to start appearing at 5000m (a little under 3 miles).  When I say "start appearing" I mean that you will be able to tell that SOMETHING is there, but it won't become identifiable until you are closer to it.

The V1 distance also serves another purpose -- it is also the distance at which, if you are BEYOND V1, FS9 unloads the polygons from memory, releasing the system resources for other things including loading new polygons for objects which you approach and enter THOSE V1 distances.

At the risk of being mistaken for someone who works in the Redundant Department of Redundancy Department, I will state again that all of this (framerate impact reduction) is possible ONLY because I am using compiled XML to place objects.  It was a pain learning it, but the benefits in terms of "framerate friendly" sceneries is TREMENDOUS!!!!!

[Skydvdan]

Okay, I just had to make sure it was a consideration.

[IBtheSarge]

Skydvdan, on Nov 6 2005, 03:46 PM, said:

Okay, I just had to make sure it was a consideration.

NP; it's a valid question that ALL users should be asking the design community.  It's the only way the designers will start paying more attention to what they're doing in terms of how many system resources their design will require.

My first attempt at design was Loring AFB and Loring International.  Brad can verify that, while it was a REAL enhancement to that area, it was also VERY framerate UNfriendly, even with NO AI installed for it.  That's why I started looking at framerates and all the things that affect fps -- polygon count, texture size, how FS9 loads/unloads polygons, distances at which they're loaded, which parts of a scenery use what type of system resources (CPU, RAM, virtual memory, video RAM, etc).  And then I found the tools I needed to start a wholly different type of designing.

KPSM will be the first completed project under this new design regimen; and if the beta testing proves it to be what I think it will be, other designs will follow (KPBG, KLIZ, etc).  In fact, KLIZ (Loring AFB ME, my first project) is at 70% complete now and KPBG (Plattsburg AFB NY) is at 60% complete.  Just waiting on the KPSM test results to process those two to full completion.

The more users question designers about their methods and processes, the better the designs will become.  It's easy to redo an AFCAD, and fairly simple to place objects.  Bringing everything together and producing something that is a worthwhile enhancement AND framerate friendly takes a bit more work.

[Skydvdan]

Have you done much research on LOD modelling?

[IBtheSarge]

Skydvdan, on Nov 7 2005, 01:50 PM, said:

Have you done much research on LOD modelling?

Very basic, for altering LOD5 terrain via alterations of the LOD13 256x256 cells.  Other than that very basic skill, no ... I haven't.  At my age, it's hard enough learning ONE trick (redesigning airports/airbases).    If you want me THOROUGHLY confused, just give me another trick to learn before I've learned the current one.

[Skydvdan]

When I say LOD modelling I don't mean terrain.  I'm talking about building different LOD models of the same object based on how far away the object is determines which model is displayed.  Check out this link.
It can be done for scenery too, and from what I seem to be gathering it's not just for GMAX.

Edited by Skydvdan, 08 November 2005 - 12:11 AM.

[PiP]

sarge, on Nov 6 2005, 03:38 AM, said:

PiP, on Nov 5 2005, 09:48 PM, said:

Is this going to be avalible for testing trough SargeUSA. I can test it on a lapop for you.

Well, PiP .... open mouth, insert foot, close mouth.    You've just been added to the list of the beta Test Team, Laptop Specialist.  

I'll PM you at the same time as scavers and mul about where to pick up the beta package.  Let me reiterate, however -- you will have to move the file {FS9}/Scenery/Name/Scenery/AP929160.bgl to a directory that FS9 does not access.  This is the only way to prevent conflicts between the default airport and the newly designed Pease AFB.  You'll know you've got it right after installing the beta package if, when typing "KPSM" into FS9 to goto the base, you see it identified as "Pease AFB (SAC)" instead of "Pease Intn'l Tradeport" (the default airport).

lol. I still know the password from when i did EGNL,

So the defaulr airfield there has its own bgl file?

could you not place an exclude over the default airfields airpoirt reference point and have your addons airport reference poin somwhere else outside of the exclusion?

Edited by PiP, 08 November 2005 - 12:57 AM.

[IBtheSarge]

Skydvdan, on Nov 8 2005, 01:10 AM, said:

When I say LOD modelling I don't mean terrain.  I'm talking about building different LOD models of the same object based on how far away the object is determines which model is displayed.  Check out this link.
It can be done for scenery too, and from what I seem to be gathering it's not just for GMAX.

Pardon me .... I immediately jumped to the conclusion that you were asking about landclass/waterclass.  Yes; although it's primarily for aircraft (polygon intense), certain sceneries (such as the one TCY is doing) can benefit from multiple LODs.  Ordinarily there isn't a whole lot you can do with a 12 polygon object (such as a building) to reduce the amout of detail presented.

In the case of several thousand polygons (AI aircraft for instance), you can create an LOD that eliminates any of the interior polygons that would be visible at a closer distance, and another LOD that isn't quite so refined in shape for display at a greater distance.  For that 12 polygon object, you can't eliminate anything else without taking away surfaces that have to be there for the textures that are on them.  That's where the designer must know how to manipulate the V1 distance, and keep the object design to the essential polygons only.  If that is done, then there's no need to use LODs for scenery objects.

Remember, too, that multiple LODs are in one package; and the total polygons of ALL the LODs are loaded into memory simultaneously and only the particular LOD is displayed depending on the V1 distance.  My terrain-covered munitions igloos are 39 polygons, but because I wanted the terrain to change as the season changes, there are four versions of that igloo in the package (for a total of 156 polygons).  All 156 polygons are loaded into memory on start-up, but only the 39 polygons for the prevailing season are displayed.  As I have set the V1 distance to 3,000m (about the right distance for an object that size to REALLY be visible), and since there are NO unnecessary polygons, were I to create an LOD with less detail, some surfaces would be missing that would be READILY evident at 3,000m.

By keeping the design to the essentials, and having no unnecessary polygons, the need for multiple LODs to reduce framerate impact is eliminated.  My Pease AFB scenery consists of 8 T-hangars of 118 polygons each, 2 ILS transmitters, a TACAN, control tower, fire/crash/rescue station, chain-link fencelines, operations and support buildings, a terrain-changing "Mole Hole" alert facility, 9 terrain-changing munition storage igloos, 9 hardened/soft alert aircraft shelters, base operations, and a few dozen taxiway/runway signs.  But by keeping the polygon count down in the designs, and using XML to place individual and multiple copies of those objects, the entire scenery is less than 500 polygons loaded into memory.

The evidence is in the framerates -- my system (P4 3.2gHz with 2.0gB DDR dual channel and Radeon 9550 256mB video) is locked at 30 fps.  The only time my actual framerates have ever dropped below 28.7 is when FS9 was displaying really weather.  So the entire design has a framerate impact of -1.3 fps; of course it will be lower depending on how much weather FS9 has to draw and how much AI I put into the base.  But the complete scenery itself has only a -1.3 framerate hit.

Just as an example:  let's go back to that fenceline.  The west side of that enclosure has one leg that is over 3,000' long.  Polygon count?  2.  There's no way to make an LOD that reduces that; to eliminate one side or the other would mean NO fenceline displayed if you were to approach the base from the direction of the polygon that was eliminated for the reduction LOD.

A lot of the "detail" is contained in the textures placed on very basic, low polygon, structures.  And I even lower the amount of system resources required for texture display by using a lot of extended bitmaps (DXT1/DXT3), which means smaller sized files that FS9 has to load as opposed to standard 256x256 or 512x512 bitmaps.