Texture sizes

[n4gix 4,947]

Just a couple of points for the sake of accuracy...1.Any a/c to be used in FSX can use DDS/DXT5 textures......regardless of what version SDK was used to compile it. IOW, FS9 compiled a/c when used in FSX can have all their DXT3 textures converted to 'vertically flipped' DDS/DXT5 format.2.You cannot "add additional textures" to an FS9 compiled model, regardless of bitmap file format. IOW, you cannot create/use specular or bump textures because the model's Material definition does not call for them.3.DDS/DXT3 and DDS/DXT5 textures have the same compressed file size. So, why use DXT5 compression rather than DXT3? Simple......ACES points out that the algorithim for DXT5 is less prone to artifacting, and will yield better textures overall.Otherwise, the only difference is that a DXT3 Alpha is explicit and a DXT5 Alpha is interpolated.4. The most important concept all modelers should keep in mind when optimizing their work is to maintain balance between their desire for crisp, high-resolution textures and the need to keep the overall memory footprint as small as possible.

[n4gix 4,947]

>One significant aspect not raised>is 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.Absolutely! Although keep in mind that even when in VC View, some of the exterior model is duplicated (albeit polygon optimized!), and those parts will still require the exterior textures to be loaded.Also, keep in mind that once loaded in vidram, the textures almost never require loading again.My target goal for all mesh UVW Mapping is to utilize at least 95% of the available pixels on any given bitmap...

[bob.bernstein 0]

Ramsa...Read your whole post, but all I got is that you are rich and unhappy because your expectation is not met. Your expectation is that developers would have a unified single optimized approach to design. Further if those darn designers would simply use that optimized approach, you'd have the performance you desire. And even further, you don't want a technical discussion.Is that it? BobPs...the world ain't that simple. It wasn't until devcon that drawcalls were highlighted as a major source of performance impact.

[Mace 1,928]

>>My target goal for all mesh UVW Mapping is to utilize at least>95% of the available pixels on any given bitmap...That takes careful planning, and...in my opinion, some luck. Either some luck, or, I am just not that good.I have found that despite my best-laid plans, I end up having at least SOME (probably more than the 5% you mention) white space on a texture sheet that I use. Sometimes I find a way to utilize the extra space on the sheet, but sometimes...the project is complete. What more could I add to perfection? :)RhettFS box: E8500 (@ 3.80 ghz), AC Freezer 7 Pro, ASUS P5E3 Premium, BFG 8800GTX 756 (nVidia 169 WHQL), 4gb DDR3 1600 Patriot Cas7 7-7-7-20 (2T), PC Power 750, WD 150gb 10000rpm Raptor, Seagate 500gb, Silverstone TJ09 case, Vista Ultimate 64ASX Client: AMD 3700+ (@ 2.6 ghz), 7800GT

[N400QW 205]

"Ps...the world ain't that simple. It wasn't until devcon that drawcalls were highlighted as a major source of performance impact."Actually we were using reduced draw calls prior to devcon Bob. A few 3PDs were scrambling to impliment and market that feature and we used it effectively in our Columbia 400 and Piper Twin Comanche then followed with Liberty XL2 and Cessna CII and CJI. :-)The technique has become sop at our shop because the results really are worth the extra effort:-)To the OPs question of "standardized" formats it must be understood that this a competitive industry and we doubt that our friends are going to call us up and offer their techniques so we can all "standardize".Wish what you will but the reality is that it's not 'gonna happen.:-)

[ramsa329 0]

Bob,Am I to understand that you did not recognize the irony in my post?The thing wasn't AUTOBIOGRAPHICAL !!!!!!!! although each thing I mentioned has actually happened.I achieved what I wanted to in my OP.I wanted to raise an issue that I see as being MORE IMPORTANT and more COSTLY to users then I felt was being addressed up till now.I work on flightsim computers for a living and I AM NOT RICH by any stretch of the imagination (even yours) Do you believe or does anybody believe here that I think I can get all of the different developers to adhere to 1 principle?I'd have to be insane.I know the egos involved and the personalities and the mine is bigger then yours attitudes that pervade this sim. ALL I wanted is that it be brought to the eye of as many people as possible.Let them "vote" with their wallets.But at least let them be aware of the minefield before they walk on it.And no I didn't want it turned into a technical discussion not because I am afraid of "technical" or find them useless but because I wanted people to think about the issue of wasted cost and potential pitfalls.I am not dissapointed with FSX at all and my performance is actually outstanding and I have more then enough experience and knowledge to know the possible work-arounds for every issue I raised (nobody knows them all).But this isn't about me or my work or my company (in case you were sneakely trying to raise that dead horse and I certainly get enough of that)Sorry I don't have any cute quotes to end this with although G** knows (or at least someone close to him/her) I searched my printout for one.LOL

