FreeCam Mousewheel-Zoom PG work, and broken IE test there-of

Hi gang.

Recently, a forum friend asked (in pm) why this PG (a freeCam mousewheel zoom)… that Arte and I had once built… quit working.

I fiddled around and I think I got it working again… with THIS pg.

Notice lines 25-38. WheelData used-to work, in some browsers, at some time. Then we needed detail for some browser(s). Now it appears that deltaY is the trend. :slight_smile:

I know these mouseWheel properties are “W3C wobbly”, a bit. There seems to be cross-browser issues, and neg/poz issues, and any number of other issues.

So, speaking of cross-browser… I cannot get the #23 playground to load-into my IE. Error… something to do with scripts (playground app issue?). And so, I was not able to test this freecam mousewheel zoomer… in IE. And I don’t have any other browsers… for full testing.

Anyone want to address any of this? What’s wrong with IE load? What’s “the best” cross-browser way for us to do freeCam mousewheeler? Is #23 best… check for legacy stuff first, then get deltaY as a final attempt?

Line 44… is an issue, too. Some browsers’ wheel-props need < operator, some need > operator. Erf.

Should we make freeCam mousewheel-zoom… be an add-on “camera behavior” or maybe a modified camera.input for freeCams? Thoughts? (thx)

PS: Line 25 deltaMode defaults == 1. I set it to 0 for no reason at all, and I don’t know what it does… at all. SO, experimenters… you might wish to disable that line, or read about it. :slight_smile:

pinging @sebavan or @Deltakosh for help!

Do you mind creating an issue for me? I will check that next week


1 Like

Thx for the attention and issue-filing, JC… cool of ya.

I tested PG #23 on a just-now-DL’d Chrome… loads fine.

A little research on Chrome’s mousewheel event properties:

Chrome… honors ALL THREE of the mousewheel event properties… event.wheelDelta, event.detail, and event.deltaY. Cool, huh? When using event.wheelDelta (which it uses for pg #23 because event.wheelDelta is the first in the list of if/then checks)… it has reversed direction (from Firefox event.deltaY).

Let’s say we COULD make a camera.input “thing”… that could be added to camera.inputs of CERTAIN cameras… that ONLY added mousewheel zoom. That’s all it does.

First, it would probably need some browser-sniffing AI… to know which “format” of mousewheel data to use. But also, MAYBE… camera.mousewheelInput.wheelbuttonPressChangesDirection = true/false.

Crazy? So, this mouseWheelInput… would do about three things.

  1. Reject cameras that already have active mousewheels
  2. Use browser-sniffing or fancy fallback-to-legacy crap, to determine best event props to use.
  3. Allow user to reverse direction (invert delta) WHILE IN USE.

3b. How about allowing setting wheelPrecision (sensibility/sensitivity) on-the-fly, too? omg.

I’m very unaware about mobile devices, but, do any mobile devices have mousewheels? Or do they all use pinch/touch-drag to zoom? or… what?

Let’s pretend ONLY desktop/mouse users… want mousewheel zoom. THEN… we can be reasonably sure that there is a shift, alt, and control button nearby, right?

IF we assume that only mousers want wheel-zoom… then… CONTROL, ALT, and SHIFT wheel-rolling and wheel-button-clicking… is at our disposal to use… for more powers/features. :open_mouth:

What I mean is… ALT-mousewheel-button-press… reverses zoom direction. Or maybe SHIFT-wheel-roll… sets wheelPrecision/sensitivity. CONTROL-wheel-roll… sets horizontal FOV. WOW! Fancy wheel-wizard stuff, huh?

Ok, I’m going to come back to Earth, now. I hope I didn’t scare anyone. :slight_smile: Just… thinkin’.

1 Like

The Playground is using modern JS (things like arrow functions for instance and thus will not work in IE anymore)

But you can still test your PG with this link:

And good news, it works :wink:

1 Like

Oh duh, that’s the 3rd time that’s “bit” me. Yep, arrow functions. Darnit. Thx DK and JC!

When this happens, I SO SO wish the IE console would report: EXACTLY what DK just said. :slight_smile:

Should we still use this thread… for discussions about other ways to add cross-browser-ready mousewheel zoom to freeCams and uniCams?

Perhaps something more core-ish (cameraInput or camera behavior)?

Or maybe let users add it, just like this playground method, and move-along down life’s dusty trail?

Anyone wanna talk about that subject? :slight_smile:

Ok, no discussion about creating FreeCameraMouseWheelInput. Thread marked as solved.

@Mathieu - I guess you’ll need to continue using the code-it-yourself method.

If anyone wants to experiment, I hijacked an ArcCam mousewheelInput into a freecam playground here, and installed it at line 127. Unfortunately, it’s full of webpack stuff (which I nopped-out), so it’s difficult to dev/mod/test the hijack on a freecam in PG.

It appears that IE and Chrome are using wheelDelta property, Firefox is using deltaY, and I haven’t found a browser… that uses detail, yet. Onward we go.

FYI: Default ArcCam inputs.attached:

keyboard: Object { ...
mousewheel: Object { ...
pointers: Object { ... 

Default FreeCam inputs.attached:

keyboard: Object { ...
​mouse: Object { ...

I’m not sure why one uses mouse and the other uses pointers. I haven’t studied camera.inputs very much.