Begining of 3D floors [continue needed]

[Soul Sucka]

kgsws, you're awesome!

[Mechadon]

Very cool stuff! I hope it can be polished off to where it works well without any major bugs.

[randi]

This certainly does look promising. I wonder how much work will be needed finish it off...

[Shadelight]

I need to be gone for three days more often ! This is really cool.

[ZDG]

[phi108]

I need to be gone for six days more often. Cool beans!

[Spleen]

Pretty cool, I think you should find SoM on the #doom-tech channel in the oftc IRC network. He made Legacy's 3D floors and Eternity Engine's linked portals, so you two could probably learn a lot from each other.

[Blzut3]

I wonder how much work will be needed finish it off...

I'm thinking that mostly depends on how much work it requires to remove step 2 in R_DrawSkyBoxes. Since Eruanna mentioned Z-buffers, I've analyzed the code a little bit, and figured I should share some thoughts.

The obvious solution (avoiding the R_DrawSkyBoxes issue) of drawing the 3D planes with the rest of the planes (but in a second pass) won't work outside of doing opaque 3D floors (though I think this would be significantly easier as it would mostly be a matter of adjusting the sprite/seg clipping to account for the "fake" planes).

Drawing the planes after the sprites/segs would probably means, along with fixing the issue with R_DrawSkyBoxes, a Z-buffer is necessary (at least while we're drawing "fake" planes it is). I've been trying to think of other possible ways to go about this for a few hours now, but haven't came up with anything that would be reliable.

[Blzut3]

Well I got a z-buffer proof of concept.

---

Note that the z-buffer isn't accurate enough at this point so that screen shot was "set up" at a specific point in which there is no bleeding with the basic code, but it should work in the end I think.

[ZDG]

oooh, shiny.

[NeuralStunner]

Nice stuff, Blzut. How well does it handle sprites?

[Blzut3]

It doesn't yet. Though it should be a fairly simple case of finding the distance to the thing and adding it to the Z-Buffer. Theoretically if all the numbers in the Z-Buffer are correct the rendering should be more or less perfect.

[kgsws-CZ]

There is already correct sorting in one sector, i mean if you see more fake floors/ceilings only in one sector, it is sorted correctly. (not sprites, just planes)

Z-buffer does not solve everything, it is good solution for normal 3D fake floors but not for translucent ones (also translucent sprites would cause problems). But of course at least some kind of "sorting" is here
There also need to be few more things done - for example sprite partitioning for water-like effects, or just transfer sector light (which is now rendered using fake floors without planes and walls, as in GZdoom). But not everywhere it is needed. (transfer light is now better than in orig zdoom - you can move with top/bottom level)
And of course psprites should be colored/shaded by correct fake floor color/shade ... i don't remember if i did it or not ... and i am too lazy to check it

I don't know who all noticed it, but middle walls on sloped fake floors are drawn bad if one of ending is out of screen. It is visible on some screenshots. Yes, i made screens of few bugs to show them.

And there is something about memory - each fake floor structure contains floor/ceiling clipping info, that can consume a lot of memory. It is possible to use just 2 floor and ceiling clipping infos (one is real, default info and second for all fake floors) as long as you have only one fake floor per sector on screen - it does not matter how high each fake floor is. (example is in my first try, translucent water - it uses only 2 clipping infos and it can render multiple water heights correctly, because each level has its own sector)
But if you see on screen more fake floors per one sector, you will have to use more infos.

And do not forget to check my "hack" in p_3dfloors.cpp for FF_BOTHPLANES, it adds new fake floor, non-solid, non-water and without any light effect, but with new flag FF_THISINSIDE as a mark to renderer.

Oh and more, i guess its bug in original zdoom code, check what i added in P_Spawn3DFloors at end (commented with: "for some reason it is not done, do it now") - it is needed to have all transfer lights working (and to have correct in-sector plane sorting) at level start and not after first fake plane movement.

heh, what a long post

[Graf Zahl]

Oh and more, i guess its bug in original zdoom code, check what i added in P_Spawn3DFloors at end (commented with: "for some reason it is not done, do it now") - it is needed to have all transfer lights working (and to have correct in-sector plane sorting) at level start and not after first fake plane movement.

heh, what a long post

GZDoom has the call in the code that sets up the GL renderer for the level so obviously for the software renderer it has to be done elsewhere.

[Blzut3]

Z-buffer does not solve everything, it is good solution for normal 3D fake floors but not for translucent ones (also translucent sprites would cause problems). But of course at least some kind of "sorting" is here

I believe the Z-buffer will work with translucent 3d floors since the translucent plane will still be drawn over the already rendered sprites. You do bring up a good point about translucent sprites, right now the only solution I can think of for how renderer works is to draw opaque 3D floors with the rest of the planes and just accept that translucent 3d floors and translucent things don't mix well.

Edit:

There is already correct sorting in one sector, i mean if you see more fake floors/ceilings only in one sector, it is sorted correctly. (not sprites, just planes)

Yes, but not when looking over a railing onto a lower bridge. Demon Eclipse MAP07 has a good example near the start where if you look at it from the side the railing planes disappear. The z-buffer corrected this issue.