VMWare rendering: Z Ordering Appears Random #1837
Comments
|
Original comment by Xander Dunn (Bitbucket: xanderdunn).
|
1 similar comment
|
Original comment by Xander Dunn (Bitbucket: xanderdunn).
|
|
Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters). Can you share the world and model files that you are using? |
|
Original comment by Xander Dunn (Bitbucket: xanderdunn). Here is a simple scene where we reproduce the problem. It's a table, bookshelf, and soda can. In this screenshot of the Gazebo GUI, you can see the scene rendered properly: The soda can is closest to the camera, the bookshelf is next, and finally a table is furthest away from the camera. However, when this scene is captured as an image through the in-scene camera object, it's not rendered correctly: The objects don't seem to be in the correct order. The table certainly shouldn't be seen going through the bookshelf. Note that the examples I showed above of the pendulum and acrobot were also using the in-scene camera. Thanks! |
|
Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters). which version of gazebo are you using? I just tried opening that world with the latest version of gazebo built from source, and it doesn't have this error (actually I modified the camera position slightly so the camera visual wouldn't overlap the bookshelf) I wonder if the OS / video card / video driver may have an effect as well |
|
Original comment by Xander Dunn (Bitbucket: xanderdunn). Thanks for testing! We're using ROS Indigo, so we're using the compatible Gazebo 2. The issue is identical across three different setups: Mac OSX 10.11 MacBook Pro, Ubuntu 14.04 MacBook Pro, and Ubuntu 14.04 AWS c4 instances. It's strange that it always renders correctly in the Gazebo GUI but often not in scene camera output. Considering the age of gazebo 2 and the fact that it doesn't reproduce on latest, perhaps it's since been fixed. We're hoping to figure out some solution for current stable ROS. |
|
Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters). You can try using the I'll try testing with an older version of gazebo as well |
|
Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters). It works properly for me with gazebo5 on trusty |
|
Original comment by Daniele E. Domenichelli (Bitbucket: drdanz). I cannot reproduce it all the times, but I can confirm this bug on gazebo 6.5.1 on ubuntu trusty from the repository (6.5.1-1~trusty). Here's a couple of screenshots |
|
Original comment by Nate Koenig (Bitbucket: Nathan Koenig). Your problem may be associated with vmware. We have never had great experiences using virtual machines and offscreen rendering. |
|
Original comment by Ian Chen (Bitbucket: Ian Chen, GitHub: iche033). I've also been testing this but couldn't reproduce the problem. It could be what @nkoenig said about problem with running gazebo in a VM. Otherwise, what graphics card and driver are you using? Gazebo has been tested most on nvidia cards. |
|
Original comment by Xander Dunn (Bitbucket: xanderdunn). Many thanks @iche033, @nkoenig, and @drdanz for your input. Yes, we were able to reproduce the issue in Gazebo 6.5.1 on Trusty. We are indeed running Gazebo in a virtual machine. We've tried in both VMWare and VirtualBox. In Virtual Box we used a virtual frame buffer with software GL. In VMWare we used the driver provided by VMWare. We can try running it on a physical Ubuntu machine, but ultimately this will be a problem for high performance computing since we deploy everything as Docker containers onto Amazon Web Services machines. As @drdanz noticed, we don't see this all the time. We see it in approximately half of our runs, where a single run consists of starting up Gazebo a single time. Any given run will either always or never show the issue. |
|
Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters). There are AWS instances with GPU's that we have used with gazebo, though they are more expensive. @hugomatic know the most on this subject. |
|
Original comment by Xander Dunn (Bitbucket: xanderdunn). Testing locally on a MacBook Pro with an nvidia card running Gazebo in VMWare with graphics acceleration still shows the issue, so the AWS instance type alone isn't likely to solve it. |
|
Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters). I meant that you could run gazebo natively on the AWS Ubuntu instance. You can also run gazebo natively on your Macbook. Have you tried these instructions: |
|
Original comment by Xander Dunn (Bitbucket: xanderdunn). Yes, we will test running it directly, outside of the virtual machine. The difficulty is scaling this across tens of thousands of Amazon runs. Everything inside virtual machines is the standard practice. |
|
Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).
|
|
Original comment by Christian Rose (Bitbucket: toxcjr). I would like to add, that I have this issue also with gazebo6 running native in ubuntu 14.04. So from my side, the virtual machine is not the problem. The exact setup is working on my second laptop with out problems. Maybe there is so issue with the gpu used. Here is a picture from gazebo: And this is the display from rviz: As you can see the blue barrel is missing and the floor looks strange. |
|
Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters). @toxcjr can you describe your hardware setup that has this problem? You said it is running Ubuntu natively; what is the video card and driver? Also, perhaps the output of |
|
Original comment by Christian Rose (Bitbucket: toxcjr). Hi. I'm running ubuntu 14.04 native on a toshiba laptop:
This is the glxinfo output: lshw -c video | grep 'configuration' gives: So i would say the system uses the intel i915 driver. Let me know what you need more. |
|
Original comment by Christian Rose (Bitbucket: toxcjr). Hi, is there anything I can do to get further help with this issue? Please let me know. Best regards Christian |
|
Original comment by Christian Rose (Bitbucket: toxcjr). It is a z-ordering problem. I placed the robot on the other side and checked the blue barrel. The result is this: With the robot facing the lower barrel in this setup: As you can see the blue barrel is not visible in the image shown in rviz. As next step I removed the wall in front of the robot. This is the view in gazebo: The output in rviz shows this: So the blue barrel is not gone, the ordering of the objects is wrong. Hope this helps. |
|
Original comment by Xander Dunn (Bitbucket: xanderdunn). One of our engineers discovered that setting Before: After setting |
|
Original comment by Ian Chen (Bitbucket: Ian Chen, GitHub: iche033). That's a good find, thanks for letting us know! Sorry haven't been able to spend much time digging into this issue. I'll look into exposing the fsaa setting via a public function like |
|
Original comment by Shridhar Shah (Bitbucket: skshah). I was also facing the same issue. This is the link to my post. Thanks for providing a solution. I tried to build Gazebo 2.2.6 (as it ships with ROS Indigo, which I am trying to fix) with the above change but it did not resolve the issue. Is it possible that his resolution only works in newer versions of gazebo? |
|
Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters). @iche033 is it alright if we assign this issue to you? |
|
Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).
thanks Ian! |
|
Original comment by Ryan McNulty (Bitbucket: rmmcnulty9). @iche033, do you have any updates on this? I am seeing the same problem as @sk1234 on Gazebo 7.0.0 from the PPA. For my application, I don't think I would be able to compile from source. It would be nice to be able to set Thanks! |
|
Original comment by Ian Chen (Bitbucket: Ian Chen, GitHub: iche033). @safijari if you like, you can submit a pull request to gazebo_tutorials to fix the instructions This is the file to edit |
|
Original comment by vkpetkov (Bitbucket: vkpetkov). For me Gazebo 2 was not running with 3D Acceleration in VMWare at all whereas 7 was OK. But I fixed it by following the advice of Hugo Rodde: "I had the same issue trying to use Gazebo along with ROS." My solution was to downgrade OpenGL from 3.3 to 2.1 as written here: http://www.mesa3d.org/vmware-guest.html Info:
[quote] So do the following: I will have to check whether this helps with the z-rendering error in gazebo 2. |
|
Original comment by Jariullah Safi (Bitbucket: safijari). That unfortunately does not fix the problem for Gazebo 2 (Ubuntu 14.04) on my end unfortunately. I also tried it with Gazebo 7 (Ubuntu 16.04, alongside Kinetic) and I get the following error Unfortunately the mentioned log file doesn't seem to exist :\ |
|
Original comment by Hans Dermot Doran (Bitbucket: HDoran). Does anyone have a compiled version with this fix available for download? Would it not be possible to make a source code branch for VM users? |
|
Original comment by Nate Koenig (Bitbucket: Nathan Koenig). The fix is in the gazebo 7.4.0 debian. Can you try that? |
|
Original comment by Nate Koenig (Bitbucket: Nathan Koenig).
Resolved in pull request #2449. |
|
Original comment by Baris Ustun (Bitbucket: bustun). Hi, I am new to ubuntu. I've installed gazebo using 'sudo apt-get install ros-kinetic-desktop-full'. it installed version 7.0. |
|
Original comment by Sharvashish Das (Bitbucket: SRV_kgp). @bustun by default the gazebo version 7.0.0 is installed when installed via ROS-kinetic. Follow this link: http://gazebosim.org/tutorials?tut=install_ubuntu to install latest gazebo binary. |
|
Original comment by Baris Ustun (Bitbucket: bustun). ok. I installed it. thanks |
|
Original comment by Nate Koenig (Bitbucket: Nathan Koenig). Let us know if it works, or does not work. |
|
Original comment by Baris Ustun (Bitbucket: bustun). I managed to install. and the camera view appeared in Rviz. |
|
Original comment by Jordan Liviero (Bitbucket: jliviero). Worked for us @nkoenig. Prior to fix: Post-fix: Note the floating objects behind the dumpster, which are visible prior but not visible post. Also, the textures on those floating objects are now rendered, when they were not previously. Good work! |
|
Original comment by Nate Koenig (Bitbucket: Nathan Koenig).
Confirmed by reporters. |
|
Original comment by Gonzalo Bulnes Guilpain (Bitbucket: gonzalo-bulnes). Hi everyone, TL;DR: I can confirm that installing Gazebo 7.4.0 solves the issue. Details: I was running Gazebo 7.0.0 and ROS Kinetic in an Ubuntu 16.04 virtual machine (VirtualBox 5.0.28, on a OS X 10.11.3 host). And Gazebo was crashing when I tried to # Terminal 1
roslaunch turtlebot_gazebo turtlebot_world.launch # requires the ros-kinetic-turtlebot-gazebo Ubuntu package
# Terminal 2
rostopic echo /cmd_vel_mux/input/teleop # outputs the motion commands as expected
---
linear:
x: 0.5
y: 0.0
z: 0.0
angular:
x: 0.0
y: 0.0
z: 0.0
---
linear:
x: 0.0
y: 0.0
z: 0.0
angular:
x: 0.0
y: 0.0
z: 0.0
rostopic echo /clock # outputs the simulated clock ticks as expected
---
clock:
secs: 1009
nsecs: 200000000
---
clock:
secs: 1009
nsecs: 210000000
---
clock:
secs: 1009
nsecs: 220000000
rostopic list | grep depth/
/camera/depth/camera_info
/camera/depth/image_raw
/camera/depth/points
# But trying to echo any camera-related topic outputs:
rostopic echo /camera/rgb/camera_info
WARNING: no messages received and simulated time is active.
Is /clock being published?
# and also crashes Gazebo in Terminal 1 with the following error message:
gzserver: /build/ogre-1.9-mqY1wq/ogre-1.9-1.9.0+dfsg1/OgreMain/src/OgreRenderSystem.cpp:546: virtual void Ogre::RenderSystem::setDepthBufferFor(Ogre::RenderTarget*): Assertion `bAttached && "A new DepthBuffer for a RenderTarget was created, but after creation" "it says it's incompatible with that RT"' failed.
Aborted (core dumped)
[gazebo-2] process has died [pid 21993, exit code 134, cmd /opt/ros/kinetic/lib/gazebo_ros/gzserver -e ode /opt/ros/kinetic/share/turtlebot_gazebo/worlds/playground.world __name:=gazebo __log:=/home/gonzalo/.ros/log/ab0fead6-9d94-11e6-9ddc-0800273ffca9/gazebo-2.log].
log file: /home/gonzalo/.ros/log/ab0fead6-9d94-11e6-9ddc-0800273ffca9/gazebo-2*.logI arrived here following from [the same issue as @SRV_kgp][orig] (see [comment above][similar]) and I can confirm that installing Gazebo 7.4.0 (using Ubuntu packages, no manual compilation needed) solves the issue. Many thanks to everyone involved! [similar]: https://osrf-migration.github.io/gazebo-gh-pages/#!/osrf/gazebo/issues/1837/vmware-rendering-z-ordering-appears-random (#1837)#comment-29498034 |
|
Original comment by Arnold Asllani (Bitbucket: asllani94). I am having this bug. I am using Ubuntu 16.04 on a dual boot not in virtual machine. How can I solve this without running. I am using Gazebo with ROS Kinetic and recompiling would be tough solution. |
|
Original comment by Freek Hoekstra (Bitbucket: hoekstrafg). @asllani94 how did you install Gazebo 7.4.0 using Debian packages? |
|
Original comment by Louise Poubel (Bitbucket: chapulina, GitHub: chapulina). @hoekstrafg , see the instructions on installing from OSRF packages here: http://gazebosim.org/tutorials?cat=install&tut=install_ubuntu&ver=7.0#Alternativeinstallation:step-by-step |
|
Original comment by Freek Hoekstra (Bitbucket: hoekstrafg). Thank you! |
Original report (archived issue) by Xander Dunn (Bitbucket: xanderdunn).
We have two simulations in Gazebo: A pendulum and an acrobot.
We have the simulations arranged such that the arms are facing the camera. However, at runtime it appears random what ordering the links are actually rendered at. Without making any changes, if the simulation is started many times, each run of the simulation will start with an unpredictable ordering.
From one run, here you can see a pendulum with an expected ordering:
The black link of the pendulum is in front of the brown post.
Randomly, on different runs, we'll see the opposite configuration, where the black link is rendered behind the brown post:
With an acrobot, that has more parts in the Z direction, there end up being more unpredictable outcomes. Here's one example:
The dark blue link is the top link (drawn behind the post). The bottom link is light blue, drawn in front of the post. This configuration of parts is physically impossible.
The text was updated successfully, but these errors were encountered: