Textures for 3DO models

[Caydr]

What are acceptable texture formats for 3DO models besides BMP and TGA?

I would just like to use a more efficient format if possible, BMP and TGA are both extremely large. A BMP which is 192kb turns into a 27kb PNG, or a for instance.

If other formats can be used, please describe the process. Thank you.

[Master-Athmos]

Well you do know that in your graphics card's memory it'll take as much space as raw bitmaps no matter which of those formats you choose? I'm not sure though if you can use all of the formats Spring can read for 3dos too (it also never was an issue though as it's all pretty damn small). I'd still say you can use whatever format you want as Spring writes everything into an atlas texture and I guess it uses the standard library for reading files for that (i.e. PNG or DDS would be fine too)...

So either do learning by doing and give it a try or wait for someone who can give you definite info on this...

[Caydr]

I would've checked the wiki, but it's outdated beyond usefulness. The forum search also fails to recognize anything shorter than 4 letters, so "3DO" can't be searched for, and "texture" yields 470 pages IIRC...

Maybe it will help if I explain what I'm up to. I've made enhanced versions of all the OTA textures. There's about 600 of them, and each one is about 190kb. Even with high 7zip compression, the resulting archive is quite large - around 40mb. If I was able to use something besides BMP, it would be much more manageable.

My most recent understanding was that DDS is exclusively supported for S3O models. If that's changed recently it would be awesome, since DDS unlike other formats requires a lot less VRAM.

[Master-Athmos]

You do know though that the resolution for the 3dos is limited? They all get pflastered on one I think 2048x2048 bitmap and if you exceed that it's "game over"...

DDS textures aren't just for s3o models - you should be able to use them anywhere (many e.g. use them for buildpics)...

[Argh]

Well you do know that in your graphics card'd memory it'll take as much space as raw bitmaps no matter which of those formats you choose?

DDS does not take up the same texture memory. Depending on which DXT compression algorithm you use, it takes 1/4 down to 1/8. You can store 8X the textures in DXT1 than you can as PNG or TGA.

What are acceptable texture formats for 3DO models besides BMP and TGA?

As for your question, Caydr... Spring automagically converts the BMP / TGA into DDS when it builds the 3DO texture atlas. Even a totally full texture atlas barely scratches the surface on modern video cards, in terms of texture memory. I don't know whether you can load PNG or JPG in place of BMP- that part of the engine may still be hardcoded, and is probably never going to get looked at again (nobody cares about 3DO, plain and simple).

You don't need to worry about that at all, basically. If you're increasing the sizes of your textures, BMP compresses almost as well (on disk) as PNG does.

I seem to recall (now that I'm bothering to ransack the hollow shell that is my brain) that if you exceed the size of the texture atlas, Spring will create more, so you can go to any size you want, in theory. I may be wrong about that, PM Tobi for confirmation.

I guess my final question is... why waste time trying to beautify stuff that's inherently ugly, when you could just make new S3Os? I know that you know how... this seems like a huge waste of time, tbh. If you make nice S3Os, you can get help with the BOS side of things, it's not that big of a deal.

We've had this conversation before, though- you need to deal with the fact that content creation has changed a lot. There are no good reasons to use 3DO- none at all. There are no real performance advantages on modern hardware.

[Master-Athmos]

DDS does not take up the same texture memory. Depending on which DXT compression algorithm you use, it takes 1/4 down to 1/8. You can store 8X the textures in DXT1 than you can as PNG or TGA.

In the case of 3dos the textures get just read out and are pasted on an atlasmap which afaik doesn't get compressed (at least not unless you enable compress textures in the settings). So despite what format you use the textures won't stay in memory and so you don't have the usual DDS advantage...

[Argh]

at least not unless you enable compress textures in the settings

I forgot that that isn't enabled by default

Anyhow... even if you have 5-6 texture atlases uncompressed, you're nowhere near overwhelming even very old GPUs' texture memory.

However, performance-wise... if each 3DO has to do texture lookups on 5 atlases, that probably doesn't work out very well. It might be best to blow up all of the current textures to twice their current size or larger by running them through an automated process, and see what performance looks like, before and after, before wasting time.

[Master-Athmos]

I'm not 100% sure but afaik there is just one 2048x2048 atlas for 3dos so Caydr will have huge problems with his like 256x256 textures anyway. When looking at it from the technical side additional atlases are quite unprobable as Spring would have to go through every model so it wouldn't need to apply two or more atlases to one model as the textures used would be split over those three atlases...

Plus we only have limited atlases for our sprites too...

[Argh]

Meh. I thought somebody said it could grow dynamically a few months ago. Probably just mis-remembering, I haven't read any of that source in years. If you're right, though, then this plan is sunk before it even starts.

[jK]

Anyhow... even if you have 5-6 texture atlases uncompressed, you're nowhere near overwhelming even very old GPUs' texture memory.

(2048x2048)*(4channels a 1byte) = (2*2MB)*4 = 16MB

6 texture atlases = 6 * 16MB = 96MB!!!


PS: spring just support 1 3do texture atlas and cuz I merged parts of the 3do and s3o rendering it needs 2 textures to do so, so it needs 32MB atm (if the full 2048x2048 is needed).

PPS: the 3do textureatlas NEVER gets compressed.

[jK]

I'm not 100% sure but afaik there is just one 2048x2048 atlas for 3dos so Caydr will have huge problems with his like 256x256 textures anyway. When looking at it from the technical side additional atlases are quite unprobable as Spring would have to go through every model so it wouldn't need to apply two or more atlases to one model as the textures used would be split over those three atlases...

Plus we only have limited atlases for our sprites too...

not to forget that 3do rendering doesn't support mipmaps, so ...
.. such detailed sprites look ugly at distance (they change pixels if you move the camera)
.. it is _slow_ cause of missing texture cache hits (e.g. it needs to read 16x16texels just to render 1pixel w/o being able to reuse the read data).

[Caydr]

So it's BMP or nothing...

Well as Argh points out, the difference between BMP and PNG will probably be reduced a lot when they're zipped up, so I guess it's not such an issue.

I admit I'd forgotten about the texture atlas limitation, but through some elaborate smartassery I think I've gotten around that problem without much trouble.

I realize that 3DO is inferior to S3O, but I'm not going to be bothered converting every TA unit just for the sake of this.

I'll report back when I've got some ingame screens. Even with old-fashioned 3DO I bet these will look pretty nice.

Can someone tell me where the atlas file is stored? It would be nice to see how much breathing room I've got here...

[Master-Athmos]

When you run the Spring.exe with a "/t" it should save all used atlases to the Spring folder...

[rattle]

TGA for team color, BMP for everything else because zipped up it's about the same size as if you were using PNGs