Jetways not working

[NMahinK]

For some reason the jetways don't seem to be attaching 

[virtuali]

They do here.

[Bruce Hamilton]

Umberto, was something done differently with the jetways, perhaps in anticipation of GSX?  Oliver Pabst released an AES patch for version 2.5, but he says the jetways don't animate because he couldn't exclude yours to replace them.

[virtuali]

He's not referring to the jetways in general, but to secondary jetway only, in parkings where a double jetway exists, we modeled the (static) secondary one as a part of the terminal, so they can't be excluded.

This is obviously faster, since each separated jetway forces additional drawcalls multiplied for each material, splitting jetways just to allow the secondary jetway for AES has a cost we would impose to all users, even those not using it.

We might consider having better integration if AES could be upgraded in the future to allow communication with GSX, in order not to have the two products fighting against each other, but it will require willingness to cooperate from Oliver, because he'll have to modify AES in order to be able to talk with our scripting engine, so we could even do things like dynamically switch objects depending if AES it's in use or not.

[Bruce Hamilton]

Does a jetway have to be seperated from the building to animate, even default?

[virtuali]

Does a jetway have to be seperated from the building to animate, even default?

Yes of course but, since FSX doesn't animate the secondary, the only reason to separate it (and accept the additional performance hit), would be to allow AES on that one.

As I've said, if we had an easy way to communicate with it, we could even do two different version of the object, and display the optimized version if there's no AES active, and the entirely splitted version only for AES usage.

[theshack440]

Yes of course but, since FSX doesn't animate the secondary, the only reason to separate it (and accept the additional performance hit), would be to allow AES on that one.

As I've said, if we had an easy way to communicate with it, we could even do two different version of the object, and display the optimized version if there's no AES active, and the entirely splitted version only for AES usage.

Umberto, just a question. Why doesn't FSX allow you to simulate the secondary (static) part of the jetway? Is it just one of those weird things?

[virtuali]

Umberto, just a question. Why doesn't FSX allow you to simulate the secondary (static) part of the jetway?

FSX it's just designed to recognize only the first main exit for jetway usage. I'm fairly sure they did it on purpose, since FSX allows jetways to AI too, so they wanted to keep performances under control

[theshack440]

Ah ok that makes sense, thank you for the explanation.

Too bad though for someone who would want a working double jetway. How did you get the triple A380 jetway to work then? Just make it an animation that isn't actually a jetway? This is just out of curiousity, while I love it, FSX is confusing (to me) and is a beast that one day I would like to understand 

[virtuali]

How did you get the triple A380 jetway to work then? Just make it an animation that isn't actually a jetway?

Yes, it's just an animation, and it's not "smart" (ok, FSX jetways are not *that* smart...), meaning you are supposed to park in the correct spot for the A380, because the jetway won't adapt to your position like the default ones.

[OPabst]

Does a jetway have to be seperated from the building to animate, even default?

Yes of course but, since FSX doesn't animate the secondary, the only reason to separate it (and accept the additional performance hit), would be to allow AES on that one.

As I've said, if we had an easy way to communicate with it, we could even do two different version of the object, and display the optimized version if there's no AES active, and the entirely splitted version only for AES usage.

There is no need for 2 Versions. It's only needed to have the static secondary Jetways exported as a seperate MDL (all jetways in one, not each one as single object) and placed as one Scenery Object via BGLComp. In this case, you have the same performance, because there is no difference, if the jetways are part of the terminal MDL or in a seperate MDL, in both cases you have one "drawcall" for the jetways, same as when they are part of a bigger Terminal MDL, because they have there own Material/Texture, so they gernerate one call in both ways.

[virtuali]

In this case, you have the same performance, because there is no difference, if the jetways are part of the terminal MDL or in a seperate MDL, in both cases you have one "drawcall" for the jetways, same as when they are part of a bigger Terminal MDL, because they have there own Material/Texture, so they gernerate one call in both ways.

Not true.

Yes, every material generates a drawcall, but the XtoMdl compiler sorts objects by material, and all polygons sharing the same material will be drawn together with a single draw call, if they are in the same .MDL.

Having the jetways in a different .MDL, would break the sorting by-material optimization the XtoMdl compiler does, since it's not propagated through different .MDLs, and there will be more state changes (costly) instead of just setting the Terminal material,  draw all the Terminal polygons, then setting the Jetway material, and draw all the jetways together.

And, a jetway in a different .MDL called as a library object, means it will have its own transformation matrix so, on top of the state changes due to losing the material sorting, there will be additional state changes to apply independent transformation matrices to each jetway, while if they were part of the same .MDL, they would shared the single transformation matrix of the Terminal itself.

[OPabst]

In this case, you have the same performance, because there is no difference, if the jetways are part of the terminal MDL or in a seperate MDL, in both cases you have one "drawcall" for the jetways, same as when they are part of a bigger Terminal MDL, because they have there own Material/Texture, so they gernerate one call in both ways.

Not true.

In the special case of Zuerich,  you will gernerate 4 calls more, because here the jetways use the same textures as the terminal. Ok. But this is less then each of your animated jetway will need, so I don't think you will see it in any form at the performance.

[virtuali]

In the special case of Zuerich,  you will gernerate 4 calls more, because here the jetways use the same textures as the terminal. Ok. But this is less then each of our animated jetway will need, so I don't think you will see it in any form at the performance.

I agree that this specific case of the secondary jetways on just Terminal B at Zurich won't affect performances in a noticeable way, but the issue was more how we design airports in general, and if we could know if AES is enabled or not, we could extend the method to the whole airport, and dynamically alternate between two entirely different versions of the terminal, one fully optimized for fps and the other splitted. With the way we generate scenery, the "slow" version wouldn't even be created, it will only take a bit of hard drive space more...

[theshack440]

Yes, it's just an animation, and it's not "smart" (ok, FSX jetways are not *that* smart...), meaning you are supposed to park in the correct spot for the A380, because the jetway won't adapt to your position like the default ones.

Haha ok that clears things up. Thank you.