How do I create portal into solid block?

[MartinHowe]

I am experimenting with portals as I have an outdoor building in a level, which is shorter than the ceiling. What I would like to do is have an area of the side of it be a portal into another part of the map, which will be a completely inside area. The "door" in the portal is shown in red below. The player (if they have an ARTIFLY derived class), and any flying monsters, need to be able to pass over the block on which the portal door is painted.

The idea is to do the 3D-floors to put a sloped roof on the building, then draw the inside geometry separately; trying to do it all with hundreds of tiny 3D-floors would be a nightmare!

Can anybody tell me if this is even possible and how do I do it? Indeed, if it isn't, then what's the point of having portals at all; this is the stand-out obvious use for them as far as I can see My experiments so far indicate that portals seem to be infinitely high

block.jpg

[Graf Zahl]

Portals always span the full height of a linedef. What you are trying to do is not possible. The limitation is not on the rendering side - that part would be easy to add - but on the gameplay side. The movement and collision detection code simply cannot handle such a setup.

[Gez]

A possibility would be to have a ceiling portal. The top of the building with its sloped roof is beyond that portal.

[Graf Zahl]

Portal + portal do not mix that well, though. That ceiling portal better be purely visual then.

[Rachael]

I may have committed unholy hackery with that with 20 Heretics' map FINAL. <_<

In fact, you'd probably have a LOT to say about it, mostly negative, if you ever opened it up in an editor and saw it. >_>

[MartinHowe]

Wow. I wondered about that, but is it not possible to give portals two parameters for floor and ceiling height and then code "If object colliding with portal line is above portal entrance height then ignore the portal line in the first place as if it wasn't there", thus avoiding the need to code for that? Kind like turning off the portal line special action (ala setlinespecial) for that monster at that time.

Though I must look at that Heretic thing and see if the hacks there are anything like what I have been trying

[Graf Zahl]

Just one piece of advice: Don't hack around with portals! They are an anomaly in Doom physics and trying to stretch their boundaries may easily end up in catastrophic failure - like crashing or hanging the engine.

[MartinHowe]

Just one piece of advice: Don't hack around with portals! They are an anomaly in Doom physics and trying to stretch their boundaries may easily end up in catastrophic failure - like crashing or hanging the engine.

Don't you mean ... "or opening a gateway to Hell?" This is DOOM we're talking about

But joking aside, I have already found that the line special cannot be turned off via script, so portals are clearly set during level startup. It's as if the destination area of the map is fudged to be mapped in where the real back side would be, possibly by a blockmap hack.

I have, however, found that using Line_SetPortalTarget to the same line itself clears the visual glitch of a tall strip of sky (or whatever); thus if the visible area (seen from outside the portal) of the target is irrelevant when the player is a long distance away or flying, it is possible to hide the fact that a portal is there. Is that hacky enough for you, or has Rachel done even worse?

Can any of the developers give me a better explanation of how they work, please?

[Rachael]

It depends on what type of portal you're talking about.

Static portals will group all adjacent and connected sectors into portal groups - in order to exclude any area from a group it must be separated by a complete void.

I am not 100% positive that this is how they work, but from observation (without looking at the code) this is what I would guess:

Once each portal group is compiled together, the engine then creates virtual coordinates for each of them, and puts them (at least virtually, but not physically) on top of each other. So Portal Group "A" appears to be on top of Portal Group "B", at least in terms of sound and AI processing. Each object's real coordinate remains unchanged, though, this is only for appearances and combat.

Once they're on top of each other (virtually), now it is possible to connect each area together seamlessly in terms of combat - so now bullet hitscans will pass through them, and any objects that pass their borders will be moved to the other side.

Static portals also listen for dynamic lights that hit their walls, as well - when that happens, they'll replicate those lights to the other side.

As far as the player is concerned, because the combat and sound are all happening in one virtual location, they perceive the area to be directly connected together, but it really is not.

[MartinHowe]

Ninja'd LOL. But thanks.

Thinking about it, wouldn't that be a way to avoid the excessive collision detection problems GZ mentioned above? In UDMF at least, there are two spare arguments to Line_SetPortal, which could be used as floor and ceiling of portal. For any portal that that has these parameters used, create an extra portal group that duplicates the area behind the portal in the "real world", as if setting the portal target to the line itself. Then if a hitscan, projectile, or ray of light in the player's LOS hits the line, choose which portal group to use, depending on if the vertical co-ordinate is within the portal height.

EDIT: FAoD, I'm talking specifically about Interactive portals on walls here as these are the holy grail for making outside buildings in a sky-roofed area with realistic insides, without having to resort to hundreds of 3D floors.

[ramon.dexter]

