Could not open gazebo gui (ogre 1.12 segfaults) #6
Comments
|
I remembered some preliminary tests did in robotology-legacy/gym-ignition#279, where a specific ogre version was necessary. There, I was building the entire colcon workspace using dependencies provided by a conda environment. Downgrading ogre to the functioning version I reported, ogre does not segfault. Here below the environment changes. |
traversaro
changed the title
|
Thanks @diegoferigo, indeed we are building the Ignition libraries for both Ogre 1.10 and 1.12 at the moment, so I updated the title. |
|
Related issue: conda-forge/libignition-rendering4-feedstock#13 . |
|
The same problem happens with libignition-gazebo6 with ogre 1.12, while with ogre 1.10 works fine. Based on an old Gazebo issue ( gazebosim/gazebo-classic#2700 ) the fix seems just to add the correct missing directories to at least Ignition Gazebo starts. |
|
Cool - should we just amend the activation script to fix this issue? |
|
Yes, I actually wanted to check on a real Linux machine if that permitted to get ign gazebo to work, as ign gazebo on its own does not work on macOS or Windows, but I guess that also just fixing that aspect would not harm. |
|
In particular, Ign Gazebo seems to start, but it prints the following error: |
|
However, even on WSL2 I am able to see something with the same rendering artefacts I have with ogre 1.10, so I guess it is worth to add |
|
@Tobias-Fischer do you have any idea on how to modify the build script of |
|
I'm not sure at all. Do you want me to ask on gitter? |
Good idea. I tought we could also just always add being printed. Not sure if this actually influnce the rendering, as in WSL2 with Xming the rendering does not work correctly, not sure if it is due to the error: that is also printed. |
|
Actually thinking about it - can't we simply do something like this in the activate script? When activating the environment, the packages are installed so we can simply check if a desired file exists. This would only work for ogre==1.12 (not >=1.12) but it might be a good start? if compgen -G "$CONDA_PREFIX/lib/libOgreMain.so.1.12.*" > /dev/null; then
export IGN_RENDERING_RESOURCE_PATH=$IGN_RENDERING_RESOURCE_PATH:$CONDA_PREFIX/share/OGRE/Media
fi |
This is actually not true! Simple the default world does not render anything useful, so it is not clear if anything works. By running While just by setting indeed the rendering is not working correctly, I wonder if due to the shader problems mentioned in #6 (comment) :
|
|
Actually, I do not think that adding The point is that if you check the code (for example https://github.com/ignitionrobotics/ign-rendering/blob/c1b0a4112ae6e4dcb3bf3238022c7b6a33bba009/ogre/src/OgreRTShaderSystem.cc#L480) the |
|
Differently from Gazebo Classic, in which After doing so, indeed the error changes: This is indeed an error similar to gazebosim/gazebo-classic#2700 . However, thanks to the experience in gazebosim/gz-sim#1116, I discovered that for ogre errors once should check the |
|
Great investigative work! The ogre error to me looks like an upstream bug? |
I am not sure. If we go back to the similar Ogre 1.12 error for Classic Gazebo (issue gazebosim/gazebo-classic#2700) according to gazebosim/gazebo-classic#2700 (comment) the problem occured in the change from 1.12.4 to 1.12.5. But in https://github.com/robotology/robotology-superbuild-dependencies-vcpkg v0.7.0, I have a build of Gazebo that works fine with Ogre 1.12.9 built via vcpkg, without even adding anything to any env variable. What I noticed is that the vcpkg build of ogre does something strange with the (Note that the |
|
Hello. Is there any solution/fix to this problem? Setting |
|
@traversaro I'm working on the flat rendering issue. I've fixed the RT Shader issues (pending PR in the ms-iot org); and have shadows. But the unshaded rendering has been driving me bonkers for longer than I'd care to admit... |
|
ogre2/ogre-next is now working fine (see #27 (comment)), I think we can drop the ogre1.12 builds. The issue can be tackled if anyone wants to work on them. |
Issue:
Even after the fix I proposed in #4 (comment), the GUI fails to open. Note that running just the server seems working fine. Here below the runtime error:
Verbose output
Environment (
conda list):Details about
condaand system (conda info):The text was updated successfully, but these errors were encountered: