Where is this function implemented? I can trace it in Visual Studio to the class interface (TubeBloomPrePassLight), but is says Assembly-CSharp.dll which seems strange.
1 Like
Yes, Assembly-CSharp.dll is basically the game its self. I’ve just decompiled it with dnspy (you can use any decompiler you would like to, though) to check out the source code.
(You can find Assembly-CSharp.dll in the Beat Saber_Data\Managed folder in your Beat Saber directory).
2 Likes
This beat saber issue need to be solved
1 Like
Please create a ticket from support: https://pimaxvr.com/pages/feedback
@brian91292 Just for the record I made another step forward, not in fixing the issue, but in understanding the mechanics and I have to correct all my previous statements about the projection matrices, because I was ignorant :). I am going to edit all my previous posts on the subject.
Now I finally figured out how the whole stack works I can confirm that all the matrices used in the game are correct in the sense that are correctly derived from the (supposedly correct) values the headset provides. Basically:
-
There is a function
IVRDisplayComponent::GetProjectionRawwhich the OpenVR driver of the headset implements and which returns the tangent values of the angles for the left, right, bottom and top clipping planes (from the central axis) for the particular eye projection.
This function basically defines what is the horizontal and vertical FOV of the headset separately for the left, right, bottom and top sections.
Which means the matrices can differ, and they do, for both Vive and Pimax (but they differ for completely different reason than I thought originally). I found this explanation why they differ for Vive (Projection matrix model of the HTC Vive - Virtual and Augmented Reality - GameDev.net). For Pimax I guess they differ because outward part of the view is larger than the inner one. -
Unity adds its own values for the near and far clipping planes to those raw values reported by the headset and computes the projection matrix for each eye, which is the one we see in the game.
-
By chance when looking around I also found a bug in OpenVR
IVRSystem::GetProjectionMatrixwhich I reported on GitHub, but which does not affect Unity as it seems that Unity calculates the projection matrix itself, and uses only the raw values provided by the headset. -
I have also verified that the view matrices (=transformation matrices) for individual eyes in BeatSaber are consistent with what OpenVR (and subsequently the headset) advertises as the headset view. In other words, Unity correctly process the geometry Pimax reports with angled views (when PP is off). Which was kind of obvious because the world (apart from the particular bloom effect) renders just fine with PP off.
So the conclusion is that the transformation (=view) matrices and the projection matrices are rock solid and if there is anything wrong it is the actual rendering of TubeBloom effect.
@brian91292 You probably already knew it, but I had to do my homework, after I realized my blunder with the projection matrices. 
3 Likes
Very cool, nice job! I guess we can just hope that the Beat Saber devs are able to solve the issue then, I’ll be sure to mention it again if it’s not resolved on the next beta version.
1 Like