The special case of the level shot file format

Ask questions about mapping in general, and show off your in-progress work.
User avatar
illwieckz
Project Head
Posts: 434
Joined: Sat Aug 11, 2012 7:22 pm UTC
Location: France
Contact:

The special case of the level shot file format

Postby illwieckz » Sat Jul 04, 2015 8:17 pm UTC

Hi, in another topic we talked about picture file formats supported and recommended for unvanquished.

Unvanquished support the png, tga, jpg, webp and crn file format, and crn file format is recommended when lossless is not needed (like color gradient) or some special case (like skyboxes).

But the level shot is another special case. Unvanquished knows how to load whatever the format, but this file could be loaded by third-party tools.

For example it could be loaded by an online server statistic tool, or a server browser. :smile:

I'm maintaining the XQF server browser and I just fixed it to be able to load level shots from unvanquished pk3 files since there are now stored in the meta/mapname/mapname.ext path instead of levelshots/mapname.ext path. XQF now found the level shots, but in many cases it cannot displays the level shot because the level shot is stored in some not-well-known file format like like webp or crn. :confused:

If Unvanquished maps use file format like crn for level shots, it means that every third-party software must add support to crn file format, only to display the level shot of the current map played, which is a bit too much.

It's not a problem at all if all others textures are stored with some uncommon but effective file format, because this is an internal usage, but the level shot can be read by third-party software to display the server status.

Why not saying that even if other file formats are technically supported, a level shot in a very common file format like jpg is a good practice to ensure the best user experience? :smile:
Last edited by illwieckz on Sun Jul 12, 2015 5:21 am UTC, edited 1 time in total.
User avatar
Supertanker
Mapper
Posts: 21
Joined: Wed Mar 07, 2012 10:58 pm UTC

Re: The special case of the level shot file format

Postby Supertanker » Sat Jul 04, 2015 9:11 pm UTC

I mentioned this in IRC but I'll reiterate:

As a mapper, I have a problem with .crn in general. As far as I know, most operating systems and image editors don't natively support the format, so viewing textures in a file manager and editing the textures are both problematic. In addition, .crn is lossy.

This poses a problem if I have a .pk3 and I want to start editing the map textures, or to adopt them into my own map, license permitting. One recent example is the cloud sky texture from Thunder; I couldn't find the uncompressed original to color tint it, so I had to decompress the .crn, and my sky has subtle but noticeable compression artifacts because the texture is stretched out over a large area.

A related problem: what happens if someday we have a map .pk3 that needs texture tweaks, and the mapper has lost the source textures? This is a less annoying situation than a .pk3 without the .map file, but it's still irritating.

Have we actually tested to see the size between different file formats between .crn, .webp (which has its own set of issues, like lightmap artifacts), and plain .tga when compressed in a pk3? .tga files are gigantic, but the .pk3 zipping does squish them down pretty good.

tl;dr I agree, and I dislike .crn in general.
User avatar
Supertanker
Mapper
Posts: 21
Joined: Wed Mar 07, 2012 10:58 pm UTC

Re: The special case of the level shot file format

Postby Supertanker » Sat Jul 04, 2015 9:27 pm UTC

Update: did some quick testing. Took the textures from spacetracks and the lightmaps from freeway (217.5MB of .tga files total). I then crunch'd the files using the default settings, and made separate zip files from the .tga and the .crn files.

The .tga pk3 came in at 13.2MB and the .crn came in at 5.7MB. So .crn does compress better...but I'm willing to trade 7.5MB for not having lossy compression. (Also, having just the level shot in a format other than .crn is not going to make the pk3 blow up.)

I didn't test .webm because I think I'm doing it wrong. I ended up with 908.1KB of lightmaps...

edit because I can't math
User avatar
Fuma
Programmer
Posts: 58
Joined: Wed Mar 07, 2012 6:49 pm UTC

Re: The special case of the level shot file format

Postby Fuma » Sat Jul 04, 2015 9:34 pm UTC

I agree.

I have always disliked webp for its compatibility problems while bringing negligible benefits.

.crn is a necessary evil because it provides IMMENSE advantages with regard to memory consumption (images are stored compressed in graphics memory), performance (lower amount of memory bandwidth used for display and manipulation), load times (no need to decompress to load), and graphical fidelity (lower memory use + higher performance = can use higher resolution textures).

Levelshots don't need any of the advantages of .crn so .jpg or .png should be recommended there.

Supertanker, you seem to lack knowlege of the various image formats.

