Carenado Fokker F50 Released

[RKinkor]

I have taken the issue up with them and so far, to no avail. I am of the belief they never properly tested it in FSX seeing the issues I am seeing. I am almost certain the large internal MDL file size (which I understand is for PBR usage) is behind the problem. With the full Cheyenne model, I can't get out of the traffic pattern without have a VAS/OOM. The lite model works better but even with that one I usually began using up VAS by the end of the flight. IMO, they should offer a regular sized model with various texture options to customize VAS & Memory usage. As it stands, I am out $40 until I go with P3Dv4. For now I won't be buying the Fokker 50 which is a pity.

Yes that is unfortunate, I spent weeks pulling my hair out thinking it was scenery issues not a airplane issue and unfortunately for me P3d doesnt work for me(just doesn't look right on my setup) but I am trying out X-Plane 11 to try a 64bit sim so far not bad though scenery is an issue.

[jankees]

Guys, regarding the model discussion, I forgot to mention there is also a 'lite' version, with the models being 80 MB exterior and 98 Mb interior..

[jankees]

I do not have this a/c yet but will get it soon. Specially if the liveries of Amapola and Icelandair are available. Are they somewhere ready for d/l?

They are now, go here .

[jeansy]

2nd one, Austrian airlines has been uploaded

This should be up in the next day or 2

[Bjoern]

Guys, regarding the model discussion, I forgot to mention there is also a 'lite' version, with the models being 80 MB exterior and 98 Mb interior..

That's still absolutely insane. What does ModelConverX's "Model Information" screen say (Drawcalls/Vertices/Texture Vertices)?

[jankees]

last one from me for this weekend:





uploading as I type this

[StormILM]

That's still absolutely insane. What does ModelConverX's "Model Information" screen say (Drawcalls/Vertices/Texture Vertices)?

When I questioned about the interior model size (on both the full and lite version of their Cheyenne III), I was told it had to do with PBR being added to it. Whatever the case, in FSX it simply will not work unless you're using the lite model and/or turn your settings down to ridiculous levels. I assume in P3Dv4 the full model runs just fine. I wish they gave the option to have a smaller size models (similar to their earlier Hawker and Citation which run great on my system).

[menef]

Repaint request for Miniliner F50 Freighter.
Miniliner was a small italian cargo company operating from 1982 to 2015. It worked mainly for FedEx/UPS/DHL. The base airport was Bergamo Orio al Serio (LIME) Italy.
The fleet was composed by 5 F27/500 and 3 F50 Freighter. LIME is the airport 20 Km far away from my house, is the airport where I fly at the local AeroClub, and there are all the old F27/500 abandoned in the ex-Miniliner apron :-(
I don't know if it is possible to cover the passenger windows to make the cargo version...
May be Carenado will add in the future the freighter model as they did with the Caravan...

[Cirrus N210MS]

i am sure enjoying it

[Bjoern]

When I questioned about the interior model size (on both the full and lite version of their Cheyenne III), I was told it had to do with PBR being added to it. Whatever the case, in FSX it simply will not work unless you're using the lite model and/or turn your settings down to ridiculous levels. I assume in P3Dv4 the full model runs just fine. I wish they gave the option to have a smaller size models (similar to their earlier Hawker and Citation which run great on my system).

You can try to run the model files throuch ModelConverter to export them in native FSX format. But that's not a recipe for success, as XToMDL tends to quit mid-compile for very large models.

[Fireball6]

Jankees - thank you very much for your fine repaints - they look superb

All the Best

Dirk

[waka172rg]

Nice work Jan and Matt. Could one of you do air new Zealand?

https://www.jetphotos.com/photo/8256284

[menef]

Nice work Jan and Matt. Could one of you do air new Zealand?

https://www.jetphotos.com/photo/8256284

This is an F27, not an F50...

[StormILM]

FYI to everyone here considering newer Carenado models for FSX. I heard back from them today and they indicated that the newer models (like the Cheyenne III and Fokker 50) will have the larger MDL files (I am guessing due to them utilizing PBR). They said that unfortunately this could very well be the reason some users will have VAS issues in a 32 bit simulator when using their newer PBR based products. It would be fitting if they added a warning/disclaimer in their sales notes regarding this issue to prevent users from having issues such as I have others have had.

They have offered me an exchange with anything in their library which I think is a kind gesture from them. I am going to research their models to make sure that whatever replacement I decide on doesn't have overly large MDL files.

[waka172rg]

This is an F27, not an F50...

That is correct Menef. I would like this scheme on the 50. The Ansett that Jan did was never a f50 scheme it's was worn by the f27.

[Victory103]

Any ride reports yet? How's the VC and FMS, assuming standard basic functions?

[jeansy]

Any ride reports yet? How's the VC and FMS, assuming standard basic functions?

The VC is just like any recent Carenado VC, the texturing is well done, and the eye candy factor is high, the passenger cabin again is also well done, I get great steady high and smooth frames in it

all the main and usual systems work that you expect to come with Carenado, most things are click-able and have a function

the FMS is a simple but friendly a box its no pmdg fms, theres a few minor things that could be improved on with the AP however they are minor post#6 gives a brief summary and Its getting a warm response on avsim

Is worth getting, I say yes, there havent been many releases of aircraft of this type and scale that have been favourable across the net or had a life on peoples HD for more than a few days

however, ive only done a few flights in it as ive been busy painting it, but i can see it staying on the HD and im now awaiting the 340 and hopefully the 360

[jeansy]

Nice work Jan and Matt. Could one of you do air new Zealand?

https://www.jetphotos.com/photo/8256284

I will have a chat with JKB and see if hes got plans, after doing the Air Lingus scheme I already have the lines done as its the curvature of the mapping is a pain

anyway I will have a chat with him to see his intentions and we can go from there, I do want to have a NZ and US scheme its just time permitting along with those 2 I want to look at some F27 schemes as well

[wombat666]

That's still absolutely insane. What does ModelConverX's "Model Information" screen say (Drawcalls/Vertices/Texture Vertices)?

Bjoern,
Could you give those of us who have no idea what the problem is a basic explanation (in 'kiddy' terms) of the how and why?
Just a brief one, as I have never had the problem in 32bit or 64bit sims.

[menef]

That is correct Menef. I would like this scheme on the 50. The Ansett that Jan did was never a f50 scheme it's was worn by the f27.

[Bjoern]

Bjoern,
Could you give those of us who have no idea what the problem is a basic explanation (in 'kiddy' terms) of the how and why?
Just a brief one, as I have never had the problem in 32bit or 64bit sims.

Huge model files = lots of data contained = lots of vertex, polygon and material data = more computing resources spent on user model = less computing resources available for other simulator elements = higher risk of running out of memory or low framerates = unhappy users

Memory is a moot point in 64 bit sims and a lot of the bloat in the .mdl is PBR data for P3D, but even without all that extra data, the file would still be way too large. Whatever happened to efficiency in model making?

It's the same thing with current AI models. Way, waaaay too detailed for their purpose. And always accompanied by those idiotic high-res paints. In the numbers they're appearing at large airports, they're killing available memory and framerate.

[wombat666]

Thanks for the explanation Bjoern.
In other words they are catering for 64bit (ie P3D4) at the expense of 32bit?
I suppose the age and limitations of FSX are one reason for this decision.
A contributing factor might be the demand for more 'immersion' and more 'bling' by the general market place, I noted the ancient Mad Dog has been updated and is being hyped as a 'Study Sim'.
That might screw with the 32bit sims on marginal systems as well, not that I'd ever bother with these so called 'Study Sims'.
Curiouser and curiouser!

[PeteHam]

Huge model files = lots of data contained = lots of vertex, polygon and material data = more computing resources spent on user model = less computing resources available for other simulator elements = higher risk of running out of memory or low framerates = unhappy users

Memory is a moot point in 64 bit sims and a lot of the bloat in the .mdl is PBR data for P3D, but even without all that extra data, the file would still be way too large. Whatever happened to efficiency in model making?

It's the same thing with current AI models. Way, waaaay too detailed for their purpose. And always accompanied by those idiotic high-res paints. In the numbers they're appearing at large airports, they're killing available memory and framerate.

Thanks for the informative reply Bjoern.

Is that also the reason the Flysimware Learjet 35A is a strain on resources, or is it another issue?

Pete.

[SeanTK]

Some potential options for repainters of retro Fokker 50s...

Estonian: http://www.airliners.net/photo/Eston...Jti2H2huMCU%3D

Crossair: http://www.airliners.net/photo/Cross...v%2BA2iSMCY%3D

Luxair: http://www.airliners.net/photo/Luxai...v%2BA2iSMCY%3D

AirUK: http://www.airliners.net/photo/Air-U...v%2BA2iSMCY%3D

Maersk Air: http://www.airliners.net/photo/Maers...BNv2A2i2MCc%3D

Lufthansa Cityline: http://www.airliners.net/photo/Lufth...v%2BA2iSMCY%3D


In terms of American operations, Fokker 50s didn't seem to make it further north than the Caribbean and South America, however the Fokker F27 had a sizable presence with operators like Fedex, Air Wisconsin / United, USAir, Horizon Air, and others.

[Bjoern]

Thanks for the explanation Bjoern.
In other words they are catering for 64bit (ie P3D4) at the expense of 32bit?
I suppose the age and limitations of FSX are one reason for this decision.
A contributing factor might be the demand for more 'immersion' and more 'bling' by the general market place, I noted the ancient Mad Dog has been updated and is being hyped as a 'Study Sim'.
That might screw with the 32bit sims on marginal systems as well, not that I'd ever bother with these so called 'Study Sims'.
Curiouser and curiouser!

Yes and no. The trend to pig out on polygons had started way earlier. Probably around the time when the first devs got comfortable with the possibilities that the FSX model standard offered. The only hard limits that FSX (and P3D?) impose on modelers is a 64k polygon limit per texture material and a limit for the number of animations per model. The former can be worked around easily while you'll run into the latter faster than a blind racing horse into a wall once you combine 3D instruments with the tons of switches in models of older generation aircraft.
Sadly not too many devs got the notice that every animation causes an additional drawcall, which inherits the material properties with all associated textures*. So if the name of your game is to reduce the overall number of textures used by your models and therefor map as many parts as you can onto your large texture sheets, you will basically end up with a recipe for a (memory) desaster.

Imagine this: 250 animated parts in a cockpit, each mapped onto a 4 MB texture file (2048x2048 px, DXT5 compressed). 250 drawcalls and each will, at the very latest, load the associated texture into FSX' memory when it is played the first time. So assuming that those model animations are played during use of the model in question, an additional 250*4=1000 MB of memory are necessary. P3Dv4 on any decently modern PC (at least 8 GB RAM and a huge page file) will shrug this off, but any 32bit sim, with its (roughly) 4 GB memory usage limitation is basically deprived of a quarter of its real estate by the user model alone. Add the notoriously poor garbage collection (unloading of unneeded data) of the simulation engine into the mix and, well...you get the idea. At least after a while, when that dreaded message box appears.

Granted, this is nowhere the ultimative word on drawcalls vs animations vs memory (see the thread linked to below), but it at least provides a guideline and a worst-case scenario during model design.

For developers, the seemingly counterintuitive solution is to use lots and lots of separate materials for animated with smaller textures for animated parts to retain as much texture detail as possible. Non-animated party may use 32bit textures at 4096 px resolution. This will be a one-time penalty. But assuming that each of those 250 animations uses a texture with a filesize of 0.5 MB (1024 px with DXT1 compression), the animation penalty will be 125 MB, or one eighth of the previous one.

For users, the only way out is to compress and/or resize textures. If alpha channels are of no concern (either all black or all white, nothing in between), compressing the textures to DXT1 format will yield a 50% reduction in filesize and animation memory penalty while retaining the texture resolution. If alpha channels are a concern, the only way out is halving the resolution of at least the textures that are used by animated parts. Halving the resolution results in a quarter less filesize (0.5^2). It can be awful lot of work to dig through the textures and the model in ModelConverterX to develop a conversion strategy, but it's the only solution short of shelving the entire add-on.

As for model file size, it needs to be understood that a part in the model file contains five major properties: Vertex data (points in space), face data (triangular surfaces connecting said points), material data (which material is assigned to what face), normal data (which vertex and which face points in what direction, using vector format) and texture map data (basically which face goes where on the texture sheet). Other properties, like material settings are negligible. Now with increasing complexity of a part, the amount of all the its properties (save for material settings) will increase proportionally. Double the amount of vertices of a part and the amount of face data, material data, normal data and texture map data will also double. Do this for all model parts and your .x file (containing the raw geometry data) will be a few hundred thousand lines in length. Note that this is without accounting for PBR data, which adds yet another property set to each part. And then there's the animation file, which contains data on what part goes where in space with what orientation at which time. Smoth animations mean lots of data. Throw the modeldef.xml into the mix that links each animation to the associated simulator variable and contains data on what to do on mouse interactions or when a part is supposed to be visible and when not.
All of this is wrapped into the .mdl file by XToMDL, which is therefor a direct result of the model complexity.

I used to scoff at the CS727 for its 600+ drawcalls and dozens of textures, but now I realize that it unintenionally (thanks to being cross-developed for the comparatively restricted FS9, limiting texture resolution to 1024 pixel) did things better than lots of "true" FSX models.

Note that framerates and memory requirements are not necessarily connected. I get really excellent framerates with JF's L-1011, but for some reason, without intervening on the texture side, I can't even do a lap around the field without running out of memory. It's a mystery, but might be caused by gauges.

Speaking of, another thing that devs more often than not get wrong in terms of rendering performance is glass gauges drawn with GDI+. If the term doesn't ring a bell, I should mention that this is what's driving certain payware aircraft's G1000 implementation. Without care, like a refresh rate limiter and other things (GDI+ is outside of my domain), these kind of gauges can drag framerate to hell.


Might be a bit much to read, but this should clear things up as to why I'm a bit touchy about model inefficiency.


* https://www.fsdeveloper.com/forum/th...7/#post-159700

Is that also the reason the Flysimware Learjet 35A is a strain on resources, or is it another issue?

Nope, same combination of animated parts with huge textures (see wall of text above). I had to downsize most, if not all, cockpit textures to 1024 pixel resolution to get things under control.
RAZBAM's Metro is another offender.