using the new alphaMods to make water

(ratty redemption) #21

@obsidian, I can certainly do this, and help you keep your shader manual up to date, in the areas of terrain and water blending dev, but other guys here probably test out the lighting code developments more often then I do.

and I`m actually finishing off some pics and a descriptions of how I did my water fall and moat water, and I will be posting them in this forum hopefully later on tonight.

although it wont be a step by step tutorial, as its initially aimed more at mappers with at least a basic skill level, but Im sure obsidian will clearly understand the process, as its very straight forward compared with what Ive been struggling with prior to ydnars alphamod volume brushes.

and to clarify, I have no objection to any other mappers building waterfalls or soft edge water based on my maps or assets, although I want us all to get them as good as possible before we publicly release our maps, that way when the players first see this technology in game, they will hopefully be really impressed.

also I would like some credit for apparently being the original developer of this water in our q3 engine games.

and credit should also go to rgoer for designing the alphamod volume brushes with ydnar, which have made my work tons easier to do, and are better tools to work with, then what I had concept designed, and was about to ask ydnar to code.

btw, the light caustics I`ve been using on the terrain, still work on the dotproduct2 blending, and result in a really nice lapping effect.

with those the embedded alpha channel is the tricky part, rather then the shader, but I can include an example of those as well, in the sample zip I`ll send you.

(Fracman) #22

@all contributors: many thanks and great job so far!!! amazing pics already, i’m very curious to see the final waterfall… already looks better than 3dmark :wink:
@ratty redemption: how much time , say in days, did you take to do just this waterfall?

Is there a chance to have a special tuturials / tutorial files section either on the original q3map2 page or Obsidians q3map2 manual page then?
The forum search is good, but somethimes the threads simply get so long before i can find what i’m searching for…

Btw. to give e.g. that special waterfall away for download would not necessarily mean everyone simply inserts it in his map… this may happen, but basically its the same “problem” as with the -convert switch…

(ratty redemption) #23

@Fracman, thanx and the water and light caustics look even better when animated :slight_smile:

and its difficult to say how long it took, as I didnt design or build it in one go.

I first started making waterfalls about 3 years ago for a q2 engine game, called heretic2, here`s a link to some pics of that game, including one of my larger waterfalls.

that was a more advanced version of one I`d made for another h2 map about a year before… anyway, when it came to building one in rtcw, I first made it out of patch mesh because obviously the shape is smoother, but then I found it too difficult, although not impossible, to set up the edge blending using alphamaps.

then I remade it out of the brushes, it is still made out of, although I had it grouped as a terrain trisouped mesh, using meta shaders to control the alpha fading.

last week, I stripped out all that stuff just leaving a func_group and using the new alphamod volume blending.

so as well as the terrain blending going through several major rebuilds, and spending a lot of time on the moat and stream water, I`ve taken about 6 months to get it to this stage.

although the good news for you guys, is from scratch I would say most average skilled mappers could build the water for the fall, in probably a day, a couple max, but it`s really consistent technology now, and there are only a few basic principles to learn.

this will make more sense when I post the pics a bit later.

and other then caring about quality and being given some credit, I`m not at all fussed about other mappers using the exact same brush work, shader and tex images from my samples, in their own maps.

in fact gerbil and I planned on releasing all the source material eventually, but if any of you guys want to experiment with this stuff, I`m happy to share parts of my terrain or water, because the chances are some of you will help me improve my own work, as you find different ways of using the technology.

as for a dedicated section or link to this kinda blending, gerbil has kindly agreed to work with me, on some step by step tutorials, once we have finished converting my test map into something playable in et, although I see nothing wrong with other sites linking to his burrow site which he`s going to over haul to make more tutorial and forum friendly.

certainingly I intend this to be an ongoing theme to help dev the best terrain and water, us mappers can get from the q3 engine games, so it wont be something I personally get bored of and stop updating, as Im sure obsidian will regually update the shader manuals, which I often use for reference.

(ratty redemption) #24

