Q3Map2 2.5.14 - Where's my stapler?

(ydnar) #1

Q3Map 2.5.14 - I’m gonna need you to come in on Saturday, yeah.

Donate here and get your karma fix for the year. :slight_smile:

Dirtmapping (ambient occlusion) rocks, as does solid lightmap fixes, upped BSP shader/surface limits, and sweet alphaMod volume feature requested by rgoer to arbitrarily set any vertex alpha value. Also new is the skylight subdivision code, producing more uniform sky lighting with fewer lights and speedier compiles.

Download: Win32 - Linux x86

Readme

Download new q3map_alphaMod volume common shaders: http://shaderlab.com/q3map2/samples/common_alphascale.zip

Version history/changes:



2.5.14 (2004-04-09)

- New: -dirty mode courtesy of RaP7oR (dirtmapping/ambient occlusion)
- New: q3map_skyLight code using more uniform angular distribution about
  the sky hemisphere
- New: q3map_alphaMod set N.N
- New: q3map_alphaMod scale N.N
- New: q3map_alphaMod volume - applies all other q3map_alphaMod directives
  to each vertex inside a brush textured with this shader, allowing large
  faded scrolling fire shaders, waterfalls, marquees, explicit dotProduct
  terrain blending control, etc.
- Fixed a bug in alphaMod code where the type of the first alphaMod was
  being used for all subsequent alphaMods
- Lowered vertex-lit surface limits to 999 verts, 1000 was breaking Quake 3
- Tightened up solid lightmap tolerances
- Fixed bug in solid lightmap code where lightmap SD coords were being
  incorrectly set

Enjoy!

y

q3map_alphaMod volume screenshot, demonstrating 3 brushes setting the vertex alpha inside them:

(ratty redemption) #2

arbitrarily set any vertex alpha value…

can we have a more detailed sample usage of this? I hope this is similar to what I was going to request, as I`m sick to death of controlling vertex alpha using alphamaps.

the dotproduct has been much more enjoyable to work with, and if we can use something similar to set vertex alpha values on flat surfaces then this will extremely helpful :slight_smile:

(ydnar) #3

Edited original post with links to the shader scripts/images courtesy of rgoer.

y

(ratty redemption) #4

thanx guys for the sample .shader and editor images, but the previous q3map_alphamod dotproduct2 now seems to be broken :frowning:

pic 1 compiled with 2.5.13

pic 2 same map, same shader file, same .tga alpha channeled images but compiled with 2.5.14

here`s an eg of my dotproduct2 shader


textures/_ratty_terrain/dirt_grass_rock_blend  // grass floor, rock wall, dirt transitions
{
 qer_editorimage textures/_ratty_terrain/shader_images/brown_grey_terrain.tga
 q3map_lightmapsampleoffset 16
 q3map_lightmapmergable
 q3map_shadeangle 178
 q3map_tcmod rotate 33
 q3map_nonplanar
 q3map_alphamod dotproduct2 ( 0 0 0.84 )
 q3map_tcgen ivector ( 512 0 0 ) ( 0 512 0 )
 surfaceparm gravelsteps
 {
  map textures/terrain/dirt_m03.tga  // dirt transition
  tcgen vector ( 0.00390625 0 0 ) ( 0 0.00390625 0 )  // 256
  //rgbgen const ( 0.6 0 0 )
 }
 {
  map textures/_ratty_terrain/shader_images/ratty_mxrock0b.tga  // grass floor
  alphafunc ge128
  alphagen vertex
 }
 {
  map textures/_ratty_terrain/shader_images/ratty_cliff_m05dcon.tga  // rock wall
  alphagen oneminusvertex
  alphafunc ge128
 }
 {
  map $lightmap
  tcgen lightmap
  blendfunc filter
 }
}

in the 2nd pic, it appears on the rock faces that mainly my first layer is drawn, with only a tiny amount of the 2nd or 3rd layers.

the grass on the ground and hill top are a separate dotproduct2 shader, again mainly the first layer of that apears to be drawn :frowning:

if we cant cant use the previous alphamod dotproduct2, then how do we achieve similar blending as seen in my 1st pic with the new alphamod?

(ratty redemption) #5

can we also have a sample .map of the new alphamod blends?

as I cant figure out how to use them, I made a box map with each of the 4 common_alphascale shaders, pasted separately onto simple cubed brushes, and they didnt shows up in game, although there were no compile errors.

