Proposal Due Saturday 11/2
at 8:59pm Chicago time
No Alpha deadline for this project but I suggest acting like there is
Application
Due Saturday 11/30 at
8:59pm Chicago time
Documentation Due Monday
12/2 at 8:59pm Chicago time
The goal of project 3 is to let you work on a VR or AR project
of your own
choice, subject to Andy's approval.
This could be a creating VR project in CAVE2 or the VIVE or the Quest, a new Unity app for the HoloLens, using Voforia or ARtoolkit to create an app for a smartphone or tablet, trying out apple's ARkit or google's OpenAR, etc. You could tie into fitbit or other body tracking software and have that drive VR or AR objects. You can create an AR app that runs outside next to ERF. You could take an existing card game like Munchkin and enhance it with AR. There is a lot of real-time data available today, so another possibility is to map that data into some kind of virtual or augmented world. You could create small game like fruit ninja in VR.
You can
combine this project with your project work in another
course but you need to be really specific what is going to
be new here, and there has to be a good reason for the VR
/ AR component.
These days its pretty trivial to lead in a bunch of models and walk around them. Its helps if the models are really pretty, but just walking around in a virtual or augmented space gets boring pretty fast. The main focus needs to be on the user's interaction with the virtual world.
Draw storyboards -
the first thing you must generate are storyboards. Draw
pictures of the user standing in the CAVE or wearing an HMD
or carrying their phone as an AR device. Make it like a
comic book. Each panel has some action initiated by the user
or the computer, and the next panel has the response. Draw a
series of these storyboards for the common usage patterns.
They should show the flow of the experience. The storyboards
do not need to be pretty, or realistic looking. They are
there to help you organize your thoughts on the experience.
You want to mentally visualize the person interacting with
your application - where will the user have problems?
Learn by doing - the flip side of drawing storyboards, which show what you want to do, is knowing what you CAN do in a given library / language. Write small programs. Try out simple versions of your ideas quickly to see if you are on the right track. A spiral development model works much better than a waterfall model in developing VR applications.
Focus on the user - see the application from the user's point of view, not the programmer's point of view. The user doesn't see the code. The user doesn't care how clever you did something. All the user sees is the end product.
Don't forget audio - ambient sounds and/or music are a good way to create mood and increase the sense of presence. Incidental sounds are a very good way of giving the user feedback (but its usually good to give visual feedback as well)
Play to your strengths -
in the case of VR remember that you have a user who is head
and hand tracked who holds one or more wands, but has no
access to a keyboard. Create worlds where the user has
natural interactions with his/her body. Also remember that
the user has stereo visuals. Create worlds that surrounded
the user; create worlds where the user interacts with
virtual objects. in the case of AR make use of things in the
real environment, especially tables, floors, walls and other
flat surfaces.
Decide on the Physical laws - decide early whether there is gravity in your world, whether the user can fly, whether the user can walk through objects, what size the user is, how fast the user can move, etc.
Choose your preferred display platform - decide if you are writing a piece for a CAVE or a tablet or an HMD or whatever and focus on the strengths of that platform.
Test on the real display - desktop simulators are nice for testing your application but there is no substitute for regularly trying things out in a tracked full-scale 3D environment like. Interaction with a tracked hand is very difficult to simulate on the desktop. Movement speeds are hard to judge in the simulator - the speed may be very different when you are interacting on the real device.
Get lots of feedback -
Once you have something working, ask others for feedback and
LISTEN to them. Its very easy to come up with an interface
which makes complete sense to you but makes no sense to
anyone else. In most cases you are not writing the interface
for yourself, so listen to your audience, especially if they
'just don't get it".
Make sure it works - your application must not crash. No matter what the user does, your application must not crash. Its better to have less functionality that you are sure will function correctly.
Get permissions - be sure to get permissions to use anything (images, models, sounds) that you don't create yourself. Don't steal.
Create reusable modules - if you are going to continue building VR worlds / interfaces then think about making things reusable - there are many things that you will be doing over and over again so its better to write them once and reuse them.
Focus on collaboration early - if the application is going to be collaborative or may be collaborative then focus on collaboration from the start. Its difficult to make an application once it has already been created.
1 |
Michael
Ybarra Zoheb Mohammed |
link |
link git |
|
2 |
Amit
Panthi |
link |
link git |
|
3 |
Lucas
Cepiel |
link |
link git |
|
4 |
Nathan
He Yushen Li Brian De Villa |
link |
link git video |
|
5 |
Justin
Donayre Frank Buttafuoco Mark Chen |
link |
link git |
|
6 |
Nicole
Laczny Conrad Ptasznik |
link |
link git |
|
7 |
Marco
Beccarini |
link |
link git |
|
8 |
Alex
Lopez Iqra Memon |
link |
link git |
|
9 |
Martin
Bragiel Tim Czepizak |
link |
link git |
|
10 |
Simran
Jumani |
link |
link git |
|
11 |
Suamaun
Vahedipour |
link |
link git |
|
12a |
Gregory Schamberger |
link |
link git |
|
12b |
Elizabeth Villanueva Divay Pandey |
link |
link git |
|
13 |
Jake
Terhark |
link |
link git |
|
14 |
Zain
Zahran Juan Moraza |
link |
link git |
|
15 |
Katherine
Misyutina Aastha Saraf |
link |
link git |
|
16 |
Edward
Reyes Jonel Alcasid |
link |
link git |
|
17 |
Shiva Reddy KJ Krunal Bhatt Suhan Nath |
link |
link git1 git 2 |
|
18 |
Michael
Lederer Mansur Shawabkeh Brent Yurek |
link |
link git |
|
19 |
Omar
Al-Khatib James Trinh |
link |
link git |