For what it's worth, you don't have to settle for billboards in rviz.  There is already a geometry shader you can choose in the PointCloud and PointCloud2 displays which lets you display the points as axis-aligned cubes.  You still have to set the size of the cubes manually, but you don't have to settle for billboards.

You could also write a display plugin to display octomaps directly.

Dave

On Sat, Oct 27, 2012 at 8:49 AM, Stefan Kohlbrecher <stefan.kohlbrecher@gmail.com> wrote:
Hi,

I'd consider it useful to make a plugin interface available within the
map_dispatcher that gives access to the map. Implementing this
interface, users could then create and load their custom plugins to
retrieve information based on map data (or even update the map). We
(Christian Dornhege, a few others and me) implemented an example of a
similar system for a modified octomap_server at the ROS summer school
in Graz earlier this year. We implemented a small proof of concept for
sensor coverage mapping based on octomap, keeping track of the
geometry seen by cameras (Video here:
http://www.youtube.com/watch?v=JwbZegYgxzc). To do so efficiently we
added the following plugin interface for coverage_octomap_server:
https://code.google.com/p/rescue-ros-pkg/source/browse/trunk/coverage_mapping/coverage_octomap_server/include/octomap_server/CoverageOctomapServerPlugin.h

The coverage sensor updater plugin (as an example) then implements
this interface:
https://code.google.com/p/rescue-ros-pkg/source/browse/trunk/coverage_mapping/coverage_sensor_updater_plugin/src/coverage_sensor_updater_plugin.h

This gives the plugin full access to the the map and also allows to
easily customize the number, types and parameters of plugins to load
via launch files. An example yaml file looks like this:
https://code.google.com/p/rescue-ros-pkg/source/browse/trunk/coverage_mapping/coverage_octomap_server/params/sensor_params.yaml

Another example illustrating the advantages of this approach even
better is probably the lookup of a single distance (e.g. raycast) into
the map, or any other operation that is cheap, provided one has access
to the map data. If the map_dispatcher does not provide the desired
functionality, some other node has to retrieve a copy of the complete
map, only to do this simple and cheap operation. Using a plugin
interface like described before, one just has to implement a plugin
that provides the requested functionality via a service server, making
things much more efficient and IMHO less cumbersome.
Most other functionality proposed for the REP could then of course
also be implemented using plugins, making the map_dispatcher
completely reconfigurable (which one might or might not want).
Anyways, I just wanted to share the idea and put it up for discussion.

regards,
Stefan



2012/10/26 Stéphane Magnenat <stephane.magnenat@mavt.ethz.ch>:
> Hello,
>
> It would be nice to hear some feedback from the potential users of the
> mapper nodes. People doing semantic mapping, object recognition, etc, what
> do you need? I feel that we have a fairly good idea of the requirements for
> mapping itself, but not enough information on the downstream use of maps.
>
> Cheers,
>
>
> Stéphane
>
> --
> Dr Stéphane Magnenat
> http://stephane.magnenat.net
> _______________________________________________
> ros-users mailing list
> ros-users@code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
_______________________________________________
ros-users mailing list
ros-users@code.ros.org
https://code.ros.org/mailman/listinfo/ros-users