How do you get an appearance of room over room in ZDoom?

In KDiZD, I saw this in the first level:



Then this on the third level:



How is this done? Additionally, how do I make an appearance of room-over-room with a wirey bridge like in congestion 1024 level 4?

There's a few ways you can do this. Those screenshots are the rsult of using "stacked sectors". To achieve true 3D however, you should refer to GzDoom's 3D floors (linedef action 160).

If you like, I can whip up a practice wad that implements these features. Let me know if you want this, because its rather difficult to explain without using examples.

the iron hitman said:

There's a few ways you can do this. Those screenshots are the rsult of using "stacked sectors". To achieve true 3D however, you should refer to GzDoom's 3D floors (linedef action 160).

If you like, I can whip up a practice wad that implements these features. Let me know if you want this, because its rather difficult to explain without using examples.

Yes please.

I'm probably gonna get hell from zomeone for this but here goes...

It's using portals in Zdoom to give the effect of a second level. I don't recommend you to use it though. It's a quite buggy feature and you'll more often than not end up with a glitchy implementation that gives off HOMs. (look for instance in UTNT Map03)

I also don't really recommend you to use 3d floors in ports such as GZdoom and EDGE etc. Well, if you're already making the wad for them, by all means go ahead and knock yourself out. But I wouldn't suggest you base your use any of those sources for that reason.

If you're actually interested in achieving 3d architecture. You should look in to the Eternity Engine and it's linked portals technology.
(Excuse my shameless self promotion by showing off a shot of one of my own maps)
http://www.tfuture.org/kristus/portals_FTW_2.gif

That looks soooo ugly. I mean one of your railing isn't even equally spaced.

kristus said:

I'm probably gonna get hell from zomeone for this but here goes...

It's using portals in Zdoom to give the effect of a second level. I don't recommend you to use it though. It's a quite buggy feature and you'll more often than not end up with a glitchy implementation that gives off HOMs. (look for instance in UTNT Map03)

I also don't really recommend you to use 3d floors in ports such as GZdoom and EDGE etc. Well, if you're already making the wad for them, by all means go ahead and knock yourself out. But I wouldn't suggest you base your use any of those sources for that reason.

If you're actually interested in achieving 3d architecture. You should look in to the Eternity Engine and it's linked portals technology.
(Excuse my shameless self promotion by showing off a shot of one of my own maps)
http://www.tfuture.org/kristus/portals_FTW_2.gif

Uber promotion post! Nice screenshot though, I wonder if that's possible in GzDoom, Eternity sure does have promising features (wondering if its worth converting from GzDoom to Eternity at this present moment)

Anyway, this is what you're looking for I believe: http://www.filefront.com/14062003/3dbridgeillusions.wad

Hope this helps!

You can do some crazy things with GZDoom 3d floors. Unfortunately it's a lot of work to make expansive 3d floors as you have to juggle around with lots of dummy sectors. I'm not familiar with how Eternity works but given the designs I've seen done with it I can imagine it's a lot less of a hassle to use its portals for the job.

Kyka said:

Yes please.

Seconded

And WHOA KRISTUS!! HOW DID YOU DO THAT!!!!1111!11!11

Nixot said:

Seconded

Link has been provided in my previous post :)

the iron hitman said:

Uber promotion post!

Yes. But I think it's warranted for Eternity. Since most people don't have the faintest idea of what EE can do. Usually people just promote Zdoom by default.

Nixot said:

Seconded

And WHOA KRISTUS!! HOW DID YOU DO THAT!!!!1111!11!11

It's done with portals.
In reality the scene is 4 layers of sectors stacked on top of each other by the engine.

kristus said:

It's using portals in Zdoom to give the effect of a second level. I don't recommend you to use it though. It's a quite buggy feature and you'll more often than not end up with a glitchy implementation that gives off HOMs. (look for instance in UTNT Map03)

There have been various stacked sector tricks discovered since UTNT map03, though. The most useful is using mid textures in place of lower and upper textures; if you do it right, some pretty complex architecture can be made with no HOMs whatsoever (esselfortium is a master of this ;)).

Also: http://forum.zdoom.org/viewtopic.php?f=4&t=18677

And BTW, if someone really wants to see how a level with well-constructed 3D floors looks, check out Hi-Tech Hell 2. It was made for Legacy so there's no slopes in there but the architecture is some of the best stuff I have seen in a Doom level.

Regarding Eternity's portals, sure it's impressive. However, I think the Doom renderer is ill-suited for any kind of portal implementation because one way or another the way the BSP is traversed gets in the way. This is the main reason I haven't pursued this in GZDoom so far. All ideas I get to work around these shortcomings have an unacceptable performance impact or require information that's only available with the software renderer. In other words: Useless for OpenGL.

