FS Efficiency and Super Textures

Lionheart · Feb 28, 2009

Hey guys,

I have been toying with this subject lately. As we get more sophisticated with FS planes (and scenery) we have also begun making projects with a moderate amount of textures, (at least me and a few others).

Now, taking a plane to 'FSX' level can mean a base package (that is the base textures plus one operable aircraft texture pack with color), and can easily have 70 different textures. Yes, your color texture pack can have only say 3 of those while the base pack supports the rest. But that is a staggering amount of textures.

Some Devs, like Stiz, can redo the textures into super textures, putting 4 textures on a large 2048 square bitmap/DDS file. The requires all and complete re-mapping of all of those parts though for each 'super sheet' of graphics.

Ok, that solves some issues, but means the super sheets will probably not be useable for ultra high resolution unless you make the super sheet a wopping 4096 pixels square, allowing the former graphics zones to stretch out to 2048 pixels, and enabling you to use DXT5/DDS format to keep it efficient in frame rates, not to mention the overall size of the package when its completed and shipped out.

So now, we could possibly be talking using super sheets that are 4096 pixels... Using such large sheets in textures and running a highly complex sim platform can surely bring some systems to its extreme limits. Its bad enough with say 20 to 50 textures, (or more) that are perhaps 512 to 1024 in size.

I am wondering if we are making things too hard on the sim platforms...

Would 7 super sheets be more efficient then 50 textures?

The beauty of X-Plane 9 is that it runs very smoothly. It doesnt stutter and the autogen can be turned up to 'ludicrous' level, (literally). But... (this is a key factor).. the planes presently do not have over 7 textures.

I am wondering... Should we as developers start heading down a path of using extremely minimal textures?

Duh! you say.. Ok, for me, I love high resolution. The most sacrifice I could be told to do is to give up that which I have fought for all along, high resolution. But, perhaps, super sheets are the way. Figuring quadrants at 1024 resolution for the sim, 4 per sheet, and a build (platform) size (when being created) to be 4096, (which would be staggering on RAM in Gmax and Max, requiring reduced JPG copies to cope with running these during the build process), may indeed be the route to go...

But I think we are hitting a limit, 'we' who use 'lots' of textures..

Perhaps the super sheet is the way of gaming? or a possible future.

Imagine all the textures you 'could' place on a single 4096 super sheet, imagining that some could be 512 pixels quadrants on a SS. That could be 16 X 512's on a SS. Its shadowed 'Light map' could then have a reduced 2048 size SS.

We still have to deal with all the other bits though, like bump maps and things. Perhaps materials with Bump Maps, Spec Maps, etc, could all be limited to one SS for materials, and one SS for each of its sub components (such as bump maps). This way, those are all quardened off from the rest, allowing maximum efficiency (little clutter as possible) for the package.

A little observation of mine that I have also been thinking on is that using a seperate HD for housing FS on and running on a computer might indeed be allowing faster frame rates, as has been talked on. You have two HD's running in tandem.

I wonder... If a Computer has to run FS on a seperate HD, what would be better? Would the aircraft textures be better placed in the world texture zone? Or would the plane textures be best put on the 'other' HD, totally seperated from the 'terrain' textures?

I can see (and compare) having multiple HD's as like having dual (and quadruple) core PC chips. You are running multiples for one single program, thus the work is being shared..

Perhaps this too will be a gaming 'avenue' in the future.... ?

Just some thoughts and theories..

Bill

I am wondering if we are perh

harleyman · Feb 28, 2009

I think that one day Bill that mine of yours will indeed hit some sort of a *Nova* idea...

You always seem to be pondering things as all the great minds have done...

You my friend, are never satasified with whats now, but always seeking the *What If's*..... :jump:

MCDesigns · Feb 28, 2009

Lionheart said:
I am wondering if we are making things too hard on the sim platforms...

Would 7 super sheets be more efficient then 50 textures?

