I have a linked portal door connecting two hallways, to make a paradox type thing were you end up in a room that is looking down from where you were before you walked through the hallway. Anyway, there are some observation rooms in the second room that when looked through the linked portal door the frames are not rendered, but when you tilt your screen so you are looking at the obs. rooms and the linked door, then they are rendered in the linked door. Basically my question is, how can I make the observation room frames stay rendered even when I'm not looking at them directly? btw they are func_dynamics

Generally looking through linked portals are going to be a major problem, especially with visibility of props and other objects. Multiple views through the same world portal can also create some major issues. The main reason why objects disappear and appear depending on where you look is because of of visleafs.
Now you could fiddle around with func_visclusters in order to determine where and what is visible, but I guarantee this will produce other visibility and performance issues.

Your best bet is to change your puzzle and get rid of the world portals. They are buggy and usually confusing for the player.

Thanks ChickenMobile the func_visclusters did the trick! Also I know linked portals shouldn't be used in puzzles I was just making a little fun coop map to do with friends just to make their brains hurt.

I know the issue has been resolved. I just had to add a comment on what ChickenMobile said.

First, when you fire a portal, that is technically a world portal with a texture over it. The blue (or orange) swirling ...thing... you see around the opening is merely an animated texture that Valve overlayed on the World Portal.

Second, LINKED world portals are not the issue. The issue is the game engine. Yes, a linked_portal_door renders things oddly. However, a regular world portal does the same thing.

Valve never tested the visual stability of the world portals because they were not planning to use them in the final game. They failed to think about the fact that portals fired from the portal gun have the same problems since they are essentially the same thing. So using world portals will remain problematic until Valve gets off their collective butts and fixes the game engine.

As to being confusing to the player, speak for yourself ChickenMobile. Not everyone is going to be confused by the shift in spacial orientation. After all, some of the puzzles in the retail game RELY on this effect. I, for one, do not have a problem with reorienting myself in space like this.

Actually, there's a rather large difference in the code between how normal portals and world portals are rendered. Since a lot of code is shared I would consider them both portals, but use the word "world portal" to refer exclusively to a linked_portal_door entity, and "normal portal" for a prop_portal.

What I don't get it that I'm 99.9 % certain that I have used linked portal doors in the past and I could see the props through the portal even if I wasn't looking DIRECTLY at them, but through the portal. I've seen other maps do this to and I highly doubt they used func_viscluster's for everything, so do I have another problem, or have world portals always worked this way and I just haven't noticed yet?

EDIT: Also the func_viscluster's have stopped working and I have no idea what I did. Could someone explain to me the "proper" way of using them so that I can keep a prop rendered even if I don't look at it so I can see it through the world portals?

Sockdude wrote:
EDIT: Also is there any other way to keep a prop rendered when not looking at it without func_viscluster's because it seems to only work if the entire map is incased in one which causes lag.

Try making a visclusters with two brushes, one filling the room on one side of the linked portal door, and the other filling the room on the other side. Tie these to the same entity so that you will always guarantee one room will be rendered while you are in the other. Hopefully this should help without impacting the performance too too much.

I've tried everything but for some reason the visclusters just stopped working. The only thing I've done before it stopped working was add a coop start and finish room. Do you know what could be causing this problem?

EDIT: I have removed the coop rooms so it is just like it was when it was working but the visclusters still won't work no matter how I put them. Could there be some sort of setting preventing it from working?

your graphics settings will change how many portals are rendered through, but you just have to accept that maybe you will have this problem =\

BenVlodgi wrote:
your graphics settings will change how many portals are rendered through, but you just have to accept that maybe you will have this problem =\

I actually wonder why they had to "improve" the graphics options screen and remove ability to tweak amount of rendered portals and stuff like that.

The HL2 kind of options menu would have been better for low-end machines as you wouldn't have to keep shader level on minimum because of overused reflections, bloom and swaying vegetation.

I apologize for off-topic.

JakeeeD wrote:
BenVlodgi wrote:

your graphics settings will change how many portals are rendered through, but you just have to accept that maybe you will have this problem =\

I actually wonder why they had to "improve" the graphics options screen and remove ability to tweak amount of rendered portals and stuff like that.

The HL2 kind of options menu would have been better for low-end machines as you wouldn't have to keep shader level on minimum because of overused reflections, bloom and swaying vegetation.

I apologize for off-topic.

The reason for this is probably rather easy: Portals seeing other portals create the so called Droste Effect the computer could calculate this infinitely; and also the objects in it. However; there will be infinite amounts of players being rendered; one prop will be calculated infitly etc etc; causing a horrible problem.

The team at valve decided that seeing through four portals was enough; if you put some orange gel down and create an infinite run; you;ll always see two sets of working portals; then a closed one. In coop you can see all four portals at the same time as well. These are the cases that exist in the game and so that limit is perfect.

If you're messing with world portals it is possible to create more than 4 visible portals at the same time. This will cause glitches because it is limited to four.

I think it's not a random variable in the settings because in the normal game no-one would notice.

Lpfreaky90 wrote:
Portals seeing other portals create the so called Droste Effect the computer could calculate this infinitely; and also the objects in it. However; there will be infinite amounts of players being rendered; one prop will be calculated infitly etc etc; causing a horrible problem.

The limit was 9 in the original game (according to max setting for rendered portals) and they told in the commentary about some trickery for that "hall of mirrors" effect (copying and downscaling the rendered portals to the ones where it wouldn't matter anymore etc.), so I don't think it would be a problem.

Of course they have probably rewritten the whole portal rendering code, so they render differently in Portal 2.

(The textures have some oddity too. Even on full settings, textures decide to stay muddy and ugly but there's bloom and reflections everywhere. Woo. I would prefer HQ textures over that shining and blooming, but the game just decides my GPU wouldn't be capable to display a couple of 2048x2048 textures instead the gloomy doom of bloom.)