Fix compatiblity problems with OGRE 1.12 release #1252

ProfFan · 2018-06-07T13:53:37Z

This PR is based on @de-vri-es 's amazing work(PR #1242). I tested extensively on Melodic and MoveIt!, and fixed several runtime errors related to resource handling.

TODO:

~~Interact function is not working (at least for me on Arch Linux with GNOME 3)~~ Fixed by 2ce1c5e
Multiple [ERROR] [1528378902.538022886]: Can't assign material Triangle List Marker2Material to the ManualObject Triangle List Marker2 because this Material does not exist in group General. Have you forgotten to define it in a .material script? errors, still need investigation.

de-vri-es · 2018-06-07T16:33:30Z

Hi, I appreciate the work you put in, and I appreciate the mention here, but the real credit is in the authorship information in the git commits.

If you want to incorporate my work in your PR, you can, but then please do preserve the git history of my commits. The best option is to simply branch of from my PR. If you rebase on my branch, that should solve the issue.

wjwwood · 2018-06-07T18:08:43Z

@ProfFan Yes, please preserve change attribution by forking @de-vri-es's branch if you want to build on top of his work.

ProfFan · 2018-06-08T01:43:32Z

@de-vri-es @wjwwood Sorry for the confusion here :) I assumed that maintainers would first merge @de-vri-es 's PR, and then this one :) Will rebase.

ProfFan · 2018-06-08T04:50:23Z

The interaction and selection tools are working now.

de-vri-es · 2018-06-08T20:43:17Z

Thanks for rebasing! I can probably find time for a preliminary review soon.

de-vri-es · 2018-06-08T20:45:01Z

src/rviz/ogre_helpers/movable_text.cpp

@@ -105,14 +105,14 @@ void MovableText::setFontName(const String &fontName)
    Ogre::MaterialManager::getSingleton().remove(mName + "Material");
  }

-  if (mFontName != fontName || mpMaterial.isNull() || !(mpFont.get()))
+  if (mFontName != fontName || mpMaterial.isNull() || mpFont.isNull())


Why did you swap away from !ptr.get()? As far as I could tell, that is the only non-deprecated way of testing for nullptrs in all Ogre versions. (The parenthesis really isn't necessary though.)

Hmm this is to make the CI happy and to make the code look consistent. I can change all .isNull() calls to .get()s as .isNull() looks really non-standard.

How exactly does CI get unhappy about !mpFont.get()? I've added a similar check before without CI complaining.

de-vri-es · 2018-06-08T20:48:08Z

CMakeLists.txt

@@ -8,6 +8,10 @@ if (POLICY CMP0054)
  cmake_policy(SET CMP0054 NEW)
 endif()

+if (POLICY CMP0072)
+  cmake_policy(SET CMP0072 NEW)


Does this solve any problems, or is it just to silence warnings from CMake >= 3.11.3?

I think GLVND is the standard now, as it supports both mesa and Nvidia GL libs. With a if (POLICY) statement here it should not do anything bad on older systems.

Fair enough. Maybe a comment to explain what it does would be nice. I know the rest of the file doesn't have it, but it's probably still a good idea.

de-vri-es · 2018-06-08T20:48:47Z

ogre_media/fonts/liberation_sans.fontdef

@@ -1,4 +1,4 @@
-Liberation Sans
+font "Liberation Sans"


Nice catch! The broken font had me going insane for quite a while.

de-vri-es · 2018-06-08T20:51:23Z

src/rviz/default_plugin/markers/mesh_resource_marker.cpp

@@ -69,18 +69,18 @@ void MeshResourceMarker::reset()
    entity_ = 0;
  }

-
+  // If we use SharedPtr then there will be no need for manual deletion


Are the materials also unloaded from the resource manager when the last shared_ptr is destroyed?

If this works properly, you should probably remove the code entirely rather than comment it out.

I kept it there intentionally for people to facilitate reviewing. Will remove if it looks good.

Right, so does the Ogre documentation shed any light on what happens when the shared material pointer go out of scope? Does it indeed unload the materials from the manager, or are we still leaking them?

de-vri-es · 2018-06-08T20:51:49Z

src/rviz/default_plugin/markers/triangle_list_marker.cpp

-    material_->unload();
-    Ogre::MaterialManager::getSingleton().remove(material_->getName());
+    // material_->unload();
+    // Ogre::MaterialManager::getSingleton().remove(material_->getName());


