Fixed Water, translucent, no sides can't clip water FOF sides in software render (r6684)

[Ezer'Arch]

This bug is not critical, rendering issue.

This is a bug that takes place mostly in cascades. I'm reporting it mostly because I worked before in 1.09.4.

A water, translucent, no sides FOF can't clip the underwater walls of a water, translucent FOF, in software render (in OpenGL, this works fairly okay). Interestingly in SRB2v1.09.4, this setup worked quite fine (see pictures).

Since no-sides FOFs require less CPU power to render it, we could take benefit of it if this bug was fixed (i.e. less lag), specially if we consider the 2.0.6 levels are way more complex than 1.09.4's.

Workaround: replace no-sides water FOF (linedef type 123) with normal water FOF (linedef type 121), and the clipping will work.

Sample wads:
- http://dl.dropbox.com/u/4799936/SRB2/BugReports/WaterFOF_v206.wad
- http://dl.dropbox.com/u/4799936/SRB2/BugReports/WaterFOF_v1094.wad (requires SRB2 1.09.4)

 

[Fawfulfan]

What? Clipping for translucent waterfalls has worked a thousand times over in Tortured Planet. Are you sure the two water blocks are the same light level and translucency?

 

[Ezer'Arch]

Clipping for translucent waterfalls has worked a thousand times over in Tortured Planet.

Translucent waterfalls with all-sides water FOF is okay. The problem is translucent waterfalls with no-sides water FOF.

Are you sure the two water blocks are the same light level and translucency?

I am. You can download the sample for 2.0.6 and confirm it for me. Perhaps, I missed something.

 

[SSNTails]

Why don't you just set the waterfall to end at the top of where the other water starts?

There is a reason for its change from 1.09.4, but I don't remember. I know that in DSZ I specifically used no-sides water FOFs only when I wasn't combining them with other types of water FOFs.

 

[Prime 2.0]

Why don't you just set the waterfall to end at the top of where the other water starts?

There is a reason for its change from 1.09.4, but I don't remember. I know that in DSZ I specifically used no-sides water FOFs only when I wasn't combining them with other types of water FOFs.

But what if the waterfall continues below it? Performance is something people have to think about when setting up multiple FOFs in one area, after all...

 

[Ezer'Arch]

Why don't you just set the waterfall to end at the top of where the other water starts?

I did it in some parts of Water Plant Zone (ArchPack). Some waterfalls received some extra FOFs to get rid of "cascade-inside-cascade" problem, as reported here.

The problem is that, this setup isn't always easy. If a cascade "flows into" a static water FOF, it's simple. But if a cascade flows into a "ceiling-moving" water FOF, it would require more complex setup. In Water Plant Zone, it's completely impossible since the main cistern overflows "above" the drains (3 small cascades that fill the cistern, see the pictures below).

<--- SRB2 1.09.4a
<--- SRB2 2.06 (ignore the broken colormap)

Then, this case was solved by replacing no-sides water FOFs with normal ones which do the waterfall clipping. But this has the side-effect of requiring more CPU, and it really does.

Performance is something people have to think about when setting up multiple FOFs in one area, after all...

Performance, that's my point here.

I've got an idea: what about implementing a linedef flag that turns on/off waterfall clipping? For instance, Linedef Type 102, Solid, Translucent has a linedef flag that makes SRB2 render the inside of the FOF, as an option.

 

[SSNTails]

<--- SRB2 1.09.4a
<--- SRB2 2.06 (ignore the broken colormap)

In the 1.09.4 version, I see no water colormap, so the issue of course goes away. 1.09.4 had a lot of cases where it incorrectly stacked the 'lightlist' in a sector and these were fixed... I know in your case it's a pain in the ass, but it's more correct on the whole.

Of course, we're also talking about the sides.... there was some issue that making the non-sided and sided water FOFs merge caused and that's the reason for it's change, but I do not remember the reason.

 

[Callum]

For the moment, the bug is fixed, though the fix needs to be regression tested by the dev team. I'm confident it should work fine though.

EDIT: This is just a fix for the waterfall sides. SSNTails, if the problem you couldn't remember was that transparent FOFs didn't work with the old conditional in 1.09.4, I modified it so that doesn't happen anymore.

 

[SSNTails]

Old conditional? What do you mean conditional?

Deep Sea Zone should be good regression testing.

 

[Callum]

Old conditional? What do you mean conditional?

Deep Sea Zone should be good regression testing.

Take a look at the revision that tries to fix the bug..

I've already tried Deep Sea Zone, everything seems to be working fine still.

 

[SSNTails]

Ah, right. Looks okay, I think. But yeah, I wish I could remember why I changed that. I'm pretty sure I had a good reason... Might have had to do with Deep Sea 3?? Dunno...

 

[Callum]

Ah, right. Looks okay, I think. But yeah, I wish I could remember why I changed that. I'm pretty sure I had a good reason... Might have had to do with Deep Sea 3?? Dunno...

Yeah, without it forcing the change only on waterblocks, underwater translucent FOFs didn't render... that did break DSZ3.