When the Elumenati visited the Virginia Tech Science Festival earlier this year, they hired videographer Paul Anderson to make a promo video about the Cyclorama. It looks amazing, check it out!
Congratulations to Phat for graduating with his MFA in Creative Technologies from the Virginia Tech School of Visual Art!
Mariah Flick created this documentary about Phat and his thesis work. Phat discusses graduate school and developing his final thesis showcase, which was shown on the Cyclorama in the Cube.
A little while back, Phyllis was forwarded this letter from a pre-school class originally sent to CHCI Interim Director Andrea Kavenaugh. It’s quite sweet. See the original letter and Phyllis’ response below:
March 18, 2016
The Rosa Sharks Class
Blue Mountain School
470 Christiansburg Pike
Floyd, VA 24091
Dear Ms. Stefi and the Rosa Sharks Class,
My friend Dr. Andrea Kavanaugh gave me your wonderful letter and drawings of robots and asked if I could help answer your questions. I really like the way you explored what you already knew about robots and then asked questions to find out more about them. I think you must be very good thinkers.
- What do robots eat?
This is a great question. Robots need energy to work just like you do. They use energy from batteries, solar panels, or an electric cord plugged into the wall. They also need instructions so that they know what to do and when to do it. We call those instructions “code,” and code comes from humans who tell the robot what it can do.
- Where do most robots live?
Robots live in lots of places. Some of them live in houses. Some live at businesses. Some even live in outer space. There are some robots on Mars right now, but I don’t know of any on Jupiter. Robots live wherever humans need them to do a job. The robot on Mars took pictures and sent them back to Earth. People can’t live on Mars, so it was a great way to learn about the planet. Some people keep a robot in their house to do the vacuuming! (That’s a job they just didn’t want to do.) You might even have a robot in your toys. If you have a toy that does something like move or make a sound when you push a button or squeeze it, you have a robot. My kids have Zhu-Zhu pets and a toy backhoe that are robots.
- Do robots go on vacation? Do they like to play?
Robots can’t do anything that humans don’t teach them to do. A robot could go on vacation or play, but it would only do that if a human told it to. Most of the time, humans just want robots to do work. When the robots are not working, they might rest in a closet or on a shelf. If you know someone with a smartphone, you can ask the smartphone about robots and vacation. Siri is kind of like a robot, and she might know a better answer than I do. Everything that Siri says, though, is something that a human told her to say.
- Where do robots come from?
Robots are built by people. Sometimes robots are built by other robots, but people have to tell the building robots what to do.
- Do you need tools like a hammer and nails or a wrench to build one?
Robots are things that move and follow instructions. You can use hammers and wrenches to make the thing and its moving parts. You can also use scissors and tape and cardboard. The shape of a robot can be made out of anything. A lot of robots have motors that help their parts move. The instructions part of a robot is usually a small computer. People use coding tools – usually a bigger computer – to put the instructions into the robot’s computer.
- Can you build a robot for us to play with?
I suppose I could, but I think it would be more fun if you built one yourself. You’d have to decide what kind of job you wanted it to do and how it should look. I like to use a Makey Makey to make a basic robot that makes sounds. You can also use a program called Scratch For Kids to learn to code. Another way to learn about robots is to take apart some old toys that work like robots.
I hope I have been able to answer your questions. Thank you again for asking them. I hope you will keep asking questions and learning more and more. I am sending your class a viewfinder that shows some fun things we do at my work.
All the best,
We’ve made a number of tweaks and user interface adjustments to this project, and it’s time to share them.
- We now have sprites and colors for EVERY type of particle. It makes it look so much more amazing. Jesse toiled over this during Thanksgiving break. Thanks Jesse!
- The user interface is now diegetic, existing in the world of the virtual environment rather than as a heads-up display or thru a physical tablet. Right now it just hangs out at a particular spot. But when the user is in VR, being motion-captured in the Cube, they will be holding an Xbox controller which will also be tracked. The virtual menu will take the position of the Xbox controller – so essentially users just need to look at their hands to look at the menu. They then select whatever part of the menu they are looking at with a simple look-and-click interface.
- We’ve also added the ability to select particles by looking at them and pressing a button. When you select them, a display pops up over the particle, showing key info. On that display, if you click the Save button, the info for that particle gets saved to a display up on the wall (which is still in the works).
- The Model section now has a preset subsection, so you can save and load different configurations of the BelleII model being on and off, along with the relative transparency values.
- There are also two “scoreboards” on the Cube walls now. One shows the current simulation time, so you can glance at it from anywhere in the room. The other allows the user to start and stop a timer with a press of a button on the Xbox controller.
- At Leo’s request, we’re also now showing “dead” particle sprites. Instead of a particle sprite disappearing after the data for the sprite has ended, a “shell” takes its place, showing where the particle was when it … passed away? This has caused some new frame rate issues that I’m struggling with. 30k is a lot of individual sprites! They’re not correctly batching right now, which is what I spent most of my day trying to figure out. I learned a few things that increased the frame rate here and there, but it’s still not great yet. It gets worse as the simulation goes on, because more and more sprites are added.
Additionally, the educational side of this project is really starting to kick into gear. Instead of spending most of the meeting time talking about features for the simulation, we’re talking about lesson plan development, which is awesome! That’s exactly where we want to be moving in to next semester. We plan on piloting this thing with Society of Physics Students folks immediately following spring break!
Editor’s Note – This post is from Phyllis Newbill, the Outreach and Engagement Coordinator here at ICAT. Enjoy!
I had the pleasure of hosting school groups today from Mountain Vista Governor’s School and Hardin Reynolds Memorial School in Patrick County. Thanks to Tanner and Zach, the students saw and heard demos of basketball games, elephants, anechoic chambers, cathedrals, dog skeletons, and fantasy landscapes. The groups also visited the Experience and Create Studios to see 3D printers, the laser cutter, and a project involving lots of pencils that I haven’t quite figured out yet. I know that graphite is conductive, though, so I think that’s a clue.
I was glad to see Mountain Vista again. Their school has done a great job of sending projects and students to the Maker Conference each year in the spring. Today’s group was of tenth graders, so I’m looking forward to seeing them again later this school year or in future years.
The Hardin Reynolds students happened to tour the Create Studio at the moment that Panagiotis, a CHCI grad student, was finishing a 3D print. He showed them how the 3D printer works, and also gave them a full demo of his 3D printed olive oil factory parts.
My favorite part of the day was when the students got to see a 3D fantasy landscape in the Cube, and they reached out to see if they could touch the objects they were seeing.
While the blog has been quiet recently, ICAT is far from it. I haven’t posted recently because I don’t have a new flashy video to show off yet, but we’ve made some excellent internal developments.
Foremost in my mind at the moment is our integration of the Oculus CV1 into the Cube motion capture system. In the past, we’d used the DK2 as our go-to headset. It was connected by HDMI and USB to a laptop that someone would have to carry around behind whomever had the headset on. The DK2 itself was OK, but the resolution wasn’t fantastic. There was also a decent amount of shakiness to the perspective coming from the mocap system.
Oh, how times have changed. With the CV1, we can use the IMU’s rotational data for the VR perspective. Not only does this eliminate the shakiness, but it’s super low-latency. But in order to enable users to walk freely thru the Cube, we’re still using the position data from the motion capture system, and disregarding position data from the Oculus infrared sensor (it still has to be plugged in or the Oculus app throws a fit, but it doesn’t actually serve a purpose). The combination of these two works *brilliantly*, resulting in by far the best VR experience we’ve ever had in the Cube.
But wait, there’s more. Right now, we have this running off a laptop with a dedicated graphics card, which is a problem. The laptop’s battery can’t supply enough juice to the GPU, so when the laptop is unplugged it automatically lowers the GPU’s memory clock which dramatically hurts VR performance. Enter the MSI VR One laptop/backpack/jetpack(!)(??)/new-kind-of-computer-form-factor-that-doesn’t-really-have-a-name-yet. This thing is designed for tetherless VR. You put it on like a backpack, you hook all the VR stuff up to it, tie up all the cords, and you’re free to walk around the room with nary a concern of tripping on cords or having someone else hold the laptop (new meme idea: Hold My Laptop… while I do some VR). Caveat: we haven’t actually tried this thing yet. It JUST released, and we have one on the way. So, it’s possible that it won’t live up to expectations, but I’m hopeful. If this works, we will get several more, and have true, tetherless, social VR in the Cube for the first time ever.
P.S. I’m still doing a lot of work on the physics VR simulation, and it’s looking great. I’ve built a diegetic interface. Once we get this backpack, I’ll take some video of a user exploring the simulation, using the interface, and post that here.
This past Friday, Thomas Tucker (faculty, Creative Technologies) and Eric Lyon (faculty, Music) installed their immersive audio and visual work Space Echoes in the Cube, using the spatial audio system and Cyclorama projection surface. Turn out was fantastic, and here’s a lovely video of the event:
This project just keeps getting cooler every week.
Come see it in person on the Cyclorama in the Cube, *this Saturday!*
Virginia Tech Science Festival, October 8, 2016, 10am-3pm.
Since the last update, we have:
- Made a few new events (datasets that represent a particle collision)
- Made sprites for each of the particles present in those events
- Colored in the pathlines and trails for the particles to be the same as the color of those sprites
- Optimized, optimized, optimized! Runs at 60FPS!
- I dumbed down the mesh to only be about 100 objects instead of many many thousand. We get some depth sorting issues with transparency still in certain situations, but it’s way better than it was originally and there are no frame rate issues when doing it like this.
- I cleaned up the particle controller code to eliminate generic lists, remove unnecessary GetComponent calls, and do better OOP. That was a dramatic FPS improvement
- The purchase order for the FastLineRenderer package from the Unity Store finally went through, and so now I’m rendering the 200k+ lines of the paths with that. When I do that, the lines are made into a mesh, which is the a single super fast draw call. That was also a dramatic FPS improvement.
- Probably some other stuff too I’ve forgotten about…
- Also! Tanner is working on the sound element now, and is getting the basic framework in place. It’s super exciting hearing that come together.
The Perform Studio has undergone exciting changes over the summer and into this fall semester.
First, Tanner overhauled the booth. Instead of just being a closet crammed full with a giant rack for the patch bays, he wall-mounted them to make enough room for it to be used as an actual mixing booth. Yay!
Second, the OptiTrack Motive:Body software was updated from 1.6 to 1.9, with excellent new features that improve nearly every aspect of the software. Additionally, we’ve ordered some extra capture-suit accessories.
Third, the Perform Studio is now being used as the CHCI lab. Doug Bowman and his cohort of graduate students can use the space to run experiments in virtual reality, using the motion capture system present. We’re very excited to have them doing their research in ICAT’s facilities. If you’d like to use the space, though fear not! You can still reserve it with 72 hours notice, and it will be cleared out and ready. If you would like to reserve the space, please contact Run Yu, who is handling the reservations for Perform Studio this year. runyu at vt dot edu
We’ve been working extremely hard on the particle physics project. A work-in-progress version of the simulation will be at the Science Festival! Saturday, October 8th, 10am-3pm. This simulation will be in the Cube. Come check it out!
Before I dig into what we’ve been working on, insert obligatory pretty video:
The main to-do list we’d like to accomplish before the Science Festival:
1. Me – Get all the particle sprites for the different kinds of particles
2. Me – Color code the path lines in coordination with the particles
3. Me – Get the full Belle II detector model in, albeit combined and completely opaque.
4. Tanner – implement draft of sound (OSC communication of particle data is complete, so he can pick it up and make it sound awesome)
5. Topher, Jesse, Sam – Make a flyer for audience to pick up on their way in
6. Topher, Jesse, Sam – Make all the images for the particle sprites, so I have them to import (there’s around 120 different kinds of particles!)
We’ve had 3 team meetings now, which are extremely helpful now that we have a full team on board. This includes:
Christopher (Topher) Dobson – senior, physics education
Jesse Barber – junior, physics
Samantha (Sam) Spytek – senior, physics education
Tanner Upthegrove – ICAT staff, sound
Zach Duer (me) – ICAT staff, visualization / organization
Dane Webster – faculty, school of visual arts
George Glasson – faculty, school of education
Leo Piilonen – faculty, physics
Nicholas Polys – faculty, computer science
Todd Ogle – master of all things, TLOS
Just in the past few weeks, Sam and Topher have picked up on the game very quickly and set out with Jesse to do a lot of work developing the educational aspect of the simulation. In the next update I will go into more detail on that.
In the meantime, I’ve been working my butt off optimizing the simulation to keep a decent frame rate. There were 3 major bottle-necks. I’ll detail them here, along with the solutions:
- The model, with all its 400,000+ individual objects slowed the frame rate down to about 10FPS. It’s a CPU problem – the GPU breezes through it, since it’s only about 2million polys. The CPU is struggling with this due to the number of draw calls. A lot of the objects are duplicates (the same mesh with the same material, but a different transform). This lets Unity reduce the number of draw calls by batch rendering, but just the process of doing that batching slows it way down. To maintain 60FPS, the full draw cycle has to happen in 16 milliseconds or less, so if there’s one thing that takes 0.01 milliseconds but it happens a few thousand times, it’s a huge problem. I’m still working on this, but in the meantime, I’m combining each major layer of the BelleII detector into a single object and setting it to an opaque material. Although this process takes some time, after I’m done the frame rate should be back up to a steady 60FPS
- The lines rendered to show the paths that the particles will take over the course of the simulation, the “pathlines” as I’m calling them, take too long to render if rendered individually. For the complex events, we’re talking about something like 4 million lines. Even if they’re done in one draw call, it’s still just too slow if done every frame. With just rendering these lines, it dropped the framerate to about 3FPS. So, instead I purchased a package from the Unity Store called FastLineRenderer. Since all the lines are known when the simulation starts, I can send them all to FastLineRenderer, and it converts them into a series of meshes (something like 64k lines per mesh). This shoots the framerate back up to almost 60FPS.
- I needed to optimize the script controlling particle movement. Yesterday and today, I completely rewrote the thing to eliminate the need for certain loops that were bottlenecking. I won’t go into any more detail now, but the resulting code is, in my opinion, much cleaner and easier to read, AND it’s a lot faster.
All that put together, and you can how smooth the above video is. Not all the meshes from the Belle II detector are finished combining, so I just threw in the Electromagnetic Calorimeter for that video. The framerate never dropped below 50FPS. I’m pretty proud of that.
Oh, and I put Lucas Freeman’s (mostly complete) Cube model in the project too, so that vastly improves the aesthetic quality.