originally posted by [AF]Haste:
if you need to line a model up with a non-axial brush face, you can always use a little trigonometry to figure out the exact rotation. if you have a calculator with arctangent (atan or tan^-1), you can use this equation:
angle = atan(y / x)
where “y” is the y extent of the brush and “x” is the x extent. make sure you get your answer in degrees rather than radians. if “x” is zero, your answer is 90. and since models are not always oriented with their backs to the x axis, you’ll probably have to add 90, 180, or 270 to the angle to get it right.
it’s not that complicated, really - and you always line it up exactly right.
(need more math on these forums...)

AF-haste> recall in your surface inspector (highlight one face and press “s”), the default x and y texture scale are both 0.5. that means, for both the x and y directions, one texel (texture pixel) takes up 0.5 game units. (in two dimensions, you can fit four texels into a 1 game unit squared surface.)

ydnar> if you use r_clear 1 sparklies are easier to spot

fog:
it won’t behave in the correct way if you apply nodraw. just make a block of fog, textured on all sides. make sure only one side is visible otherwise it will b0rk, and make sure it is always perfectly square or rectangular, you may not use the clipper tool.
terminal

the reason for this is that the first brush side in the map file determines the contents. personally, i make all fog shaders nodraw and then use another set of brushes textured with nodraw + a fog surface shader to make the surface. this cuts down on overdraw a bit, especially in large maps with complex geometry cutting into fog volumes.

y

there are 2 primary methods of using a texture’s alphachannel for transparency/masking
alphaFunc and blendFunc

alphaFunc
used when you need a masked texture, either fully opaque or fully transparent. this is usually faster than an alphablended pass, as the destination pixel is not part of the equation. to use, simply add alphaFunc (gt0 or ge128) in a shader stage. if you wish to do subsequent passes, such as a lightmap, add depthwrite to the alphaFunc stage and depthfunc equal to the following stages.

the parameters gt0 and ge128 specify how the alpha channel is interpreted for masking. they are interpreted as greater than zero and greater than or equal to 128. since the alpha channel is a single byte, it has a value of 0 (transparent) to 255 (opaque). gt0 will make anything that has a non-zero alpha value opaque. if you have a complex alpha channel, this will produce stair-stepping artifacts. ge128 applies the minimization/magnification filters to the texture (depending on whether mipmaps are used) and then uses the resulting alpha value as the decision factor, producing “rounded” edges on the alpha mask.
note: since pixels are either fully opaque or transparent, shaders using alphaFunc can be sorted and rendered in mixed order with normal opaque shaders. this is especially apparent with complex map models with masked textures such as trees.

blendFunc
this is used when soft, semi-translucent blending is required. the blendFunc parameter takes two forms, longhand using openGL blending equation names, and a shorthand form, which i will not cover here. the general form for doing a simple masked/blended stage is this: blendFunc gl_src_alpha gl_one_minus_src_alpha. the first value, gl_src_alpha, is the source blending factor (the texture) and the second value, gl_one_minus_src_alpha, is the destination blending factor (the frame buffer).
the blending equation is simply dst = src * src_factor + dst * dst_factor.
if you work out the math for the two extremes, fully white or black alpha, you see how transparency is achieved. unlike alphaFunc, the blending factors are treated in the range of 0 (fully transparent) to 1.0 (fully opaque).
there are all kinds of other nifty blending tricks you can do, play around with it until you come up with an effect you like.

y

tcGen vector ( 0.001953125 0 0 ) ( 0 0.001953125 0 )
tcMod transform 1 0 0 1 -0.5 -0.5
tcMod rotate 20
if you sync that up with the spinning spotlights, and add a twin-blob texture with blendFunc gl_dst_color gl_one on the floor/walls below the lights, you can get a dynamic light on the map.
it’ll be centered about the origin, projected over 512 units in the x and y directions, spinning at 20 degrees per second.
reorder the tcMods can you can project a static image onto a rotating entity too...
yes, I’ve tested this, and no, i won’t explain further.

y

ydnar> linear lights don’t affect lightgrid too well, i suppose.
jer> linear is the falloff of the light, isn’t it? nonlinear would be continued lightvalue from center to end
ydnar> non-linear is q3a default. 1/distance squared
af-haste> like in rl
ydnar> which is more or less realistic, except there aren’t point lights irl

