Texture sizes

[ramsa329 0]

I decided to open this discussion as a result of some observations that I have made.I'm interesting in seeing some replies from designers both freeware and payware or anyone else who has some insight into what I am asking.I have noticed (of late) that I am seeing texture sizes in both freeware and payware aircraft texture folders that seem a little puzzling.I am finding textures in dds format that are 4097KB which seem to be incongruous to the sim in its standard configuration.What this would seem to mean would be 2048x2048+1 pixel which would disallow the ability to mip-map these textures since that would require 2048x2048 or any other number divisable by 2 which 4097KB is definately not.I have also noticed that these super heavy textures cause certain performance and visual anomalies even when settings are changed within the fsx.cfg. What I would like to hear is some feedback as to:1) Why designers are doing this? When did it start, how did it start and why did it start?2) What benefit visually or performance wise do they {the designers}think we are gaining from such graphics intensive texture sizes?3) I would like to hear if others have noticed this and how or if it is affecting their performance and/or visual quality.Finally if their is no perceivable benefit and possibly detrimental side effects why is this continuing?I ask this because it would seem that anything decreasing available resources in such a resource hungry environment as FSX bears investigation. Thanks

[n4gix 4,947]

This question simply begs for an extremely technical reply which isn't truly suited to this more general forum. IOW, it should take place in the Aircraft and Panel forum where such techo-esoteria is more apropos... ;)Keep in mind that the following is directly from the nice folks at ACES. It is not in the least bit speculative, but is experiential. :)The short answer is that beginning with FSX, texture sizes aren't quite the major issue they have been up until now......what IS more critical is the requirement to keep draw calls to a minimum. Every Material/texture combination results in one draw call. Materials using the same bitmap but with even slightly different scalars (such as specular, reflection, etc.) will force a new draw call.FSX will allow up to a 4096^2 texture to be used, but for practical purposes 2048^2 will perform better. Instead of using four, 1024^2 textures for an exterior model, we can combine all four onto a single 2048^2 sheet. Not only does this allow for greater detail, and easier "painting," the additional "blank space" normally wasted can be used to eliminate as many as a half-dozen smaller bitmaps!Judicious use of this technique can reduce what would have required twenty draw calls to a single draw call!Recently, I collaborated with a freeware author to apply the full gamut of FSX optimization in my arsenal. What originally had a whopping 289 draw calls was reduced to a miserly 8 draw calls... :) (see the North American Navion here in the library).This technique should only be used with "user flown" aircraft, since such a/c don't need lower LOD models. In fact, the only time a lower LOD model could possibly be displayed would be from the tower view... *:-* Because of this, MIPS aren't required for user a/c since they'd never be used...Furthermore, modelers should ideally use DDS/DXT5 or DDS/DXT1a only. Because DDS textures are stored "pre-flipped," they can be sent by FSX directly to the vidram, reducing load on the CPU.There is a lot more that could be said, but again that really should take place in the appropriate forum. ;)BTW, the compressed size (4097k) has no 1:1 relationship with the pixel size of the uncompressed bitmap... :-beerchug

[Guest JIMJAM]

What he said:-badteeth

[Palebushman 0]

Don't fret Jim,One of the reasons why I just love the AVSIM forums, is the knowledge that people like our 'Treasured' Bill is in the wings, ready to catch bulls like these, by the horns.Sit back, relax now and watch a 'Master Craftsman' display his awesome skills, if this thread is continued here.

[ramsa329 0]

