Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inertia visual #326

Merged
merged 22 commits into from
Jun 15, 2021
Merged

Inertia visual #326

merged 22 commits into from
Jun 15, 2021

Conversation

atharva-18
Copy link
Contributor

@atharva-18 atharva-18 commented May 24, 2021

🎉 New feature

Summary

Adds inertia visual to debug models.

Screenshot from 2021-06-03 12-23-56

Test it

I have added a sample called visualization_demo in the examples folder.

Checklist

  • Signed all commits for DCO
  • Added tests
  • Added example and/or tutorial
  • Updated documentation (as needed)
  • Updated migration guide (as needed)
  • codecheck passed (See contributing)
  • All tests passed (See test coverage)
  • While waiting for a review on your PR, please help review another open pull request to support the maintainers

Note to maintainers: Remember to use Squash-Merge

Signed-off-by: Atharva Pusalkar <atharvapusalkar18@gmail.com>
Signed-off-by: Atharva Pusalkar <atharvapusalkar18@gmail.com>
Signed-off-by: Atharva Pusalkar <atharvapusalkar18@gmail.com>
@github-actions github-actions bot added the 🏯 fortress Ignition Fortress label May 24, 2021
Signed-off-by: Atharva Pusalkar <atharvapusalkar18@gmail.com>
@codecov
Copy link

codecov bot commented May 24, 2021

Codecov Report

Merging #326 (42a6a41) into main (cbc35f8) will increase coverage by 0.02%.
The diff coverage is 57.89%.

Impacted file tree graph

@@            Coverage Diff             @@
##             main     #326      +/-   ##
==========================================
+ Coverage   57.91%   57.94%   +0.02%     
==========================================
  Files         162      166       +4     
  Lines       16162    16385     +223     
==========================================
+ Hits         9361     9494     +133     
- Misses       6801     6891      +90     
Impacted Files Coverage Δ
include/ignition/rendering/Scene.hh 0.00% <ø> (ø)
include/ignition/rendering/base/BaseScene.hh 0.00% <ø> (ø)
ogre/src/OgreInertiaVisual.cc 0.00% <0.00%> (ø)
ogre/src/OgreScene.cc 27.39% <0.00%> (-0.39%) ⬇️
...clude/ignition/rendering/base/BaseInertiaVisual.hh 72.00% <72.00%> (ø)
src/base/BaseScene.cc 75.36% <86.36%> (+0.40%) ⬆️
ogre2/src/Ogre2InertiaVisual.cc 91.56% <91.56%> (ø)
include/ignition/rendering/InertiaVisual.hh 100.00% <100.00%> (ø)
ogre2/src/Ogre2DynamicRenderable.cc 75.22% <100.00%> (+2.50%) ⬆️
ogre2/src/Ogre2Node.cc 92.04% <100.00%> (+0.09%) ⬆️
... and 7 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update cbc35f8...42a6a41. Read the comment docs.

Signed-off-by: Atharva Pusalkar <atharvapusalkar18@gmail.com>
@ahcorde ahcorde self-requested a review May 24, 2021 07:07
Copy link
Contributor

@ahcorde ahcorde left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some small comments in the code. Two more things:

  • Can you add some tests to these new classes?
  • Can you add an example in the example folder? I'm fine doing this in another PR and maybe include in the same example wireframes too. And potencially all the other new features.

include/ignition/rendering/InertiaVisual.hh Outdated Show resolved Hide resolved
ogre/include/ignition/rendering/ogre/OgreInertiaVisual.hh Outdated Show resolved Hide resolved
ogre/include/ignition/rendering/ogre/OgreInertiaVisual.hh Outdated Show resolved Hide resolved
ogre/src/OgreInertiaVisual.cc Show resolved Hide resolved
ogre2/src/Ogre2InertiaVisual.cc Outdated Show resolved Hide resolved
ogre2/src/Ogre2InertiaVisual.cc Outdated Show resolved Hide resolved
Signed-off-by: Atharva Pusalkar <atharvapusalkar18@gmail.com>
Signed-off-by: Atharva Pusalkar <atharvapusalkar18@gmail.com>
@scpeters
Copy link
Member

I was expecting to see a call to ignition::math::MassMatrix3::EquivalentBox as we do in osrf/gazebo's InertiaVisual::Load. How do you currently set the size of the inertia box?

@atharva-18
Copy link
Contributor Author

@scpeters The size of the inertia box is currently set in ign-gazebo's SceneManager.

Copy link
Contributor

@ahcorde ahcorde left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for adding the tests! Do you mind to change the status of the PR from Draft to a normal PR ?