Same here, if this works as intended, better just remove the code entirely.

de-vri-es · 2018-06-08T20:55:47Z

src/rviz/mesh_loader.cpp

@@ -441,6 +442,9 @@ void loadMaterials(const std::string& resource_path,
  {
    std::stringstream ss;
    ss << resource_path << "Material" << i;
+
+    // Prevent loading a material twice
+    if(Ogre::MaterialManager::getSingleton().getByName(ss.str()).get() != NULL) continue;


Aren't the resource names unique anyway? Besides, it seems unlikely that this check would ever trigger, since you're not passing the resource group name to getByName.

getByName defaults to ResourceGroupManager::AUTODETECT_RESOURCE_GROUP_NAME I think. This piece of code is here because in my tests Ogre panics here saying that you cannot have resources with the same name. Needs more testing though.

Ah, I see. That's odd because in some places the default changed to DEFAULT_RESOURCE_GROUP_NAME (see [1]), but it seems they didn't update the defaults everywhere..

Still, it would be good to know in what situation there are duplicate material names and if we can safely skip creation then.

Slight detail, but stringstream.str() creates a copy of the internal buffer. It may be better to call it once and reuse the same copy.

[1] https://github.com/OGRECave/ogre/blob/630fe20d7e274d8cd17645911aa0a8121533be26/OgreMain/include/OgreResourceGroupManager.h#L48-L54

de-vri-es · 2018-06-08T20:58:44Z

src/rviz/mesh_loader.cpp

+        return thisfont.staticCast<Ogre::Mesh>();
+      }
+    }
+  }


In what situation does getByName return false? Shouldn't this be fixed by passing the correct resource group name to getByName instead?

The name fonts and thisfont also seem somewhat misleading. They're meshes, right?

Silly me forgot to change the names when copy-pasting code. Will fix :)

Also see the previous comment.

de-vri-es · 2018-06-08T21:01:04Z

src/rviz/ogre_helpers/movable_text.cpp

-    if (!mpFont)
+        = FontManager::getSingleton().getByName(mFontName);
+
+    // Workaround for getByName bug


Could this be fixed by passing the correct resource group to getByName instead?

Good idea, will test :)

de-vri-es · 2018-06-08T21:03:20Z

src/rviz/selection/forwards.h

@@ -76,6 +76,10 @@ inline uint32_t colorToHandle(Ogre::PixelFormat fmt, uint32_t col)
  {
    handle = col >> 8;
  }
+  else if (fmt == Ogre::PF_R8G8B8)


Maybe add another or-clause to the first if?

Here is also for consistency I think.

Well, the first if statement does exactly the same as this one and already has two conditions. But it doesn't matter much I suppose.

de-vri-es · 2018-06-08T21:05:11Z

src/rviz/selection/selection_handler.cpp

@@ -214,7 +215,7 @@ void SelectionHandler::destroyBox(const std::pair<CollObjectHandle, uint64_t>& h
    Ogre::WireBoundingBox* box = it->second.second;

    node->detachAllObjects();
-    node->getParentSceneNode()->removeAndDestroyChild(node->getName());
+    if(node->getName().length() > 0) node->getParentSceneNode()->removeAndDestroyChild(node->getName());


Won't this leak anonymous nodes?

In other places I replaced removeAndDestroyChild(node->getName()) with:

node->getParentSceneNode()->removeChild(node); node->getCreator()->destroySceneNode(node);

Thanks for the suggestion. Will test.

de-vri-es · 2018-06-08T21:10:20Z

I had a crazy idea (maybe), but since the maintainers currently don't have the time for reviewing, would it be an idea to send your PR to my branch for #1242 (https://github.com/fizyr-forks/rviz/tree/ogre1.11)?

That way we can at least consolidate efforts on fixing Ogre 1.11 compatibility. Right now I need some of your fixes to continue on my branch, and if I change my branch, yours may not merge cleanly anymore.

Authorship information will of course be preserved for your commits as well if we do this.

@ProfFan, @wjwwood: thoughts?

ProfFan · 2018-06-09T06:06:40Z

@de-vri-es LGTM :)

ProfFan · 2018-06-09T06:13:54Z

@de-vri-es Plus I think you should also rebase your branch on origin/melodic-devel

de-vri-es · 2018-06-09T08:29:05Z

