Fixing framerates

[Guest R_Driscoll]

Many moons ago I did some initial trials on framerates using McChord airforce base. The main result was a conclusion that number of polygons determined framerates, and that number of objects was not as important.The big airports in the UKS scenery generally have over 1000 objects per package, with some simple objects (such as Jon's trees), a few complex objects (such as Jon's tractor, agtim's planes) and the majority of middling complexity.The big airports all suffer from framerate problems on my computer. I have done a few more tests over the past week trying to find ways to improve framerates. Here are some results (all conducted at Luton in perfect weather, low haze, Steve's Archer, F5 view from player start position showing main terminals, runway & taxiways):1) initialRESULT - 4.2 fps2) replaced all 256x256 graphics with 128x128 graphicsRESULT - 4.3 fps3) restored 256x256, then removed all moving objectsRESULT - 4.2 fps4) switched off all AIRESULT - 4.6 fpsResults so far - graphics resolution is not a factor, confirming the initial tests I did at McChords. So there is no reason to try to save processor time by reducing graphics complexity - might as well go for photo-realistic! But greater than 256x256 is not possible.More tests:1) deleted Luton package except airport (this means I deleted all objects, but kept the airport definition file "Luto" which has information on the runways, taxiways etc to allow AI)RESULT - 15 fps (this is the best I ever see - remember that Noah left my computer on Mt Ararat because he thought it was obsolete technology).2) added primary hangarsRESULT - 12 fps3) added runway, ground overtexturesRESULT - 12 fps 4) added large light towers, fuel tanksRESULT - 8.5 fps5) added trees, small light towers (which don't use transparency)RESULT - 8.4 fps6) landscaping surroundings with approx 800 other small objects, signs, trees, people, tractors etc.RESULT - back to 4.2 fpsI think this shows that adding lots of models has some effect (the initial drop from 15 to 12), but my models are not that complex or sophisticated - basically barns and a few rough curves, so don't impact too much - its just the number of models).But the big drop from 12 to 8.5 is with the addition of relatively few models - the tanks and large light towers. What causes this? I think its due to the use of transparency. Here's where my computer might be different - back in the days when dinosaurs roamed the earth, transparency was done by software. Maybe newer computers take less of a hit here by using hardware - the graphics card.The tanks also use transparency (guard railings) and are two-sided textures - both of these may be very important factors.As a result, if I was making the tanks again, I would make the sides from one material, non-transparent, single-sided, using a small transparent MIP for the railings. But the large light towers depend on transparency to look realistic (think of Jon's power pylons for example).It would be great if someone with a modern graphics card could look at this and determine whether the use of transparent textures causes the same reduction in framerate on computers with hardware rendering!Conclusions on making packages (what I will try to do in future):1) high detail textures are OK to use, look better, do not affect framerate.2) simple objects are best. Too many of agtim's planes will affect the framerate (but an airport needs SOME planes, just like a hospital functions better if there are patients, and a school needs a few students).3) use models with transparency sparingly - you need some (eg fences, light towers, trees) but they cost. Don't use lots of trees - all trees use transparency. Of course some trees are necessary and are very effective at making scenery look realistic, and they are simple objects, so a few are good (but my more complex "tree1" is a bit slower).4) some structures (flat to ground objects such as runways, taxiways and overtextures) are identified by FU3 as "runway" type objects, and rendered in greater detail from greater distances. This is a nuisance, and an exception to point 1) above; that is, detail of textures is important on runways (which is very unfortunate). This was obvious when I redid the Heathrow airport with higher detail runways. Some way of preventing FU3 identifying objects are runways would be excellent!RobD.

[Guest effyouthree]

Rob,I've been doing more playing (when does it stop??) and, just before I plug in the HD and get stuck into UKS, I wanted to do some more experiments (especially before I embark upon more models...).You are partially correct regarding double-sided textures. They can slow things because FU3 always renders the 'other' side, even if you cannot see it. Also, things normally occluded by the object will also be rendered so for example, a tree behind a house may not be rendered at all because it is occluded. Placing a window in the house makes the tree visible. As soon as one polygon requires rendering, the entire object is rendered (or the side you can see if not double-sided). This means that simple comparisons can reveal huge differences between single and double-sided textures. In reality (flying around), it's not 4 times as bad (not even 2) but noticeable.I am working with the 3-sided forest models on this and the result is a slight framerate improvement.As to things appearing and disappearing, it seems to rate simply to the size of the longest dimension of the 'bounding box' vs. field of view. This is why large objects appear sooner and why overtextures and large buildings absorb so much framerate, even at a distance. The only way to fix this is to use smaller model footprints.At some size (haven't found it yet), the models NEVER disapper :-eek I found this with my larger forest models. In some cases, they appear 'through' mountains etc :-eekAnyway, I'll post some things tomorrow :-waveRegards,**************Jonathan Point**************"I'd rather be down here wishing I was up there than up there wishing I was down here"