Jump to content

viewports with update position


Dad72
 Share

Recommended Posts

Hello,

I would like to add a BABYLON.Viewport on a div element. and that <div> must draggable. But that's not possible. then I make my container <div> transparent to see the BABYLON.Viewport behind the <div>, and I would like to update the position of BABYLON.Viewport when I move the window that is draggable <div>, but again, I think this is not possible.

Would there be the possibility that a function is available to update the x and y position of a BABYLON.Viewport.

ex: (what is 'bold' is never updated if the values change dynamically.)

new BABYLON.Viewport(this.positionx, this.positiony, 0.21, 0.38);

Thank you for your helps

 

Link to comment
Share on other sites

Hi D!  Interesting idea.  In a way, you are talking about using a different <canvas> element for each viewport, and then you could drag the <canvas> elements.  That would be cool.

There might be another way... and that's the renderTargetTexture thing.  Let's pretend you want 4 viewports.  You could... umm..."loose-attach" 4 planes to the "main camera", and then use 4 "aux cameras" to put camera views onto those 4 planes.  Now you can drag those 4 planes around, and size them, and spin them, click them (to focus on them).  When you focus on one (click on it), you can drive ITS camera just like any BJS cam.  The main camera would probably target a blank space or black plane, and never be attached to the canvas.

Notice I said "loose-attach" because you would want these renderTarget planes to sort-of  be parented to the main cam.  They could still be dragged on canvas x and y, but with limits to keep them from being dragged out of main camera view.

Just thinkin', D.  Probably nothing useful.  :)  Be well.

Link to comment
Share on other sites

Hi W! :)

Yes, there are the ideas, but I do not use more canvas to avoid having to create multiple engine. and it does not work properly. I use div to create my window and makes it transparent container to see the BABYLON.Viewport behind. But that requires me to prevent this window is draggable div.

What would be great: To be able to attach this BABYLON.Viewport on an html element (div) or to be able to update the position of BABYLON.Viewport. one or the other might do the trick.

 

 

Link to comment
Share on other sites

Yes.  I was thinking about changing the engine, so that one engine could feed many canvas.

engine - feeds main canvas

renderTargetTexture#1 - feeds aux canvas #1 (wrap in div, can do)

renderTargetTexture#2 - feeds aux canvas #2 (wrap in div, can do)

etc.  *shrug*

Also, maybe if/when an aux canvas is not focused (has no mouse/controller events attached), it could become a dynamically-updated IMAGE element.  Drag image elements == same as div.  It would be an image element that is constantly updated by a renderTargetTexture.  *shrug*   Drag'n'Drop-able renderTargetTexture "monitor" windows.  Buttons... with live views from the scene.  :)  Coooooool!

But you want drag-ables, not buttons... so... Wingy get's back on-subject...

Drag camera #2 image element and drop onto big canvas window, and then the scene (big window) switches to camera #2.  Still always one viewport, but 3 renderTargetTextures feeding 3 image elements.  (or 3 DIV background images, if you wish).

On your 3 small windows/views, do you want to allow users to move those cameras IN (upon/over) those views?  Or, will you only allow camera moving in the big viewport?

Aside:  Dad72, would you please re-word the last sentence in your Wingnut Chronicles post.  I'm not sure I understand it.  :)  Thanks!  (feel free to remove the quote, too)

Link to comment
Share on other sites

I edited the post Wingnut Chronicles.

For your idea, I think I'll find myself in the same situation. A dynamic texture on a plane, yes, but then the plan, I have the attach or updated the position of div just as with BABYLON.Viewport.

The camera can be moved on the scene by the user (left of image), but not by picture cameras windows that are only to indicate that a camera path to the user.

So I use a method or another I think I'm having the same problem. but using BABYLON.Viewport makes things easier as dynamic texture (It is fewer lines of code). rest just has to update the x and y position of a BABYLON.Viewport and that's ok. but this is not possible yet.

However, I also like the idea of a dynamic image, but the texture is applicable only in the 3D world and not on an html element. 

 

 

Link to comment
Share on other sites

Yes, you are probably correct.  hmm.  Darn.

Still, let's try something...

http://www.babylonjs-playground.com/#20FHBL#3

First person to get the renderTargetTexture (currently a ground texture)... to render (constantly) into the image element below the canvas...  WINS A COOKIE!!!  :)

Change to a canvas element... A-OK.  Change to a div and use it's backgroundImage...  a-ok!  Almost anything is allowed!  (but it should try to address the issue)  :)

Addenda:  http://www.babylonjs-playground.com/#20FHBL#5   Look at THAT!  That is the longest playground error that I have ever received.  I'm SO proud!  Lines 32-40... we got trouble... right here in River City.  :(

Even more:  http://www.babylonjs-playground.com/#1WROZH#5  (It's just getting worse by the demo)  heh!   Sub-window 1 (camera 1) has a renderTarget of the renderTargets.  Wow!   But apparently he can't face himself.  He can't look himself in the mirror.

Link to comment
Share on other sites

Hey, cool, and interesting.  Thanks.

Dad72 could use your thoughts, though, if you have any... about his issue.  I sort-of contaminated his questions/thread with my foolishness.

DK, or anyone, can you imagine a way to have 5 canvas on one webpage.... 

 - One canvas is the main render canvas

 - Four (or more) canvas are renderTargetTextures

- One engine only

