New Trackball suitable for whole earth databases

[Robert Osfield]

Hi All,

With the new vsgpagedlod example's ability to stream and generate whole earth databases the usability of the the traditional trackball functionality provided by vsg::Trackball for these large databases is so poor as to make it unusable.  To improve the usubility I've begun developing a GlobeTrackball class that is now checked into the vsgpagedlod example in the PagedLOD branch vsgExamples:

https://github.com/vsg-dev/vsgExamples/blob/PagedLOD/examples/nodes/vsgpagedlod/GlobeTrackball.cpp

The OpenSceneGraph has a TerrainManipulator class that works better than the traditional trackball as it adds terrain intersections for clamping the center of rotation, it's not perfect though, and osgEarth has it's EarthManipulator which is more suitable, but it's not as intuitive as it could be.

So I've been experimenting with a approach to adapting the behaviour of traditional trackball to the needs of a whole earth database.  My hope is that the general feel of the interaction will be similar between the traditional unconstrained trackball and the one that clamp to the ellipsoid model.  The main change in behaviours are the clamping to the ellipsoid and changing of panning  so that dragging the mouse around will be equivalent to dragging a point on a physical globe around.  

By keeping the general behaviour similar to the traditional trackball and the new globe trackball then rather than having multiple classes it'll be sufficient to just have a single vsg::Trackball class that supports unconstrained or constrained to an EllipsoidModel.  For uses it'll just be a configuration option - possibly as simple as passing in the vsg:::Node or NodePath that you want to constrain the camera manipulator to. 

I have uploaded to youtube  a video of traditional vsg::Trackball vs the experimental GlobeTrackball:

 

    Experimental GlobeTrackball camera manipulator

I still have a few more improvements in mind so will continue working on the new class, with the goal of getting it checked into the core VSG next week.

[Robert Osfield]

I have made further improvements to the vsg::Trackball adding throw and viewpoint animations with the goal of making the user interaction a smoother and more intuitive experience whether you are working on small models or whole earth GIS style models.  To illustrate them in actions I've recorded a video:

       https://youtu.be/O0ONM_FcFPo

The changes to vsg::Trackball are checked into VulkanSceneGraph master, as well as add API for setting new viewpoints to animate to, keyboard bindings for user defined viewpints there are now controls for setting the mouse button masks used to control so users can customize the behavior to what suits there users:

    https://github.com/vsg-dev/VulkanSceneGraph/blob/master/include/vsg/viewer/Trackball.h

I have updated the vsgpagedlod example to illustrate how one can set up keyboard bindings that control which viewpoints to animate to:

    https://github.com/vsg-dev/vsgExamples/tree/master/examples/nodes/vsgpagedlod

The code for setting up the Trackball is:

                auto trackball = vsg::Trackball::create(camera, ellipsoidModel);
                trackball->addKeyViewpoint(vsg::KeySymbol('1'), 51.50151088842245, -0.14181489107549874, 2000.0, 2.0); // Grenwish Observatory
                trackball->addKeyViewpoint(vsg::KeySymbol('2'), 55.948642740309324, -3.199226855522667, 2000.0, 2.0);  // Edinburgh Castle
                trackball->addKeyViewpoint(vsg::KeySymbol('3'), 48.858264952330764, 2.2945039609604665, 2000.0, 2.0);  // Eiffel Town, Paris
                trackball->addKeyViewpoint(vsg::KeySymbol('4'), 52.5162603714634, 13.377684902745642, 2000.0, 2.0);    // Brandenburg Gate, Berlin
                trackball->addKeyViewpoint(vsg::KeySymbol('5'), 30.047448591298807, 31.236319571791213, 10000.0, 2.0); // Cairo
                trackball->addKeyViewpoint(vsg::KeySymbol('6'), 35.653099536061156, 139.74704060056993, 10000.0, 2.0); // Tokyo
                trackball->addKeyViewpoint(vsg::KeySymbol('7'), 37.38701052699002, -122.08555895549424, 10000.0, 2.0); // Mountain View, California
                trackball->addKeyViewpoint(vsg::KeySymbol('8'), 40.689618207006355, -74.04465595488215, 10000.0, 2.0); // Empire State Building
                trackball->addKeyViewpoint(vsg::KeySymbol('9'), 25.997055873649554, -97.15543476551771, 1000.0, 2.0);  // Boca Chica, Taxas

                viewer->addEventHandler(trackball);

