How to get fullscreen for 3D rig

[JCPalmer]

engine.switchFullscreen(true); does not work.  How are other people with 3D scenes getting the display into fullscreen?  Looks like you need to put a native html button on the page, but then the scene will not be covering the entire display.  The stereo rigs for sure will not work right unless they use the entire screen.  You also need to delete the button afterward, or the illusion is going to be destroyed.

If you put in a Dialog extension button or I assume bGUI, it does not work.  It has to be a html button.

[Vousk-prod.]

switchFullscreen function is ok, but it works only on some browsers (Apple limitation for instance, that doesn't allow web app to go fullscreen).

To create a button to manage fullscreen is the duty to the final app dev, not the 3d engine. BJS  provides a method to put 3d canvas fullscreen, the rest is the work of BJS users.

[JCPalmer]

Ok, figured out when you go to fullscreen, the code in repo makes the scene take the whole screen.  Big problem is that I no-longer have a cursor.  Am using ArcrotateCamera for scene.  Target just spins. in FireFox.  See

I am using 2.4 as of yesterday.  Was having trouble clicking the Dialog extension buttons too.  Think there is something wrong with the input system of 2.4.  Am trying to get postprocessing and 3D rigs working together, so I cannot go back to 2.3.  This is turning into a larger challenge than I thought.  Will see if Android tablet / chrome does the same.

[JCPalmer]

Ok, works in Android!!!!  Now I can check my changes on my 3D TV, without making a CocoonJS app.  Just update googledrive, & screencast from tablet to TV.

This is still a weird firefox issue though.  Am using v46.0

[GameMonetize]

Did you find the problem with input?

[JCPalmer]

No, since it sort of works eventually, trying to suffer through, till camera work do.

[JCPalmer]

Ok, this picking thing pissed me off one too many times.  I put this into the Dialog extension on my local system.

scene.onPointerDown = DialogSys.onWTF;

. . .

public static onWTF(evt: PointerEvent, pickInfo: BABYLON.PickingInfo) : void{
    var mesh = pickInfo.pickedMesh;
    console.log("mesh picked " + (mesh ? mesh.name : "nothing"));
}

When you click on a "button", you might actually hit 1 of 2 meshes.  The first mesh is the merged geometry of all the letter meshes.  It is very slightly proud of the gray backing mesh, which is the actual button.  The button has the action manager.registerAction. If you make sure the pointer is not on the letters when you hit the button, it works.  On 2.3 it would work with either mesh, on 2.4 looks like the click is being consumed by the letters label mesh even though there is nothing registered on it.

That's why VR & None worked a lot more.  Their letters geometry took up less space, so you had a higher probably of not hitting it.  Is this change for 2.4 intended?

[GameMonetize]

For 2.4 I just introduced a way to specify your own picking predicate. But by default here is the one used:

https://github.com/BabylonJS/Babylon.js/blob/master/src/babylon.scene.ts#L701

[JCPalmer]

Ok... (what's that mean?) ... shouldn't the default be one that matches prior behavior?

[JCPalmer]

I made an override of default.  Was not sure what returning true means, ready to consume?  Returning false when the parent is button does change the name of the mesh in the onPointerDown message to the actual mesh with the action, but still only runs action when not clicking text.

public static pickPredicate(mesh: BABYLON.AbstractMesh) : boolean {
    var buttonParent = mesh.parent instanceof Button;
    if (buttonParent){
        var parent = <Button> mesh.parent;
        console.log("original mesh " + mesh.name + " parent " + parent.name + " ret " + (parent.isPickable && parent.isVisible && parent.isReady() && (!parent.actionManager || parent.actionManager.hasPointerTriggers)));
        return false;
//        return parent.isPickable && parent.isVisible && parent.isReady() && (!parent.actionManager || parent.actionManager.hasPointerTriggers);
    } 
    return mesh.isPickable && mesh.isVisible && mesh.isReady() && (!mesh.actionManager || mesh.actionManager.hasPointerTriggers);
}

I updated the scene above with a dialog ext logging in onPointerDown & and pickPredicate.  Is this what I am supposed to do?

[GameMonetize]

The problem is that should be compatible with previous version.

returning true means: this mesh is candidate to be picked. The mesh is then tested with the ray to see if there is a collision.

 

can you check that your text is not pickable?

[JCPalmer]

I was defaulting to true.  I have now forced my Letter class (merged letter[] of clones is now just a big Letter) to isPickable = false.  Looked like is worked so I removed the pickPredidate & the onPointerDown error,  but click below the baseline in "Side-by-Side" or "Anaglyph" & it still fails.  Put the onPointerDown log back in.  In those cases, the mesh in the screen gets picked.

I want to get back to my original task of post processes.  I cannot remember what I did to make sure all the letters have the same base line at the moment, but I know I am doing something.  If you play with trying to get the same behavior as before by default in the meantime, let me know if you want anything.

[GameMonetize]

Can you jsut share a repro with a reference to babylon.max.js ?

[JCPalmer]

Think because it is public on google drive, that repo is already being shared.  The link is in a different format when you want to reference the files instead of as a web page.  Will PM with link.  I do not have a clean 2.4 max at the moment, changes to Camera.ts & messages in postProcessManger.ts.

I could just send you the link.  If you change one line at the top of index.html, you can run it with anything you want, or by repo do you mean a page not the files?

[JCPalmer]

Only took a moment to think, all I had to do was revert changes to head revision, then just compile again afterwards.  The name is still babylon.js, to avoid changing html.

Here is link to file access, if that is what you wanted.  Currently pickable for text is false.  Do you want me to change back?

[GameMonetize]

nope that's fine, thanks!

[GameMonetize]

Can you zip it? google drive is a pain in the ass when you want to download everything

[JCPalmer]

Done.  tester.zip has files matching rest of files in drive updated as of today.  dialog.js is back to the way where pickable is defaulted. 

babylon.js is a name changed max with my changes to camera / post processes (many console messages when switching rigs).  The other files as of 2 or 3 days ago.  Fetched right before I made last gulp, but saw you committed something with Gulp.  Decided not to merge.

[GameMonetize]

I'm on it

[GameMonetize]

Ok so far the texts are pickable so I do not see a problem. The bug was certainly before 2.4 because a pickable mesh as to be pickable

[JCPalmer]

In the index.html, if you comment / uncomment the BJS script tag to the 2.3, then clicks work no matter if you click over a letter mesh or a a gray area.

The letter meshes are pickable (yes, probably should not be), but they have no actionManager assigned.  I think the change is although no action is assigned, the click is consumed by the pickable mesh in front.  Mesh behind that actually has the action never gets called.

When I set the Letter class to non-pickable in its constructor a few days ago, there were side effects.  The triangle buttons on left & right of LCD scroller and checked & unchecked meshes are also Letter subclasses, since they come from blender in 2 & 3D versions.  There was also the weird pick to the scene mesh when the Letter went below the base line.

Just did a better implementation of only setting isPickable when the mesh has an action.  Everything inherits from Dialog.BasePanel.  It has a _button property.  I set isPickable to the same value in constructor & here:

/** for those who cannot set it in constructor, like buttons for NumberScroller */
public setButton(button : boolean) { 
    this.isPickable = this._button = button; 
} 

I seems to work again no matter what, but others may not.  Maybe just say you fixed a bug.

[JCPalmer]

Also, back to the original title of this topic.  I also tried using the playground with Firefox 46.0, and clicking its full screen button also results in lose of cursor, and seems like mouse is stuck pressed too.  I have not noticed this before.

Can anyone else determine that FireFox does this going full screen on the playground?  I am running Ubuntu.  Another OS data point might good.

[GameMonetize]

Yep this is the change I introduced in 2.4: pickable dictates the behavior. I hope this won't be a big deal for you

[Vousk-prod.]

In latest Firefox, on Windows 10, in fullscreen I have the same behavior as yours (no cursor visible, and click stuck pressed).

But in my own projects, I have no mouse cursor problem in fullscreen, so it may be due to your way of using the fullscreen function.

[JCPalmer]

I went back to double check things.  The argument to Engine.switchFullScreen is whether to request the pointer be stuck down, not whether to go fullscreen or not.  Maybe whom ever supports the playground should change the arg to false.  Fixed this for me.