[osg-users] Oculus+OSG

[Jan Ciger]

On Thu, May 21, 2015 at 3:55 PM, Björn Blissing <bjorn.blissing at vti.se>
wrote:

>
> The head of the master branch is currently supporting the v0.5.0.1 of
> Oculus SDK. The work with v0.6.0.0 is currently located in a separate
> branch. I have not decided yet on how to proceed with the branches. I
> usually tag the last working commit of an SDK version before pushing
> commits belonging to a new SDK version. But since Linux and Mac will be
> abandoned, it may be a demand for a separate branch for the continuous
> development based on SDK v0.5.0.1.
>
> I will keep the idea in mind...
>

I think that for the time being it is completely enough to simply tag the
"last good" version and document the tag name somewhere, so that when
someone needs it the revision can be found easily. A branch can be done at
any time later, if required.


> Well, I guess they believe that reducing the number of accessible parts of
> the SDK makes the product easier to integrate. BUT as they keep closing the
> SDK they also reduces the ways people can use the product. They seem 100%
> focused on (windows) games (which maybe the smart business decision), but
> they leave out the people how like to hack stuff and create solutions which
> no one at Oculus Inc. imagined.
>

The problem is that they are shooting themselves in the foot, even when it
comes to the "mainstream" (i.e. game) applications. I was working quite a
bit with the Unreal Engine 4 and their rendering code recently because of
my work and there the Oculus integration is a token effort at best and a
horrible, bolted on kludge at worst. The last time I checked (4.7.x
version) there wasn't even support for the DK2 and things like post render
warping yet. Perhaps this has changed in the upcoming 4.8, but I didn't
have time to check so far.

 UE4 renders in such way that there are several rendering threads
collecting rendering and compositing commands (UE4 uses deferred shading
approach) into "tasks" and that is then queued for another thread to be
actually executed by one of the "RHI" (D3D/GL/GL ES/...) backends. That is
all happening asynchronously, in order to achieve the best performance. The
engine architecture is such that integrating deeply intrusive features like
the post render warping or the predistortion from the Oculus SDK is a major
and messy work, having to introduce the Oculus-specific code all over the
place.

The SDKs "my way or the highway" approach pretty much flies in the face of
all the abstraction and architecture work in these engines :( And that is
all for a single HMD - what about Valve, Morpheus and perhaps yet another
major player that could appear? All those (will) require their own hacks
like this. I doubt that this is going to be a sustainable development model
- the costs of maintaining the resulting code mess will be enormous. Or the
engine developers end up saying that they support only HMD X on a platform
Y and that's it. In the worst case the company decides that VR is so niche
market that the effort to support an HMD is simply not worth it. And those
are commercial developers, good luck to indies or the open source ones
without the resources and access that Epic or Unity have ...


> Hopefully the competition will benefit the HMD manufacturer which is most
> open, but I guess that the winner will be the one who can provide "the
> killer application" (or in this case; "the killer game").
>

I wonder what will be the actual adoption rate by the game studios. So far
there was a lot of hype, but very few have explicitly announced support for
HMDs in their upcoming titles (it isn't something you can just "bolt on"
after the fact, for both technical and usability reasons). Moreover, pretty
much the only game engine on the market with good support for the Rift is
Unity3D right now. And that is only because Oculus engineers are working on
it, AFAIK.

I guess we need to wait until the next year and see what happens once the
mass market CV1 is released.

J.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20150521/f6bdd591/attachment-0003.htm>