These additions combine functionality seen in osgEarth::EarthManipulator and the osgGA::TrackballManipulator/TerrainManipulator into a single class. The remaining vsg::Trackball feature I'd like to implement before VSG-1.0 is terrain following using intersections with the scene.  There are more pressing features I need to get on with before returning to this.  My end goal with vsg::Trackball is to provide good out of the box functionality but not the be all and end of all of camera manipulators for the VSG, it's also meant as a clean example/base for users to customize or implement their own camera manipulators.

[Robert Osfield]

To illustrate how you can configure the button mapping I've added a --osgearth / -e command line to vsgpagedlod that invokes the following code:

                if (osgEarthStyleMouseButtons)
                {
                    trackball->panButtonMask = vsg::BUTTON_MASK_1;
                    trackball->rotateButtonMask = vsg::BUTTON_MASK_2;
                    trackball->zoomButtonMask = vsg::BUTTON_MASK_3;
                }

This is checked in vsgExamples master.  The rotation is still a trackball rather an heading/tilt rotation that osgEarth::EarthManipulator uses and the zoom mechanism is different, but should at least feel a bit more familiar.

[Karol Nowak]

Robert,

Have you tested new trackball manipulator for the simplest scenario?

I have a problem with rotation/zooming of model. It does not work smoothly as before.

I've attached a video which presents the problem I am facing. 

Best regards,
Karol

[Robert Osfield]

Hi Karol,

Thanks for the video, it would be hard to explain what the issue you are seeing without it.  At this point I don't have any ideas as to the cause of the problem so we'll need to iterate between us.  Hopefully others will chip in with their own testing as this would help spot any patterns of where the problem exists.

On Sat, 27 Mar 2021 at 19:44, Karol Nowak <ikaro...@gmail.com> wrote:

Have you tested new trackball manipulator for the simplest scenario?

Yes.  Tested with other VSG examples like vsgviewer and vsgintersection.  Just re-tested now and it's working fine.  I'm testing with Xubuntu 18.04.

 

I have a problem with rotation/zooming of model. It does not work smoothly as before.

Most of the changes to vsg::Trackball should just affect the behavior when you assign a vsg::EllipsoidModel to it - which is what is done with whole earth models like doe in vsgpagedlod.

 

I've attached a video which presents the problem I am facing.

I've just tried vsgimgui and vsgmyfirstvsgapplication and the Trackball is working as intended.  The only difference vs the old behavior should be the throw mechanism.

The only oddity I've spotted so far is when interacting with a ImGui window - when I drag a release a slide when the scene is rotating after being thrown the motion stops on release of the mouse button while still in the ImGui window.  What should happen is the motion should continue.

What platform are you working with?

Have you tested unmodified examples like vsgviewer?

Have you updated to master and rebuilt the VSG, vsgXchange and vsgExamples?

Are panning and rotating working?

Cheers,

Robert.

[Karol Nowak]

Robert,

I am working with Linux platform, Xubuntu 20.10 distro.

I've tested with the latest VSG and unmodified example 'vsgexecutecommands' - problem observed.

I found the commit which causes the problem for me:

https://github.com/vsg-dev/VulkanSceneGraph/commit/793bae785e4124487b8b20f1780d1b670ec9df6a

I do not observe the problem with the previous commit. (246f695f328029d161042d5750d2442c4fd1cd00)

I've prepared a video again which covers pan/zoom/rotation in three cases:

• with the latest VSG changes (master-head)
• with the VSG on 246f695f328029d161042d5750d2442c4fd1cd00
• and at the end, on 793bae785e4124487b8b20f1780d1b670ec9df6a

Best regards,

Karol

[Robert Osfield]

Hi Karol,

On Sun, 28 Mar 2021 at 00:21, Karol Nowak <ikaro...@gmail.com> wrote:

I am working with Linux platform, Xubuntu 20.10 distro.

That should broadly be similar to Xubuntu 18.04.  I did have Kubuntu 20.04 installed on my system but I broke it installing too much experimental stuff, I'll need to reinstall and see if I can see any difference.

 

I've tested with the latest VSG and unmodified example 'vsgexecutecommands' - problem observed.

vsgexecutecommands is working fine for me.

 

I found the commit which causes the problem for me:

https://github.com/vsg-dev/VulkanSceneGraph/commit/793bae785e4124487b8b20f1780d1b670ec9df6a