Yes, and yes!

Just because the sim supports it doesn't mean it has to be that way. I spend way to much time reducing texture sizes since I notice a big hit with them on my old rig. While I am sure some developers may have more info on the impact (or non impact) textures and formats have on their aircraft and the sim, common sense and experiences says to me that to many large texture sheets degrades performance on my rig. I would love to be proven wrong and have documented proof that I am, but until then, that is what I believe. It's no surprise that the AS blackhawk has a hard time on my rig with 80+ textures to load. Nothing worse than to switch the view to the VC and have it be gray for 30 seconds while the 200+ textures load.

From a modeling POV, oh yeah, I love large textures. In my CGI work, I use 6000 x 6000 sheets and boy does that eat up memory, but the rendering apps I use are made for this and can handle/optimize the load, unlike FSX.

Personally, I'd love to see a list of how many textures and their sizes a payware aircraft has before buying, as that makes a big difference in my purchasing or not.

jeansy · Feb 28, 2009

unctuationKerning/> <w:ValidateAgainstSchemas/> <w:SaveIfXMLInvalid>false</w:SaveIfXMLInvalid> <w:IgnoreMixedContent>false</w:IgnoreMixedContent> <w:AlwaysShowPlaceholderText>false</w:AlwaysShowPlaceholderText> <w

oNotPromoteQF/> <w:LidThemeOther>EN-US</w:LidThemeOther> <w:LidThemeAsian>X-NONE</w:LidThemeAsian> <w:LidThemeComplexScript>X-NONE</w:LidThemeComplexScript> <w:Compatibility> <w:BreakWrappedTables/> <w:SnapToGridInCell/> <w:WrapTextWithPunct/> <w:UseAsianBreakRules/> <w

ontGrowAutofit/> <w:SplitPgBreakAndParaMark/> <w

ontVertAlignCellWithSp/> <w

ontBreakConstrainedForcedTables/> <w

ontVertAlignInTxbx/> <w:Word11KerningPairs/> <w:CachedColBalance/> </w:Compatibility> <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel> <m:mathPr> <m:mathFont m:val="Cambria Math"/> <m:brkBin m:val="before"/> <m:brkBinSub m:val="--"/> <m:smallFrac m:val="off"/> <m:dispDef/> <m:lMargin m:val="0"/> <m:rMargin m:val="0"/> <m:defJc m:val="centerGroup"/> <m:wrapIndent m:val="1440"/> <m:intLim m:val="subSup"/> <m:naryLim m:val="undOvr"/> </m:mathPr></w:WordDocument> </xml><![endif]--><style> <!-- /* Font Definitions */ @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4; mso-font-charset:1; mso-generic-font-family:roman; mso-font-format

ther; mso-font-pitch:variable; mso-font-signature:0 0 0 0 0 0;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4; mso-font-charset:0; mso-generic-font-family:swiss; mso-font-pitch:variable; mso-font-signature:-1610611985 1073750139 0 0 159 0;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {mso-style-unhide:no; mso-style-qformat:yes; mso-style-parent:""; margin:0cm; margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:11.0pt; font-family:"Calibri","sans-serif"; mso-ascii-font-family:Calibri; mso-ascii-theme-font:minor-latin; mso-fareast-font-family:Calibri; mso-fareast-theme-font:minor-latin; mso-hansi-font-family:Calibri; mso-hansi-theme-font:minor-latin; mso-bidi-font-family:"Times New Roman"; mso-bidi-theme-font:minor-bidi;} span.EmailStyle15 {mso-style-type

ersonal; mso-style-noshow:yes; mso-style-unhide:no; mso-ansi-font-size:11.0pt; mso-bidi-font-size:11.0pt; font-family:"Calibri","sans-serif"; mso-ascii-font-family:Calibri; mso-ascii-theme-font:minor-latin; mso-fareast-font-family:Calibri; mso-fareast-theme-font:minor-latin; mso-hansi-font-family:Calibri; mso-hansi-theme-font:minor-latin; mso-bidi-font-family:"Times New Roman"; mso-bidi-theme-font:minor-bidi; color:windowtext;} .MsoChpDefault {mso-style-type:export-only; mso-default-props:yes; mso-ascii-font-family:Calibri; mso-ascii-theme-font:minor-latin; mso-fareast-font-family:Calibri; mso-fareast-theme-font:minor-latin; mso-hansi-font-family:Calibri; mso-hansi-theme-font:minor-latin; mso-bidi-font-family:"Times New Roman"; mso-bidi-theme-font:minor-bidi;} @page Section1 {size:612.0pt 792.0pt; margin:72.0pt 72.0pt 72.0pt 72.0pt; mso-header-margin:36.0pt; mso-footer-margin:36.0pt; mso-paper-source:0;} div.Section1 {page:Section1;} --> </style> yep yep and yep, myself and a few other painters discussed this some time back, im kinda laughing now know we weren’t the only ones who are thinking that, after some people told us we were full of Sh#T as it doesn’t matter and it doesn’t make sense

