feat: Enhance camera orbiting

[Luisao-official]

This commit introduces a new orbiting functionality by implementing a polar coordinate system (constrained to the Z-axis). This new method makes the orbit camera a lil more intuitive

Key enhancements:

• A new moveCamForAxes function for smoother, more predictable orbiting.
• Improved exception handling with the addition of a log_exception function.
• Constrained camera pitch to prevent unexpected camera rolls.

[nivekmai]

*aren't

[Luisao-official]

shame on me

[Luisao-official]

If I remember correctly, these except block changes were just to avoid letting bare excepts (mainly to get rid of the IDE warnings). My implementation was to take whatever text the fusion360 handler gave to that error and print on the API shell, centralizing that to the log_exception. All of those can be removed safely. The orbiting implementation itself was working correctly, with the caveat of not allowing full 360 loops on the XY plane, due to the reference (cross vector) being the Z axis (that cross vector breaks when the view angle is parallel to the Z axis)

[nivekmai]

Required:

• update yaw/pitch/orbit when orientCam called

Nits:

• move global variable definitions to be like the others (globalize and init in run)
• use pascalCase instead of lower_snake to have consistent variable/method naming

Other than that, it works well! If you wanna address the required and nits I'll merge, otherwise I'll just rewrite using your new maths and my preferred style.

[nivekmai]

Since you now store separate variables for the camera location instead of updating the existing camera, you need to update the local variables to match the camera when hitting HAT buttons.

[nivekmai]

All unused now right? Can delete

[Luisao-official]

Yes these were replaced by implementations inside the new moveCamForAxes itself

[nivekmai]

extract 0.05 to a constant (maybe update ROTATION_AXIS_SCALE since you don't use it anymore?)

[Luisao-official]

yeah definitely. Also, that needed to be fine-tuned, but I personally found it quite fluid with that scaling factor

[nivekmai]

Should be a constant up w/ the others?

[Luisao-official]

I think that's much closely related to the orbiting context, and that constant is just there to prevent the glitches when trying to loop on the object (over XY plane). In that regard, this constant could even be ditched and replaced with a hardcoded max angle value on the relevant section, maybe with a comment explaining that option (L442)

[nivekmai]

Should this use the same ROTATION_AXIS_SCALE constant as L435, L436?

[Luisao-official]

nop that controls how fast the zoom occurs when a zooming signal is detected [-1,1] * zooming factor (in this case 0.05)

[nivekmai]

Would be nice to pull this out to a method (getOrbitOffset)

[nivekmai]

pull duplicated code to a method

...
    addScaledPanComponent(pan_vec, panXAxis, side_vec, orbit_radius) 
    addScaledPanComponent(pan_vec, panYAxis, local_up, orbit_radius) 
...

addScaledPanComponent(panVec, axis, inputVec, orbitRadius):
    panComponent = inputVec.copy()
    panComponent.scaleBy(scalePanAxis(axis) * orbitRadius * PAN_ZOOM_COMPENSATION)
    panVec.add(panComponent)

[Luisao-official]

I'm having trouble making the new moveCamForAxes compatible with the jump-to-view button functionality. The outcome I'm getting is that when I press the button and wait for some time, the camera position remains persistent, but this is not consistent, and the tendency is for the camera to snap back to where moveCamForAxes left it.

My implementation was to basically reverse engineer the camera position that fusion gives, into polar terms, using atan/asin, and then updating the respective variables (which are now global, initialized inside run())

A brief summary is:

inside orientCam()

   global yawAngle, pitchAngle, orbitRadius
   # other orientCam() stuff...
   setCam(cam)
   
   doEvents()  # allowing Fusion to process the camera change
    app.activeViewport.refresh()  # ensuring (in hopes) that the view is updated

    # recalculating orbit state from the new camera position (from fusion)
    cam = app.activeViewport.camera
    target = cam.target.copy()
    eye = cam.eye.copy()
    view_vec = target.vectorTo(eye)

    orbitRadius = view_vec.length

    # Now it's the reverse-engineering part to get the yaw and pitch angles
    # for pitch, we can use the Z component of the view vector and the orbit radius

    pitchAngle = asin(view_vec.z / orbitRadius)

    # for yaw, we need to consider the X and Y components.
    # it's crucial to get the angle in the XY plane relative to the positive X-axis. (our reference direction)
    # we create a vector from the target to eye projected onto the XY plane.
    xy_projected_vec = Vector3D.create(view_vec.x, view_vec.y, 0)

    # just a little check to avoid issues with atan2(0,0)
    if xy_projected_vec.length > 1e-6:
        yawAngle = atan2(xy_projected_vec.y, xy_projected_vec.x)
    else:
        # If the camera is directly above or below the target, yaw is ambiguous.
        # We can keep the current yaw or set it to a default (like 0)
        # My approach is to keep the current yawAngle
        pass

My controller has got some serious drift, so that isn't helping either

[nivekmai]

My controller has got some serious drift

I'd assume that's why you see it "snap back after a second", probably the drift triggering a move, I find it only snapping back if I start moving joysticks. Maybe try increasing the dead zone to compensate for the drift?