fog - sky & water surface blending problem...

kat · 2004-02-08 20:28:45 UTC

[snipped from Q3W-LEm]

I’m making a quick SP map for RtCW and this fog problem has cropped up and I can’t seem to fix it.

The two shaders involved are lightly modified versions (fog parameters - distance, colours have been modified) from the original RtCW assets but this seems to be a big problem regardless of the textures used… water just doesn’t want to play ball with skyfog…!!

Currently problem is shown below, the surface of the water doesn’t seem to blend correctly with the fog; standing in one place and looking around the water surface fades in and out from being completely fogged to partially fogged (as you rotate around a standing spot the water surface fades in and out as you turn). The water itself (as you swim thru it) is ok, but a side effect of this non-blending surface is you get a hardline where the fogcull values start instead of a gradual blend/fade out to opaque.

skyshader


textures/kt_aserocks/sky_forest_day_3200
{
	qer_editorimage textures/skies/sky_4.tga
	q3map_lightimage textures/skies/n_blue.tga
	surfaceparm noimpact
	surfaceparm nolightmap
	surfaceparm nodlight
	q3map_globaltexture
	q3map_lightsubdivide 1024
	q3map_sun 0.06 0.07 0.10 50 325 35
	q3map_surfacelight 200
	fogvars ( .1 .1 .1 ) 3200
	skyfogvars ( .1 .1 .1 ) 0.9
	skyparms full 200 -

	{
		map textures/skies/newclouds.tga
		blendfunc blend
		tcMod scroll -0.001 -0.003
		tcMod scale 6 6
		depthWrite
	}
}

water shader


textures/kt_aserocks/fog_water_beach
{
	qer_editorimage textures/liquids/ocean_m1.tga
	q3map_globaltexture
	deformVertexes wave 160 sin 0 10 0 .3
	nofog
	surfaceparm nomarks
	surfaceparm nonsolid
	surfaceparm water
	tesssize 768
	waterfogvars ( 0.1 0.1 0.1 ) 3200
	{
		map $lightmap
		blendfunc filter
		rgbGen identity
	}
	{
		map textures/liquids/ocean_m1b.tga
		rgbgen identity
		tcmod scale .4 .2
		tcmod scroll .0 .007
		fog on
	}
}

I’m not enough of a shader monkey to see whats wrong here but something very odd is happening. Any of you chaps have a clue on this??

ratty_redemption · 2004-02-09 01:44:43 UTC

I doubt this will fix the your problem, but I recommend you replace the lines…

q3map_lightsubdivide 1024
q3map_sun 0.06 0.07 0.10 50 325 35
q3map_surfacelight 200

with something like these, which uses the penumbra (half shadow) sun effect and better ambient lighting, then the old surfacelight when used for sky shaders…

q3map_sunext 0.06 0.07 0.10 150 325 35 2 16
q3map_lightmapfilterradius 0 64
q3map_skylight 50 3

also you could try adding a depthWrite to the water shader image stage, and or remove depthWrite from the sky shader… and I Gerbil suggested for water fog in wolf, that we have a seperate nonsolid fog brush, rather then use waterfogvars in our water shaders, again may not fix your problem but might be worth a try.

kat · 2004-02-09 03:11:05 UTC

thanks ratty. The interesting thing about this problems (which supprised me actually) is that the water itself is fogged properly and doesn’t show any of the usual issues when you dip in and out of it. What is is the waters surface, for some reason it’s just not blending correctly with the ambient fog of the sky.

ydnar did post an edited version of the water shader itself over on Q3W-lem which I haven’t touched other than to test compile so I suspect the culprit now is the sky so I’ll off and try those things you’ve suggested and see what it does. bbl…

ratty_redemption · 2004-02-09 03:16:04 UTC

understood and good luck

kat · 2004-02-09 03:48:20 UTC

just a quick update… removing depthWrite from the sky shader doesn’t fix either… moving onto those other things suggested… blip

kat · 2004-02-09 04:53:34 UTC

hmmm ok, update.
added the lines above (commented out the old) and it didn’t technically fix the problem at hand… it did however do something else very interesting in itself.

reduced compile time of a (test) -bsp -meta, -fullvis, -light -fast -faster compile from c.900sec down to c.100sec
added ‘colour’ (in as much as you can with grey textures…!!) back into the textures of the map.

The previous settings were basically ‘bleaching’ the colour from the textures so they were paler in colour than they should have been. These newer setting have picked up all the bits of green and yellow in the rock texture that were missing (or at least not very noticable) before…

so… although the blending issue is still at hand, you’ve have given me some better quality settings (esp for me newer rock textures)

ta ratty :drink:

ratty_redemption · 2004-02-09 06:48:43 UTC

understood and cool but it`s ydnar who we should be thanking

and kat, are you using dotproduct2 blending on your terrain?

I recently tried it out and love it, although there is some performance hit from over draw, but we can minimize that with careful use of the shaders.

anyway, there are some interesting results we can get from experimenting with the alpha channels of rocks.

Ill show you my latest source files when Im happy with them and it might inspire you with your tex

also Im going to get a website setup as asap so I can finally link to screen shots from here... ydnars going to get sick of me posting in here, but hey

pazur · 2004-02-09 17:09:33 UTC

hi kat,

i think your problem has something to do with the tessalation of the water. i had something similar with really large brushes and patches. what resolved this was to “cut” the large brushes with the clipper tool like every 512 units… and with the patches adding rows/columns helped

tips for shaders with fogvars fog…

when using more than 2 stages the 3rd stage is belnded correctly when using blendFunc GL_SRC_ALPHA GL_ONE_MINUS_SRC_ALPHA

example:


textures/natter/ventgang_metal
{
	qer_editorimage textures/metal_misc/metal_m02ss.tga
	surfaceparm metalsteps
	surfaceparm nomarks
	q3map_bounceScale 3.0
	{
		map textures/metal_misc/metal_m02ss.tga
		rgbGen identity
	}
	{
		map $lightmap
		blendfunc filter
		rgbGen identity
	}
	{
		map textures/natter/tinfx_n.tga
		blendFunc GL_SRC_ALPHA GL_ONE_MINUS_SRC_ALPHA
		tcMod scale .3 .3
		tcGen environment
		rgbGen identity
	}
}

or a water shader using only blendFunc GL_SRC_ALPHA GL_ONE_MINUS_SRC_ALPHA


textures/natter/fluss2
{
	allowCompress
	qer_editorimage  textures/natter/fluss_seq.tga
	//qer_trans .5
	q3map_globaltexture
	deformVertexes wave 128 sin 0 1 0 .3
	surfaceparm trans
	surfaceparm nonsolid
	surfaceparm nomarks
	surfaceparm nolightmap
	cull disable
	sort 8
	surfaceparm nomarks
	{
		map textures/natter/water_fluss.tga
		blendFunc GL_SRC_ALPHA GL_ONE_MINUS_SRC_ALPHA
    	rgbgen identity
        tcmod scale .5 .5
		tcmod scroll -.24 .00
		tcmod turb .01 .05 0 .125
	}

	{
		animMap 6 textures/natter/fluss_seq.tga textures/natter/fluss_seq1.tga textures/natter/fluss_seq2.tga textures/natter/fluss_seq3.tga
		blendFunc GL_SRC_ALPHA GL_ONE_MINUS_SRC_ALPHA
		tcmod turb .01 .035 0 .25
		tcmod stretch sin 1 .005 0 .06
		tcmod scroll -.05 .00
	}
	{
		animMap 8 textures/natter/fluss_seq.tga textures/natter/fluss_seq1.tga textures/natter/fluss_seq2.tga
		blendFunc GL_SRC_ALPHA GL_ONE_MINUS_SRC_ALPHA
		tcmod scale .5 1
		tcmod turb .01 .025 0 .3
		tcmod scroll -.05 .00
	}
}

im mp (i think the same will happen in sp) granades or rockets leave marks that look not correct from distance when using fogvars. so i added nearly to each shader used in outdoor areas “surfaceparm nomarks”

kat · 2004-02-09 17:34:56 UTC

hullo matey…!!

Is that a ‘random’ cut or is it best to approximate the tesssize set out in the shader (in this case 768). I’ll try this 1st and see what it does, then take another look at the blend stages of the sky shader.

ratty : I’ve been playing around with it but I’m not getting the results I was expecting, either I’m doing something wrong (most likely) or vRtCW SP doesn’t fully support the dotProduct (given the implimentation of shaders this isn’t out of the question…!!). If you’ve got some screenies available I’d be very interested in seeing them… have you got this to work on 3pt clip brushwork?? (rocks)

Davros · 2004-02-09 17:39:02 UTC

ratty redemption:

which uses the penumbra (half shadow) sun effect and better ambient lighting, then the old surfacelight when used for sky shaders…
q3map_sunext 0.06 0.07 0.10 150 325 35 2 16
q3map_lightmapfilterradius 0 64
q3map_skylight 50 3

sorry to sound a dumbass but what does q3map_lightmapfilterradius and the following numbers 0 64 do?

pazur · 2004-02-09 19:59:46 UTC

@torchy
The second value of q3map_lightmapfilterradius 0 64 is like the gaussian blur radius of photoshop… it filters the lightmaps of the brushes lit by the sun. q3map_lightmapfilterradius 0 0 is no filtering

@kat
I guess after a cut u will see 2 brushes with the texture scrolling and scaling with a clearly visible seam that looks unrealistic for water. i would try to make the water surface of a flat patch(that has more than 3x3 rows/cols) and have 100% transparent shader for water below it (that indicates the place for swimming)

transparent(invisible) water shader:


textures/natter/wasser_ohnenix
{
	qer_editorimage textures/common/skip.tga
	q3map_globaltexture
	surfaceparm trans
	surfaceparm nonsolid
	surfaceparm water
	surfaceparm nolightmap
	surfaceparm nomarks
	nofog
	{
		map $whiteimage
		alphaFunc GT0
		alphaGen const 0
	}
}

edit: i think u wont see the textures/skies/newclouds.tga because of the fogvars 3200 so i think there is no need for a blendfunc in the skyshader

kat · 2004-02-09 22:37:22 UTC

ok well I finally figured out what the problems is and it’s not directly related to shaders per-say.

I don’t know why I didn’t think of this before as it happens all the time with big brushes and fog in maps for RtCW… it’s the physical size of the brush that’s causing the problem, make a brush bigger than say 512 units and you start to get ‘fogging’ problems where the surface tends to have a ‘skin’ on it when viewed from certain angles instead of blending correctly with it’s surroundings; this is exactly what’s happening with the water brush, cut the brush up and the problem dissappears, so pazur, you were on the right track, it just wasn’t directly associated with shaders tess-size. So there you have it… cut the brush up into smaller sizes…!

Mind you I still don’t understand why big brushes don’t fog properly anyway…!!

ratty_redemption · 2004-02-10 00:13:31 UTC

@kat, why don`t you just use a shader tesssize of 512 or less, rather then cut the actual brush up?