ydnar> ents will bounce light in radiosity, btw
ydnar> so doors/plats/bobs will reflect light
{wf}shadowspawn> can you make an ent cast a shadow
{wf}shadowspawn> i can’t think of a reason to, but just wondering if you could
ydnar> was thinking about adding in arbitrary shadow generators
{wf}shadowspawn> its not like the shadows would move after a door opens so it would be odd
ydnar> well, things like the game models in wolf, where the trees aren’t compiled in. those would be good candidates for shadow casting ents

bytenik> ************ error ************
bytenik> loadtga: only type 2 (rgb), 3 (gray), and 10 (rgb) tga images supported
bytenik> how do i know what file died?
djbob> check the ones you changed. sounds like a shader error
bytenik> i don’t quite remember which one i changed
djbob> did you include any .jpg endings on any texture references? they should all be .tga, even if the file is actually a .jpg
bytenik> in the shader file?
djbob> yeah
bytenik> i thought that was a bug in q3map...
djbob> no...
bytenik> why’d they do that?
djbob> because .jpg files were a late addition to the engine, so they probably didn’t want to have to go to the trouble of changing lots of stuff
bytenik> do i use .tga for the qer_editorimage key or .jpg?
djbob> .tga always
bytenik> no wonder I’ve never gotten a custom shader working in my life. =p

cloudscapes> question from a shader noob: what do i modify in this script so that my 512x512 texture takes up, say, 1024x1024 game units instead of 512x512 game units?
ydnar> q3map_tcGen ivector

dotExE> how can you set the “score” view of a map (the one that’s shown with the scores in the end of a game)?
ydnar> intermission entity
ydnar> with a target
dotExE> hmm... okay

ydnar> btw. try r_showtris and r_lockpvs. that lets you see the larger “meta” surfaces.
ydnar> btw. if you have two brushes next to each other, with a shared plane with the same texture on it, they’ll get merged into a metasurface. but, if the texture alignment between the two brushes is different at all, then there will be duplicate verts.
ydnar> aligning coplanar same-texture adjacent faces is a good thing even if they “appear” aligned, the offset might be different by texture width/height, making the effective alignment different.

jer> << hex editing tree models to use new texture
jer> arg
hro> jer, use milkshape
jer> it’s true... i could
ydnar> are they misc_models or game_models? you should add surfaceparm alphashadow to them, and a q3map_lightimage with a blurry shadowmask image alpha channel.
jer> along with making these near-black textures brighter
ydnar> you can convince q3map to produce some really nice results
jer> hmm, milkshape doesn’t recognize these md3 material
hro> you have to reassign them.
jer> yeah
jer> they aren’t even created though
hro> no need to remap the texture
jer> so I’m wondering if the texture mapping will be the same
hro> you sure you have textured on?
ydnar> md3s have uv-mapped textures
ydnar> will work regardless of texture size
jer> i mean aligning up these alpha branches to their appropriate quads
jer> looking at the texture coordinate editor is insane
jer> heh
ydnar> huh?
ydnar> ah, retexturing the md3
jer> yeah
jer> there are polygon rectangles that have alphachanneled textures lined up to go to the trunk

ydnar> laerth i actually do some manipulation of your map’s offset values. i mod them by the texture size. so if they appear aligned in radiant, they should be snapped just fine in q3map.
ydnar> mod = integer divide remainder
ydnar> 384 % 256 = 128
ydnar> for instance
laerth> ok
laerth> what’s the bsp switch to view the meta surfaces?
ydnar> -debugsurfaces
ydnar> try -debugportals too

ac3-jerk-3j> why does q3map_backsplash 0 have errors?
ydnar> ac3-jerk-3j you did add q3map.shader to your scripts dir, right?
ydnar> ac3-jerk-msg me the shader
ac3-jerk-3j> believe so
ac3-jerk-3j> k
ydnar> oh sorry
ydnar> it needs a 2nd value
ydnar> distance
ydnar> read the shader manual
ydnar> or use a smaller q3map_lightsubdivide
ac3-jerk-3j> k