Open HWiese1980 opened 6 years ago
I've seen something like that before where it's actually caused by clipping of the viewport box when you have a strange reference frame.
I don't have time to look into in detail right now, but if you could provide a small bag file and an rviz config that reproduces the problem, at least someone else could reproduce the issue locally.
Okay, I'll see what I can do regarding the bag file.
Alright, so here are the corresponding rviz and bag files:
https://www.dropbox.com/s/lt5z0sxxs3mwtnd/rviz_bag.tar.gz
You can (if at all) best see the effect in Orbit view starting with the following view data:
Distance: 8.3
Yaw: 3.95
Pitch: 0.35
Focal Point: -0.19 2.41 -0.37
Near Clip: 0.01
Focal Shape Size 0.05
Focal Shape Fixed Size: yes
Target Frame:
and using the mouse moving to Pitch: 0,57
The effect is especially visible at the end of the bag file as "head of the depicted person (me) disappearing behind wall"
Thanks. Again, I don't have time to look into it right now, but having this to help reproduce increases the chance someone else will have a look and will help me when I eventually have time to look into it.
Alright, hope to get some help soon... it's quite disruptive...
I figured out that it only happens when Alpha of the rendered point cloud is set to something less than 1.
I can reproduce this issue. #1644 / #1656 are not fixing this issue - so it's not related to bounding box / bounding sphere calculation. Due to the fact that Alpha
needs to be less than 1, it looks like a basic rendering issue.
When reducing the point size
from 3 to 1, the points become visible as well.
Is the z-rendering of the points actually correct when point size is set to 1, or is it just a coincident because overlapping points of course get rarer the smaller they are?
Just to mention it, I'm no longer on the project, so I have no means currently to check anything. I'm just curious to see how things here turn out in the end.
I'm afraid that the overlap between pixels is just smaller. Unfortunately, we don't have rendering experts amongst the rviz maintainers (anymore). So, unfortunately, I have no idea how to tackle this issue.
That's a pity. I mean, Rviz is first of all for rendering the current state of the robot in a 3D environment... so I'd assume, rendering experts were an essential part (if not the most essential) of the maintainers... but who am I to criticize. It's the way it is. I'm no rendering expert either, otherwise I'd have of course offered my support or at least tried to fix it myself. Now I'm wondering what the plans are regarding the future of Rviz...
Either way, thanks for checking! It's been a while since I felt the pain that made me open this issue. I'd be happy if it got tackled nevertheless somehow, if not for me, then at least for other people who also experience the issue.
rviz for ROS1 isn't actively developed anymore. I'm the only maintainer trying to fix the most pressing bugs... Hopefully, the ROS2 team of maintainers is larger.
Ah, I see... I'm not sure if this is an actual "pressing bug". Not for me anyway. So I guess the choice is yours whether you want to continue tackling it or not. Since I'm currently not affected anymore, I can't really tell how pressing it is.
Hi everyone,
I've been experiencing some weird z-buffer errors wrt. PointCloud2 rendering recently that I don't know what causes them and how to solve the problem. You can see the effect here. It doesn't look like the point cloud itself is wrong. The points are where they should be. But they somehow from some certain perspectives appear to be rendered in the wrong z order.
From the About box: RViz version is 1.12.15 (Kinetic), OGRE is 1.9.0 (Ghadamon), QT is 5.5.1. OS is Ubuntu 16.04 LTS.