I do not observe the problem with the previous commit. (246f695f328029d161042d5750d2442c4fd1cd00)

Unfortunately that commit contains lots of changes relating to the new functionality so knowing exactly what might be causing the issue on your system will likely need us to put some diagnostics into the code to see what is happening at your end.

 

I've prepared a video again which covers pan/zoom/rotation in three cases:

• with the latest VSG changes (master-head)
• with the VSG on 246f695f328029d161042d5750d2442c4fd1cd00
• and at the end, on 793bae785e4124487b8b20f1780d1b670ec9df6a

What is the environment that you are using when running the VSG?

What is the hardware/monitor and input devices that you are using?

What happens when you build and run the VSG/vsgExamples in just a standard console/bash?

 I am just using the console and some simple bash scripts for building the VSG components.  The script I used most often is:

cd $VSG_DIR
cmake . -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=~/Install
make -j 15
make install

cd ../vsgGIS
cmake . -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=~/Install
make -j 15
make install

cd ../vsgXchange
cmake . -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=~/Install
make -j 15
make install

cd ../vsgImGui
cmake . -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=~/Install
make -j 15
make install

cd ../vsgExamples
cmake . -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=~/Install
make -j 15

I use a Microsoft mouse and apple trackpad for input, both appear to work smoothly with the VSG master Trackball - the only difference in behavior for normal scenes has been the throw support.  The implementation is quite different but aims to achieve a similar result.

To discount the throw from consideration I've just checked in a bool vsg::Trackball::supportsThrow that defaults to true, but you could reset it to false in your application when setting up the Trackball via:

    trackball->supportsThrow = false;

Or temporarily change the default in the VulkanSceneGraph/include/vsg/viewer/Trackball.h

Given the nature of the issue you are seeing I think the easiest way to track down what is going on is for me to be able to recreate what is happening on your system.  I need to install a more modern version of the Ubuntu family so will do this.  The environment you are using is totally unfamiliar to me but would rather not having learn a new environment just to try and reproduce a bug.

I would appreciate testing and feedback from the wider community on the new trackball as this may well be important in finding out when and where it works fine and when it behaves odd.

Cheers,

Robert.

[Karol Nowak]

Robert,

I've prepared a bash script which clones, compiles VSG and vsgExamples and runs the example 'vsgmultiviews' at once.

I run the script and recorded it. Have a look:

https://youtu.be/wxhJG50FSoE

The problem still occurs no matter if I built the VSG from bash or by using Meson Build System.

I was trying to set trackball->supportsThrow = false; but it does not help.

The hardware I use is:

- Laptop: Dell Latitude 5501

- Monitor: Dell P2419H

- Mouse: Logitech M170

What details do you need about my environment I run VSG example in?

I share the script, it may be helpful to others:

#!/bin/bash

set -e

set -x

# sudo apt install cmake libxcb1-dev pkg-config

THIS_DIR="$(dirname "$(readlink -f "${BASH_SOURCE:-$_}")")"

VULKAN_URL="https://sdk.lunarg.com/sdk/download/1.2.162.1/linux/vulkansdk-linux-x86_64-1.2.162.1.tar.gz"

VULKAN_PACKAGE_PATH="$THIS_DIR/vulkan.tar.gz"

export VSG_DIR="$THIS_DIR/VulkanSceneGraph"

export VSG_EXAMPLES_DIR="$THIS_DIR/vsgExamples"

export VSG_FILE_PATH="$VSG_EXAMPLES_DIR/data"

export VULKAN_DIR="$THIS_DIR/vulkan-sdk"

export VULKAN_SDK="$THIS_DIR/vulkan-sdk/x86_64"

rm -rf "$VSG_DIR"

rm -rf "$VSG_EXAMPLES_DIR"

rm -rf "$VULKAN_DIR"

rm -rf "~/Install"

pushd "$THIS_DIR"

mkdir -p "$VULKAN_DIR"

wget -O "$VULKAN_PACKAGE_PATH" "$VULKAN_URL"

tar -C "$VULKAN_DIR" --strip 1 -xf "$VULKAN_PACKAGE_PATH"

git clone https://github.com/vsg-dev/VulkanSceneGraph.git

git clone https://github.com/vsg-dev/vsgExamples

popd

pushd "$VSG_DIR"

cmake . -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=~/Install

make -j12

make install

popd

