For this one I’ve actually split the code into a Base class BaseCameraPointersInput that can be used for any Camera
and a derived FollowCameraPointersInput for the FollowCamera.
I probably should have been doing that for my previous commits as well…
There’s quite a bit of duplicated code around these classes.
On the other hand, i’m a frontend noob so not sure what accepted design patterns are.
Interested to hear opinions on this.
Haha.
Well it looks like i’ve implemented exactly the opposite direction for every single one of these…
I was thinking “move the camera” rather than “move the scene”.
Happily though they can all be reversed: Set a negative number in the relevant field.
eg: camera.inputs.attached.pointers.angularSensibilityX = -1;.
I’ll read up a little on touch UI tomorrow and see what the internet consensus is on the matter.
If it makes sense, i’ll reverse the default direction.
Sensible default options are sensible.
Ok, it took a while as i ended up completely re-factoring ArcRotateCameraPointersInput to use my new BaseCameraPointersInput as well. (Somewhat outside the scope of my original work but i was having fun…)
Here for prosperity: https://github.com/BabylonJS/Babylon.js/pull/5798
All this has been pushed to dev and should start working in playground soon.
Mouse drags should alter camera positions. Pinch-es on mobile devices should work too.
Watch here for evidence of the merge: https://www.babylonjs-playground.com/ts.html#P9RQJW#9
I think i’m close to done with this.
It would be nice to see Base classes for other input methods like BaseCameraPointersInput to prevent code duplication but my brain is itching to move on to another project (my CNC router needs more work) so i think it’s unlikely i’ll do that…
That said, i’m more than happy to tweak things in the code i’ve written if they aren’t working right.
(I also owe @Deltakosh some unit tests for ArcRotateCameraPointersInput. Going to start on those now.)