edit: you guys might want to first make a strong cup of coffee, to help you stay awake through this next post of mine, but I`ve typed it up now, so someone might as well read it :wink:

now this might sound insane, but to help demonstrate how much more mapper friendly, the new alphamod volume blends are… I would like to first partly explain how I dev the soft edge water using the less friendly alphamaps.

however, rather then a showing a simple blend example, I want to show the most complex blend section, I made for my moat water, as the simplier alphamap blends could appear deceptively easy.

which I found to my frustration, when I tried to use them with more complex brush work, like in the example below, and where I ran into an almost random way of working.

pic 1 shows the blend section on it`s own… this was used to cover the seam between my moat water flowing from two main directions, 90% and 270% in radiant, and a 3rd direction branching off at 360% towards a narrower stream.

if the stream had of been the same width as the moat, it would of been a lot easier, but I didnt realize this until after Id spent about 3 weeks doing all the brush work for the stream.

which ironically I then completely stripped out and rebuilt a month later when I started cutting down on the number of tris in my test map, originally from about 12.5k down to about 8k, but I`ll be explaining why I did that in the terrain tutorials in the future.

anyway, back to the alphamap example…

the func_group in the above pic, had the keys


"_indexmap" "textures/_ratty_alphamaps/new22.pcx"
"_layers" "2"
"_shader" "_ratty_water/moat_water_360_slow"

the water surface was also painted with my moat_water_360_slow shader.

I could post an example of this, but for those mappers that have previously used alphamaps, and meta shaders to blend terrain, it was just a modified terrain shader with a few tcmod scrolls and translucent blend funcs.

the rest of the brush faces were painted with common/nodraw.

the actual water property was contained in another single nodraw water brush that ydnar recommended I used, as it ment the engine didnt have to keep track of as many separate water volumes... I think that was the reason, but if Ive got that wrong, I`m sure someone will correct me.

note the inserted alphamap image in the bottom right of the xy window… this wouldn`t actually be seen in radiant, but in psp, and that is a resized version, so we can clearly see it… the original alphamap is 6x6 pixels although we can easily zoom into images that small, in psp.

now this is where the “random” element Ive mentioned a few times kept cropping up, as those mappers experienced with alphamaps should notice that my mesh doesnt have 6x6 verts but in fact 5x4.

maybe this was a bug in how q3map2 read really small .pcx images, but anyway… an alphamap is ment to have the same number of pixels as our terrain meshes have verts, ie a mesh of 10x10 rows, would actually have 11x11 verts and so it`s alphamap should be 11x11.

Ive built several larger terrains using this principle, and if we didnt match the number of verts exactly, then our resulting terrains would get visual artifacts in the blending.

either the 3 way junction type, where instead of a smooth blend there would be sharp edges to some of the terrain tris, or we would get large stripy patterns going across the terrain.

but I found working with really small alphamaps, that the “rules” broke down, along with consistency of results.

ie some compiles the pixels on the alpha map would almost align (map) with the verts on the mesh, when then tested in game, and other times they would produce the artifacts.

so I gave up trying to match the number of verts and instead started guessing what dimensions the alphamaps should be, starting at the “correct” size, then adding a couple of rows or columns of pixels until I got the blending to look right in game.

pic 2 is an example of this, which also proves the size rule broke down at this scale… note the pic has r_showtris 1

pic 3 is without the showtris.

because this is rendered with a fast sky drawn almost black, its not so obvious how much the blending on the outer quards (2 paird tris) fades but likewise, if I showed the proper sky with its cloud layers, then the soft edge water would be so subtle, we could hardly see it`s outline, hence me usually testing these with dark backgrounds.

iirc that mesh and it`s alphamap, which admittedly looks very simple, as it only has a few possible pixels to paint between the 100% translucency dark green color, and the 0% light green color… actually took about 2 whole working days to make, and that was with a lot of previous experience doing the waterfalls and building and blending most of my moat water.

to a n00b mapper trying to following my dev work back then, even if they had a step by step tutorial, this would of still been a complete nightmare as there was very little consistency in the results… until that was, when I got the exact shape of the mesh, including all its diagonal tris aligned as they are now, plus the alphamaps exact size and pixel design.

then for some “magic” reason each compile would result in the perfect blending, I showed in the 2nd and 3rd pics… that is until I tried copying that mesh and alphamap, and tweaking them to make a similar but not identical blend, and then the whole laborious process would begin again.

