Artwork submission guidelines for 0.5+

Thinking about improving the Artwork in Vega Strike, or making your own Mod? Submit your question and ideas in this forum.

Moderator: pyramid

safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Artwork submission guidelines for 0.5+

Post by safemode »

Make this sticky.


When submitting new art, you must do at least the following:

1. commit the png or other lossless file to the appropriate directory in the masters repository.

2. If you used some type of script to generate the image this should be committed as per pyramid's instructions that hopefully he'll add below. This is in addition to the image you use to make the DDS image.

If you are capable of generating DDS files correctly, you can also commit to the data4.x repository:

1. Scale the file to the nearest power of two resolution for both the width and height.

2. Remove the alpha channel if you aren't using it.

3. If the image doesn't make use of it's alpha channel, compress using DXT1 nvcompress DDS compression. If it does use alpha blending, use DXT5. If the image is never to be scaled, do not generate mipmaps.

4. Only DDS files can be committed to data4.x, png files need to have a very special reason to be committed to data4.x, and jpegs should never be.


To summarize, you must always commit to the masters repository, the image that will be made into a DDS for the data4.x repository.


Hopefully pyramid will now chime in with his instructions on naming, and organization of source files to images made in masters repository.
Ed Sweetman endorses this message.
pyramid
Expert Mercenary
Expert Mercenary
Posts: 988
Joined: Thu Jun 15, 2006 1:02 am
Location: Somewhere in the vastness of space
Contact:

Re: Artwork submission guidelines for 0.5+

Post by pyramid »

safemode wrote:Hopefully pyramid will now chime in with his instructions on naming, and organization of source files to images made in masters repository.
Hehe :D Done long ago: http://vegastrike.sourceforge.net/wiki/ ... quirements

Also follow the other links under art-related development: http://vegastrike.sourceforge.net/wiki/ ... rt-related

