Accomplishment:

This week we successfully realized the synchronous playback of our 3D scene project: the courtyard project. The main problem last week is that the monitors and  head node show different screens. We solved it by change our node to the same position of the FPS controller. Then we changed the position and direction of our display array to cover the same area of the camera in the camera holder. We also found that the controller of original project can not rotate beyond XY plane. By changing our prefabs under the camera holder to inherit more controller information, we successfully solved the problem.

Challenges:

The challenge is that there is a delay problem when we used the controller for this 3D scene. Benny said that the main limitation is from the hardware, which we cannot improve. But I will try to delete some of the complicate objects shown in the 3D scene to make it more simple, and see if it will improve the performance.

Plan for next week:

1. Try to solve or reduce the delay problem
2. Summarize two projects

Progress:

The application is done and ready for testing. I’ve run it on myself and a few friends thus far with consistent enough results to merit further tests. I’ve finished the UI finally, and the rest of the code needed to make the different components communicate. A user is now able to transition between tests, and return to the start screen / abort tests as desired.

While the application will calculate a Snellen letter score, and it seems to put out something close to physical tests, I’m not sure I’m sizing the letters right (which for me means adjusting the distance the C object moves each time).

Struggles:

The actual letter size still alludes me. Mostly because all of the information out there on sizing Snellen letters for a LogMAR test pertains to physical tests, where the actual size of the letter is first measured, then scaled to append 5 minutes of arc at different test distances.

Next Week

• Talk with Alex and/or Kevin about further testing
• Go over design, come up with features for custom tests
• Try on other HMDs (not vive)

Accomplishment:

This week we kept trying to let the UniCave prefabs work in the 3D scene project. For the courtyard project, we tried to add our monitor prefab under its playerController as its child in order to getting the position and rotation information. However, it seems that the UniCave prefabs will get confused about which cameras to be selected when there are more than one camera for different purposes. Therefore, we tried to delete some of unnecessary objects in Courtyard scene. Still, we have some unsolved problems of the UniCave prefabs, and we will try other simple 3D scene project like Tuscany next week if we cannot figure it out.

Challenges:

The courtyard scene has so many objects which are related with each other that it is challenging to figure out every object’s function and relation.  We try to delete unnecessary objects to make it simple and find the right position to add our monitor prefab to inherit the right position and rotation of camera.

Plan for next week:

1. Try to realize the player controller mode in the tiled display system for Courtyard scene.
2. If we can not figure it out, we will jump to Tuscany project and add the play controller by ourselves later.

Progress:

Per the suggestion of Kevin, I transitioned the way the timed test works to use the Invoke Repeating method. This method solved all my problems with multi-threading in Unity. The test itself will now run through the trials, displaying the C at different positions for X amount of time before recording a failure. There is a period of rest, where there is no C displayed, which I handle by placing a black plane in front of the C display. Using a simple transform it appears and disappears. The test will end when the participant either completes 5 trials at each of the 14 distances, or when the participant fails 4 or more trials on a given distance (as was done in Paisan).

I’ve also started fleshing out the UI more. The main menu scene is currently under construction, and I’m working on displays for the test results once the trial is complete.

Struggles:

Now my that my multi-threading woes are over, I’m making good progress.

Plan for Next Week:

1. Finish functionality: Main menu, Basic UI
2. Find calculation for correct logarithmic distance
3. Program calculation for LogMAR score at end of test
4. Start testing

Accomplishment:

This week we created some prefabs to save our original 3D video project’s objects and tried to build a new 3D scene project. We used the courtyard as our 3D scene, which is a free source provided by unity, and tried to add the prefabs we made before to realize the tiled display function. The picture shows that the presetting works.

Challenges:

The courtyard demo seems to be too large for our head node. We may change this with a smaller 3D scene. Also, there are some camera setting problems which we will try to figure out next week.

Plan for next week:

1. Try to build and run the 3D scene project in our tiled display setting.
2. Try to create dynamic anaglyphs for this 3D scene.

Accomplishment:

This week we wrote TCP Communication python scripts to realize launching. We set all the sub nodes as servers and the head node as client. There were some errors to start executable on the head node because of the firewall setting. But thanks for Kevin and Ross’s help, we successfully solved it. After that, we made some fine tuning of the position of each monitor for calibration. The performance looks good.

Challenges:

Still, the video shown on different monitors will have a few frame difference. When the video finished and looped to the start point, the frame difference became more apparent.  But we plan to jump to the next 3D scene project since the performance of the video without looping looks good.

Plan for next week:

1. Convert 3D video project’s object to a Prefab.
2. Create a new 3D scene project and finish the presetting part.
3. Try to add a Kinect system to the environment for head tracking.

Accomplishments:

After looking into them, co-routines will work for accomplishing the timed component of the Landolt C test. I’ve been able to successfully write the rest of the code pertaining to running the actual test. The last thing I need to to do is figure out how to mathematically represent logMAR units, and produce the correct result.

Struggles:

Fixing the threading issues were a little slow, and I didn’t have as much time as I would’ve liked in the dev lab this week, but I’ll have more next week.

Next Week:

1. Get the test to output logMAR composite score
2. Build a basic UI for entering / completing / customizing the test
3. Start administering it for a few different people to bug test before gathering people for trials