Fresh install of 302 had 900+ additional downloads. Is that to be expected?
Edit: Then it did another 284. I gather this is not the intended outcome. I installed to C:\Users\<Me>\Games\Allegiance 1.2\
Allegiance Installer 3.01
Training mission use an old core, not sure if only the used models exist nor it only contains just giga, ic and bios.factoid wrote:QUOTE (factoid @ May 23 2014, 04:50 AM) Additional note, with texture packing on, sometimes at 1024 max I get wierd artifacts where the rocks and bases will flicker in and out.
Do not use texture packing, this makes you testing inaccurate and is another source for errors.factoid wrote:QUOTE (factoid @ May 23 2014, 04:50 AM) When I switch to my Nvidia GTX660, I always crash at 2048 textures, and always crash at 1024 if texture packing is on. I can run with texture packing on at 512.
I've also tested it on my machine with high res PNG files. It crashed even more often, not sure if it was optimization of the PNGs.factoid wrote:QUOTE (factoid @ May 23 2014, 04:50 AM) Lastly, for the high quality environment textures, do we have the source images? Are they 32 bit? I'm pretty sure the mdl compiling process drops them to 16 bit, which makes the colour range much less and introduces the really ugly banding that you see on the nebulae. I might be able to fix the mdlc program to stop doing that. 32 bit cards weren't common in 2000 either.
The Escapist (Justin Emerson) @ Dec 21 2010, 02:33 PM:
The history of open-source Allegiance is paved with the bodies of dead code branches, forum flame wars, and personal vendettas. But a community remains because people still love the game.
We can just use pngs? Should be doing that instead. MDL files are uncompressed, and I don't know if they preserve 24 and 32 bit color. The high res textures BTW have some serious issues that I'll address when I'm off work, but in short they're overkill in many cases.
"I make it a point not to chat with AP off... space is vast, but it's never vast enough for my scout."
-
TheAlaskan
- Posts: 2256
- Joined: Tue Apr 03, 2007 2:15 am
- Location: Denver, CO
So, texturing 101... textures are for providing per pixel colour information for objects being rendered. How much texture memory you need to render an object well depends on how many actual pixels it'll reasonably take up on screen. To this effect, a lot of the textures in the high res pack are horribly oversized. More pixles does not automatically mean more awesome. Keep in mind that most people's displays max out at 1080p.
So let's take a look at what's in the pack.
acs08 - It's a station, those textures are used for a lot of little details, so 2048 is probably ok.
bgrnd03 - They're rocks, you don't usally get too close to them, but when you do they can easily take up the whole screen. So 2048 works alright.
build1 - This could probably be dropped to 1024 or even 512. It's not something that has to look amazing.
cap05 - Not only does this waste a lot of space, but it seems to not actually have detail on it that requires 2048. 512 would probably work (as will probably be the case for most ship textures)
environment - These textures form the skymaps, they are always huge and are the things that benefit most from being 2048
exp - I don't even... these are animated textures that are "n" by 1 frames. 15k x 512 is not something many video cards will deal with. They tend to cap out along a single axis at the 4k or 8k. and 512 for a single explosion frame is kind of overkill. 128 or 256 per frame would make more sense, and the animation should be organized into a square matrix of frames to ensure they'll fit better on to most cards.
faohbs* - The station textures, 2048 or 1024 sure, the ship textures, probably 512x512. Lots of wasted texture space as well, even at lower res a better mapped object might be able to look better.
fig03/20 - Just no... too freaking large. 512 should be enough
fig30/34 - The betler textures, 512x512 for ship... gold star! Need more stuff like this.
fx18 - It's a blast wave. It is on screen for fractions of a second 2048 is not necessary. This would probably be just fine at 512.
fxmine - This one's probably fine
mis* - How much of a missile do you really see. I bet you could drop these to 256 and you's never notice. They also seem very wasteful texture wise.
mis404 - Really? 256 at most, maybe even 128
mis405/6 - You're killing me smalls...
neb* - These one's are interesting. They're bilboards, and when I was flying I never saw them take up the whole screen. So even at 1080p I don't think they took up more that 600 pixels. 512 or 1024 would be sufficient for them to still look amazing.
rixbay - I'm pretty sure these are just the insides of the launch bays. 512 is probably enough
ss* - In general the large parts of the stations are fine at 2048.
ss95, 97, 98, 99 - These are the exceptions, they look like they're simpler geometry, and can probably be reduced to 1024 or 512
ta_drac - I'm no artist, and I'd have to check the obj file mappings but given the patterns above, 2048 textures are overkill for fighters, May be overkill for some of the stations or teleporters.
ta_int and lt_int - Same texture... they could actually be compiled to reference the same image
ta_pod - 512 might even be overkill... 256 is probably fine.
It's easiest to guage these things when you can compare the different scales on a model in real time. The mdlviewer program I wrote for FA will let you do that. I can see about adjusting it to make it easier to compare alternate texture caps, but I'm pretty sure we could do the above resizings and that would solve many of the issues.
The other issue is the bit depth of the textures. If the current client supports 32 bit surfaces, we should be making sure the mdl compiling isn't reducing 24 and 32 bit textures to 16. It makes for ugly banding on the textures.
So let's take a look at what's in the pack.
acs08 - It's a station, those textures are used for a lot of little details, so 2048 is probably ok.
bgrnd03 - They're rocks, you don't usally get too close to them, but when you do they can easily take up the whole screen. So 2048 works alright.
build1 - This could probably be dropped to 1024 or even 512. It's not something that has to look amazing.
cap05 - Not only does this waste a lot of space, but it seems to not actually have detail on it that requires 2048. 512 would probably work (as will probably be the case for most ship textures)
environment - These textures form the skymaps, they are always huge and are the things that benefit most from being 2048
exp - I don't even... these are animated textures that are "n" by 1 frames. 15k x 512 is not something many video cards will deal with. They tend to cap out along a single axis at the 4k or 8k. and 512 for a single explosion frame is kind of overkill. 128 or 256 per frame would make more sense, and the animation should be organized into a square matrix of frames to ensure they'll fit better on to most cards.
faohbs* - The station textures, 2048 or 1024 sure, the ship textures, probably 512x512. Lots of wasted texture space as well, even at lower res a better mapped object might be able to look better.
fig03/20 - Just no... too freaking large. 512 should be enough
fig30/34 - The betler textures, 512x512 for ship... gold star! Need more stuff like this.
fx18 - It's a blast wave. It is on screen for fractions of a second 2048 is not necessary. This would probably be just fine at 512.
fxmine - This one's probably fine
mis* - How much of a missile do you really see. I bet you could drop these to 256 and you's never notice. They also seem very wasteful texture wise.
mis404 - Really? 256 at most, maybe even 128
mis405/6 - You're killing me smalls...
neb* - These one's are interesting. They're bilboards, and when I was flying I never saw them take up the whole screen. So even at 1080p I don't think they took up more that 600 pixels. 512 or 1024 would be sufficient for them to still look amazing.
rixbay - I'm pretty sure these are just the insides of the launch bays. 512 is probably enough
ss* - In general the large parts of the stations are fine at 2048.
ss95, 97, 98, 99 - These are the exceptions, they look like they're simpler geometry, and can probably be reduced to 1024 or 512
ta_drac - I'm no artist, and I'd have to check the obj file mappings but given the patterns above, 2048 textures are overkill for fighters, May be overkill for some of the stations or teleporters.
ta_int and lt_int - Same texture... they could actually be compiled to reference the same image
ta_pod - 512 might even be overkill... 256 is probably fine.
It's easiest to guage these things when you can compare the different scales on a model in real time. The mdlviewer program I wrote for FA will let you do that. I can see about adjusting it to make it easier to compare alternate texture caps, but I'm pretty sure we could do the above resizings and that would solve many of the issues.
The other issue is the bit depth of the textures. If the current client supports 32 bit surfaces, we should be making sure the mdl compiling isn't reducing 24 and 32 bit textures to 16. It makes for ugly banding on the textures.
"I make it a point not to chat with AP off... space is vast, but it's never vast enough for my scout."
-
TheAlaskan
- Posts: 2256
- Joined: Tue Apr 03, 2007 2:15 am
- Location: Denver, CO
I down sampled some reference art from 24 bit RGB888 to 16 bit RGB565, and visually the difference is minimal. I'm going to try to find the ideal texture sizes for the high res stuff and see if I can repack it. The source 24 bit art isn't critical.
"I make it a point not to chat with AP off... space is vast, but it's never vast enough for my scout."