Three.js: OrbitControls : zoom damping ?

[Astrak]

Few months ago https://github.com/mrdoob/three.js/pull/12179 was sent to provide OrbitControls with damping when zooming and panning, as this behaviour already exists when orbitting in OrbitControls, and for all actions in TrackballControls. In my opinion we can propose a smoother experience this way and I've been happy to use this version until now. The PR didn't go well however, may have looked surprising for any reason etc. Another way to go with this PR has been suggested in its last message but no news about it. So opening this issue instead : is damping for pan and zoom something developpers can benefit ? Or should this PR be closed ? Or is another one prefered ? If yes, what should be done differently ? Thanks !

[XanderLuciano]

IMO, the PR just had a lot to it. I've adapted the OrbitControls script to my liking with improved damping, better touch controls, etc. OrbitControls is a great starting point, but is not fully polished on it's own. To me, OrbitControls is just the base that most people build up from. I put together my Script by more or less just copy-pasting features I liked from unmerged PR's.

Regarding your PR though, the one issue that concerns me the most would be are separate damping and speed rates required on different platforms? Zooming in particular worries me because OSX has built in acceleration.

I can see a case being made to add damping to panning though. Shouldn't be any issues between platforms with that. Small changes are generally preferable in large projects because they are easier to review.

Alternatively, you can make this into a gist, and share the gist with people who are looking to add smoothing to OrbitControls.

[Astrak]

Thanks ! I'm tweaking OrbitControls as well for different uses. Just asking if I should close or if it is of interest for anyone, as I believe it is of general use.

Regarding zoom damping, most end-users are still not on Mac. Devs can easily customize the script for that, but then run into the same problem of built-in Apple damping vs their custom damping.

[WestLangley]

I have https://github.com/mrdoob/three.js/pull/13242 in the pipeline. After that, I have a PR to add damping for panning. Damping while zooming will have to be addressed subsequently.

[XanderLuciano]

@WestLangley I did see that PR earlier this week 👍 I like the idea of adding new features one step at a time.

@Astrak Ideally on OSX, you wouldn't use any damping as the OS should be handling it. On windows, though you have discreet scroll values which would benefit from smoothing being applied. I don't know if this uniform across browsers and OS's though, so like WestLangley said, we'll just have to cross that road when we get to it.

most end-users are still not on Mac.

Also, I really don't think this is a fair point to make. While I don't expect a lot of OSX users for a three.js game, I can totally understand OSX users using browser based utilities for like viewing 3D models (especially if you are sending a model to a client, and they don't have a copy of a 3D modeling program that runs on OSX). And just for reference, I have about the same number of Firefox users as I do OSX users.

I guess just the overall point I was trying to make is that I don't think it's a good mentality to ignore a chunk of users and potentially providing them with a poor UX. I also don't think we want to be creating custom browser / OS detection scripts and adding fallbacks and polyfills to support browsers, just so we could add 1 feature.

That said, I do remember running into an issue where on mobile devices, using 2 finger pinch to zoom (calculating change in distance between the two touch events) was prone to "jittery" zooming because your fingers are fairly imprecise, so zoom smoothing by actually be worth the effort. But in that case, it's also possible to just add smoothing into just the touch event handlers and not the mouse event handlers, which would prevent having to mess with browser or OS detection.

Anyways, I don't wanna derail this thread anymore than I already have. Just wanted to voice my thoughts.

[Astrak]

I'm unsure I understand. WestLangley is providing the damping for panning and it is not being debated here, so I'm renaming the thread to zoom damping : you did start providing arguments that would just be copied if we open another thread on this topic.

My starting point of this can then be rephrased : the code for zoom damping is not a big feature to add, so should ThreeJS worry about it instead of letting everyone adding it by oneself ? For the moment it looks a missing important UX feature to me for all non-Apple end-users.

The main answer I've been understanding until now is that Apple's built-in damping is satisfying for Apple developpers and that yes, people should add the code themselves if they need it. It seems that I'm debating with 3 Apple devs in this thread and the one of the PR so dare I voice more thoughts too :smile: (Debian&Windows+Android here).

@XanderLuciano, you write :

I don't think it's a good mentality to ignore a chunk of users and potentially providing them with a poor UX

This is where I start getting lost in the previous post because I am stating the same, only Apple users can benefit zoom damping for the moment and the rest of the end-users have a poor UX instead. So to better understand what leads to our different conclusions, may I ask :

Q1 : Is it better to not provide zoom damping than to have different zoom damping speeds depending on the OS, on an easy optional feature ? ThreeJS could provide the damping and the user customize the speed depending on the OS if necessary.

Q2 : TrackballControls do have zoom damping. Why so then, and how does it behave on different OSs ? (disable staticMoving in the TrackballControls example to check it : is it a bad UX on Apple ?).

[Astrak]

The discussion is here in case anyone feels like contributing to it in the future, closing for the moment.