Hi everyone!
I’d like to have a camera that would switch places in a set interval based around a flying balloon, while keeping it in it’s center view (a directed camera, not controlled by the user). I’d like it without animations, just straight up setting a new position every 20 seconds. I’ve managed to do something like this in Three.js, you can check it out here.
Both the camera and ballons are moving next to each other, after 20 seconds camera is fed current balloon coordinates at the moment and it’s position is changed based on them.
While trying to do the same thing in BabylonJS I’ve encountered an issue where the camera when changing positions seems to reference the initial placement of the balloon, disregarding that I’m giving it it’s current position in the world space. With every change it then gets further and further away from the balloon. Any guess why this happens?
Here’s the playground showing what I’m trying to achieve and what really happens (the model might take some time to load).
Is there some other, more convenient way to make a camera follow an object and switch positions on regular intervals from code?
If I understood your issue properly this is what’s happening.
At the start you defined camera target to look at (0, 0, 0). And then you are changing the position of the camera, while camera target still remains at (0,0,0). In fact camera will always look at (0, 0, 0), but camera position will change. So as baloon changes the position (at the start it was at (0, 0, 0), which coincidentally (or not) is the same as cameraTarget position ), baloon will drift off somewhere, while camera still looks at the (0,0,0).
Now, what you need to do is either to change camera target in setInterval to match position of the baloon OR, what I’ve done in this playground, is that at the start you set camera target position to the position of the baloon (I’ve chose one of the parts), so whenever baloon position changes, the camera target will will match that change.
Note: in playground I reduced setInterval to 2sec to not wait a lot to see the effect.
Hey there, I think this might be closer to what you are looking for ? I found it easier to think through with grouping the meshes under a TransformNode and call that airship. Also cameraPositions should just be the offsets
I sped up the movement as well so that you can see if you comment out line 65, the problem from before is back.
Added in the camera target changes as well like @nogalo mentioned
Your solution worked flawlessly for me until I’ve noticed in my scene that with every camera position change it seems like it’s progressively moving more forward along the X axis. Like apart from current airship position + offset there’d be some additional value constantly increasing and moving the camera further than it’s needed.
Unfortunately I wasn’t able to reproduce it in a playground, making camera move on the same axis as the balloon makes it stick properly and doesn’t incrementally drift away as it does in my scene.
I’ll try to figure out what is causing this, the only way I can show you what it looks like is directly from my scene hosted in github.. After waiting a bit you’ll notice how during the next position switches the camera is shifting more and more on the X axis.
Well, you are slowly moving the camera in yours, I had that taken out of mine. Not sure if that is what you are referring to. camera.position.x += 0.054; in the update loop
That’s correct,
I did that because the camera is supposed to move with the airship and keep moving after switching positions (imagine multiple cameras on a rail). In that last playground you can see that even while moving the camera in the update loop it doesn’t shift anywhere further than it is set, the airship is always centered in the camera view.
In my scene it looks like it’s progressively shifting further and further on the X axis, like the offset is getting bigger every time the camera loop restarts. I’ve yet to come up with why that is happening but I might just account for that by substracting the offset by some fixed value or something.
Your idea of using TransformNodes still helped me progress further that so you have my thanks!
Okay the reason was actually much more dumb than I thought.
In my scene there’s a group of airships moving together and the first one loaded is turned into the transform node to use it’s position as a point of reference to change the camera’s position.
I didn’t notice in my code that while the camera was moving 0.054 units on X axis per frame, the transform node was moving 0.06 units so it was actually faster than the camera. I couldn’t see that becasue visually in the scene it seemed to be moving at the same speed as the camera while in reality it was actually faster.
I managed to cheese it out by importing the first airship twice, turning the very first one into the TransformNode and making it invisible, so there’s actually an invisible little balloon lagging behind the armada of airships
The camera is still referencing that invisible dummy airship’s position when changing it’s own but it’s actually moving around the actual airship armada. It’s a very stupid solution but works for me!
Nice Glad you found it! I was having trouble seeing it because on macbook pro getting 5 - 10 FPS on that scene. I wonder what is bogging down my machine so hard
Yeah, I’m doing this for my master thesis, the scene is supposed to be sort of a makeshift performance benchmark so it is made to be performance heavy. It features around 60000 thin instances of trees, multiple “clouds” done using Babylon’s GPU particle system and a day/night cycle with a dynamic directional light.
I actually did some testing on one Macbook Pro and found out issues forcing it to use a dedicated GPU on MacOS, it kept using the integrated one which didn’t really handle the scene well.
EDIT: I’ve updated the scene here so you can see my transform node solution in action.
Oh I don’t think mine even has a GPU, that makes sense about the performance then. Is a neat scene for benchmarking! Reminds me of this one airship one from way back when actually
), baloon will drift off somewhere, while camera still looks at the (0,0,0).
Glad you found it! I was having trouble seeing it because on macbook pro getting 5 - 10 FPS on that scene. I wonder what is bogging down my machine so hard