Transformer readability and visualization world frame selection

[maltewi]

Adds:

• Possiblity to configure transformer frame name text size
• Possiblity to configure transformer frame text alignment (screen, 3d axes) (cf. Render transformer graph labels in Screen coordinates #35, but configurable)
• Possibility to explicitly select the frame that should be used as world frame for visualization of the 3d scene

[maltewi]

this is just for testing purposes but not unit tests.. maybe should be removed, maintainer should decide

[maltewi]

this is just for testing purposes but not unit tests.. maybe should be removed, maintainer should decide

[skasperski]

I tried it out and it looks good to me. I was a little confused why there is a new property "transformerRootFrame" instead of using the existend "frame". I always thought "frame" should be the visualization root. With this new setup one has to be extra careful not to use world_osg anymore, which unfortunately is the default for everything.

How do you decide what is the default for transformerRootFrame? Probably should be world_osg to stay consistent with previous behavior?

I also get a lot of messages like this from the rock-display console, which might or might not be related to this PR:

CullVisitor::apply(Geode&) detected NaN,
    depth=-nan, center=(0.183333 0.0833333 0),
    matrix={
	nan nan nan -nan 
	nan nan nan -nan 
	nan nan nan -nan 
	nan nan nan -nan 
}

[maltewi]

The 'frame' property is assoviated to the "Frame"-Manipulator, i.e. the camera controller and afaik not at all to the transformer.

How do you decide what is the default for transformerRootFrame? Probably should be world_osg to stay consistent with previous behavior?

I didn't change anything on the behaviour how world_osg is selected initially. But instead added a way to manually change the default selection of 'world_osg'. Practically, if you select 'frame_a' as 'trasnformerRootFrame' that means that 'frame_a' becomes the new 'world_osg'. Do you still think there's need to change the bahavior? What would be more favorable?

I also get a lot of messages like this from the rock-display console, which might or might not be related to this PR:

CullVisitor::apply(Geode&) detected NaN,
    depth=-nan, center=(0.183333 0.0833333 0),
    matrix={
	nan nan nan -nan 
	nan nan nan -nan 
	nan nan nan -nan 
	nan nan nan -nan 
}

Don't know if its related. Can you kind of narrow down when this occurs (minimal steps to reproduce)?

[skasperski]

I didn't change anything on the behaviour how world_osg is selected initially. But instead added a way to manually change the default selection of 'world_osg'. Practically, if you select 'frame_a' as 'trasnformerRootFrame' that means that 'frame_a' becomes the new 'world_osg'. Do you still think there's need to change the bahavior? What would be more favorable?

Good question. The thing is when I loaded the Robdekon-Sim, the visualization was like 90° rotated, because it selected one of Sherpa's arm joints as transformerRootFrame. So maybe we can initially choose one of the frames that have no parent? I don't think it's super important, but it might save you setting the parameter in many cases and people will probably be confused when their visualization suddenly is rotated unless they set this new parameter.

[haider8645]

Hello Malte, I am facing an issue with opening vizkit3d visualizations from rock-display. If I open any rock plugin like plot2d etc tthen it works. However, none of vizkit3d visualizations work. Vizkit3d visualizations started via ruby scripts still work. The only problem is when they are opened via rock-display. The vizkit3d widget window opens for a few seconds and then crashes with the following error.

Traceback (most recent call last):
	10633: from /home/dfki.uni-bremen.de/mlodhi/ROCK/artemis_demo/gui/vizkit/bin/rock-display:108:in `<main>'
	10632: from /home/dfki.uni-bremen.de/mlodhi/ROCK/artemis_demo/gui/vizkit/lib/vizkit/vizkit.rb:146:in `exec'
	10631: from /home/dfki.uni-bremen.de/mlodhi/.local/share/autoproj/gems/ruby/2.7.0/bundler/gems/qtbindings-bfe173dd488d/lib/Qt/qtruby4.rb:479:in `exec'
	10630: from /home/dfki.uni-bremen.de/mlodhi/.local/share/autoproj/gems/ruby/2.7.0/bundler/gems/qtbindings-bfe173dd488d/lib/Qt/qtruby4.rb:479:in `method_missing'
	10629: from /home/dfki.uni-bremen.de/mlodhi/.local/share/autoproj/gems/ruby/2.7.0/bundler/gems/qtbindings-bfe173dd488d/lib/Qt/qtruby4.rb:479:in `qt_metacall'
	10628: from /home/dfki.uni-bremen.de/mlodhi/.local/share/autoproj/gems/ruby/2.7.0/bundler/gems/qtbindings-bfe173dd488d/lib/Qt/qtruby4.rb:2470:in `invoke'
	10627: from /home/dfki.uni-bremen.de/mlodhi/ROCK/artemis_demo/gui/vizkit/lib/vizkit/vizkit.rb:142:in `block in exec'
	10626: from /usr/lib/ruby/2.7.0/forwardable.rb:235:in `step'
	 ... 10621 levels...
	    4: from /home/dfki.uni-bremen.de/mlodhi/ROCK/artemis_demo/install/lib/ruby/2.7.0/typelib/container_type.rb:266:in `handle_container_invalidation'
	    3: from /home/dfki.uni-bremen.de/mlodhi/ROCK/artemis_demo/install/lib/ruby/2.7.0/typelib/type.rb:366:in `block in handle_invalidation_protect_containers'
	    2: from /home/dfki.uni-bremen.de/mlodhi/ROCK/artemis_demo/install/lib/ruby/2.7.0/typelib/type.rb:365:in `handle_invalidation_protect_containers'
	    1: from /home/dfki.uni-bremen.de/mlodhi/ROCK/artemis_demo/install/lib/ruby/2.7.0/typelib/container_type.rb:275:in `handle_container_invalidation'
/home/dfki.uni-bremen.de/mlodhi/ROCK/artemis_demo/install/lib/ruby/2.7.0/typelib/container_type.rb:268:in `ensure in handle_container_invalidation': stack level too deep (SystemStackError)

[planthaber]

@maltewi is this still a draft? Otherwise we could possibly merge #65 to have the viz frame selection before we merge this PR.

[maltewi]

The discussion points raised by @skasperski and @haider8645 are not sorted out. Without an update on that (i.e. more testing and validating of falsifying the issues) I'd not consider it as ready

[planthaber]

Then I'll merge the other PR, I guess you'll have to resolve the conflict then along solving the other issues