A .tga file is essentially an uncompressed image. Putting it in a .pk3 will, at best, reduce it to the size of a .png because .png already uses similar compression internally while maintaining the lossless nature of the .tga format. Additionally, while .tga may have decent support in various production tools, it still has less market penetration than .png (its direct competitor).

We have measured the difference with .crn and other formats and have found it to be an immense improvement in all of the cases I mentioned above. If you do a little research, you will find that ALL games on the market today and the last 7+ years use similar gpu compressed image formats because of how much better it is. See https://en.wikipedia.org/wiki/Texture_compression for the bare minimum of information on this.

We could keep our images uncompressed or in .png format and then compress them at runtime into a gpu supported compression format, but that will greatly reduce startup speed for at least the first load of a given map (I'm talking many minutes to even hours here). It will also give less quality since we can't spend as much time optimizing because it would take too long. That said, after the first time they are compressed, we could cache the images to speed up subsequent runs, or even compress them as part of the install.
This would greatly increase our download size though because we would force everyone to download the MASSIVE uncompressed versions of the textures.

What I still recommend and have advocated for in the past is for the uncompressed versions of the assets be stored in some publicly available area. Unfortunately, no one has done anything about that and I don't even know if we still have the uncompressed versions of some things anymore.

Supertanker, your test was rather meaningless because you didn't account for the rest of our assets. Your 6MB saved, as a percentage, is HALF of your map size. Given that 95% of our size is due to textures, this would bloat our download size by 2x, and would increase the amount of memory consumed by over 6x. Remember, unless it is a gpu supported compression format, these textures will be stored without any compression at all. A 2048x2048 RGB texture will take up 12MB of vram uncompressed. It will also greatly increase load times back to minutes instead of the seconds it takes currently. Not to mention the performance concerns I mentioned earlier.
User avatar
Supertanker
Mapper
Posts: 21
Joined: Wed Mar 07, 2012 10:58 pm UTC

Re: The special case of the level shot file format

Postby Supertanker » Sat Jul 04, 2015 9:39 pm UTC

I didn't realize .crn had so many benefits on the GPU side; I concede the point.

If we had some sort of public repository to put uncompressed map assets, my main concerns would no longer be concerns. What would it take to set this up (and to get people to actually use it)? I've made a GitHub repo for one of my maps in development, but as far as I know, nobody else does this.
User avatar
kharnov
Granger
Posts: 1851
Joined: Tue Mar 06, 2012 10:54 pm UTC
Clan: GT
Location: New York City

Re: The special case of the level shot file format

Postby kharnov » Sat Jul 04, 2015 9:55 pm UTC

We could have Ishq set something up on the server.
User avatar
illwieckz
Project Head
Posts: 434
Joined: Sat Aug 11, 2012 7:22 pm UTC
Location: France
Contact:

Re: The special case of the level shot file format

Postby illwieckz » Sat Jul 04, 2015 10:25 pm UTC

Well, in an awesome and utopic world, map sources are versionned into a git repository with lossless assets, and some kind of `make` command generates a ready-to-use and shrinked-and-optimized version to distribute. :grin:

This what I'm doing (without the versionning, not yet) with an handmade script I must rewrite properly before releasing it, when I type `build_map`, it compiles the map, compile navMeshes, creates the minimap and converts all the textures to crn.

But it's not the point, I'm not against crn at all for in-game textures, but for the level shot which is a metadata, the crn file format is just annoying for third party tools, and there is no real reason to use this file format in this case. :confused:

About webp, I'm not against this file format, if it's true webp is better than png for lossless compression, why not using it, but the level shot does not need to be in webp (nor lossless ?).

The better is to let metadata readable effortlessly, I think. :smile:
Last edited by illwieckz on Sun Jul 12, 2015 5:23 am UTC, edited 2 times in total.
User avatar
Fuma
Programmer
Posts: 58
Joined: Wed Mar 07, 2012 6:49 pm UTC

Re: The special case of the level shot file format

Postby Fuma » Sun Jul 05, 2015 2:26 am UTC

Indeed, .crn is fundamentally a texture compression format and should therefore only be used for textures i.e. 2d images that are projected onto a 3d surface. Map metadata, the HUD, and other similar images should always be stored in another format. Webp is pretty bad for most cases even if it is a bit smaller because of a lack of wide range support. This lack of support will severely limit a lot of legitimate use cases in the future. The only real use case for it that is not fulfilled by other formats is lossy images with transparency.

Return to “Level Design”

Who is online

Users browsing this forum: No registered users and 2 guests