Two trackballs?

[dov]

I'm trying to implement a "Orienter Gizmo", that should show the xyz axis orientation in the corner of the viewport. My plan was to create a OrienterTrackball connected to an "orienter camera". The OrienterTrackball inherits vsg::Trackball but blocks the zoom and pan functions. That part worked fine and I can rotate my axes. But when trying to add the model trackball to the scene, I discovered that when I try to add a second event handler after adding the event handler for the orienter trackball, then those events are not processed. Here is the relevant code.

  auto trackball = OrienterTrackball::create(camera);
  auto orienterTrackball = vsg::Trackball::create(orienterCamera);
  viewer->addEventHandler(orienterTrackball); // Blocks events to trackball!
  viewer->addEventHandler(trackball);  

How can I add events both to my (model) trackball and to my orienter trackball?

Thanks in advance!

[robertosfield]

The vsg::UIEvent base class that all the event types subclass has a handled flag to specify whether an event handler has dealt with the event and subsequent event handlers should take this into account on judging whether to handle the event themselves:

https://github.com/vsg-dev/VulkanSceneGraph/blob/master/include/vsg/ui/UIEvent.h#L36

The vsg::Trackball class both sets and honours the handled flag so if the first trackball handles it then subsequent ones won't handle it. If your custom event handler doesn't intend to avoid other classes from processing the events then you could just not set the handled flag.

Alternatively you could subclass from vsg::Trackball and override/customize it's behaviour, possible mix it with the OrienterTrackball you have. You could event nest another event handler within an outer one and pass the events on to the nested class and manage the handled flags at the time that suits you usage case.

[dov]

Thanks! That explains it. Indeed after resetting the handled flag explicitly in the orienter event handlers, did I get events to my (model) trackball as well. But I agree with your second approach as the two two trackballs are not independent, and should show the same orientation. So I'll change my implementation to have the orienter trackball delegate the events to the model trackball.

[dov]

So I changed my architecture so that the orientation trackball takes the model trackball as a parameter, and it succesfully delegates all events to it. But I still fail to match to align the view matrices of the orientation camera and the model camera. At construction I tried to make them match by setting the orientation camera as follows:

    // Setup the orientation camera based on the model camera
    auto lookAt = vsg::LookAt::create();
    lookAt->set(modelCamera->viewMatrix->transform());
    setViewpoint(lookAt);

But this did not align them! However the interaction affects both cameras, but not fully. E.g. sometimes I'm left with the model camera continuing rotating while the orientation camera has stopped.

What am I missing?

My complete example can be found here:

https://gist.github.com/dov/8a03c01d610203dbca23be1b6d394013

[robertosfield]

I don't know what functionality you are attempting to implement, all I know is how you've gone about trying to achieve the functionality. Without knowing the end point and reasons behind what you are trying to implement I can't provide any advice on how you should be implementing it, and how to resolve what issues might be remaining.

The best I can say it's combine two trackball classes is not something I've come across other users attempting with the OSG or VSG, it might what you are trying to do is reasonable, or might be that you've just heading off on the wrong track.

[dov]

Thanks for your comments, Robert. Sorry for not being clearer. What I wanted to do is to show a "gizmo" in the corner of the vsg view which shows the current camera orientation. For an example of such a gizmo see the following screenshot from Blender:

After playing around some more with my example, I realized that using two trackballs is indeed unnecessary. Instead in my latest effort I subclassed vsg::Trackball as OrienterTrackball and had it control the model camera, just is the normal behavior of the baseclass. In addition, OrienterTrackball creates a second camera, orienterCamera that views only the gizmo, and in the overloaded vsg::Trackball::rotate() method, I tried to update the view matrix of the orienterCamera. Unfortunately, it still doesn't work as I have not figured out yet how to create the orienterCamera view matrix that reflects the rotation (but not the zoom or pan) of the model camera.

Here is the graph that I have created. The green arrow represents the normal camera that the trackball controls. The blue arrow is the additional camera that is created by the OrienterTrackball and is updated in the vsg::Trackball::rotate() overloaded function, based on the viewMatrix extracted from the camera.

Does this approach make sense? Do you have another idea of how to create an orientation gizmo?

[robertosfield]

Thanks for the explanation. This is why high level intros are really helpful.

The way I would tackle a compass/axis insert view like you describe is that set up the insert View as you describe but assign it's own vsg::Camera and it's own vsg::ViewMatrix and vsg::ProjectMatrix instances. For vsg::ViewMatrix on the insert view I would subclass from vsg::ViewMatrix and override the transform method to implement the tracking on the main view's vsg::Camera's own ViewMartrix.

The vsg::RelativeViewMatrix subclass from vsg::ViewMatrix is the closest to what type of ViewMatrix you'll want. Instead of adding a relative transform like this class does you'll want to track the rotation component of the main ViewMartrix. The vsg::decompose function can be used to convert a vsg::dmat4 into it's component parts include the rotation.

With this approach you can have your insert view track any main view setting as it's just coupled to the view matrix not the trackball implementation, so if you change how you set the main view's camera view matrix it'll just work with no needed changed.

[dov]

Thanks Robert! It works! vsg::decompose did the trick. The axes now track the rotation of the model, and are unaffected by zoom and pan. Do you think there is interest as an example? Though I need to clean it up first.

[robertosfield]

Great to hear you got it working. I was hoping that a vsgExample might be possible this as it's something that other useful will be curious about. So if you can clean it up it'll be much appreciated :-)

[dov]

I just created a PR for my cleaned up version. Here is a short video of it in action. Next step is to add interaction and various flavors for the orientation. blender like and freecad like would be the first once to add.

vsgviewgizmo-screenshot.webm

Thanks @robertosfield for your help!

[robertosfield]

Looks good, thanks for writing the example.