Java3D bug using JDK11

While porting my software over to the JDK11 environment,  I noticed the following bug that I would like to report:  when running Java11, I have lost the middle mouse button functionality that exists with the same code running under Java8.  That functionality was used to zoom with the mouse:

//Set up ZOOMing behavior around TG3.
    MouseZoom mouseZoom = new MouseZoom(); //CENTER BUTTON (or ALT-leftButton)
    mouseZoom.setTransformGroup(tg3);
    mouseZoom.setSchedulingBounds(bs);
    tg3.addChild(mouseZoom);
    mouseZoom.setFactor(0.001);
    //System.out.println("mouseZoom");


A little bit more insight into the MouseZoom anomaly:  in JDK8, my software works as expected: the left mouse button is programmed and works as expected,  the center mouse button also works as expected (shown above), and the right mouse button is not programmed, but works like expected (i.e. it does nothing).    The JDK11 version of the software has all three buttons behaving as if they were the left button. I was able to move the code snippet for the center mouse over to the MouseWheelZooom class and now it behaves as programmed.  All of these mouse classes come from javax.media.j3d.SceneGraphObject -- so something must have changed up at that level in javax to cause the anomalous functioning of the center and right mouse buttons.

Hello

By the way, try with Java3D 1.7 too.

Just want to make sure I know where the official release of Java3D 1.7 is?    If I go to the thread at the top of this site (http://forum.jogamp.org/JogAmp-s-Java3D-continuation-Java3D-1-6-0-and-later-td4030907.html) and click on the "follow these steps link", I can see a translated page that has links to Java3D 1.6 but I don't see a link to Java3D 1.7?  

BTW, I did find the 3 jar files in:  https://jogamp.org/deployment/java3d/1.7.0-pre1/   So perhaps you might just want to update your thread to point to that location?   Anyway, I did download the 3 updated jar files and switch them out with the 1.6 versions that I had, and still got the same result regarding mouse behavior.  

Some developers stick with Java3D 1.6 because they don't want to modify the imports in their source code. Note that Java3D 1.7 is mentioned above. Thanks, I'm going to update the guide.

Hi, I'm Phil the main developer of JAva3D. I've looked into this and for the life of me I can't get a middle mouse button to register a drag on a component no matter what JDK I use, below is my code.

So I guess whatever was registering your middle mouse button (and the loss of it) is something specific to the JVM and JDK you are using. Sorry I can't be more help here.

The EventCatcher will only fire on a mouse motion drag event and the MouseZoom requires the alt key to be pressed at the same time, so perhaps some flavors of Linux pass this as a mouse middle button drag event, and the MouseZoom was being helpful.

public static SimpleUniverse createUniverse() {
                GraphicsConfiguration config = SimpleUniverse.getPreferredConfiguration();
                Canvas3D c = new Canvas3D(config);
                SimpleUniverse univ = new SimpleUniverse(c);
                univ.getViewingPlatform().setNominalViewingTransform();
                univ.getViewer().getView().setMinimumFrameCycleTime(5);
               
               
               
                MouseMotionListener mml = new MouseMotionListener() {

                        @Override
                        public void mouseDragged(MouseEvent e) {
                                System.out.println("my one! " + e);
                               
                        }

                        @Override
                        public void mouseMoved(MouseEvent e) {
                                // TODO Auto-generated method stub
                               
                        }
                       
                };
               
                c.addMouseMotionListener(mml);
                return univ;
        }

Thanks Phil for looking into this.     I am not a professional programmer -- just dabble every now and then with Java,  I havenn't had time to set up your code below for my system, but may be able to do so one of these days.   In the meantime, I wanted to give you more info about my current code situation.   See below:


Platform: Windows 10
Development environment: Netbeans 11
Mouse: 3 button.  Middle button can be depressed and also scrolls (it is really a wheel).

a. JDK 1.8:  Scrolling (rotating) with middle button does nothing, but one can depress the middle button and then translate it to get the desired zooming behavior.  The portion of the code below that successfully performed this functionality is currently commented out below but shown for awareness – to show what was successful with JDK1.8.  This is the functionality that I wanted.

b. JDK11 :  Using the code exactly as shown below, depressing middle button causes same functionality as use of left button (and also right button has same functionality).   I really didn’t want all 3 buttons performing the same function.  But by scrolling the middle button, instead of depressing it,  I can get desired zoom behavior, but not as smoothly.


CODE FOLLOWS:

private void setupMouseBehavior()
  {
    //we want these mouse actions to work over the following
    //100km bounding sphere:
    BoundingSphere bs = new BoundingSphere(new Point3d(),
                                 (float)StarChart3Dpanel.MAX_DIST);

    //Set up the RA panning behavior around TG1.
    MouseRotate mouseRot = new MouseRotate();
    mouseRot.setTransformGroup(tg1);
    mouseRot.setSchedulingBounds(bs);
    tg1.addChild(mouseRot);
    mouseRot.setFactor(0.003,0.0); //turns off vertical motion of button

    //Set up the DEC panning behavior around TG2.
    MouseRotate mouseRot2 = new MouseRotate();
    mouseRot2.setTransformGroup(tg2);
    mouseRot2.setSchedulingBounds(bs);
    tg2.addChild(mouseRot2);
    mouseRot2.setFactor(0.00,0.003); //turns off horizontal motion of button

    /* Don't allow this.  We want to use the right mouse button for popups
    MouseTranslate mouseTrn = new MouseTranslate();
    mouseTrn.setTransformGroup(tg1);
    mouseTrn.setSchedulingBounds(bs);
    tg1.addChild(mouseTrn);
    mouseTrn.setFactor(0.02);  //default is 0.02  THIS IS THE RIGHT BUTTON
    */
   
   
    //   -------------------------------------------------------------  
   
   
    /**
    //  NOTE: this works with Java 1.8 and earlier, but not Java 11.
    //Set up ZOOMing behavior around TG3.
    MouseZoom mouseZoom = new MouseZoom(); //CENTER BUTTON (or ALT-leftButton)
    mouseZoom.setTransformGroup(tg3);
    mouseZoom.setSchedulingBounds(bs);
    tg3.addChild(mouseZoom);
    mouseZoom.setFactor(0.001);
    //System.out.println("mouseZoom");
    * */
   
   
   
    // The following works with Java 11:, but is not as easy to use as above.
    //Ease of use can be fixed by changing 0.001 to a different value.
    MouseWheelZoom mwz = new MouseWheelZoom();
    mwz.setTransformGroup(tg3);
    mwz.setSchedulingBounds(bs);
    tg3.addChild(mwz);
    mwz.setFactor(0.01);
   
    //  --------------------------------------------------------------
   
  }

I also have a separate but somewhat related question -- is there any intent to release Java3D as a module?   As you know, there is a push to go modular and not need JREs.   My other homebrewed software is now modular, but I can't step up to making a couple of my applications(which required java3D) standalone apps without a modular java3D.

We encountered similar problems when we use AdoptOpenJDK 11 and Java3D 1.7.1:
The left, middle and right mouse buttons do the same thing, which is different with JDK 8.

After some tests, we have arrived to get a solution: use SwingUtilities methods,
isLeftMouseButton, isMiddleMouseButton and isRightMouseButton,  to make them work.
This was done by making a minor change to

 void doProcess(MouseEvent evt)

in MouseRotate, MouseZoom, and MouseTranslate.

In MouseRotate:

            if ((id == MouseEvent.MOUSE_DRAGGED) && !evt.isMetaDown() &&
               SwingUtilities.isLeftMouseButton(evt) && ! evt.isAltDown()){

In MouseZoom:

    if ((id == MouseEvent.MOUSE_DRAGGED ) && ((evt.isAltDown() && !evt.isMetaDown()
        && SwingUtilities.isLeftMouseButton(evt))
        ||    SwingUtilities.isMiddleMouseButton(evt)))

In MouseTranslate:

            if ((id == MouseEvent.MOUSE_DRAGGED) &&
                !evt.isAltDown() && SwingUtilities.isRightMouseButton(evt)) {

The above changes seem to work in Windows 10 and RHEL 8.

Java3D 1.6.and 1.7 has solved many issues which were encountered using Java 1.5.
We are very grateful to the many efforts in developing Java3D.

hi all,
what i experienced is the lost of the right button for panning (translating) the view.

I attempted a fix.
this is done in
org.jogamp.java3d.utils.behaviors.vp.OrbitBehavior.java
https://jogamp.org/cgit/java3d/java3d-utils.git/tree/src/main/java/org/jogamp/java3d/utils/behaviors/vp/OrbitBehavior.java#n884
the code is made to read this way:

    boolean rotate(MouseEvent evt) {
	if (rotateEnabled) {
	    if ((leftButton == ROTATE) && SwingUtilities.isLeftMouseButton(evt) &&
		(!evt.isAltDown() && !evt.isMetaDown())) {
		return true;
	    }
	    if ((middleButton == ROTATE) && SwingUtilities.isMiddleMouseButton(evt) &&
		(evt.isAltDown() && !evt.isMetaDown())) {
		return true;
	    }
	    if ((rightButton == ROTATE) && SwingUtilities.isRightMouseButton(evt) &&
		(!evt.isAltDown() && evt.isMetaDown())) {
		return true;
	    }
	}
	return false;
    }

    boolean zoom(MouseEvent evt) {
	if (zoomEnabled) {
	    if (evt instanceof java.awt.event.MouseWheelEvent) {
		return true;
	    }
	    if ((leftButton == ZOOM) && SwingUtilities.isLeftMouseButton(evt) &&
		(!evt.isAltDown() && !evt.isMetaDown())) {
		return true;
	    }
	    if ((middleButton == ZOOM) && SwingUtilities.isMiddleMouseButton(evt) &&
		(evt.isAltDown() && !evt.isMetaDown())) {
		return true;
	    }
	    if ((rightButton == ZOOM) && SwingUtilities.isRightMouseButton(evt) &&
		!evt.isAltDown() && evt.isMetaDown()) {
		return true;
	    }
	}
	return false;
    }

    boolean translate(MouseEvent evt) {
	if (translateEnabled) {
	    if ((leftButton == TRANSLATE) && SwingUtilities.isLeftMouseButton(evt) &&
		(!evt.isAltDown() && !evt.isMetaDown())) {
		return true;
	    }
	    if ((middleButton == TRANSLATE) && SwingUtilities.isMiddleMouseButton(evt) &&
		(evt.isAltDown() && !evt.isMetaDown())) {
		return true;
	    }
	    if (rightButton == TRANSLATE && SwingUtilities.isRightMouseButton(evt) &&
		!evt.isAltDown() && !evt.isMetaDown()) {
		return true;
	    }
	}
	return false;
    }

by adding SwingUtilities.is{ Left , Middle, Right }MouseButton(evt) in the if clauses for the respective button checks.
this apparently solved for problem for AdoptJDK11 running in Linux. I've not tested in any other platforms.
This is for a "3 button mouse" i.e. left and right buttons, and the mousewheel is the middle button.
The mousewheel codes is untouched. physically, I rotate the mouse wheel for zooming.

I tweaked the if statement in the last translate() clause

	    if (rightButton == TRANSLATE && SwingUtilities.isRightMouseButton(evt) &&
		!evt.isAltDown() && !evt.isMetaDown()) {
		return true;
	    }

the original is somewhat different, in this case, I'm checking for a right mouse click/drag with no modifiers, i.e. no Alt and no Meta. I'm not sure how 'other' platforms and different mouses would respond as this is specific to the '3 button' (left, wheel, right) mouse.

I did not actually change the original codes, rather i copied the class and renamed it, then make the changes.
I'd guess it would be similar by inheriting and overriding the 3 methods.
This would likely help if you are using OrbitBehavior.

when I debugged the codes, it turns out that without adding the specific SwingUtilities.is{Left,Middle,Right}MouseButton(evt) && clauses, the codes terminate in the rotate() method and is not processed for translate. hence, my 'right mouse' drag is not processed, i lost 'panning' functionality. The above fix restored my 'preferred' behavior with a working translate on right mouse drag.

thanks ot @goodwilling for some pointers.

edit:
i'm suspecting that based on the conversations above, the button responses and order of the buttons could be different between mouses.
this is probably influenced by specific mouse drivers.

Your changes look good to me.