Objects popping in and out in Steam Home

Was there ever a fix for the objects popping in and out at the edges of the headset screen?

I see it in Steam Home a lot and it annoys me incredibly.


Pp sometimes works & hidden Mask may also work.

Otherwise no as this is likely due to how program was created & thinks you can’t see that area yet.


BUT! Can’t we do something, in Pitool for instance, to increase that outer limit so certain games won’t do the poppings? I hate it, ab-so-lute-ly hate it.

I am willing to give up rendering power if that’s what it takes. The popping at the edges completly ruin the VR experience of immersion for me.

1 Like

I don’t experience this in most games when parallel projections is enabled. What experiences outside of the home environment give you this issue?

Pimax can’t do much, the issue exists within the game engine code. Occlusion culling for many VR titles is set for an FOV of 110-130 simply because they were written without pimax in mind. It’s a smart way to improve performance, but I do agree it’s immersion breaking on the pimax when this happens. In Unity, the ‘camera FOV’ determines at what point objects are occluded.

Really all you can do is lower the set FOV unfortunately if this bothers you enough. I haven’t seen it in the titles I play luckily.


Had it in Bigscreen where it drove me nuts and I made the post

1 Like

This is a game engine problem, which, most likely, calculate the FOV for culling wrong. There is nothing Pimax can do about it.


The thing is, if we could somehow increase the rapported FOV to the game that does the calculation wrong, we could arrive at a setting that works. It will be costly but it might solve that problem per game.

