Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Sticks on June 23, 2005, 01:21:05 pm
-
Currently, having 24bit specmaps and glowmaps, is one of the major problems that is causing some of you to get stuttering, low mem warnings, some crashes, etc. So my question to you is, would you be willing to sacrifice 24bit specs and glows (and replace them with 8bit versions) to gain a smaller memory footprint?
-
I vote gameplay over graphics any day. ;)
-
DDS textures, while at 32 or 24-bit, use approximately the same amount of memory as an 8-bit texture of the same dimensions. I'm already testing a full DDS conversion at load time for all graphics which gives you about the same 32-bit quality but only using the 8-bits worth of memory. Going back to 8-bit versions of that stuff isn't really going help in that case, especially since nearly all of the current 8-bit graphics are loaded as 16-bit for blending reasons.
-
Spec maps need the extra for the alpha channel, don't they?
Glow maps can remain 8-bit, no problem there, but the spec maps, because of the lpha environment layer, and because they look better, should remain.
DDS is good, too, but not for everything, as Lightspeed pointed out some time ago.
-
You're saying that if there's a way to get the env map out of the specmap, you can reduce that to 8 bit?
-
Originally posted by Raa
Spec maps need the extra for the alpha channel, don't they?
Glow maps can remain 8-bit, no problem there, but the spec maps, because of the lpha environment layer, and because they look better, should remain.
DDS is good, too, but not for everything, as Lightspeed pointed out some time ago.
I don't care much for DDS because some cards have quality issues when it comes to compressed textures, especially early GeForce cards. In all honesty, I think if I showed you a ship with a 24bit specmap vs. and 8bit specmap, you'd be hard pressed to tell the difference because of the way the technique works. The only thing you'd lose are the cockpits with differently colored shines and other details using that trick.
If everything went to 8bit, you could fit 4 different textures into one 32bit file. Spec, glow, enviro, and bump.
-
But how would you acheive environment mapping control?
-
DDS get's my vote, they've sped up TBP quite a lot.
Shinemaps are fine in 8bit, but some glowmaps need 24bit for smooth gradients (light cones and stuff)
-
limiting artist's options is bad.
-
Yes. I'd ***** like all hell if you removed my option to use tga. Remove that, and you lose this modeler.
If performance is an issue, it should be up to the end user to decide wether or not they want to use TGA or not. And should not be forced upon everyone.
-
Originally posted by Bobboau
limiting artist's options is bad.
silence!
the ever wise one speaks!
:D
hows that materialls system comming along? it should improve our options greatly. and what ever happened to the most recent test build, i have a machine that can actually run it now :D so i can see what it can do and establish some usage doctrine.
-
yes, it should, too bad I'm forbidden from working on it untill after we release, I was right in the middle of something realy complecated too
and if you want that materials build I posted a while back, it's here (http://freespace.volitionwatch.com/blackwater/fs2_open_r_mat_test_0.zip)
keep in mind the table format is still quite subject to massive changes and shouldn't be consitered complete untill an offical release with it integrated. I know for a fact I intend to completely change the way textures are assigned.
-
I'd want to see side-by-side comparisons first, but I'd be inclined to say no. I can pick out quality differences in the interface art when I'm not using -pcx32, so I'd guess that I'd notice lower-quality textures. The most recent builds seem to be getting much more stable and efficient for me, at least. As I said to someone in another forum when discussing the SCP, the gameplay's already perfect, so prettier graphics is all I really need. My video card (Radeon X300) needs to be upgraded anyway. :)
-
Originally posted by Mongoose
I'd want to see side-by-side comparisons first,
http://penguinbomb.com/lightspeed/TGADDS.html
-
The solution is for people to make 8-bit versions if it's really a big problem.
Honestly, no one is threatening lawsuits if you use VPView (http://www.descent-network.com/cgi-bin/descman.cgi?module=vpview20) to extract the textures from the mediaVPs, IrfanView (http://www.irfanview.com) to convert them to 8-bit versions, or using DXTBmp (http://www.mnwright.freeserve.co.uk/programs/dxtbmp.htm) to compress them to DDS versions. If you have the hardware to support it I see no reason to force people to use lower-quality graphics...I have to say I've actually been spoiled by fs2_open, because at times I'll find myself looking at a wall or something in Half-life and reflecting on how bad/compressed it looks compared to s2_open.
-
Shine, - and Specmaps shoud remain as they are. It should be upon the end user to decide what goodies are enabled ingame, launcher serves that purpose. Also, we must remember the heavy work and endless hours that are comitted into these features.
So in my opinion, I am willing to sacrifice some fsp and see the Freespace 2 at its finest.
-
freespace's life has been greatly extended, its pretty much on par with the games on the market today. computers are about 5-10 times faster. cpus have increased clock speed 5 times over, 64 bit has become common (is there support for this yet?), busses are 5 times faster. memory is faster aand has higher capacity, htl as greatly increased games speed. freespace is certainly keeping up with the technology. cutting resolutions or going back to 8 bit seems like a step back. im now comfy using 2048^2 and bigger maps.
compressed textures are good for high res maps, its resolution that makes the texture, not the absence of compression artifacts., compression allows for us to increase map size without sacrificing performance. at such a high res artifacts are negligable but eliminating them means you need to use a texture 4 times smaller to get the same performance. i choose the bigger texture.
-
Originally posted by Bobboau
yes, it should, too bad I'm forbidden from working on it untill after we release, I was right in the middle of something realy complecated too
Instead of complaining that you can't work on your materials stuff, why not take the time and do some debugging instead? That's the whole reason for the code freeze after all. :doubt:
If you're going to code for the SCP, you have a responsibility to fix bugs too.
-
I haven't had the time to do much of anything, the guy who was helping me at work quit after memorial day, so rather than getting more time after that I ended up with less. and they made me come in earlier.
-
Actually I have an important bit of info about specmaps:
Almost *NONE* of the current specmaps use the true potential of the engine!
The engine would be capable of showing rough, smooth, glassy, gloss and another myriad of surfaces.
(This could all be done by applying textures with different noise levels and distribution.)
The engine would be capable of showing true metalic stuff - giving different shine colors to the material than what is the diffuse base color.
(The only model that took a real advantage of this was the Shivan gas miner and I saw a pic of an Arcadia with a blue glint.)
Roughly ~85% of the shinemaps are nothing more than the base map with darkened/highlighted parts.
For a matte/initial conversion job that was very good.
However it's still far from what *CAN* be done with the system.
So before removing features, pls. check if anyone was aware they existed!
-
So before removing features, pls. check if anyone was aware they existed!
This is part of the problem. Almost no one uses these obscure features. Almost all spec and glow maps are already grayscale, esentially wasting the extra 16bits entirely. You don't get any more gradations of gray in 24bits vs. 8bits. I'd see the other side's argument better if these were things people actually use. Everyone complains that this is some thing "we really really really need, please please", but I don't see it even being used to its full potential. Rather, it hurts the average user instead, when people tell noobs to download the ludicrously overbuilt MediaVPs, and then they come back with big issues.
Honestly, no one is threatening lawsuits if you use VPView to extract the textures from the mediaVPs, IrfanView to convert them to 8-bit versions, or using DXTBmp to compress them to DDS versions. If you have the hardware to support it I see no reason to force people to use lower-quality graphics....
And who's going to tell the new user to do that? "Hey, if it's running crappy, here's this 2 hour step you can perform."
I have to say I've actually been spoiled by fs2_open, because at times I'll find myself looking at a wall or something in Half-life and reflecting on how bad/compressed it looks compared to s2_open
Well, we're about to enter that era with the -img2dds flag. Not that I think that converting to DDS is a bad solution, I just think it skirts the issue, even if only momentarily.
The engine would be capable of showing rough, smooth, glassy, gloss and another myriad of surfaces.
Well, environment and normal maps would absolutely have to be 24bit. And you absolutely should not compress normal maps. So that's a load of textures for each object. Base, normal, spec, glow, env. It's only going to get more out of control.
-
And who's going to tell the new user to do that? "Hey, if it's running crappy, here's this 2 hour step you can perform."
If we change it, we'd have to do that anyway, unless the engine is going to automatically convert files. Of course it probably isn't a 2-hour process, just add all the -glow and -shine maps into IrfanView's batch conversion and make them all 8-bit.
Either that, or it's a process of redoing all the art so that it looks worse, which I'm sure people will be overjoyed to do.
This just seems...absurd. These features are crashing some people's computers. So what's the solution? Oh, take them out entirely so no one can use them. :wtf:
Has no one noticed the massive thread dedicated to the new materials system, or do people simply not care? This is exactly the sort of thing that would be optional with it. Yet half the dev team is calling for 24bit glow/specmaps to be taken out entirely.
Nor do I see putting this in before 3.6.7 as being any more valid than putting the materials system in, as it technically breaks compatibility with older fs2_open campaigns (Gee, where have I heard this before?) and could easily cause bugs if it was implemented now.
Not to mention that I'm pretty sure that at least some of the glowmaps in the mediaVPs use colored gradients to make it appear that light from the glowy bits is falling on nonglowy parts of the hull, and my artistry has been confined to the MSPaint thread.
Plus, it'll probably take a LOT longer to implement, test, and bugfix this than it would to convert the files to 8-bit colour, but I don't see anyone volunteering.
Nor do I see why everyone talking about this needs the features to be taken out entirely and not simply autodetect if a texture only has one channel and apply it differently if it does (hell it might do this already)
-
OMG! I can't believe it, I totally agree with WMCoolmon! The world is coming to an END!!! Evacuate now!!
Sorry, bad joke. :D
I want to mention something that has been brought up briefly before but never really pointed out as a real option. DDS doesn't mean a compressed, low quality image. DDS is DirectDraw Surface and that can be anything from a compressed image to just an 8-bit alpha channel and everything else in between. You can make a DDS image with an 8-bit color palette if that's all that you require and compression doesn't do the artwork justice. The OpenGL code can tailor itself to the image being used right now and I'm sure that the D3D code can be made that way if it isn't already. The DDS loader doesn't properly handle everything that you can throw at it but if people want to do this stuff then I'll gladly take an hour or two and make the needed changes to the code.
As far as -img2dds goes I don't know how many people have actually tested it out and can say that the quality is acceptable or not but as I mentioned, it's only a test of the code. If you're happy using -pcx2dds in D3D then this is only a much better version of that. Though -img2dds is somewhat dependent on the API being used it works and a higher level so you can have more control over it and apply it's memory usage savings to the greater area of the game. The final version of the code could just have options for each file type if wanted so -pcx2dds can convert just PCX images, -ani2dds can just convert ANI, -tga2dds..., etc. It's there now so we can better figure out how to make use of it. I can tell you from just my perspective that on my slower Windows test machine I seriously enjoy the 52% decrease in memory usage and 30-40 FPS speed improvement in-game. I like all the pretty pictures so I use them even if the computer can't really handle it that well. Finally getting to have to pretty stuff, even if it is of slightly lower quality on some things, while actually having a playable game on that crappy computer is a great thing to me.
-
IMHO the a good solution could be implementing support for 8-bit glow/spec.maps (since AFAIK there isn't) if there is a demand and make it *optional*.
So if the users want to, they can use the grayscale images and save mem while others could use the colored images.
Not as if using DDS wouldn't be just as liberating, but still if you have an irresistable urge to purge 16-bits of those files this would be a good aim without braking anyone's jewels.
BTW Bobb, should have some authority in the whole question as his Material system will replace the whole lot of this.
Currently for each and every pixel on a texture you can assign:
-A diffuse color
-A glow color
-A specular color (and intensity)
-A reflective color (and intensity) *am I right on this one?*
-Opacity
That's quite a lot. Many non-FS modders would salivate in anticipation if told a FREE (well *semi*) engine is availible that's capable of handling all of that.
When told that the engine can do anisometric LODing (superdetail boxes) and handle massive polycounts they would take us for fools...for that's too good to be true.
This engine is more capable than what we're actually aware of and many people outside the Freespace/HLP community would be glad to use it if they were aware of its potential.
-
Originally posted by Flaser
IMHO the a good solution could be implementing support for 8-bit glow/spec.maps (since AFAIK there isn't) if there is a demand and make it *optional*.
That's what I was saying. Make an 8-bit, uncompressed, DDS and it will get used that way. If you make a PCX then it has to be converted to 16-bit (very difficult to pick and choose what goes 16 or stays 8) but the DDS could be used as is. That makes it optional, totally up to the artist, and it requires very little change to the code to work. That would work easily for glow/spec maps and you could just make an EFF of the DDS images if you wanted a small, animated glow map.
EDIT: And I should say that using 8-bit DDS wouldn't save any memory over a compressed DDS. DXT5 is a 32-bit image with a 4:1 compression ratio. That makes it's memory usage the same as an 8-bit image of the same dimensions. A 24-bit DXT1 has a 6:1 compression ratio so it's even smaller. The compressed versions are faster for relatively modern video cards to use so if you can get by with the compression artifacts then you can have full color for the same memory used.
-
i thought dxt1 had an 8:1 compression ratio.
i think its more troublesome for the engine to handel 8 bit texts when most video cards are designed and optimised to use 24 and 32 bit texts. dds is a format optimised for games, when you look at all the other image formats, they werent designed in such a streamlined manor. the fact that the texture is lossy is irrelevant, because rarely is the texel size gonna exceed the pixel size. hopefully the materials system would allow us to manually script how the individal maps are used. just because the game can handel difuse, spec, env, and glow maps for each and every texture, doesnt mean that each and every texture in the game has to use their own. the materials system should allow us to define a generic effect for a texture, or use their own custom maps for fine details.
-
I'm not saying to destroy 24bits in its entirely. Just for glows and specs. If the majority (90%) of spec and glows are grayscale, why are we wasting 16bits per pixel?
That's my only point. The buck has to stop somewhere, or else there will be no new users eventually. Go ahead and change a couple spec and glows to 8bit and you tell me if you can see the difference.
-
you could make something like an eff, but instead of frames of an animation, it litsts for a texture all the maps used. so instead of.
armorplate.dds
armorplate-shine.dds
armorplate-glow.dds
you have something like this
armorplate.whatever
--armorplate.dds
--genericmetal-shine.dds
--genericlight-glow.dds
hopefully materials will let you low end guys use something like that, you will still have env and specular, but they wont look as good. and sence multiple textures would share generic effects, it would greatly reduce memory consumption. but as far as im concerned i think the current system is really good and the materials system will make it better for high-enders and low-enders alike.
-
Originally posted by Nuke
i thought dxt1 had an 8:1 compression ratio.
Either or, though I don't remember the conditions which determine whether it's 6:1 or 8:1. I'm mostly seeing 6:1 in my tests so that's what I go with.
Originally posted by Sticks
I'm not saying to destroy 24bits in its entirely. Just for glows and specs. If the majority (90%) of spec and glows are grayscale, why are we wasting 16bits per pixel?
Not sure what images you are looking at but I'm not seeing mostly greyscale, I'm seeing almost all color glows and specs. Maybe 5% could be considered greyscale. Getting rid of 24-bit color seriously limits how useful those features are and if the glows and specs are compressed DSS then you would be saving zero memory by going with 8-bit versions. As flaser said, the current images barely touch on what the code can do. Limiting color space to save memory is one thing but with the current code you can save memory and still have your color space if you only use compressed DDS. If a compressed DDS of 24-bit color is only an 8-bit greyscale image then who the hell cares if you are wasting 16-bits of color, it's not using any more memory and it's more efficient for the video card to use than an 8-bit image.