Announcement

Collapse
No announcement yet.

Crunch Texture Compression Showing Off Promising Results For Unity

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    Originally posted by willmore View Post
    As someone who isn't a game developer but has spent some time with compression, I'm driven to ask if they're doing the right thing here. They quote improvements in compression speed, but tiny gains in compression ratio. As a 'compress once, store millions of times' task, isn't the compression ratio truely the most important metric? Time should be something you're willing to sacrifice a lot of to get better compression. Hearing them say it's 5x faster makes me wonder if they could have gotten better compression if they had spent 5x *longer* trying to do a better job.

    I understand that the write/compile/test loop needs to be kept short to keep developers productive, but you only need to recompress the textures when you change them--which I wouldn't expect to be that often--and you don't need to do the uber-super compression on them at that point--only before final testing. I guess the 5x faster can help a little in the case where the developer is tweaking textures. I don't know the workflow, is that so big of a concern?
    If you read the blog post, it appears those numbers are comparing the Crunch performance in Unity 2017.3 to 2017.2 - so their Crunch support has gotten a lot faster to encode over the last few months, but it's still likely slower than a non-Crunch encode. They're just trying to make it more reasonable to use, while continuing to also make further compression gains of 10% more than they already had gained previously.

    So think of it like hearing that a new version of a VP9 codec got 10% better compression and a 2.5x speedup over the previous version, not like comparing VP9 to another x265 codec.
    Last edited by smitty3268; 15 November 2017, 04:18 PM.

    Comment


    • #12
      Originally posted by Hi-Angel View Post
      So what? ≈65% of lastnames I see, both latin and cyrillic, directly mean something, and another ≈10-15% resemble real words.
      his point was that his surname is funny enough for other kids to harass him, not that it has a meaning.

      Comment


      • #13
        Originally posted by M@GOid View Post
        Some AAA games got artificially inflated for some obscured reason, like 40 to 60 GB on their console disk. Some says it is to discourage piracy. But some indie games are unbelievably large for the graphic and contents you see on the screen. I have some 2D, pixelated indie side scrolling games that are larger than 1 GB. You see them and ask yourself how they managed to get a 16 bit SNES/Mega Drive style game and inflate it enough to be so big on file size.
        That's the result of noob developers, or devs that aren't even trying to do a good job because the game is called CoD/AssCred/GTA/Battlefield 23453354 and it will sell well regardless.

        Comment


        • #14
          Originally posted by willmore View Post
          As someone who isn't a game developer but has spent some time with compression, I'm driven to ask if they're doing the right thing here. They quote improvements in compression speed, but tiny gains in compression ratio. As a 'compress once, store millions of times' task, isn't the compression ratio truely the most important metric?
          Same. I thought the important metrics for this use were compression ratio and decompression speed, as the textures are going to be decompressed in any game before being used (and cached hopefully).

          Comment


          • #15
            Originally posted by willmore View Post
            As someone who isn't a game developer but has spent some time with compression, I'm driven to ask if they're doing the right thing here. They quote improvements in compression speed, but tiny gains in compression ratio. As a 'compress once, store millions of times' task, isn't the compression ratio truely the most important metric? Time should be something you're willing to sacrifice a lot of to get better compression. Hearing them say it's 5x faster makes me wonder if they could have gotten better compression if they had spent 5x *longer* trying to do a better job.
            Building texture sets and other assets for Unvanquished last around 2 hours on my rig. Since I exclude map compilation time from that 2 hours, it's mainly doing crunch compressions on a ton of pixmaps, probably 95% of these 2 hours is spent running crunch.

            Even if the build tool can do partial build (like make), saving time is always a good idea, especially when swaping git branches reset some file timestamps and you have to rebuild so many stuff…

            As a game developer, I want to get small files to distribute, but I want to save time while I'm developing. That's the same issue developers have while compiling code: the shorter the compilation last, the less time you spend testing stuff etc.

            Originally posted by aras_p View Post
            Not in this case, IMHO. The number 1 reason from our users (I work at Unity) in "why you don't use Crunch" has been "compression is too slow"
            Oh, since you work at Unity, can you get a look at the three fresh PR I just sent?

            BTW, the article here on Phoronix makes it sound like this has something to do with Valve (it doesn't), or that the improvements have not been open sourced (they are right there on github; in the link that original blog post says).
            Yay, it's Phoronix…

            Originally posted by starshipeleven View Post
            Same. I thought the important metrics for this use were compression ratio and decompression speed, as the textures are going to be decompressed in any game before being used (and cached hopefully).
            Like DDS, the crunch format is meant to be eaten-up by GPU almost directly (iirc, the engine just unwrap them to feed the GPU but not decompress the textures itself), The .crn files are the cached files. That's why decompression speed is very fast, CPU don't care, it's GPU task. Also, you send less data to GPU since it's sent compressed. So decompression speed is already good, but a better compression speed is a need by game developers. Basically these changes look to be for game developers first to make them happy to use it so they use it so end-user is happy to have a game with quick loading time.

            At Unvanquished we are very happy to use crunch for years now: it saves a lot of bandwidth when players download maps from servers and it saves a lot of time to load the assets, so players quickly join online games because they download extra content faster and they load assets faster.

            Just for fun, it's well known a 7z archive full of plain uncompressed TGA files is usually smaller than a 7z archive full of PNG files compressed with hungry optimizers like zopfli. So, if you want to save packaging time, just not compress your texture individually (but people will wait a lot for loading time at game time). If you use crunch, you win on both side: small packages, quick loading time. So, even if a naïve 7z archive full of uncompressed TGA files can be small, I don't have any answer why so many games assets are so big…

            Comment


            • #16
              Originally posted by jhenke View Post
              Rich Geldreich probably had to face quite some jokes about his name. His family name literally means "money rich" in German....
              Well, Peyton in portuguese would be a terrible name, because it sounds like "Peitão" which means "big breasts", so imagine a kid being bullied because he is named for big breasts

              Comment


              • #17
                I'm excited that Unity's actively modifying and maintaining crunch. I put my heart and soul into this library before I went to Valve, and I open sourced it while taking a break after working on the graphics and shader effects for Portal 2 and DotA 2. The Source 2 developers at Valve said crunch would go nowhere, and that it was without value. The developers at Epic and Id ignored it. Only Unity's developers understood how valuable it was, and how to use it. I hope every Unity game under the sun will now use crunch compressed textures. This will apply pressure to the other engine vendors to do something competitive.

                This is also good for us at Binomial, because we have something to compare to and point at that is active when we're talking to customers and potential customers. We're purposely not directly competing against crunch (either the original or Unity's version), or anybody really. Instead we are listening to our customers and building GPU texture codecs with rate distortion optimizations, done in a way that is compatible with modern software LZ codecs like Oodle/Brotli/Zstd, or hardware GPU LZ codecs. We've shipped our first LZ optimized RDO texture codecs for the DXT/ETC formats to licensees a few months ago. The interest we've gotten in this technology is off the charts, because it can be used to cut game downloads and updates by half or more.

                We're currently working on a universal GPU texture format which can be decompressed/transcoded either by the CPU or GPU. It's basically a JPEG-like solution for GPU textures. One file gives you GPU texture data on both mobile and desktop, with no overhead vs. crunch. We're going to use this tech as the foundation of a new video codec designed specifically for GPU textures. There's also a lot of interest in applying these compression solutions to newer formats like BC7/ASTC, which is inevitable.
                Last edited by richgel999; 16 November 2017, 03:33 AM.

                Comment


                • #18
                  Originally posted by richgel999 View Post
                  ...


                  Congrats, I imagine it must be exciting to see this take off.

                  Comment

                  Working...
                  X