Multiple Viewport Issues

[gryff]

Well encouraged by some success with creating babylon files, I thought I would tackle a little scripting inspired by Wingnut's trial and tribulations with multiple viewports. I created two viewports, Viewport 1 showing a box and just behind it a blue plane, Viewport2 showing a purple sphere with a black plane just behind it.

 

In the image of the two viewports attached below have marked the two issues I am having 1 and 2

 

Issue 1.  The two viewports are created successfully - the grey area is the scene.clearColor. This is the line of code that positions the small second viewport:

var viewport2 = new BABYLON.Viewport(0.75, 0.75, .25, .25);

I expected the viewport to be flush with the right edge of the screen - but it is not. Any ideas why?

 

Issue2. I set up the little box to return pick information when it is clicked with the following code:

   //Click event        window.addEventListener("click", function (evt) {        // We try to pick an object        var pickResult = scene.pick(evt.clientX, evt.clientY);        console.log(pickResult.hit);               if (pickResult.hit)        {                    object = pickResult.pickedMesh.name;                     switch(object) {                            case "aBox" :                    divPick.innerHTML = object;                    break;                                default:                    divPick.innerHTML = "----";                    break            }        }                }); //end of click event

It works fine if there is only one viewport. But as soon as Viewport 2 is added - it fails. The console.log line of code returns "false" when the little box is clicked with two viewports present

 

Any ideas why ?

 

cheers, gryff

[Wingnut]

I inspired somebody !!!  Holy crapski !!!  PARRRRRRRTY !!!! 

 

Gryff, have ya got your babylonJS-famous CSS style crap onboard?

   <style type="text/css">        html,body,#canvas {            width:100%;            height:100%;            padding:0;            margin:0;            overflow: hidden;	    background-color: black;        }    </style>

I'll do some more thinking, too... but the style thing spanked me once or twice, so I thought I better mention it.  Also, the 'new' bleeding edge way to set the text of a html tag... is with .textContent, and ya might want to put a 'var' in front of object = .  And never be afraid to use long variable names...  like objectName. 

 

Let's say your div had an id="divpick".  Then your line COULD be...

 

document.getElementById("divpick").textContent = objectName;

 

That way you wouldn't need to use a document.getElementByID somewhere out in global land.    Your scripting looks just fine, though, in general.  Don't sell yourself short on your scripting abilities.  You're smokin'!

 

Be aware:  Our BJS scene.getMeshByID("some_mesh_ID")... uses 'ID', but DOM's document.getElementById("some_html_Id")... uses 'Id'.  Fun with capitals. 

[gryff]

Gryff, have ya got your babylonJS-famous CSS style crap onboard?

 

Wingy, yes - basically I am using a rearranged version of your viewports file with the basic css. I dropped viewports 3-5, rearranged the code for each viewport (so I could rem out viewport 2 quickly), added a div tag and some css for the new tag to report the picked object, added some rem comments for my own info, then added the "click" event code. Nothing very fancy. You can download the simple html page as a zip file here:

 

Viewports

 

I can live with the margin issue - I suspect it may have to do with how browsers handle the right side of the screen. However, the breaking of the "pick" on meshes with two viewports is either my clumsiness with javascript or a bit of a disappointment if it is not possible. I particularly want to be able to click on a small object, a book perhaps,  in a scene (like my "10bells" scene) and be able to get a different closeup view of the book and perhaps even turn pages. I figured that using two viewports and showing and hiding one of them might be the answer. An idea I got from reading your viewports tribulations.

 

cheers, gryff

[Wingnut]

Hi gryff! 

 

I like your idea.    Its cool.  Books, bottles, detail-viewer.  good idea!

 

Um, here is a zipped version of my weird test.  In that zip, there is a picture of what your test... looked like for me... when I first booted it.  To be frank, I did not see any right margin weird things, so I would almost say that something is strange with your monitor-width and graphics display width... at your place... regarding that right margin situation.

 

Just guessing, though.  In my demo, I pulled it all left a little bit... and let me know if my thing looks different from yours, regarding that right margin, and we'll do some more pondering about why.

 

Now, for picking.  Oh boy.  I believe that babylon.js picking is NOT READY for multiple viewports.  But I have said things like that before, and it always turns out to be "Wingnut not ready to understand how stuff works."    I got picking to work in the left viewport#1 ok, but not at all in the right viewport#2.

 

Its all a blur now, but, one thing I saw... is that it matters WHICH camera you push into scene.activeCameras first, and which second.  It seems... that the last camera pushed into that array, is automatically set as scene.activeCamera.  Weird. 

 

What happened is that you made cam1, and pushed it into scene.activeCameras.  Then you tried to set camera1 as scene.activeCamera, and that worked.  Then you made cam2, and pushed it.  That set scene.activeCamera to camera2, unwantedly.  As long as camera2 was the most recent camera pushed into scene.activeCameras, BJS was not going to allow camera1 to be set as scene.activeCamera... as best I can tell.  When I switched the order of scene.activeCameras array, then I was allowed to set scene.activeCamera = camera1.  Strange.

 

So camera 2, being the last one pushed into .activeCameras... remained as the scene.activeCamera... no matter how much you tried to say otherwise.

 

So, picking on viewport1 flopped, because camera2 was active... over in viewport2.  And it wouldn't show you...  that IT was picking things, because...

 

1. picking in viewport #2 doesn't work at all, and

 

2. even if it did, you had no case "aPlane2" or case "aSphere" in the event function... reporting up to pickDiv.

 

Boy, this was a tough one to find.  At first I thought evt.clientX and evt.clientY was screwed up, and needed to be halved... because we were now operating in half-screen width.  Nope, not that.  Then I noticed... that if I clicked right near the center between vp1 and vp2, pickDiv would report aBox just got picked.  hmmm.  Weird.

 

So, to make a long story even longer, currently, it starts in fullscreen on viewport0, a new fullscreen viewport I made.  Click the box, and it detaches cam1 from viewport 0 and opens viewport 1 and 2... both half-screeners.  I have remarked-out the camera2.attachControl(canvas), so viewport 2 stays locked on the sphere and the now-green plane.  They both are now located out at z-axis -1000.  I built a little photo studio way out there... (Gryff's Z-1000 Studios) so there would be no overlapping of picking.  In other words, as long as aPlane and aPlane2 were sort of atop each other, there was a chance that a pick could go thru one and hit the other. I wanted aPlane2 and aSphere FAR AWAY from aPlane and aBox... and they now are. 

 

Click on the blue plane of viewport1, and viewport 2 closes, and camera1 gets control again, and scene again goes normal fullscreen.

 

I have pick-listeners in the switch-case event code... listening for picks on aPlane2 and aSphere... when viewport2 is open... but I just cannot get pick events from viewport2 to happen.

 

I tried strange things like:

	engine.setViewport(camera2.viewport);	scene.setTransformMatrix(camera2.getViewMatrix(), camera2.getProjectionMatrix());	camera2.viewport.toGlobal(engine);

...just feeling around in the dark, trying to get picks to work in viewport2.  No luck.

 

Anyway, the zip is full of comments. It is also more ready for what I THINK you want to do with viewport2, but... there is something I don't yet understand... with pickingRay, or something.  I will keep working on it, but I thought you should have what I have so far, and hear what has been done so far... and also let other users grab our zips and try to help.

 

Again, click box, opens viewport 2.  You can turn on camera control for that viewport2 if you please.  Currently remarked-out (disabled).  Click on blue plane in vp1, closes viewport2... normalizes the scene. 

 

I know you are going to need vp2 picking/clicking if you want to turn pages of a book... and for all sorts of "examining in detail" activities that could be done in that "aux viewport".  Again, I love the idea of "detailed view". What a great use for a pop-open, pop-closed viewport.  I hope we get the beast working.  We will.  We'll put the really smart people on the job if we need to.    There's lots of cool stuff to be learned in my zip, I hope.  I made lots of functions and did lots of goofy but maybe useful things.  Should be an hour of laughing, for ya, anyway.    Good luck.  I'll keep ya posted of what I learn, you do the same for me, eh?  Thanks.

 

A quick note to DK... it seems that if a plane is created size 1, and then is scaled big, picks only work on the size 1 part of the plane and not on the scaling-made part.  When I created aPlane size 1, then scaled it to be 20 x 40, picks failed on it.  *shrug*.  I could be wrong, too.  I often am. 

[Dad72]

You will able to write a book of 500 pages soon.  I confess to being discouraged to read so many thing.

[gryff]

Thanks for your efforts Wingy - I did not mean you to spend a whack of time on it - but I will spend time after supper going through your efforts. Hopefully we are getting nearer either a solution or an explanation about what is going on. As I said before the margin issue, I can live with. It might be a monitor issue as I get the same results in two browsers FF and Chrome.

 

So onward and upward!

 

TY in advance for your efforts.

 

cheers, gryff

[gryff]

@dad72 - it will be more than just books ;-)

 

