Hello,
I’m using Pitool with a Pimax 5K+ for flight simming: IL2 BoS and DCS, with a 1080 Ti
The best setting for me is Pitool at 2.0 and SteamVR at 20%
I’m using the last 121_R211 beta version of Pitool.
As parallel projection makes a huge fps loss in IL2 BoS I wonder why.
And notice the following numbers in SteamVR:
without parallel projection : res = 2359x 2355, 5 555 445 pixels
with parallel projection : res = 2493 x 2944, 7 339 392 pixels
So this explain why I have a so huge fps loss : pixel number is increased by 32% when parallel proj. is activated !
As parallel projection is mainly handling the fact that screen are not aligned, I wonder why it is needed to increase so much the vertical resolution…
10 Likes
That is a very good question. @Sean.Huang, please ask someone to verify that the vertical height really needs to be that large. If it can be reduced, PP would be less of a performance hit. If PP could use 2493 x 2355 in this example, PP would be ~25% faster.
4 Likes
The overhead for PP on was actually 50% more pixels in the old PiTool, so I assume the latest beta is Pimax attempt to make it less demanding.
Edit: I read it wrong about the vertical res.
2 Likes
why increasing vertical at all? the projection correction is about a horizontal problem
2 Likes
its probably due to distortion profil
There is a perspective correction needed on vertical direction too, and it seem to be much more significant.
Imagine how the angled panels would project their shapes on a plane which is parallel to your face (PP on does basically the inverse projection). The outer edge of the panel will get larger (in the projected shape) than the inner edge. I believe the vertical factor is compensating for exactly that.
If this assumption is true it would also mean that Pimax could apply additional hidden area mask to suppress rendering on the unused portion of the image (with PP on).
5 Likes
Just to visualise what Risa explained:
So the viewer’s eye is at the 3D cursor, and the filled rectangle is the no-PP viewplane (n.b: This is drawn as if there was no fov to the right, for the left eye here, just to make is easier to see how things line up, in the figure – in reality the right edge “hinge”, would be farther to the right). Projecting from the camera, through the corners of that viewplane, to a PP equivalent that covers the same field of view, leaves you with the rectangle behind, which is larger both horizontally and vertically.
The filled triangles represent the bits Risa suggests could be added to the hidden area mask.
6 Likes
But that extra resolution is requested from game si it is not used for deformation. We are talking about an angle of ~7,5 ° for each screen, I wonder why that need 30% increase of vertical resolution. In fact I though that it may be in the rendered part that is not diplayed by default…Can you make a real scale drawing ?
1 Like
I’m afraid I do not understand what angle we are talking about here.
The answer to the resolution question lies at the right hand edge in the indeed-not-to-scale figure I posted:
If one look at the left edge, the vectors from the camera encompass the entire length of it, for both the non-PP and PP viewplane, so right there you could use the exact same bitmap size for them both, to arrive at the exact same effective resolution, in Pixels Per Degree.
To the right, however, that vertical edge of the non-PP viewplane only covers part of that of the PP one, so in order to achieve equivalent PPD in PP as in non-PP, we need to render correspondingly more pixels, the top and bottom portion of which will be just thrown away when the image is reprojected to the non-PP output (I am not ruling out the possibility that maybe Pimax already adjusts their hidden area mask, to encompass those bits).
Now: The right edge is right in front of you, and where the the lenses do the most magnification, so we definitely do not want to sacrifice PPD there.
Alas, we currently have to render a rectilinear pixel matrix, with the same density across the entire bitmap (Stuff like NVidia’s “Variable Rate Shading”, as supposedly used by Pimax’s “Fixed Foveated Rendering”, could help here), so we have to apply the same conditions to the left edge, as to the right one, adding pixels on the vertical axis, and oversampling where it is the least needed.
Did that make sense?
(EDIT: One could, of course, render 1:1 at the right edge, maintaining equivalent PPD there, and let the vertical FOV taper to the sides, which would save lots of work without sacrificing resolution, but maybe make it feel a little as if you were looking out from inside a knight’s helmet. :7)
1 Like
The angle the panel holds against the plane parallel to the face is 10°.
I can confirm that in the old PiTool I use they do not, as is shown on ED pics I ripped from the pipeline for PiTool render quality topic. The only hidden area mask applied was for lens (FOV) shape.
1 Like
Could you please provide a link? I searched for the topic, but didn’t find it. Thanks!
Aha. Room left to shave off a percent or two, then. :7
Yes and no. Yes if part of the image is missing for transformation you can either scale the existing part up and loose resolution or oversampling it in order to have the target resolution at the end of the transformation. We are not talking on FoV here, because FoV ans resolution are not direclty linked (because of SS ans thing like the one we discuss). But regarding size changing linked to projection, my point of view is that should be linear for horizontal and vertical dimensions: I still do not understand why vertical res. nedd to be two times increased than horizontal res.
And I though that the angle between screens was 15°.
I don’t know exactly what Pimax does, nor why; It was just explained why there would be an increase on the vertical at all.
Plugging your values into the simple model, I would indeed expect more on the horizontal (assuming sticking with 1:1 pixel aspect ratio), but on the other hand: Projecting from two arbitrary camera-to-viewplane distances (EDIT: …and with the camera assumed centered on it (for small FOV), which is probably not correct (EDIT2: …in fact: Move it to where the intersection is with your values, and it appears you’ll end up with an equal amount of FOV to the left and right, from looking straight ahead)), those still end up with the vertical outpacing the horizontal. Remember that the projection is from the vantage point of the eye relative to the no-PP plane, and as the PP plane tilts away 10 degrees from that, on one axis, it swerves away, and, if it continues, its, in this case left hand edge eventually (much sooner in small FOV setting) ends up hidden behind that of the non-PP one, whilst still sticking up above and below from behind the occluding plane, as you look down along the normal of the non-PP plane.
EDIT3: Illustrating edit2 above:
(EDIT4: Err… Scrap that: That’s viewing 10 degrees off perpendicular from the PP plane - not the no-PP one, with the latter consequently ending up at 20 degrees in the figure, rather than 10; The eye would still need to be farther to the right – Clumsy me. :P)
It was here (https://community.openmr.ai/t/is-it-best-to-fix-pitool-at-a-certain-resolution-like-1-75-or-2-0-and-change-steamvr-ss-or-the-opposite-or-are-they-interchangeable/14897/28). You should look at the “source” image, which is the output from the application. The hidden area mask is represented by the black area in and around the corners.
Just keep in mind it was taken with the old PiTool (1.0.0.91), so we might yet to see how it works in the new one. I am still reluctant to update to the latest beta as it does not seem stable enough (for me).
2 Likes
I understand your concerns. I waited until there was some reasonable feedback. I’ve encountered no new problems (compared to .112), but I’m only using it for 1 game (Elite Dangerous).