Doing it with a Build-like algorithm will yield much better results I think (and also be much more efficient when using a hardware renderer.)

Graf Zahl said:

And BTW, if someone really wants to see how a level with well-constructed 3D floors looks, check out Hi-Tech Hell 2. It was made for Legacy so there's no slopes in there but the architecture is some of the best stuff I have seen in a Doom level.

Regarding Eternity's portals, sure it's impressive. However, I think the Doom renderer is ill-suited for any kind of portal implementation because one way or another the way the BSP is traversed gets in the way. This is the main reason I haven't pursued this in GZDoom so far. All ideas I get to work around these shortcomings have an unacceptable performance impact or require information that's only available with the software renderer. In other words: Useless for OpenGL.

Doing it with a Build-like algorithm will yield much better results I think (and also be much more efficient when using a hardware renderer.)

I'm having some difficulty understanding how being useless for an OpenGL renderer has anything to do with how well-suited Doom's own renderer is for portals.

Ah, but Eternity doesn't use Doom's own renderer.

Oh, but it used to, and it had portals then, too! :)

Graf Zahl said:

And BTW, if someone really wants to see how a level with well-constructed 3D floors looks, check out Hi-Tech Hell 2. It was made for Legacy so there's no slopes in there but the architecture is some of the best stuff I have seen in a Doom level.

Also note-worthy is Kristus' (Ebola's) "Phobia" maps. Utterly fantastic!

Regarding Eternity's portals, sure it's impressive. However, I think the Doom renderer is ill-suited for any kind of portal implementation because one way or another the way the BSP is traversed gets in the way. This is the main reason I haven't pursued this in GZDoom so far. All ideas I get to work around these shortcomings have an unacceptable performance impact or require information that's only available with the software renderer. In other words: Useless for OpenGL.

Yes, in order for you to accomplish the same type of portal setup in hardware mode, you would basically need to create something analogous to a shadow volume from the camera that was fitted to the silhouette of the portal window and discard any geometry that didn't intersect that volume. Highly inefficient.

Doing it with a Build-like algorithm will yield much better results I think (and also be much more efficient when using a hardware renderer.)

A build-type system would work much better for your purposes. EE's compatibility demands prompted me to seek a BSP-friendly solution.

*Edit*
Also, on the subject of Zdoom's portals being "buggy": They aren't buggy, they render exactly what a doom map would look like from above/below in that any 1s line or blocking upper/lower walls will make hom beyond them. I've implemented portals in Legacy (beta feature that never went anywhere) and EE now, and I can tell you it requires workarounds. My original code for Legacy was HORRID trying to reject the correct architecture to not cause HOM/incorrect sprites from rendering and not cause a terrible speed loss.

EE's system is much cleaner and better designed (IMO) and requires only one function I would consider a "work-around" which does produce a slight performance hit, but I'm looking into a better designed solution to integrate this test so that it's a natural part of the seg rendering codepath rather than a separate work-around... But I digress.

SoM said:

Yes, in order for you to accomplish the same type of portal setup in hardware mode, you would basically need to create something analogous to a shadow volume from the camera that was fitted to the silhouette of the portal window and discard any geometry that didn't intersect that volume. Highly inefficient.

What I am doing is using a stencil buffer to discard the stuff that must not be drawn. The performance hit is very noticable - especially if more than one portal is in view.

Another problem is this that there's some potential of too much geometry being processed - even though I am already narrowing down the viewable area in the clipper as much as possible. This can also cause slowdowns

There is one issue I have not solved yet:

There's horrible glitches if the portal view gets obstructed by some geometry in front of the visible part but in front of the camera. If I could solve this I'd be able to do a (rather inefficient) implementation of Eternity's portals in the GL renderer.

Graf Zahl said:

What I am doing is using a stencil buffer to discard the stuff that must not be drawn. The performance hit is very noticable - especially if more than one portal is in view.

Another problem is this that there's some potential of too much geometry being processed - even though I am already narrowing down the viewable area in the clipper as much as possible. This can also cause slowdowns

I assume that the stencil buffer is probably the only way you can do portals in an OpenGL environment. I bet turning on the stencil test does damage your frame rates, especially on slower cards. Although you still haven't touched on the REAL problem implementing portals in Doom...

There is one issue I have not solved yet:

There's horrible glitches if the portal view gets obstructed by some geometry in front of the visible part but in front of the camera. If I could solve this I'd be able to do a (rather inefficient) implementation of Eternity's portals in the GL renderer.

There we go! This is what I was referring to with my "shadow volume" concept. Basically, in the software renderer I have the outline of the portal "window" and I can reject segs based on their screen position. For ceiling portals, any seg that would render entirely above the portal window gets rejected, for floors, any seg that would render entirely below the portal window (in screen space, that is) is rejected. This is all done with a quick pass through the projected silhouette coords for segs that could potentially cause HOM in the portal.

