Begining of 3D floors [continue needed]

Moderator: GZDoom Developers

Soul Sucka
Posts: 141
Joined: Sun Apr 04, 2010 9:36 pm

Re: Begining of 3D floors [continue needed]

Post by Soul Sucka »

kgsws, you're awesome!
User avatar
Mechadon
Posts: 470
Joined: Thu May 03, 2007 3:13 am

Re: Begining of 3D floors [continue needed]

Post by Mechadon »

Very cool stuff! I hope it can be polished off to where it works well without any major bugs.
User avatar
randi
Site Admin
Posts: 7746
Joined: Wed Jul 09, 2003 10:30 pm

Re: Begining of 3D floors [continue needed]

Post by randi »

This certainly does look promising. I wonder how much work will be needed finish it off...
User avatar
Shadelight
Posts: 5113
Joined: Fri May 20, 2005 11:16 am
Location: Labrynna

Re: Begining of 3D floors [continue needed]

Post by Shadelight »

I need to be gone for three days more often :P! This is really cool. :)
User avatar
ZDG
Posts: 918
Joined: Sat Jan 02, 2010 12:01 pm
Location: in SlumpEd

Re: Begining of 3D floors [continue needed]

Post by ZDG »

:rock:
User avatar
phi108
Posts: 976
Joined: Sat Dec 01, 2007 6:28 pm

Re: Begining of 3D floors [continue needed]

Post by phi108 »

I need to be gone for six days more often. Cool beans!
User avatar
Spleen
Posts: 497
Joined: Fri Nov 28, 2008 7:07 pm

Re: Begining of 3D floors [continue needed]

Post by 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
 
 
Posts: 3166
Joined: Wed Nov 24, 2004 12:59 pm
Graphics Processor: ATI/AMD with Vulkan/Metal Support

Re: Begining of 3D floors [continue needed]

Post by Blzut3 »

randy wrote: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
 
 
Posts: 3166
Joined: Wed Nov 24, 2004 12:59 pm
Graphics Processor: ATI/AMD with Vulkan/Metal Support

Re: Begining of 3D floors [continue needed]

Post by Blzut3 »

Well I got a z-buffer proof of concept.
Spoiler:
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.
User avatar
ZDG
Posts: 918
Joined: Sat Jan 02, 2010 12:01 pm
Location: in SlumpEd

Re: Begining of 3D floors [continue needed]

Post by ZDG »

oooh, shiny.
User avatar
NeuralStunner
 
 
Posts: 12328
Joined: Tue Jul 21, 2009 12:04 pm
Preferred Pronouns: He/Him
Operating System Version (Optional): Windows 11
Graphics Processor: nVidia with Vulkan support
Location: capital N, capital S, no space

Re: Begining of 3D floors [continue needed]

Post by NeuralStunner »

Nice stuff, Blzut. :) How well does it handle sprites?
Blzut3
 
 
Posts: 3166
Joined: Wed Nov 24, 2004 12:59 pm
Graphics Processor: ATI/AMD with Vulkan/Metal Support

Re: Begining of 3D floors [continue needed]

Post by 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
Posts: 70
Joined: Sun Jul 19, 2009 9:50 pm

Re: Begining of 3D floors [continue needed]

Post by 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 :lol:

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 :)
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49098
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: Begining of 3D floors [continue needed]

Post by Graf Zahl »

kgsws-CZ wrote: 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
 
 
Posts: 3166
Joined: Wed Nov 24, 2004 12:59 pm
Graphics Processor: ATI/AMD with Vulkan/Metal Support

Re: Begining of 3D floors [continue needed]

Post by Blzut3 »

kgsws-CZ wrote: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:
kgsws-CZ wrote: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.

Return to “Closed Feature Suggestions [GZDoom]”