Announcement

Collapse
No announcement yet.

DDS vs Ace

Collapse
This is a sticky topic.
X
X
Collapse
First Prev Next Last
 
  • Filter
  • Time
  • Show
Clear All
new posts

    DDS vs Ace

    Using forest regions and using the "load dds in preference of ace" option I get this picture below.



    The alpha seems to be cutting out too much of the tree?

    Below is the same exact tree using ace instead.



    Same exact file, but one is saved as an dds and one as an ace. I have created the dds from an ace and I have created the dds from the original picture and saving direct to a dds using dxtbmp.

    #2
    I like the top one better...

    Robert
    sigpic

    Comment


      #3
      After saving an ACE file to TGA with TGATool2 it can the be saved easily to DDS using Paint.NET !
      Web site: www.otto-wipfel.co.uk

      Comment


        #4
        I prefer the top one as well, it just appears more 'realistic' to me.

        Comment


          #5
          Originally posted by rdamurphy View Post
          I like the top one better...

          Robert
          Ok, here are some of the same trees in a different location, Ill compare dds to ace. DDS seems to look fine up close, but even then the tree is not nearly as full as it is with an ace file.





          As we back the camera away you can see with the dds texture is starts to lose a lot of its fullness about midway in the tree. Trees up close are ace files and distant trees are the dds.





          More of the same at a further distance. Trees up close are ace files and distant trees are the dds.





          Lets try track level, or close to it. Trees up close are ace and trees further down track are dds.



          Comment


            #6
            Originally posted by OTTODAD View Post
            After saving an ACE file to TGA with TGATool2 it can the be saved easily to DDS using Paint.NET !
            Doesnt saving to ace degrade the quality of the texture?

            Comment


              #7
              James,

              I see what you are saying, but I also think that it comes down to personal preferance. I sort of like the 'thinner' look to the DDS textures. As you can see in the final ACE picture, there is an obvious line showing up in the trees due to their placement, that is 'softened' in the DDS version.

              Geoff

              PS> I can also see how the DDS 'thinness' (if that's a word?!?) would be more of a negative in a deep forest type of setting.
              Last edited by gkhager; 03-12-2014, 11:27 AM.

              Comment


                #8
                From http://www.fsdeveloper.com/wiki/inde...sion_explained

                DXT3
                The colour information in DXT3 is saved similar to the DXT1 format without an alpha channel. So a palette of 4 colours is used to represent 16 pixels of the texture. But the alpha information is stored with 4 bit in the DXT3 format. That means that in total 128 bit are used for the 16 pixels (32 for the palette, 32 for the colour indices and 64 for the alpha information). So this results in a compression ratio of 1:4.

                Because the alpha information is stored in 4 bit, the smallest step in the alpha value that can be stored is 16. This means that very smooth transitions in the alpha channel can not be stored in the DXT3 format.

                DXT5

                The DXT5 formats differs from the DXT3 format in the way the alpha information is saved. The colour information is stored in the same way.

                For the alpha information it uses a palette, similar to the way the colour information is also stored. This palette contains a minimum and maximum alpha value. Then 6 other alpha values are interpolated between this minimum and maximum. This thus allows more gradual changes of the alpha value.

                A second variant does interpolate only 4 other alpha values between the minimum and maximum, but also adds an alpha value of 0 and 1 (for fully transparent and not transparent). For some textures this might give better results.
                In dxtbmp what compression method did you use? If the original .ace is not using a 1 bit alpha channel (which is what it looks like in your screen caps) using DXT3 instead of DXT5 will make a difference in the result. The thinning out will most likely be certain levels of alpha being tossed out during the compression with dxtbmp.

                Try both DXT3 and DXT5 and see what the results are....better still post the screen caps of just the .ace and .dds files from your paint program (the texture AND the alpha channel).

                Just my guess

                Comment


                  #9
                  Hi Folks,

                  I haven't had the opportunity to check myself - but - perhaps the way DXT5 handles Alpha's differently - could possibly fix the alpha sorting issue with signals - such as not displaying smoke when looking through the alpha ???
                  <a href=https://www.trainsim.com/forums/filedata/fetch?filedataid=80663&type=full title=thumb_80663.png >thumb_80663.png</a>​ My Blender Models

                  Comment


                    #10
                    Originally posted by James Collins View Post
                    Doesnt saving to ace degrade the quality of the texture?
                    I am saving the loaded into TGATool2 ACE into TGA because Paint.NET can not load ACE files and using TGA also includes the ACE's Alpha channel if it has one !
                    Web site: www.otto-wipfel.co.uk

                    Comment


                      #11
                      Originally posted by James Collins View Post
                      I have created the dds from an ace and I have created the dds from the original picture and saving direct to a dds using dxtbmp.
                      Have you tried not generating mipmaps or using other tools to create the DDS? Paint.NET is known to generate bad mipmap data in our own testing of this option, and your first picture looks kinda similar to the corruption/effect caused by Paint.NET's issue.
                      James Ross
                      Open Rails Management Team
                      sigpic

                      Comment


                        #12
                        Originally posted by twpol View Post
                        Have you tried not generating mipmaps or using other tools to create the DDS? Paint.NET is known to generate bad mipmap data in our own testing of this option, and your first picture looks kinda similar to the corruption/effect caused by Paint.NET's issue.
                        I use paint shop pro and have only used dxtbmp to create dds files so far. Something is off for sure, but it could be a fault with dxtbmp, I will try other tools as well and see if that changes anything.


                        In dxtbmp what compression method did you use? If the original .ace is not using a 1 bit alpha channel (which is what it looks like in your screen caps) using DXT3 instead of DXT5 will make a difference in the result. The thinning out will most likely be certain levels of alpha being tossed out during the compression with dxtbmp.
                        I have been saving them as DXT5. I will try DXT3 and get back with the results.

                        Comment


                          #13
                          .dds? .ace?
                          The only matter of consequence is which one uses the least computing power?
                          IBM XT i386; 512Kb RAM; 5.25" FDD; 1.4Mb FDD; 5Mb HDD; VGA 256-colour graphics card; AdLib soundcard; DR DOS 6.0; Windows 3.0

                          Comment


                            #14
                            Ok, so after trying a few tools and compression methods, it seems DXT1 works just fine in DXTBmp and convimx. DXT3 and DXT5, both looking the same as my previous post, no matter which program I used.

                            Here are both programs using DXT1. All tree textures are dds in all shots.









                            There are differences between the two programs and the shots above and I guess it comes down to preference at this point, but the main issue of corruption as James put it is gone.

                            Comment


                              #15
                              Great research and documentation. Definitely going to be helpful going forward with questions about moving away from the .ace format!

                              Thanks for your hard work: I'm going to bookmark this thread...

                              Perhaps we should make it a sticky? Mods?

                              Robert
                              sigpic

                              Comment

                              Working...
                              X