Rviz *_LIST visualization/flickering

[trigal]

I'm opening this issue following this ROS answers post and @wjwwood suggestion.

I'm publishing three different marker-arrays:

• the first one, CYLINDER, yellow in the image (which are the waypoints in OpenStreetMaps)
• second, the roads, LINE_LIST, green
• third, buildings, TRIANGLE_LIST, light blue in the image.

As you can see in this video, when I move the pose inside RVIZ only the cylinders are always visible, all the *_LIST markes appear and disappear as I move the view..

The issue can be reproduced in this way: I've just created a bag-file with only the TFs and the markers plus a Rviz-Config file you need to correctly visualize everything. As you'll see, all the markers are referred to a /map frame which is the standard UTM origin, while local_map is the reference frame I use to visualize all the markers i.e. the fixed_frame in Rviz. Even if the jump is big I don't think the problem may be referred to this huge transform (I mean, some loss of precision with the variables) since the cylinders are pretty fixed in their position (and all the markers are referred to that position, also the blue GPS track you can see in the image attached to my first post).

I'm putting also a bigger bag-file recorded with the -a option, it's about 60M and here you have also the map and lot of stuff (btw I think the first one is enough). As I wrote before, my suspects are about only the LIST arrays. It seems that with those markers there is some kind of precision loss somewhere, but I can't figure out where (I've already checked and all the points seem to be Double-s).

[wjwwood]

I found this: http://www.ogre3d.org/forums/viewtopic.php?f=3&t=68535

Which seems like a similar issue (it seems to be related to camera angle). I can pause the bag (so no updates from the topic) and move the camera and if I stop where the rendering is ok it will stay ok. If I stop where parts of the lines are not showing it will stay that way. So it seems to me that it must be something related to the camera angle to the billboard. This remains true if I let the bag play (updates from the marker targets and from tf).

I tried to integrate the code from the above Ogre post in the branch flicking_custom_ogre_billboard_line_chain (it's a mess, but you can try it out if you like), and even though I can assert it is executing the modified code, I cannot see a difference in the "flickering".

I also tried disabling AA, but that didn't help either.

Unfortunately we may need to try and create a minimal billboard line chain example in ogre and send it upstream. I also haven't tried with Ogre 1.9 (I've been using 1.8).

[wjwwood]

Also, I haven't looked into the triangle list, but I guess they may have a similar problem. I'll see if I can look at those as they might have a different problem with a more tractable solution.

[wjwwood]

@trigal I am beginning to think that your issue is the large UTM transform. Can you try to pick an arbitrary and nearby UTM coordinate as the origin of the /map frame and then try to render it? I don't have time to set that up right now, but I do remember in college having this exact problem (rendering a car and lane markings in a UTM coordinate frame). It probably has to do with how Ogre manages its scene graph with floats.

See this issue for some context: #502

[trigal]

@wjwwood I've created a simple node that transform the markers into the /local_map frame.
Using this frame all the Markers/points have this kind of pose

header: 
  seq: 91
  stamp: 
    secs: 1459842986
    nsecs: 681713872
  frame_id: /local_map
ns: oneway
id: 90
type: 5
action: 0
pose: 
  position: 
    x: 0.0
    y: 0.0
    z: 0.0
  orientation: 
    x: 0.0
    y: 0.0
    z: 0.0
    w: 1.0
scale: 
  x: 1.0
  y: 0.0
  z: 0.0
color: 
  r: 0.0
  g: 1.0
  b: 0.0
  a: 1.0
lifetime: 
  secs: 0
  nsecs: 0
frame_locked: False
points: 
  - 
    x: -17.8555240802
    y: -6.92406820599
    z: 0.0
  - 
    x: -27.4903413883
    y: -13.1652913885
    z: 0.0
  - 
    x: -27.4903413883
    y: -13.1652913885
    z: 0.0
  - 
    x: -33.7115945332
    y: -18.6542765461
    z: 0.0

And the final answer is YES, the large UTM transform is the problem with the _LIST markers. I can't really figure out why all the other not LIST markers have a different behavior and, following this reasoning, I think this could be considered a bug (or at least a defect).

I've created a new bag file where the ways _LIST were transformed to a "local" frame, while the buildings profiles are still in the original UTM frame (for comparison). You can download it from here and use the same rviz config file, changing inside rviz the marker topic, from /ways to /UTM_converter/ways.

[davetcoleman]

I've had rending issues with LINE_LIST within rviz_visual_tools for a long time, and I do not believe its related to UTM frames. I'm glad to see you guys have been looking into this. I've captured a video of the problem - these lines are rendered in the /world frame (global frame) within 2 meters (Rviz units) of the origin. Cylinders, on the other hand, do not have this rendering issue so for a long time I've just used them instead of lines. However I recently had too many lines I needed to draw so a single LINE_LIST message was way more efficient.

[wjwwood]

@davetcoleman doesn't look like the same problem. The issue in your video appears to me that the lines only have one normal face which is determined by the order in which the points are created usually. They're not flickering as reported here, but simply don't appear from one direction.

I think you should make a new issue or investigate whether or not the line list should automatically create the second face.

[wjwwood]

The general term for this is "face culling":

https://www.opengl.org/wiki/Face_Culling

There is an Ogre3D discussion about how to avoid this when using a ManualObject, which is what LINE_LIST uses IIRC:

http://www.ogre3d.org/forums/viewtopic.php?f=2&t=53533