Is This Carrying the "Minimalist Approach" Too Far? :)

[n4gix 4,947]

Just to see if it could be done, I mapped all the gauge polys onto one, single 1024x1024x23bit template. Here are the results...The first picture is the complete VC, left main, right main, glareshield annunciator, pressurization panel, lower throttle quad, and compass are all mapped to one $vc_complete texture, and the vc_complete.BMP follows:http://forums.avsim.net/user_files/61719.jpghttp://forums.avsim.net/user_files/61720.jpg

[n4gix 4,947]

I did the forgoing simply as an experiment, but since resolution is of paramount importance, I finally dedicated the full width of two 1024x1024 bitmaps to the main panel, but used the "empty space" on the second one to map the compass, pressure panel, glareshield annunciator and lower throttle quad on the same $texture.bmpThis allowed me to reduce seven 'VcockpitXX' entries in panel.cfg to a mere two textures! This will maximize resolution without engendering the overhead processing required for FS to render so many 'VcockpitXX' textures.Here is a shot of the combined Vcockpit02 in FS Panel Studio:http://forums.avsim.net/user_files/61730.jpg

[Guest JeanLuc_]

Hi Bill, please excuse my newbie question, I really want to understand this. Why wasn't the VC done like this before, or on the contrary, why before most designers designed VC with many (too many?) VC windows? Was there a constraint of any sort forcing to use many VC Windows?

[n4gix 4,947]

>Hi Bill, please excuse my newbie question, I really want to>understand this. Why wasn't the VC done like this before, or>on the contrary, why before most designers designed VC with>many (too many?) VC windows? Was there a constraint of any>sort forcing to use many VC Windows?I was beginning to wonder if anyone was going to comment on these two posts, after seeing it had been read many times... :)There was (and still is) a fundamental "mind set" that because the various VC subpanels are on different "depths" and several "angles" with respect to the vertical plane that we "need" separate bitmaps for each subpanel.This, coupled with the typical vagueness of MS SDK's led those who wrote the earliest "tutorials" (including your's truly!) to emphasize this "mind set," and thus perpetuate the confusion to "newbies."There have even been those who've carried this to the extreme by using individual Vcockpit gauge polys for each instrument!OTOH, there has been at least one payware developer that I'm aware of, who used the technique I've described, but in typical "payware fashion," didn't share this information with the "great unwashed..." :)A colleague of mine, who isn't a "panel guy" at all, brought this to my attention and... not having been "contaminated" by the aforementioned "mind set," proceeded to demonstrate to me how this could be accomplished. By this time, this "mind set" has become "conventional wisdom," and the erroneous assumption has thus been made that VC's must be done this way!In retrospect, it's easy now to see that there's absolutely no reason why the same techniques that allow a single texture bitmap to be used for many separate "parts" cannot be used in the VC as well. After all, on a practical level there's no difference between an "invisible texture" than a conventional texture!What is truly "embarrasing" to me personally, is that I had become so set in this idee fixe that I couldn't see the forest for the trees, and it took someone "who didn't know any better" to bring it to my attention! :)I did often note that it was a shame that there was often a lot of "wasted space" on a $panel bitmap, but simply assumed that was just "the way things were" and didn't "think outside the box."It is a well known fact that the more Vcockpit entries there are, there is a significant drain on FS's computational resources. Using this technique will not only reduce that processing overhead, but will also allow us to use that previously "wasted space" and thus reduce the number of huge 1024x1024 .bmp's required to provide high resolution of VC gauges.Up until now, most designers have made hard choices about the use of 1024x1024 in all areas of the VC, resulting in compromised and uneven resolution when viewed by the sim-pilot. Some parts of the panel were crisp and easy to read, others were blurry and smeared. Now, every part of the VC can take advantage of the highest resolution possible!Thanks for asking, and I hope this helps! :)