cam path

[jerome]

Hi,

 

Working on the tube mesh and tearing my hair out with all those continuous tangent, normal and binormal calculations, I just had the idea of a camera path.

 

The camera path could be an object implementing a curve (the path to be followed by the cam) and a method returning on each curve point the tangents, normals and binormals not normalized.

Why ?

Because these three values could be a way to orientate the cam when following the path : does it look ahead in the movement direction or does it look at a fixed point in the world or at another moving mesh (waahhoo, it's a plane dogfight sensation here) or does its orientation change according to speed/acceleration, etc ?

 

I just talked about the orientation, but it could be the camera speed or acceleration instead... or both.

Everything is possible. 

 

Speed and acceleration could just be evaluated along the curve in function of current speed/acceleration and current triplet (tangent, normal, binormal)  by a user custom function.

 

I don't know if I am clear enough...

 

Do you think it would a need for this ?

 

 

 

 

[Wingnut]

Hell yeah, we could use flight paths!  We currently have keyframe animation with bezier and easing, but I haven't done much experimenting with it.  It's new.    Hi again, Jerome.  Are you about sick of seeing my wireframe face?  I bet.

Here, use this barebones cropduster if you wish:  http://playground.babylonjs.com/#RVDXB#1  Rip-out all the extra crap and it might become useful for you.

Speaking-of line 423:  var elapsed = engine.getDeltaTime()/1000

Ok, let's not speak-of that, but it might become important to you, when pondering flight paths.  Here's some other things that might be important.  Free cameras DO have a rotation property, but you cannot get a free camera to rotate on the z axis.  Don't ask me why.  The camera police decided it was just too dangerous for youngsters, I suspect.  Not very "free", are they? 

Here's a messy testing playground, and you can see line 9 proudly standing strong, doing nothing. 

http://playground.babylonjs.com/#LV50F

Activate line 21, and boom, free camera z-rotation happens.  The camera's parent became box, which is z-rotated.

Also notice that free camera has a setTarget() function [needs constant updating if animating] and a .lockedTarget property [locked-on].  Both of these things might be important to you, later.  But maybe not.

And, notice that spotlights and other lights that use a .direction... have a light.setDirectionToTarget() function [needs constant updating if animated]. 

And... mesh has a .lookAt() function [needs constant updating if animated]. 

Some of these functions are remmed-out in that messy playground, but can be turned-on to experiment with things.  Hack it up as needed.  The spotlight has box2 as its parent (yawn).  I turned on animation on box2, while constantly doing a box2.lookAt(box.position) and it got sick and barfed.    But that is irrelevant at this time.

Speaking of parenting...    um, I suggest thinking about pathing a mesh box along a deltaTimeline.  You can determine a 'forward' vector, and pretend its a robot, and attach (child) a camera and light, as wanted.  By pathing a box instead of lights or cameras, you get a more universal path follower that ANYTHING can be parented-to.  Thus, you get banking (z-axis rotation) on the free camera!!!  YAY!  The camera's parent (the box) is actually flying the path, so the camera will bank with the box.  Fly the box, and then parent anything to it later.  Right?  Maybe?

You can pretend the spotlight is a camera, for now.  Put some assorted mesh on a ground plane, and fly the box on curves around the assorted mesh... having the box turn and shine its spotlight on various mesh as it passes-by them (police helicopter with un-steerable spotlight on its nose).   Just some thoughts. 

[jerome]

Thank you Wingy for all these tips and explanations.

I admit it's just an idea for now and I didn't really look at BJS cams. I just focused on paths, tangents, normals, binormals and other *$%@!§#s till now

 

I guess my need is just a cam object, its  absolute position in the world and a direction (axis / vector) to look at from this position, both paramaters updatable each frame.

Does one of the current BJS cams propose this frugal need ?

[Wingnut]

So, I failed at convincing you to use a box instead of a camera, after all that yapping?  hmm. 

 

Ok, let's try one more time.

 

If you use a box as the path follower...

 

1. You get to attach a camera to it, with full banking power.

2. You get to attach a light to it (also), with full banking power, but light-banking is useless.

3. You get to attach a helicopter to it, with full banking power.

4. The box can be set to invisible.

 

So set your camera 1 as a wide angle normal camera which can easily see your path visualizer helper lines.  Set camera 2 as a child to the path follower box.  Now fly the box down the path as if it were a camera.  If you want to view from the path follower, just make camera 2 active.  Or, even use a multiview to view both cameras at once (optional).

 

But if you're absolutely dead-set on using a camera instead of a much more reusable box (ahem), then take a look at babylondoc.azurewebsites.net/Classes/2.0/BABYLON/Node/Camera/TargetCamera

 

TargetCamera has Camera as its super, but Camera is quite basic.  Like Wingnut, Camera has no direction.

 

FreeCamera is a subclass of TargetCamera, and it picks up a few more features at that layer.

 

How about a nice (invisible) box with a spotlight and (any) camera mounted to the front of it?  That would work fine, eh?  What a good parent to ANYTHING... that would make, huh?  (ahem)  hehe

[jerome]

Arrrff

 

I like your efforts to convince me :)

