Hooray wrote:there are several options for integrating things - the "best" being proper USB/HID support built right into FlightGear, i.e. through Nasal/cppbind bindings or by mapping USB/HID devices into the property tree. A simple workaround would be a standalone application that supports USB/HID devices, and simply uses a custom protocol to talk to FlightGear, which is the more traditional way, but also more complicated to set up for people.
Hooray wrote:I believe Oculus Rift support is one such idea. I've given my reasons why I think that way, but I'm keenly aware that there could easily be something I haven't considered about it, so I do hope folks will be able to spare a little time to present any thoughts that could educate all of us here about it.
Look at the manpower we have development-wise, then look at the people who are really familiar with the project, who could actually add those changes. These are usually the same people, and they are usually juggling tons of responsibilites. So whenever something has priority, other things need to be neglected.
In theory, oculus rift support could be awesome - for people who have access to the hardware. In practice, it would probably affect 5-10 FG users, and it would largely affect OR users to try out FG, i.e. have something else to play with.
Now, to develop OR support, you need a bunch of folks to have access to the hardware in the first place, and access to the specs, the SDK etc.
As you can tell just by looking at earlier discussions, not even the OR developer is 100% clear if and how FG could be supported. As far as I know, none of their developer came here and actually inquired about FG support. If that were the case, I'd be sure that more people would jump on the waggon. But so far, it's really "just" users requesting support, not people knowing how to do.
If you had come here offering to look into it, while making clear that you have done the work to build FG from source and that you know C++/OpenG/L/OSG, my responses would have been different, I would have provided tons of pointers, related to OSG, SimGear and FlightGear to get you going.
Really, the situation itself isn't totally new: We have had people requesting ATI TwinHead/TwinView support for many years, we've had lots of people requesting ATI CrossFire or Nvidia SLI support. And then we've had people requesting Saitek support. Undoubtedly, all of these would be great for people who actually have the corresponding hardware. For others, it would just mean that the focus of development is shifted towards supporting proprietary/commercial products that most of us in the community don't even have access to.
Imagine for a second FlightGear 4.0 came out, featuring 2 years worth of coding, all dedicated to supporting hardware and features that you cannot even use without spending $500 US first, awesome, right ?
Thus, we really need to be thinking in building blocks, to come up with features in the most general form - for example, TwinView is all about supporting multiple screens. FlightGear supported that through multiple instances that were sync'ed - which would allow people to use multiple screens at the cost of running multiple machines, without being vendor-specific.
Later, through the adoption of OSG, we now have multi-window support, all without being hardware-specific.
Same goes for things like Saitek or Oculus Rift support: it simply makes NO sense whatsoever for the project developers to just implement support for a single vendor or device, support must be generic, and useful for all other efforts. That requires shared functionality and common requirements to be identified and encapsulated in the form of a portable interface.
Supporting USB/HID devices in general would be useful for all related efforts, without being specific to Saitek or Oculus Rift.
So even if some vendor were to came up with serious cash to sponsor certain efforts, I would hope FG developers to keep that in mind, in order not to implement vendor-specific extensions that are of little use to 95% of FG users.
Hooray wrote:Like I said, the work ahead isn't overly difficult actually - it just requires motivated people with access to the hardware & specs, and some spare time - all the building blocks are already there, in both, Oculus Rift and FlightGear - it really just a matter of integrating things now, preferably in a cross-platform fashion, using a standard USB/HID layer that will be part of FlightGear, which is in the works anyways - for Saitek support.
Users browsing this forum: No registered users and 10 guests