hubbabubba
Charter Member
As I was working on a project, I decided to include multi-resolution in my model, also known as «LOD» (Level Of Definition or Level Of Details). Exploring the WEB, including SOH, for information, I found very little, and many false interpretation in the lot! So I decided to explore models (MDL files), some I had, some I had to download, to experiment on. Rather than keep this recently acquired knowledge to myself, I've decided to share it with you. If you don't use it for your own modeling, you will at least understand what «multi-resolution» and «LOD» mean when you're reading the description of a bird you're tempted to install in CFS1 hangar.
WHAT IS IT FOR?;
Any visual object you see on your screen, a/c and scenery, when playing CFS1 is made out of instructions run in a loop. For an aircraft, these instructions are within the MDL file. Your computer read these instructions and, when needed, show what these instructions tell him to. In short; the more time it takes to read, the less it has to show. When you're wandering alone in a barren landscape, it does not matter that much. But when you are in a «visually rich» environment, lots of a/c over a complex scenery for example, you may get stuttering, «deck of cards» effects, and even hangups! This is why the framerate vary, depending on the number of objects to read and show.
On the other hand, modelers, quite comprehensibly, want their «babies» to be at their best. Models get more and more detailed, with more and more bitmaps. The passage from AF5 to AF99 did a lot for that trend, SCASM lets you go even further. And simmers were not complaining; they were even complimenting modelers for showing details with ever increasing accuracy.
Then simmers, especially but not exclusively MP gamers, started to exclude certain a/c as «framerate hogs».
Can we have the best of both; good framerate and detailed a/c? Can we keep our cake and eat it too? The answer is YES... with multi-resolution.
WHAT DOES IT DO?;
As the names imply - multi-resolution and LOD -, an a/c could be made of many loops; each one being more and more detailed as you get closer and less and less detailed as it gets further away. Who cares about that magnificent panel that could be read from the outside view when the a/c is only a dot on the horizon? Well, if your a/c was made with AF5 or AF99, chances are your computer's CPU is churning like crazy to read all the vertices, polygons, and bitmaps applied to that panel!
It is surprising to see how many third-party aircraft are made with a single visual model, my Taifun included. AF99, and BAO AF5 before, simply didn't knew better. I don't know about AD2000, but models made with it are such framerate-killers that I would be surprised if it had multi-resolution.
HOW IS IT DONE?;
I will use the CFS1 stock P-51D set of instructions for the demonstration, as decompiled by MDLDisAS version 3.04. The «hearth» of it all takes only a few lines;
:L00356A
IfVSize( :L003598 35 1 )
IfVSize( :L0035B4 26 1 )
IfVSize( :L003612 20 1 )
IfVSize( :L003936 10 1 )
IfVSize( :L004412 1 1 )
Jump32( :L00A048 )
Let me try to translate in English what it means;
When label L00356A is called, you will verify if 35 vertical units are less than one pixel high. If it is the case, go to label L003598. If not, verify if 26 vertical units are less than one pixel high. If it is the case, go to label L0035B4. If not, verify if 20 vertical units are less than one pixel high. If it is the case, go to label L003612. If not, verify if 10 vertical units are less than one pixel high. If it is the case, go to label L003936. If not, verify if one vertical unit is less than one pixel high. If it is the case, go to label L004412. If not, jump to label L00A048.
The labels being called are at the starting point of a visual loop. From top to bottom, each loop is more and more detailed. The jump to the last label sends us to the most detailed visual loop, the one we normally see when we're using the outside view to look at our own plane.
The instruction IfVSize ( or IfVRes ) is a bit misunderstood, even by Manfred Moldenhauer himself, who created SCASM. The first number after the label does not represent the actual radius of the model. It represent an arbitrary number of visual units. If the scale is in feet, this unit will be in feet. If it is in meter, then meters are used. The P-51D is way higher than 35 reference points, but quite close to the highest scaled unit of 29.44. Since only two kinds of length are being measured - original reference points distance and scaled units -, we must presume that scaled units are being used.
Another confusion is caused by the second number; the pixel. If I was to make a visual model where only a vertical line measuring 35 units would show, it would be seen eventually with the previous code, as we are getting further away, as a dot. In fact, any visual model becomes a dot at one point. The difference between a multi-resolution model and a «one loop» model is that the latter will read all the model, then show a dot, while the former will read a loop that says «show a dot». Visually, they both show a dot but, internally, computation is much reduced in multi-resolution.
One side-note here; the instruction IfHSize (or IfHRes) is supposed to do exactly the same thing as IfVzise (or IfVRes) with the horizontal radius but MDLDisAs can't read it and will show an error. But it will compile it correctly! Unless you have a very distorted image on your screen, they are interchangeable.
It must be stressed here that the instruction IfVSize is not the same as IfVarRange( :label 33B max min ). It is not a measure of distance that triggers the conditional jump, but a measure of pixel visibility. If an object is at five hundred feet, zooming on it with the IfVarRange instruction won't change the distance, and will not activate a more detailed model, but if the IfVSize is used, the model shown will change if the pixel count justifies it.
WHAT DOES IT LOOK LIKE?;
This is the view we normally have of the stock P-51D;
The cockpit is translucent, a pilot «bust» inside. Control surfaces are moving. Gears are visible, so are propellers and rockets. Breaking parts will show if needed. But if you go into chase view (C key) and push the minus key of your keyboard to get as far as possible, you will trigger the next loop. The one pixel per one unit barrier broken, this is what you will get;
The translucent cockpit is gone, so is the pilot. Main gears, in a less elaborate version, are still there, but not the tail wheel. Control surfaces are gone, but propeller and rockets are still visible (my deconstruction-reconstruction does not show them, but you can take my word for it). It will still show breaking parts. As diminished as it is, this model is still more elaborate than many third party a/c.
To go further away, you will need to get another a/c to look at, so freeflight is out of the picture, quite literally! So, looking at your wingman P-51D as one pixel comes to represent 10 units, he will look like this;
Textures are gone. Gears, props and rockets too. The silhouette is suggested with rough shapes, but parts are still showing in their proper order. Gluing was performed. I don't know what the Mach numbers would be for that flying tank, but I like the little bugger! Next step would be a 20 units per pixel;
I don't know about you, but it reminds me of these 10 cents styrofoam gliders I bought when I was young. It looks like there is only three parts but don't be fooled; there is 24 as to not make concave polygons. At 26 units per pixel, our beloved Pony has lost its luster;
Yep, this is it! A few lines. But, at 35 units per pixel, it reaches the «dot state»;
We can barely see it, hence the yellow circle. An interesting fact about dots and lines; their «thickness» never changes. This is why some WWI string bags look like cantilever bridges at a certain distance. Simply put; a dot is a dot is a dot, period!
Third party models would gain by using multi-resolution. Maybe not like the stock P-51D, I really think they over did it, but at least with enough LODs to reduce framerate significantly at medium and long distance. Final remarks; you don't have to relate units to only one pixel, as long as you use integers for both. Trials and errors method should guide you rather than some cryptic mathematical formula.
This is how you can have your cake and eat it too, isn't marvelous?
WHAT IS IT FOR?;
Any visual object you see on your screen, a/c and scenery, when playing CFS1 is made out of instructions run in a loop. For an aircraft, these instructions are within the MDL file. Your computer read these instructions and, when needed, show what these instructions tell him to. In short; the more time it takes to read, the less it has to show. When you're wandering alone in a barren landscape, it does not matter that much. But when you are in a «visually rich» environment, lots of a/c over a complex scenery for example, you may get stuttering, «deck of cards» effects, and even hangups! This is why the framerate vary, depending on the number of objects to read and show.
On the other hand, modelers, quite comprehensibly, want their «babies» to be at their best. Models get more and more detailed, with more and more bitmaps. The passage from AF5 to AF99 did a lot for that trend, SCASM lets you go even further. And simmers were not complaining; they were even complimenting modelers for showing details with ever increasing accuracy.
Then simmers, especially but not exclusively MP gamers, started to exclude certain a/c as «framerate hogs».
Can we have the best of both; good framerate and detailed a/c? Can we keep our cake and eat it too? The answer is YES... with multi-resolution.
WHAT DOES IT DO?;
As the names imply - multi-resolution and LOD -, an a/c could be made of many loops; each one being more and more detailed as you get closer and less and less detailed as it gets further away. Who cares about that magnificent panel that could be read from the outside view when the a/c is only a dot on the horizon? Well, if your a/c was made with AF5 or AF99, chances are your computer's CPU is churning like crazy to read all the vertices, polygons, and bitmaps applied to that panel!
It is surprising to see how many third-party aircraft are made with a single visual model, my Taifun included. AF99, and BAO AF5 before, simply didn't knew better. I don't know about AD2000, but models made with it are such framerate-killers that I would be surprised if it had multi-resolution.
HOW IS IT DONE?;
I will use the CFS1 stock P-51D set of instructions for the demonstration, as decompiled by MDLDisAS version 3.04. The «hearth» of it all takes only a few lines;
:L00356A
IfVSize( :L003598 35 1 )
IfVSize( :L0035B4 26 1 )
IfVSize( :L003612 20 1 )
IfVSize( :L003936 10 1 )
IfVSize( :L004412 1 1 )
Jump32( :L00A048 )
Let me try to translate in English what it means;
When label L00356A is called, you will verify if 35 vertical units are less than one pixel high. If it is the case, go to label L003598. If not, verify if 26 vertical units are less than one pixel high. If it is the case, go to label L0035B4. If not, verify if 20 vertical units are less than one pixel high. If it is the case, go to label L003612. If not, verify if 10 vertical units are less than one pixel high. If it is the case, go to label L003936. If not, verify if one vertical unit is less than one pixel high. If it is the case, go to label L004412. If not, jump to label L00A048.
The labels being called are at the starting point of a visual loop. From top to bottom, each loop is more and more detailed. The jump to the last label sends us to the most detailed visual loop, the one we normally see when we're using the outside view to look at our own plane.
The instruction IfVSize ( or IfVRes ) is a bit misunderstood, even by Manfred Moldenhauer himself, who created SCASM. The first number after the label does not represent the actual radius of the model. It represent an arbitrary number of visual units. If the scale is in feet, this unit will be in feet. If it is in meter, then meters are used. The P-51D is way higher than 35 reference points, but quite close to the highest scaled unit of 29.44. Since only two kinds of length are being measured - original reference points distance and scaled units -, we must presume that scaled units are being used.
Another confusion is caused by the second number; the pixel. If I was to make a visual model where only a vertical line measuring 35 units would show, it would be seen eventually with the previous code, as we are getting further away, as a dot. In fact, any visual model becomes a dot at one point. The difference between a multi-resolution model and a «one loop» model is that the latter will read all the model, then show a dot, while the former will read a loop that says «show a dot». Visually, they both show a dot but, internally, computation is much reduced in multi-resolution.
One side-note here; the instruction IfHSize (or IfHRes) is supposed to do exactly the same thing as IfVzise (or IfVRes) with the horizontal radius but MDLDisAs can't read it and will show an error. But it will compile it correctly! Unless you have a very distorted image on your screen, they are interchangeable.
It must be stressed here that the instruction IfVSize is not the same as IfVarRange( :label 33B max min ). It is not a measure of distance that triggers the conditional jump, but a measure of pixel visibility. If an object is at five hundred feet, zooming on it with the IfVarRange instruction won't change the distance, and will not activate a more detailed model, but if the IfVSize is used, the model shown will change if the pixel count justifies it.
WHAT DOES IT LOOK LIKE?;
This is the view we normally have of the stock P-51D;
The cockpit is translucent, a pilot «bust» inside. Control surfaces are moving. Gears are visible, so are propellers and rockets. Breaking parts will show if needed. But if you go into chase view (C key) and push the minus key of your keyboard to get as far as possible, you will trigger the next loop. The one pixel per one unit barrier broken, this is what you will get;
The translucent cockpit is gone, so is the pilot. Main gears, in a less elaborate version, are still there, but not the tail wheel. Control surfaces are gone, but propeller and rockets are still visible (my deconstruction-reconstruction does not show them, but you can take my word for it). It will still show breaking parts. As diminished as it is, this model is still more elaborate than many third party a/c.
To go further away, you will need to get another a/c to look at, so freeflight is out of the picture, quite literally! So, looking at your wingman P-51D as one pixel comes to represent 10 units, he will look like this;
Textures are gone. Gears, props and rockets too. The silhouette is suggested with rough shapes, but parts are still showing in their proper order. Gluing was performed. I don't know what the Mach numbers would be for that flying tank, but I like the little bugger! Next step would be a 20 units per pixel;
I don't know about you, but it reminds me of these 10 cents styrofoam gliders I bought when I was young. It looks like there is only three parts but don't be fooled; there is 24 as to not make concave polygons. At 26 units per pixel, our beloved Pony has lost its luster;
Yep, this is it! A few lines. But, at 35 units per pixel, it reaches the «dot state»;
We can barely see it, hence the yellow circle. An interesting fact about dots and lines; their «thickness» never changes. This is why some WWI string bags look like cantilever bridges at a certain distance. Simply put; a dot is a dot is a dot, period!
Third party models would gain by using multi-resolution. Maybe not like the stock P-51D, I really think they over did it, but at least with enough LODs to reduce framerate significantly at medium and long distance. Final remarks; you don't have to relate units to only one pixel, as long as you use integers for both. Trials and errors method should guide you rather than some cryptic mathematical formula.
This is how you can have your cake and eat it too, isn't marvelous?