When will/Why aren't there True Portals?

[Kristus]

But after all you admit yourself that using portals to do a chair is overkill - which was the whole point I was trying to make. What about 10 chairs, each with a different height?

So is using 3d floors for it. Quaint little details like that is best made using items with sprites or models at best.

[Nash]

I can't see any of the pics that essel posted! :(

[Unknown_Assassin]

I can't see any of the pics that essel posted!

How about now?

---

[Graf Zahl]

(Yes, it's a bump, but it's directly related to this topic)

I think in the end the best combination would be Build-style portals plus 3D floors. I hope GZDoom eventually gets there...

I finally had some time to work on this and programmed a Build style algorithm to collect the level geometry. In general it works but there's one big problem with it that makes it most likely useless.

Build does not have any ordered structures to process the level like the BSP. So it has to do a lot of sorting in the rendering loop. For small maps like everything vanilla compatible or small it's not a problem and performance is approximately the same as the BSP method.

But things turn bad when levels become larger.
The P:AR E1M1 test scene from my benchmarks already requires 5 ms for sorting its data but if we go to some level with a lot of stuff to process (like Hellcore's MAP09) it's hopeless. On that level sorting the geometry that's collected already takes more than 40 ms rendering the whole thing useless.

So it looks like the mapping community with its hyper-complex maps has made this an option that's no longer available for Doom engines... (unless I find something to speed up the sorting but it does not look good.)

Maybe I can salvage some of this code to write a better portal clipper but now I'll have to rethink this stuff first. Too bad. I was somehow hoping that this would be the solution to the portal problems.

[MartinHowe]

I often wondered how Build got away with no BSP - or similar precomputation - and could therefore allow moving sectors as a first class feature. Nevertheless there are some absolutely HUGE dn3D maps out there that dwarf anything made for DOOM; I'm thinking especially of the third map in Sang's Battlefield 3, I have never seen such a huge map, but it was playable even on my old 2002-era P4.

Presumably Build does something really clever with maps like that - could GZDoom not do whatever it does? I always wished there was some sort of gradual degredation (with radius from player) of LOS checking in DOOM, especially after GROVE.WAD was released. This first occurred to me when playing Need for Speed 3 and realising that implementing DOOM style FPS logic in settings that big just wouldnt work with the current LOS checking. Perhaps a percentage of the area covered or monsters included in the check, something like that; it certainly looks/feels (from the player's POV) as if that's what's happening when playing BF3/3.

Maybe that's what Build does? After all, even monsters don't have 20/20 vision at three miles!

[Graf Zahl]

It's not about monsters. If that's a concern there's always REJECT. It's also not about absolute map size.
What happens in the 2 cases I mentioned is different:

As long as there's some view blocking stuff in the way everything behind that will never be processed. These problems arise when very much needs to be drawn.

The P:AR map contains some extensive use of crossbeam walkways which result in some rather small and fragmented geometry that creates a lot of drawing data that can't all be processed quickly enough so temporarily the internal lists get quite long.

The HC map is one wide open area with absolutely nothing sight blocking anywhere. So again some huge lists of items to draw get created before there's a chance to process all of it.

Doom doesn't have these problems because the geometry is processed in a perfectly ordered fashion so it's just looking at one subsector, processing it and going on. There's no sorting involved and mappers don't need to be too careful with how to design their maps.

These 2 are admittedly extreme cases. On maps with relatively normal detail this won't happen.

This is a situation Build is not well equipped for. Since it has no preordered geometry like the BSP it needs to do this on the fly and worse, repeatedly per frame.

The code I use for sorting is pretty much a 1:1 copy of the Build code with some necessary alterations because it works on different data.

[Necromage]

This may be a dumb question but couldn't the bsp algorithms be changed to work with the build code? I imagine it wouldn't be easy but it seems like the obvious solution.

[Graf Zahl]

No. BSP and Build are fundamentally different algorithms to collect a level's visible geometry. There is no way the can be combined.

[Gez]

I wonder if the algorithm used in DarkXL and roughly explained here could be used. The "Perplexion" screenshots are certainly interesting enough!

[Graf Zahl]

I can't find a source download so I can't tell. If he managed to get that done without a stencil buffer it might be interesting - but I somehow doubt that it'll help here. The problem with the Build algorithm was not to find portals but to sort the existing geometry. Modern Doom maps are far more complex than anything else in existence and an engine tailored to original Dark Forces may not perform well enough. It's like that with Build: As long as the level of detail remains small it's a great algorithm that's much more convenient for some things than Doom's BSP but in the end nothing can beat a pre-sorted tree that can just be traversed top to bottom to find everything that needs to be drawn. With a BSP you only need to look at each item once. That's often not the case with these other algorithms. For Build, for example, each line needs to be checked at least twice.