Multiple Viewport Issues

[gryff]

OMG I thought I became mad with this bug

 

TY - DK that fixes the issue with the initial click on the grey box.

 

But there is more madness to come - see the image below.

 

Once the second viewport is open, clicking on the purple sphere is supposed to close the second viewport - but it does not.

 

To close the second viewport you have to click approximately where the red circle is.

 

Clicking on the purple sphere tells you that you have clicked on the green plane - almost like you click through the sphere.

 

Maybe Wingy will have some more thoughts and experiences too.

 

cheers, gryff

[GameMonetize]

Could you send me a link or a jsfiddle so that I can debug?

[gryff]

DK -maybe Wingy can set up a jsfiddle, but in the mean time here is a zip file containing all three files.

 

twoviewports

 

Don't lose your mind over it or let it take you away from important things.

 

cheers gryff

[Wingnut]

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

 

(New jsFiddle)

 

Not yet fixed.  Now infoline is moved to bottom.

 

Now click below and right of gray box to open viewport 2.

 

- When 2 viewports, aPlane2 (green) 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... aSphere is not located there).

 

Reworded: click down and right of gray box... to open viewport 2.

With viewport 2 open, click above gray box (about 50 mm?) to pick aSphere.

With viewport 2 open,  click anywhere... even in viewport 1 (aPlane)... shows aPlane2 being clicked (except 1.5 inches above gray box - which shows aSphere clicked.  aSphere is not there.  It is in a different viewport.

 

Let's try a translation.

 

Infoline a été déplacé vers le bas. Pas plus clientX et clientY compensés problèmes. A ce moment, vous êtes tenu de cliquez sur le coin inférieur droit de la boîte grise ... pour ouvrir fenêtre 2.

 

Avec fenêtre 2 ouverte, cliquez sur un emplacement rapports aPlane2 est cliqué. Sauf lorsque vous cliquez sur un emplacement à une certaine distance au-dessus de la zone grise. Puis il signale asphériques est cliqué. asphérique n'est pas à cet endroit. Il s'agit plutôt d'en fenêtre 2.

 

Pour résumer, boîte grise clic activité est ci-dessous et à droite de la boîte grise, et quand fenêtre 2 est ouvert, en cliquant n'importe où près rapports aPlane2 est cliqué. Pour cliquer asphériques, vous devez cliquer dessus de la zone grise, qui n'est pas près de asphériques à tous.

 

Thx for your work, DK, but we are only getting started.

[gryff]

Now click below and right of gray box to open viewport 2.

 

Actually Wingy the grey box appears to be working fine for me, but as you say, once the viewport is open even the grey background is "live".

 

TY for doing the jsfiddle thing. And, DK, please forgive Wingy and I for any mental stress we are putting you under

 

cheers, gryff

[GameMonetize]

the thing is that is you want to pick in the green viewport you have to provide "adapted" mouse coordinates meaning not relative to the full canvas but only to the viewport

[Wingnut]

Yep, that was talked about here... http://www.html5gamedevs.com/topic/5973-multiple-viewport-issues/?p=35947

 

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

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

 

*scratch scratch*

 

Oh well, we gave it a good try, Gryff.  Thanks for the analysis, DK.  I'll do some more thinking and testing when I get a chance.  I guess we have to convert the viewport.width and viewport.height... to pixels (they are currently a float between 0 and 1), then... convert those to percentage of total canvas width and height.  Then calculate the same percentage... against evt.clientX and evt.clientY, and then send those numbers as the pick args... something like that.  *shrug*

 

If we need to deduce a formula here, I suppose we better make it ready for any number of viewports wide and any number of viewports tall... thus... percentages get involved.  Yep, beer time. 

[gryff]

Well I tried changing a a few of the viewport settings:

function makeViewports(scene) {    // create 3 viewports.  #0 is for fullscreen, #1 and #2 for split screen.    scene.viewport0 = new BABYLON.Viewport(0.0, 0.0, 1, 1);    scene.viewport1 = new BABYLON.Viewport(0.0, 0.0, 1, 1);    scene.viewport2 = new BABYLON.Viewport(0.0, 0.5, .5, .5);}

essentially not changing the size of Viewport1 when the box is clicked, and opening the new Viewport 2 in the top left corner of the window see image.

 

Clicking on the purple sphere now works.

 

For anything else, I think you are right Wingy a lot of fiddling around with the math of screen, browser window  and viewport sizes

 

cheers,gryff

[gryff]

Using my very limited javascript talents I have tried to do the math so that clicking on the purple ball in the second viewport screen  will close the second viewport screen.

 

Try it here : 2viewports

 

Click on the grey box to open the second viewport . - then try to find problems and let me know.

 

I will post the code later - and there maybe (likely even) be better ways to code it ;-)

 

cheers, gryff

 

Edit: here are the zipped code files 2viewports.zip including babylon.1.11.0.js

[Wingnut]

Yeah. it looks like you have yourself an operational workaround, at least.  When viewport 2 is open, aPlane2 is pickable all over the screen, but if that doesn't get in the way of your needs, I guess you can't complain.  Pretty fancy math ya got going there, G!

[gryff]

As you say Wingy it is a workaround. There are two issues that drive the math:

 

1. The click event reports its co-ordinates with 0,0 being the top left of the screen and are in pixels.

2. The viewport properties are from 0,0 at the bottom left of the screen and range from 0 ->1

 

And resizing the has to be taken into account.

 

And I still do not understand why that second viewport thinks it is hiding away - always at the top left of the screen.

 

Maybe some of your "murmered shrugs" will eventually cause a change  

 

cheers, gryff

[Wingnut]

Nod.  Deltakosh ALWAYS strives to makes things easy for the users.  And if you saw the pickingRay code, it is not simple code at all.  He may not have a magical solution to this situation at this time, but I think he stores stuff in the back of his mind, and mulls it over.  In this situation, we have a DOM event... working with a 3D pick on a webGL canvas... in a scene.  Difficult enough by itself, but then maniacs like you and I... try to do goofy stuff, and mess-with an already complicated situation.

 

Ideally, don't be in a hurry.  Deltakosh is very very smart, and if he doesn't invent a magical way to improve this task in the framework, he will likely come up with some really nice formulas that users can include in their createScene funcs.  Also, keep in mind that DK's hands are tied... by webGL.  He can only do just so much... and then webGL/openGL stands in his way.  But rough water like you and I found... CAN affect the future of webGL itself.  And if that changes, new avenues can open for you, I, and the framework.

 

You can rest assured that Deltakosh is giving this thought... and if he can come up with something to make it easier for us, he WILL implement it or tell us about it.  He is a very accommodating chap, but he also can see 'the big picture' much better than you or I.  There are quite a few 'issues' that are involved in this.  If you can lay back a bit and give deltakosh some time to mull this over, I tend to think he will come up with a sweet and powerful formula for us to use in the short term, and possibly a framework accommodation in the longer term.  He's a great guy and smart as a whip.  If there's a way to help us, he'll find it and gladly give it to us.

 

Feel free to keep experimenting with it, of course... but... don't blow a brain fuse or get too impatient, if possible.    You know how to open a second viewport, you know how to point a camera at its meshes, and you know how to put a div or two at the bottom of the screen.  Maybe think about what i said earlier, about making a bunch of keypresses go active, when viewport 2 opens... like the [ and ] keys, and the < > keys, or (n)ext page and (p)revious page, etc.  When viewport 2 opens, display a div at screen bottom, telling the users what keys they can use to do things in viewport 2.  It may save you some headaches, yet you will be ready for picking in viewport 2 if/when that option becomes more viable.  Just thoughts. 

[gryff]

Ideally, don't be in a hurry.  Deltakosh is very very smart ...

 

You can rest assured that Deltakosh is giving this thought... and if he can come up with something to make it easier for us, he WILL implement it or tell us about it.

 

 

Don't worry Wingy - right now I have something I can work with. An important piece of functionality and game mechanics - so I want to now use it in a practical way.

 

Feel free to keep experimenting with it, of course... but... don't blow a brain fuse or get too impatient, if possible.

 

The important part of it all is your code - the five functions: makeCams(scene); makeViewports(scene); initViewport(scene); goViewport2(scene); and endViewport2(scene). And for that I am very grateful.

 

Im not going to tinker with that. I may tweak the math bit - and may even try to set it up to open more than one extra viewport but I am a great believer in "if it ain't broke, don't fix it"

 

I want though a game example - and already I have started building in Blender and hopefully it won't take too long.

 

Again thank you for all your help

 

cheers, gryff

 

 

[GameMonetize]

You're cute but this is not so complex. However you are right on at least one point: next version will include the following fix so you will never have to bother with coordinates and picking. Babylon.js will handle that for you

 

btw here is the code to offset mouse coordinates:

            var cameraViewport = camera.viewport;            var viewport = cameraViewport.toGlobal(engine);            // Moving coordinates to local viewport world            x = x - viewport.x;            y = y - (this._engine.getRenderHeight() - viewport.y - viewport.height);

[Wingnut]

Thanks dk and gyrff!

 

Gryff, I don't claim ownership over anything at all.  I'm a socialist and altruist at heart, so use anything you wish and even claim it as yours... not a problem.  I'm honored if you find anything I code... useful.  I gather my enjoyment from looking at other people's art/scenes, and with making discoveries with people's frameworks. 

And chatting with folks.

 

And by the way gryff, don't believe him for a second.  Nothing is complicated to DK.  Friggin' genius, ya know? 

 

For me, pickingRay code such as BABYLON.Ray.prototype.intersectsTriangle... looks like schematics to a nuclear reactor. 

[garidan]

I up this post with a modified version of drag and drop example, extended on 3 viewports.

Be warned, I'm a 3D beginner

 

http://jsfiddle.net/garidan/zbgkq8nr/6/

 

I aim for a 3D view paired with a top and a side view of the scene, all three with draggable meshes.

I managed to have drag and drop on 3D and top view, but I miss drag and drop on side view (lower left viewport).

When drag and drop starts working everywhere, I'll attach the ArcRotateCamera to canvas events, and detach it on clicks outside 3D viewport.

 

Can anyone of you suggest what I'm doing wrong please ?

 

 

Thanks

 

 

[Wingnut]

Hi Garidan, welcome to the forum... good to have you, and your tri-view is pretty cool.  I assume you meant "lower right viewport" 

 

I am a bad programmer, but I took your code home and played with it.

 

The problem is here...

if (pickinfo.hit) {     console.log(pickinfo.pickedPoint);  // I added this line     return pickinfo.pickedPoint;}

We get good console.log output when dragging in the main viewport, and in the top-right viewport, but no output when dragging in the lower-right viewport.  You are the first person to ever try drag'n'drop from a side view, and I think there is a situation in the framework itself... that is causing the problem.

 

Without getting good pickinfo.pickedPoint from the framework, your onPointerMove function will not work correctly.

 

I don't know how to fix this, but maybe some forum experts will be able to help... now that we know what is happening.  Sorry that I could not be more helpful.

[joshcamas]

*Actually* he's not the first person ever to try it from a side view. I happen to know the problem

The problem is this entire demo. Basically it needs to detect a point "in the air" where the mouse is clicking. Which makes a problem. This demo "fixes" this problem by adding a mesh (the plane/ground) that will detect clicks! Hacky, but it works... unless you're not clicking the plane...

I managed to fix it in my editor by shamelessly copying the Babylon Editor and making it better. :3

I'll make an example on the playground in a bit, k?

 

EDIT: Annndddd made it! http://playground.babylonjs.com/#1RQ5E5

It took a bit of work, but it works now! Note that I made it so you cant drag it lower than y=0, just because. This can be removed if wanted. 

I made it so when you "tagged" a mesh as "draggable", (mesh.draggable = true) then the mesh is... well, draggable!

Enjoy! Parts of the code was written by the coder who made the Official Babylon Editor!

 

EDIT2: I added a fancy alpha-changing thing to the ground, just for fun. Hey, I was bored, ok!?!

http://playground.babylonjs.com/#1RQ5E5#1

[garidan]

Great !

It's easy to say now, It was a simple reason for it not working, I forgot about the ground trick ;-)

 

I go forward and modify my test, I'll post an update for others to come.

 

Thanks everyone

[garidan]

OK, I learned a little more and I have almost anything do what I want, ... almost.

Here is my updated code: http://playground.babylonjs.com/#1PA7HW#9

I have a problem with the lower right viewport, the side view. Drag and drop works on the ground plane, that is x-z axis, not on the x-y plane as I would like.

I think the problem is in the transformPosition(camera) function where it gets the projection matrix and view matrix from the scene, with no reference to the viewport/camera involved (but the top view works ...).

Or is it due to a "special role" of ground ?

Code is clean, I would not like to patch with a hack.

May you help me please?

[joshcamas]

I believe you are correct garidan. I'll try to fix...

I got a partial fix on it: http://playground.babylonjs.com/#1PA7HW#10

However it's not completely fixed. :/ You seem to have edited the code so much I'm not sure why/how it works :3

[garidan]

I compared your code with mine.

You used: 

var wMCamera = targetCamera.getWorldMatrix();

instead of identity matrix, I can understand that.

But to let side viewport work you had to switch the order of scene active cameras, pushing side camera as last one:

scene.activeCameras.push(topCamera);

scene.activeCameras.push(camera);

scene.activeCameras.push(sideCamera);

 

I think this shouldn't be and the fact this made side panel work (and disrupt top panel) means scene projection matrix and view matrix are dependent on current "last" active camera.

var pMScene = scene.getProjectionMatrix();

var vMScene = scene.getViewMatrix();

 

It should be possible to specify as argument a camera or viewport, something like:

var pMScene = scene.getProjectionMatrix(camera);

var vMScene = scene.getViewMatrix(camera);

 

What do you think?

 

PS: top panel now doesn't work anymore because y axis seems switched ... I'm going to patch it ..

[garidan]

My patch for top panel is to reverse z axis drag (I don't know why I have to do this):

 

// PATCH

if (targetCamera.name=="topCamera") {

res.z=-res.z;

}

 

Code working:

http://playground.babylonjs.com/#1PA7HW#11

[joshcamas]

That works.  

I am wondering how this could be fixed however, without the hack.

[FreeFrags]

hi,

 

is it also possible to render a viewport onto a new canvas? if not how can we make it look like a vp is drawn in a different window add a border around the viewport for example