pushd $VSG_EXAMPLES_DIR

cmake . -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=~/Install

make -j12

./bin/vsgmultiviews $VSG_FILE_PATH/models/teapot.vsgt

popd

Yeah, it would be the best if someone else verifies it as well.

Best regards,

Karol

[Karol Nowak]

Robert,

Short update from my side.

Trackball.cpp:216: pan(delta * scale);

When I change it to "pan(delta);" Pan seems to work fine as before.

I've prepared a video which presents PAN operation before and after change.

Best regards,

Karol

[Robert Osfield]

Hi Karol,

Good detective work.  I'm away from my dev machine so will do a proper review of the code tomorrow.

At this point I'm still curious why my system behaves so different than yours.  Something different must be happening with the time code that can be used to set the scale. The code went through several incarnations before I settled upon the current implementation. I will need to step through the history of the changes. perhaps the scale code isn't required any more for the handling of the movement.

If it isn't the scale core that is inappropriate then the bug must be somewhere in the timing related code.

Cheers,

Robert.

--
You received this message because you are subscribed to the Google Groups "vsg-users : VulkanSceneGraph Developer Discussion Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vsg-users+...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vsg-users/32dae73a-d10c-4555-8c3c-ae6cfe39b560n%40googlegroups.com.

[Robert Osfield]

Hi Karol,

On Mon, 29 Mar 2021 at 21:16, Robert Osfield <robert....@gmail.com> wrote:

Good detective work.  I'm away from my dev machine so will do a proper review of the code tomorrow.

When disabling vysnc I see awkward behavior with the scale code that you removed, commenting out this line fixes the behavior.  I think this code was originally added when the apply(Frame&) was handling a portion of the movement when dragging, whereas now apply(Frame&) only handles the throw and animation to viewpoint, the apply(MoveEvent&) now just is focused on responding to mouse move events. 

As commenting out the scale is working best across different usage cases I have checked in the commenting out of the scaling method.

When testing I've found that the panning on the a whole earth model when at latitudes far from the equator the behavior isn't right, looks to be another regression.  I must have missed this when adding the throw and animate to viewpoint support.

Cheers,

Robert.

[Karol Nowak]

Robert,

Thank you for providing the commit which disabled the scaling. It works perfectly again.

On the occasion. It must be quite overwhelming to maintain a few VSG repositories at once, isn't it? When I visited vulkanscenegraph.org for the first time I was happy that examples (and so on) will be separated from the VSG core, my thought was: that's the way it should be done. However, when I started using VSG more and more I changed my mind and I must admit that a few repos approach does not make life easier, quite opposite. From time to time, someone shows up and reports a problem that sth does not work here or there, you have to go through at least two repositories to make sure that problem is placed in examples repo or in vsg core repo. I understand that each approach has its pros and cons but in my opinion All-in-one approach which was used in OSG does its job. These days time is precious, nobody wants to spend much time for gluing all pieces together to setup his/her project or use VSG quickly - From psychological point of view it may be quite discouraging. It seems that simple solutions win over complicated ones. Please don't get me wrong, I don't complain, I respect your job, I just share my thoughts. I think All-in-one approach would allow to gain more community. What do you think? Is it overwhelming or not? Are you lost among the repositories from time to time? :)

Best regards,

Karol

[Robert Osfield]

When testing I've found that the panning on the a whole earth model when at latitudes far from the equator the behavior isn't right, looks to be another regression.  I must have missed this when adding the throw and animate to viewpoint support.

I have tracked down what looked like regression, turns out that it was a bug in the addViewpoint(lat, long, altitude) code's set up of the up normal, but it the odd behaviour this error caused wasn't obvious until I did more testing of panning when moving over a viewpoint with a high latitude.  It looked like the panning code was buggy, but it turns out it was simply the set up.  The fix is now checked into VSG master.  

[Robert Osfield]

I think All-in-one approach would allow to gain more community. What do you think? Is it overwhelming or not? Are you lost among the repositories from time to time? :)

Earlier in the VSG's life I experimented with a vsgFramework project that pulled in the components and built them all together.  I have been considering updating this so it can be used as a basis for end users with their own projects.  

My expectation is that the VSG components will just be a part of all the dependencies that a user project will have, so having a standard method for collecting dependencies together and building them as a unit would become a standard approach.  Having the VSG components built as units that can be mixed and matched like this should make this possible and straight forward.