before the firing line targets me next, down here in aus , the new fad is HD textures, this requires you to max out your texture load setting to over 4000 where default is around 512-1024, personally i dont bother changing it, please dont get me wrong the guys are doing fantastic work, good on them <!--[if gte vml 1]><v:shapetype id="_x0000_t75" coordsize="21600,21600" o:spt="75" o

referrelative="t" path="m@4@5l@4@11@9@11@9@5xe" filled="f" stroked="f"> <v:stroke joinstyle="miter"/> <v:formulas> <v:f eqn="if lineDrawn pixelLineWidth 0"/> <v:f eqn="sum @0 1 0"/> <v:f eqn="sum 0 0 @1"/> <v:f eqn="prod @2 1 2"/> <v:f eqn="prod @3 21600 pixelWidth"/> <v:f eqn="prod @3 21600 pixelHeight"/> <v:f eqn="sum @0 0 1"/> <v:f eqn="prod @6 1 2"/> <v:f eqn="prod @7 21600 pixelWidth"/> <v:f eqn="sum @8 21600 0"/> <v:f eqn="prod @7 21600 pixelHeight"/> <v:f eqn="sum @10 21600 0"/> </v:formulas> <v

ath o:extrusionok="f" gradientshapeok="t" o:connecttype="rect"/> <o:lock v:ext="edit" aspectratio="t"/> </v:shapetype><v:shape id="Picture_x0020_6" o:spid="_x0000_i1025" type="#_x0000_t75" alt="http://www.sim-outhouse.com/sohforums/images/smilies/ernaehrung004.gif" style='width:45pt;height:30pt;visibility:visible;mso-wrap-style:square'> <v:imagedata src="file:///C:\DOCUME~1\Matt\LOCALS~1\Temp\msohtmlclip1\01\clip_image001.gif" o:title="ernaehrung004"/> </v:shape><![endif]-->:ernae:but saying that dragging out your texture max puts strain on the system, with all the new fsx scenery being photoreal like orbx and other developers making scenery that detailed to the level where every single possible object can be seen. you often have to wonder where is the line drawn for eye candy and compatibility

the saying goes, KISS- Keep It Simple Stupid<o

></o

>

SolarEagle · Feb 28, 2009

As to large texture sheets in the world of gaming....

The original version of the id Tech 4 engine was criticized for its perceived inability to handle large outdoor areas. The MegaTexture technology addresses this issue by introducing a means to create expansive outdoor scenes. By painting a single massive texture (32,768×32,768 pixels, though it has been extended to larger dimensions in recent versions of the MegaTexture technology) covering the entire polygon map and highly detailed terrain, the desired effects can be achieved. The MegaTexture can also store physical information about the terrain such as the amount of traction in certain areas or indicate what sound effect should be played when walking over specific parts of the map. i.e. walking on rock will sound different from walking on grass.<SUP id=cite_ref-6 class=reference>[7]</SUP> It is expected that this will result in a considerably more detailed scene than the majority of existing technologies, using tiled textures, allow. Currently, the only game that utilizes MegaTexture based on the Tech 4 engine is Enemy Territory: Quake Wars

