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

Questions
1

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:

2

pinging @sebavan or @Deltakosh for help!

3

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

4

Done

1 Like
5

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
6

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: https://playground.babylonjs.com/frame.html#6FHKHC#23

And good news, it works :wink:

1 Like
7

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:

8

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.