Skip to content

Conversation

@Sanakan8472
Copy link
Contributor

  • XR support
    • OpenXR plugin added
    • Moved companion window logic into XRWindow base class
    • Basic input support
  • Various camera related fixes to support XR
  • Renamed existing VR classes to XR and moved all XR interface code into GameState/XR
  • Fixed deployment of release build dependent binaries. Both debug and release dlls are now source files and switch deployment depending on build target
  • Removed particle node from HololensRenderPipeline as it is not supported
  • Added ReplaceExisitingNativeObject for texture resources

Copy link
Member

@C-Core C-Core left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🕐

Comment on lines +821 to +823
// EZ Forward is +X, need to add this to align the forward projection
const ezMat4 viewMatrix =
ezGraphicsUtils::CreateLookAtViewMatrix(ezVec3::ZeroVector(), ezVec3(1, 0, 0), ezVec3(0, 0, 1));
const ezMat4 mViewTransformLeft = viewMatrix * poseLeft.GetInverse();
const ezMat4 mViewTransformRight = viewMatrix * poseRight.GetInverse();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This may depend on the coordinate system configuration, which is set in the ezWorld. @C-Core should this be handled here?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, if you want to make this future proof, get the coordinate system provider from the world to obtain the forward axis etc


In reply to: 423524360 [](ancestors = 423524360)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok I'll put that on my list of things to improve. Too big of a task to do in this PR but might be a good idea to do that before reviving the OpenVR plugin,

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Frankly, I wouldn't mind ignoring this for the time being. Was just pointing it out, but in practice it's not a problem.


ezGALResourceFormat::Enum ezOpenXR::ConvertTextureFormat(int64_t format)
{
switch (format)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should remove ezGALResourceFormat at some point and just use ezImageFormat everywhere instead.
(@marcappelsmeier)

You can use ezImageFormatMappings to map between DXGI and ezImageFormat.

You can then use ezTextureUtils to map from ezImageFormat to ezGALResourceFormat.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll use that now for the color formats but I still need the switch case for the depth format as they are not in the image format enum.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, maybe it would be best to extend that then? I guess it's not in there, because a DDS file can't use the format. Again, not high priority, but we seem to have a proliferation of custom image format handling code.

@HeadClot
Copy link

Got a question for @Sanakan8472 Will this plugin support OpenVR? Just curious.

@Sanakan8472
Copy link
Contributor Author

@HeadClot this PR will only add OpenXR as an implementation to the XR interface but the same interface will support OpenVR in the future. There is still old code in the repo for OpenVR support that I'll get back to a working state again soon as iteration times are much better in OpenVR compared to OpenXR when using a Windows Mixed Reality HMD.

* XR support
  * OpenXR plugin added
  * Moved companion window logic into XRWindow base class
  * Basic input support
* Various camera related fixes to support XR
* Renamed existing VR classes to XR and moved all XR interface code into GameState/XR
* Fixed deployment of release build dependent binaries. Both debug and release dlls are now source files and switch deployment depending on build target
* Removed particle node from HololensRenderPipeline as it is not supported
* Added ReplaceExisitingNativeObject for texture resources
@Sanakan8472 Sanakan8472 merged commit fabe5f0 into dev May 21, 2020
@Sanakan8472 Sanakan8472 deleted the user/cm/openXR branch May 21, 2020 15:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants