You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The plugin supports multiple viewports/windows, which means it needs to keep track of which one (and thus which PanOrbitCamera component) should be processing input events. This is called the 'active' camera. This works great when the input is from the mouse or touch, because those are always tied to a specific viewport/window (whichever one is under the cursor / being touched).
However, #45 just added 'roll' controls with keyboard only, which lands us in an awkward situation. When the user presses a roll key, which PanOrbitCamera should process the events? Because key presses alone aren't tied to any particular window/viewport, there's no way to know which camera the user intends to control. Given how this plugin is set up, the result is that rolling controls whichever camera is under the cursor, and if the camera is outside the window entirely it does nothing.
This isn't 100% solveable, but one possibility that should cover most cases is that when there's only a single instance of PanOrbitCamera then treat that as a special case and make it process all events regardless of whether it's the 'active' cam. Since I strongly suspect the vast majority of the time this plugin is used to control a single camera, this should fix the problem for most people.
One other possibility is to make the 'roll' controls use the mouse. I need to test this, but I think it might feel weird? Or maybe even removing the controls for roll and make that up to the user to do manually, since I think rolling is likely not a common use case anyway.
The text was updated successfully, but these errors were encountered:
The plugin supports multiple viewports/windows, which means it needs to keep track of which one (and thus which
PanOrbitCamera
component) should be processing input events. This is called the 'active' camera. This works great when the input is from the mouse or touch, because those are always tied to a specific viewport/window (whichever one is under the cursor / being touched).However, #45 just added 'roll' controls with keyboard only, which lands us in an awkward situation. When the user presses a roll key, which
PanOrbitCamera
should process the events? Because key presses alone aren't tied to any particular window/viewport, there's no way to know which camera the user intends to control. Given how this plugin is set up, the result is that rolling controls whichever camera is under the cursor, and if the camera is outside the window entirely it does nothing.This isn't 100% solveable, but one possibility that should cover most cases is that when there's only a single instance of
PanOrbitCamera
then treat that as a special case and make it process all events regardless of whether it's the 'active' cam. Since I strongly suspect the vast majority of the time this plugin is used to control a single camera, this should fix the problem for most people.One other possibility is to make the 'roll' controls use the mouse. I need to test this, but I think it might feel weird? Or maybe even removing the controls for roll and make that up to the user to do manually, since I think rolling is likely not a common use case anyway.
The text was updated successfully, but these errors were encountered: