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.
2 Likes
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.
3 Likes
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.
2 Likes
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.
4 Likes
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. (HMD Geometry Database | Collected geometry data from some commercially available VR headsets.).
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.
2 Likes
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
2 Likes
This makes me a little worried about the future of âcanted viewsâ in OpenVR/SteamVR.
3 Likes
âŚ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âŚ
2 Likes
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⌠
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? 