@de-vri-es Plus I think you should also rebase your branch on origin/melodic-devel

It is based on melodic-devel, isn't it?

ProfFan · 2018-06-09T09:51:24Z

It is based on melodic-devel, isn't it?

PR sent

rhaschke · 2019-03-07T18:20:51Z

Dear @ProfFan,
as suggested in #1252 (comment) and in #1242 (comment), I would like you to cooperate with @de-vri-es to consolodate all changes into #1242 and then close this PR.
Thanks.

hgaiser · 2019-06-25T13:03:00Z

There were a few "new" commits (end of 2018) in https://github.com/ros-visualization/rviz/pull/1242/commits , could you incorporate them in this PR? I think https://github.com/ros-visualization/rviz/pull/1242/commits can be closed since this PR supersedes that PR?

ProfFan · 2019-06-25T14:13:10Z

@hgaiser I think I have sent a PR to @de-vri-es 's branch and he has not responded to that one yet. Since I think you two are working in the same company can you brief us on the current situation? Many thanks!

hgaiser · 2019-06-26T07:43:17Z

@hgaiser I think I have sent a PR to @de-vri-es 's branch and he has not responded to that one yet. Since I think you two are working in the same company can you brief us on the current situation? Many thanks!

Ah I see. Unfortunately we don't have time to work on this issue anymore. I would suggest to try to merge this with feedback from the rviz maintainers instead.

ProfFan · 2019-06-26T11:18:52Z

@rhaschke @hgaiser I will start merging the changes here. However I am currently in the process of moving to another institution so expect some delays.

ProfFan · 2019-08-23T16:27:35Z

Now that I have finished moving I'll get this going #mark

Because it breaks with strict resource manager mode in Ogre 1.11.

This was split off to a plugin in Ogre 1.11, and is required for decoding PNG textures.

The program compiler in Ogre 1.11 does not seem to resolve relative paths anymore.

In Ogre 1.11 deleting an anonymous node by name triggers an assertion failure.

Mesh files can't seem to specify the resource group for a material, so this is a relatively simple workaround.

The old signals library has been removed from boost 1.69. Because of that, find_package(Boost COMPONENTS signals ...) doesn't work anymore. The newer signals2 library is header only and does not need to be listed as boost component at all.

ProfFan · 2019-09-17T18:26:32Z

Rebased to latest melodic-devel. Need testers :)

ProfFan · 2019-09-19T13:33:14Z

SIP processing in Catkin is a bit broken on macOS. @rhaschke What is your stance on putting in workarounds in the repo?

rhaschke · 2019-09-19T14:55:52Z

If SIP is broken I would prefer a fix in the package python_qt_binding - if that's possible.

rhaschke · 2019-09-19T14:57:23Z

By the way, many thanks for your efforts working on this PR. I hope to release rviz on this weekend and then this PR will become my top priority item for rviz.

hgaiser · 2019-09-19T15:12:04Z

Is it this that broke in sip ?

ProfFan · 2019-09-19T18:36:08Z

@hgaiser Similar but not exactly. build_sip_binding will blindly pass the rviz_LIBRARIES variable to the linker, which does not account for differences between a framework (folder, -framework) and a dylib. Still figuring out the best way to get around it, but either way, python_qt_binding is the culprit.

ProfFan · 2019-09-19T18:37:36Z

Will now push the WIP here so you can see the problem.

ProfFan · 2019-10-01T16:25:46Z

Looks like travis is broken. Ping @rhaschke can you help reviewing this PR and also tests against other targets (Flavors of Linux, etc.)?

rhaschke · 2019-10-04T10:00:31Z

Closing in favor of #1434. @ProfFan, unfortunately, most of your additional commits (on top of #1242) were kind of work-arounds. I hope, I found proper solutions for the remaining issues (e.g. selection) in #1434. If you think that some of your changes are missing nonetheless, please file them in a new PR against noetic-devel. Thanks a lot for your effort!

ProfFan force-pushed the melodic-devel branch from e055c37 to a28ce77 Compare June 8, 2018 02:09

ProfFan force-pushed the melodic-devel branch from 9a2dc98 to 18a3897 Compare June 8, 2018 06:45

de-vri-es reviewed Jun 8, 2018

View reviewed changes

Germanunkol mentioned this pull request Jul 8, 2018

Huge changeset fizyr-forks/rviz#1

Closed

majorx234 mentioned this pull request Aug 8, 2018