why am I telling you guys this? well other then wanting your sympathy for all my sweat and tears :wink:

I think your going to really appreciate just how much easier this same blend was to make with the alphamod volume method, which I`ll explain in my next installment :wink:

(obsidian) #25

The reason for the nodraw water shader is that there are sometimes problems with the way the water acts as a volume. If you were to use normal nodraw on the sides of water brushes, you may have (seemingly random) problems with the water volume act as nodraw instead of water. This means that sections of your water will inherit the properties of the nodraw shader rather than the water shader - therefore the player will just fall right through it instead of being able to swim in it.

This problem has to do with the way map files are stored, the brushes inherits the properties of the first shader listed for that brush. To compensate for this problem, we use a modified nodraw shader that contains the “surfaceparm water” directive, so that there won’t be any question as to whether the brush should inherit the properties of water or nodraw.

Just wanted to clarify.

I’ve done quite a bit of alphamap experimenting in the past as well, so I can totally relate to your efforts. But I think that none of that compares the amount of “sweat and tears” that ydnar must have had programming all these features into Q3Map2.

(ratty redemption) #26

@obsidian, although I agree with everything you said about the nodraw/water problem, I was already using a nodraw water shader on the hidden faces of my water brushes.

but as I had several hundred of them at the time, ydnar suggested I made my visible water brushes from nonsolid, trans brushes, but moved the water property to a single brush or in the case of my moat, a few simple brushes.

I think its to do with the physics engine in game not having to detect loads of water volumes thus raising the fr, rather then a compiling error, but admittedly I dont fully understand it.

as for the “sweat n tears” ydnar has put in, I totally agree with you. it`s hard enough learning how to use the tools, let alone the idea of coding them in the first place.

luckily for me being an artist, most of what I work with is gui based, and although I love writing shaders to give effects to my tex, I wouldn`t want to mainly be working with a scripting or coding language like ydnar does.

(G0-Gerbil) #27

as for the “sweat n tears” ydnar has put in, I totally agree with you. it`s hard enough learning how to use the tools, let alone the idea of coding them in the first place.
Makes me wonder whether there’s any feature Ydnar put in thinking ‘this’ll be killer functionality!’ only for people to ignore it completely, making him a very depresssed Ydnar indeed :wink:

(ratty redemption) #28

yeah probably alphamaps, and ratty`s been winging about them ever since :wink:

(ratty redemption) #29

before I show the pics of the new blending, here`s one more of the old alphamap method.

the inserted bitmap in the lower left of the pic, is quite odd looking and it`s several times bigger then the dimensions of the mesh, 16x16 pixels as opposed to 4x4 verts, but it was the only way I found of getting that alphamap to work.

maybe someone good at maths can explain this, could it be because 4 is a multiple of 16?

anyway, onto the new blending :smiley:

this pic shows the same mesh as one of my previous posts, but this time the func_group has no additional keys like the terrain meshes used to have, ie it just has a classname key.

and instead of a meta shader painted on the water surface, here`s the simpler one I used…


textures/_ratty_water/moat_water_360_slow_new // scroll  -0.15 0
{
 qer_editorimage textures/_ratty_terrain/terrain_water_360.tga
 qer_trans 0.8
 q3map_notjunc
 q3map_nonplanar
 q3map_nolightmap
 q3map_globaltexture
 q3map_shadeangle 178
 q3map_tcgen ivector ( 1024 0 0 ) ( 0 1024 0 )
 surfaceparm nonsolid
 surfaceparm trans
 cull disable
 {
  map textures/_ratty_terrain/image05.tga
  tcgen vector ( 0.00130208333 0 0 ) ( 0 0.00130208333 0 )  // 768
  rgbgen wave sin 0.6 0.3 0 0.3
  tcmod turb 0 0.1 0.3 0.1
  tcmod scroll  -0.15 0
  alphagen vertex
  blendfunc blend
 }
 {
  map textures/_ratty_terrain/image06.tga
  rgbgen wave sin 0.6 0.15 0.3 0.3
  tcmod turb 0 0.05 0.3 0.1
  tcmod scroll  -0.15 0
  alphagen vertex
  blendfunc blend
 }
 {
  map textures/_ratty_terrain/image07.tga
  rgbgen wave sin 1 0.4 0.6 0.3
  tcmod turb 0 0.075 0 0.05
  tcgen environment
  tcmod scale 2 2
  alphagen vertex
  blendfunc blend
 }
}