http://en.wikipedia.org/wiki/Id_Tech_4

http://en.wikipedia.org/wiki/MegaTexture

Running FSX on a separate HDD is best, but I see no need for more than one drive for FSX, unless your using RAID. From my experience with landclass terrain texture loading is not in any way HDD limited on a fast single drive, only CPU limited.

For example I run FSX on a single RaptorX, and on my i7 system I can firewall the Razorback using 4x time compression with my usual eye candy settings and see little to no blurries, even when flying down low. That's 350mph x4, and it stays in the highest LOD, or 1 to 2 steps behind. If I disable one core on the CPU, I would then see heavy blurries, meaning 2+ steps behind on LOD. Since blurries scale perfectly with the number of threads I run, it tells us the HDD is not a factor.

Lionheart · Feb 28, 2009

SolarEagle said:
Running FSX on a separate HDD is best, but I see no need for more than one drive for FSX, unless your using RAID. From my experience with landclass terrain texture loading is not in any way HDD limited on a fast single drive, only CPU limited.

Hey Solar Eagle,

Could you imagine the day when the game comes with a plug in mini tower, like a HD book that has all the info on the HD in it? lol.... Drivers and all, textures, etc, could all be held within that single box.. and allow the main OS, HD, and PC run seperately..

Just a thought that came to mind in reading your reply.

Bill

Lionheart · Feb 28, 2009

Michael and Jeansey,

Sounds like we are on the same page.

I thought 70 was high. But you know, it only makes sense with FSX if all existing textures are having so many other textures added like Spec's, etc. It all adds up really quick.

So, does 80 textures from 1024 in size and under run faster then 12 4096 textures?

It would be interesting to find out..

Bill

stiz · Feb 28, 2009

Lionheart said:
So, does 80 textures from 1024 in size and under run faster then 12 4096 textures?

well in theroy the 12 4096 should run faster, however it all depends on the computer, plus if your useing 12 4096 textures your doing something wrong in your texture layout or your going exterme!!!! in reality you make a plane look great with only 1 or 2 4096 textures, one for outside and one for in. However people use 80+ little textures nowadays which just kill performance, and all of which could have been put on a single big texture, yes you wouldnt be able to fine tune the materials so that bit of metal has a slighty different shine to the one next to it, but this is a game not an architural demostration :engel016:

Also i cant really see the point of makeing an effort to use big textures, but why use 16 1024 textures when they all fit on 1 4096

d0mokun · Feb 28, 2009

I think the problem with using 4096 textures is that you are relying on a user to set the maxtextureload feature. Once you start relying on a user to dabble in configs, you're asking for trouble.

Yes you might have a few bods on a forum like this that are perfectly apt at changing things, but those few bods are in the minority. So instead of having one nice map and the theory in play, you'd have a hundred emails complaining of low res textures and so on so forth.

Unless of course 4096 doesn't have to be set anymore and I'm on the wrong tracks.

Of course though, all developers will have a different view on things.

some1 · Feb 28, 2009

The TEXTURE_MAX_LOAD entry in fsx.cfg (which is controlled by "Global textures resolution slider" in FSX settings) doesn't affect textures on a planes, provided that they don't have mipmaps. Then you can have it set to lowest value and still see 4096 or bigger textures on your plane.

What's important, it's possible to set TEXTURE_MAX_LOAD to maximum of 1024 from FSX UI, and it gets resetted to this value after any change in FSX settings, even if you set it higher by editing fsx.cfg. So it's better to not rely on this entry too much.

