This is an issue that has weighed very heavily on my mind for several nano-seconds now and I'm glad to see it finally being addressed.

I know that I worried about this all last night so much, that I didn't sleep a wink.

I dont understand why there are some very condescending replies in this thread. If it doesn't bother you or you don't have anything constructive to say, don't reply...

 

Sent from my Nexus 4 using Tapatalk

 

 

I dont understand why there are some very condescending replies in this thread. If it doesn't bother you or you don't have anything constructive to say, don't reply...

 

Sent from my Nexus 4 using Tapatalk

 

Well said :good:

Lee, sometimes we just get bored and read these sub-interesting posts.

 

Ray

Obviously wrong, default gates do not affect fps that much. Yes, it's an easy way to save FPS, but look at ALL of FSDT's airports. They all have default jetways and FSDT KLAX has excellent frames.

 

And the same could be said about any add-on. Go say to Fsdreamteam "This is a FLIGHT simulator, not a GROUND handling simulator", or "This is not an airport simulator".

 

All of the small things add up to make the most realistic experience, so yes, we should focus on this. 

 

Here is a quote from the jetways section which you may like to read:

 

"The screen shot shows the default jetway. This one design is used throughout the simulated world.

There is a performance cost in rendering animated jetways, so they only appear when the Scenery Setting is set to the maximum."

 

So, the question is why are animated jetways more framerate intensive than non animated?

 

Well, a simple non animated jetway can be one single part and will only make one drawcall (if the texture is mapped properly). In addition, again if the scenery is made properly, adding additional jetways will not increase the number of drawcalls due to the FSX texture batching. Drawcalls are important because these really kill framerates, far more than increasing polygons. If you can draw 50 jetways with only 1 drawcall you are doing really well.

 

Animated jetways use bones animation and in the example in the SDK there are 8 bones in a single jetway. Animated parts do not use FSX texture batching. Having 8 animated parts means there will be at least 8 drawcalls (each animated part creates at least one new drawcall). Multiply by 50 jetways and you could have 400 drawcalls for animated jetways versus just 1 for non animated.

 

And drawcalls have a very big impact on performance. Reducing drawcalls to the minimum possible should be the objective of all good scenery designers. It is also one of the things that all scenery designers have to consider. Performance vs appearance.

 

 

This is 2013, not 2005, Grow up.

 

Yes indeed it is, but the sim we are using is still 2006 tech, and if devs see benefits in performance by not having moving jetways I don't blame them. I rather have static jetways than having the airport run like a slideshow -_-

You can throw all the technical jib jab at me all you want, explain FSDT's excellent frames at their airports then.

 

And if Animated Jetways have such a high performance cost, than doesn't adding AES just cost more FPS then? hmm..

Apparently I'd just be wasting my time.

Apparently I'd just be wasting my time.

No, you haven't! That post was very interesting, thank you very much for taking the time and share your knowledge.

 

Since I have no idea about what developing a scenery actually means, this might sound stupid, but what about developers give us the option to choose between static and (default) moving jetways during the installation process? As mentioned above, I have no problem with static ones myself, even without AES, but since obviously quite many want to have moving jetways, that seems a reasonable aproach to me (but again, I don't know about scenery design, so from a pro point of view that could very well be supid)

It might help to understand that when it comes creating any content for FSX there are a lot of things shared in developer forums in terms of how to create things, but when it comes to payware offerings it is not uncommon for some discovered tidbits to become proprietary. Thus it is possible for "Brand X" to manage something that other brands have not. That's never going to change.

FSDreamteam jetways do move, but the wheels sink into the ground or the wheels lift off the ground for a heavy, soo.... I still use AES. 

No, you haven't! That post was very interesting, thank you very much for taking the time and share your knowledge.

 

Since I have no idea about what developing a scenery actually means, this might sound stupid, but what about developers give us the option to choose between static and (default) moving jetways during the installation process? As mentioned above, I have no problem with static ones myself, even without AES, but since obviously quite many want to have moving jetways, that seems a reasonable aproach to me (but again, I don't know about scenery design, so from a pro point of view that could very well be supid)

 

That is entirely possible. The developer could make one placement bgl file (ie scenery file) that places static jetways and another that places moving jetways. The user could then run a small utility that switches between the two bgl files.  In fact, ORBX sometimes had a utility program with some airports which would switch on or off certain scenery elements using the technique of just changing the .bgl extension on some scenery files to .off.

 

The issue of course is the extra development time making the moving jetways which are a fair bit more complex than static jetways.

I dont understand why there are some very condescending replies in this thread. If it doesn't bother you or you don't have anything constructive to say, don't reply...

 

Sent from my Nexus 4 using Tapatalk

+1

 

 

Because it requires the developer of the particular airport to provide the files to do that. Umberto explained that, and imagine how long that would take.

 

If they have provided the files for AES support, I see no reason why the same files can't be sent to FSDT should they make such a feature available.

Shouldn't take any longer than it does for the AES developer to make it compatible.

Then again when you're charging 29.90 plus VAT on your product, why go the extra mile, right?