I expect ydnar will tell me off for the long shader name :wink:

and I do intend to shorten it, this was just from a test map, so won`t be the final version.

for those of you used to writing shaders, there`s nothing new or particularly special about the above example, so you can use almost any shader you want, just make sure it includes…

alphagen vertex or rgbgen vertex, and has a blendfunc blend, or another alpha blend, like gl_src_alpha gl_one, which I used on the waterfalls as its brighter then just blend, as weve probably mentioned before.

the really important shader is the new alphamod volume one, which is painted onto every face of the highlighted brushes in my pic, these then added to the func_group, so this trisouped mesh only volume blends it`s own group, and not any of the other groups or worldspawn brushes sharing verts with it.

here`s the shader I use

textures/_ratty_water/alpha_0
{
 qer_editorimage textures/_ratty_terrain/alpha_0.tga
 qer_trans 0.5
 q3map_alphamod volume
 q3map_alphamod scale 0
 surfaceparm nodraw
 surfaceparm nonsolid
 surfaceparm trans
}

the important lines are the new q3map ones… volume means the following q3map_alphamods effect, will be applied to any other brushs verts, that are found inside the volume brush at time of compiling, as long as they also follow the group rule, mentioned above.

if you look closely as the xy window in my pic, you can see that the highlighted volume brushes over lap the mesh`s brushes.

I have my volume brushes 8 or 16 units wider and taller, then the other brushes, but Im guessing even a volume brush of only 1 unit wider on each side would work, although that wouldnt be as easy to clone or edit in radiant, so probably only needed for really small work.

it also doesn`t appear to matter how large the volume brushes are, so they could enclose several brushes if we needed them to.

note this blending method is really a way to control the alpha values of the brushes verts, like the old alphamaps.

and although I didn`t use any volume brushes on the rest of my sample mesh, except around the outside, the water shader my mesh is painted with, uses paths to tex images containing embedded alpha channels, so that type of blending will also affect the volume (vertex) alpha.

ydnar can probably explain how, but it seems my water shader and alpha channel, were subtracting their values from the alphamod volume results.

anyway, we can use alphamod scales from 0-100, but I found 0 to be the most useful value, as it will fade the nearest verts outside the volume brushes, from 100% opaque to 0% opaque, or what ever scale alpha has been set at in the volume brushes, which in this case is fully transparent, and is great for my soft edge water.

Im no good at maths, but I think if a volume brushs scale was set at 75, and the tex image contained an alpha channel with an indexed color of 127 (which is 50% of the maximum 255) then the result would have the same as a volume brush on it`s own set at 25.

in my tests a scale of 25 appeared very subtle if mixed with other alpha blending methods, although scale 50 would be quite useful, especially if the tex images didn`t have any embedded alpha channels.

if I hadn`t used those traditional ways of controlling alpha, then only the outside verts of my mesh would fade as they were inside the volume brushes, and the ones on the middle of the mesh would be untouched.

this is why I build my meshes out of trisouped brush work, because if we applied volume blending to the outside of a single brush, then if the shaders alphamod scale was the same on each side, the brush would end up a constant alpha value, rather then a linear fade from one vert to the next.

it will probably make more sense if you look again at this pic, where you can see the outer quads of the mesh, are where the volume blending has occurred.

well the theory does make it sound more complicated then it is in practice, so hopefully I`ve not put off anyone from at least trying this method of blending.

it actually took me a lot longer to type this up and proof read it a few times, then it previous took me to make those meshes and volume brushes in radiant :wink:

edit: and I still made typos and grammatical errors, bloodly lame ratty that I am :blah:

(ratty redemption) #30

one final note for now, if you look at the corner quads on that last pic I linked to, your see the ones on the left side of the pic, are aligned so the diagonals splitting the quads, are pointing away from the actual corners, this gives a more “rounded” shape to the overall blend.

as opposed to the right side of the pic, where the quads are split right into the corners, resulting in a sharper, although still faded, blend.

eg, with the small pool inbetween my waterfalls, I used the rounded quad method, so the pool wouldn`t look as square.

