Wednesday, 12 November 2014

Keeping the momentum - Organising!

Our team is doing well but we have a deadline looming (2 weeks away). As such I thought it would be a good idea to get a sense of the project overview and agree on some deliverable / method of work for the next week. 

With this in mind I created a spreadsheet that can be used to track the progress on the overall project. Both in terms of official deadlines and sub tasks. The sub tasks are gathered together in a number of 7 day 'sprints'. There is also a Gantt chart although some of the sprints are currently at a 7 day default without much detail. This will change as we progress. An example of the sheet can be seen below:

Gantt Chart

Additionally Luke suggested we check out Trello to stay on top of project deliverables. As such I had a play around and set up a basic project dashboard. An example of this can be seen below:

Our Trello thus far :D

I have also continued reading up on the research documentation and organised a DK1 (Oculus Rift) for Tuesday! The University will be providing me with one for the day. I can't wait to test it out and get my prototypes running! Unfortunately the hardware is being used by lecturers so I will need to keep this in mind for future testing and provide ample time to book the DK1 again.

I also suggested to the team that each of us create a general project design concept. I figured that if each of us did at least one we would have a total of 7. We could then use this to help speed up our brainstorming. This could also allow us t emphasises what was important to us in terms of our roles/interests. I am hoping this will save some time and allow us to hit the ground running (with design and dev) in the next sprint, which will lead into our 25th deadline.

That's it for today!

Monday, 10 November 2014

Finishing tasks and showing off some dev demos

Most of the tasks below have been completed. A summary of my tasks for this week were:
  • Currently reading through the Project document we got from Dr.Claus (on going)
  • Contacting personnel to find out about booking the Oculus
  • Looking into using 360 Controllers in Unity
  • Looking into Project Morpheus as a potential alternative
  • Get in touch with Kingston College staff in case we need access to A-level students for our (UX) design guys
  • Working to tweak the camera's in a demo project so that we can offer two different views (basic and 'oculus mode') to users if we need too
 I also mentioned the following two elements I wanted to look at:
  • Looking into the controller/movement functionality in more detail (on going)
  • Writing a basic rotation script to rotate and object along its X,Y or Z axis in 3D space.
I contacted the person at University and asked about getting our hands on the Oculus rift, I am awaiting his reply mail.

I had a busy week but I managed to research a few things. Even though we may not use any of the stuff below, I felt it was important to get my feet wet in the code side of things as soon as possible. And also felt the need to investigate some potential issues, like camera problems.

I researched the controller support in Unity and the functionality offered by the oculus integration. I started messing around with the Oculus provided scripts by implementing minor changes for example rebinding keys to different (custom) functionality. I am still looking into this further.

Super simple example

I also researched cameras and how they would work between Oculus and non-Oculus systems. Seems like as long as we do scene changes, things are pretty modular which is really good news I think. More on this can be seen in the demo below. I put up a small demo on youtube, as it was easier and more interesting to show.

 As mentioned above I also researched the rotation in 3D space. I found a cheeky way to do this in Unity, as can be seen, but I would like to use a more standardised way (the mathematical way). I believe this will be of use to me in the future (specifically when I do my 3D games programming module). Using a more generic implementation will also mean I can use this regardless of Game Engine. 

It was important to find a way to rotate the camera rather than the object. As we want to immerse the user, having them rotate and seeing the whole world shift with them is important. It is much better than simply rotating the planet itself. Although if required this can be done pretty easily.

To summarise after thinking about the problem and looking into it I came up with the following solutions:

Solution One:
Using an empty game object, placed in the centre of the world (3D space at Vector3 0, 0, 0). I then use this object as a parent of the camera. Rotating the parent will also rotate the camera and any other game object attached as a child to it in relation to the parent object. I then place a sphere in the centre (0,0,0) on its own and the camera then appears to be rotating around this object.

Focal Point in 0,0,0 parented to the camera
I also wanted to use Unity's 360 pad support directly so used this as a simple excersise. The code for the actual rotation is pretty simple:

Rotate with detla time :D Simples!

This is the method used in my video above, the results are pretty neat.

Solution Two:
Similar to camera behaviour in RTS games (for example Total War) rotating the camera in a circle could be achieved by a mixture of direction and camera rotation. This is similar to how a car turns. In Unity I believe I could implement something like this by translating (moving) on an axis and rotating the camera at the same time. The only drawback with this solution is it may be difficult to establish the best position for the camera. It may also make it difficult to reuse the solution.

Solution Three:
I knew this was a math problem, I just wasn't sure how to tackle it. I found a solution on stackoverflow (see here). Rather than simply copy paste to solution I was keen to know how this worked. I knew that I would be able to use the radius of a circle in some way. As I was only really concerned with a 2D circle in 3D space. I am very rusty on my maths and as such had to dig a little deeper into using cos / sin and tan. After some more digging I found this site here. Which explained things pretty well. I now see, or am starting to see how to apply a mathematical solution to this problem. I still need to read up more about this but it is not crucial for the project at this stage. But for personal interest I will continue to read into this solution

At the very least I learnt how to calculate cos/sin/tan for a given angle (SohCohToa!) :D

Sunday, 9 November 2014

Contoller supported custom demo using OVR

Hey all,

Just a quick rough update. I spend an hour or so making a custom prototype scene to see how to do the following:
  • Use skyboxes with Oculus
Pretty easy as the oculus in Unity is actually two cameras. I just added the same skybox material to each 'eye' camera.

LeftEye camera with custom skybox
  • Use a 360 controller with Unity and Oculus 
Making use of the OVRGamePad Controller script included with the Oculus integration. I am currently reading through how this script functions and why it doesn't make more use of Unity built in controller features.

The results are below. I set up a simple scene with a skybox, and basic textured terrain and some rigidbodies for collision detection. Then I imported the OVR stuff I required (character/camera) and got rid of the default Unity camera. Everything is pretty much plug and play and controllers work! But I want to do more on this to see how to customise my controller input since it's tied to the OVR's classes settings at the minute.

Figure 1 - Basic terrain being made and custom skybox added to Oculus

Figure 2 - Replacing the plane with terrain

Figure 3 - Final outcome, 360 controllers work as long as the OS can see the 360 driver, collision works, skybox also works.

That's all for now, along with my other tasks I will be looking into the controller/movement functionality in more detail. 

I will also be writing a basic rotation script to rotate and object along its X,Y or Z axis in 3D space. This is another test in case we can make use of this functionality later.