Search Unity

  1. We are migrating the Unity Forums to Unity Discussions by the end of July. Read our announcement for more information and let us know if you have any questions.
    Dismiss Notice
  2. Dismiss Notice

Modo 202

Discussion in 'Formats & External Tools' started by Richard_B, Aug 4, 2006.

  1. Richard_B

    Richard_B

    Joined:
    Jul 22, 2005
    Posts:
    436
    It's out and FBX export is fixed!!

    Richard
     
  2. taumel

    taumel

    Joined:
    Jun 9, 2005
    Posts:
    5,292
    Thanks for notifying!

    Now if only the manual would ship too... :O/

    *update*
    >>>
    Faster rendering (peak performance improvement up to 42%)
    <<<

    Hah, what did i argued once?! ;O)
     
  3. taumel

    taumel

    Joined:
    Jun 9, 2005
    Posts:
    5,292
  4. pete

    pete

    Joined:
    Jul 21, 2005
    Posts:
    1,647
    that's a fine looking block of wood! really it is! just curious... what's it got to do with modo? did you export the bump out or something?
     
  5. Richard_B

    Richard_B

    Joined:
    Jul 22, 2005
    Posts:
    436
    Yes - a very fine block of wood indeed! But why does it take so long to download?

    Richard
     
  6. taumel

    taumel

    Joined:
    Jun 9, 2005
    Posts:
    5,292
    @pete
    It has to do with modo because it was made in modo... :O)

    @richard_b
    Because these are two 1kb^2 textures (diffuse and normal) in png format. Unity isn't able to compress such data to jpg (if wanted) for instance in order to provide smaller filesize at the moment like sw3d does.
     
  7. Jonathan Czeck

    Jonathan Czeck

    Joined:
    Mar 17, 2005
    Posts:
    1,713
    "1kb^2" doesn't make any sense, I guess you mean 1024x1024. Also, Unity does not work that way, at all. Read this: http://unity3d.com/Documentation/Manual/Reducing File size.html The fact that you have your image in PNG format is irrelevant. In your case, two of those images (DXT1) takes 1.3 megabytes, (assuming mipmaps) and that's very reasonable compression I think. How small can you get those two images with jpg compression and how bad would the normal map look in jpg format? Half that size? The other thing is that because Unity is storing these textures in this format, it can just grab the data from disk and send it right to the graphics card. This really helps loading times if done right.

    Did you compress textures? (The checkbox in the build window)

    -Jon
     
  8. taumel

    taumel

    Joined:
    Jun 9, 2005
    Posts:
    5,292
    Hi,

    it does make sense when you use the terminology just to differ the 1000 from 1024 no matter that there are bytes afterwards. Well, as for the exponent i think i don't need to explain it to you... ;O)

    Secondly as for the texture compression: The fileformat isn't irrelevant as long as you don't use texture compression and so JPGs produce smaller filesizes than PNGs. Whilst experimenting with textures it's just taking too long to produce the compressed textures during a build - at least on my mini.

    And also if you compare JPGs to PNGs in a compressed format you can still produce smaller files with almost half of the size in this testscenario.
    By the way i don't have all the DXTC versions in mind and what is interpolated in each version exactly but don't they all just provide only 16Bit?!

    JPGs provide you the smallest filesizes in most cases and i guess you just not only use normal maps, don't you?! If there would be support for JP2 then you also could have transparent ones. Further more if you're after quality for the normal maps i also won't use DXTC here. By the way how well was ATIs 3DC again?

    Best would be if i could define (a) global settings for all and b) lokal settings for each texture) if i would like to publish a texture in a jpg (also 2) format and the compression value i would like to use. This would take up more time during setup before the app starts but it also would produce the smallest filesizes unless there would be a procedural texture generator in the engine itself and unity would only save the parameters for setting up the texture...welcome werkkzeug!

    And nope i didn't compress the files, but if i would i do get:

    816kb with dxtc and pngs
    424kb with dxtc and jpgs


    Regards,

    taumel
     
  9. Aras

    Aras

    Unity Technologies

    Joined:
    Nov 7, 2005
    Posts:
    4,770
    DXTn textures are not 16 bit. That is, in each 4x4 block the two extreme colors stored are 16 bit, but the two interpolated ones are 32 bit. Some info here.

    Most often they are very good for regular textures with a filesize of 1/6 to 1/3 of the uncompressed image.

    Yes, for normalmaps plain DXTn is worse. ATI's 3Dc is not supported everywhere (and it's not that different from using a swizzled DXT5), but the problem with it is that all bumpmap shaders have to be written twice: once for regular textures, and once for 3Dc/swizzledDXT5.

    However, it is very true that for webplayers you sometimes want to compress the textures better, with JPG or JP2 or whatever else. We might look into adding that.
     
  10. taumel

    taumel

    Joined:
    Jun 9, 2005
    Posts:
    5,292
    >>>
    DXTn textures are not 16 bit. That is, in each 4x4 block the two extreme colors stored are 16 bit, but the two interpolated ones are 32 bit...
    <<<

    Then i would say it depends on the usage and the texture how fast you get into banding.
     
  11. Aras

    Aras

    Unity Technologies

    Joined:
    Nov 7, 2005
    Posts:
    4,770
    I'd say it depends more on the quality of the DXTn compressor you're using. Though yes, most compressors have some trouble with very smooth gradients. And yes, the rainbow images like in the article from my post above are also not what DXT is good at. But then, the majority of the textures in a typical game are neither gradients nor rainbows...
     
  12. taumel

    taumel

    Joined:
    Jun 9, 2005
    Posts:
    5,292
    By the way a version with one jpg and one png compressed via: http://spielwiese.marune.de/_uni/holz/holz2.html

    One thing i've noticed: When not using compression this results almost everytime into gfx glichtes so that the picture is destroyed on my 9200er. This can be fixed by switching to fullscreen and then back to windowed mode. After that the texture is okay. Downside of this is that it leads to lockups of the whole system in a lot of cases here. The 9200er of the mini isn't a card which is good supported yet (no idea if it's Apple or Unity).
     
  13. Aras

    Aras

    Unity Technologies

    Joined:
    Nov 7, 2005
    Posts:
    4,770
    We're looking into this texture corruption on a 9200 problem right now.

    By the way: as aarku said, it does not matter whether what format the input images are in. Be it psd, jpg, tga or bmp; what makes a difference in the datafile size is the texture format you choose in Unity. DXT5 is always one byte/pixel, no matter if it comes from a jpg or png.

    So most often it's better to not supply textures in jpg format, because they already have some details lost due to jpg compression. Png and other lossless formats are ok of course.
     
  14. taumel

    taumel

    Joined:
    Jun 9, 2005
    Posts:
    5,292
    >>>
    By the way: as aarku said, it does not matter whether what format the input images are in. Be it psd, jpg, tga or bmp; what makes a difference in the datafile size is the texture format you choose in Unity. DXT5 is always one byte/pixel, no matter if it comes from a jpg or png.
    <<<

    And as i said the filesizes differ...

    Uncompressed comparison with the same textures just in different formats:

    1.9MB with a JPG and a PNG
    2.4MB or 2.8MB with two PNGs (can't remember right now)

    Compressed whilst using the same DXTC method

    816kb compressed with PNGs
    424kb compressed with JPGs

    Maybe the cleanup code has a bug then?
     
  15. Aras

    Aras

    Unity Technologies

    Joined:
    Nov 7, 2005
    Posts:
    4,770
    The thing is that JPG and PNG images are different (the first contains JPG artifacts, the second does not). So as they are different images, they also produce different DXT compressed images.

    One of them further compresses for the webplayer datafile better, and one worse. The other textures may be different. If you try building a standalone player, you'll see that there's no size difference (because the datafile is not compressed there).
     
  16. taumel

    taumel

    Joined:
    Jun 9, 2005
    Posts:
    5,292
    Which says in practice that JPGs produce smaller filesizes while looking almost the same (used on diffuse for instance)...
     
  17. Joachim_Ante

    Joachim_Ante

    Unity Technologies

    Joined:
    Mar 16, 2005
    Posts:
    5,203
    Actually it seems very likely that the png contains an alpha channel (and the alpha channel is not a solid color) while the jpg doesn't. You can disable the alpha channel in the import settings (which will half the size in the case of compressed textures).
     
  18. Joachim_Ante

    Joachim_Ante

    Unity Technologies

    Joined:
    Mar 16, 2005
    Posts:
    5,203
    Thats probably a very, very bad idea.

    While of course it could be possible that it produced smaller filesizes, i think it's very unlikely. Check if alpha is enabled for the png texture first. (Unity automatically chooses an alpha format if there is an alpha channel with a non-solid color)

    Jpg causes pretty bad artifacts on most game like textures. Thats why no one really uses jpg for offline distribution.
     
  19. taumel

    taumel

    Joined:
    Jun 9, 2005
    Posts:
    5,292
    I Just did another little test with reducing the alpha in photoshop already. This leads to (all dxtc1):

    o png 420kb (without transparency)
    o jpg 424kb
    o png 716kb (with transparency)

    Now by deactivating alpha in unity you mean the usage of dxtc1, right? If not i would be interested where the other switch is as i haven't seen another one.

    As the original file was presented as a online file i obviously also was mainly after online distribution. The possibility to distribute JPGs would beat all the dxtc scenarios filesize wise and regarding the scenario you could also provide better quality than using dxtc. Just saying that it would cause very bad artifacts is a bit too easy. Beside of my own stuff i also do remember quite a lot of jpgs in other games where i've browsed the data folders.


    Regards,

    taumel
     
  20. taumel

    taumel

    Joined:
    Jun 9, 2005
    Posts:
    5,292
  21. NicholasFrancis

    NicholasFrancis

    Joined:
    Apr 8, 2005
    Posts:
    1,587
    Your point being?
     
  22. taumel

    taumel

    Joined:
    Jun 9, 2005
    Posts:
    5,292
    a) I still don't know why i do get different filesizes with the PNGs - see above.

    b) As for the abstract: Better quality for a compressed normal map and so a smaller filesize.

    *update*
    And i guess the best quality i could come up with dxtc at 360kb whilst not hanging my mini... http://spielwiese.marune.de/_uni/holz/holz3.html
     
  23. NicholasFrancis

    NicholasFrancis

    Joined:
    Apr 8, 2005
    Posts:
    1,587
    1) Because your png has alpha in it and the JPG does not.
    2) If you read the paper, you'll see that they're using dxt compression just like we are. They are doing some extra steps (renormalizing the normal map) that we're not. this gives better quality, at the cost of slower rendering.

    The filesize is constant, though.

    Edit: I'm not saying that there is no way to compress normal maps better or textures better (JPG2000, wavelets, etc). At some future point we might look into that. For the time being, though, I feel the quality/size tradeoff is adequate.
     
  24. taumel

    taumel

    Joined:
    Jun 9, 2005
    Posts:
    5,292
    1) Sorry i don't get it:

    Case A has a PNG where the Alpha is killed in Photoshop -> 24bit.
    Case B has a PNG where the Alpha is available (although not used) ->32bit.

    Both cases compress with DXTC1 (manually set) which says RGB without the Alpha. So i would expect the same filesizes as the Alpha in Case B should be killed...

    This leaves me dazed and confused: Bug in unity or i'm not understanding something here...


    2) This would be a nice option to have!
     
  25. NicholasFrancis

    NicholasFrancis

    Joined:
    Apr 8, 2005
    Posts:
    1,587
    Ahh, I thought you were talking about your numbers above (where you were comparing jpg vs. png). What exactly are you meaning here?
     
  26. taumel

    taumel

    Joined:
    Jun 9, 2005
    Posts:
    5,292
    Have you read my last posting? That's my problem.

    I do get nearly half of the filesizes when killing the alpha in photoshop already. And the way i've understood dxtc1 it should kill the alpha automatically for me so that it doesn't matter if alpha is involved or not. The way it seems now is that dxtc1 isn't killing the alpha.
     
  27. NicholasFrancis

    NicholasFrancis

    Joined:
    Apr 8, 2005
    Posts:
    1,587
    File a bug with some sample files, then we'll look at what is going on. This sounds weird.

    Edit: You are building with compressed textures, right? Just to be sure.
     
  28. taumel

    taumel

    Joined:
    Jun 9, 2005
    Posts:
    5,292
    Yes! :O)

    Believe me i've checked often enough that i've really choosen dxtc1 and build is compressed.

    I'll send the media files with the bug report.

    By the way i'm right if i assume that if a texture is dxtc it also utalizes only the compressed memory in the vram?

    As for 2) This would really be cool to have! The futurecrew also does it *dumtidum* ;O)
     
  29. Aras

    Aras

    Unity Technologies

    Joined:
    Nov 7, 2005
    Posts:
    4,770
    The size difference was the tricky corner of DXT1 spec, when it produces bytes that compress worse for image portions that have alpha=0 in input. The result is correct, and the uncompressed image is the same size, it's just one zips for the web-player better and the other worse. I'd think that about ends this dicsussion.

    Taumel: I'm not sure Futurecrew actually did the normalization of normal maps... 1994 was a bit too early to do that :)
     
  30. taumel

    taumel

    Joined:
    Jun 9, 2005
    Posts:
    5,292
    I've understood the mail easier than this one... ;O)

    As for the futurecrew: Feel free to call them Mad Onions, Futuremark Corporation or whatever...i guess you've understood whom i meant. ;O)

    *update*
    Okay Futurecrew are more than just Futuremark but i just had a little talk with someone from them regarding the normal mapping compression so i was thinking mainly of them and not remedy etc.