Plonq
Lacking boundary values on panning
I have been attempting to limit my the position of my pan_orbit_camera to specific x, y, and z values using the below code:
fn limit_pan_system(mut query: Query<&mut Transform, With <PanOrbitCamera>>) { for mut camera in query.iter_mut() { const MIN: f32 = -100.0; const MAX: f32 = 100.0; camera.translation.x=camera.translation.x.clamp(MIN, MAX); camera.translation.y=camera.translation.y.clamp(MIN, MAX); camera.translation.z=camera.translation.z.clamp(MIN, MAX); } }
This will cause the camera to pop to within the allowed value on update, which is a bit janky, but works. However, when I resume panning, it will pop back to the original bad values and resume moving from them. This makes me think that the panning system has locally stored x, y, and z separate from the transform that I do not have access to. Could those be exposed, linked to the transform values, or have a clamping feature added?
You are correct, panorbit camera stores its own values which it uses to update the camera's transform. Updating the camera's transform directly is not supported.
What is your goal here? This is an orbit camera - if you are clamping the camera's location, then you are interfering with the orbiting motion, which would be weird, would it not?
But let's say you wanted to keep the camera within a specified box, moving the camera in towards the focus while orbiting, in order to keep it within the bounds. To do this you'd need to calculate the maximum radius value, based on the focus, pitch, yaw, and the box bounds, and update zoom_upper_limit accordingly.
The goal here is to keep the camera within a specific space. I had considered the method that you put forth, but it seemed overly cumbersome. Determining if the camera's current transform x, y, z is within the allowed zone is easy, but computing the zoom_upper_limit is difficult when the bounding space is not spherical. For instance, in a cubic "room" i wish to allow the user to park the camera in any corner of the room for maximum visibility, and the radial distance to the corner is different from the radial distance to the center of the wall. Thus, I would have to recompute the zoom_upper_limit based upon the focal point's position within the bounding cube and then compute the distance from that point to the intersection of the bounding cube's side based upon its current pitch and yaw. None of this computation is light, as far as I am aware.
However, determining the minimum and maximum x, y , and z values allowed requires a one time computation upon entry into the cubic space.
Perhaps there is a library or known method for casting a ray and determining its distance to intersection that I am not aware of? I wonder if that library has some computationally light method of doing that? Otherwise, updating this camera to support x, y, and z clamping would certainly resolve that.
Yeah I understand it's more complicated. I don't know how computationally expensive it would be but I would have guessed not hugely.
There's no real alternative here. Focus, yaw, pitch, and zoom are the source of truth. In order for smoothing to work, these are the values that must be modified. If I implemented clamping in the plugin, I'd have the same problem as you. I would need to do that calculation.