People were reporting that turning PP on fixes the popping. If you look at the reported geometry for native and PP modes, you can see that the total reported horizontal FOV in both modes are exactly the same. (https://risa2000.github.io/hmdgdb/).

The problem is that while the total FOV is the same it is covered differently in each mode and my assumption is that in the native mode the game engine “forgets” to take into account canting of the views and thus arrives at a lower FOV than expected. This is a bug in the FOV calculation in the engine.

If you however believe that the problem could be fixed at the cost of increased performance impact and a loss of quality (as you suggest) you may simply turn PP on, because this is exactly what PP does.

But this doesn’t work for Steam Home, which is kinda funny since it’s from the creators of whole VR universe

Why it does not work in SteamVR Home is a good question, only Valve can answer. They may as well have the FOV hardcoded, or whatever.


It works for me, at least with the Steam environments I have installed, with PP activated there isn’t objects popping anymore

1 Like

No less when one consider that their own headset also has canted screens (…and I can confirm that if one sets SteamVR to “raw” camera mode, the overzealous culling at the right edge in SteamVR Home happens with the index, too). :7


This makes me a little worried about the future of “canted views” in OpenVR/SteamVR.


…when even these guys can’t be bothered, yes…

On the other hand: Whenever more manufacturers build larger FOV headsets, it will no longer be possible to ignore. I am hoping for raytracing with curved view planes, myself, some time before the heat death of the universe. :7

(EDIT: Hmm, maybe one should check whether anybody has actually taken it upon themselves to file a ticket on the matter to Valve’s bug tracker… Tomorrow maybe… :7)

1 Like

Hopefully this “zooming in” that was reported for the current Alyx internal build when used with Pimax isn’t the new “solution” how to cope with wide fov headsets now. Sure, easy to implement - but… nooo!

One little thing I can relate from experience, is that, before I sold my 5k+, when changing back and forth between devices, I got a strong impression that everything appeared much closer to me in it, and larger - indeed kind of “zoomed in”, than with the Index – regardless of fitting and settings (with both devices).

-This is what I find to be the strength of the Index, compared to every other HMD I have owned; Everything looks “right”: Geometrically correct – were and how it should be, with a profound (but not exaggerated) sense of “room”.

Hopefully Pimax’s purportedly improved calibration and distortion correction will have sorted that, and trickle down to the older models sooner rather than later.

1 Like

The new headsets were said to have better distortion profiles that fixed a lot of the edge distortions. I’m just not sure why this profile isn’t already available for older headsets. Makes me wonder if it’s a marketing strategy or that they did something with the new panels and/or lenses that isn’t possible with older models.

1 Like

As far as I understand the zooming in is a decision of the game - how to cope with non-default aspect ratios. Either they can extend the view, so you see more. Then the culling algorithm has to cope with non-default aspect ratios though, so objects don’t pop in and out as described in that thread.
Or they simply keep the horizontal viewing angle constant for all aspect ratios and cut off vertically for wider aspects. Which leads to the “zoom-in” effect.
The latter is of course easier to implement. But not what wide aspect ratio HMDs were designed for…


Who knows… Everything we have heard suggests that the lenses are exactly the same as in the 8k and 5k+, and if that is the case, I can imagine no reasonable obstacle whatsoever (…other than the matter of individual unit calibration, but that is “just” the topping on the dish), to straight up applying the improved profile to output for the older models. :7

I am not following, I’m afraid – not that it is difficult to vex the addled old lump of solid bone on top of my shoulders. :7

A box that is one metre wide, and stands facing me, one metre away, should take up 53° of my FOV, on the side, and its projection offset between the left and right eye should likewise correspond 1:1 to how it would appear in real life, in accordance with my IPD – and these dimensions should be the exact same no matter what HMD I am using. This is a non negotiable basic fundamental of VR, propagated by the various VR runtimes the games go through, and not something for individual developers to choose to adhere to or not, other than for things such as deliberately turning you into a small creature or a giant, or playing with perspective, or something, as part of their experience.
There is no valid leeway for zooming, or panning-and-scanning when we are mimicking a “real view”, rather than rendering to a picture shown on a “loose” display panel, on one’s desktop, or printed in a magazine; The aspect ratio is in angular measurements, and determined by the capabilities of the HMD, entirely supplanting any “legacy” formats, that are not relevant in the context.

If I had managed to “slap together” an engine (…not that I, personally and specifically, can put together anything at all, what so ever), that can only render out bitmaps that are, say, 16:9 rectangles, or power of two pixel count dimensions, or only able to project a small selection of fixed discrete fields of view, and on top of that am unable to frame and crop out a suitable arbitrary viewport window within those restrictive bounds, so that proper scale is extracted from it, then how on earth was I able to to do all the actually hard bits, when I can’t do the basic ones? :7

( So ( just in case, but I don’t really get the impression you need the primer )… The culling frustum is its own thing - next to the camera’s, albeit, one would expect, derived from it, and just a simple truncated pyramidoid volume - you could make it any dimensions within the confines of 3D space; Any object whose bounding box intersects that volume will be evaluated for rendering, since the camera can probably see it - any whose don’t are ignored. There is no reason for it to be limited by aspect ratios in any way.
I’d speculate that the offending games are calculating a shared culling frustum for both cameras, so that they can share work between the two views, but simply at some stage failing to take the full transform (with rotation) into account, so that the width becomes the extreme peripheral edges of the two views as if they were facing forwards, instead of canting out to the sides, and counting from the left edge, which would be why it so often occurs only on the right side.)

…or something like that… :stuck_out_tongue:

Asume this is what you see with HMD1 with a 10:4 ratio and (for simplicities sake) 10x4 objects floating in the air - so you can see all of them full screen.

|1 1 1 1 1 1 1 1 1 1|
|2 2 2 2 2 2 2 2 2 2|
|3 3 3 3 3 3 3 3 3 3|
|4 4 4 4 4 4 4 4 4 4|

Now you have an HMD2 with a twice as wide 20:4 ratio. Here you could either increase the amount of visible objects to 20 * 4, so you see more objects (asuming the objects are around the player…). Then the engine has to take care that it renders the additional 5 * 4 objects on the left and on the right side correctly - even though HMD1 users wouldn’t see them. Many engines just remove stuff that isn’t visible anyways to accelerate drawing. So if the engine doesn’t take the wider field of view into consideration then you might see objects disappearing and appearing at the edges - which is obvious, even for people who don’t have another HMD to compare to.

1 1 1 1 1 |1 1 1 1 1 1 1 1 1 1| 1 1 1 1 1
2 2 2 2 2 |2 2 2 2 2 2 2 2 2 2| 2 2 2 2 2
3 3 3 3 3 |3 3 3 3 3 3 3 3 3 3| 3 3 3 3 3
4 4 4 4 4 |4 4 4 4 4 4 4 4 4 4| 4 4 4 4 4

The alternative way to fill a 20:4 ratio HMD is to keep the horizontal angle in a way that you can still only see 10 objects. But cut away the upper and the lower row. Because 20:4 and 10:2 is the same ratio (of 5:1) :

|2 2 2 2 2 2 2 2 2 2|
|3 3 3 3 3 3 3 3 3 3|

So even though you have your entire field of view filled now, you actually see less information than with the HMD1 with it’s narrower field of view. It just looks “zoomed in”. The advantage for the game devs is that they can hardcode the algorithm that determines which objects don’t have to be drawn - optimal for HMD1. For HMD2 owners (who don’t have a HMD1 to compare with) the fact that the view is zoomed-in might be less obvious than if objects would be popping in and out - easier to get away with.
Supporting arbitrary aspect ratios would of course be much better for HMD2. But it needs special attention (and might even be slightly slower for HMD1 as some constants now become variables). Which might not be worth it if the aspect ratio of HMD1 is the 95% case.

Edit: Hm, you might be right, it’s not easy to come up with an actual optimization that would really benefit from hardcoding the horizontal field of view in the culling algorithm. Even if some heuristics constants are used these could be pre-calculated once at the start, asuming the ratio doesn’t change. Ok, slightly more complicated and perhaps not considered worth it? But I don’t know, “we don’t care” might be the most plausible explanation?

Edit2: Found an optimization that would benefit from assumptions about horizontal field of view: Asume you have all your objects organized in an octree (think of hierarchically stacked cubes - 1 that contains everything, 8 sub-cubes that are split into eight subcubes each etc.). Now if you know that the player cannot be further away than that they see the content of let’s say two adjacent side-by-side level 2 cubes (because your level is a dungeon where you know the size of the largest room) then you could in a first step already restrict your drawing to eight level 2 cubes (2 in each dimension) - without any further check.
If the horizontal field of view can be wider, it could be that this simple algorithm would already lead to “popping” objects, as the player might now see objects from three adjacent cubes.

If you increase the number of cubes to consider from 2 to let’s say 4 (the exact number would have to be calculated up front), then potentially a lot of additional objects would be painted (if no further fast-to-calculate culling steps occur). Then the amount of objects and their complexity might not fit to current mainstream hardware anymore. So it might be easier to stay with the fixed horizontal field of view, “zoom in” and keep the framerate up in return.
Not sure whether this is/was an actual consideration anywhere - but it might be? :slight_smile: