You can use a Camera in ARC as a button without any external code. I created a custom multicolor named "Dark" and set it a orange/red range and I set it to the maximum size for detection. This is what worked best for me as I discovered the orange/red color range was reflected off my hand as it moved toward the camera to block the view.
I started out using the darkest shade of blue possible but that color did not perform as well for me. I encourage you to experiment as skin tone, lighting conditions and even the type of camera will very from user to user.
Below is my script which I named CamBlocked It only looks for the $CameraObjectColor value to change and so this scripts acts as a sort of "hair trigger".
#updated 7/21/14
$CameraObjectColor = ""
:Start
IF ($CameraObjectColor = "Dark")
ControlCommand("Bender Sounds", Track_19)
sleep(500)
ENDIF
$CameraObjectColor = ""
sleep(500)
goto(start)
The line below is the action I have chosen to perform when my "Dark" multicolor object is detected.
ControlCommand("Bender Sounds", Track_19)
Video Tutorial:
Here is an alternative take on the script. Rich's modified script uses the WaitForChange function and $CameraIsTracking value. My tests showed that I had to wave my hand slowly more closely in front of the camera for 1-3 seconds in order to trigger the event.
#from Rich 7/21/2014
$CameraObjectColor = ""
WaitForChange($CameraObjectColor)
:Start
IF ($CameraObjectColor = "Dark")
ControlCommand("Bender Sounds", Track_19)
EndIf
WaitForChange($CameraIsTracking)
$CameraObjectColor = ""
WaitForChange($CameraObjectColor)
Goto(start)
If you test the two scripts, please let us know the results.
My thinking is that in your script it does; a) fires the event continuously if the camera is blocked b) needs to be blocked for half a second
Not huge deals but not as smooth as I personally would go for.
A way around that would be to use WaitForChange. This also reduces the load on the system resources since it's not looping around twice a second.
Since the camera control doesn't revert the variable $CameraObjectColor back to nothing when that colour isn't detected you will still need to figure out a way to reset this when it's not detected.
So we use a WaitForChange() for this too.
We WaitForChange in the $CameraIsTracking variable since when it's not tracking the colour it will be 0 and when it is it will be 1. This holds the script at that point until it changes. After this change we can reset the colour variable.
Once reset to nothing we can WaitForChange in the $CameraObjectColor variable. This will hold the script at that point until the variable changes i.e. until it detects darkness again.
So with both of these added in, the code should look like this;
Running it should reset the colour in the variable. Wait until the camera is tracking Reset the colour in the variable Wait until the colour changes again Then loop around
Writing this I've spotted the first time it is covered it wont detect until the hand is moved away again but that's a simple problem to solve...
All it needed was a WaitForChange() for the colour at the top, this makes sure that the variable would be "Dark" before running the if for the first pass and therefore letting it work.
If the colour isn't "Dark then the IF will fail, the command wont run, it will stop until tracking again, reset the colour to nothing and wait until it's detected again.
This should, at least in theory, provide a much smoother detection.
Its still not working as hoped. I think what is negatively effecting it is $CameraIsTracking variable does not really change state when the motion of the hand moves up to the camera. So to the $CameraIsTracking variable may not change it all, while $CameraObjectColor would change to "Dark" and atleast trigger the event/sound once. If I remove the WaitForChange($CameraIsTracking) then the functionality goes back to an increase of multiple triggers (as the original script does).
DJ said on the first threat about this - "Configure the drop down for how many frames before object is considered tracked. " That suggests the CameraIsTracking trip point can be adjusted, but I'm still not sure where that is at specifically. If anyone has a screen shot of where the option is I would appreciate it.
Really? $CameraIsTracking should change from 0 to 1 when the camera begins tracking pretty much instantly, at least it did when I tested it.
I think I see where the issue is. In my original script, I only look for $CameraObjectColor value to change to "Dark" and then I reset it to "" so the effect I get is anywhere a flash of my multicolor is detected, even for a hot second, my event is triggered. This gives the effect of a "hair trigger" and I can have my hand further away from the camera lens.
With the $CameraIsTracking value added to the modify script I find I need to move my hand closer and wave it slowly for 1-3 seconds, almost touching the lens in order to capture a longer box detection in the preview window in order to prompt the change in value for $CameraIsTracking.
This is very neat to see the results from our two scripts. Thank you Rich.
I'll keep looking at the script and seeing if there are any other methods or ways to possibly improve detection etc. I'm sure I'll be doing that sub-conciously too - chances are I'll be driving along and suddenly have a thought about a different approach to it, that's usually when things hit me