A more efficient way for the camera I need to move around a scene

[JohnK]

What I wanted to do

 

A camera that can move forwards, backwards, up and down and rotate to the left and to the right and up and down. The front of the camera will be a distance of B from the front of the camera

The camera should be blocked from moving

• forward when its front is in contact with an object;
• backwards when its back is in contact with an object;
• up or in an up rotation when its front top is in contact with an object;
• down or in a down rotation when its front bottom is in contact with an object;
• in a left rotation when its front left is in contact with an object;
• in a right rotation when its front right is in contact with an object.

How I achieved this

B is set to 60 in the z direction

 

I constructed a  viewer which consists of a holder ( a box mesh) which is a parent to six planes (plane meshes) one plane for each of the front, back, top, bottom, left and right of the holder.. The planes are called viewer.front etc.

 

The holder dimensions are 6 in the x and y axes and 60 in the z axis and its centre is at the origin.

 

I created a camera the position of which is always set to the position of the viewer.back.The camera looks in the z direction when created. The long axis through the holder is the line of sight. A target for the camera is set in the distance, for example at position (0, 0, 780). The target is given the holder as parent. This as the holder is moved and rotated the target is always along the line of sight and the same distance away.

 

The numeric keypad is used to move the camera.

 

5 move forward, 0 move backward, 4 rotate towards left, 6 rotate towards right, 8 move up, 2 move down, 7 or 9 rotate up, 1 or 3 rotate down.

 

Collisions are checked using intersectMesh between each of the planes and all of the objects in the scene and knowing which planes are blocked prevents movement in those direction only.

 

A working example.

 

http://www.babylonjs-playground.com/#AGEQ3   shows the code and how it was achieved.

 

(Slight problem you need to move the mouse on the playground before the scene is rendered, once rendered it works -- don't no why???? probably something stupid I have done!!!!).

 

Question

 

Given the range of Babylon cameras there must be a more efficient way to do this. Any advice gratefully received.

 

 

 

 

 

 

[Wingnut]

Hi!  This is cool, John, and I understand where you are going. 

 

I think more people will join the conversation, if you can add another camera... wide angle.  Maybe give us a standard arcRotate "chase cam" to watch this 6-panel collider box... move (pos and tilt/pan).  Make the panels partially transparent.  Put a fake BB around the cam.  Maybe set color changes when collisions are happening.

 

Ideally, I would like to see the viewer box... from another camera angle.  A picture is worth a thousand words.

 

I'm just basing these ideas on MY initial thoughts... which were "My my, this is difficult to visualize.  Thank goodness John explained it thoroughly." 

 

I guess I could just add it myself, and do these tweaks... but I'm feeling pretty lazy.  (normal)

[JohnK]

@Wingnut thank you for reviving this question. Here is a new PG http://www.babylonjs-playground.com/#AGEQ3#2

 

There are now two viewports the top uses an arcrotate camera. Please note as well as needing to move the mouse in the playground NUM LOCK has to be on when using the number keypad.

 

In addition you can now play with the length, height, and width of the viewer. The planes are now visible and you can see more clearly when they collide with a box.

 

Sorry Wingnut et al, as usual I "rushed to press" before thorough testing. The concept was working in my project but I needed to make changes to put it in the playground. A major change was switching from evt.keyCode to evt.sourceEvent.key and forgetting to state the Num Lock had to be on for the movements to be used.  Also I hadn't noticed that the variable viewangle had not been set.

 

My thoughts on further reading are that perhaps using and setting checkCollision with onCollide might be more appropriate but my limited attempts have not got these registering contact between meshes, perhaps because there is no animation involved. 

 

Anyway perhaps I should just be happy that I have it working as I want.

[Wingnut]

Thank YOU, John...  I appreciate the new playground.  I tweaked it a bit to my liking... http://www.babylonjs-playground.com/#AGEQ3#4

 

The tilting funcs... lines 184 - 206  ...I temporarily turned-off the viewangle conditional... and I assume line 196 was supposed to be for keys 7 and 9, as 8 was already used in line 175.  I also put a "camera bumper" in a renderloop func... so the bottom viewport works at RUN time.  But, the mousewheel seems to work backwards on that top viewport, and the scene disappears when I mousewheel-in too close.  I'm not sure what's happening there.

 

Collide cam movements summary (world space):

 

Press:  1/7 or 3/8 for TILT up/down. (rotate)

Press:  4/6 for PAN left/right.  (rotate)

Press:  8/2 for PED up/down (position)  (pedestal)

Press:  5/0 for DOLLY in/out (position forward/backward)

Press:  ?/? for TRUCK left/right  (position) (missing?)

 

See me using them cool TV industry terms?  Ain't I just something?  (yikes)  I'm TV production trained... a total waste of time considering how exclusive and uppity THAT industry is.  Sad.  We move on. 

 

Other than those observations, I did a little camera work on your demo... disabled lines 6 and 10 and set the cam values in the line-5 constructor, instead.  Too many .position and .setPosition() on cameras... makes me nervous. 

 

Feel like making another, John?  Feel like getting truck/pos left-right turned-on?  Or am I missing something there?  In a moment, we'll talk about worldspace translations vs localspace translations.  (uh oh) 

 

Ever thought about making your viewports side-by-side and then calling toggleEditor() in your code somewhere?  Its the first function of our "let's bastardize PG code so it won't run offline" project.    I'm hoping for toggleHtmlToolbar() someday, too... so we can have a rack of buttons to push/hold instead of needing to use keypresses.    Keypresses are cool, but ALSO having buttons that do the same things... is cool, too.    As it currently stands, it takes about 200 lines of JS to get a dynamic html toolbar installed across the top of the PG canvas or whole PG window.  So much for easy testing buttons, eh?

 

But, you know the issues.  Try to run some pg code offline... that has a toggleEditor() or a toggleHtmlToolbar() in it, and it will chow gravel (face plant) (fail)    That's the problem with talking to your coding environment... FROM within one's code.  The code can easily travel to coding environments that don't understand those commands.  So, often, you need to test what environment you're in.  The way I test... canvasZone - an html div that resides in the playground.

if (document.getElementById("canvasZone") {    thisIsPlayground = true;}

My World's Worst Flight Sim uses an HTML toolbar... see line 281?  CanvasZone is where I append my toolbar.  I put a canvasZone element in my OFFLINE version of the flight sim, too.  That way, it doesn't matter if I am in the PG or offline. 

 

BUT, if you were to Get .Zip of that PG, the <div id="canvasZone"> element would not be there, and the button bar would not work... until that div was added to the html scene launcher (index.html). 

 

That button bar looks better when the editor is toggled closed, and it disappears with the 'fullscreen' button.

 

I'm certainly no pro at dynamically building html toolbars.  I've only done it a couple times in the playground.  My 10-cam demo is another one.  (yawn)  The PG version of the 10-cam demo is currently broken, possibly due to changes in the framework since 1.14... so I won't show you that one.  What's that?  I just did?  Crap.  Don't push any buttons on that, it might explode.    I have activeCameras troubles in there, I hear, from the experts.  I should fix it someday.

 

With me, John?  Let's hope not.  hehe.  I'm not suggesting that you put an HTML button/tool bar in your PG, John, but I wanted to show that you could.  Sidebars, too, but they get in the way of editor toggling a bit.

 

You actually have 16 needed actions (oh my god, huh?):

 

Pans:  pan left, pan right, tilt up, tilt down  (4)

Trucks/dollies:  truck left, truck right, dolly in, dolly out, ped up, ped down  (all done along grid lines)  (world space)  (6)

Per camera orientation trucks/dollies:  truck left, truck right, dolly in, dolly out, ped up, ped down (all done orthogonally to current camera orientation)  (local space)  (6)

 

With me?  There is a dolly in/out that goes straight down the z-axis, following grid lines (no x or y change during these dollies).  There is also a dolly in/out that travels directly down the camera's line of sight, correct?  (like zoom).  Depending upon the aiming of the camera...  ALL axes could/will change during this local space dolly type.

 

All the trucks and dollies in the third line (the last 6 actions)... are done PER the current orientation of the camera.  Let's say a camera is tilted up at 45 degrees, and panned right 45 degrees.  There are two truck-lefts, correct?   One... truck the camera left in world space.  The other... truck the camera left in local space (orthogonal to viewer.left).  The latter type... would move the camera in world space... -x, 0, +z, (leftward, and away) because of the camera's orientation.  In the camera's local space... we are trucking left in local space.  Just -x movement.

 

Still with me?  16 actions.  16 keypresses or buttons... JUST to get your proper testing lab completed.  After that... we can take over the world!

 

I'm with you on this, all the way.  I think a TON of stuff can be learned from these tests.  I wouldn't worry too much about efficiency, yet.  Let's gather all the info that we can... from your cool demo, first.  Maybe a followCam for the wide angle view.... so we can auto-hover over the viewer and watch it closely as it does collisions. 

 

Have you played with the famous .moveWithCollisions() func yet?  That's a greasy puppy.  I once proposed companions for it... rotateWithCollisions() and scaleWithCollisions()... but few heralded the idea, and collisions are a challenging system.  Still, those funcs are on my todo list (like I EVER look at THAT).    The tests/experiments that YOU are doing here... will help that cause, I think.

 

Just some thoughts.  Hope you're well... and thanks again for doing these tests.  Interesting!!!  I hope I didn't tell you anything that is wrong.  I do that sometimes.  I certainly had plenty of opportunity, here.  Check my yammering carefully.

[JohnK]

Hopefully with a few days (weeks months?) I will be able to have a working project added to the projects page and then perhaps it might be clearer on what I am attempting - there is a scene making screen where models (groups of meshes) can be added and positioned and a viewing screen which is a walkthrough (glide through?) the completed scene. I wanted the walkthrough to be a first person type view with only walking (flying - perhaps the walkthrougher??? is an angel) forward and looking around allowed, no side stepping and so no I had no truck with TRUCKING. I had to add a backward step to stop being entirely blocked on occasions. Maybe an over the shoulder type walkround might be clearer with a rearview character replacing the whit front square?

 

Thanks for the tweeks I'll incorporate them.

 

As for moveWithCollisions() yes I have read about them but got scared off, was hoping one of the experts might say hey you are going about this all wrong and using  collisions and associated functions you can do all this in half a dozen lines like this. 

 

Your talk of on screen button bar has got me thinking - TILT if cursor moves up/down, PAN if cursor moves left/right, right cursor key to DOLLY in, left for out, up/down cursor keys for PED up/down. However it is the export import scenes next on my list once this is done I can submit the project for further guidance.

[Wingnut]

Ahh, ok.  I thought your objective was to put collisions through their paces... testing every camera collision scenario.  But you have a specific task in mind.  *nod*  (I'm catching up). 

 

 

                    /

                   /

                  /

           []-> /

                /

               /

              /

             /

            /

           /

          /

 

Ever thought about skid-along-the-wall stuff?  If the camera kept continuously pushing in the arrow direction, would it stop when it hit the wall... or slide left (upward) along the wall until it cleared?  Same question for the camera trucking right (downward).  Would it hit the wall and stop, or keep sliding down (and backwards) until it cleared the wall?  I imagine diagonal wall-sliding is something we have to write ourselves, with some kind of advanced .moveWithCollisions or something.  I haven't studied these things... but I would imagine they are important in games.  In Serious Sam, for example, I find that the more you drink before playing the game, the more useful dungeon passageway wall-sliding is.