I apologize Bill if I posted, in your eyes, in the wrong forum. I should have seen that coming.and I certainly appreciate the excellent technical information from you and appreciate the reference to ACES's posts which I was already much much much more than aware of.But none of that answered the questions I asked in my original post either when ACES wrote it or when you copied it, although it seemed satisfactory to the forum user following you where the ubiquitous HUZZAHS were delivered. However,as that may be, I and many (perhaps even very many} others see a lot of texture distortion on add-ons and on the default planes without mips and a great deal less with mip-mapping. And no it has nothing to do with video settings, nhancer or Nvidia drivers.Try this use the - key on your keyboard while flying the default Learjet move out to a distance of 0.50 in spot view and without a doubt you will see distorted textures on the surfaces of the model. Now use a tool like DDS Converter 2.0 and create mip-maps. Then fly again.But then again YMMV especially since I "suggested" it.and let me add this:4096 texture recognition at least of certain textures (clouds i.e.) can only be used when there is an adjustment made in the FSX.cfg file which I am absolutely positively sure everyone is aware of or maybe not otherwise I believe the default is 1024 but then again................that's just me Nor do I see "less" textures being used by designers in the majority of planes that I've tested and I have a lot (to put it mildly) of add-ons. although I admit that the partcular add-on that you worked on is not in my hanger but will be soon.The number I was interested in was 4097,which appears to be 4096 + 1 pixel,its history, value and purpose and not more techno-speak.Which is why I chose this forum. I am well well well aware of the 4096 limit and that 2048 will perform better (which is slightly contradictory given that texture sizes "aren't quite the major issue"}.All of which makes my original questions regarding the issue of 4097 even more relevant since there is a discrepency between 4096 and 4097.I think maybe my point was not quite clear.Let me adjust it:Even if this appears to be a peripheral issue the cost of add-ons is not and if there is some new "myth" in the design of add-ons, and in discovery that "myth" causes any "disturbance" and even 1 person gets an add-on which either fails on a performance or graphic level than it was worth my time to post this question.And I would never post here in these forums if there wasn't some "smoke" already and even a little bit of "fire". LOLi assure you of that.

[ramsa329 0]