Signed-off-by: Atharva Pusalkar <atharvapusalkar18@gmail.com>
@atharva-18
Copy link
Contributor Author

I have added a sample in the examples folder
views_demo

@atharva-18 atharva-18 marked this pull request as ready for review May 26, 2021 10:28
@atharva-18 atharva-18 requested a review from iche033 as a code owner May 26, 2021 10:28
Copy link
Contributor

@ahcorde ahcorde left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you mind to add support for windows ? Take a look to this PR #291

examples/views_demo/GlutWindow.cc Outdated Show resolved Hide resolved
examples/views_demo/Main.cc Outdated Show resolved Hide resolved
examples/views_demo/Main.cc Outdated Show resolved Hide resolved
examples/views_demo/Main.cc Outdated Show resolved Hide resolved
@scpeters
Copy link
Member

I was expecting to see a call to ignition::math::MassMatrix3::EquivalentBox as we do in osrf/gazebo's InertiaVisual::Load. How do you currently set the size of the inertia box?

@scpeters The size of the inertia box is currently set in ign-gazebo's SceneManager.

If this class doesn't actually take inertial parameters as direct inputs, I'm not sure it makes sense to call this class InertiaVisual. Currently it's just a box with 3 orthogonal lines. I think it will be easier to generate inertia visuals in other applications if we put the sizing logic in this class rather than require the downstream application to pass the pose and scale. For example, how about the following API?

virtual void Load(const ignition::math::Inertiald &_inertial);

Signed-off-by: Atharva Pusalkar <atharvapusalkar18@gmail.com>
Signed-off-by: Atharva Pusalkar <atharvapusalkar18@gmail.com>
@atharva-18
Copy link
Contributor Author

atharva-18 commented May 27, 2021

I was expecting to see a call to ignition::math::MassMatrix3::EquivalentBox as we do in osrf/gazebo's InertiaVisual::Load. How do you currently set the size of the inertia box?

@scpeters The size of the inertia box is currently set in ign-gazebo's SceneManager.

If this class doesn't actually take inertial parameters as direct inputs, I'm not sure it makes sense to call this class InertiaVisual. Currently it's just a box with 3 orthogonal lines. I think it will be easier to generate inertia visuals in other applications if we put the sizing logic in this class rather than require the downstream application to pass the pose and scale. For example, how about the following API?

virtual void Load(const ignition::math::Inertiald &_inertial);

I see. I think using math::inertiald also makes more semantic sense. Similar to Gazebo classic, we can call Load(const ignition::math::Inertiald &_inertial) which in turn calls Load(const ignition::math::Pose3d &_pose, const ignition::math::Vector3d &_scale) to create the visual. Thoughts @ahcorde?

@ahcorde
Copy link
Contributor

ahcorde commented May 28, 2021

@iche033 do you mind to take a look ?

@iche033
Copy link
Contributor

iche033 commented Jun 1, 2021

I see. I think using math::inertiald also makes more semantic sense. Similar to Gazebo classic, we can call Load(const ignition::math::Inertiald &_inertial) which in turn calls Load(const ignition::math::Pose3d &_pose, const ignition::math::Vector3d &_scale) to create the visual.

That sounds good to me. Looking at the implementation, I think one API suggestion is to call the function SetInertial(...) instead of Load(..) to indicate to the user that it is safe for this function to be called multiple times as opposed to be a once only thing on load.

examples/views_demo/CMakeLists.txt Outdated Show resolved Hide resolved
examples/views_demo/GlutWindow.cc Outdated Show resolved Hide resolved
examples/views_demo/GlutWindow.cc Outdated Show resolved Hide resolved
examples/views_demo/Main.cc Outdated Show resolved Hide resolved
include/ignition/rendering/base/BaseInertiaVisual.hh Outdated Show resolved Hide resolved
ignition::math::Vector3d s(0.5, 0.5, 0.5);
inertiaVisual->Load(p, s);

EXPECT_NE(nullptr, inertiaVisual->BoxVisual());
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can you expand the test to include other APIs like Material and OgreObject?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the methods to get Material and OgreObject are local to Ogre 1 and 2 classes only, similar to the LightVisual test and the Ogre1 LightVisual class

Signed-off-by: Atharva Pusalkar <atharvapusalkar18@gmail.com>
@scpeters
Copy link
Member

scpeters commented Jun 3, 2021

I see. I think using math::inertiald also makes more semantic sense. Similar to Gazebo classic, we can call Load(const ignition::math::Inertiald &_inertial) which in turn calls Load(const ignition::math::Pose3d &_pose, const ignition::math::Vector3d &_scale) to create the visual.

That sounds good to me. Looking at the implementation, I think one API suggestion is to call the function SetInertial(...) instead of Load(..) to indicate to the user that it is safe for this function to be called multiple times as opposed to be a once only thing on load.

I see that you added the SetInertial(...) method in 3456a69, nice work. I did notice that the content of OgreInertiaVisual::SetInertial is identical to Ogre2InertiaVisual::SetInertial. Since none of that code is ogre-specific, I would move it to BaseInertiaVisual<T>::SetInertial and not override the ogre SetInertial methods. What do you think @iche033?

@ahcorde
Copy link
Contributor

ahcorde commented Jun 3, 2021

Since none of that code is ogre-specific, I would move it to BaseInertiaVisual<T>::SetInertial and not override the ogre SetInertial methods.

+1

Signed-off-by: Atharva Pusalkar <atharvapusalkar18@gmail.com>
@atharva-18
Copy link
Contributor Author

I see that you added the SetInertial(...) method in 3456a69, nice work. I did notice that the content of OgreInertiaVisual::SetInertial is identical to Ogre2InertiaVisual::SetInertial. Since none of that code is ogre-specific, I would move it to BaseInertiaVisual<T>::SetInertial and not override the ogre SetInertial methods. What do you think @iche033?

I moved the content to BaseInertiaVisual<T>::SetInertial from the Ogre methods.

@atharva-18
Copy link
Contributor Author

One possible fix to the Ogre2 bug is to destroy all child visuals whenever BaseInertiaVisual<T>::Destroy is called

@@ -86,6 +89,17 @@ namespace ignition
       T::Init();
     }
 
+    //////////////////////////////////////////////////
+    template <class T>
+    void BaseInertiaVisual<T>::Destroy()
+    {
+      for (unsigned int i = this->ChildCount(); i > 0; --i)
+      {
+        this->ChildByIndex(i - 1)->Destroy();
+      }
+      T::Destroy();
+    }
+

@iche033 iche033 self-requested a review June 7, 2021 18:31
@iche033
Copy link
Contributor

iche033 commented Jun 8, 2021

what's the ogre2 bug? How about being explicit and just removing the BoxVisual instead of all child visuals

Signed-off-by: Atharva Pusalkar <atharvapusalkar18@gmail.com>
@atharva-18
Copy link
Contributor Author

what's the ogre2 bug? How about being explicit and just removing the BoxVisual instead of all child visuals

In Ogre2, destroying an InertiaVisual doesn't, in turn, destroy its BoxVisual. Destroying the box visual explicitly by this->dataPtr->boxVis->Destroy() is giving a segfault in the inertia visual test, specifically when calling engine->DestroyScene(scene).

@ahcorde
Copy link
Contributor

ahcorde commented Jun 9, 2021

@atharva-18 how I can reproduce the issue ?

@atharva-18
Copy link
Contributor Author

@atharva-18 how I can reproduce the issue ?

These are the steps:

  1. cd to the visualization_demo directory and add inertiaVisual->Destroy() after Line 133 in the Main.cc file.
  2. To produce the boxVisual "not getting destroyed" bug, comment out Ogre2InertiaVisual::Destroy() method.
  3. Now, if you run the demo using Ogre2, the inertia visual's box remains at the origin, detached from its parent.

If we keep the Ogre2InertiaVisual::Destroy() method as it is, the box visual gets destroyed, but the unit test gives a segfault.
One way to avoid the segfault is to not explicitly destroy the box visual,

@@ -86,6 +89,17 @@ namespace ignition
       T::Init();
     }
 
+    //////////////////////////////////////////////////
+    template <class T>
+    void BaseInertiaVisual<T>::Destroy()
+    {
+      for (unsigned int i = this->ChildCount(); i > 0; --i)
+      {
+        this->ChildByIndex(i - 1)->Destroy();
+      }
+      T::Destroy();
+    }
+

Presumably, this bug is also present in AxisVisual.