I`m still using wolf, and both the old and new dotproduct blending do work, and seem to work on any visible brush face, as long as the vertex angle in the shaders is pointing in the right direction for the angle of brush face.

I got some pics, temporally ul to a buddy`s site, here is a pic of dotproduct2 blending in wolf, before I added in water to the stream.

all the brush work in the pic is hand made tris, of various sizes, and is much less restrictive then working with lots of alphamap blending, although I do still use small strips of it to cover the seems of dotproduct shaders.

btw, a short hand version of blendFunc GL_SRC_ALPHA GL_ONE_MINUS_SRC_ALPHA is blendFunc blend, which works exactly the same.

@pazur, instead of the image stage of your water shader, couldn`t you just have surfaceparm nodraw?

kat · 2004-02-10 01:14:55 UTC

I did use other tessalation values but they have no effect on this particualr fog problem; it must somehow still rely on the size of the original brush passed over from BSP (I’m assuming it must be something like this), if the original brush is bigger than a certain size this fog error occurs regardless of the shader settings. The only way it was fixed was to physically cut the brush up into smaller chunks. Having thought about it for a bit I’m wondering if it’s linked directed to the BSP splits, ie. brushes greater than the default value of those @ 1024 (the blue line blocks you can switch on in GTK) have the problem.

That’s a kickass shot by the way… some very, very nice blending going on there (I knew about the blendFunc thing btw… they were a bit more explicit with thier parameters in Wolf than in Q3 where the more common parameters were ‘add’, ‘filter’ & blend’), hand made is the only way to go for interesting stuff, what’s your ‘mesh’ density like in that shot?

ratty_redemption · 2004-02-10 03:35:06 UTC

Having thought about it for a bit I’m wondering if it’s linked directed to the BSP splits, ie. brushes greater than the default value of those @ 1024 (the blue line blocks you can switch on in GTK) have the problem.

understood and could you test your theory with _blocksize added to worldspawn, and see if larger values would affect how large our brushes can be, before the bsp splits are needed?

That’s a kickass shot by the way… some very, very nice blending going on there… snip …hand made is the only way to go for interesting stuff, what’s your ‘mesh’ density like in that shot?

thanx very much

and here is a xy shot of that cave entrance in gtk… the larger tris are 256 units wide, most of the cave is 128 and the stream is 64.

but after talking to Gerbil about the average frs him and me are getting in our latest terrain maps (mines a little larger then his helms deep) ...Im now going over the whole of my map and “merging” tris where ever I can to get the tris number down, it was over 9,000 for the terrain alone, and some of that used 512 size tris on flatter areas.

Im leaving as much detail in the most interesting areas though, but trying not to go below 128 size as I now think its too expensive with an open area map this size… with good vis blocking though, we could probably have higher density brush or model meshes without too much of a performance hit.

and recently reyalP helped Gerbil optimize his latest terrain shaders, which cleverly use alpha maps, and the results are stunning as they have very little tex tiling even on large cliff faces, so I`m going to try n combine what I learnt from them into the dotproduct shaders I use.

