[Documentation] [TitleIndex] [WordIndex

Development on this stack is discontinued.


The visualization_engine stack (also known as RVE) is a framework for developing 3D visualization tools. The goal of RVE is to provide enough functionality to build rviz2 as a GUI on top of it.

While the overall goal of the stack is 3D visualization, there are also a number of underlying technologies that have been developed that may be useful on their own. These packages are currently prefixed by rve_, but if they're proven useful may get promoted upwards.

The packages in RVE can be thought of as belonging to 4 different categories. There are infrastructure packages, which may be useful outside of RVE. Second, there are message/interface packages, which provide messages that are specific to RVE. Third, there are rendering packages, which handle the various aspects of 3D rendering. Last, there are meta-visualization packages, which provide higher-level functionality on top of the infrastructure and rendering packages.


These packages may be useful outside of RVE, and may be promoted to a higher level at some point. They're being released under the RVE name in order to prove their use and evolve their APIs under real-world use. They also tend to make assumptions about how they're being used that will need to be fixed before they can be promoted out of RVE.

Note that anything here that says it's cross-platform really means it has been abstracted so that alternate platforms can be easily implemented. The only currently tested platform is posix.


The message/interface packages are:

3D Rendering

These packages handle the interfaces to rendering 3D data in a scene. RVE's renderer is split into two parts, the client and the server. Splitting it this way provides a number of advantages:

  1. The initial goal with the client/server was to model an Active Object, which allows all rendering to happen in a separate thread from, say, the UI. Because we use rve_rpc for this, it extends to being able to run the render server in another process as well, or even across the network (on, say, a cluster machine).

  2. The only code dependent on ogre is in the server. Replacing ogre with something else (such as raw OpenGL) involves only rewriting the server. None of the client code should need to be modified.

  3. It allows more control over the rendering being done. Everything going through a custom rendering pipeline (as opposed to direct access to Ogre) allows uniform support for picking, lighting, etc.
  4. It opens the possibility of implementing an alternate renderer. For example, one could implement a realtime raytracing renderer for generating super high-quality screenshots or movies

The rendering-related packages themselves are:


The meta-visualization packages map to higher-level concepts useful for writing visualization tools. For example, rve_transformer package creates a Transformer concept that is similar to but more powerful than an rviz Display, the goal being to turn some input data (generally a topic) into renderable output. GUI code that may be useful to multiple projects also fits into this category.

Report a Bug

2024-07-20 14:47