[Big Screens] Things that might help you
Big Screens show is over ⊂(´・◡・⊂ )∘˚˳°
Since we spent a lot of + hard times on big screens, I wanted to leave some comments that might help next year class. This is specifically for people working with Processing. If you are dealing with Cinder, Bill or Ryan can help you ( https://github.com/wdlindmeier/bigscreens ), if you wanna expand your screens to browser (which is really really great idea because you don't have to deal with goddamn ethernet cable connection) , the project of Jess & Ju would be helpful for you.
So... Hi Processing Friends. I will just scatter the thing that I found || people were curious about while doing our project. Oh, first, 'we' are Mary Fe & Hanbyul, our project was 'cub3s'
1. Since we worked on 3d environment, lots of people asked us Processing is enough for this. I might not be the best person to answer this, but Processing was good enough at least for us. As you can notice, the number of cubes was less than 1500, which is not that bad, also we tried not to calculate many things in real time. The speed, position, angle, and color.. almost everything is already set when they are initialized. Mesh scene was little bit hard because it required running real time noise to make natural wave,so I had to optimize the number of cubes. I don't exactly know how much you can benefit from switching to other languages, but it is true that performance based on java &jogl (opengl for java, Processing) is not that great , so you sometimes have to be careful.
2. I personally think that the bigger cons of using Processing than performance problem (which means you are using Most Pixels Ever library for connections of screens) is testing. I couldn't figure out why, but now (December, 2013) it is impossible to test 3d sketches on local with Most Pixels Ever auto mode. It means that you always have to stage your sketch on itp screens or wherever you can spread the clients. I could see manual mode (The mode that you have to set the scene up manually, like camera things) running on local, and couldn't figure out why it doesn't work on default. If I can find out more, I will post.
3. Sometimes it is not your problem. MPE server is not super stable, and ethernet connection in ITP is extremely fragile. If Eclipse throws 'can't find -1.xml' error, it means that ethernet connection was screwed up. You may have to physically unplug and plug cables till they are working. If controller suddenly stops talking to server, don't panic, just restart server and controller. Not to confuse controller, it is better to turn on the server before turning on controller, this was the problem we got at second performance. HAHAHA!
4. There are some libraries & functions conflicting with MPE library. Especially the library related to camera ( ex. PeasyCam ), it is not gonna work with MPE because MPE needs to take over priority to make seamless connections between screens. Even some of P5's built in function, such as camera or frustum, don't work in auto mode of MPE. You can go to Manual mode if you want more freedom of camera, but you still can't do that many things since many parts of MPE's default camera are for lining 3 screens up.
5. Those are not big screens, but wide screens. their screen resolution ratio is more than 10:1, which throws crazy perspective. I just edited default camera to see extremely far (Yes, I edited the library's source directly, might not be the decent way ) , so we could avoid fish-eye effects on screens.
I hope these things are helpful feedbacks rather than boring whine..