(Seems few are reading the wiki :roll: Usually I'm keeping the stuff related to my work pretty up-to-date)
Please post here if anything is missing or unclear.
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Post by klauss »

Why not jpegs in data4.x? high-quality jpegs may be way better than png at times. A small reduction in quality for a much smaller download. But they should be very high-quality jpegs. Very.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Post by safemode »

jpegs will just be compressed on the fly to DXT, as it has always been even before DDS. DDS's whole purpose is to bypass that. When i put DDS support in, I made PNG really lossless, meaning, we dont compress PNG on the fly anymore.


The way it was before DDS was everything gets compressed to DXT# on the fly. Which was why loading was very very slow.

The way it is now, is everything is already compressed to DXT#, with PNG as an uncompressed bypass type now.
Ed Sweetman endorses this message.
charlieg
Elite Mercenary
Elite Mercenary
Posts: 1329
Joined: Thu Mar 27, 2003 11:51 pm
Location: Manchester, UK
Contact:

Post by charlieg »

klauss wrote:Why not jpegs in data4.x? high-quality jpegs may be way better than png at times. A small reduction in quality for a much smaller download. But they should be very high-quality jpegs. Very.
masters -> lossless originals (jpeg is lossy)
data4.x -> lossy DDS images (better than jpeg or png for HW acceleration)
Free Gamer - free software games compendium and commentary!
FreeGameDev forum - open source game development community
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

I think Klauss said data4x; not masters; and I presume that he meant to say that perhaps JPG should enjoy the same status and treatment as PNG, by the engine, (no on the fly conversion).

But, myself, I'd also contend that the loss of a jpg at 90% quality is entirely negligible, for a 20-to-1 better compression in many cases, and should be accepted as masters format, as well; --even recommended. The masters repo, if you insist on it being strictly non-lossy, will probably grow to be about 10 or 20 or 50 times the size of data4x... Will sourceforge allow a 25 gig svn repo, say? And it misses entirely what is really important about a masters repository:

Most important thing of images in masters is that they be in fact the masters, (input textures), and of master sizes.

When texturing, I'd imagine people work at 4x the final scaling, do all their blendings and detailings at high res, then at the very end scale down the final diffuse, specular and whatnot results to game texture size, right? THAT is what will be needed again when updating the unit's mesh, for instance, or to produce an alternative paint job, or texture packing. The output of the blending is rather useless to preserve as a PNG, as it cannot be edited.

If I wanted to make a few minor changes to the Llama texture, I'd be unable to, without a separate bumpmap, if the diffuse and specular have ambient bumpmap shading included. If I wanted to change the language of a sign on a station, for an alternative faction, I'd be unable to, without a separate paint layer... Once all the layers are blended, and paint covers metal, and dirt covers paint, and scratches undo dirt and paint... How can I? To try to change that is pretty much impossible, whether it be dds or png, it doesn't matter. What you need is the INPUT layers, at high resolution.

THAT is what most importantly needs to be preserved, and therefore needs to be in the masters repo: the high res originals used as input to the blending, like paint and bumpmap and rust and ambient occlusion layers, etceteras; not just png's of the dds's in data4.x, I submit. The PNG's that begetted the DDS's are rather useless; --too close to the end of the pipeline; like calling a project "open source" because just the .o files are made available--; I wouldn't even call them "masters".

Masters are the *sources* one needs when modifying or updating a textures package.

But insisting that masters be in a lossless format is rather pedantic, IMO; and probably unsustainable in the long run.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Post by safemode »

for the artwork we can get the source files to, we do. That is, the scripts and instructions on how to render the images used to create the png/jpegs whatever images that are then used to generate dds files.

If we cant get the source scripts to the free applications you used to create the image, then we want a lossless image in masters. If we can get the source scripts, then jpg is fine if that's what the artist finds acceptable to represent their work. Just remember, the DDS file is made from the png/jpg image, the DDS file is not going to be generated by loading up the scripts and outputting a new file and using that. Any artifacts in the master image will only be magnified in the dds file. Try both and see if jpeg is fine.

as for jpeg in data4.x, jpeg has never enjoyed not being converted on the fly, indeed, neither did png. We decided that png would no longer be converted because it's a lossless format, so apparently, it is important enough to not be compressed from the artists perspective. We've culled all such images though leaving only a small number of textures. This is usually < 4x4 size textures. The size difference of jpeg to png for that size image is negligable. Hell even bitmap may be good for that. But really, that's not going to make a big difference in the game.

The idea is, with the size and number of textures in the game and being loaded into vram in any given system, we can't afford uncompressed textures of a significant size, we can barely handle them compressed.
Remember the textures do get decompressed on gpu and we do have to use vram for things other than storing textures, and most people dont have video cards with 1GB of ram on them. Our number and size of textures loaded at any given time is only going up, so we want to keep an eye on what we're loading. Already, my Nvidia 6600 which only has a 300Mhz gpu clock has no problem processing data, it's the memory that is it's bottleneck at high quality best shader etc. The vram can't keep up with the game, and it's 500Mhz 256MB ram. We're completely memory bound when it comes to the graphics, not system memory, but vram memory.
Ed Sweetman endorses this message.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

I understand that, but still, when speed is not an issue, such as at bases, jpg's would do a fine job, whether converted on the fly to dds or not, and would reduce the size of data4.x significantly.

WRT the masters repo, not everybody uses "scripts". I use Gimp layers, and Blender "noodles" (node networks). But in any case, what needs most badly to be in the masters repositories is not just the "scripts" or instructions, but the masks. For each ship there should be separate bumpmap mask, ambient occlusion baking, radiosity baking, base materials layer, a paint layer, greebles layers, etceteras; for both diffuse and specular.
Case in point: There's not even a point in wasting server space with normal maps. Normal maps are not editable. The height map used to generate the bumpmap is what's important.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Post by safemode »

We did what we did to make everything start from DDS. Then we knit pick things back after arguing over whether it was necessary.

Things like splash screens for instance, are less than a couple hundred KB bigger than the jpeg they're built from. 520K vs 370K. They're also in a fast code path so it makes sense to keep them as DDS. Base images however are huge, some as big as 2048x2048. There are quite a lot of related textures, I'd say roughly 50 textures. The size difference between jpeg and dds gets much bigger the higher up you go in resolution. The time it takes to compress goes MUCH higher as well.

I could throw in a check to the filename, and if we detect that the texture comes in from */sprites/bases/* then we dont compress jpegs, thus we would load them and not generate mipmaps either.


By the way, if you really want to clean the size of data4.x, bin is almost as big as the bases directory, at 50MB. Music is 158MB. The vast majority of the size is in unit textures and various other textures, and the vast majority of those are needed to be DDS. nothing you can do about that. We want big ass high resolution textures for our units and planets.



You'll have to talk to pyramid and talk over what is necessary to master the images we use in data4.x, i dont really deal with that aspect.
Ed Sweetman endorses this message.
pyramid
Expert Mercenary
Expert Mercenary
Posts: 988
Joined: Thu Jun 15, 2006 1:02 am
Location: Somewhere in the vastness of space
Contact:

Post by pyramid »

For masters it is viable to store whatever format is required to rebuild the data files.
Currently we have the following guidelines for masters repo:
1) Original images go here. Format is free, this can be png, jpg or whatever.
2) If more than one image, scripts, or project files are required to build the master image, they should go into the sources subdirectory with _source extension. This can be multiple layers e.g. in a gimp xcf file, or multiple image files, project files, scripts, noodles, or other rarities in a zip.

As far as i can see, this already covers the requirements presented by chuck.

As for data images and textures, due to performance issues DDS is a good compromise. I am not very happy with the compression quality, but certainly appreciate the loading speed and memory usage. Haven't noticed any eye catching artifacts in bases so far though some splash screen images look slightly worse (blocky) with dds than they did before. I don't really see how we can gain much in storage usage when there are roughly 4MB per base being used now in average. The only really interesting point about using jpg in-game would be the aspect of image quality. I can imagine allowing jpegs in very well defined places only (e.g. bases and splash screens) where performance is not a concern. However the impact on video memory should be estimated.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Post by safemode »

they were dds before too. Even worse than now because they were all hardware compressed dds. So dont let the idea of them being dds on the drive psychologically fool you. They're better quality now than before.

slash screens are definitely a place where performance is concerned. Until we thread the graphics subsystem, the time it takes for GL to do it's thing holds up the rest of the loading process. Plus, the jpg versions of the splash screen only barely smaller than the DDS versions.
Ed Sweetman endorses this message.
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Post by klauss »

If performance reasons concern you, placing jpeg where you want quality won't hinder it. Before, when a jpg was encountered, runtime compression was applied (usually referred to as "hardware" compression, though it's not the hardware doing it). Now, since we can store dds where we want dds, runtime compression has been disabled (afaik). I'm positive pngs don't get compressed, and safemode will know whether jpegs get compressed (they shouldn't).
So... if you use jpegs, the only performance hit is that of decompressing the jpeg which, lets face it, is minimal for a handful of images of any resolution.

So, I'd use jpegs for splash and base stuff. High quality jpegs, or pngs. Depending on image contents of course.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
Breakable
Hunter
Hunter
Posts: 95
Joined: Sun Nov 18, 2007 1:19 pm

Post by Breakable »

Jpeg for masters is bad idea, because if you modify and recompress it you will lose quality.
Jpeg for data.4 is a bad idea. They would be reasonable for bases and splash screens, if they would not be converted to dds on the fly when loading - which is not likely to be the case because of how bliting is done (as far as i know), in other case its better to have a compressed dds.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Post by safemode »

jpegs are treated as they used to be, so they still get compressed. and i think they would also get mipmapped and all that jazz

I call it hardware compression because it is the hardware that GL uses to compress things on the fly. GL doesn't do a fallback to software DXT compression of the hardware doesn't support it. It's just not available in that case. So it is most definitely the hardware that compresses the file when you tell GL to compress so and so image to DXT You can tell it to use s3tc, or whatever mode the hardware supports, but we strictly use S3TC. No matter what the method is, the hardware has to support it and the hardware would be doing the compression and decompression, GL doesn't know how to compress or decompress.

Now that aside. I can make jpegs follow the same path that png's do and disable on the fly compression altogether, since now we're starting from compressed and knit picking stuff to not be (the opposite of the way it was before). The thing is, we need to make sure non compressed images dont stay in cache or on the video card after they're used (they'd take up a lot of space). I would also dictate that non compressed images can't be used in situations where it would be mipmapped.

An uncompressed image at 2048x2048 takes over 12MB of ram, system for when it's decompressed and then VRAM when it's loaded to GL. That's 6 times the amount of ram (we dont decompress in either) a DDS image would take of the same size. We need to keep this in the fore front of our minds when we decide to make something not DXT.
Ed Sweetman endorses this message.
Breakable
Hunter
Hunter
Posts: 95
Joined: Sun Nov 18, 2007 1:19 pm

Post by Breakable »

safemode wrote: Now that aside. I can make jpegs follow the same path that png's do and disable on the fly compression altogether, since now we're starting from compressed and knit picking stuff to not be (the opposite of the way it was before). The thing is, we need to make sure non compressed images dont stay in cache or on the video card after they're used (they'd take up a lot of space). I would also dictate that non compressed images can't be used in situations where it would be mipmapped.
When do you think it makes sense to have an uncompressed image in memmory?

The only case I would see is if requires great performance for some reason (is there any case like that)

Jpeg should not be the case if they are used for base backgrounds and load screens.

PS:How do the other games handle it - maybe this problem has some simple solution?
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Post by safemode »

High performance is DDS. It's just not practical to bounce around 12MB textures. Uncompressed would be faster, if you had very small textures only and few of them.


The only reason why anyone is considering uncompressed textures in the game now is to reduce filesystem footprint for textures that aren't used in main gameplay. We're not going to be compressing them in order to offset the performance penalty for having to decompress the native format, and to avoid the performance hit of having to compress to DXT.

Thus, the use of non compressed textures for bases is a size issue, not performance. They're not suggesting it to be faster than DDS. They're saying, that the speed decrease will be moot because of when we use those textures, so we can have a net gain of performance, because the size on disk can be greatly reduced. From ~80MB to around 20MB if they're all 500K or less jpegs.


The only case there if for non dds files is in areas where you cant use dds to any effectiveness (very very small textures) or in areas where we really dont care how long it takes to load (and we can discard the texture after we use it).
I really dont want to see this done to splash screens, because splash screens aren't very much bigger than thier jpeg counterparts, and loading the game is an area where we care how long things take to load.
Ed Sweetman endorses this message.
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Post by klauss »

I disagree about splash screens. And the "hardware" thing.

Splash screens and any picture intended to fill the screen, like backgrounds, and stuff, are better off being uncompressed (in VRAM) because otherwise the loss in quality is noticeable. Just that.

Also, removing mipmapping is not that right. Unless you resample them to the approximate size of the area they'll take on the screen, you want mipmapping to get higher quality interpolation. You'll only be able to discard mipmaps when you know you won't downsample images. Only low res splash screens/backgrounds could potentially be in that situation.

I know your problem. Splash screens are implemented as a randomized .ani. All splash screens get loaded, and if all of them get mipmaps and load uncompressed from jpegs, then yep, the performance hit is significant. But only one of them should be loaded. You do that editing the ANI!

Code: Select all

.3 .3
5 20.0 startRandom,video
Jackal.png
FraternalWar.png
Shapers.png
Jackal.png
FraternalWar.png
Magic!
Now only the current frame gets loaded, and caching is disabled. So they get freed when destroyed. Is that what you wanted?
:D


About the hardware thing. It's not hardware compression. The hardware has only decompression abilities. Except last-gen GPUs, which can only compress in hardware with GPGPU apps like nvCompress (but the driver won't ever). Compression is done in software. The software compressor is part of the driver. The difference with that software compressor and nvCompress and the like is only the amount of work they do to find the closest representation of the image. The driver does things very quickly, but introducing a lot of (unnecessary) error. nvCompress takes a lot longer, but minimizes error. It's a tradeoff, but it's all software.

PS: tested 'video' and it seems it has been broken after so much messing in gfx code. I guess it needs some debugging.
PS2: 'video' has little to do with actual video. It was an early attempt at playing video sequences in the form of a sequence of pics (disabling caching was required, for instance).
PS3: I don't have one. I prefer the Wii anyways. :p
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Post by safemode »

splash screens barely vary in size from DDS to jpeg, They dont need to be decompressed to be in a format understandable by the video card when they're dds. I dont see the point in making them uncompressed. You wont really save any hdd space (there's not only very little difference in size, but there aren't that many splash screens), you might save 2MB total. I suspect you'll see a net gain in load time simply from the jpeg decompression.


We can see a net win with bases because there are so many (50). and many textures are 2048x2048 or so and the size difference for those can be upwards of 1.5MB each. That and we really dont care if it adds time to loading base screens.

Making a dozen textures non-dds to save 2MB of hdd space is not worth it in my opinion.
Ed Sweetman endorses this message.
Xit
Bounty Hunter
Bounty Hunter
Posts: 186
Joined: Mon Aug 06, 2007 2:34 am
Location: Cambs

Post by Xit »

These are good arguments but I assume that in future we will have more splash screens? (well, assuming that splash screens don't become redundant) and that the texture size will increase to accommodate the advances in displays and graphics cards?
Save The Economy
http://vegastrike.sourceforge.net/forum ... hp?t=10605

My boxes: Dual Opteron 280s, Geforce 7600, 2GB RAM, but waiting for a new PSU! grrr...
500 MHz Compaq laptop that gives DC electric burns
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Post by safemode »

when loading the game, even generating the universe, i only see less than 5 screens. when loading a save game, 2
Ed Sweetman endorses this message.
pyramid
Expert Mercenary
Expert Mercenary
Posts: 988
Joined: Thu Jun 15, 2006 1:02 am
Location: Somewhere in the vastness of space
Contact:

Post by pyramid »

There are currently 20 splash screens available in data though they are disabled at this point in time in favor of oblivions 4 load screens, not sure why.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Post by safemode »

yea, but what i mean is that it takes less than a minute to load a save game, and it takes slightly more than 1 minute to generate a new game. While it's good to randomize some screens, you wont be seeing more than what you can count on one hand at a time. And even with 20, you'd only save up to 3MB by moving to jpeg... if we were to use the masters.

There's no net gain there. If the base images were 1024x1024 instead of twice that in many cases, it would be a much harder argument to go non-dds.
Ed Sweetman endorses this message.
ace123
Lead Network Developer
Lead Network Developer
Posts: 2560
Joined: Sun Jan 12, 2003 9:13 am
Location: Palo Alto CA
Contact:

Post by ace123 »

The problem is that most of the splash screens are only shown at startup--and these days with compressed textures, loading is so fast that you can hardly notice these screens.

When loading I think it only uses the three splash screens defined in data4.x/animations/load_screen.ani

Perhaps we can stick all the screens into load_screen.ani, and have it use that animation as well for starting up?
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Post by klauss »

People! Read what I write!

I'm not proposing saving them in jpeg to save disk space (though it's a nice side effect). It's so that they're loaded in uncompressed form to the GL, and we thus get quality improvements. (jpeg compresses a lot artifactless than DDS anytime).
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
charlieg
Elite Mercenary
Elite Mercenary
Posts: 1329
Joined: Thu Mar 27, 2003 11:51 pm
Location: Manchester, UK
Contact:

Post by charlieg »

Quoted for emhpasis :D
klauss wrote:People! Read what I write!

I'm not proposing saving them in jpeg to save disk space (though it's a nice side effect). It's so that they're loaded in uncompressed form to the GL, and we thus get quality improvements. (jpeg compresses a lot artifactless than DDS anytime).
Free Gamer - free software games compendium and commentary!
FreeGameDev forum - open source game development community
Post Reply