"DP New-Lava" Thread

[jakub1]

exactly :-)
-
but i'm not a coder... so maybe there's another way. i had another idea - imagine hell knight holding red hot glowing sword with heathaze effect around it... it would be real quake.

[inkub0]

but does this means "change the original maps" ? mmmm

[jakub1]

lava heat haze effect and some other thougts

seven asked me to join this discussion and so i do.
-
transparency - i'm absolutely convinced that lava shouldn't be transparent, not even slightly. i know that quake world has nothing to do with reality and that's why i like it. however, transparent lava is nonsence even in the quake realms.
-
heat haze effect - darplaces uses part of the q3 shader system and there's no heat haze effect in stock q3 arena engine - i went through the shaders script manual linked here by seven as well as through some other sources and there's no sign of heat haze in q3a. as far as i know, dp supports only part of q3a shaders and we can't create heat haze effect for q1 simply by adding shader to the lava texture. if q3a engine (and dp possibly) can or can't handle heathaze effect is different question. developers of overdose driven by highly modified q3a engine somehow managed to implement heathaze into their engine. the only solution i see with current functionalities of dp is to place extra nonsolid brush above lava, use completely transparent texture for this brush and then apply some shader already supported by dp for this texture to emulate some distortion effect. this is, of course, useless for finished maps...
-
jakub

[ChronoSeth]

Thanks seven, the Beta build allows it to work.

I must say, these liquid effects make Darkplaces look more beautiful than I thought possible.

[Seven]

Hello ChronoSeth,

I tried to simulate your problem, but couldnt.

May I suggest the following:
- Use latest beta build from DP: klick
- Please try to use my config.cfg temporary in your ID1 folder
(find it here)

Hope I could help a bit.
Seven

[ChronoSeth]

Eh, for some reason this isn't working for me. All that's happening is the lava being replaced by a pure white texture. I followed the instructions exactly; place the PK3 in QUAKE\ID1\. The pretty water addon works fine.

The effects look great in those screenshots.

[Spinvis]

Man this looks so good in game, makes the lava finally look alive. Even the illusion that the lave is coming up... amazing! I simply love it. And i agree with ikub0, that hot air distortion will make it even more dope. I am sure that is possible after i've seen the effectinfo's from you guys.

Thanks (again) a lot Seven for the hard work, i'm looking forward to what you come up next.

[Seven]

Thank you very much gb !

Your explanation now proofs, that the "cutted" texture problem in some places is
because of the "lazy mapping" (as you described it).
Unfortunately I cannot do anything against it cause its in the ID1 maps.

So big sine waves in z-direction is a no-go.

For our "DP New-Lava" project this is anyway not interesting,
because lava doesnt behave this way (waves in z-direction).
Its a pity for "DP Pretty water" though.
I implemented it in "DP new Teleport". Here it has no texture issues,
because teleporter texture are always correct and have no visual issues.
(I didnt release the updated New-Teleporter pack yet. If anyone is interested, let me know)


Now back to our Lava project:
So far we have good scaled and nice looking textures.
The movement is in my opinion also quite good.

[golden_boy]

The entire water surface belongs to the same brush. It is not in any way cut by the mapper. It is, however, cut by QBSP, into triangles that can be displayed in the engine.



There are several weird cuts in the water surface around that pillar. This could be what upsets your shader. If so, it is rooted in the original map's brushwork.

There are quite simply limits to how much you can do with shaders and textures. Eventually, you would have to solve the underlying problems. That would mean rebuilding the entire set of maps while keeping all this in mind.

Same water and same pillar in RemakeQuake (map rebuilt from scratch):



More regular cuts.

Most of the water in the original e1m2 is ONE BRUSH that runs through the entire map, crossing all walls. The water at the yellow armour is the same brush as the one near the SSG. Only the water at the start is a separate brush, I believe.

Lazy mapping.

[Seven]

Thank you very much for your code MH.

But it knocks me out of my shoes.
I just started to know shader syntax. And this is by far too much for me.
I studied this page: klick
Your code is far beyond that.
So I have to give up for now.


gb,
I am also not a mapper. So what does it mean, when you say it is only one brush.
Why is then the texture ripped apart in this area (as seen on the screenshot) ?
If it is one brush, how can it look like on the screenshot ?
It looks like someone cut it with a scissor.
I really dont understand it.


Its much harder than I thought.

[golden_boy]

The e1m2 water in that area is one single brush. It does penetrate the walls though.

[MH]

OK, I understand now.

Here's mine (HLSL version, which I consider "the master") for reference:

float4 LiquidPS (VertLiquidOutput Input) : COLOR0
{
	// same warp calculation as is used for the fixed pipeline path
	// a lot of the heavier lifting here has been offloaded to the vs
	float4 color = tex2D (tmu0Sampler, mul (mul (sin (Input.Texcoord1), warpscale) + Input.Texcoord0, 0.015625f));
#ifdef hlsl_fog
	color = FogCalc (color, Input.FogPosition);
#endif
	color.a = AlphaVal;

	return color;
}


VertLiquidOutput LiquidVS (VertLiquidInput Input)
{
	VertLiquidOutput Output;

	// this is friendlier for preshaders
	Output.Position = mul (Input.Position, WorldMatrix);
#ifdef hlsl_fog
	Output.FogPosition = mul (Input.Position, ModelViewMatrix);
#endif
	Output.Texcoord0 = Input.Texcoord;

	// we need to switch x and y at some stage; logic says lets do it per vertex to get the ps instructions down
	Output.Texcoord1.x = mul (Input.Texcoord.y, warpfactor);
	Output.Texcoord1.y = mul (Input.Texcoord.x, warpfactor);

	// keeping vs instructions down is good as well, of course.
	Output.Texcoord1 = mul (Output.Texcoord1 + warptime, 0.024543f);

	return (Output);
}

[Seven]

Dear MH,

sorry, I maybe didnt express myself well.

I mean, with regular "DP pretty water", the linking problem is NOT visible.
Only when I add big waves in Z-direction (up and down) with this shader command (example):
deformVertexes wave 100 sin 0 7 0 0.3
the linking problem becomes visible.
Of course not everywhere, but in a few places where the mapper had to cut out the
water texture because of objects penetrating straight walls.

A very good example is Map E1M2. Right at the beginning, there is water with a pillar on the side.
Here you can see that the original map (which we all use) has not good linked textures/brushes.

Without waves in z-direction:



With big sine waves in z-direction:



Can you maybe show a screenshot of this area with z-direction sine waves activated using your shader ?
I would be very interested to learn. Maybe you can help to solve this issue ?

Thank you very much for your help and effort.
Seven

[MH]

The water textures work perfectly fine in my GLSL and HLSL shaders to reproduce the classic software Quake water warp; no bad joins, no breakup or tearing. Curious.

[inkub0]

i think 0.2 is the better value =)