Page 3 of 3 FirstFirst 123
Results 21 to 26 of 26

Thread: DDS vs Ace

  1. #21
    Join Date
    Nov 2006
    Location
    Charleston, WV
    Posts
    162

    Default

    Quote Originally Posted by twpol View Post
    There shouldn't be any real differences once loaded...
    First Id like to say Im not expert at all on this subject, but have always heard dds is a great thing to have, which brings me to acouple of thoughts.

    What about mipmaps? Doesnt this take stress off of the gpu by using smaller images at a distance in order to save from loading a large texture that wouldnt be any benefit from afar with the thinking that the eye couldnt tell the difference in a scaled down, lower quality texture vs just loading large 1024x1024 image?

    My final question is, what benefit does dds bring to OpenRails, or will bring to OpenRails, since both dds and ace are compressed, my thinking was dds while compressed holds up much better in quality than ace? So, I guess what Im saying is, I thought dds would bring better load times and higher image quality? Isnt it also a format that graphics cards can reader quicker? Feel free to correct any of that, Im all ears really.

  2. #22

    Default

    Quote Originally Posted by James Collins View Post
    First Id like to say Im not expert at all on this subject, but have always heard dds is a great thing to have, which brings me to acouple of thoughts.

    What about mipmaps? Doesnt this take stress off of the gpu by using smaller images at a distance in order to save from loading a large texture that wouldnt be any benefit from afar with the thinking that the eye couldnt tell the difference in a scaled down, lower quality texture vs just loading large 1024x1024 image?

    My final question is, what benefit does dds bring to OpenRails, or will bring to OpenRails, since both dds and ace are compressed, my thinking was dds while compressed holds up much better in quality than ace? So, I guess what Im saying is, I thought dds would bring better load times and higher image quality? Isnt it also a format that graphics cards can reader quicker? Feel free to correct any of that, Im all ears really.

    Now this is from memory and my programming is done in linux but........

    The main benefit of using DDS is that the XNA toolkit has in built support for this texture format. DDS appears from its specfication to by designed as textures for games, most other formats are just image formats. DDS has a number of inbuilt facilties that would make a programmers life using the XNA tool kit easier.

    A couple of down sides is its compression format used is lossy and its not as yet an open format and does not appear to be diretly supported by open source tools such as gimp. It appears no conversion tools TO DDS exist also for linux. Its seems unlikley then from the above information that there will be real good Open source support for this format which I would THINK was a fairly serious problem in an open source program such as openrails. Mind you that is just my opinion.

    The problem for limited support for an open source format is of course is reduced amount of software to generate the textures in the first place and from my point of view DDS is no improvement in this respect over the ACE format.

    Note: I personally do all my textures I use under linux it being my main OS, windows only being used for train siming. I find working with MSTS in this way a real pain as there is no way to directly support the MSTS texture format. This has definitely limited the model work I do for MSTS.

    Lindsay

  3. #23
    Join Date
    Oct 2009
    Location
    United Kingdom
    Posts
    434

    Default

    Quote Originally Posted by James Collins View Post
    First Id like to say Im not expert at all on this subject, but have always heard dds is a great thing to have, which brings me to acouple of thoughts.

    What about mipmaps? Doesnt this take stress off of the gpu by using smaller images at a distance in order to save from loading a large texture that wouldnt be any benefit from afar with the thinking that the eye couldnt tell the difference in a scaled down, lower quality texture vs just loading large 1024x1024 image?

    My final question is, what benefit does dds bring to OpenRails, or will bring to OpenRails, since both dds and ace are compressed, my thinking was dds while compressed holds up much better in quality than ace? So, I guess what Im saying is, I thought dds would bring better load times and higher image quality? Isnt it also a format that graphics cards can reader quicker? Feel free to correct any of that, Im all ears really.
    DDS is a better format to use than ACE for a couple of key reasons:
    * DDS is much more widely supported by tools.
    * DDS supports formats that ACE doesn't, such as cubemaps, natively.

    When you get down to it, if you're using a format supported by both ACE and DDS (so RGBA, DXT1/3/5), they are basically just two different wrappers around the exact same data. All they're doing is saying things like "Hi, I'm a DXT3 texture that is 1024x1024 with 7 mipmaps" - both ACE and DDS do this. Once loaded onto the GPU, they'd be identical (if the same data went in and the same format options applied). They both support mipmaps, so there's no difference there either.

    At the moment, I'd say the only real advantage of DDS is tooling support. Open Rails supports the exact same formats (RGBA, DXT1/3/5) in both ACE and DDS, both with and without mipmaps, so you don't gain any great new way to store your images or better quality compression. In fact, ACE files using RGBA format can be compressed in a way that DDS files cannot, so you might argue that ACE is better than DDS in that respect. But the tooling really wins in my book. You can't go in to your favourite image editor, be it Paint.NET, Gimp or many others and save an image as ACE. But you can save as DDS.

    However, DDS also supports the future; new graphical formats we want to add, such as cubemaps, but also bump maps and other things are natively supported by DDS already. When we get around to them, we can simply go ahead and use these newer/more interesting formats.
    James Ross
    Open Rails Management Team

  4. #24
    Join Date
    Nov 2006
    Location
    Charleston, WV
    Posts
    162

    Default

    Quote Originally Posted by twpol View Post
    However, DDS also supports the future; new graphical formats we want to add, such as cubemaps, but also bump maps and other things are natively supported by DDS already. When we get around to them, we can simply go ahead and use these newer/more interesting formats.
    Cant wait to be able to finally use bump maps in OR. Thanks for the explanation.

  5. #25
    Join Date
    Nov 2006
    Location
    Charleston, WV
    Posts
    162

    Default

    Deciding to use dxtbmp since it has been my go to exporter and way of quick viewing files for many years, I saved a few trees using the DXT1 (with alpha of course) only to notice the trees flickering in OR, kind of like a moire effect when moving towards the trees.

    I first tried many settings in the nvidia control panel, adjusting AA and AF, texture filtering quality, screen resolution etc. and it made no difference. As a last resort I tried convimx, saving as a DXT1 (with alpha) and the flickering is gone. I dont know why that is, but it is. Just a little tidbit for anyone looking for a dds exporter. I have the photoshop plugin for dds but dont really use it, since for me at least it has limited function. Maybe its where I use PSP12 still

    By the way, this flickering happened with three different tree textures I tried, until I used convimx. Guess I will use convimx instead for now on.

  6. #26
    Join Date
    Nov 1999
    Location
    Wyoming
    Posts
    597

    Default

    I got rid of the flashing vegetation by unchecking the model instantsing button in the options/video tab in OR.
    Only you can stop Fred Flintstone wheels

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •