The wonders of converting 3do mods to s3o

[Beherith]

Hi guys, so Ive been thinking and coding a lot about making all of BA-s units (all 400) into s3o's, so I could add AO baking, normal mapping, and even parrallax mapping.

But the texture space requirements have me really scared:
- In a worst case scenario, with no optimizations, each unit would require a texture between 512*512 to 256*512, and 4 of these (tex1, tex2, normal, parrallax), requiring 1 megapixel of uncompressed texture space for each unit, resulting in almost a gigabyte of uncompressed unoptimized space.

-AO baking each unit would result in textures that differ quite a bit, but the symmetry of most units would allow at least halfing of the required space. Using DDS textures I can bring it down to about 100 megabytes - which is still way too much. Other optimizations are possible in this case, such as reuse of closely similar tiles, and reducing the size of small scale quads with large textures.

-1600 individual textures would be an issue with texture context switching, but atlasing them to 2k*2k textures would decrease this to about 100. Atlasing would even provide me with more space to search for similar textures.

My question is the following:
- Should I attempt to forego the AO bakes, which would mean that I could use a single texture atlas (I wouldnt want this, as I like AO bakes...), or try to pursue them, even knowing a whole lot of work must be done into optimizing them to make it all fit.

Edit: another advantage of not using a single atlas would be the ability to use perspective correct UV maps so that ugly non rectangular quads could be corrected to remove half-assed stretching.

[Otherside]

TBH I don't know why your bothering trying to convert all OTA models to S30. Your better off spending your time on your remodeling efforts. Even with an AO bake and normal mapping, units will still look like crap. At least with the remodeled units they actually look decent and you can keep them faithful to the original designs.

[Beherith]

TBH I dont know why you dont read posts, if you did, you would notice the as of yet overlooked issue of massive texture space creep. Even a conservative estimate of 512*512 textures per model results in a whopping 600 megabytes of tga textures for BA.

And telling me how I should spend my free time? It takes me two full days to remake a model, and it becomes decidedly not fun by the end of a week.

[smoth]

Add to that all the baw it isn't how I want to look that you see from the community

[KaiserJ]

what strikes me immediately is that you could possibly get by with 256x256 for most tier 1 units... like you said, some of the models are symmetrical; some of the economy buildings could be reduced 4x (thinking of solar panels)

if you kept the 512 just for the big guys (t2 tanks and the like) then you'd also have a better chance of maintaining pixel aspect... for a good example of how not to do this, play evo, build a hover lab, and compare the look of the lab up close to the light tank... looks fucked, because they are using the same size skin, but one is way more massive than the other.

what eats your time the most when remaking btw

[Beherith]

Well, drawing a sketch on paper takes only a few minutes, but requires an idea.

Then modeling takes anywhere from 2-6 hours, depending on complexity and how many times i start over.

Then UV mapping, which is mindless drudge work, but needs to be done once, done well is like another 2 hours.

Then texturing it can take anywhere from 1-4 hours, and finally theres a few hours of drudge work, importing into upspring, setting up everything perfectly, painting teamcolor, glow, reflections, making the wreck, etc.

[KaiserJ]

well, i have to bounce to work in a minute or two, but im thinking collaborative effort. this isn't far off something i was going to attempt myself in the near future.

i've been able to make a unit of similar complexity to OTA style (albiet 2x polycount) and uvmap it in 45 minutes to an hour using some sneaky tricks.

of course, that still makes it a job that will take hundreds of hours. just musing out loud really

[Argh]

Even a conservative estimate of 512*512 textures per model results in a whopping 600 megabytes of tga textures for BA.

Which is one of many reasons to use DDS. That, and better overall throughput and consistent mips on all hardware.

There is a reason why nothing commercial uses TGA any more. It's huge and even PNG is a far better choice.

But the texture space requirements have me really scared:
- In a worst case scenario, with no optimizations, each unit would require a texture between 512*512 to 256*512, and 4 of these (tex1, tex2, normal, parrallax), requiring 1 megapixel of uncompressed texture space for each unit, resulting in almost a gigabyte of uncompressed unoptimized space.

First off, parallax only requires an alpha channel for the depth, plus a normalmap. So you really only need 3 textures per unit. You can do AO bake, and you could even use that shader stuff I'm working on to store it in the blue channel for final processing, instead of merely using it to change diffuse values. But frankly it's not even that important anyhow.

Second off, a 512 DDS is 342KB, and that texture is compressed on the hardware. 256 DDS is only 86KB, and is sufficient for a lot of things, with normalmaps to provide extra context.

-1600 individual textures would be an issue with texture context switching, but atlasing them to 2k*2k textures would decrease this to about 100. Atlasing would even provide me with more space to search for similar textures.

Atlasing is useful only if you have a lot of individuals on the screen that share that atlas. For example, an atlas for all of the buildings would be a big performance enhancement when viewing a base, but using an atlas for the less-seen Units is a mistake, because crunching through that big skin is very expensive. You don't want to throw a 2048 around for one guy, and then have 40 guys over somewhere else on screen that are using 5 different atlases.

Moreover... here's the big rub with atlases. Spring checks to see if Units match each other and prevents texture duplication by checking with the previously rendered Unit. If tex1 and tex2 match, then the atlas has saved a texture context switch. This series of checks is performed in alphabetical order... so you'd have to re-arrange all of the unitDefNames to match your atlasing schema to really see it work properly. It's really stupid that it works that way, but that's what happens when you have an engine that doesn't use a material system.

But, as I've said in the QA thread, right now it doesn't matter if you atlas or not- Spring's process for rendering Units is doing some really inefficient stuff atm. I think that atlases are pretty much a waste of time outside of ARB-shaded stuff until all of this stuff gets fixed, frankly.

[Kloot]

Spring ... prevents texture duplication by checking with the previously rendered Unit.

wrong

If tex1 and tex2 match, then the atlas has saved a texture context switch

wrong

This series of checks is performed in alphabetical order

wrong

so you'd have to re-arrange all of the unitDefNames to match your atlasing schema to really see it work properly

wrong

It's really stupid that it works that way, but that's what happens when you have an engine that doesn't use a material system.

It's really stupid that you keep spouting bullshit about an engine whose rendering internals you don't understand over and over and over again.

[Beherith]

Kloot, your normal/parallax shader gadget is one of the primary inspirations for this endeavor, and I would greatly value your input on this matter.

I am prepared to do two pilot projects, one involving no AO bake, just the atlassed TAtex for all units (color, other, normal and parallax), and one with separate textures for each unit, with AO bake and texture space optimization.

[Hoi]

wrong
wrong
wrong
wrong
wrong

It's really stupid that you keep spouting bullshit about an engine whose rendering internals you don't understand over and over and over again.

M-M-M-MULTIKILL!

I really do not recommend doing anything to those OTA units. And yeah, making units takes a lot of time. It's not like TA was made in 1 day, remaking it in a day is even harder :)

The best thing to do in my opinion is just doing new units (based or not based on ta units). The more you do it the more you learn. I can uv map most simple units (1000 polygons +-) in about 30-45 minutes and do a great job, overlaying, using nearly all space et cetera.

The more you do the faster, and the better you will be able to do it later. Just remember that and also remember that you can't make a complete set of assets for a game yourself in a short amount of time.

What does take me a lot of time is 4000-8000 polygon handgun models, that's where it really starts getting complicated. If you ever do that you'll wish you can do simple units again

[SpliFF]

Even a conservative estimate of 512*512 textures per model results in a whopping 600 megabytes of tga textures for BA.

Well there's your problem right there.

512*512 TGA = 988.7 kB
512*512 PNG = 31.1 kB
Difference is 957.6 kB

TGA -> PNG = (957.6 / 988.7) * 100 = 96.85% size reduction
600M * 0.9685 = 581.1M saving
Your 600M becomes 19M

There is absolutely no reason to use TGA. It's the product of an older time where it was the only lossless 24-bit color format supporting transparency. PNG has made it completely obsolete.

When saving your files as PNG crank the compression up to 9. It is still completely lossless (your image quality isn't affected in any way) it just takes longer to compress and decompress. On any modern system that translates to microsecond differences so you simply won't notice it. In fact by reducing the number of disk blocks needed to be read you'll often load faster (due to the relative slowness of disks to CPU).

[Peet]

Aren't PNG images left uncompressed in video memory too?

[SpliFF]

Depends if you turn on "compress textures" in SpringSettings. That applies equally to all formats except DDS.

Also I forgot to explain, that actual size of TGA in a spring mod is entirely dependent on the 7-Zip compression of the .sd7 mod format.

Just tested with 7-Zip archives:

TGA
1 512*512 image = 424k
2 512*512 images = 432k
2 512*512 images, 1 1024x1024 image = 614k

PNG (with compression level 9)
1 512*512 image = 28.5k
2 512*512 images = 40.4k
2 512*512 images, 1 1024x1024 image = 61.5k

So PNG still wins hands-down (90% smaller). Results may vary with hundreds of textures though.

[Argh]

It's really stupid that you keep spouting bullshit about an engine whose rendering internals you don't understand over and over and over again.

Fair enough, but the last time I asked, that was what I was told it did, and that is what it appears to be doing when tested.

Anyhow, if there's a process that would actually work easily for atlasing and be efficient, please let us know, it would be useful.

[smoth]

Harbor set.

[Argh]

I know what an atlas is, lol. What I want to know is: how do you have to arrange the UnitDefs / tex1 / tex2 / etc. so that it's efficient. Like, say if you want to use 6 2048s instead of 96 512s.

What process does the engine use this week to determine whether to switch contexts? Names? Internal numbering? Texture names?

[Beherith]

This isnt going anywhere, so Im locking this thread until I have some progress.

[Beherith]

Progress is promising, but Ive run into a pretty heavy block in converting the 3DO's to S3O.



But the issue is with 3dos facing +Z while, s3os face -Z.
So this results in the units going the wrong way. Ive tried mirroring the unit on the Z axis, as well as rotating it 180 around Y axis, but all of these methods fuck up the animations.

So anyone have any experience converting to s3o while keeping the old animations?

[smoth]

I have 3dos and s3os using the same animations.