Ideation, Creation & Everything In Between
Adding New Paint Strokes –
There are several paint strokes within the scene that have been updated to change the behaviour this has been done through updating the FBX files if any animation has changed, Updating the textures and then plugging these new textures into the materials of the appearance of the paint strokes is changed.
The scripts that control the fade in and out behaviour of the paint strokes have also been updated if the timing needed to be adjusted.
Introduction & Frames Additional Paint Strokes –
The paint strokes were only coming into the scene at the intro but the screen time of these has now been adjusted. We had made the decision based on user experience feedback that the quiet particles and frames section of the interview was lacking visuals so we decided to add a vortex effect of paint strokes in this section of the interview to make it appear to be busier.
I feel like these additional paint strokes work really well with the interview sequence and they make it more interesting to look at and watch. They are very mesmerising and help to make the sequence complete.
New paint strokes within the interview in Unity –
Sketch Panels Texture –
During the explorable gallery in the sketches section the texture panel has been adjusted to shorten the paragraph so that it is easier for the participant to read within the gallery experience.
The decision was made to edit the panel as in user experience we had tested it and found that there was simply too much to read so that new one has been edited and placed within the scene.
The image below shows the old sketches panel and the new shortened one.
Loading Times –
At present we are experiencing some pretty long loading times when we click on an option to explore the gallery or play the interview from the intro menu screen scene. I wanted to try and discover why this was and what is using all of the processing power at this stage to see if there is anything I can do to optimise the scenes so that they may load faster as at present the menu appears to freeze and then go black inside the Oculus while the participant is waiting.
A measure taken to improve the loading times was making the engine: change scene actions occur inside of a scene dependant cutscene rather than a project dependant actionlist (asset file) this meant that the change scene is taking place in the scene rather than having to look through the project to find the action. Therefore the logic behind this is that this could decrease loading time which it has appeared to do so far.
I had a look into using a loading screen as I thought that this may be resolution to the problem and if the user is being informed with a screen that the scene is loading they may not think that the experience is broken. My only concern with using a loading screen is in earlier experimentation we had tried using menu elements from Adventure Creator and these did not display inside the Oculus so my thoughts were will the loading screen show within the Oculus as this is technically an AC menu element.
This then got me to looking into how to make a menu screen within Unity and not necessarily using Adventure Creator to achieve this.
Making a loading screen within Unity –http://blog.teamtreehouse.com/make-loading-screen-unity 08/05/16
Making a loading screen using Adventure Creator – http://www.adventurecreator.org/forum/discussion/732/loading-screen 08/05/16
Loading Time Solution –
Experimenting with loading time further it seems that the scene being played in the unity editor or the build caches information and that the more times it is played it technically buffers and does not have to find and call as much information as it did the previous time it was played. Playing the scene a few times in the build before proceeding with a demonstration of the scene has cut the loading time down from 8 seconds to 3 seconds.
All we can do is play the scene in the build a few times to warm it up as such before we show it to anyone then we should be on our way to faster loading times. If I get anymore time during the week I will keep looking into this matter to try and speed things up so that they are seamless.
Fade Box Issue –
All throughout the interview experience we have been having an issue with the fade box being seen we have edited the shape of the box and the shaders and have still had no luck. Previously I had tried a sphere but I could see out of this so thought that this is not going to work.
Thinking more about a sphere I figured out that this did not work because the normals were on the outside of the sphere not the inside and I have no way of editing this inside Unity. Navigating back to Maya I made a sphere at the scale we have been using 100x100x100 and reversed the normals on it and then exported this from Maya and imported it into Unity and what do you know it worked.
Now that I cannot see out of the sphere it works as a perfect fade bubble as such as there are no rough edges that are seen or corners of a box. We have replaced all of the fades with this new sphere and tested it within the Unity editor and the build and it looks awesome. Im really happy that I was finally able to crack the fade issue we have been having and now we have pretty seamless fades considering all of our fades are a hack and we shouldn’t even be able to do this at all.
Extended The Floor –
The floor platform that appears throughout the interview was not a large enough size to fill the composition and sometimes depending on where the user was looking at the time meant that the user could see the edge/corner of the floor so I have extended it so that they can no longer see this in the experience.
Again this is a minor change that has made a pretty big difference to the interview sequence and has improved the look of the experience.
Controller Not Functioning Within Build –
When we made a build we navigated to the explorable gallery section of the experience and discovered that the controller was no longer working in the gallery within the build. I noticed that when making a build the windows architecture was not set to _64 which is for a 64 bit operating system rather than the 32 bit.
A controller.dll file was present for the 64 bit build but not the 32 bit build that I was building for. I then changed to build for a 64 bit operating system as the controller.dll for this architecture was present. There was no controller.dll file for the 32 bit operating system as this had to be removed due to an error conflict in the unity console.
Making the build for the new architecture with the correct controller.dll file allowed for the controller to then work when we tested it within the build. Im so glad that this was not a major issue and that I remembered about the error of the dll file and associated that with what was happening now.
Security Of Equipment & Back Up’s –
Were having some pretty tough times in the university at the minute and security has been raised and were now taking measures to ensure that the equipment we are using for this project is safe and sound. We have also made back up’s of the project and build to date and are hoping to keep everything safe and secure.