rviz on Ogre 1.11 Map not displayed #1277

Closed

rhaschke mentioned this pull request Mar 7, 2019

Fix compatibility with Ogre 1.11 #1242

Closed

rhaschke added the changes requested label Mar 7, 2019

rhaschke mentioned this pull request Aug 31, 2019

[WIP] rviz on Ogre 1.11 #1251

Closed

de-vri-es added 6 commits September 17, 2019 12:57

Add compatibility header for setting materials in OGRE 1.8 to 1.11+.

084fe73

Don't try to remove unknown materials in destructors.

9d8865c

Because it breaks with strict resource manager mode in Ogre 1.11.

Load Codec_STBI plugin for Ogre 1.11 and later.

acb1d01

This was split off to a plugin in Ogre 1.11, and is required for decoding PNG textures.

Fix shader programs for Ogre 1.11 by avoiding relative paths.

e2bf359

The program compiler in Ogre 1.11 does not seem to resolve relative paths anymore.

Avoid referring to anonymous scene nodes by name.

e1c075c

In Ogre 1.11 deleting an anonymous node by name triggers an assertion failure.

Use proper resource group name when setting materials.

7158dc7

de-vri-es and others added 15 commits September 17, 2019 12:57

Add a BaseWhiteNoLighting to the rviz resource group for loaded meshes.

854849f

Mesh files can't seem to specify the resource group for a material, so this is a relatively simple workaround.

OGRE 1.11 Resources Changeset

48e6dd2

Use libglvnd on newer systems

0b8cbe6

Change raw pointers to SharedPtr

f695ce2

Remove unnecessary ROS_DEBUG

162666b

Fix the interaction and selection tool under ogre1.11

ec87bce

Fix crash when interactive marker are bounded

415ed68

Make the CI happy

bddcb97

Fix crash on deselection

41965d7

Ogre < 1.11 compatibility

91a4870

More compatibility fixes

1b498f6

Follow ogre 1.10 conventions

61e260e

Use OgrePrequisites.h for forward declarations.

a57d73f

Find rviz package for python bindings.

ed01e46

Fix compatibility with boost 1.69.

62803f8

The old signals library has been removed from boost 1.69. Because of that, find_package(Boost COMPONENTS signals ...) doesn't work anymore. The newer signals2 library is header only and does not need to be listed as boost component at all.

ProfFan force-pushed the melodic-devel branch from 07cd9c5 to 62803f8 Compare September 17, 2019 18:24

ProfFan changed the title ~~Fix compatiblity problems with OGRE 1.11 release~~ Fix compatiblity problems with OGRE 1.12 release Sep 19, 2019

ProfFan added 2 commits September 19, 2019 14:38

Add missing OGRE import

8f0a7df

Dirty workaround for SIP linking bug

2bfc636

rhaschke closed this Oct 4, 2019

Fix compatiblity problems with OGRE 1.12 release #1252

Fix compatiblity problems with OGRE 1.12 release #1252

Conversation

ProfFan commented Jun 7, 2018 • edited Loading

de-vri-es commented Jun 7, 2018

wjwwood commented Jun 7, 2018

ProfFan commented Jun 8, 2018

ProfFan commented Jun 8, 2018

de-vri-es commented Jun 8, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

de-vri-es Jun 8, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

de-vri-es Jun 9, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

de-vri-es commented Jun 8, 2018

ProfFan commented Jun 9, 2018

ProfFan commented Jun 9, 2018

de-vri-es commented Jun 9, 2018

ProfFan commented Jun 9, 2018

rhaschke commented Mar 7, 2019

hgaiser commented Jun 25, 2019

ProfFan commented Jun 25, 2019

hgaiser commented Jun 26, 2019

ProfFan commented Jun 26, 2019

ProfFan commented Aug 23, 2019

ProfFan commented Sep 17, 2019

ProfFan commented Sep 19, 2019

rhaschke commented Sep 19, 2019

rhaschke commented Sep 19, 2019

hgaiser commented Sep 19, 2019

ProfFan commented Sep 19, 2019

ProfFan commented Sep 19, 2019

ProfFan commented Oct 1, 2019

rhaschke commented Oct 4, 2019

ProfFan commented Jun 7, 2018 •

edited

Loading

de-vri-es Jun 8, 2018 •

edited

Loading

de-vri-es Jun 9, 2018 •

edited

Loading