0
$\begingroup$

Rosanswers logo

Hello

I am using colladadom to produce a dae file of a simple 3D structure (a simple polygon with a color)

Then I send a visualization_msgs::Marker to rviz of the type MESH_RESOURCE pointing to that dae file.

I all works great, the polygon is drawn on rviz.

My problem is that I want to be able to change this 3D structure in real time (no so fast, but to change it in runtime)

So what I do is rewrite a the dae file and then send a new visualization_msgs::Marker message to rviz so that it draws the new polygon (the new rewritten dae file)

The problem is that after the first draw, which goes well, rviz seems never to update the marker again, even if I change the dae file to a different polygon the old one is drawn.

I was thinking and it could be one of the following things:

  1. the header.stamp of the marker msgs: I checked and the new polygon marker message has a newer timestamp, so it should override the old polygon.
  2. the action field in the msg. I tried ADD and MODIFY (although I think now they are the same). Nothing changed.
  3. the id field of the marker_msg. I was wondering if it was a problem of receiving always the same id. I tried changing this and nothing happens.

If the problem is not related to any of the previous points, I was wondering if rviz has some behaviour of loading the collada files just the first time. Or could it have something to do with the resource retriever?

Thanks for the help

Miguel Oliveira


Originally posted by Miguel Riem de Oliveira on ROS Answers with karma: 254 on 2011-11-09

Post score: 1

$\endgroup$

2 Answers 2

0
$\begingroup$

Rosanswers logo

I think I found the problem

In the rviz code, at /rviz/default_plugin/markers/mesh_resource_marker.cpp

line 101,

there is something like this

void MeshResourceMarker::onNewMessage(const MarkerConstPtr& old_message, const MarkerConstPtr& new_message) { ROS_ASSERT(new_message->type == visualization_msgs::Marker::MESH_RESOURCE);

scene_node_->setVisible(false);

if (!entity_ || old_message->mesh_resource != new_message->mesh_resource)
{ //DO THE WHOLE PROCESSING HERE }

(...)

I think that for efficiency reasons the rviz author decided not to reload a dae file, and that if test checks just that.

I am able to solve the problem using two different files and alternating between both.

The problem now is that the rviz also loads the mesh once. In rviz package

rviz/src/rviz/mesh_loader.cpp, line 532 the following code

if(Ogre::MeshManager::getSingleton().resourceExists(resource_path))
{ return Ogre::MeshManager::getSingleton().getByName(resource_path); } else { //LOAD THE MESH HERE NORMALY

Also prevents a previously loaded file to be reloaded. Is there any way I can force rviz to reload files?

Thank you Miguel Oliveira


Originally posted by Miguel Riem de Oliveira with karma: 254 on 2011-11-09

This answer was ACCEPTED on the original site

Post score: 2

$\endgroup$
0
$\begingroup$

Rosanswers logo

Something like this has come up before, the desire to essentially send a "Mesh Message", which has not yet been written.

To work around it with rviz as is, you are almost there. You will need to actually write a brand new file name for each new mesh. Then MeshManager::getByName() will never find your new file to be a duplicate and will always load the new mesh.

Whatever node is publishing the Marker messages and writing the mesh files can also delete each old file. You might leave a buffer of a few mesh files in case rviz gets behind.

This is probably not a very efficient solution, but you said it's not happening all that fast.

Another way to handle it is to use the TRIANGLE_LIST marker type. You would need to write something to pull the triangles out of the mesh, and you couldn't texture it, just set the color of each triangle.

Longer term, it probably makes sense to implement a MeshMarker message for rviz which actually transmits the mesh data right in the message, and thus updates the shape every time.


Originally posted by hersh with karma: 1351 on 2011-11-16

This answer was NOT ACCEPTED on the original site

Post score: 1


Original comments

Comment by Miguel Riem de Oliveira on 2011-11-16:
Ok I'll do the delete the old one and create a new file in every iteration, as you suggest. Thanks for the repply :)

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.