Official Composition Layers Experimental Package is now available

How about HDRP support?

 

Could this be part of the Open XR package instead of having yet another package to deal with?

 

This is so very cool! Kudos to the XR team who are making a lot cool releases recently.

Saw "Behind the scene there is a hidden camera that captures the texture of the Canvas" in the Composition Layer UI section. Is it possible to use it as a standalone feature to get the texture of UI canvas?

Can't even count how many times I had to set up custom layer and camera for capture canvas texture in Unity. I am sure a lot of Unity devs working with UI could use this streamline process.

 

Awesome!

I was looking on the Provider implementation guide
https://docs.unity3d.com/Packages/com.unity.xr.compositionlayers@0.5/manual/provider-guide.html

I want to implement WebXR Layers. For that I need a reference to the Texture or RenderTexture of the layer, to then use in WebGL calls when the WebXR API allows that.

Just to make sure that I got it right:
When a developer sets a CompositionLayer component with TexturesExtension component, I understand that I can get the texture reference from the TexturesExtension data.

And it's the same when a developer sets Composition Layer for Interactive UI, the Projection Eye Rig will have a CompositionLayer component with TexturesExtension component that renders the XRI Rig.
Then I can get the RenderTexture reference from its TexturesExtension data?

There are no native graphics calls that Unity does for this? It's all on the provider to implement?
If so, that's great

 

Installing another package is not the end of the world, but there definitely seems to be a trend within Unity in recent years, "let's just do whatever is easier for us". User ease of use doesn't seem to be a priority anymore.

And while I'm complaining, it would be good if the documentation showed an example of the difference using Composition Layers would make for a UI to give devs an idea of whether it would be worth implementing.

 

Thank you for providing early access to the feature for feedback! So far it looks really good. Are there plans to also expose the "Default Scene Layer" through this package? At the moment there doesn't seem to be a way to customize it and add extensions to it, such as the Color Scale and Bias extension.

And the passthrough layer also doesn't seem to be exposed. Is that planned?

 

Thanks for releasing this package! It's been a long time coming. I would also like to author a standalone implementation of XR_FB_passthrough, I've had a pure c# version stubbed for a long while that only required the layer submission to finish it off. Is this now possible with this package?

 

Hi Sam, sure thing.

It's less of an issue with layers and more OpenXR in general. At the moment I feel that the point of OpenXR is failing, especially where Android is concerned; we have the standard, but each device vendor is shipping their own SDK and implementation of the same loaders/extensions that are incompatible with each other. For example, Pico's OpenXR implementation does support XR_FB_passthrough, but I can't use Meta's SDK to address that, because it's wrapped up in the OVRManager shared binaries that are specific to Quest, and vice-versa. Each vendor's SDK complains when the opposing vendor's device input profiles are present, even though they'd do no harm as they wouldn't be loaded. Ultimately, if this was a pure OpenXR system akin to something like StereoKit, then if a feature wasn't supported it would just be ignored. There's no reason we can't have a single build across OpenXR devices. This is before we get into the politics of the various Platform APIs!

For context I'm one of the developers of Open Brush, and we currently have 5 separate Android builds for what should ideally be 1, 2 if you count China specific builds. https://github.com/icosa-foundation/open-brush/actions/runs/8160767392, all blocked by various artificial limitations of the vendors, even though the underlying spec should enable them to be a single build.

Therefore, I'd really like to build our own suite of extension implementations that live outside the vendor SDKs, where we can use the cross platform loader and guarantee portability. I've already authored a version of XR_FB_display_refresh_rate (https://gist.github.com/mikeskydev/8e27668eade137a1085843868fbc6269) that works, and I'm wanting to see how far we can take it. This was my WIP of XR_FB_Passthrough: https://gist.github.com/mikeskydev/5f52bd25cd40f67a1b753dd6abd95ffe

/rant! Thanks for listening

 

How can we capture a screenshot when using OpenXR layers? Unity's screenshot capture function only captures eye buffer but not other layers.

 

So, just to be clear about the intended use here as it seems like this isn't the case in the docs.

But, one of the main uses of compositor is to render "something" while transitioning scenes or doing heavy loads. However, this says disabling the object disables the composition layer, and I'm expecting the objects to be disabled on a scene load...

https://communityforums.atmeta.com/...-in-Unity-like-when-using-SteamVR/td-p/611801
https://forum.unity.com/threads/oculus-compositor-overlay-loading-screen.498430/
https://developer.oculus.com/documentation/unity/unity-ovroverlay/

Does this mean it won't actually work for changing the color on scene loading? In which case, it would make more sense to not use this, switching OpenXR for Oculus SDK, and using ovr-overlay?

I'm just trying to understand the full use case here and maybe its because this is being called Composition Layer instead of Compositor, and being used to render stuff during the scene instead of when the headset is under a performance load and trying to stop screen tearing between scene loads.

 

Also, just to be share on why I'm trying to use this - this thread was linked to on that question on the forums by Unity staff as the solution, but doesn't appear to show how that is possible in the documentation.
https://forum.unity.com/threads/openxr-compositor-layers.1197517/

 

I haven't tried it with this particular use case yet, but perhaps you could have your loading compositor layer on an additional scene that is additively loaded? whenever you need to switch main scene, you can do so in the background.

 

Thank you for the feedback - I did debate trying this to see if it would work. I ended up removing it for now anyway, as it was blocking Video Players from rendering to the scene, and I recognize it is in experimental phase.

I'll definitely keep it in mind should we return to it down the road

 

Is there an ETA when this will get out of the experimental state?

 

There is clearly a feature update planned for single pass rendering etc. An ETA for V1 feature completion would be very useful.

 

Thanks for the response! I have looked into the OpenXR (Meta) packages, but it seems very heavily aimed at AR Foundation, and I notice it has a hard dependency on AR Foundation rather than it being optional. I'd rather use the standard XR setup and call Start/Stop as I feel like it. I can see how I might be able to alter this plugin to achieve what I was aiming for, however.

 

I am trying to use Projection Eye Rig to pass several content layers to the OpenXR runtime. That seems to be working for a few seconds, but will then result in a crash of Unity Editor. Furthermore, depth submission seems to fail when using any layer on top of the default scene layer. Are these known issues? Any advice on how to improve?

 

Update: Finally had time to look at this. I was able to get my previous implementation working! All that was missing was this new function to submit layers to XrEndFrame via

OpenXRLayerUtility.AddActiveLayersToEndFrame

provided by this new package. https://x.com/mikeskydev/status/1783896907615535207?s=46