Q3Map2 2.5.14 - Where's my stapler?

(ratty redemption) #21

so in that sense, can this be also be used as a kinda bump mapping to make surfaces appear rougher then normal, or is the effect too subtle for that?

I know bump mapping should have shadows being cast away from light sources, but if they arent deep bumps then Im guessing they also could make a map surface look dirty?

admittedly I haven`t used any of this kinda lighting yet in maps, actually not since I used to do 3d modeling, animation and rendering about 10 years ago, so I am rusty as the various effects and how they work.

plus some of this technology is new to what I worked with, although it is very cool more of the old effects which took days or weeks to render, are now showing up in our game engines and with relatively very little compile time :slight_smile:

(RaP7oR) #22

Wibble !

Ok, so since there seems to be a lot of confusion about what Ambient Occlusion / Dirtmapping actually is, heres a little explanation.

What happens is this :
Each surface sample ( in our case a luxel ) checks how much it is occluded by neighbouring geometry.
Depending on amount and distance of occluding geometry, the sample will get darker.

This technique has been around in VFX for some time and is used to kind of fake global illumination shadowing.

Heres a list of some control-switches that you can use for controlling the dirtmap-calculation :

( all of those go into the -light phase, and only work if -dirty is present )
-dirtmode x
x = 0 or 1
0 Uniform Mode ( default )
1 Noise Mode
This controls the mode in which the dirtmap is calculated. The Uniform Mode tries to create a very smooth looking dirtmap, while the Noise Mode is, uh, noisy.

-dirtdepth x
x = max Depth of Occlusion-Checking in Game-Units ( default 128 )

-dirtscale x
x = 0 - ?? ( default 1 )
This scales the “darkness” of the dirtmapping-effect. Floating-point values are allowed here.

Thats all i can pull out of my head right now :slight_smile:

(seremtan) #23

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.

Most of these new features are baffling to me, but this fading scrolling effect sounds ace and just what I could use right now. Any chance of a small sample map to illustrate usage of these new features for the technically retarded (i.e. me)?

(ratty redemption) #24

with embedded-grayscale-alpha-channeled tex, which water in quake games traditionally uses, the alpha channel would scroll with the tex, so limiting the type of blends we could do with it.

eg, a waterfall could have faded edges but the top and bottom of the scrolling tex would have to be opaque, so where the waterfall touched the pool of water, there would be an obvious seam… although that could be partly hidden by mist at the bottom of the waterfall.

alphamaps which use indexed-color-bitmaps to set vertex alpha on the brushes or mesh themselves, allowing us to have a scrolling tex along with it`s alpha channel, blended with the non moving vertex alpha.

eg, a waterfall using this method, could have the sides as well as the top and bottom of the falling water translucent, so there is no obvious seam where it meets the pool.

also a stream running along a ditch could have translucent edges, and where the flowing water meets other bodies of water, the blends can be very smooth.

this is how I did my soft edge water, but the bitmaps were a real pain to make, especially with non axial meshes, as it`s almost random and very difficult to map the pixels on the bitmaps to the where the vertexes are on the meshes.

hopefully what ydnar has now implemented, is a more predictable and reliable way to set the alpha on brush or mesh vertexes.

I know it has something to do with painting special shaders onto our brushes in radiant, like we do with the dotproduct blends, but unlike dotproduct, this new blending won`t depend on slopes to set the alpha.

so another eg, would be to have a large flat patch of grass, and blend in some dirt tex or perhaps a winding road, again without the need to use alphamaps, well I`m hoping that is the case :wink:

but I too need to see a sample map of how this is set up, as I don`t have time to just experiment like I did with the alphamaps.

(G0-Gerbil) #25

So erm, instead of dirty mapping eating up my compile times, I could just take the lightmaps into photoshop and add a bit of noise, which is what I’ve been doing before then for terrain? :slight_smile:

(rgoer) #26

Jesus Gerbil just make a tiny test map and try out the -dirty switch you’ll instantly see what it does ;^)

No it’s pretty different from just adding noise to lightmaps. Some early tests were done with a similarly simplistic algorithm, and it looked mad shitty.

(rgoer) #27

btw here (20 kB) is a small demo map that shows how to use the volume alpha shaders.

edit: this map is Q3:A

(ratty redemption) #28

wow, thanx to ydnar and rgoer, I dont think Ill ever have to touch the evil alphamaps again, these alphamods are excellent and very easy to use :smiley: :banana:

basically we can create brushes of any size, I used small cubes of 16x16x16 size, and paint them with one of the new common_alphascale shaders, covering every face of the brush.

we then position them so they enclose another brush or mesh`s edge or vertices.

eg, a larger cube brush with two of these alphascale brushes covering two of the larger brush`s corners.

we can then use multiple alphascale shaders to set different levels of translucency.

eg, one corner could have a alphascale brush using alphascale 0, while the opposite corner could be using 0.5

