I've been experimenting with Anchored Portals to add some 3D visual fluff to levels, for example a broken floor with the player able to see architecture stretching underneath the floor while standing in the hole. I can also make this reciprocal, so Anchored Portals become 2-way 'windows'.
So far so good. A player standing inside such a Anchored Portal area can see the linked-from area, PLUS any additional LINKED Portals connected to the linked-from area.
But if the additional portal is not a Linked Portal but an Anchored Portal it won't render..!
Is this a limitation? Is there a way to get around that?
Be sure to use "two-way" portal types if the area you can see in the portal has a portal leading back to the area with the first portal. Otherwise you can get into some bad situations with unbounded drawing. I am not sure that's what's going on here, but, you didn't state you were using two-way portal specials so I have to ask that first.
295 Apply anchored portal to the ceilings of all tagged sectors
296 Apply anchored portal to the floors of all tagged sectors
297 Apply anchored portal to the floors and ceilings of tagged ectors
298 Anchor line (for specials 295 and 297)
299 Anchor line (for special 296)
I think they've been documented forever. And talked about multiple times on the forums here. They were created like in 2007 or so to fix problems with anchored portals that could cause infinitely recursive rendering.
SoM changed something again around the time that overlays were added which makes regular anchored portals even more strict about not recursing than they used to be. Two-way portals are supposed to be used in all such situations.
The first screenshot shows a normal room, with a raised platform. In front of that platform is a tiny raised sector with missing lower textures, used to fix an anchored portal (296). The anchored portal shows up as the space underneath the platform.
This portal has a view leading back to the main room, using the reverse. This is what you see in the second screenshot.
Big problem: I can't do the same with another platform nearby, because the space under a second platform can't be rendered when viewed from underneath the first one.
I've tried, but can't seem to duplicate this with 2-way anchored portals nor linked portals which would (probably) do render all attached portals from wherever. Well, not without dividing the main room in two layers, which kinda defeats the purpose (linked portals currently don't allow player to travel up that ladder between the two parts).
The reason I'm using 1-way anchored portals is because of that are far more lenient in their use, and can be tricked into doing the things seen in those two screenshots. And it works.
However, you can't "see" inside a different anchored portal when you're standing inside another one. It won't render. The obvious solution is to avoid that situation, but in some cases that hinders a particular level layout.
If I could manage to do the same with 2-way anchored portals or even linked portals, this problem disappears. But that seems not possible.
HOM. Which is 'as intended', since it's a 1-way portal viewed from another 1-way portal. So basically I'm looking for a way to do the same with a 2-way or linked portal.
Pretty much. From the 'main room' a 296 anchored portal enables the 'under platform' view, from 'under platform' another 295 anchored portal leads back to the 'main room'. So sketching it out:
code:
[linked portal] <> [ main room ] <> [ anchored portal A ]
ok <---- Player ---> ok
ok <---- ok <--- Player
But:
code:
[anchored portal B] <> [ main room ] <> [ anchored portal A ]
ok <---- Player ---> ok
HOM <---- ok <--- Player
Mordeth said: They are in the same relative position as their anchor points from the main room. Keep in mind, those anchored portals are the 1-way kind.
So the camera starts inside the player, then goes to another place, then the inner portal sends the camera back to inside the player. When the inner portal renders, the first thing that gets rendered is the surface the first portal is applied to, which makes it render the first portal again. This creates a recursive portal rendering which there is currently no way to fix.
Yeah I know. But that wasn't really the question :) I'd like to use a different portal (2-way, or linked) to create the same effect but which doesn't have this problem. And that seems not possible. So far at least :)
It allows for on-the-spot creation of a 3D visual effect (eg. a suspended crate or the underside of a vehicle) without having to slice up the main room into several (linked) portal layers. Which btw, also isn't really feasible right now due to the clipping/movement issues between portals.
If the thin 'effect' sector with its missing lower textures is affected by a 2-way portal, the only way it mimics the above setup is if the 'effect' sector is below player viewpoint. That would limit its use to eg. render undersides of vehicles. And still, the recursive bit I can't seem to do: I cannot make the effect so that you can eg. look underneath a vehicle and see the main room behind it.
SOM: that's how I currently do small-scale stuff like 'underside of vehicles' scenarios. Basically the illusion that you can see all the way underneath a structure back into the same room, while in fact it's just a portal copy. But that's pretty limited in use.
But hey, if I ever find a trick around this, I'll post it here ;)
Scuba Steve: not 16 years of development, but 16 years of honing skills :) Goddamn I feel old now.
Mordeth said: SOM: that's how I currently do small-scale stuff like 'underside of vehicles' scenarios. Basically the illusion that you can see all the way underneath a structure back into the same room, while in fact it's just a portal copy. But that's pretty limited in use.
But hey, if I ever find a trick around this, I'll post it here ;)
I don't think there is one, and yeah, it's limited in use. Portals are mostly good for ROR scenarios. Cars and other 3D structures are an example of things that 3d floors are better at. Too bad I'm not implementing 3d floors ;)
01-09-13 19:48 
