PointCloud2: Huge point size when window is maximized #1508
Comments
|
Sorry, but I cannot reproduce your issue. Showing the test point cloud generated by
|
|
A bit similar here, points from pcl or LaserScan appears very small, size cannot be changed and with no color, unless rviz is started with |
|
This is weird. I tested on two different laptops, no discrete GPU as well. No problems. |
|
I thought it was weird that the console output printed "Forcing OpenGL version 0". is that normal output? |
|
On my laptop with a discrete nvidia GPU, no issue but on another computer Intel only, same issue (all points are small and colorless) |
|
my computer has an Intel as well. |
|
I'm running on an Intel "GPU" as well. However, the OpenGL version reported is different for me: Could you please report your installed (software) OpenGL packages? Mine are: $ dpkg -l | grep mesa
ii libegl-mesa0:amd64 20.0.4-2ubuntu1 amd64 free implementation of the EGL API -- Mesa vendor library
ii libgl1-mesa-dev:amd64 20.0.4-2ubuntu1 amd64 transitional dummy package
ii libgl1-mesa-dri:amd64 20.0.4-2ubuntu1 amd64 free implementation of the OpenGL API -- DRI modules
ii libglapi-mesa:amd64 20.0.4-2ubuntu1 amd64 free implementation of the GL API -- shared library
ii libglu1-mesa:amd64 9.0.1-1build1 amd64 Mesa OpenGL utility library (GLU)
ii libglu1-mesa-dev:amd64 9.0.1-1build1 amd64 Mesa OpenGL utility library -- development files
ii libglx-mesa0:amd64 20.0.4-2ubuntu1 amd64 free implementation of the OpenGL API -- GLX vendor library
ii mesa-utils 8.4.0-1build1 amd64 Miscellaneous Mesa GL utilities
ii mesa-va-drivers:amd64 20.0.4-2ubuntu1 amd64 Mesa VA-API video acceleration drivers
ii mesa-vdpau-drivers:amd64 20.0.4-2ubuntu1 amd64 Mesa VDPAU video acceleration drivers
ii mesa-vulkan-drivers:amd64 20.0.4-2ubuntu1 amd64 Mesa Vulkan graphics drivers
|
|
On the Intel platform:
and |
|
|
Interesting, when starting with with |
|
Last bunch of info: So it looks like a OpenCL version issue |
|
I'm puzzled why I get OpenGL 3 on my machine, while you get OpenGL 4.6 on yours - having the same mesa libs installed! |
|
To add to the confusion, on my nvidia machine, rviz works fine and it seems that I have openGL 4.6: About the different version between mine and your Intel machine, it may be because we have a different generation and also a different driver. I use the Intel NEO: https://github.com/intel/compute-runtime/releases |
|
That's not so surprising to me. I think we need to blame the 4.6 implementation of libmesa... |
|
@wjwwood, can you delegate this issue to an OpenGL expert? I neither have the experience nor the resources to handle this. |
|
I can ask @iche033 if he's got any ideas, but I don't know any opengl experts other than him (I'm certainly not one, haha). The other avenue would be to produce an example that using Ogre only and ask them about it. I'll see if I can allocate some time to help with that, but it will be a few weeks most likely as we're in the midst of our second release in so many weeks, and there will be fallout to contend with after. |
|
I do know that in my virtual machines I only have OpenGL 2.something, and that's not enough for Ogre any longer (it used to be) and so it throws when it cannot get a certain OpenGL function it needs. I don't think it's the same issue, but it is not the first time we've had issues with different opengl versions. |
|
Also, it might be worth trying to build rviz from source using the newer ogre version, as it might already be fixed by their abstraction layer? |
|
I have this issue when compiling on Focal from src and I believe it is ogre version 1.9 which is used: |
|
Yeah, we decided to stick with 1.9 for our debs, but 1.12 is also available via So you'd need to uninstall |
|
After compilation with ogre 1.12:
Rviz starts, then crash when trying to display a pointcloud:
|
|
Disappointing. I won't have time to look into this next week. |
I don't have a ubuntu 20.04 installed yet but on 18.04 with ogre 1.12.4 and noetic-devel it works Main difference between the glxinfo's you posted is that @rhaschke 's notebook from 2010 and my notebook from 2016 report OpenGL 3 compatibility profile while the one from @doisyg from 2018 talks only about OpenGL 4.6. So maybe someone found it clever to drop some compatibility mode (or maybe it needs to be requested differently/manually ...) Apple apparently does not support compatibility modes at all, I thought you're using that @wjwwood ? Seeing that --opengl 210 works, maybe we should default to that if something newer is found? ogre has a backend/ There's also a high-level shader system that would allow using all of the backends (Metal, DX11, ...) but I haven't understood how that works yet and if it can actually handle geometry shaders (and I'm not sure to what extend that's available in 2013's ogre 1.9) |
|
Given the fact that NVIDIA's OpenGL 4.6 renders correctly, while Mesa's not, I'm still tending to blame Mesa. @doisyg, could you have a look for issue reports over there? |
|
gave it a go with ogre 1.12....similar issues as before. cannot change size of points, but also rviz wasnt able to render any type other than |
|
strange...just relaunched rviz and I can now resize the points?? still getting the weird "no techniques available for material" error UPDATE: when I drag RVIZ to the right side of my screen to auto-size to half of the window the render of the points updates to their largest size and I am unable to resize them without restarting rviz UPDATE2: can confirm rviz works as expected when the entire rviz window is NOT full screen or half screen - aka just in the middle of the screen & not auto-sized. so strange |
|
@flynneva, did you also get a segfault the first time you started rviz? |
|
Does it work to manually resize the rviz window? |
|
@rhaschke randomly there is a segfault and rviz crashes, but most of the time it runs ok other than the material error shown above. and yes, manually resizing works great, its just the auto-sizing when I drag it to the right or to full screen when I am unable to resize the points. |
|
I can confirm that the issue of large points also occurs with xfce window manager, when window is auto-sized to 25%, 50%, or 100%. It is related to Mesa 20. It doesn't appear with nvidia OpenGL. Suggested workaround: Use squares instead of points. |
rhaschke
changed the title
|
Xubuntu 20.04, ros noetic, Intel cpu, nvidia gpu caught in the act: https://www.youtube.com/watch?v=F3vnVlUaqfc The size of the pixels seem to behave like "size=max(window width / 20,1)" Confirmed case: effect is reproducible 100% at different window sizes
The interesting thing is that this was working about a week ago, so something triggered the event, maybe an apt-get upgrade yesterday. To make sure there is no rviz config degradation, I've rolled back my repo (with the .rviz config) and I can confirm the same config that was working a week ago does not work now. dpkg log confirms that my update yesterday brought these new packages (I had it sorted by package name to help analyzing). Boxes vs points: rviz output at startup: nvidia packages mesa packages |
|
Thanks for the video. Actually, I observed a point size that varies non-linearly (in a sine-shaped fashion) with the window size (actually window height only). This definitely is an libMesa issue. Fixating the point size in the vertex script yields exactly the same (wrong) behavior. I confirm again that the nvidia driver is not affected. I comes at a surprise, that your (@Petrox) package update list doesn't show libmesa. I filed an issue upstream: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4506 |
|
@rhaschke My computer has been installed as 16.04, then upgraded to 18.04,and 20.04 so this is far from optimal in terms of package dependencies. Nevertheless here are my mesa related items from my /var/log/dpkg*gz files: |
A mesa update has triggered a bug in rviz on intel systems[0]. Doesn't seem like it'll get fixed soon, so this changes the default point display type to "flat squares." It doesn't look great close-up, but works reasonably well for visualizing sample data and room-sized scenes. * Also rearrange the rviz window config a bit to be more useful * Update published images to have 16-bit dpeth * Use the usual method ot fit range values into 16 bits * Rename intensity/ambient topics and variables in the img_node * Add reflectivity image output to the img_node [0] ros-visualization/rviz#1508 Approved-by: Chris Bayruns Approved-by: Pavlo Bashmakov
|
@rhaschke just an update here - i dug into this bug some more and realized it only happened when adjusting the height of the render window (3D viz). this happens when either closing out the bottom time panel or when adjusting the entire RVIZ window height. adjusting the width does not cause this bug (at least on my machine). not sure if this is helpful in tracking down the problem but I would guess that somewhere in the code where we calculate the pixel ratio based in height is where the bug is. also, just a note that this bug also affects rviz2 right now. im debugging there now with galactic since the example pointcloud publisher package was released for galactic |
|
also one interesting note is that this bug does not appear to affect rviz2 on windows (renders pointclouds as expected) but does affect rviz2 on ubuntu. |
|
@flynneva: thanks for this update. See #1508 (comment). |
|
Idea (just guessing) :
- virtual desktop size differs from screen size
- maybe the problem is not about the window height but about getting the
screen height right
- maybe it is a race condition (using a previous window size while a new
value is the correct one)
- maybe in relation to the window being fullscreen or not
I do not know the internals just thinking out loud.
…On Fri, Jun 18, 2021, 00:21 Evan Flynn ***@***.***> wrote:
also one interesting note is that this bug *does not* appear to affect
rviz2 on windows (renders pointclouds as expected) but does affect rviz2 on
ubuntu.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1508 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAXFKXIFRPDWMKVKAW3URTTTTJYNZANCNFSM4NLK4JNQ>
.
|
|
@flynneva: thanks for reinforcing the mesa opengl issue. |
|
@rhaschke made some good progress over on the mesa opengl issue. it looks like somewhere in the call stack the height of the viewport is being used to set the size of the point. that should explain the symptoms i think, now its just a question of figuring out where this is happening. |
|
@rhaschke so im not sure when i installed my last lib mesa update but this bug seems to be fixed now. I can adjust the height and the points now do not explode in size. can anyone else confirm that its fixed on their machines as well? EDIT: my version of mesa is: EDIT2: and printout for |
|
I confirm that the issue is gone with |
|
@rhaschke @flynneva If i run OccupancyMap in Rviz, i see core dumped in terminal:
|
|
@muratkoc503, I think this is a new. Please create a new issue and exactly describe your setting, i.e.
|
|
@rhaschke, thanks and sorry. this is relating to octomap. i solved this problem. |
A mesa update has triggered a bug in rviz on intel systems[0]. Doesn't seem like it'll get fixed soon, so this changes the default point display type to "flat squares." It doesn't look great close-up, but works reasonably well for visualizing sample data and room-sized scenes. * Also rearrange the rviz window config a bit to be more useful * Update published images to have 16-bit dpeth * Use the usual method ot fit range values into 16 bits * Rename intensity/ambient topics and variables in the img_node * Add reflectivity image output to the img_node [0] ros-visualization/rviz#1508 Approved-by: Chris Bayruns Approved-by: Pavlo Bashmakov
looks like in the noetic rviz release there seems to be a bug when you try to change the point size for pointcloud2 topics.
Here is a screenshot of the default pointcloud points that show up when I add in the viz, and yes I have tried to change the type/size of it:
Your environment
The text was updated successfully, but these errors were encountered: