I tried my hand at textures a few nights ago:

http://killpixel.com/textest.jpg

From a picture of a rusty baking pan, I cut out horizontal bars and applied bevel/emboss to each one.

The cool part is you just use the eraser to make the worn/distressed bits and the bevel/emboss as automatically applied.

Slap on some grime and blend as you wish, shrink, sharpen, adjust hue/saturation and brightness contrast, index to quake palette and BAM, speedy textures.

This set took about 1.5 hours total.

Now that I know how to make textures I'm going to experiment with less generic designs. 

Beautiful! You might want to team up with http://forums.inside3d.com/viewtopic.php?f=17&t=5442 , which looks super promising. 

Really interesting and nice texture set !

Keep it up ! 

Standart Photoshop effects such as Bevel and Emboss are cool for some quick results. Although it's quite important to not rely on them too much. Sometimes they can be a bit too obvious.

Ah, Inside3d. I noticed it's quite hard to get there. After around 2 months of waiting I finally gave up hope that my account will be activated in the current decade. 

@Spirit, thanks!

@JPL, for the amount of time, thought and effort that went into them I think they turned out pretty good.

@dwere, agreed. However, using any effect or method injudiciously will look amateur.

If this was anything more than "learn how to make textures" I would have fixed the glare atop the "1138" sign to dim as it moved away from the light source, among other things.

I also understand these textures are about the easiest to make: Simple, geometric shapes with a noisy surface in shades of brown... kinda hard to mess that up. 

dwere: Your account should be enabled now. 

Why, thanks! 

Well, i�ve been waiting much longer now for a account there, and gave it up finally.
My questions were answered without account.

@KillPixel Cool textures you made there, i like the rusted pan "approach". made me smile. 

dwere, I fixed the rendering glitch for your model: http://sourceforge.net/p/quakespasm/patches/19/

I'd like to ask on inside3d if the change I made is reasonable, I basically just randomly removed a 0.5 offset from gl_mesh.c, and the results looked good :-)

KillPixel: nice start on the texture set. 

Interesting.

They probably added this offset for a reason. But no matter what the problem was, their solution seems rather hacky.

Thanks for bringing attention to this oddity. 

my guess is 0.5 puts a vertex on the center of a pixel, rather then the vertex being on the corner of 4 pixels. I can't say why it's there unless it was to emulate winquake, and obviously you're saying it doesn't. 

http://i.imgur.com/AJIHWYpl.png 

 

Bear in mind you're gonna make some people unhappy by changing that 0.5 pixel offset - for example sock took advantage of it on some of his models to create "half-width" highlights on a skin at double the resolution the skin size normally allows details. The Quoth .mdl format ammo models are also textured with the assumption that UVs sit at the centre of the pixel - which prevents them being a pixel perfect match to the bsp versions, but they're gonna be a whole pixel adrift on the right hand edge after the patch.

If you say it's closer to winquake then that might justify it, but just be warned that the GL rules might have become the defacto standard in the mean time...even the software renderer in QME uses the centre point. 

that makes a huge difference. 

God, I hate GLQuake. 

Yeah, I guess glquake's behaviour for the texture alignment is probably more of a de-facto standard than winquake's at this point 

This "different standarts" situation is rather sad. It pretty much eliminates the idea of pixel-perfect detailing. Even if you align everything for one engine, it will look like ass on another. 

 

Runic Monster 

Sock working on a quoth map?! Nowai 

Keep it burning! 

This "different standarts" situation is rather sad

I feel like I just had a discussion with someone about this.

also: yay sock 

if every GL-based engine uses the 0.5 offset, and QME (the only native authoring tool for quake models?) uses the same offset, then it seems like this is probably worth keeping.

Probably if you want to "fix" this you should have a cvar that can restore the behavior of all other GL engines, since a lot of content has been made now with qME and tested in a GL engine. In fact what content HASN'T been made with qME? 

Yeah, glquake and winquake are just incompatible in this small way. I'd give the tiebreaking point to glquake, only because winquake alias rendering has a bunch of artifacts when it renders far away models and large polygons - the distortion is very high. It's harder to make the case for an exact standard based on an inexact renderer - even though it has seniority.

Disclaimer: I may be biased, on account of having carefully accounted for the glquake behaviour on several models and tools, not knowing that winquake behaved differently.

ps: Loving those force-field walkways sock!