OpenXR/OpenVR (virtual reality support), new Python workbench WiP

Have some feature requests, feedback, cool stuff to share, or want to know where FreeCAD is going? This is the place.
Forum rules
Be nice to others! Read the FreeCAD code of conduct!
User avatar
Kunda1
Veteran
Posts: 13434
Joined: Thu Jan 05, 2017 9:03 pm

Re: OpenXR/OpenVR (virtual reality support), arch-friendly update

Post by Kunda1 »

catman wrote: Sat Aug 13, 2022 8:22 pm Is that a different effort from AppImage packages? Thats what most people are used to from Asm3 testing.
AppImage as a solution for FreeCAD packaging was implemented way before Snap was. But now Snap is becoming popular. There is also a Snap package for realthunder's Link branch (what used to be A3 before realthunder made it available for the master branch as an addon, see this ticket for reference). It has 2 channels: stable and edge (aka LinkStage3 and LinkDaily respectively).
catman wrote: Sat Aug 13, 2022 8:22 pm Personally I found it more difficult to get the VR chain up and running. At least on Ubuntu the repositories seem a bit ignorant to VR
Ubuntu repos are notoriously behind when it comes to dependencies (due to Debian). But Snaps and the KDE folk are kicking @ss and make it very possible to conveniently run software.
Alone you go faster. Together we go farther
Please mark thread [Solved]
Want to contribute back to FC? Checkout:
'good first issues' | Open TODOs and FIXMEs | How to Help FreeCAD | How to report Bugs
catman
Posts: 412
Joined: Fri Jan 11, 2019 10:42 pm

Re: OpenXR/OpenVR (virtual reality support), arch-friendly update

Post by catman »

Kunda1 wrote: Sat Aug 13, 2022 8:31 pm AppImage as a solution for FreeCAD packaging was implemented way before Snap was. But now Snap is becoming popular. There is also a Snap package for realthunder's Link branch (what used to be A3 before realthunder made it available for the master branch as an addon, see this ticket for reference). It has 2 channels: stable and edge (aka LinkStage3 and LinkDaily respectively).
EDIT <removed text> So for me its not an option, unfortunately.
Kunda1 wrote: Sat Aug 13, 2022 8:31 pm Ubuntu repos are notoriously behind when it comes to dependencies (due to Debian).
Oh, yes I agree. But 22.04 just came out. Thats about the most current one will ever get in a Ubuntu repository. However, in the cases I meant not dependencies were the problem but missing package compile options. There was just nobody complaining since so few people are using that stuff in Linux at this time for non-gaming.
Last edited by catman on Sun Aug 14, 2022 2:16 pm, edited 1 time in total.
User avatar
adrianinsaval
Veteran
Posts: 5541
Joined: Thu Apr 05, 2018 5:15 pm

Re: OpenXR/OpenVR (virtual reality support), arch-friendly update

Post by adrianinsaval »

catman wrote: Sat Aug 13, 2022 8:43 pm Well, the problem with snap is that it does not work offline (I read somehwere that Canonical wants to make it paid option). I think its a wise idea to keep production systems offline if possible. So for me its not an option, unfortunately.
Wtf, I dislike a few things on snap but this just unfounded BS, you need to be online to install stuff and get updates, the installed software does not need to be online. And if canonical was stupid enough to try and make it paid it would be the death of Ubuntu and of snaps, so it's baseless speculation IMO.
catman
Posts: 412
Joined: Fri Jan 11, 2019 10:42 pm

Re: OpenXR/OpenVR (virtual reality support), arch-friendly update

Post by catman »

adrianinsaval wrote: Sun Aug 14, 2022 12:33 pm Wtf, I dislike a few things on snap but this just unfounded BS, you need to be online to install stuff and get updates, the installed software does not need to be online. And if canonical was stupid enough to try and make it paid it would be the death of Ubuntu and of snaps, so it's baseless speculation IMO.
I did not say SW must be online to run. It was about using snap offline (to install). As today it works fine with apt.
And it was not baseless, I found the link: https://askubuntu.com/questions/1236220 ... ffline-use.

But I agree that I was too short to be fully clear and I can see that the statement can be read in a different way from how I meant it. As its not my intention offend anyone and as its beside the topic of the thread anyway I will remove it.
Hope that solves it for you.
User avatar
ppd
Posts: 108
Joined: Tue Feb 26, 2019 12:01 pm
Location: Munich, Germany

Re: OpenXR/OpenVR (virtual reality support), arch-friendly update

Post by ppd »

You can install snaps offline just fine: https://snapcraft.io/tutorials/snap-dow ... oad-a-snap
As snaps bundle most dependencies, it actually works much better than figuring out which deb packages an offline PC actually needs if the dependency graph is rather complex.
Try FreeCAD from the Snap Store: Stable releases (in latest/stable) & daily builds (in latest/edge). Supports installing additional python packages via pip!
Image
User avatar
kwahoo
Posts: 680
Joined: Fri Nov 29, 2013 3:09 pm
Contact:

Re: OpenXR/OpenVR (virtual reality support), arch-friendly update

Post by kwahoo »

catman wrote: Sat Aug 13, 2022 8:30 pm I do not know the constraints for C++ code in workbenches but do you know if technically this can be done in an external workbench as well? This would lower the testing barrier tremendously.
I am thinking about reimplementing everything with https://github.com/cmbruns/pyopenxr Just to get something that:
a)would be available in the addon manager
b)could be easily extended, especially with some drawing/editing tools

Cons:
a)needs manpower to rewrite
b)may be a bit slower
catman
Posts: 412
Joined: Fri Jan 11, 2019 10:42 pm

Re: OpenXR/OpenVR (virtual reality support), arch-friendly update

Post by catman »

kwahoo wrote: Mon Aug 15, 2022 3:33 pm I am thinking about reimplementing everything with https://github.com/cmbruns/pyopenxr Just to get something that:
a)would be available in the addon manager
b)could be easily extended, especially with some drawing/editing tools

Cons:
a)needs manpower to rewrite
b)may be a bit slower
I agree to the advantages. About b) that may turn out to be difficult since performance will always be a bottleneck with VR. A question might be what the different data flows are to get the scenegraph into the driver. In the current code it looks to me that you derive from the inventor class that does the rendering of the 3D view anyway, so the OpenXR libs have direct access to that data. Is that flow as efficient when that data must be accessed by an OpenXR lib that is behind a python binding and a C++Python interface in FreeCAD? Another way could be to create custom Python API extensions for every OpenXR lib call used in the current code, modify the current code to work as API and translate todays VR class to Python.

If C++ could be used in a workbench the code may be moved to a shared lib and loaded by the workbench. That would effectively work similar to now, just a bit more complex. And it would need a dev knowing how to handle C++ in workbenches (but no VR knowledge). Or do you know a simple WB that uses C++ and can be used as template today?
User avatar
kwahoo
Posts: 680
Joined: Fri Nov 29, 2013 3:09 pm
Contact:

Re: OpenXR/OpenVR (virtual reality support), arch-friendly update

Post by kwahoo »

catman wrote: Mon Aug 15, 2022 4:51 pm In the current code it looks to me that you derive from the inventor class that does the rendering of the 3D view anyway, so the OpenXR libs have direct access to that data. Is that flow as efficient when that data must be accessed by an OpenXR lib that is behind a python binding and a C++Python interface in FreeCAD?
I did it this way in my first (before any of C++ implementations) demo script that used pyopenvr.
It still works despite of pyopenvr being deprecated now. And I am not sure if it is slower than C++ implementation at all.

Providing a shared library has a downside: there are multiple architectures, operating systems. If someone compiles FreeCAD on his exotic machine and downloads the addon, he will have to recompile the shared library too.
catman
Posts: 412
Joined: Fri Jan 11, 2019 10:42 pm

Re: OpenXR/OpenVR (virtual reality support), arch-friendly update

Post by catman »

kwahoo wrote: Mon Aug 15, 2022 7:02 pm I did it this way in my first (before any of C++ implementations) demo script that used pyopenvr.
It still works despite of pyopenvr being deprecated now. And I am not sure if it is slower than C++ implementation at all.
Providing a shared library has a downside: there are multiple architectures, operating systems. If someone compiles FreeCAD on his exotic machine and downloads the addon, he will have to recompile the shared library too.
Well, good point with the lib. Can't run your test as I can't use steam. The code seems simple enough - its happy with just a scenegraph link from the FreeCAD document. Can you compare frame rates with the current solution on the same scene?
User avatar
kwahoo
Posts: 680
Joined: Fri Nov 29, 2013 3:09 pm
Contact:

Re: OpenXR/OpenVR (virtual reality support), arch-friendly update

Post by kwahoo »

catman wrote: Tue Aug 16, 2022 7:23 am Can you compare frame rates with the current solution on the same scene?
For some reason the Python script does not work with realthunder's renderer. I had to use the mainline, very slow, renderer.
There are results, when I loaded a motorcycle engine model: about 42-43ms per frame for both pyopenvr and C++ OpenXR implementations.
Post Reply