and how come 3 of 4 the common_alphascale have the same properties? shouldn`t their scales be different to reflect their names?

textures/common/alpha_75
{
	qer_trans 0.5
	q3map_alphaMod volume
	q3map_alphaMod scale 0.75
	surfaceparm nodraw
	surfaceparm nonsolid
	surfaceparm trans
}

textures/common/alpha_50
{
	qer_trans 0.5
	q3map_alphaMod volume
	q3map_alphaMod scale 0.75
	surfaceparm nodraw
	surfaceparm nonsolid
	surfaceparm trans
}

textures/common/alpha_25
{
	qer_trans 0.5
	q3map_alphaMod volume
	q3map_alphaMod scale 0.75
	surfaceparm nodraw
	surfaceparm nonsolid
	surfaceparm trans
}

textures/common/alpha_0
{
	qer_trans 0.5
	q3map_alphaMod volume
	q3map_alphaMod scale 0
	surfaceparm nodraw
	surfaceparm nonsolid
	surfaceparm trans
}

the middle two seem to be written wrong to me?

(G0-Gerbil) #6

New: -dirty mode courtesy of RaP7oR (dirtmapping/ambient occlusion)
Any chance of a sample? The techy phrase is pretty much meaningless to me :smiley:

(rgoer) #7

http://www.quake3world.com/ubb/Forum6/HTML/027301-16.html?#548

(rgoer) #8

btw, dirtmapping has become much “cleaner” since that dev build.

(badong) #9

Seems you’ve been missing a lot of work lately.

(G0-Gerbil) #10

I still don’t get what dirtmapping is - the second pic just looks a bit darker, that’s all.
I can possibly see the slightest ‘less uniform’ lighting, but in effect that’s just a faint noise added to the lightmap (which I already do on occasions, eg on terrain) and may just be jpeg artifacts anyway.

I’m obviously still missing something…

(rgoer) #11

http://google.com/search?q="ambient%2Bocclusion"

(rgoer) #12

Basically, traces are made outward from each dirtmapping sample to determine how much it is “exposed” to light sources. The less exposure, the darker a sample becomes. Samples that are tucked in nicks and crannies will get pretty damn dark. Samples out in the open stay bright (as bright as the un-dirtied lightmap would be for said sample). When you multiply this ambient occlusion pass into the rest of the tex+lightmap combo, whatever it is you are lighting/dirtmapping ends up looking dirty/grimy. Hence the name.

(ratty redemption) #13

sounds cool and does it add much time to the compiling?

also does anyone know anything about the seemingly broken alphamod dotproduct2 code?

if this isnt a bug, then I have several months of hard work and dev wasted if I cant easily emulate the results in 2.5.14 …either that or I stick with 2.5.13 which worked perfectly for those blending effects, but then I miss out on the new lighting code :frowning:

(Davros) #14

so does this mean its possible to control where textures blend together on modelled terrain, regardless of the steepness of the terrain? the terminology baffles me :eek:

here is a pic of my terrain http://www.torchy.net/misc/max.jpg i have large areas where i have one texture and it would be nice to add some other textures in there to break it up a little.

(ratty redemption) #15

yes, thats what weve been asking ydnar to implement with the alphamod blending so it`s independent of the slopes angles to control transparency.

and manually I`ve been blending on any angle surfaces using alpha channel tex to cover up the seems between different shaders, which I can show you how to do, although it is quite a lot of work, hence hoping ydnar could help automate the process.

and if you can move and add verts into your modeled terrain, as well as assign different shaders to parts of the modeled terrain, then I think my method would work on it… I`ll ul some pics of how I do it if anyone is interested?

(ydnar) #16

Uh, ok. I’ll look into the busted alphaMod dotProduct2. Sorry if that’s a bug… :slight_smile:

As for the shaders all having q3map_alphaMod scale 0.75, that’s an error. They should have 0.25, 0.5, 0.75 respectively.

y

(ydnar) #17

@ratty: I found the bug, it was a stupid mistake I made when overhauling the alphaMod code. If you download the development build it’s fixed:

http://akiba.shaderlab.com/GtkRadiant/tools/quake3/q3map2/Release/q3map2.exe

Also, I noticed your shaders used a subdirectory “shader_images” for the textures. This is a Bad Idea. Quake and the tools have a 63-character limit on file/pak paths and your texture paths are dangerously close to breaking it (61 and 63 chars respectively). Just put the images in the directory like normal textures.

y

(G0-Gerbil) #18

I’m still confused over the dirty mapping.
Seems to me it’s just a way of generating more accurate ambient lighting - but surely that’s just normal diffuse lighting??
I mean, there’s no such thing as real ambient lighting in real life, so what’s the shortcut?
The tutorials mention the benefits of blending a rendered lit scene with a real life scene, but of course that’s a moot point for this, not to mention the other benefit of static scenery = quick renders from different viewpoint.
Now, if it’s QUICKER then that’s a benefit I can understand without worrying unduly, but since it’s supposed to be more realistic, well, why?
EG take this quote:

For any given scene, you render a pass or texture map that determines how much ambient light hits any given point on a surface. i.e. a lot less light illuminates my armpit than the top of my head.
But it’s not ambient light - your armpit is darker because less light hits it, the ‘light’ being a combination of direct light and reflected light (both specular and diffuse).
So umm… dirty lighting is a ‘shortcut’ way of generating more accurate ambient lighting?
I thought radiosity was a good way of doing that (reflected diffuse lighting model) - granted radiosity is slow, but it’s coloured, which from the examples given I don’t think dirtmapping does…
Ho hum :smiley:

(ratty redemption) #19

@ydnar, my map is working perfectly again, thanx man! :smiley: :banana:

and I liked to keep the shader images in a separate directory to the shader names, but I could abbreviate the path names… saying that, I`ll try moving them all into their normal directories.

(rgoer) #20

Gerbil:

During production of Star Wars: Episode II, ILM didn’t have time to render a real radiosity pass for every frame of CG they needed. Where they could get away with it, they used a key/fill/highlight setup, an additional “bounce” light to approximate the predominant color of whatever the radiosity light would be for a given scene, and used an Ambient Occlusion pass to sell the whole effect as true radiosity. You know the old mantra of CG: the look is all that counts.

Since we have real radiosity with Q3Map2, and we have time to impliment it when we compile our maps, we don’t really need to use AO to simulate GI. AO does have another effect, though, in that if you add a little noise to the AO pass and multiply it on top of an already-affected-by-radiosity lightmap, a given surface will be made to look “dirty” or “grimy.” Like a statue that is tough to clean and is very old or something.