And if it is a book - probably won't be anywhere near 500 pages - and maybe I can  get my french speaking daughters to translate for me.

 

cheers, gryff

[Wingnut]

gryff, I think dad72 was referring to my mile-long posts. 

 

Sorry Dad72.  Sooo long, eh?  But, lots to explain.

 

Look at this...

 

http://blogs.msdn.com/b/eternalcoding/archive/2013/01/16/hand-js-a-polyfill-for-supporting-pointer-events-on-every-browser.aspx

 

Now THAT is long!  Me?  Little stuff. 

[Dad72]

I understand   You love to write. Ofcourse I told you that with the smile.

[gryff]

Wingy, TY again for the code - interesting to browse through. You did a nice job of getting the second viewport to show

 

But ...

 

No controls for cam 2 at the moment. Change at will. It should stay focused on the book or bottle... but still allow picks/clicks.

 

The no controls is not an issue - I just wanted to be able to click on objects in veiwport 2. You tried a number of ways I see, but as you succinctly put it "Things wingy tried... to get picks working in viewport 2.  Failed."

 

Now I did tinker with this line of  code :

scene.activeCameras = [camera2, camera1];

 and changed it to

scene.activeCameras = [camera2];

 Now viewport2 is clickable - at least partially the green plane but not the sphere (why?) - but of course there is no viewport1 any more .

 

I added

endViewport2(scene);

to the green plane - case: "aPlane2" in the switch set up - so I can toggle back and forth between viewports.

 

I will play some more later today.

 

cheers, gryff

 

 

 

 

[Wingnut]

Cool.  Interesting.  Thanks.  Yeah, I think the picking started working in viewport 2... because there was no longer a viewport 1.  That pickingRay thing...  it wants a single viewport, I think.  Too bad, because it WILL succumb to our demands, or else it's fired.    (like I have any say)

 

Did you see in the scene source code ... line 983...  that you can add a few more args to the 'pick' call?

 

scene.pick(evt.clientX, evt.clientY, null, null, scene.getCameraByName("Camera2"));  ??

 

I goofed around with that a little bit... no changes seen.

 

I am starting to think that the framework should maybe do... 

 

scene.pick(viewportX, viewportY);  (certainly not DOM event-ready)

 

As a temporary work-around, you could make new keypresses become active... when vp2 is open.  Page-up and page-down could zoom in and out, < and > could turn pages, [ and ] could choose 'next book' and 'next bottle', etc.  *shrug*.  In the tradition of adventure games, vp2 could also be used with dynamic text textures... to list the user's inventory... and used to select an item from it... to hold... or view the graphical details-of.

 

For 2D pop-open windows, we could turn to the same method that our Virtual Joysticks use... which is to put a sub-canvas atop our main canvas.  When I first saw our Virtual Joysticks code, I found it rather interesting, and potentially very useful for many types of GUI.  vjCanvas could be developed into a powerful universal "subCanvas" system, someday.

 

Thanks for the update.  I have no new news for you.

[GameMonetize]