As you said before, hardware doesn't give you access to this information, so your best bet would be some sort of frustrum culling but that would be a nightmare. I totally agree with you that portals+bsp aren't a good solution for hardware renderers. A build type system wouldn't help you much with the stencil buffer, but would be quite useful for the other problems you're having.

SoM said:

I assume that the stencil buffer is probably the only way you can do portals in an OpenGL environment. I bet turning on the stencil test does damage your frame rates, especially on slower cards. Although you still haven't touched on the REAL problem implementing portals in Doom...

Indeed. Depending on the portal's complexity I have seen framerates break down from above 100 to less than 30 fps.

A build type system wouldn't help you much with the stencil buffer.

That depends on what you allow. If you set a rule saying 'no overlaps' and you can assume that any part behind the portal won't show through in the regular part of the map it can be done without a stencil. It could all be rendered in one pass so there'd be no slowdowns or other ugly side effects.

*crosses hardware rendering in Eternity off his wish list*

Graf Zahl said:

That depends on what you allow. If you set a rule saying 'no overlaps' and you can assume that any part behind the portal won't show through in the regular part of the map it can be done without a stencil. It could all be rendered in one pass so there'd be no slowdowns or other ugly side effects.

Couldn't you say 'no overlaps' currently and rendering every in one pass?

What difference would that make?

If there's no overlaps the result would be the same - but Build's way of traversing a level would make the one pass approach more natural.

*leap in* I thought KDiZD's "room over room" was done with portals?

Or what about the bit in Genesis of Descent where you fight through a room, and then end up on top of the building and can see the room you fought in underneath you?

SoM said:

I totally agree with you that portals+bsp aren't a good solution for hardware renderers.

I totally disagree.

BSP gives you subsectors in rendering order. That is just as useful for rendering a portal as it is for rendering the normal scene.

You can prevent the portal contents contaminating the normal scene with clipping planes. OpenGL only guarantees 6 which is only enough for say depth 2 (a portal in a portal), however by using software clipping planes you could support unlimited depth.

andrewj said:

I totally disagree.

BSP gives you subsectors in rendering order. That is just as useful for rendering a portal as it is for rendering the normal scene.

That may be. But the problem lies elsewhere:

There is absolutely no correlation between the subsectors in the main scene and the ones in the portal - which makes the scene a lot harder to process because you can't rely on the main scene for processing the portal.

With Build you get a natural crossing from one side to the other which eliminates a lot of problems without ever having to work around some of the issues that a BSP-based renderer would have (e.g. obstructing geometry between the camera for the portal part and the actually visible part of the portal.)

OpenGL's clipping planes are more or less useless here if the portal gets more complex.

You are not moving the camera to render a portal, right? That is the wrong approach.

I think BSP is nearly as natural as Build, when you hit a portal seg you just setup a new geometry translation and walk the BSP tree again, skipping nodes and subsectors that lie outside of the portal (like you do for the normal view frustum).

One issue I had was that I wasn't clipping blocking segs (manually) to the portal before updating the 1D occlusion buffer with them, leading to bad glitches.

andrewj said:

I totally disagree.

BSP gives you subsectors in rendering order. That is just as useful for rendering a portal as it is for rendering the normal scene.

You can prevent the portal contents contaminating the normal scene with clipping planes. OpenGL only guarantees 6 which is only enough for say depth 2 (a portal in a portal), however by using software clipping planes you could support unlimited depth.

The problem isn't portal contents contaminating the regular scene. The problem is 1S and other clipping lines causing HOM in the portal windows themselves.

Nixot said:

How is this done? Additionally, how do I make an appearance of room-over-room with a wirey bridge like in congestion 1024 level 4?

Seems everyone would rather debate portals than answer your actual questions...

That kinda fake glass-look floor is done by offseting translucent middle textures down into the floor.
The 'wirey bridges' are usually constructed of floating middle textures and Zdoom's bridge things.

In either case you should be able to see how the effect is achieved if you simply open up the maps in an editor.

Cybershark said:

Seems everyone would rather debate portals than answer your actual questions...

Thread has almost been hijacked. But on topic...

Incase no-one has bothered reading my posts higher up, I'll re-post the practice wad link.

Link: http://www.filefront.com/14062003/3dbridgeillusions.wad

If anyone wants a proper tutorial on it, I will "try" and make one when I get time.

Cybershark said:

Seems everyone would rather debate portals than answer your actual questions...

That kinda fake glass-look floor is done by offseting translucent middle textures down into the floor.
The 'wirey bridges' are usually constructed of floating middle textures and Zdoom's bridge things.

In either case you should be able to see how the effect is achieved if you simply open up the maps in an editor.

No.

What you see here is an actual portal, not a cheap fake.