Hi HD, welcome to the BabylonJS forum. This is a tough issue. One thing you have not told us about… is the positions of the models. Can I assume you want complete freedom to move the models (the target points) anytime and anywhere?
Some models may be smaller and/or nearer to scene origin. This means… when camera is “focused-upon” a small mesh near scene origin, and if it is a close-up shot, user won’t be able to SEE all the other mesh, and therefore cannot click on them.
Related… if you want camera animations to NOT “pass thru” not-focused models on the way to its new target, the first step in the animation process is to dolly-out to a wider shot, then start animated left-right trucking the camera (and animating its invisible mesh .target). You want to avoid making the camera go THROUGH another mesh… on the way to its new target. This is rough.
Fixed splines for both cam-path and invisi-mesh cam.target… will prevent easy-moving the models in BJS… because after moving a model/mesh, the spines needs re-calculation. If your mesh never change positions from their Blender-set position, then i’ts possible. But stlll, you might want a NEXT and PREV buttons, and not allow users to select ANY mesh/model. Then you never need to animate “across the group” (where cam could accidentally fly THRU another model… while traveling to new target).
SO… positions of models/mesh… frozen? Are some closer to scene origin than others, and/or smaller/larger than others? (arc cam radius different for each “featured” model?)
WHAT IF… you didn’t fly/animate the camera/target to the clicked mesh. What if you fade to black, fast-move camera and target, and then fade-up from black? After each re-position, standard arc cam operations, except camera.target is set to new mesh, and radius is forced to be perfect for framing the new mesh, too.
You’ll probably want the user to have full model-examination/exploring at each “model station”. This means… at the beginning of an “animate to new mesh”… you won’t know the camera alpha/beta orbit position, nor its current .radius. (user has been moving/zooming cam to examne mesh). Fixed pre-made splines won’t handle this well.
There are some ways to “fake” on-the-fly path-finding for the camera, but it might look odd. First step would be to animate the camera.radius WAY OUT (dolly out far)… then truck-animate the target to the new mesh (which COULD be done WHILE the far dolly-out is happening, so user might not notice.
Then, once new arcCam target is set, start cam-position anim-dollying-IN, WHILE animating the .alpha and .beta to some viewing angle. The models/mesh MIGHT carry with them… info about “where to put the camera to best view me”… so each mesh might have a .bestCamPosition/.bestRadius, .bestAlpha, and .bestBeta properties. These would be used be camera animations… after user clicks on new mesh and invisble mesh .target has been animated/quick-moved to newTarget.position.
In short, back-out cam to real wide shot WHILE moving camera.target to new .position. Then start down-animating cam.radius toward newTarget.bestRadius (dolly in), WHILE truck-animating the cam to newTarget.bestAlpha and newTarget.bestBeta. (radius, alpha, beta set cam position… no need to animate a cam.position IF one exists on arcCams, which i doubt.)
Is essence, this is similar to a crop-dusting plane. At the end of each pass… plane goes wide and high to make a turn and begin targeting a new target on the field. You would sort-of do the same, but camera would always keep looking-down towards “the group”. You would back-out the camera far from the old target, and then fly it to new target. During that “backing-out” or flying-in, the “group” will likely appear to be spinning. (depending upon WHEN… you start animating to newTarget .bestAlpha and .bestBeta). You could start animating those… during the far-distance dolly-out, or wait for the dolly-in animation and do the spins then.
SO much… depends upon getting camera.target… changed from oldTarget, to newTarget. IF you do that move/anim WHILE camera is near to group… it will be obvious to user. If you back-out the camera to a half mile, then do a cam.target = newTarget.position, user won’t notice… even if NOT animated (jump-cut setting, instead).
You will want to wait until AFTER the cam.target is set to newTarget.position… before you start animating cam .alpha, and .beta, or dolly-in animating .radius.
Backing the camera WAY OUT, making adjustments, then animating back-in (.radius animations)… is somewhat similar to fade-to-black/fade-up-from-black. The only problems eliminated by this back-out/fly-in system… is to prevent camera from ever flying THRU a model on-the-way to another, and not knowing where user has put the camera prior to selecting a different target. In this system, you will ALWAYS begin your animations at cam .radius, .alpha, and .beta (the big 3). This is because the user has FULL arc-cam powers no matter which mesh they are “featured-upon”. The cam’s .target will be set to the chosen target, and that’s the only thing you “force”. The rest… you don’t know until you ask the camera for its curren t.radius, .alpha, and .beta. (where-ever the user placed the camera at time of newTarget click).
The sequence would be…
- user clicks on newTarget
- Quickly truck-out cam to 1/4 mile with cam.beta of maybe .75 (altitude), perhaps.
- Maybe WHILE doing that fairly-swift anim, swiftly animate cam.target to clicked newTarget.position
- Then begin animating cam alpha, beta, and radius… to NEW positions/orientations. Because cam.target is already set to newTarget.position, camera will remain facing the new target during the in-bound flying.
Just some ideas. Again, it would be nice to know if SOME of your models/mesh are smaller/larger than others (special .radius depending upon which model is selected)… and IF/NOT the mesh will ever be re-positioned. Having each model/mesh carry with it… information about WHERE/HOW to position an arcCam for best viewing starting position (after its .target is set to ME)… would seem handy, in my opinion. Each mesh would be carrying “I’m best-viewed when cam is blah blah blah” info. After a mesh is clicked by user, you can get that info… and use it in your animate-to settings.
Stay tuned for more/wiser ideas, and please tell us about mesh re-positioning possibilities, and IF/NOT some mesh will be lots smaller/larger than others. Fade-to-black-and-back system… and the crop-dusting-like fly-way-out-and-back-in system… are both fairly fool-proof… with little chance of cam accidentally animating THROUGH other mesh to travel-to newTarget. Both systems will take approx 5 seconds to complete “the move”, I suspect.
There MAY BE advanced rayCasting and pathFinding ways… all of which are too advanced for ME to talk about. They would, essentially, establish no-fly-zones, and camera would likely use no fixed animations, and instead… use AI/fuzzy-logic to fly itself to new orientations/locations. Erf. A type of scene mesh analyzer might be employed… with a function that “maps” all the mesh in the scene and gets their boundingBox.extendsWorld values… to establish the no-fly-zones. Ouch.
Yuh, camera flying has always been a HUGE challenge for 3D scenes… multiple decades now, with little progress toward a magical solution. When mesh carry their own “best viewed-from” info… that removes SOME of the hassles. Sort of like a “best used-by” date on a jar of pickles, eh?
I’m pretty sure that “best viewed-from” data was used on the Grand Canyon object… to help park planners nicely position their “scenic overlook” locations.
Again, there is likely no camera.position to SET… on an arcRotate cam. Not sure. You’ll be animating .alpha, .beta, .radius and .target… to establish cam position/rotation. On free/universal cams… it’s all different again. I like arcCams best, because of their orbital mesh-examining power/ease. And their .target is the pivot-point of the orbit… which sort-of indicates to the user… that a certain mesh is being featured/focused-upon (selected). You might find that a NEXT TARGET and PREVIOUS TARGET buttons are all you really need… and no anims. The buttons just move camera.target to clickedMesh.position, and then its user’s job to mousewheel-out their radius and pan-around camera until new target is nicely viewable. They animate themselves to the new button-set cam.target. shrug
Semi-decent example: https://www.babylonjs-playground.com/#STX192#16 Ease-animating .target to clicked mesh (of 74)… user handles arc-cam normally after the .target animating.
Less than 30 mesh in scene? Might want to activate a GUI stackPanel of buttons with mesh names on them. Click a button… takes cam to preset place… instantly or flown. Not really on-topic, but it lets users select ANY mesh, whether it is currently in-view or not. shrug
Caution: Wingnut often confuses “truck” and “dolly”. I think dolly is left/right, truck is forward/backward, and ped is up/down. Or maybe reverse that. All in all, it is LIKELY that I have reversed dolly/truck terms throughout my yammering.
Stay tuned for more ideas.