Process view

This section gives an overview of the most important processes in the application. There are four different figures explaining different processes. Figure 4.7and Figure 4.8 focus on user interactions, while Figure4.9focuses on the sequence in which the data are received from Leap Motion, and processed in the software made in this project. Figure4.10illustrates what happens in the main loop of the software.

Two different types of diagrams have been chosen for the process view. One is a flow chart diagram, and the other is a sequence diagram. The sequence diagram is used primarily to show the interactions between objects in the sequential order that those interactions occur. The flow diagram is used to show how a certain part of the software can be in different states, and how and what is needed for the software to change states. A flow diagram is also used to visualize what is going on in the software to help users to understand the process.

Changing strategies

As seen on Figure 4.7, there are four different rotation strategies implemented in this system.

They are called “Copy Hand Rotation” strategy, “Joystick Rotation” strategy, “Gesture Rotation”

strategy, and “Two Handed Rotation” strategy. These are the four strategies a user can use to rotate models. The strategies can be changed using Unity’s inspector, or at runtime by the user.

These strategies are the proposed strategies for evaluation. A detailed description of how the different strategies work can be found in Section4.2.6.

CHAPTER 4. DEVELOPMENT PROCESS 63

Figure 4.7: Different strategies for rotating objects in the application can be used. The strategies can be changed at run time, or using Unity’s in-spector.

Changing modes

The application offers to operate in different modes. Modes in this project means that the soft-ware is able to perform the different homogeneous transforms separately, offering a more pre-cise workflow (see Figure4.8). It will be possible to move objects independently, or translate objects independently, or scale objects independently when operating in the different modes.

The different modes arerotate,translate, andscale. These modes can be changed by the user, and two different approaches to change a mode have been suggested:

1. A user can tap with a finger to switch between modes (see Figure4.13for the definition of a finger tap gesture)

2. A user can display a certain number of fingers with the secondary hand, where the number of fingers specify the mode to use.

The tapping gesture proved to be too unreliable when it was prototyped. Tapping gestures were not recognized good enough, and sometimes they were recognized even though no tap-ping gesture had been performed. The same behavior occurred even though the secondary

CHAPTER 4. DEVELOPMENT PROCESS 64

hand was used to change modes. Displaying a specific amount of fingers with the secondary hand worked better.

Figure 4.8: The software may run in different working modes, the user can choose which mode to use when working with the application. The different modes are: rotate, translate, and scale.

Interpreting data from Leap Motion

For the application to work, it must interpret the data Leap Motion sends to the computer. Fig-ure4.9 illustrate the sequence on how data from Leap Motion are interpreded. The data are passed from Leap Motion as Frames to Unity. TheseFrames are then interpreted by the class LeapInput, which dispatch events to all other classes registered as listeners to those events.

TheLeapInputAdapteris the class that listens to events fromLeapInput, and is also responsi-ble for updating the position and orientation of theprimaryHandand thesecondaryHand(the secondaryHandis omitted from the sequence diagram to make the diagram more comprehen-sible). LeapInputAdapteris the class that creates a new LG.Handobject, and it is up to the HandInterpreter to get the object. TheHandInterpreterwill then use the parentLG.Hand object as a reference when creating aGhostHand,SmoothedHand, or a mix of both of them (not

CHAPTER 4. DEVELOPMENT PROCESS 65

shown in the diagram). In the update cycle within Unity, Leap Motion will keep sending frames to LeapInput as often as it can. It is up to the LeapInput to interpret the frames, and dis-patch events. LeapInputAdapterreceives events, and will manage the differentLG.Hand ob-jects (giving them the correct id, and/or tell them that they need to update themselves with new properties such as position and orientation). TheHandInterpreter is only interested in the primaryHandand thesecondaryHand, but it does not care about how they are found.

Figure 4.9: The sequence in which a hand is registered and updated in the system.

How to transform objects

The most important sequence in this project, might be how the models are actually translated, rotated and scaled (see Figure4.10). TheHandInterpreteris the class that manages the main

CHAPTER 4. DEVELOPMENT PROCESS 66

update cycle for the application. It will get the position from where the hands are registered by Leap Motion and transform the positions to fit within the scene in Unity. It will then use the orientation and position of the hands to display two spheres in the user interface, that represents the hands of the user. The orientation and the position of the real hands are also used to apply a rotation and translation to objects in Unity when they are being grabbed by the user.

Figure 4.10: The sequence in which objects are rotated and translated in the game loop.