Fix plane when resize in window

[juanmajr93]

Hi,

@jerome

@Wingnut

I have added a new element to my proyect. However I don't know how can I fix the plane on world when I resize window. If you test it in screen of (1920*1080) resolution, the scene is well. However if you change the window's size, the plane will disappear. I would like to set an unique position over right menu and avoid that plane could move to other place. Moreover, I want to remove specular or diffuse light in this plane so I set the property ( mon1.specularColor = new BABYLON.Color3(0, 0, 0)) but it doesnt work.

To make this implementation, I have used the follow example:http://www.babylonjs-playground.com/#1WROZH#12

Link to my scene: http://217.217.131.1:8081/subsuelo/

Thanks you very much.

[Wingnut]

haha.  Yuh, keeping a plane (mon1) that is parented to camera... docked against a screen edge... no matter the viewport size... is a serious challenge (somewhat difficult), I suspect.

I'll need to think about that issue for a while.  That's a brain challenger.  I suppose we could use an extra viewport along that right side.  With the added along-right-screen-edge viewport, the right side "menu" would be a PERCENTAGE-of-total-screen-width... wide.   For example, right viewport could be 20% wide... but... I don't think it could "mix-in" with any HTML sidebar you have over there... UNLESS... that HTML sidebar was absolutely positioned.

In other words, you MIGHT have a viewport along the right side of the screen... that is 20% wide... but it will likely be 100% tall (because of the way viewports are defined).  SO... let's say you wanted mon1 at the top of that area.  With viewport camera and RTT positioning, you could put it there, at the top of the new viewport. 

And then if you want HTML stuff UNDER that (including things like datGUI panel)... then that html would be absolutely positioned ATOP part of the new viewport (perhaps below mon1).  The HTML part of the right side menu (if there IS HTML on that menu) would sit atop part of the canvas of the new viewport.

I don't think you can add a viewport like this...

********************************
*                             *            *
*                             *            *
*                             ***********
*                                          *
*                                          *
*                                          *
********************************
So, instead... and because of the way viewports are defined/placed, you might do this...

********************************
*                             *            *
*                             *            *
*                             *            *
*                             *            *
*                             *            *
*                             *            *
********************************

and then absolutely-positioned HTML area covers bottom of new viewport, for example...

********************************
*                             *            *
*                             *  mon1 *
*                             ***********
*                             *            *
*                             * HTML *
*                             *            *
********************************

HTML area covers bottom canvas area of added viewport.  *shrug*  Might work okay. 

IF menu is NOT HTML, but instead Canvas2D primitives, then no problems at all.  Lower section of new viewport can be filled with Canvas2D buttons, labels, dials, knobs, everything, and no absolute positioning of HTML needed at all.  There would be no HTML.    In fact, even mon1 might not be a plane anymore.  It might be a Canvas2d primitive such as Shape2D or Sprite2d.  You might be the first person EVER... to use an RTT (renderTargetTexture) on a Canvas2D primitive.  WOW! 

 ----------------------------

Now, about the specularColor on mon1.  It is likely NOT mon1.material.specularColor causing the unwanted specular shine.  It is likely the mesh.material.specularColor of the scene item that the camera is SHOWING a picture-of.  Check out http://www.babylonjs-playground.com/#1WROZH#15

Mon1 is SHOWING a huge amount of secular shine coming from the grass plane.  But it is NOT caused by mon1 plane .material, or by camera1 (well, camera1 viewing angle IS a factor).  But mostly, it is caused by materialPlane.specularColor and light.specular (both are not user-set, so are currently set to default values).  With me?  Probably not caused by mon1.material.  It is likely caused by the material on the mesh that is doing the specular shine. 

Weird, huh?  *nod*  Easy to get confused.

Now you have a ton of new things to think about, and so do I.  Perhaps others will comment.  Be well.

Oh, you want to see a multiple viewports demo?  Okay.  http://www.babylonjs-playground.com/#13TVWJ#2 

Believe it or not, there are FIVE viewports, there.  Even the thin blue lines are in thin viewports.  Lines 26-49 carefully divide-up the canvas into sections... all measured from lower left corner (0,0) to upper right corner (1,1).  Notice that the upper viewports each use 50% of screen width, no matter how wide the screen.  Percentages.  Viewports are kind of strange, but very useful in some situations.    

[juanmajr93]

Hi, @Wingnut at first of all thanks by your interesting answer. The problems relative to specularColor of material and specular light are resolved. The other problem relative to the plane "mon1" that I am using, I consider using a Canvas2d primitive is not the solution because in this case I could only apply a texture so I couldnt see the movement of camera arround the sphere. There isn't any problem to set HTML menu under plane or viewport where sphere appears. If I decide to use viewport maybe I could manage that I want. In this case I only need 2 viewport distributed by the follow way:

********************************
*                             *                  *
*                             *  Viewport2 *
*        Viewport1     *****************
*                             *                  *
*                             *     HTML    *
*                             *                  *
********************************

Do you agree with this example? Moreover, the camera of Viewport2 must be attached to canvas because I don't want to interact there. I am waitting to your answer very interested!

 

[Wingnut]

Hi J! 

Yes, that is perfect.  But viewport2 will go behind html... because... you know... we can't make a viewport in one corner only. 

Or, HTML section could be covering a viewport 3.  It doesn't really matter.  Having it cover the bottom part of viewport 2... would be less work. 

I think you understand this.  (it's because of how viewports are positioned)

Another problem might be... keeping absolute-positioned HTML... "docked" to the right screen-edge.  Resizing screen can cause problems for absolute positioned HTML.  It is important to set sidebar.style.width, .height, .top and .left... with percentages, and not "pt" or "px" values.  Margin settings are ignored for absolute-positioned HTML, I think.

Thanks for info about RTT on Canvas2D prim.  You tried it / thought-about it, huh?  Cool! 

Likely, it would need to use a special Sprite2D or Shape2D with constant update from RTT.  Probably not yet invented. 

 

Wouldn't it be great... if we could "feed" an html <img> element... with a renderTargetTexture?  Then, the whole right sidebar would be HTML stuff.  No viewports or canvas on the right.

Perhaps mon1 could be a HTML <canvas> element  (with context-2d, not context-3d).  hmm.  That would also allow us to have an ALL-HTML right sidebar.  Perhaps, doing that is a security issue.  Not sure.  I think I might have tried that before, and failed.  But I fail often... and sometimes unnecessarily. 

 

Ok fellow forum helpers...  here is "The Juan & Wingnut Challenge of the Weekend"!  Use a camera view or renderTargetTexture... to fill an EXTRA context2d HTML canvas.

Essentially... we need another HTML canvas (or <img> element)... below the renderCanvas area (for our tests).  That <canvas> or <img> must be constantly updated from a renderTargetTexture.  CAN IT BE DONE?    I dunno. 

Here's a starter playground with 4 HTML <canvas> "monitors" under the renderCanvas.  http://www.babylonjs-playground.com/#1WROZH#17

First person to get a RenderTargetTexture... continuously displayed on one of those context2d canvas (canvai?)... gets...  A BRAND NEW ROLLS ROYCE!  everyone's love and appreciation.  Alright!    Thanks for all attempts, comments, successes, miracles, etc.  I think what we are trying... is a browser security violation.  So even if someone DOES do it successfully, we would probably need to report it to the W3C, and then they will change the browsers... and make it quit working.