At this time, I have no idea about the way of doing this therefore   It's just an idea, a project, a whim (I'm struggling at setting ribbon uvs at this very moment and it is quite more complex than I expected : how to project a a priori  unknown shape - ribbon paths are input parameters - onto a texture the best way ? )

 

But I hear you and like your approach too. It has got many advantages.

Honestly, I don't know yet how I will do this, even if I will only do this !

 

Never solve a problem before it raises !

 

If I start implementing it, I only know I will probably do it the KISS way, as usual

[Wingnut]

Yep, I agree.  KISS.  Why screw around with the features and limits of various cameras, when you can use a box that follows paths and turns and looks-at things just like a camera would need to do.

 

I'm thinkin' maybe you're a bit addicted to numbers (which you call KISS?  OMG!)... and maybe you are somehow reluctant to assemble a video camera model with attached light... using basic BABYLON shapes.  Then parent all the parts to a central object called pathtracker.  Wow, what an important-sounding name!  Then add a genuine BABYLON free camera and a genuine BABYLON spotlight... to it. 

 

How about a box with a picture of an eyeball on one side?  We'll jam a freecam and a spotlight right into the iris!

 

Maybe you are scared to leave the comfort of MathLab and get your hands dirty with a little old-style modeling, using primitives.  Maybe you're not the man I hoped you'd grow up to be.  hehe.

 

Yuh yuh yuh, how to make it easy for users to build complex paths with inertia and banking and camera-tracking on fly-bys.  Difficult, without a tasty visual editor.  *shrug*  Lots of easing tweaking.

 

Aside:  AltReality is working on the railroad, all the live-long day.  I bet HE has a use for 'pathtracker'. 

[jerome]

I never used MathLab, don't even know how it works

 

And I don't want to re-invent the wheel too... if primitives or basic shapes help, I'll use them of course.

I keep you idea of a box traveling along the curve and then attach any kind of camera.

I will have to find a way to give the box (or the lone or many cams inside) the tangent, normal, binormal on each point of the path, because they could be used to set the box/cam speed, acceleration and orientation.

So far, I didn't think about the cam aspect but only the path traveling aspect, you know.

Every opinion is welcome

[Wingnut]

  I'm just giving you "the business", you know.  (joking around)

 

I think I understand what you are thinking about.  A series of points along a path... contain un-needed values that you could re-purpose as directives for any follower (player) of that path.  In this case, I mean 'player' as in "tape player" because the path would act like that... a strip of sequential information.  *nod*.  Interesting.

 

By the way... THANK YOU for the visualizer helpers in your playgrounds.  Way nice.  They sure help me understand/learn-about your excellent ribbon-wrangling and tubeworks.

[gryff]

Hi jerome and Wingy - interesting ideas. Now I can't contribute much (nothing more likely) from the coding end but though you might like to see this:

 

Racing Camera

 

Done in Blender - animation along a path. Essentially, create a curved path, animate a box along the path with camera and light parented to the box. The box is always orientated so that it faces along the path.

 

Will follow this thread see where you go

 

cheers, gryff

[ancientholiday]

Hi jerome and Wingy - interesting ideas. Now I can't contribute much (nothing more likely) from the coding end but though you might like to see this:

 

Racing Camera

 

Done in Blender - animation along a path. Essentially, create a curved path, animate a box along the path with camera and light parented to the box. The box is always orientated so that it faces along the path.

 

Will follow this thread see where you go

 

cheers, gryff

 

Can the camera be animated in blender and then exported to babylon.js? Without being parented to a box?  I want to animate the camera itself

[GameMonetize]

Yes you can:)

[ancientholiday]

Yes you can:)

I made a very simple Babylon project based on the tutorials.

 

I cant seem to get anything to work on it.  Can someone take a look, I must be doing something wrong that is very simple:

http://www.mosesbydesign.com/def2.html

[ancientholiday]

Nevermind,  the code is working now.  I found another tutorial.  :-)

[dbawel]

In Mathlab and most graphic software, we are able to constrain a single axis to follow the path.  This will be necessary for any camera path, as the Z axis needs to orient itself along the path.  Otherwise, it's pure mayhem.  And if you add a Y axis constraint (up vector) to the tool, we're all happy.