0.9.0 textures todo list?

[Udi]

In OA, it is:
TGA > JPG > PNG > PCX > BMP

Thanks, so we should use JPG where possible because of the filesize or is TGA loading faster?

[fromhell]

JPG in release pk3s for when an alpha channel doesn't exist. Keep the original TGA somewhere, like maybe in a upper folder 't.tga', or '.lossless' where I can automatically exclude it in the PK3 building process.

(I realize, I should have done this in the first place.)

[anyone]

I have no idea how you organize your work, but is it normal that very few textures are striked although they're present in OA? Do they need revisions to be considered done?

Beside that, just a small suggestion (for what it's worth): parent textures sorting (could take plenty of time); When you check the original game, plenty of textures are derivative from basic textures or use common patterns. Maybe sorting those stuff would help to make the base assets (no directly used in game), which could speed up the process to create final textures. For instance the skulls in baseboard09_e, baseboard09_e2, baseboard09_f, baseboard09_f2 but also window_a_bottom1, iron01_p, iron01_p2... Or the pattern in metalciclesrust, metaltech16gold, backtower1, archxiandm1dblack, metaltechfloor01final, xiandm9doore2 and so on...

[Udi]

I have no idea how you organize your work, but is it normal that very few textures are striked although they're present in OA? Do they need revisions to be considered done?

Beside that, just a small suggestion (for what it's worth): parent textures sorting (could take plenty of time); [...]

My current goal is rather simple, I only focus on one original Q3 map at a time. When it's ready I will make a small video to increase OA's popularity among both players and artists. I want to make it as fast as I can, so I leave the ready replacement textures as they are. The only exceptions so far are the metalfloor texures, because nihilus released a nice looking curcuit pattern, so I remade those shaders and textures. When I'm ready I will release a pk3 with all the new stuff so you can test it before I post it to the SVN commits.

The parent textures sorting is a good idea, but I will skip it because of the one map at a time progress. I make as raw images as possible and always keep all the image layers, so I can remix and modify the similar textures later (and since it's open source those will be released too). Of course if I have one texture ready I will see if there's another one with a similar filename, and will do also that, but won't go very far beyond the requirements of the current map.

Is there a coding standard for shader files? Like opening brackets on new line/same line, spaces instead tabs, blendfunction shorthands where possible, texture names defined with or without file extension, UTF-8 or something more basic, CR+LF/LF/CR, etc.? First I thought I will define the texturefiles without the extension, but if OA has TGAs, my JPGs won't be loaded, so I will have to make an extra installment to delete the TGAs I want to overwrite.

[Neon_Knight]

http://www.heppler.com/shader/

What about that?

[Udi]

http://www.heppler.com/shader/

What about that?

Yeah, I use that for the commands reference, but what I'm asking is more practical, like:

This kind of standard:

Code:

textures/sfx/xmetalfloor_wall_9b
{
qer_editorimage textures/sfx/metalfloor_wall_9b.jpg
q3map_lightimage textures/sfx/metalfloor_wall_9bglow.jpg
q3map_surfacelight 60
{
map textures/sfx/metalfloor_wall_9b.jpg
rgbGen identity
}
{
map $lightmap
rgbGen identity
blendFunc GL_DST_COLOR GL_ZERO
}
{
map textures/sfx/metalfloor_wall_9bglow.jpg
blendFunc GL_ONE GL_ONE
}
}

Or rather this:

Code:

textures/sfx/xmetalfloor_wall_9b {
  qer_editorimage textures/sfx/metalfloor_wall_9b
  q3map_lightimage textures/sfx/metalfloor_wall_9bglow
  q3map_surfacelight 60
  { map textures/sfx/metalfloor_wall_9b
     rgbgen identity }
  { map $lightmap
     rgbgen identity
     blendfunc filter }
  { map textures/sfx/metalfloor_wall_9bglow
     blendfunc add }
}

Both are correct and have the same effect, but have different format.

[Neon_Knight]

I would use the first.

[chaoticsoldier]

The second looks much less confusing to me, even though they contain the same information.

[andrewj]

In my own shader files I use the first format, { } on their own lines and at the same indent level.  I use two space indents and leave off the extension on image names, and write 'rgbGen' instead of rgbgen (etc).

[fromhell]

I'd use the second only to hastily make detail texture assignments

[fromhell]

(I realize, I should have done this in the first place.)

50% resizing all textures, as 8-bit PCX (Unreal standard) totals the compressed size of it all to 18.1MB. Big savings from 114MB there, lower quality though, not to mention no alphas preserved.

I will need to do some further experimentation on size.

[Udi]

50% resizing all textures, as 8-bit PCX (Unreal standard) totals the compressed size of it all to 18.1MB. Big savings from 114MB there, lower quality though, not to mention no alphas preserved.

I think most of the compression comes from the TGA -> PCX switch. I just wonder if the alpha channel information could be stored in a separate black/white or grayscale pcx and added again with shaders...

[fromhell]

Darkplaces recently added a similar loading pipeline. I'd say its possible, just add it in renderer where the images get loaded and parsed, look for _alpha and copy its grayscale value over to the alpha when loaded as a 32-bit texture.

[andrewj]

I just wonder if the alpha channel information could be stored in a separate black/white or grayscale pcx and added again with shaders...

Shaders cannot do that.

I think fixing the TGA loader to supprt type 9 files (RLE COLORMAPPED) would shrink that 18MB even more, perhaps as low as 10MB (114 / 4 / 3).

Also TGA colormapped files theoretically support RGBA colors, i.e. alpha values, in their palette, but I'm not sure whether programs like the GIMP can create them.

[Udi]

Shaders cannot do that.

I think I found something which _seems_ to accomplish what I was looking for, but I lack the knowledge how shaders really work, so please check if it's a viable solution. Basically what this method is about is that, after a blendFunc GL_DST_COLOR GL_SRC_ALPHA step another blendFunc filter will "mask" the second texture according to the first greyscale alpha texture. I've tried it with two transparent textures, and the results seem to be the same.

First example is the metafloor_wall_14_specular texture (OA doesn't use it yet, but you can find it in q3dm16).

The separated pcx solution is a little bit darker, according to the heppler reference, it's due to the additional blendFunc. The shader definitions used (left the transparent TGA, right the two PCX):

Code: textures/base_wall/metalfloor_wall_14_specular { qer_editorimage textures/base_wall/metalfloor_wall_14 { map $lightmap rgbgen identity } { map textures/base_wall/metalfloor_wall_14_specular rgbGen identity blendFunc GL_DST_COLOR GL_SRC_ALPHA } }

Code: textures/base_wall/metalfloor_wall_14_specular { qer_editorimage textures/base_wall/metalfloor_wall_14 { map $lightmap rgbgen identity } { map textures/base_wall/metalfloor_wall_14_specular-alpha.jpg rgbGen identity blendFunc GL_DST_COLOR GL_SRC_ALPHA } { map textures/base_wall/metalfloor_wall_14_specular-color.pcx rgbGen identity blendFunc filter } }

Filesizes (512x512px):
metalfloor_wall_14_specular.tga: 1.0 MB
metalfloor_wall_14_specular-alpha: 248.7 kB (8bit PCX) or 194.9 kB (grayscale JPG)
metalfloor_wall_14_specular-color: 259.5 kB (8bit PCX)
Sum: 1024 kB vs. 508.2 kB

The another example is the cybergrate2 shader, which you can find on the railgun platform of oa_ctf4ish. It's trickier than the previous, because only the metal grid was transparent, the electricity effect wasn't, but due to the method both had to be made transparent. The result:

The PCX solution is a bit ugly on the edges, but don't worry about that. Shaders used (left original, right new):

Code: textures/base_floor/cybergrate2 { surfaceparm metalsteps cull none { map textures/sfx/portal_sfx_ring_electric.tga tcmod scroll 1 -1 blendfunc add } { map textures/base_floor/cybergrate2.tga blendFunc blend rgbGen identity } { map $lightmap blendFunc filter rgbGen identity } }

Code: textures/base_floor/cybergrate2 { surfaceparm metalsteps cull none { map textures/sfx/portal_sfx_ring_electric-alpha.pcx tcmod scroll 1 -1 blendFunc GL_DST_ONE_MINUS_COLOR GL_SRC_ALPHA } { map textures/sfx/portal_sfx_ring_electric-color.pcx tcmod scroll 1 -1 blendFunc filter } { map textures/base_floor/cybergrate2-alpha-mono.pcx rgbGen identity blendFunc GL_DST_ONE_MINUS_COLOR GL_SRC_ALPHA } { map textures/base_floor/cybergrate2-color.pcx rgbGen identity blendFunc filter } { map $lightmap blendFunc filter rgbGen identity } }

Filesizes (256x256px):
cybergrate2.tga: 132 kB
cybergrate2-alpha: 5.1 kB (8bit PCX) or 3.6 kB (1bit PCX)
cybergrate2-color: 35.7 kB (8bit PCX)
Sum: 132 kB vs. 40.8 kB

Here's a test package so you can try this at home: http://udionline.hu/fajlok/z_pcx-experiment.pk3

The filesize compression is more than 50% in both cases, but of course the shader steps require more computing. Is it worth to deal with this method?

[andrewj]

I stand corrected

I think though that sacrificing rendering speed for smaller file sizes is a bad trade-off.

PNG also supports palettes with alpha values, and ioquake seems to support it (looking at the tr_image_png.c code).  So for images with "simple" alpha (always 255 or 0) then PNG is the way to go.

[fromhell]

Hmm. If that's the case, then some sort of batch process that nicely puts the alphas like that on map textures in pngs on palettes would be sufficient.

[Udi]

The first package is ready with textures fully covering q3ctf4 as Mr. January. 71 textures are done, most of them brand new, and some of them replacing already existing textures. I believe they can compete with the Q3 textures, but the creator is always corrupt, so be my judge:

Screenshots: (1), (2), (3), (4), (5), (6), (7)
Video: missing-textures1_v1.ogv
Package: z_missing-textures1_v1.pk3 (tested with 0.8.5 RC1)
Sources: missing-textures1_v1_src.zip
License: GPLv2, both the package and sources contain a readme file with a detailed credits list

Since there are some replacement textures aswell, both oa_ctf4ish and wrackdm17 are also influenced. Oa_ctf4ish even has an overburnt texture since the previous was a semi-alpha one, but the Q3 one isn't. So it probably needs a recompile, but since the tribute maps will be dropped, it's not a big issue. Q3dm17 got also pretty close to the 100% finish, I will do it in February next to the webdesign rework. I also noticed, that my perl script does not extracts all the textures, until I fix it, you can use the clanarena resources. And I will also do some other shader fixes for 0.8.5, that's all I've got on my OA todo list.

Any feedback is welcome. We have plenty of time testing and polishing it, since it will only be committed after 0.8.5, and some shader filename cleanup.

[Graion Dilach]

Looks nice. Definitely.

I'm not a CTF player, but I've tested the pack on q3dm16, dm17 and dm19. Firstly I didn't like the launchpad's base on dm19 (caused by atech1_e.jpg) but then I checked them in my brother's Quake 3, and it turned out that I've became used too much to Jack_Thompson's GPL pack. Maybe the yellow base should be a bit darker-greener on that one.

Also, I got some "WARNING: unhandled AL error. Invalid value." in the console on those maps.

[Udi]

The atech1_e caused a lot of headache, I've tried to improve that one before the release, but it will be definitely reviewed in the next pack with the other atech textures.

The unhandled AL error is coming from OpenAL, not the texture pack.

[Graion Dilach]

Oh, sorry the OpenAL thing, then.

I think the... oh, whatever... Az elrendezés kiváló, igazából a sárga NYÁK tud csak zavaró lenni benne, mert mindegyik lebegőn is a sárga virít ki.

For the others... that yellow base thingie's too bright after a test run on dm19.

[Udi]

Hu: Köszi, tényleg a sárga felületek rontják el. Már az elején elcsúszott a koncepció, mert abban gondolkodtam, hogy ez egy számítógép belseje, tele csipekkel, kondikkal meg mi egymással. Aztán a q3tourney6-nél láttam, hogy a préselő gép teljes oldala ezzel van borítva, akkor jöttem rá, hogy ez inkább valami gőzgép csupasz külseje. Utána próbáltam átalakítani, de nem sikerült tökéletesre, a következő kiadásban jobb lesz.

En: Thanks, it is really the yellow things which make it bad. The concept was faulty from the beginning, because I thought that it displays a computer from inside, full of chips and etc. Then I saw on q3tourney6 that the whole smashing machine is covered with it, and I realized that it is more like an uncovered steam machine than a computer. After that I tried to change it, but it ain't perfect, it will be better in the next release.

[Udi]

I can't finish the next missing texture package in March, but I've made a teaser screenshot to show some progress. Available at 1280x800 (my native resolution) and 1920x1080 (forced on Windows).

[pulchr]

looks good!

[BCH32]

I'm just amazed by tha quality of the overall work on texture !!!
The

Package: z_missing-textures1_v1.pk3

look very nice !