@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?
