One of the premises of Zenva Sky is to make the teachings of computer science and coding something immersive and interactive. Virtual reality can allow the interaction between the user and their surroundings in manners that are not possible with 2D or normal 3D development, which is what we normally do at Zenva when we teach coding.
VR is a new medium so it is hard to know in advance what will work and what won’t. Also, the only way to know is to build an actual VR prototype. Our methodology and goal for the next two weeks is to continue exploring prototypes and mechanic ideas, until we find one that feels suitable.
The prototype we have built so far allowed us to try a few things and yielded really interesting finding. Unfortunately, it also brought up a few challenges we will need to solve
Keep on reading to learn what worked, what didn’t, and how we plan to solve these issues!
We’d like to thank Intel and Microsoft for the generous support and hardware provided, which consisted on:
Zenva Sky is being developed on Windows 10 Pro with the Unity engine.
Last week we presented an interactive experience where the user can apply “commands” to interactive objects.
We expanded on that concept by improving the UX so that the prototype can be used entirely in VR, without the use of the keyword.
By using their hand-tracked controllers, the user can point to an object with the “laser pointer” and activate it to prompt a series of commands. For now we only have the command “Move”:
When selecting a command, options for that command are presented. In this case, the user can choose what axis to move on and how much.
There is some progress from last week:
The way we implemented these spatial UI windows is by using Canvas objects in Unity, and setting their rendering to “world space”, which means the UI is shown in the 3D world (as opposed to it being 2D and overlayed on the screen).
We use box colliders in these canvases for them to read the “laser pointer”. For the laser pointer we are using VRTK version 3.
The Program is the main set of instructions that will be executed. The user can add different commands to it (well, for now just Move!).
In this manner, users learn intuitively what a command and a program is. This approach is similar to that taken by popular robots that teach kids coding.
The Program now shows a screenshot of the object that will be moved, in order to make it easy to distinguish which objects the commands apply for.
The main updates from last week here are the ability to remove commands with the “X” button, and to see that screenshot of the object.
The screenshots are taken in-game and saved into a variable. This was done by having another camera in the game, which doesn’t render to the VR headset, have that camera positioned in between the user and the target object, and render its contents into a texture, then that texture is placed in the UI.
The camera ignores certain layers of the scene such as the sky and the UI elements.
When executing the program, all the commands are applied to the corresponding targets, in sequence. If a movement encounters collision (for instance, you try to make the block go underground) that command is ended and the next command is executed.
This was already implemented last week, and the only change we made was to send things back to their initial position a couple of seconds upon termination.
This prototype provided very valuable insights on how a basic programmable environment feels like. However, the following issues were found:
There are two variations of this prototype that we want to explore next. The good news is the components we’ve developed so far can be easily ported onto either:
What option do you think will work best? Come back next week for an update!
Intel's compilers may or may not optimize to the same degree for non-Intel microprocessors for optimizations that are not unique to Intel microprocessors. These optimizations include SSE2, SSE3, and SSSE3 instruction sets and other optimizations. Intel does not guarantee the availability, functionality, or effectiveness of any optimization on microprocessors not manufactured by Intel. Microprocessor-dependent optimizations in this product are intended for use with Intel microprocessors. Certain optimizations not specific to Intel microarchitecture are reserved for Intel microprocessors. Please refer to the applicable product User and Reference Guides for more information regarding the specific instruction sets covered by this notice.
Notice revision #20110804