Forum Discussion
360 image interactions: variables & trigger
Suggested: add built-in variables to Storyline for 360 interactions, such as "total number of hotspots and markers in this interaction", which we could test for to control things like the Next button. For each interaction, ideally have a Markername.Visited Boolean. (Yes, I'm trying to get you to create an object-oriented scripting language.)
Add a trigger to rotate the camera to point at a marker or hotspot, which would let me have a custom Next button that points to the next thing the learner is meant to see, rather than the next slide, except that after all markers/hotspots have been visited, that same button takes the learner to the next room or spot. This is not difficult to do in JavaScript, but it would be enormously easier if the function was directly supported in Storyline.
2 Replies
These are interesting ideas. Markers technically have Visited states, even if they're not exposed upon instantiation of a new marker. They can be added from the state portlet and can be checked like the dot-notational property you reference.
Hotspots are more challenging, but it's been my understanding they're superceded by buttons, which like the markers also contain their own native Visited state. Everything I know of that hotspots can do, buttons can do better, and with the added accessibility that hotspots lack. Many designers and developers are actually forbidden from using hotspots for compliance reasons so I would be surprised if Articulate expanded the functionality of hotspots when they're already somewhat like substandard buttons.
Your idea about rotating a camera is interesting, though it suggests that there's a camera to rotate. It's my understanding that to implement a camera would require hooking into a library like three.js. I've been able to simulate a camera in native Storyline by translating 2D elements around the screen, but it would be amazing to have some sort of camera object with aperture and depth of focus and such.
The Next button can be co-opted as you describe just using native triggers and without any JavaScript. Conditionals on the triggers allow us to determine when the learner can progress to the next slide and when the state of a "next" object should highlight. JavaScript definitely makes it easier, especially now that states can be directly read and changed using the API. Maybe we'll get a simulated camera in the API someday.
I was just using "camera" in the VR and animation sense, a (to reveal my physics background) vector with an origin point and a direction, essentially the way the viewpoint is looking, e. g. "parallel to the ground and compass heading 210 degrees from the exact center of the room." I'd like to be able to read the polar coordinates of the view direction from some kind of system variable, and even set them by changing the two values of those coordinates.
In animation, you speak of "cameras" meaning the angle and distance you view the action from.