Wow Palebushman that was a little personal. ROFLI'm not quite sure what prompted that. Do I know you? Did I dissapoint you at some point in time? Possibly you hold me responsible for some terrible trauma you suffered in a past life?I wasn't aware (but apparently i'm stupid like that) that Bill was "teaching me a lesson" nor did I catch on that he had succeeded in fact I thought he missed the point. I'm a Sagittarian myself not a Taurus. ROFLAnd even if Bill, who I have a lot of respect for whether that is mutual or not, was in some remote otherworldy way, "putting me down" I'm sure I could survive it and him with little or no great effort.I don't know what your problem is but I'll bet its hard to pronounce.

[Palebushman 0]

My sincere apologies 'ramsa' if you feel offended by my response to Jimjam and his wonderful :-badteeth GSOH.That was not my intention at all.

[toprob 105]

"The number I was interested in was 4097,which appears to be 4096 + 1 pixel,its history, value and purpose and not more techno-speak."I think that this is where people got a bit confused -- you are comparing a file size of 4097 kilobytes with a texture dimension of 4096 pixels. These are two entirely unrelated things. From a quick test, an unmipped DXT5 image of 2048x2048 gives a file size of 4097kb, so I suspect that this is what you are looking at. Maybe you could read the replies in this light, and it might make a bit more sense to you.Godzone Virtual Flight, for 'Real New Zealand' sceneryhttp://www.windowlight.co.nz

[ramsa329 0]

Thank you Toprob for that reply.Actually I am well aware of the difference between the the file size and the texture dimensions.What I am questioning is the efficiency of the use of 4097 textures versus the 1025 textures.And I am also questioning designers who use it as to whether in fact they might be causing resource strain on the video card and an increase on the overall impact on FSX.I am also questioning if it is a fact that less calls are made then why are the stock planes different in this aspect or was this just a throwback or some other issue.Along with this I would have liked to hear why there would be so much disparagy between products fron the same source i. e. Alphasim in comparing say the B-24 to the Rutan. Aside from the obvious point of using different designers.I can even site examples of planes released in their original form using 4097 and that later were reversed in subsequent "fixes".And if it is the case that the use of this format has proven to be more beneficial i.e. visuals as well as performance why that is certainly not the issue with the Real Air Spit which was developed in the "stock" format.And lastly whether it might be of benefit to the whole community of simmers if we were to call on designers to establish a more strict set of parameters which would increase both visual and performance levels as well as reliability when spending precious money on an add-on.Say for instance an $80 add-on not using even DXT5 or another exceptable format but 32bit which I never saw as acceptable at all.

[n4gix 4,947]

>And even if Bill, who I have a lot of respect for whether that>is mutual or not, was in some remote otherworldy way, "putting>me down" I'm sure I could survive it and him with little or no>great effort.Michael, I have a great deal of respect for you in your area of expertise, an area to which I am admittedly much less competent.In no fashion was I attempting to "put (you) down."I only suggested that the answer(s) to your questions might be inappropriate to this more generic forum; not that the questions themselves were out of place. There is a very distinct difference between the two concepts.As for the default a/c in FSX not utilizing these new techniques, there is a very simple answer. Those models were locked down and completed long before the concept of "draw call optimization" was recognized.More to follow as time allows...

[n4gix 4,947]

>I am well well well aware of the 4096 limit and that 2048 will>perform better (which is slightly contradictory given that>texture sizes "aren't quite the major issue"}.A 2048^2 bitmap replaces four 1024^2 bitmaps.A 4096^2 bitmap replaces sixteen 1024^2 bitmaps.Using a 4096^2 would be horribly inefficient, as no project should ever require that much pixel real estate...I will agree that misuse of the "2048^2 bitmap technique" can -and will- result in less than optimum performance in the sim. Simply because we can do something doesn't automatically mean that we should...As for the quoted "aren't quite the major issue," it is a simple statement of fact. Texture sizes are still important to be sure, but they are no longer the most critical. Simply put, most systems today have adequate physical memory, and the video cards required to make the sim sing and dance can much more easily handle the texture load.Here is a practical example of rational and optimal use of a single 2048^2 bitmap:#1 2048^2 bitmap = 4097KB total load = 4097KB#2 1024^2 bitmap = 1025KB1024^2 bitmap = 1025KB1024^2 bitmap = 1025KB1024^2 bitmap = 1025KBtotal load = 4100KB#3 1024^2 bitmap = 1025KB1024^2 bitmap = 1025KB1024^2 bitmap = 1025KB1024^2 bitmap = 1025KB256^2 bitmap = 342256^2 bitmap = 342256^2 bitmap = 342256^2 bitmap = 342total load = 5648KBIt is clear that both case #1 and #2 are -for all practical purposes- identical loads.What isn't obvious is that while #1 requires at a minimum only once draw call, #2 requires at a minimum four draw calls. Keep in mind that draw call equals rendering pass. Essentially the entire image in vbuffer must be redrawn four times vs, once. Granted, the difference in absolute time between one render pass and four render passes is meaured in microseconds, but even such minute differences can make a significant impact when accumulated... ;)In addition, as I mentioned previously it is possible to make more efficient use of the available space on a 2048^2 texture sheet, since the "white space" between larger object's UVW Mapped mesh template may be used to UVW Map smaller object's mesh, and in many cases eliminate the need to have multiple 256^2 or 512^2 bitmaps.This is case #3 above. Note that in this case a single draw call has replaced a total of eight draw calls, while simultaneously reducing the vbuffer load by ~1.5KB... :)As for the differences between the same vendor's various product offerings, keep in mind that (a) not all were modeled by the same person, (:( not all were modeled recently, and © not all modelers have developed their skills yet to most efficently exploit the new possibilities allowed by FSX... ...I know that I certainly haven't gotten there yet!Every day I learn something new.>All of which makes my original questions regarding the issue>of 4097 even more relevant since there is a discrepency>between 4096 and 4097.The question is a non-sequitur and based on a misunderstanding, since it's already been established that there's absolutely no relationship between the bitmap's dimensions of 2048^2 and it's DDS/DXT5 compressed file size other than coincidence.

[ramsa329 0]

Thank you Bill now that was extremely informative and gives me the background that I needed.Now when and if you have time let's try this.We'll say for the sake of argument that I have noticed graphic and performnace deterioration in certain aircraft and i decide to do something about itI decide to resize said textures in order to enhance performance or eliminate wavy surface textures through mip-mapping What I have seen is that all will resize with no problem and accept mip-maps and function very well except...............the bump files (not.bmp)When these are resized they cause graphic anomalies and function very poorly.If I could pick your brain once more on this issue I would appreciate it.

[n4gix 4,947]

>When these are resized they cause graphic anomalies and>function very poorly.>>If I could pick your brain once more on this issue I would>appreciate it.Now this is extremely complex to explain! However, I will try to make the principles of the mechanics as simple as possible, but first you will need to go herehttp://www.fsdeveloper.com/forum/showthread.php?t=9819for some requisite background information. ;)Critical to understanding is that what ACES calls a "bump map" is actually what is more widely known as "normal maps" in the rest of the 3d graphics world.The purpose of a "normal map" is to provide shading information to the video hardware so that the DX shaders can properly bitblit the image to vbuffer prior to the final rendering pass. The four channels of a "normal map" are used to hold precalculated vector information.The main point being made is that in "normal maps" the vector that results from R,G, and B will be unit length one.The DX shaders written by ACES differ from those used in other 3d applications in one important respect. The contents of the Red channel have been moved to the Alpha channel, and the Red channel is flooded with pure black (RGB:0,0,0), and the Green channel is made pure white (RGB:255,255,255).The shader's algorithim applies an algebraic expression to the data from the Blue channel and the Alpha channel to produce a "normal vector of unit 1..."As a result, "normal maps" cannot be edited post-creation. They cannot be resized or otherwise "tweaked" simply because the very process destroys the integrity of the data set. The shader then suffers from the infamous GIGO principle. *:-* I hasten to point out that the above has been horribly simplified! There's a lot more going on than described, but nonetheless the end result remains the same.

[basys 4]

Hi FolksBill -Agree fully with all you are sayingexcept for one point regarding no LODs / no mips -This technique should only be used with "user flown" aircraft, since such a/c don't need lower LOD models. In fact, the only time a lower LOD model could possibly be displayed would be from the tower view... Modelers applying this technique,without correspondingly applying mimimum drawcall methodologiespotentially make their a/c unuseable in multi-player environments,(except for those who have high-spec machines).ramsa -3) I would like to hear if others have noticed this and how or if it is affecting their performance and/or visual quality.Issues I've seen on supposedly 'native FSX' a/care more symptomatic of underlying modeling & the texturing issues that Bill has outlined.> 300 drawcalls, mirrored textures, etc.One significant aspect not raisedis the unnescessary potential FPS impact caused by failure to seperate texture sets for interior & exterior models.i.e.Loading a 2048^2 texture sheet to only utilise < 4% of the sheet content.ADMIN -Can this thread be moved please to the MSFS Aircraft and Panel Design Forum.Topic's too important to dissuade potential respondents from following up.HTHATBPaulResized logo pending ;-)http://www.fs-odg.com

[ramsa329 0]

basys,Thank you very much for pointing out the importance of this thread.I, for one , would rather not see it moved.I am trying to show the practical aspect of this issue rather than dealing with the deep technical side (which I have seen and read many times). My work is not that of a designer.Let me give you some true examples without mentioning companies:1)User 1 buys an aircraft from a well-known designer. Being inquisitive he/she opens one of the texture folders and discovers that each dds individual texture of a group of textures is over 16,000KBs (this is for real not a typo)with bumps at 4097KBs.Now User 1 thinking to themselves "What the he**" I've just spent all this money (you'll find out if you keep reading that User 1 has lots of money) so he/she decides to test the plane anyway and not only do the graphics appear unstable(wavy lines on the surfaces) but the performance suffers.Realizing that it just isn't working right User 1 can try to get The money back(but that's not always available).User 1 rushes to AVSIM forum(s) where some know it all tells them not to buy from any company that doesn't allow refunds. 2) User 1 (now you know they are rich) buys another plane from a different company installs it and looks in the texture folder (they work/worked for an IT company) and sees 4097KB textures with bumps of 4097 and thinks to themselves "AH HA now I understand this makes sense".But performance still suffers and the graphics at certain sim settings are so-so.User runs to AVSIM forum(s) where they are told that the problem is all due to their machine, FSX, The terrorists etc...and that absolutely no one else sees any problem at all.3) User 1 (obviously rich) buys another plane from a 3rd company and finds DDS textures of 1025KBs and bump files of the same size and that looks excellent at least from a texture folder point of view.But there are still problems of wavy lines.So after years of simming he/she knows how to mip-map them, opening a special tool for dds, to make sure that they are DXT5 but now what."Uh oh" they are DXT3 and now he/she is really confused because isn't DXT5 the correct format and why would a well-known company release something that wasn't right?He/she runs to the AVSIM forum(s)where they receive 100 conflicting answers and 5 totally abstract replies from techno-kings.4)Top of the Line, King of the Hill, developer releases very desirable great "IFR Only" dream "HEAVY" which is ridculously expensive due to the intensive testing and development time but according to "those who know" indispensible (he/she doesn't care since they are rich remember).Now user 1 (still very rich) must have it because he can't "LIVE" without it.Upon examining the textures (because now he/she has learned to) "Oh my God" they're 32 bit and they're dds and that's even in the textures in the panel folder or some other very weird thing called a texture folder with no name just texture and there are a WHOLE LOT of them.But undaunted he/she loads the plane and guess what .............the performance and the visuals (wavy again) are very sad.So they run to the AVSIM forum and ..............say that it is the greatest add-on ever !!!!!!!!!!!!!!Each of these scenarios repeats itself daily in the sim world with designers who IMHO jump on whatever new found tool (and in the case of 4 an old one that IMHO was questionable since day1) they can find and then charge users for the experiment (although how it's possible for 100's of Beta testers and then users to not see anything wrong, or just plain weird, is for another day).Whew that was long!!!!Hope you get the point