Issue 1
Due to the way the processing sketch works, the webcam image is a mirror of he actual movement so when the person moves left it goes right and vice versa. This isn't ideal for an interactive piece that relies on motion, so I flipped the webcam image in processing so that the action on screen maps the movement. I did this using the translate property. it was a couple of lines of code applied to the webcam image, but Seb showed me a useful way of doing the same thing using a piece of OpenCV code reducing it even more.
Issue 2
One issue I had before the feedback session was performance. The light painting effect I created was fairly intensive for processing to do. This wasn't an issue initially, as the mask obscures most of the on screen action so the lower framerate isn't that noticeable. When I added my particle array (which is above the mask) this issue became much more noticeable. As the particles spawned it was painfully obvious that the framerate was much lower than 30.
The code for the particle array is extensive, but it is unlikely to be the cause of the low framerate. There's no code for collisions, no motion blur or other intensive effects. The particle image is a small PNG and there are only 50 particles on screen at any time. This means that there is something in the rest of the code that is slowing the framerate.
One issue I had before the feedback session was performance. The light painting effect I created was fairly intensive for processing to do. This wasn't an issue initially, as the mask obscures most of the on screen action so the lower framerate isn't that noticeable. When I added my particle array (which is above the mask) this issue became much more noticeable. As the particles spawned it was painfully obvious that the framerate was much lower than 30.
The code for the particle array is extensive, but it is unlikely to be the cause of the low framerate. There's no code for collisions, no motion blur or other intensive effects. The particle image is a small PNG and there are only 50 particles on screen at any time. This means that there is something in the rest of the code that is slowing the framerate.
We discovered the source of the issue was the resolution that the camera was being sampled at. We halved it from 640x480 to 320x240 and then have that upscaled. This is much less intensive for OpenCV to process (since my sketch relies heavily on filtering processes in OpenCV). After changing this performance was significantly improved to the point where there was no longer an issue.
After discussing the issue with Seb we discussed further ways of improving performance and explained that the filtering effects of OpenCV are quite intensive. To create the initial image before effects it uses a difference filter. To make the image more abstract I am applying a heavy amount blur to this image so the difference isn't noticeable as the shape of the person as they move. Also, near the end of the code where the faded trailers of the difference image are being rendered I am applying a heavy amount of blur (again, to make it less like the object it's tracking) making it look more like a light painting.
This extensive use of blurring may be contribute to low performance. Since reducing the resolution performance isn't as much of an issue. I reduced the use of blur filters to optimize it further, but it is a very useful thing to keep in mind about Processing and OpenCV.
Opinion
I asked for Seb's opinion on what I had done so far and he seemed to find it interesting and thought it could be enjoyable. He was reluctant to provide creative feedback but was very helpful in providing feedback on my code. Seb thought I had done a good job of thoroughly commenting my code, because I explained that by commenting each line I break it down to a point where I can understand it.
Outcome
With this new information and receiving feedback from Seb I have improved the performance of the sketch and made sure that my project is on track for submission.