Hi Robert,
On Sun, 11 Jul 2021 at 09:31, Robert Osfield wrote:
> On Sun, 11 Jul 2021 at 07:43, James Hogan wrote:
>> I'm not sure I follow this. Doesn't OSG's own stereo method use slave
>> cameras too, or does it somehow avoid multiple cull traversals?
>
> The built in strereo is one of early
Hi James,
On Sun, 11 Jul 2021 at 07:43, James Hogan wrote:
> I'm not sure I follow this. Doesn't OSG's own stereo method use slave
> cameras too, or does it somehow avoid multiple cull traversals?
>
The built in strereo is one of early parts of the OSG, so 20+ years old,
and can be found in
Hi Mads
On 15 June 2021 18:42:29 BST, Mads Sandvei wrote:
>> OSG already has a concept of stereo (which currently this code
>doesn't
>interact with)
>OSG's multithreaded rendering works better with its own stereo method
>than
>the slave camera method, so i would recommend integrating with
On 22 June 2021 23:10:32 BST, James Hogan wrote:
>> > Performance is currently terrible. CPU usage and frame times don't
>seem high, so its blocking excessively somewhere
Fortunately the main performance issue turned out to be my misinterpretation of
XrSwapchainSubImage::imageArrayIndex as
On Tue, 22 Jun 2021 at 22:15, James Hogan wrote:
>
> On Tue, 15 Jun 2021 at 17:30, Robert Osfield wrote:
> > My recommendation would be to move your code into it's own osgXR library,
> > but stick with the osgViewer::ViewConfig approach as this as it should make
> > it easier for developers to
> Won't that result in fixed velocity objects not moving smoothly though,
since the objects won't necessarily be in the positions they should at the
time of display? (I'm not getting high enough frame rates yet for this to
be apparent, so nvidia on linux not supporting async reprojection is the
Hi Guys,
I'm just lurking on this topic so can't provide guidance on low level stuff
at this point, on the high level side I provide a bit of background that
might be helpful.
I'd like to chip in is that OVR_multiview functionality integrated into the
MultiView branch will be rolled into the
On Tue, 15 Jun 2021 at 21:05, Gareth Francis wrote:
> Not much to add specifically for openXR yet, but happy to test or debug if
> blockers/quirks pop up (windows or linux, htc vive, nothing fancy)
Thanks Gareth!
Cheers
--
James Hogan
--
You received this message because you are subscribed
Hi,
On Tue, 15 Jun 2021 at 18:42, Mads Sandvei wrote:
> I have some experience integrating OpenXR and OSG from my work on OpenMW-VR.
> I'll share some of what i've learned
Ooh, thanks, I'll have a peak at how you've gone about it.
> > OSG already has a concept of stereo (which currently this
On Tue, 15 Jun 2021 at 17:30, Robert Osfield wrote:
> My recommendation would be to move your code into it's own osgXR library, but
> stick with the osgViewer::ViewConfig approach as this as it should make it
> easier for developers to switch between desktop and VR configurations - a
>
Hi all,
I'm the one looking into vsg vr (at least when I get the time, slow
progress overall). See https://github.com/geefr/vsg-vr-prototype for
progress so far.
Only using openvr for the moment, but this looks very relevant, some
interesting concepts to consider if my stuff ends up with XR
Hi
I have some experience integrating OpenXR and OSG from my work on OpenMW-VR.
I'll share some of what i've learned
> OSG already has a concept of stereo (which currently this code doesn't
interact with)
OSG's multithreaded rendering works better with its own stereo method than
the slave
Hi James,
I don't have a work VR headset to test against right now so can't pitch in
with any testing or insights into OpenXR. I did a quick look over your
changes and can share a few thoughts about general direction.
My recommendation would be to move your code into it's own osgXR library,
Hi
On Monday, 24 June 2019 at 23:07:53 UTC+1 davidg...@gmail.com wrote:
> Greetings!
>
> I guess that I'm going to gripe on this subject like I did a year ago!
> I know that OpenXR is at least in Open Bata and I was wondering what
> progress anyone has made incorporating it in OSG.
>
> While I
14 matches
Mail list logo