(Shaderman) #31

I’m afraid its time to ask for your help now :frowning: I’m new to this alphamod stuff and tried to get NOP’s sample map to work for 2 days now (it doesn’t work out of the box for me). I’ve corrected ydnar’s common alpha shaders and compile with q3map2 2.5.14. There’s one thing I’m not able to figure out (seems to be almost the same problem like NOP described in his first post). The transition between the deepToShallow and the shallowWater shader won’t work. It seems like there must be two alpha brushes overlapping (alpha_0 and alpha_60) but if they do, I get this result:

If the alpha shaders don’t touch each other it looks good, but this would result in a space between the water shaders:

What am I missing here please? I’m sure there’s a simple solution :eek:

(ratty redemption) #32

I rebuilt NOPs sample map a while back, but only recently made my own textures for it from scratch, so it wasnt previously released as I didn`t want to use any copy write material.

anyway… I think my version of that sample map is simpler and probably easier to get working.

saying that, I`m currently finishing off the 3rd and last part of my terrain tutorial, as well as taking pics and sorting through my notes for a new combined water and terrain tutorial, which will be in a separate thread.

and where I intend to give step by step instructions, and try and make it easier to follow and less disjointed then my previous tutorials :wink:

problem is Im doing that stuff inbetween other mapping and modding projects, so I dont know how long it will be before I post the tutorials, although in the meantime I could ul that sample map so you could have a look at it, but I can`t walk you through it atm.

(NOP) #33

EDIT: Raty (again) beat me to it

You’re right it is something simple(isn’t it always)

The brushes are func_grouped.
The two alphaMod brushes that overlap belong to 2 different func_groups so they only affect the brushes in their own func_grups. The 0% alpha only affects the brush with the deepToShallow shader on it and the 60% brush only affects the brush with the shallowWater shader on it. Press L and take a look at your func_groups in radiant to see what i mean.
Your version of q3map2 might not support func_grouping (ydnar re-released 2.5.14 later on) so get the latest one from the top thread.
When i made that map, I too was just learning this alphaMod stuff so the arrangement in it might not be all that great. I made a few changes for the water in Saberpeak.
Also there’s a tutorial on my website about alphaMod brushes etc. if you need more help even though there are a bunch of them in this forum already.

(ratty redemption) #34

good post NOP, and I can still post my sample map if need be, although I was intending to post it along with others in the new thread, which I`ll probably still do, even if I post it in here first.

as for the development of water and terrain building and their shaders, its an ongoing interest for several of us, and Im personally finding quicker and more efficient ways of making both, the more I practice and further my understanding of the whole process, as I`m sure several of the other guys in here are also doing.

(WolfWings) #35

Shaderman - You need to have your deepWater and shallowWater brushes TOUCHING. They’re not, in the above map. And the alpha-channel value for the contact point should probably be constant. I.E. AlphaMod 0 for both brushes, or AlphaMod 60 for both, not 0 for one and 60 for the other. Also, as has been said, func_group both water brushes and the AlphaMod brush together.

Also, as a side-note… would you mind if I started working on posting some examples I’ve built for your alpha-channel-included dithered terrain, Ratty? I’ve figured out how to reduce things to two shaders and no brush-copying to start with, so it’s easier to implement for first-time mappers, based on the info ydnar posted a while back about numerous shaders being worse (generally) than 3-pass shaders most of the time.

To be honest… if ydnar could add that one feature to allow for ‘constant-alpha polygons’ to be replaced by some other shader, it would end up being identical to your original ‘dithered’ terrain effect. :slight_smile:

(ratty redemption) #36

@WolfWings, sure go ahead :slight_smile:

Im always open to suggestions for improving, optimizing our mapping or shaders... although in the end, I think its up to the individual mapper which construction methods, shader code etc, they use.

and I go through phases of preferring to use certain methods over others, then I might experiment and change over to another method… iow it`s also nice to have choices.

edit: I too recently have been using blend func_groups without cloned brushes underneath, although they were linear alphamod volume blends and not the dithered style, but we can probably optimize those as well.