btw, the green editor image you see for the grass there, is a simple 1 texture stage shader, blendfunc filtered with it`s lightmap stage, so no wasted overdraw.

the lighter grey has 3 alpha blended texture stages, for grass, dirt and rock, plus the lightmap stage, and seems to have the most impact on the map`s fr, although I think the result is worth it, but covering the whole map with that kinda shader and no decent vis blocking was slowing fr down a lot.

the darker grey on the cave shader looks the same as the normal rock but it also has surfaceparm trans, so it doesn`t cast shadows, as they really were fooking up the lightmapping.

also the hidden faces of the cave func_group are painted with a nodraw trans shader, instead of caulk …again to fix the ugly shadows I was getting on top of the caves… that took days trying to figure that bug out, despite ydnar point us in the right direction by confirming there were sun light and shadow leaks in the latest q3map2 builds …their worth using though for the penumbra effect.

btw, one of my ex web friends and team mates, once told kat, that I couldn`t map terrain to save my life, or words to that effect …which is why it means so much to me, that kat, who we know is an excellent mapper and tex artist has finally seen and liked some of my work

kat · 2004-02-10 04:43:33 UTC

[quote=“ratty redemption”]

…btw, one of my ex web friends and team mates, once told kat, that I couldn`t map terrain to save my life, or words to that effect …which is why it means so much to me, that kat, who we know is an excellent mapper and tex artist has finally seen and liked some of my work
lol… yeh cough :eek2: that must have been quite a while ago now so yeh this is the 1st time I’ve seen anything major you’ve done a-la terrain…!

I’ll post a proper reply tomorrow as it’s pretty late now, but the GTK (that is GTK isn’t it??) shot is interesting to see, using different density sections is pretty flexible as welldespite taking longer to set up…!

ratty_redemption · 2004-02-10 05:23:34 UTC

yep, several months since I said "Ive almost finished my water and terrain shaders, would you like to see them kat?" and I still havent finished them, lol

and that is gtk 1.2.13, which was the stable release for wolf, but I didnt like the toolbar icons so I made my own, I also make nearly all the qer_editorimage textures, so again it probably looks odd compared to most peoples setup

kat · 2004-02-10 18:17:47 UTC

ah that explains it then… hehe.

regarding the terrian : sock told me that when they did the ET maps they could only do what they did by using multiple mesh densities, the physical size of some of the maps ment they were generating hugh amounts of data which borked out the compiler. At the end of the day it depends on how ‘mercanary’ you want to be with the details visible in the map, be really ruthless and place big blocks where players either can’t go or can’t directly see and then adjust your tri mesh to fit, it all helps at the end of the day to get the FPS and triscount a little more ‘manageable’. Looks like you’ve got a decent handle on doing this already so keep it up…!

ratty_redemption · 2004-02-10 19:48:10 UTC

understood and cool

G0-Gerbil · 2004-02-16 16:57:06 UTC

and recently reyalP helped Gerbil optimize his latest terrain shaders, which cleverly use alpha maps, and the results are stunning as they have very little tex tiling even on large cliff faces, so I`m going to try n combine what I learnt from them into the dotproduct shaders I use.

Not entirely true - you did help me a lot too you know
Ratty is a modest rodent at times!