I'm not sure what the dragging is for, but I suppose he will want to HTML-drag any renderTarget aux canvas... onto the main canvas, and then THAT camera goes active in the main canvas.

He also might want to drag a renderTarget aux canvas... to arrange its position on the aux canvas side-panel.  In short, he might want to drag to change the order of the "buttons".  But maybe that is not important.  Maybe he only wants to drag/drop a renderTarget button... onto the main canvas.  (no button re-arrange needed)

He seems to hold hope for Babylon.Viewports.  I don't see how they could ever be draggable.  I think there is a better chance of getting renderTargetTextures to render in their own private canvases.  Maybe that is also not possible... or plausible.

@dad72 ... I hope I restated your issue correctly.  Sorry if I didn't.  There is one other thing that you could consider.  Instead of dragging a canvas or viewport, you COULD drag a "cursor" or "widget".  Lets pretend user clicks and holds... upon one of your side buttons.  Instantly, you create a standard HTML DIV with a border... that is the exact same size as the viewport to be dragged.  Then drag that DIV onto the main canvas, and drop it.  You don't drag the viewport, but you drag a "proxy frame" FOR that viewport, and drop THAT on the main canvas.  During the drag, this proxy drag-widget could flash its dotted border, and even have the camera number written inside the div in big fonts.

The user doesn't drag a viewport...  they drag a representative of it.  *shrug*  That's what Venkman's Rob Ginda  (old-days Mozilla JS debugger) did for his MDI-like GUI packed with "views".  You never dragged the view.  You dragged a widget that represented the dragged view.

To go a bit further, Rob needed MDI-form persistence.  He needed the GUI layout of the views... to be remembered from session to session.  Look at this if you please...

http://mozdev.org/pipermail/jslib/2005-September/000636.html

Somebody's Mozilla prefs.  I'll cut to the chase...

user_pref("extensions.venkman.layoutState.default", "x-vloc:/mainwindow/initial-container?target=container&id=outer&type=horizontal; x-vloc:/mainwindow/outer?target=container&id=gutter&width=231&before=vright&type=vertical; x-vloc:/mainwindow/gutter?target=container&id=top-tab&height=370&before=locals&type=tab; x-vloc:/mainwindow/top-tab?target=view&id=scripts&height=177&before=windows; x-vloc:/mainwindow/top-tab?target=view&id=windows; x-vloc:/mainwindow/gutter?target=view&id=locals&height=308&before=bot-tab; x-vloc:/mainwindow/gutter?target=container&id=bot-tab&height=233&type=tab; x-vloc:/mainwindow/bot-tab?target=view&id=breaks&height=100&before=stack; x-vloc:/mainwindow/bot-tab?target=view&id=stack&height=75; x-vloc:/mainwindow/outer?target=container&id=vright&width=560&type=vertical; x-vloc:/mainwindow/vright?target=view&id=source2&before=session; x-vloc:/mainwindow/vright?target=view&id=session&width=677");

Virtual locations.  This is what was stored and parsed whenever Venkman launched or when prefs got saved... to remember the Venkman GUI layout.  Rob allowed views to be tabs, too, as you can tell.  Every view had a tab-bar at its bottom, which collapsed when no tabs were in it.  So every view-area was reusable by any views who had tabs on the bottom of that view-area.  The GUI could be arranged with one big view... with 25 tabs at its bottom, if you chose that way.  Or, 4 views with 6 tabs on the bottom of each, etc.  Each view could be drag-sized, docked or floated, and could go full-screen (maximized).  After finished with maximized, the view's "restore" button would return the view to its former state, be it floated, docked, or tab.  Amazing stuff.

Notice the mention of gutters?  Those are "bars" along the sides of views... that you would drop another view-onto.  In YOUR project, if you wanted to drag camera 2 button... so that it was on the LEFT side of cam 1 button, you would drag cam 2 drag-widget... onto a thin gutter that runs vertical along the left side of cam 1 button.  The "gutter" would turn black, and the drag-pointer would change from an "X" to a hand... indicating that the gutter was a "legal" drop zone. 

The same would happen for tab-bars.  If you wanted to drag a view to a tab bar, you would drag its drag-widget onto a gutter above any tab-bar.  The cursor would turn to a hand, the gutter would go highlighted (or black, in my case), and you could drop there, and the view would disappear, but become another tab.

Way too much talking from Wingnut, eh?  If you want use dragging to re-arrange the order of your side buttons, you might want to consider the use of gutters... and maybe think about NOT dragging the view... but dragging a widget FOR the view... instead.  Ok, party on!

 

Link to comment
Share on other sites

I create a video to make it clear my problem and what I want to achieve.

http://www.babylon.actifgames.com/dragViewport.avi

You can see that the BABYLON.Viewport' not moving with my <div>. and I would like to update the X and Y position of BABYLON.Viewport with div so that it always has inside.

var move = function() {			
		var ctl = document.getElementById("block-window");// my div		
		var percentW = ctl.offsetLeft / $(window).width(); // convert in %
		var percentH = ctl.offsetTop / $(window).height(); // convert in %		
		this.positionx = parseFloat(percentW); // update position X
		this.positiony = parseFloat(percentH); // update position Y
};

// updated viewport
global.camera[1].viewport = new BABYLON.Viewport(this.positionx, this.positiony, 0.21, 0.38);

My request is could there be the ability to dynamically update the X and Y position of BABYLON.Viewport
Is that a work viewport.updatePositionViewport (x, y) could not be created.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...