to clarify, feel free to go over any of my tutorials, samples maps, textures or shaders and see if they can be improved, whether it be technical or artistic, if I like the suggestions any of you guys make I`ll implement them :slight_smile:

(NOP) #37

There seems to be a problem when compiling the sample map I posted earlier in the thread with the latest version of q3map2. (sorry for all the trouble Shaderman)
I’m not sure what’s causing this but I’m posting something in the release thread, maybe Ydnar can give me a clue.

No…if you’re using the sample map you need the func_groups to have different alphaMod brushes. The 60% alphaMod brushes are used to give transparency througout the water and the 0% brushes are there to perform the actual blends between the shaders. You can achieve the same result by just adding an alpha channel to the textures in which case you can completely remove the 60% brushes.(but you also need to modify the shader a bit). But yes the brushes need to be touching.
Anyway…right now I gotta find out what’s wrong when compiling with 2.5.15, so if you figure it out, post something.

(WolfWings) #38

Heh. Using a single func_group for an entire two-texture dithered terrain blend is mostly appropriate for ‘detailing’ an area. The full four-shader approach is better if you have more than two ‘base terrain textures’ to transitions between, but for, say, adding some snow to a cliff, or alien slime to a computer terminal, this change works wonders. It can also be somewhat more subtle as it lets you turn off the alpha-Masking.

The reason my ‘simplification’ is less appropriate than the full version is that it requires two textures per transition-line. I.E. In addition to a ‘dithered’ Snow texture, this method requires a ‘recieving’ texture. Specifically, it’s a method of adding a smooth-blended ‘overlay’ to an existing area. I.E. Rust on a metal catwalk, alien slime on a wall, blood on a mirror, etc.

Simple text-only example:

Say you want to add some snow to an area of terrain composed of flat ‘Rock’ texturing right now. You need a ‘dithering Snow’ texture. The usual ‘copy the value to the Alpha channel, equalize, save as a .TGA file’ approach tends to work fine. Now, load up the ‘Rock’ texture, and copy the Alpha channel from the Snow texture. With one change. Invert it. This inverted-dithering-alpha texture is what I call a ‘recieving’ texture. It’s meant to ‘recieve’ dithering from whatever texture the alpha channel originally came from, in this case, Snow. So this is a ‘Snow-recieving dithering Rock’ texture now. (Can you tell I’m a big fan of making sure the terms I use are explained in gorey detail? :smiley: ) I’ll explain the economics, and shaders needed, of this method at the end.

Now, apply the ‘dithering Snow’ shader over all the terrain-surfaces that will have any of the snow on them, realizing it will be a very subtle effect (whisps of Snow, for example) at the edges when you’re done. This is so you can see how far out the effect will spread, realize this stage should look like there’s too much Snow, for example.

The boring part, but easier for newer mappers to understand. Apply the ‘Snow-recieving dithered Rock’ shader on the surfaces that currently have the ‘dithering Snow’ shader on them, that also touch the original ‘Rock terrain texture’ surfaces on one or more vertices.

Finally, anywhere the ‘Snow-recieving dithered Rock’ and ‘dithering Snow’ shaders touch at a vertex of the terrain, add an ‘AlphaMod 0%’ brush surrounding that vertex. This is the only AlphaMod brushwork you’ll need for the effect.

Now, compile, and you’re done. Shaders needed follow:

// Snow-recieving dithered Rock texture is rock1_1.tga
// dithering Snow texture is snow1_1.tga

textures/wwsf/dithering_Snow_on_Rock
{
 q3map_tcGen iVector ( 256 0 0 ) ( 0 256 0 )
 q3map_shadeAngle 175
 q3map_lightmapAxis z
 q3map_nonPlanar
 q3map_lightmapMergable
 qer_editorImage textures/wwsf/rock1_1.tga
 {
  map textures/wwsf/rock1_1.tga
 }
 {
  map textures/wwsf/snow1_1.tga
  alphaGen oneMinusVertex
  blendFunc blend
 }
 {
  map $lightmap
  blendFunc filter
 }
}

textures/wwsf/Snow_recieving_dithered_Rock
{
 q3map_tcGen iVector ( 256 0 0 ) ( 0 256 0 )
 q3map_shadeAngle 175
 q3map_lightmapAxis z
 q3map_nonPlanar
 q3map_lightmapMergable
 qer_editorImage textures/wwsf/snow1_1.tga
 {
  map textures/wwsf/snow1_1.tga
 }
 {
  map textures/wwsf/rock1_1.tga
  alphaGen oneMinusVertex
  blendFunc blend
 }
 {
  map $lightmap
  blendFunc filter
 }
}

Now, the economics. It uses two three-pass shaders per transition, but that’s relatively little actual cost that I know of. The real cost comes if you end up needing to apply more than just Snow to the Rock texture. Each ‘surface effect’ you want to apply to Rock, in this case, needs a new version of the rock1_1.tga file.

If you wanted to apply Snow to Grass and Rock, you’d only need:
Snow-recieving dithered Grass texture
Snow-recieving dithered Rock texture
dithering Snow texture

If, instead, you wanted to apply Snow and Grass to Rock, you’d need:
Snow-recieving dithered Rock texture
Grass-recieving dithered Rock texture
dithering Snow texture
dithering Grass texture

See how the economics work?

The above can be changed back to using the AlphaFunc keywords to allow for using q3map_styleMarker2. It takes a non-intuitive change though, partially reversing the above sequence, which I’ll explain if folks are interested It also looks worse than the smooth blending this achieves, though if you turn on FSAA the ‘problem’ goes away instantly. Combining dithered terrain with styled lights is definately a fairly advanced combination though, and not one I thought should come up THAT often unless someone wants to do, say, lightning. =^.^=

And as a final side-note… I’m in the process of munching through all the Golgotha textures, so I’ll have a pretty damn-good-quality pack of terrain-compatable textures for folks to use. Q3A especially (when you don’t have TA installed) is SERIOUSLY lacking in any remotely-decent terrain-texture sets. :blah:

(WolfWings) #39

http://wolfwings.us/wwsf.zip

The above is a FFA/TDM map I’m at the point of style testing (lighting and construction) the buildings to go into the courtyard, and the terrain effects, before I start building the final versions. Skybox is a blend of two of SocK’s most infamous and generally useful ones, Dusk to Dawn and Frozen Wasteland. =^.^= If I go with the ‘rubble’ building, I’ll probably light the top of the collapsed roof on fire to give off more lighting in that area.

(Shaderman) #40

First of all thanks to all of you trying to sort this out here.
I read a lot the last days about this alphamod stuff and was happy to finde a simple looking sample map to see how things have to be done. I tried to understand how shaders, alpha shaders and this func_group thing should work (I think i understood those basics anyway). But one thing confused me. On the one hand I read about using func_group(ing) shaders and a bug that was fixed in q3map2 - one the other hand I remember a post from ydnar saying that func_grouping isn’t necessary to get this blending work (must have misundertood this one :eek: ). So I tried NOP’s sample map with and without func_grouping the shaders. Both had no effect since I don’t seem to have this one special q3map2 version (the 2.5.14 you can d/l now from the official place seems not to work). I don’t know if I discovered a bug while working with a simple sample map but believe me - I’m still a bit confused :eek2: I think the only remaining problem for me is where to get this working q3map2 version to go on with my study :smiley:

@Ratty: Nice to hear that you’re working on a “combined water and terrain tutorial” because this is exactly what I want to know. It should surely be very interesting for me to have a look at your sample map even if it’s not finished yet. Maybe you’d like to upload it and let me (the noob himself :smiley: ) test you descriptions you 're still working on to see if it’s explained well.

@NOP: Yes, I think the problem is the q3map2 version I’ve downloaded for my shader experiments. (Said above) I don’t know where to get it and why the newer versions don’t work, too (let’s wait for ydnar to clear this). I think your sample map is great to start with because you don’t confuse a beginner with some extra tga alpha channels. I read your tutorials, too but is there anything better than a sample map or some pictures to learn from? :smiley:

@WolfWings: I knew that I should connect those brushes but wanted to show that each side of the water works alone and point out that the problem appears when trying to connect them (I tried to show that there’s no mistake in one of the shaders itself).

I think I’ll wait now for ydnars answer before I go on with my experiments because I can’t see anything I made wrong or didn’t try yet. Thanks for your help guys (and sorry if you should have trouble understanding my english now and then)!