then in game the larger cube would have one corner (vert) fully transparent while the opposite was 50% transparent, and the other corners not inside alphascale brushes would be left at full opaque (0% transparency)

note: for a larger brush or mesh to be affected by the alphascale brushes, it seems to need a shader containing…

alphagen vertex // or rgbgen vertex
blendfunc blend // or blendfunc gl_src_alpha gl_one

default shaders using blendfunc filter won`t be affected.

and we can combine the alphagen vertex with lightmaps.

edit: I finally got ligtmap stages to blend to full transparency, so I can now have lightmapped water :banana:

textures/ratty_alpha/test
{
	qer_editorimage textures/_ratty_terrain/image05.tga
	surfaceparm nonsolid
	surfaceparm trans
	cull disable
	{
		map $lightmap
		tcgen lightmap
		alphagen vertex
		blendfunc blend
	}
	{ 
		map textures/_ratty_terrain/image05.tga
		alphagen vertex
		blendfunc gl_src_alpha gl_one
	}
}
(Fracman) #29

Thanks for the demo map. But could you (rgoer) please post a screenshot of the effect you were able to produce?
I’m mapping in JK:JA only and i had not the textures you were using.
So I did own water textures but they are just more transparent, thats all :???:
Or did i miss something? Special compile switches?

(ratty redemption) #30

no you don`t need special compile switches, any compiling from a simlple bsp stage to a full vis, and lighting will work with the new alphamods :slight_smile:

edit: here is a pic of rgoers q3a map converted to rtcw, the principle is exactly the same, you don`t need the q3a tex he uses in this sample shader, just the images contained in his pk3.

simply edit the paths in his sample shader to point to any tex in the game your mapping with.

(Fracman) #31

great! thanks! :clap:

(ratty redemption) #32

@ydnar, although this alphamod you and rgoer have dev is simpler, and more fun to use then the numerical alphamod I had in mind, there is one request I have for now, which would make your alphamod even more powerful…

and that is to have some key pairing so we can have func_groups that share verts inside an alphascale brush, but only the specified paired groups would be affected.

the reason I ask for this, is because I would like to have more then one alpha channeled mesh sharing the same verts, especially when blending bodies of water together, and a must if they are using deform verts or the different meshes won`t move in sync.

and I wouldn`t always want to alphascale the main water surface, just the blend section polygon offset on top of it.

Im sure you understand my request, but I dont know if it is possible to code, is it?

also what does the q3map_alphamod set do?

(ydnar) #33

I considered making them func_group dependent, but figured it’d be annoying to have to group alphaMod brushes into a terrain func_group.

q3map_alphaMod set N.N

Sets the vertex alpha to N.N * 255, so 0.5 would be 127.5 (127), or half alpha.

q3map_alphaMod scale N.N

Scales the vertex alpha by N.N.

y

(ratty redemption) #34

remember with terrain, we can now have it`s keys in worldspawn and or func_groups, so not all terrain brushes need to be in groups like they used to, but it still allows us to group them, if we want parts of the terrain to be treated differently.

couldn`t we have the alphamods behaving the same?

ie they work in both world spawn and groups, and only the ones in worldspawn would affect brushes or meshes in worldspawn, and any grouped ones would only affect members of their own group?

and is q3map_alphamod set 0.5 just another way of writing q3map_alphamod scale 0.5? …it sounds like the result would be the same, or am I missing something?

(ydnar) #35

Good idea. I’ll do this:

  • worldspawn alphaMod volume brushes will affect all surfaces
  • func_group’ed alphaMod brushes will affect only that entity

As for scale vs set, they are different.

q3map_alphaMod set N <- sets the alpha, regardless of whatever it is
q3map_alphaMod scale N <- scales the alpha, so if it’s 0.5 scaling a 0.25 alpha, the resulting alpha is 0.125, not 0.5

y

(ratty redemption) #36

great thanx ydnar, this will make my life a lot easier since I do so much blending, and it has often been quite unpredictable and very time consuming in the past.

but thanx to your various alphamods we now have some really powerful tools to work with :smiley:

and I understand now about the set vs scale, thanx for explaining that :slight_smile:

can you just confirm…

worldspawn alphamod volume brushes will affect all surfaces

that these won`t affect surfaces in func_groups?

(ydnar) #37

What part of “all” are you not clear about? :slight_smile:

Anyway, it works as described. Func_group’ed alphaMod volume brushes will now only affect their own group’s surfaces:

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

y

(ratty redemption) #38

I wasn`t sure if it was a typo :wink:

thanx and Ill try this release, but if it doesnt work as I hope, would you consider tweaking it?

(ydnar) #39

I’ll consider it if you get rid of that silly sig. :slight_smile:

(ratty redemption) #40

you have a deal…

edit: better? :wink:

and seriously if I had an income I would also donate to your charity work.