Carenado Fokker F50 Released

[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/Esto...riVqt1PlPmyr9fKha7dbs6bhbyV5eVDFMJti2H2huMCU=

Crossair: http://www.airliners.net/photo/Cros...qolYrdf7T5kq/9FWr3Zo9nw4r2cuLKobJBPv+A2iSMCY=

Luxair: http://www.airliners.net/photo/Luxa...qolYrdf7T5kq/9FWr3Zo9nw4r2cuLKobJBPv+A2iSMCY=

AirUK: http://www.airliners.net/photo/Air-...qolYrdf7T5kq/9FWr3Zo9nw4r2cuLKobJBPv+A2iSMCY=

Maersk Air: http://www.airliners.net/photo/Maer...qolYrdf7Tpko/91Wr3Zo9HXcr2cuLKobJBNv2A2i2MCc=

Lufthansa Cityline: http://www.airliners.net/photo/Luft...qolYrdf7T5kq/9FWr3Zo9nw4r2cuLKobJBPv+A2iSMCY=


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/threads/animations-and-drawcalls.25607/#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.

 

[wombat666]

Another very informative post Bjoern, TY.
Aside from needing to copy your 'wall of text' to print out and digest (thanks for that all by the way!) I'm beginning to understand why the over modelling causes aggro.
I might get branded as 'Heretic' for this idea, but if developers stopped with all the interior bling, as in entire passenger cabin furnishings in civil types or multiple stations in the military subjects, that might (possibly, maybe?) ease the load?
Given that I try to 'fly' in sim instead of wandering around the aircraft a fully furnished interior is a total waste for me.
If one doesn't ask one never knows.
Must be time for my medication, certainly time I was sleeping!

 

[jeansy]

it hasnt been mentioned why the model is so large, theres ground support vehicles that come with the package

 

[Bjoern]

Another very informative post Bjoern, TY.
Aside from needing to copy your 'wall of text' to print out and digest (thanks for that all by the way!) I'm beginning to understand why the over modelling causes aggro.
I might get branded as 'Heretic' for this idea, but if developers stopped with all the interior bling, as in entire passenger cabin furnishings in civil types or multiple stations in the military subjects, that might (possibly, maybe?) ease the load?
Given that I try to 'fly' in sim instead of wandering around the aircraft a fully furnished interior is a total waste for me.
If one doesn't ask one never knows.
Must be time for my medication, certainly time I was sleeping!

Well, it's not the "what" that kills, but the "how".
There are some planes with very nice, yet efficient cabins and stations around and especially on smaller planes, it does make sense to have these things included. If everything is kept relatively low poly with little to no animations, devs can get away with it. SCS' Tu-134, for example, profits immensely from its glass nose navigator station because of the great vistas offered, yet remains a FS9 model with all its limitations.
Some models also keep their cabin models hidden (thus decreasing the load on the rendering engine, but not the memory impact), unless the user actively wants to explore it by clicking the cockpit door/curtain to make it visible (e.g. Chuck Jodry's Citation Sovereign).
So basically, there may be a lavatory as long as it doesn't have a lot of polys and there's no flushing animation.

 

[jankees]

The Ansett that Jan Kees did was never a f50 scheme it's was worn by the f27.

Looks a lot like a F50 to me though..

But I may do some F27 schemes, not sure yet...

 

[BendyFlyer]

Yep Ansett used the F50, I remember hitching a ride on FND from Canberra to Sydney. While I liked the F27 (Mate of mine flew them with East West, said the checklists [106 items] were horrendous to remember and do) the F50 with its tiny windows, baggage in the back, uncomfortable seats and squeezy interior and it was noisy. I did not like it at all, peformance wise it seemed fine but the Fokker style was gone it seemed. They were desperate days for Fokker and they went to the wall not long after Will I get it? No, happy with the JF F27. One day somebody might do the F28 1000 or 4000, it was a gem!

 

[bazzar]

I'm really not sure what all the fuss is about. Are we seriously suggesting that the average customer has to concern themselves with drawcalls and model sizes?
Developers these days have been brow-beaten into providing more and more fidelity, detail and authenticity- but wait- not at the expense of framerates please and keep the cost down and keep the texture sizes down and don't use too many polygons whatever you do...

It is all very simple. If you want these levels of detail, it is going to take polygons and PBR style materials and textures to achieve them. If you have a computer that cannot handle that then maybe that product is not for you. You can't ask a developer to dumb down a project to suit lower end computers any more than you can ask that developer to produce all this candy for a small price.

Models are going to get larger and larger, trust me. There are export engines capable of allowing that even for 10 year old sim engines like FSX. PBR can be adapted to suit 32 bit operating systems. That is excellent for compatibility using the same models across different simulators. The price? More memory, better cards. That's the price of progress.

 

[jeansy]

 

[wombat666]

I'm really not sure what all the fuss is about. Are we seriously suggesting that the average customer has to concern themselves with drawcalls and model sizes?
Developers these days have been brow-beaten into providing more and more fidelity, detail and authenticity- but wait- not at the expense of framerates please and keep the cost down and keep the texture sizes down and don't use too many polygons whatever you do...

It is all very simple. If you want these levels of detail, it is going to take polygons and PBR style materials and textures to achieve them. If you have a computer that cannot handle that then maybe that product is not for you. You can't ask a developer to dumb down a project to suit lower end computers any more than you can ask that developer to produce all this candy for a small price.

Models are going to get larger and larger, trust me. There are export engines capable of allowing that even for 10 year old sim engines like FSX. PBR can be adapted to suit 32 bit operating systems. That is excellent for compatibility using the same models across different simulators. The price? More memory, better cards. That's the price of progress.

Out-bloody-standing reply Baz!
"Developers these days have been brow-beaten into providing more and more fidelity, detail and authenticity- but wait- not at the expense of framerates please and keep the cost down and keep the texture sizes down and don't use too many polygons whatever you do..."
Exactly, the demand for more bling and 'study sim' levels of complication seem to be the big ticket but the expectation that this will run on a 10+ year old sim and 10+ year old hardware is naive to say the least.
I've learned a lot from a few exchanges with one of our SOH members......and I'm still learning.

 

[IanP]

What Baz said, but with one proviso in my experience, some developers just push poly count because they can. It becomes a challenge for them to see how high a polycount model they can get to compile and run.

Also, some customers just believe that more polys = "better model", without understanding the cost of it, and complain that developers who don't put every little bump and cranny on a model are just being "lazy". Some other customers understand it, want it anyway, then simply lie about how well it works in their sim. More customers couldn't care less. They buy it, realise they can't run it, so bash it in public and either leave it to languish on their sim or uninstall it. Most customers buy get it, realise that it runs a bit slow, so turn settings down to use it, or have it installed, but don't use it because they can't run it the way they want.

PBR has been used in 32-bit games for donkeys years now... Especially comnbat games and RPGs. They just run fewer, smaller, textures than we demand in the FS world and they load and unload them on a more frequent basis, using levels, timed matches and the advantage of smaller view radii. I've just been watching videos all about how to do it in earlier versions of Unreal and Cryengine as part of an online course.

Cheers.

Ian P.

 

[ncooper]

Intriguing as this is, what is the correlation between a model file size and what it displays?
Out of curiosity, I looked at the:

PMDG DC 6 and its model files are 16.4 mb and 21.3mb.
The Majestic Dash, 4.52 mb and 6.15 mb
The Just Flight Fokker F 27, 10.8 mb and 14.8 mb.