[jasonwatkinspdx]

Portal Rendering style engines were invented in the early 90s. I think several people had roughly the same idea at the same time in academia, as well as industry.

Descent was based on a portal and cell renderer that used a unit cube with limited orientations as the cell. This let them simplify and pre tabulate some of the rendering math.

The PVS precalculation done for quake levels is effectively a portal renderer.

Unreal's software renderer needed portal rendering to limit overdraw, so the engine was based around it.

[hypertele-Xii]

Those portals are baked into the maps. I think we're specifically discussing dynamic portals, where the player has the ability to bridge any two spaces at runtime.

Descent can't do that.

[jasonwatkinspdx]

The way the underlying engine works is what's significant, not that it's a dynamic game design element. Descent levels are just a graph of cubes where a portal rendering algorithm runs per cube instance in a flood fill that spreads from the camera origin until there's no more unclipped portals visible on the screen. You could totally make a portal gun mechanic in that engine, they just didn't want to. Well beyond the hatches that open and close, which do case an end to the portal rendering cell walk when closed.

There's nothing particularly novel about Portal (the game) style portals in rendering. Racing simulators did the exact same thing for rear view mirrors for decades prior. It's just another transform in the scene graph clipped to a subscreen area.

[hypertele-Xii]

We are still not talking about rendering. Rendering portals is trivial, and as you say, is the basis of nearly all 3D engines as a means to figure out what to draw. But that info is compiled as the visibility graph into the game map data structure and cannot be modified in realtime.

Narbacular Drop is like, literally the first 3D game ever released that allowed dynamic creation of portals at runtime.

[jasonwatkinspdx]

I am aware of what you're saying. Please reread what I wrote a bit more carefully and charitably. Dynamic portals are not a precedent worth talking about.

[hypertele-Xii]

> Dynamic portals are not a precedent worth talking about.

Dynamic portals are literally the topic of this specific thread of comments. Here's the bit I originally replied to:

> [Prey] had portals before Portal.

Then you showed up conflating dynamic portals with compile-time map rendering, and now you're saying that dynamic portals, the very subject of this discussion, aren't worth talking about, because static portals, the preceding tech, existed earlier, even though dynamic portals clearly introduce fundamental design space as popularized by the critically-acclaimed game Portal.

The word "render" appears in your reply to my first comment six times, which is a lot in a discussion that is not at all about rendering.

Please correct any misunderstanding here on my part.

[jasonwatkinspdx]

> Then you showed up conflating dynamic portals with compile-time map rendering,

I did not. Reread.

"Dynamic Portals" as you term them are nothing more than the combination of a transformation matrix and a screen space clipping region in the context of a recursive approximate depth first renderer, a combination that was utilized by MANY MANY games before the one you're apparently cheerleadering. And this is exactly what I'm talking about, but you're failing to catch the specifics of what I'm actually saying out of apparent defensiveness over this one game.