Mipmaps are usually a good thing in graphics engines (remove stuttering and improve performance at the cost of bigger textures size) but in FSX they are EVIL.

d0mokun · Feb 28, 2009

Aha, excellent, thanks for that info.

SkippyBing · Feb 28, 2009

How much of a performance improvement is there between 16 x 1024 and 1 x 4096? It's ultimately the same amount of data bar a slightly increased overhead for the extra file headers.

some1 · Feb 28, 2009

Each texture require new material, each material is new draw call and extra processing on CPU side.

SkippyBing · Feb 28, 2009

Yeah, I get that, but has anyone got any figures to give an idea of what the performance hit is? A 4096x4096 texture is a lot of data to be moving around and to be honest doesn't sound that easy to work with in the modelling stage. If it's only a few percent better than using 16 1024 textures then I personally wouldn't bother, if it was 50% faster then I'd be interested.

Cazzie · Feb 28, 2009

From a skinner's POV Bill, I like the super textures in lieu of many textures. The A2A WoP II P-47 is a whopping 4096 texture on one sheet for the entire exterior, makes painting easy, but I can wash dishes while they load! LOL

With FSX often requiring the work of redoing three sets of each texture, main, bump, and spec; I can say that I can put out an A2A P-47 paint in a couple of days, but an Aerosoft F-16C will take a week or more because there are so many textures involved and alignment of colors and markings that carry over from one texture to another are a complete PITA!

A yes, I can see the day when a sim is in the form of an external HD and operated by a plug-in.

Caz

jetstreamsky · Feb 28, 2009

It would be interesting to validate the impact of the different approaches

If two versions (one high texture count, one few but large textures) of an identical but fairly detailed model (to ensure the system is under load) were to be released to the forum members who have a wide range of systems, then the performance differences could be identified easily. Of course this would be a lot of work for someone to map out the model versions.

JoeW · Feb 28, 2009

jetstreamsky said:
It would be interesting to validate the impact of the different approaches

If two versions (one high texture count, one few but large textures) of an identical but fairly detailed model (to ensure the system is under load) were to be released to the forum members who have a wide range of systems, then the performance differences could be identified easily. Of course this would be a lot of work for someone to map out the model versions.

I have done somewhat the same thing with Mikes J-3. I have a P4 3.2 ghz with 2 gigs PC3200 with an AGP 7600gs vid card. I had a problem with some streaking and smuding and loss of menus with the original 32 bit textures. I reworked the textures keeping them at 2048 in size and changing the format from 32 bit to DXT5, DDS and I can fly it that way with out all the smearing. Frames are great, I have FSX locked at 15 and I'm getting 14.5 to 15.0 while flying.
I don't think I lost any detail and FSX is sure smoother.

N2056 · Feb 28, 2009

Personally I like 2048, and I minimize the number of sheets used. When I started working on the Thorp in FSX I redid all of the textures, and part of the process was eliminating all of the 'oddball' little ones. I also paid attention to things like putting anything that needed to have any reflection on a single sheet. That allows me to use a single texture for many different materials, and cuts draw calls nicely. I ended up having to re-map the whole thing, but in the end it made a noticeable difference in frame rates.

mcjerkyls · Feb 28, 2009

So nobody is using FSX on one of those solid state disk thingies...im intrigued about them to say the least

FS Efficiency and Super Textures

Lionheart

SOH-CM-2014

harleyman

Guest

MCDesigns

Guest

jeansy

No longer active

SolarEagle

Charter Member

Lionheart

SOH-CM-2014

Lionheart

SOH-CM-2014

stiz

Charter Member 2011

d0mokun

Merovingian Ninja

some1

Charter Member

d0mokun

Merovingian Ninja

SkippyBing

Charter Member

some1

Charter Member

SkippyBing

Charter Member

Cazzie

SOH-CM-2024

jetstreamsky

Charter Member

JoeW

Charter Member

N2056

Charter Member

mcjerkyls

Charter Member