Floot/ceiling portal means that the floor/ceiling is a portal, not that the portal touches floor or ceiling. You know, for collision detection, the floor and ceiling is the same.

[printz]

Why not just use a 3d floor for that structure?

[Graf Zahl]

In UDMF at least, there are two spare arguments to Line_SetPortal, which could be used as floor and ceiling of portal. For any portal that that has these parameters used, create an extra portal group that duplicates the area behind the portal in the "real world", as if setting the portal target to the line itself. Then if a hitscan, projectile, or ray of light in the player's LOS hits the line, choose which portal group to use, depending on if the vertical co-ordinate is within the portal height.

You first have to make it work with the collision detection, which is not that easy. It was hard enough to get it to its current state and still isn't free of bugs.

[MartinHowe]

OK, well that's some explanation - thanks. I guess this sort of thing always takes a while to mature from experimental stage

[Darkcrafter]

What if I resurrect the thread and say that the solution was found?
https://github.com/Darkcrafter07/LZDoom ... 3.90.33-XP

https://github.com/Darkcrafter07/LZDoom ... 344074fd84

It works in modern GZDoom too, athough one block is a bit different in hw_walls.cpp:

Code: Select all

in hw_walls.cpp:
void HWWall::Process(HWDrawInfo *di, seg_t *seg, sector_t * frontsector, sector_t * backsector)
{
//

		/* mid texture */
		sector_t *backsec = isportal? seg->linedef->getPortalDestination()->frontsector : backsector;

		bool drawfogboundary = !di->isFullbrightScene() && di->CheckFog(frontsector, backsec);
		auto tex = TexMan.GetGameTexture(seg->sidedef->GetTexture(side_t::mid), true);
		if (tex != NULL && tex->isValid())
		{
			if (di->Level->i_compatflags & COMPATF_MASKEDMIDTEX)
			{
				auto rawtexid = TexMan.GetRawTexture(tex->GetID());
				auto rawtex = TexMan.GetGameTexture(rawtexid);
				if (rawtex) tex = rawtex;
			}
			texture = tex;
		}
		else texture = nullptr;
		lightlevel = hw_ClampLight(seg->sidedef->GetLightLevel(foggy, orglightlevel, side_t::mid, false, &rel));
		rellight = CalcRelLight(lightlevel, orglightlevel, rel);

		if (isportal)
		{
			lineportal = seg->linedef->getPortal()->mGroup;

			// --- Modern GZDoom hardware renderer portal height window cut START ---
			// args[1] = Floor Height, args[4] = Ceiling Height from your UDMF configuration
			if (seg->linedef->args[1] != 0 || seg->linedef->args[4] != 0)
			{
				float customFloor = (float)seg->linedef->args[1];
				float customCeiling = (float)seg->linedef->args[4];

				// Set tight bounds strictly for the hardware portal stencil mask graph pass
				ztop[0] = customCeiling;
				ztop[1] = customCeiling;
				zbottom[0] = customFloor;
				zbottom[1] = customFloor;
			}
			else
			{
				ztop[0] = bch1;
				ztop[1] = bch2;
				zbottom[0] = bfh1;
				zbottom[1] = bfh2;
			}

			// Submit the bounded portal task slice into the modern hardware deferred draw command queue
			PutPortal(di, PORTALTYPE_LINETOLINE, -1);

			// --- Modern GZDoom hardware renderer portal height window cut FINISH ---
		}
		else
		{

			if (texture || drawfogboundary)
			{
				DoMidTexture(di, seg, drawfogboundary, frontsector, backsector, realfront, realback,
					fch1, fch2, ffh1, ffh2, bch1, bch2, bfh1, bfh2, zalign);
			}

			if (backsector->e->XFloor.ffloors.Size() || frontsector->e->XFloor.ffloors.Size())
			{
				lightlevel = hw_ClampLight(seg->sidedef->GetLightLevel(foggy, orglightlevel, side_t::top, false, &rel));
				rellight = CalcRelLight(lightlevel, orglightlevel, rel);
				DoFFloorBlocks(di, seg, frontsector, backsector, fch1, fch2, ffh1, ffh2, bch1, bch2, bfh1, bfh2);
			}
		}

		/* bottom texture */

Idk how to implement the visual side for software and polymost renderers yet though...
So here's my "fork" of GZDoom v4.10 ( I like this version the best ) - with the feature implemented, although I didn't make the GitHub repository for it ( do I even need it hehe? ). Only Windows build there ( I'm a PC user you know... ).

Upd.. this one got a bit old because 3D-floors driven cut was added in https://github.com/Darkcrafter07/LZDoom ... 3.90.35-XP
GZDoom fork also updated - so you guys may perhaps use this code to push in recent UZDoom versions...


Ooops appologies for many edits...