When using picking with multiple cameras you have to use the complete pick function:

        Scene.prototype.pick = function (x, y, predicate, fastCheck, camera) {            var _this = this;            /// <summary>Launch a ray to try to pick a mesh in the scene</summary>            /// <param name="x">X position on screen</param>            /// <param name="y">Y position on screen</param>            /// <param name="predicate">Predicate function used to determine eligible meshes. Can be set to null. In this case, a mesh must be enabled, visible and with isPickable set to true</param>            /// <param name="fastCheck">Launch a fast check only using the bounding boxes. Can be set to null.</param>            /// <param name="camera">camera to use for computing the picking ray. Can be set to null. In this case, the scene.activeCamera will be used</param>

[Wingnut]

Thx dk.  Like this?

 

var pickResult = scene.pick(evt.clientX, evt.clientY, null, null, whichCam);

 

(I have 'whichCam' as a global, continuously updated in the render loop)

 

Gryff and others... here is my latest zip, (x2), using the line above.  Now I only get picks on aPlane, no matter where I click.  And therefore, I can't get vp2 to open (no picks on aBox).  I made some more divs...  actually spans.  They are set when the event triggers.  They report evt.clientX and evt.clientY, and whichCam.name.  I was hoping for accomplishment, but I backslid.  :/  The only other significant changes I made...

 

goViewport2(scene) ... I changed the order of the cams in scene.activeCameras yet again.  NOP

 

endViewport2(scene) ... I detached camera 2 from the canvas... camera2.detachControl(canvas);  NOP

 

In this case, NOP = No Observed Progress.    *shrug*  Debug on!

[gryff]

Thanks DK - I think that was what Wingy was pointing too as well in the post above you.

 

And you have gone further than me Wingy. I tried

var myCam = camera1;var pickResult = scene.pick(evt.clientX, evt.clientY, null, null, myCam);

and got a message that "camera1 is not defined" - because it is not a global variable.

 

I gave up at that point figuring I would need to reorganise the whole code.

 

I've been looking after my daughter's dogs - an Italian Greyhound (an "iggy") and a golden retriever. The iggy is a lovable dog - but can find trouble in a seemingly empty room. Can't take your eyes of her - so concentration goes out the window.

 

cheers, gryff

[gryff]

Now I only get picks on aPlane, no matter where I click.  And therefore, I can't get vp2 to open (no picks on aBox).

 

Wingy, I got the same result but...

 

when the first Viewport opens - zoom in a little with the up arrow key - now you can click the box  and viewport two opens, but no objectname in the pick box

 

cheers, gryff

[Wingnut]

Uhn, sure enough.  Good catch... and interesting. *scratch scratch*  Want to see another fun weirdness?

 

When vp2 is open, click above the box about 2 inches.  aSphere!!! 

[gryff]

Want to see another fun weirdness?

 

When vp2 is open, click above the box about 2 inches.  aSphere!!!

 

And everywhere else on the blue plane - aPlane1 - registers as "aPlane2" in the pick box.

 

If you change the code for the aSphere case statement:

case "aSphere" :  divPick.textContent = objname;  endViewport2(scene);  break;

Clicking on that invisible sphere on the blue plane actually closes the second viewport!

 

This seems like a situation that beer was invented for

 

cheers, gryff

[Wingnut]

haha.

 

Yep, it saw a click on aSphere, so anything you add inside that case "aSphere"... will also happen.  The important part is that it saw a pick on aSphere.  See how the pick is sort of acting like the two viewports are sitting atop one another?  That is why I thought it was a good idea to move the mesh and camera for viewport 2... far far away from the mesh and camera for viewport 1.  *shrug*

 

Yep, we have the pickingRay well-confused.    Deltakosh and others will help us with this, eventually. DK is in the middle of "the great typescript conversion" so he is a little busy at the moment.  He probably hasn't showered or eaten in days, and his wife will be wondering who is the stranger in bed with her... if he ever gets there again. 

 

He is on a mission much much larger than ours.

[Dad72]

Yep, we have the pickingRay well-confused.

I ask this question once between pick() and pickWithRay()

The answer is here:

http://www.html5gamedevs.com/topic/3874-pick-and-pickwithray/?p=24475

[gryff]

See how the pick is sort of acting like the two viewports are sitting atop one another?

 

Yes it is very odd behaviour Wingy. May very well be above my javascript pay grade.

 

cheers, gryff

[GameMonetize]

could you share a sample on jsfiddle guys?

[Wingnut]

Thx for your interest, Deltakosh.  If you are busy, don't be concerned... Gryff and I can slowly troubleshoot more.

 

http://jsfiddle.net/87YW4/4/

 

I am not very good at making jsFiddle things.  I hope I did it correctly.

 

Run.  You see aBox and aPlane.  Click on gray box (aBox)...  might fail. 

 

To make aBox click work (and open viewport 2), click .5 inches right of aBox...

 

or...

 

Zoom camera with cursors until aBox is bigger.  If not able to zoom camera, click on 'test' to focus canvas.  Zoom in.  Click on box (aBox).  Viewport 2 opens (with aPlane2 and aSphere) - normal. 

 

When viewport 2 is open... clicking anywhere... picks aPlane2 (green plane).  Click on red sphere (aSphere), no pick.  Now click 1 inch above gray box. aSphere pick happens.  It closes viewport 2... normal. 

 

aSphere is not located in viewport 1.  It is located in viewport 2.  Code acts like viewport 2 is on top of (atop) viewport 1, according to pick.  (Viewport 0 is used with camera 1... when scene is full-screen.)

 

Main problems:

   Need to click to the right-of aBox, or zoom-in to aBox... before pick works.

   When 2 viewports, aPlane2 pick is happening everywhere (except 1 inch above gray box - then it is aSphere).

   When 2 viewports, pick for aSphere happens above gray box (wrong viewport, and aSphere not located there).

 

Gryff, I hope you don't mind me jsFiddling your code.  Deltakosh, thanks for looking at it.  If you are busy, don't worry about this.  I suspect Gryff agrees with that.

 

One comment typo:  'get camera2 off-of viewport3'  should read 'get camera2 off-of viewport2'

[gryff]

I am not very good at making jsFiddle things.  I hope I did it correctly.

....

 Gryff, I hope you don't mind me jsFiddling your code.

 

Well Wingy, as I know nothing about jsFiddle, I am reminded of an old saying:

 

"In the kingdom of the blind, the one-eyed man is king."

 

Mind you  I could not zoom with arrow keys and only one out of 4 tries managed to find the click spot to open second viewport, but then given the weird behaviour we have found can't blame jsFiddle.

 

And as for my code - it is probably more yours than mine at this point at this point.

 

I spent the day playing with skyboxes and heightmaps - I'm not sure you want to know. But that should be another thread

 

cheers, gryff )

