I have no idea what happened, but suddenly VaMLaunchGUI.exe doesn't run anymore. I did nothing new. Nothing was updated. I tried uninstalling and reinstalling, and it just doesn't run. I see the exe come up in task manager and then immediately close. Any ideas?
When that happens to me I just start the VAMLaunchGUI again - it rarely crashes. But it seem to crash more often if I start it without waiting a few seconds after turning on the Launch. Maybe windows + Launch is doing some initial communication that just makes VAMLaunchGUI crash (or not) during startup.
I always wondered why we are "predicting" anything, when the anchor points that are tracked are mapped into a known 3D environment with known coordinates that should be extractable. If I'm waving something around manually, in a recorded 3D environment, I should be able to easily grab those data and use it to move the hardware. Not sure why prediction is necessary. It's most likely just the limitation of the API.
This plugin merges 2 different plugins.
ToySerialController and the VamLaunchPlugin.
The ToySerialController sends it's tracking coordinates (input) to the -> VamLaunch plugin. The VamLaunch plugin has always used predictive movement due to limitations in the Launch API. You must tell the device (the Launch) to move to a certain position with a certain speed (from it's current position). Then the device will move to that position and stop before accepting new inputs.
I have tried to continuously send smaller incremental steps but then the device will basically move a bit. Pause a brief moment. Move a bit. Pause. Move. Pause. Move. Pause. Which doesn't only feel wrong but also increases the wear and tear of the device, especially when it should move fast. Perhaps this wouldn't be a problem on other devices but I do not own any other devices.
To be able to go from predictive behavior to actually sync with the animation this would require either:
A: Peek in the future of the animation information (if possible), run the physics and whatnot to predict where the input from the ToySerialController actually will stop. This would be (if even possible) computational heavy as it would basically run a copy of VAM to just peek into the future in the animation. Let's not do that and tank anyone's FPS by half.
B: Someway be able to record the input motion by playing a scene once and then be able to create a timeline with information when the Launch device should start moving to a certain point and how fast in order to sync up with the animation. Recording a scene would then only be required to do once after which information can be extracted for when a launch should start moving, how fast and to which point to match the motion of the animation.
Now, record the input from a scene is troublesome because what should be supported? VAM's native timeline is probably doable but a lot of work. Integrate with AcidBubbles Timeline plugin perhaps if the correct API exist but again a lot of work. All other ways of producing animations, such as AnimationPatterns or CycleForces, I would ignore due to it being too unpredictable variables.
The amount of work that recording would entail just makes me not do it, I have given it some real thought how it would be solved but I will leave it as that, a thought exercise. This plugin works well enough for me even if I for some scenes would have it more accurate when it comes to the speed which it just can't predict well.
C: In supported scenes, allow the scene creator to create a well-known point with known coordinates and limitations to be able to extract data to this plugin that drives the Launch providing information about how the launch should move. But how should that technically actually work as we need when to start move, where to move to and with what speed (or another way of putting it, at what position should the launch be at at a specific time in the future)? Getting tired thinking about this again
Hopefully someone wants to continue to work on this plugin and fix and improve and tweak things and maybe make it easier to use. Or write a completely new one from scratch to overcome this plugin's all limitations
As I have written in earlier posts, the goal was to merge 2 existing plugins together which I consider completed.
Bottom line: Go from predictive movement to a fixed movement is not trivial due to limitations in the Launch API, I have some ideas how one could theoretically overcome it but not without a lot of work that I don't feel like spending into this project anymore in my spare time.