Modo 202

It's out and FBX export is fixed!!

Richard

 

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)

 

Just because it's so easy to do... :O)

http://spielwiese.marune.de/_uni/holz/holz.html

 

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?

 

Yes - a very fine block of wood indeed! But why does it take so long to download?

Richard

 

@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.

 

"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

 

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

 

>>>
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.

 

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).

 

>>>
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?

 

Which says in practice that JPGs produce smaller filesizes while looking almost the same (used on diffuse for instance)...

 

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

 

And how about... http://download.nvidia.com/developer/Papers/2004/Bump_Map_Compression/Bump_Map_Compression.pdf

 

Your point being?

 

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

 

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.

 

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!

 

Ahh, I thought you were talking about your numbers above (where you were comparing jpg vs. png). What exactly are you meaning here?

 

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.

 

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.

 

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)

 

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.