{
if (this->dataPtr->boxVis != nullptr)
{
this->dataPtr->boxVis->Destroy();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

reset boxVis so when Destroy is called again, the above line won't be executed.

this->dataPtr->boxVis.reset();

After that, apply this patch, and see if it fixes the crash for you

diff --git a/ogre2/src/Ogre2Node.cc b/ogre2/src/Ogre2Node.cc
index 63a43a93..cff1e3e8 100644
--- a/ogre2/src/Ogre2Node.cc
+++ b/ogre2/src/Ogre2Node.cc
@@ -64,6 +64,8 @@ Ogre::SceneNode *Ogre2Node::Node() const
 //////////////////////////////////////////////////
 void Ogre2Node::Destroy()
 {
+  if (ogreNode)
+    return;

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The crash is fixed, but UNIT_Scene_TEST seems to be failing

      Start 55: UNIT_Scene_TEST
55/93 Test #55: UNIT_Scene_TEST .......................***Failed    1.25 sec

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oops that should've been if (!ogreNode)

Can you take a look at the changes in this commit:

9575d3d

I think that fixes the test and crash.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed in dd42817

{
this->dataPtr->boxVis->Destroy();
}
BaseInertiaVisual::Destroy();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is not needed as we are handling most of the destruction of object ourselves.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Destroying the crossLines still requires us to call BaseInertiaVisual::Destroy(), see #326 (comment)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed in dd42817

{
this->dataPtr->boxVis->Destroy();
}
BaseInertiaVisual::Destroy();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Destroy material:

  if (this->dataPtr->material && this->Scene())
  {
    this->Scene()->DestroyMaterial(this->dataPtr->material);
    this->dataPtr->material.reset();
  }

Copy link
Contributor Author

@atharva-18 atharva-18 Jun 11, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am getting this message in the console

visualization_demo: /var/lib/jenkins/workspace/ogre-2.1-debbuilder/repo/OgreMain/src/OgreHlmsDatablock.cpp:170: virtual Ogre::HlmsDatablock::~HlmsDatablock(): Assertion `mLinkedRenderables.empty() && "This Datablock is still being used by some Renderables." " Change their Datablocks before destroying this."' failed.
Aborted (core dumped)

I think this is because of crossLines still using the material. Explicitly destroying crossLines before the material is giving an exception in the test

      Start 17: UNIT_InertiaVisual_TEST
17/93 Test #17: UNIT_InertiaVisual_TEST ...............Child aborted***Exception:   0.33 sec

This material is also used in LightVisual where it is not destroyed.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed in dd42817

Comment on lines 25 to 27
set(TARGET_THIRD_PARTY_DEPENDS
${TARGET_THIRD_PARTY_DEPENDS}
GLEW::glew)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was not able to build the demo with these lines as it complains about glew

I had to replace it with:

  if (WIN32)
    set(TARGET_THIRD_PARTY_DEPENDS
      ${TARGET_THIRD_PARTY_DEPENDS}
      GLEW::glew
    )
  else ()
    set(TARGET_THIRD_PARTY_DEPENDS
      ${TARGET_THIRD_PARTY_DEPENDS}
      GLEW
    )
  endif()

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FIxed in ca3ac18

Signed-off-by: Atharva Pusalkar <atharvapusalkar18@gmail.com>
Copy link
Contributor

@ahcorde ahcorde left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Last comment from me

@@ -5,7 +5,7 @@ include_directories(SYSTEM
${PROJECT_BINARY_DIR}
)

find_package(ignition-rendering4)
find_package(ignition-rendering6)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This change is not related to this PR I prefer to remove it from this PR

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

created PR for this change: #343

Signed-off-by: Atharva Pusalkar <atharvapusalkar18@gmail.com>
Signed-off-by: Atharva Pusalkar <atharvapusalkar18@gmail.com>
Signed-off-by: Atharva Pusalkar <atharvapusalkar18@gmail.com>
@ahcorde ahcorde requested a review from iche033 June 15, 2021 07:50
Copy link
Contributor

@iche033 iche033 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

just have one more comment about ogre2 transparency setting for the purple box, otherwise it's working well for me.

material->SetTransparency(0.5);
material->SetCastShadows(false);
material->SetReceiveShadows(false);
material->SetLightingEnabled(false);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks like the semi-transparent purple box is occluding the green lines in the ogre2 visualization. I think you can disable depth write to make the transparency effect more like ogre 1.x (which has depth write disabled by default when objects are semi-transparent).

material->SetDepthWriteEnabled(false);

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed in 42a6a414

Signed-off-by: Atharva Pusalkar <atharvapusalkar18@gmail.com>
@ahcorde ahcorde merged commit b0c9523 into gazebosim:main Jun 15, 2021
@osrf-triage
Copy link

This pull request has been mentioned on Gazebo Community. There might be relevant details there:

https://community.gazebosim.org/t/google-summer-of-code-2021-new-gui-widgets-in-ignition-gazebo/1081/1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🏯 fortress Ignition Fortress
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants