Hard Light Productions Forums
Modding, Mission Design, and Coding => The Modding Workshop => Topic started by: Flaming_Sword on September 26, 2009, 11:19:53 am
-
Just throwing this out there:
Would anyone find PNG support useful?
Does anyone use JPEG for their modding?
Would anyone care if JPEG support got removed?
-
Remove jpg. Anyone using jpg for anything besides interface art should be shot. And even there, jpg suffers from a lack of transparency and introduces ugly artefacts. PNG FTW.
-
TBP and Zatharas are using .JPG for some of their textures, I was using it a long time ago when making effects and textures, so changing it will require messing with something old that works perfectly now. Plus I don't really see anything we can gain form removing .JPG, and it's most likely going to take time and effort, meaning delay in commiting changes. Adding PNG is obviously a good idea, as it's going to be a new feature that will allow new possiblities. So I vote to keep .JPG and add PNG.
-
Add and Keep
It's not really an argument to say "I think .jpg sucks and everyone thinking about using it should be shot". To avoid total breakage of older mods/campaigns, just keep it. Unless it is in some way interferring with added .png support or something.
-
Keep it. Definitely.
Why remove it?
-
Don't care, I use PCX. :P
:lol:
-
Remove jpg. Anyone using jpg for anything besides interface art should be shot. And even there, jpg suffers from a lack of transparency and introduces ugly artefacts. PNG FTW.
Agreed.
-
Blueplanet has a few .jpg's in the interface folder
Edit: Though that's the old version I'm looking at here apparantly. So disregard me.
-
TBP does? I'll have to see about converting those.
So it does. Mostly planets and skyboxes. Wondering if that is causing slowdowns now.
-
Seriously, what would be gained by removing it? By all means add support for the superior format, but for the sake of not screwing over who knows how many older fan-made materials, leave .jpg in there too. Isn't one of the primary goals of the SCP supposed to be maintaining backwards compatibility?
-
PNG?!?
THE **** IS WRONG WITH DDS?!?
sorry for the shouting, but isnt png extremely inefficient for game usage?
also, DDS is superior to it in any way, except for the complexity of making a proper dds.
-
sorry for the shouting, but isnt png extremely inefficient for game usage?
Interface art?
-
dds can do it too
just because artists are lazy, it doesnt mean that an truly inferior technology should make its way in.
-
Don't remove anything, or things will break. PNG support would be nice though. Not as big a download as uncompressed DDS, and doesn't have compression artefacts like compressed DDS often has.
-
dds can do it too
just because artists are lazy, it doesnt mean that an truly inferior technology should make its way in.
Except that uncompressed u8888 dds take up a lot more space than the equivalent pngs. Except that compressed dds introduces compression artefacts. Except that png is actually pretty workflow-friendly.
-
Except its memory inefficient. And utterly useless in real-time or offline renderer.
-
2_Options_Main. 1024x768. As a 32bit Color graphic.
Uncompressed DDS (u888): 2,363,392
TGA: Same as uncompressed DDS.
DXT1 DDS: 397,312 but has artifacting which will only get worse with successive edits and saves.
JPG, Quality 12 (no compression): 233,472 still introduces JPG Moire along edges and borders, will get worse with successive edits and saves, no transparency. More compression will mean significantly smaller sizes, but further reduction in quality.
PNG: 294,912 no compression artifacts. Successive edits and saves offer no change in quality, meaning that working copies can be refined without the massive space used by DDS. Transparency and Alpha-Blended transparency (gradient) supported. Smaller than DXT1 without any quality issues.
Further more: PNG implementation and support for rendering does not, when done properly, incur any more overhead for processing the PNG image than the DDS rendering code does in rendering DDS files. In a WORSE case scenarios, it's not going to consume any more over-head than the existing JPG/PCX libraries. And if it consumes as much as TGA does, I'll shoot somebody.
EDIT: And even more further more: Anybody assuming that just because JPG is in the engine means that OMFG somebody most be using it: Only TBP and Flames of War can be found to use JPG files, and ONLY as interface art. JPG, while usable on a model, most certainly NOT be. So JPG's only sad lonely existence is currently as an alternative interface format that you can't even EFF and have look good. The file count is so damn small that the fabrication of PNG replacements would be easy to accomplish.
-
i can see a few places where youd want to use jpg. such as tech animations. since its animated the artifacts wont even be noticed. jpeg eff could be used to save drive space (memory usage in this case shouldnt even be an issue). another place is to make the mod download smaller using the better (but lossy) compression ratio no textures. have the engine convert those textures to the propper dds format and output the texture as a dds in the cache folder. that way mods can have their textures packed down in jpeg format. the engine would convert them to dds and use those from then on.
i really cant think of any reason to use png. if i want limited lossless compression i could use tga with rle. though i see very few uses for it. all model textures especially large textures should be compressed, as should animations. normal / height maps should be compressed if possible. all large effects should be compressed (thousgh sometimes it pays off to use a low res 8888 on some smaller effects). the only place you really need lossless is in the interface and hud, and tga or 888/8 dds works fine for that.
-
i can see a few places where youd want to use jpg. such as tech animations. since its animated the artifacts wont even be noticed. jpeg eff could be used to save drive space (memory usage in this case shouldnt even be an issue). another place is to make the mod download smaller using the better (but lossy) compression ratio no textures. have the engine convert those textures to the propper dds format and output the texture as a dds in the cache folder. that way mods can have their textures packed down in jpeg format. the engine would convert them to dds and use those from then on.
The problem is that jpg does not support transparency. And using the "green is transparent" workaround that is available for pcx is definitely not a good idea if you are using a lossy compression.
-
Jesus.
TGA existis because no image editior in the world needs any (or should need any) plugins or what not to use it. I'm fine with that. Even has transparency. But did you miss the file sizes listed above? F'ing huge wherever it is used.
Yes, at no compression the JPG is SLIGHTLY smaller. See the emphasis on slightly? Thought so. Now, have a transparency. Can't be done unless you make a SECOND jpeg for use as a mask. Assuming that mask support for the file in question is in the exe. JPG as an EFF compared to the other farmats is frankly a joke and I've NEVER seen it used. Anywhere. Period. Conversion of JPG in mem to a DDS? As in, -img2dds flag? Adds computational overhead and if it's for something that needs to be mip-mapped, it should be in DDS to begin with, and -img2dds adds compression on top of it, so an already compressed JPG will look even MORE like ass compared to a straight PNG.
For compressed container storage, both JPG and PNG have negligible differences between the resulting file size. I really cannot think of any reason why to use a jpeg where a PNG could be better served all the way around. No corruption of the image during frequent edits/saves for a texture usage that doesn't require or need being in DDS (compressed or otherwise, and the image quality vs a compressed DDS (See DXT1 above) is far superior).
-
we need a materials system!
rle is pretty effective on intrerface graphics that have a lot of consecutive pixels of the same value. this pretty much includes all border space (especially in the vertical). you can use that space for alignment purposes without chewing up much more space than the part of the image that is actually useful. but it wont save any memory over dds. just a small amout of drive space.
i also keep all my images in photoshop format, with layers and channels intact, then export to dds (or other formats) as needed. all in all some textures represent 14 channels, 2 of which absolutely cannot be compressed. normal uv which can be stored in an 88 dds. you can store the remaning 12 channels in 4 other dxt1 maps or 3 dxt5 maps. you can assign channels which require more depth to the green and alpha channels.
or you can store every map in 2 dxt1s and 2 dxt5s. use 2 of the dxt5 alpha channels (least lossy) for uv normal, 3 of the green channels (second least lossy) for rgb diffuse. 3 of three red channels (most lossy) for the specular color, 3 of the blue (most lossy) channels can store the glow color. the remaining rgb values can be assigned to env, height and alpha. a container image format can use this setup, though im not sure if thats gonna be a headache at rendering, not sure looking up rgb in 3 different images stored in memory can be done as fast as extracting all the channels from a single image. hopefully its as easy as passing the correct pointers.
-
Somehow, I don't think you've quite understood what this is about. Noone is seriously proposing to use png as a texture format; It's interface screens we're dealing with here. And believe me when I say that run-length compression does **** all for those. Especially when you create pretty ones. And a small amount of drivespace saved is important when you want to do mods that look pretty but don't take up 130+ MB for the interface alone.
-
Changing my vote to "other".
I no longer have any opinion on this matter.
-
You can't honestly expect every single modder to know the subtle difference between these formats. Because for a non-artist, all you can judge from is file size, and JPG is very good at that!
You can't honestly expect every single modder to constantly check what kind of stuff the SCP removes on a daily basis, and revise their work accordingly. Updating, re-VPing, retesting and reuploading constantly is a lot of hassle, not to mention that because of the very frequent updates, there'll be numerous versions all around the Internet, assuming you don't have a control over all the mirrors.
You also can't honestly expect every single player to know that the SCP no longer supports JPG, and that's why the mod he's about to play doesn't work. I imagine that a lot of players would quite simply vent their frustration at the modders and rate their work 0/10 just because he can't run it.
Removing features is an irresponsible and self-centered move. You don't like JPG? Fine, then don't use it, but if someone from the SCP had bothered to implement JPG support, don't remove it.
-
What Topace said.
-
Yes.
-
You can't honestly expect every single modder to know the subtle difference between these formats. Because for a non-artist, all you can judge from is file size, and JPG is very good at that!
You can't honestly expect every single modder to constantly check what kind of stuff the SCP removes on a daily basis, and revise their work accordingly. Updating, re-VPing, retesting and reuploading constantly is a lot of hassle, not to mention that because of the very frequent updates, there'll be numerous versions all around the Internet, assuming you don't have a control over all the mirrors.
You also can't honestly expect every single player to know that the SCP no longer supports JPG, and that's why the mod he's about to play doesn't work. I imagine that a lot of players would quite simply vent their frustration at the modders and rate their work 0/10 just because he can't run it.
Removing features is an irresponsible and self-centered move. You don't life JPG? Fine, then don't use it, but if someone from the SCP had bothered to implement JPG support, don't remove it.
I think you're overreacting just a little bit. For one, jpg was never used heavily. Making the changes necessary should be a minor job. And it can be implemented in a way that warns the player about the problem, and tells him what to do and where to direct their anger properly.
-
And it can be implemented in a way that warns the player about the problem, and tells him what to do and where to direct their anger properly.
If that's the way it'll be implemented, or an automated conversion program will be implemented along with it, then it's fine by me.
-
I've still yet to see anyone giving any sort of reason why you'd even want to remove JPG support in the first place, no matter how unfavorable that particular format might be. I feel safe in assuming that doing so won't magically give us a 10 FPS increase in-game. If there are mods out there that do use JPEGs, and would be broken if support for them were removed, I don't see how the team has any business in doing so.
-
So. In looking things code wise over and having a think:
It was a lot easier putting PNG in as a replacement for JPG. But it is not impossible to have the two.
So, the two it is. There will be builds soon showcasing the event as soon as some more testing is done.
Now there are more potential choices for people to use.
My apologies for allowing my personal tastes to over rule my community focus. Vote changed.
-
Sorry for the Double Post.
We can close the Poll now. It's useless at this point.
Secondly: While PNG support may or may not make it into the code, there will be no further discussion of removing JPG or any other format from the engine. This will also include PNG if it is found or made to be stable.
To that end, Read Here! (http://www.hard-light.net/forums/index.php?topic=65892.0) for some builds made that support using PNG files.
I highly encourage people to test these builds, even if you have _no_ interest in the PNG format or this discussion. We want to make sure we are not putting in something that breaks something else.
I also _HIGHLY_ recommend testing the Inferno builds as well.
-
It was a lot easier putting PNG in as a replacement for JPG. But it is not impossible to have the two.
That could've changed a few opinions. :p Though I agree that having both would be friendlier.
-
...and poll is locked.
Next up... vi vs emacs :nervous:
-
...and poll is locked.
Next up... vi vs emacs :nervous:
Emacs!
LOL I could never stand vi.
Anyways we should spend more time developing a material system rather than this LOL
-
You volunteering? :p
-
HAHAHA sure if you want it done in C# :lol:
-
What happen to Bob? Wasn't this on the table 4 years ago?
(IIRC it started in regards to something about shading and then revamping the whole materials system to enable shading, or words to that effect?)