Discussion on Rviz rewrite

[wjwwood]

@pbeeson

I realize that I have changed from the original Unreal/Unity approach I mentioned at the start of this thread to a webgl approach, but this is in response to any licensing issues with Unity or Unreal (though for free/open source, I don’t see any real challenges with Unreal or Unity either).

Actually both Unreal and Unity would be unsuitable for rviz in my opinion (and unnecessarily sophisticated). Unity is not open source, and a that’s deal breaker for us, since we want a fully open source stack for our user space software. And Unreal because even though it claims open source, they have restrictions on distribution of source and binaries (no matching OSI license for that), as well as commercial use and would potentially prevent someone from producing a product with rviz embedded without needing to pay royalties or something. And that’s a feature of the BSD license we’ve chosen and want to preserve.

I did consider VTK and Qt3D, however. I think both are in the right range of compromise: open source, easier to use than plain OpenGL, not a full blown game engine (we don’t need to simulate water or physics in rviz, perhaps Gazebo but not rviz).

Any ways we’ve had that discussion on the rviz issue. Ogre is still ok for now (I’m not sure what limitations it has that rviz needs to overcome), my biggest concern for Ogre 1.x is support lifetime since the main Ogre team has moved on to Vulcan/Metal based Ogre 2.x. But that’s why I started abstracting in the ROS 2 work.

@pbeeson

If you were to redo Rviz using three.js or Babylon.js, then you eliminate any need for third party apps as a browser becomes your 3D rendering environment. Of course adding plugins and other Qt-style
Menus means people have to write Web apps, but In some sense that’s easier for certain individuals. Also, the open source communities behind these webgl platforms is large so perhaps it might spur more outside (of OSRF) development from people that are intimidated by Rviz.

If you want a web based solution, there can be both, and there is. You could consider porting robot web tools (http://robotwebtools.org/tools.html), which had a rviz clone called visualization_rwt I think. OSRF doesn’t have to initiate every project that’s possible . I think a web based solution will not replace the desktop application written in C++ (for now) since performance is a key feature of rviz (not saying 3d is slow in the browser, but pub/sub, serialization, and transforms have been issues for rwt in the past due to JS being slow). Maybe with enhancements to the WebAssembly sandbox it might be possible at some point to replace the desktop app. But that’s too risky to try instead of porting the existing rviz right now. If we had more resources I’d definitely love to try.

@pbeeson

we are trying to plan how to make th Ros2 jump in the near future without the Interactive Markers and other Rviz tools that our navigation and manipulation frameworks are built on top of. We need to replace those with something.

Your absolute quickest and least effort option for that is to contribute to the rviz2 port. It has everything ported except some of the displays, and the effort of porting most displays is relatively low. Interactive markers might be a more considerable amount of work, but there’s no other option that would be less work in my opinion.

@pbeeson

I’ve written a couple of industrial HMIs recently as well, which may be why I am looking for anything other than Qt

I guess it depends on your use case, but I don’t have any issues with Qt productivity wise, and it seems like a good option (not sure what your particular issues with it are). It also just got an ISO 26262 option for those industrial users who need that sort of thing and are willing to pay for it:

Safe and Effective: Functional Safety and Qt