[bob.bernstein 0]

sorry if I missed the humor/irony. Oddly enough, I attempted some humor in the bombs thread and it failed to amuse at least one reader.Oh well, "timing" they say.B

[Chuck_Jodry-VJPL 663]

The tenor of the questions leave the impression that you disapprove of this practice and are trying to prove a point that to me remains somewhat nebulous at this stage in spite of my confederates efforts at explaining the progression of this practice and its utility to developers .As Ron mentioned a single standard is improbable and with the greater part of Modellers having learned their art through solitary hours with an SDK and tool of choice, it has once been said there are as many ways to build a model as there are modellers ... this is actually rule one of modelling because there are a multitude of means to build a given form and when done hang a bitmap on the mesh.What I would like to hear is some feedback as to:1)

[virtualstuff 758]

>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 it>>I 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.>> I like always to make things not complicated but instead just go for the simple approach lol just make a new bumpmap (normalmap for the confusion lol I love FSX)) from the resized textures which can be done with ease in photoshop about two minutes...Performance issues are solved ;-) That's all and just save always in DDS/DXT5 without mip and file size as small as possible lol and then watch your draw calls ;-)http://i5.photobucket.com/albums/y156/awf1/sign.jpg

[Guest David Ketchum]

The truth is that if you use a batch utility to reduce the size of your ground and sky textures in FSX, your performance will go up about 100 percent (give or take). I am working on just such a utility now. There used to be another one available for use with FSX textures, but it has long since disappeared.Also, others can debate the 'efficiency' of the larger texture format till the cows come home, but FSX developers themselves conceded early on that reducing texture sizes in FSX will result in huge performance gains, period. I could quote a well-known FSX developer by name on this, but don't want to open another can of worms if you know what I mean. :)

[Ramasurinen 0]

Quite an interesting discussion going here!One thing I haven't seen mentioned though is polygon counts, and believe me they still matter in a big big way. Reducing draw calls is all well and good, and definitely helps, but the system still has to pump the polys and map them in the end, and every polygon hurts. Most of the default aircraft that shipped with FSX fall into the 10k-25k polygon range, and with such efficient modeling it really doesn't matter how crazy you go with texture space. Polygon stripes and clever mapping aside a texture can only do as much performance damage as the number of polygons it's applied to, and in most cases these days that's one heck of a lot of polys.Compare the default aircraft counts to the amount in the average 3rd party addon and you'd be shocked. In the addon world 50-75k polys for an external model is more the norm and this spells certain performance death for multiplayer fans, a rapidly growing group that sadly few developers seem to consider. There are very few exceptions to this rule unfortunately and in fact I can think of only *one* payware aircraft out of the dozens that I own that I would call brutally efficient in this regard. At the opposite end of the spectrum I have a couple of planes in my hangar that touch the 100k poly mark which is something I just don't understand. If I get even one of those 100k monsters on screen in multiplayer it can bring my highly tweaked and overclocked Penryn and 8800 ultra system to its knees.I spent nearly ten years modeling and texturing for console games at EA and Namco and the poly limits I had to work with there per object were measured in the low hundreds, having a budget of thousands was some kind of fantasy hehe. That career instilled a real love of efficient modeling in me. If everyone followed the incredibly lean (and yet good looking) examples set by Aces then I think we'd see a lot less complaining about performance, especially in multiplayer. Texture efficiency is only half the battle and pretty graphics aren't doing much good if the average computer is bleeding under the strain of them.-mike

[bob.bernstein 0]

<>Mike, using your logic, users would prefer the default aircraft to third party products! The reason there's a market is because folks WANT a higher poly option. Devs are re-visiting the optimization of these models to satisfy a want of the users that default a/c don't meet. Isn't it baseless to suggest "part" of that optimization effort should remain unchanged? Pretty much eliminates the nature of "change". I think you are really saying that only default aircraft should be used, because no other 3rd party aircraft pass your test unless their poly count matches the default (and if anyone ever did that they'd be wasting their time as the user gets the defaults for free...imagine the market price for a "new" default level product).Bob

[ramsa329 0]

Mike What a great post thank you very much for raising the issue of polygon count and bringing it to the public eye.This is exactly what I had hoped for when I started this.Raising the awareness of people to these "issues" will I hope someday convince designers that with FSX and with economics the way they are that the time has come to pay more attention to the "details".and that we will all be the "better for it"

[bob.bernstein 0]

Its NOT the devs you guys need to convince...they do what the customers reward. Until the customers demand fewer features and less detail, this change you're dreaming of won't happen.The market demands drive the products.Bob

[bob.bernstein 0]

THis is a function of video memory...to say that a video memory bottleneck will always exist is not scientific.Bob