[Wingnut]

Hi again.    Did you click on one of your 'test' divs in the scene... before trying to cursor-zoom?  That seems to works for me, consistently.  But yes, nothing can be predicted on this puppy.    We've 'scene' it all, haven't we?  The world of 3D web is young, and we are all trailblazers.  It's a good time to leave many ugly bulldozer ruts and do lots of littering.  hehe

 

Speaking of littering, jsFiddle is generally called a "whiteboard"... a place where everyone and their neighbor can "fliddle" with the code and see what happens, live, online.  I bet you had that already figged.  Make a change, hit run, make a change, hit run.  Avoid the 'update' choice as that makes a new version of the 'fiddle'... even though I still used 'update' 4 times... somehow.  That's why the URL has a /4 on it.  I took many of the comments out, because big-dog coders don't like talkie source code. 

 

Gryff, feel free to use The Wingnut Chronicles to rattle about anything you want-to, anytime. It's a free-for-all 'chat' zone.  If you feel like talking about your adventures in skyboxes and heightmaps there, go for it... glad to have it.  This goes for everyone else, too.  Or start a new thread... "My Adventures in Skyboxes and HeightMaps".    There's no laws that say forum threads have to be problems or questions.  Getting naked in public is pretty fun... and I have proudly made an idiot of myself many times in the chronicles thread.  The people in this forum are great, and they have clothed me many times... and set me on more-correct paths.

 

Gryff did you notice that Deltakosh asked you over in Tutorial Talk... to tell us of all the things you notice... that change when you export from Blender?  "Gryfferences - Blender Exporting Before & After"  hehe.  We thought that you should start a never-ending thread (introduce its purpose in the first post)... where you and others could tell us of things that are different... after they make the trip through the Blender->Babylon.js exporter.  You are one of the best modelers around these parts.  At minimum, we'd love to have you keep a journal of 'anomalies' you see... regarding 'Blendylon' (the exporter).  Feel free to deal with that request in any way you wish, or completely ignore it, of course.  But know that Deltakosh and probably many others... are interested in things you see that don't seem right... when exporting from Blender.

 

Ok, Wingy has rattled-on long enough, again.  Party on!

[GameMonetize]

OMG I thought I became mad with this bug

 

Which is not a bug (not in babylonjs )

 

So:) because you are using clientX and clientY you are getting the position from the window origin BUT because there is the infoline header there is a slight offset on Y (the height of the header)

 

Two ways to fix that:

use offsetX and offsetY but this is not really well supported across browser 

use absolute positioning:

        #canvas {            position: absolute;            left: 0;            top: 0;        }		#infoline {            position: absolute;            left: 0;            top: 0;			background-color: rgb(128, 128, 128);			line-height: 2em;		}