Some thoughts on the new PP HAM on Pimax 8k+ and 8k-X headsets

[risa2000]

Thanks to @generic I got the hmdq data from his brand new Pimax 8k-X and pushed the visualizations and the data to the HMDGDB.

When doing just a quick check over the files I noticed that the stereo overlap on 8k-X is a bit smaller than on 8k+ (or any other Pimax) headset. This might be related to the smaller LCD as being already advertised by Pimax. What bothers me more however, is the way the new headsets (8k+ and 8k-X) handle the HAM.

When I posted my suggestion to modify the HAM in parallel mode so it matches the (projected) shape of the HAM in the native mode (https://community.openmr.ai/t/pimax-5k-parallel-projection-ham-mod/22952) I assumed two things:

1. The HAM in the native mode is correct.
2. The HAM depends on the hardware features of the headset.

The first point is an assumption, but considering the fact that the HAM in all native modes (Large, Normal,…) is basically the same mesh, probably not correct.

The second point is the very reason for the HAM. It assumes that while the FOV for the rendering is always defined as rectangular (because this is how the rendering nowadays works), the lens shape, the frame shape, the shape of the displays, etc. all limit it mechanically so the user cannot see the full rectangle but only a certain part of it. This is basically the visible FOV.

This FOV does not depend on what FOV the application renders as it is pretty much defined by the headset design, so setting the headset to Large, Normal, Small, etc. should not affect that shape. Which in other words means, that if the Large FOV seems to be limited by the HAM at the extreme periphery, the Small FOV should not be limited at all as it is (visually) only a smaller subset of the Large, with its periphery at the spot where the Large one has still long way to go.

Anyway, what I am saying is that I doubt that the native FOVs are defined consistently in regard to the actual design features of the headset. Basically on any Pimax headset.

Now coming to the new HAMs Pimax introduces for the parallel projection modes:

The original HAM on Pimax 5k+/8k in Large FOV and PP on looked like this:

The new one for 8k+ looks like this:

and for 8k-X even like this:

The green shape is the projected HAM from the native mode (for comparison) the red shape is the actual HAM in parallel mode.

Theoretically, the “inner” shapes should be aligned (as I visualized it in my post about the HAM mod), but here the red is limiting the FOV more than the green one, which does not make much sense (as per point 2) above).

So either the native HAM is not defined correctly (and masking less than it should) or the red one masks more than it should! I guess only someone with the headset can confirm that, by looking into the same scene (or using RoV tool) with parallel mode on and off and comparing the visible vertical FOVs. If it does not change then the native is still a “bit loose”, if it does change then the PP HAM is too restrictive.

The discrepancy is somehow present on all types of FOV in the new headsets (they are probably on the old ones with the new firmware too, but I have not yet verified it) but in a different manner. (You can easily compare it by looking at the different HAM images for different FOVs in the database).

It seems that Pimax created a new HAM for the parallel mode and then used the same mesh in all FOVs, which, as the visualized projections show, does not work, because the projected HAM has to be calculated individually for each FOV (basically the way I did it in my mod).

[MrAhlefeld]

Hi Risa

Once again might fine work, and thanks to @generic as well.

@PimaxUSA @SweViver @Alex.liu @PimaxQuorra
Please have your engenieers read this full post and all the information, as there seems to be some optimization of the HAM maybe both in Native and PP mode.
This is valuable info and a low hanging fruit ripe for the picking

Edit:
@risa2000 if Pimax somehow does not pick up on this and implement it, could you please share how you modded the HAM yourself, because IIRC your original post was made well over a year ago

[neal_white_iii]

Right, a HAM optimized for each mode would provide a higher framerate.

[jojon]

While it looks like at least the inner corners would lack their rounding, even if case were: Does the above render take into account the eventuality of the height of the PP viewplane potentially having been optimised, by way of being cropped relative to the native one (…and then composited to fit, with “ghost” margins “unplotted”, in reprojection)?

(EDIT: I reckon whilst you might not have access to such a “margin”, applied late-stage by piserver, the frustum still gives you the right angles to line up, without “unduly normalising” the height at the “hinge” between the planes… so to speak… but still… :P)

[risa2000]

@jojon

Does the above render take into account the eventuality of the height of the PP viewplane potentially having been optimised, by way of being cropped relative to the native one (…and then composited to fit, with “ghost” margins “unplotted”, in reprojection)?

The rendered visualization takes into account the same information the application (which renders the scene) has, i.e.:

1. The advertised FOV
2. The advertised HAM

The application is supposed to render the HAM into a stencil buffer (or whatever) and then render the scene defined by the given FOV.

The only thing which the visualization does is that it displays the HAM from the native mode projected into the same plane as the HAM for PP mode so you can compare the two.

It does not need to do any side-guessing about what Pimax software might do with the rendered image later, because it is irrelevant. It has to respect the FOV and the HAM provided by the OpenVR API.

[risa2000]

@MrAhlefeld

if Pimax somehow does not pick up on this and implement it, could you please share how you modded the HAM yourself, because IIRC your original post was made well over a year ago

Well, my post, while already old, is still valid .

If you are interested in how I did it: I rendered the native HAM (in the corresponding FOV) and projected it into the parallel plane. Then manually in Blender defined the HAM which matched the projected shape while respecting the original FOV. Exported the mesh, transformed it into texture UV space (in which the HAM is defined) and used my debugging filter driver to inject the HAM into OpenVR runtime instead of the one from Pimax driver to test that it works. It worked.

[jojon]

@risa2000

It does not need to do any side-guessing about what Pimax software might do with the rendered image later, because it is irrelevant. It has to respect the FOV and the HAM provided by the OpenVR API.

…which makes sense, but none the less: Better ask than assume.

[coverman]

I saw a screenshot in NoMan’s Sky that resembled the pattern in that figure.

PP/on

PP/off

[risa2000]

@coverman

screenshot in NoMan’s Sky that resembled the pattern in that figure.

Actually, what you saw should exactly match the HAM shape. The only thing, which may look differently is the shape of the HAM in PP off mode, but this is because what you see in the screenshot corresponds to the rendered image + HAM shape in canted plane.

In other words, what you see is correct.

[NextGenVR]

Sounds interesting! I’ll try this out when I receive my 8KX.

Can someone explain to me what HAM stands for?

[DrWilken]

https://www.reddit.com/r/Pimax/comments/anm7s9/what_does_hidden_area_mask_do/

There are some pixels on the rendered rectangle that are wasted because they end up outside the visible area after barrel distortion. The mask blocks those pixels before rendering, so you don’t waste time calculating them. It gives a performance boost, but can occasionally cause visual issues.

[neal_white_iii]

@NextGenVR

Can someone explain to me what HAM stands for?

Hidden Area Mask. It’s a speed up. It prevents the GPU from drawing stuff you can’t actually see (due to VR headset transforms, which would place those pixels off-screen).