Who is leading the effort for the viewport-configuration of Projection Caves?
I am working with single-projector caves using fisheye lenses.
I am particularly interested in a needed feature, the 2D-warping of the output image so it will match the optical fiducials of the cave.
The output image stream must be calibrated to the projector and cave, a unique warping specific to the dimensions and shape of the room.
Essentially, texture mapping a square fisheye image to a rectangular image that is immediately input to the projector.
There are no WG members publicly working on any CAVE-related extensions, though several of us are interested. You’re welcome to start drafting an extension (or opening an issue for discussion) on the OpenXR-Docs github, I’d be happy to let the interested parties (besides myself ) know.
In terms of the output warping: that is squarely in the realm of the runtime, the application does not need any awareness about it. You might consider starting with the open source Monado runtime, which I help lead development of. https://monado.freedesktop.org/ I think we should be able to handle the warping without any api changes, I think the only change we might need is having the fov change each frame (due to tracking).
In the development of openXR cave projection, I would recommend taking a look at Extensible 3D (X3D), Part 1: Architecture and base components, 42 Texture projector component.
Some other parts of the X3D spec might be useful in constructing the openXR spec.
The texture mapping is particularly Important for projection in caves, because it visually calibrates the physical last step to the user (i.e., projector, lenses, cave shape).
I will open an issue on GitHub.
Is this a reasonable link for what you referenced? Extensible 3D (X3D), ISO/IEC 19775-1:202x, 42 texture projection component That is the kind of thing that sounds useful for runtime implementation, particularly generic implementation, but that OpenXR is unlikely to actually expose to the application/user, thus outside the scope of the spec itself.
In terms of application API (the OpenXR extension required):
My current best thought is that we create a view configuration that is basically “bag of n views” where the number of views is variable. Alternately we may have a “bag of n stereo pairs” where each of the pairs has two views that are fairly closely aligned such that things like jointly culling those two views and/or using a multiview rendering extension might be useful.
In terms of implementation (because I’d love to have Monado work on CAVEs):
If you were to describe your CAVE in a way that would let me (a runtime developer on Monado) render to it, how would you describe it?
- Would it be using an X3D file? (Didn’t know it could describe that, pretty nifty - does any existing VR runtime system use a file like that as a config?)
- My previous experience in CAVEs is mostly VR Juggler based, which has an XML format for describing view planes (no distortion!) or tracked (e.g. head worn, though I think there too, without distortion) only. e.g. vrjuggler/C4.displays.closed.jconf at master · vrjuggler/vrjuggler · GitHub
- Based on my more recent work with OSVR, OpenXR, and Monado, I’d generally/generically say that I’d want to know a virtual display plane location/size (of which the real display is a subset, I think) and a distortion map/mesh of uv pairs. The distortion map would be just as we use for distorting HMD images, and e.g. might actually be a full-size array: same dimensions as the scanned-out display content. Our existing distortion pipeline basically computes each pixel in the scanned-out image by sampling the distortion map at the same coordinates to find the u,v pair to use when sampling the flattened, composited layers (basically, when sampling the texture that the application rendered and submitted).
As a CAVE Hardware provider this is of great interest to us, but we have no clue about how to start with OpenXR, do we provide our CAVE specs (we have multiple and is extensible so customers can run custom setups), do we write software apps to interact with OpenXR, how would someone run an OpenXR application in our environment, etc.
Would love a call or a link to a simple ‘how to’ guide for enabling multiple displays so that we can jump on this ASAP!
Hi Max, what is your website?
For some reason I cannot post a link, the forum keeps blocking me.
If you search for FULmax you will find us
You’d want to build a runtime for OpenXR, which would probably start from Monado (our open source one) and you’d also need an OpenXR extension to add a form factor and view configuration. There are several interested, so if you come to the github or (better) join Khronos, we’d like to get it going for you. I haven’t used a cave since 2014 but I am still nostalgic…
This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.