@songchengjiang
Ok… so, let’s start:
There two uses cases:
Use Case A: I want to “port” my existing game to VR
This is a quick & dirty way to have VR in your game.
Users will need to upgrade cocos2d-x v3.12 (3.13?) and then just enable VR rendering, and nothing more than that.
This won’t work for many games, since head-tracking won’t be enabled. So it will only be applicable for games that use a “remote control” or something like that (specially for games that only require just one button, like Flappy Bird). If games require a complex control, it won’t work I guess.
Use Case B: I want to design a new game with full VR experience (or change an existing game)
- In this case, users will either create a new game from scratch
- or migrate existing ones: They will need to add headtracking input support in their games, and adapt the game mechanics to VR.
The only different between Use Case A and Use Case B, from an API point of view, is that:
-
Use Case A: Only uses VR rendering
-
Use Case B: Uses full VR: VR rendering + VR headtracking
So, let’s talk about high level components:
VR Rendering:
Who is responsible for owning this?
CocosVR creates a Node with a custom rendering command, and two cameras.
And I think it was Ok as a proof of concept, but it is not suitable for a final feature. VR should work with the need to modify existing game code (Use Case A).
I think the VR rendering should be implemented in the CCGLView
class. And also Director
should deletegate more responsibilities to CCGLView
, like the rendering.
Something like:
Director::drawScene()
{
...
_glview->renderScene(_runningScene, _renderer);
...
}
CCGLView::renderScene(Scene* scene, Renderer* renderer)
{
// if VR is enabled to the stereo rendering
// else, do the mono-rendering.
// delegate the rendering to the right VR rendering instance:
// deepoon rendererer
// cardboard renderer
// ...
}
VR headtracking
We need a new class for the headtracking… in Unity it is called InputTracking
, in Cardboard is called HeadTransform
… not sure what is the name in the other devices.
But right now the name is not that important (as long is it is a good name).
This class should have at least these properties:
- head position / forwardVector : returns a vec3 or vec4
- head rotation: returns a quaternion
VR Misc:
A class that reports info about the VR device. Perhaps driver version (eg: deepoon v1.2), and other properties reported by the driver.
@songchengjiang
Thoughts? What do you think?