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

Wrong work with large coordinates #1091

Open
CodeGenerator opened this issue Apr 26, 2017 · 6 comments
Open

Wrong work with large coordinates #1091

CodeGenerator opened this issue Apr 26, 2017 · 6 comments

Comments

@CodeGenerator
Copy link

Hello!
I changed in rviz example http://wiki.ros.org/rviz/Tutorials/Markers%3A%20Basic%20Shapes position of the marker object to

marker.pose.position.x = 4E6;
marker.pose.position.y = 6E6;
marker.pose.position.z = 0;

After that I opened rviz and changed origin to (4E6, 6E6, 0). If I move camera around marker (especially when object type is visualization_msgs::Marker::ARROW) I see that arrow breaks up on several parts. Moreover for some angles the marker blinks and disappears.

Do we have some way to allow rviz work with large coordinates without such glitches?

@wjwwood
Copy link
Member

wjwwood commented Apr 26, 2017

I think this is caused by issues with the underlying Ogre3D implementation of some of the marker types, especially line lists and arrow. There are some issues related to this already:

So the short answer is no. Typically what people do is pick an arbitrary origin nearby and use that as the fixed frame. It's uncommon that you want to look at two things simultaneously which are separated by such great distances.

If you figure out a more general solution, we'd be happy to try and integrate it into rviz via a pull request.

@wjwwood wjwwood added this to the untargeted milestone Apr 26, 2017
@CodeGenerator
Copy link
Author

Hello again!
Accordingly to my investigation this problem occurs because rviz uses float32 for object position manipulations. I recompiled ogre engine with double precision (OGRE_CONFIG_DOUBLE) and compiled rviz with that Ogre instead of system one, made few corrections where float was used instead of Ogre::Real. After that aforementioned example started to work well without degradations!
I tried to go a little further and test other markers but found that complex markers like SPHERE_LIST use custom shaders and stuck there. There is constructor PointCloudRenderable::PointCloudRenderable where a shader is built by definition. If I change Ogre::VET_FLOAT3 to Ogre::VET_DOUBLE3 for position slot in shader and make correspondent changes in PointCloud::addPoints I get Ogre lock vertex buffer errors and suggestions to recreate buffer.
Could you assist me how I should change PointCloud to make it work with double type for position?

@wjwwood
Copy link
Member

wjwwood commented May 2, 2017

@CodeGenerator that's great news that you've made progress. I'd like to help you out, but could you post links to the code you're talking about? I might be able to make recommendations if I'm certain which parts you're having trouble changing to doubles.

@CodeGenerator
Copy link
Author

@CodeGenerator
Copy link
Author

What can you suggest to try? Do you know why type substitution didn't work for shader?

@wjwwood
Copy link
Member

wjwwood commented May 8, 2017

@CodeGenerator I do not. Unfortunately I'd have to spend more time than I have digging into the issue to be really helpful. But since you've made the issue more visible, perhaps someone else in the community could help you with it too.

@wjwwood wjwwood removed this from the untargeted milestone May 10, 2018
130s pushed a commit to 130s/rviz that referenced this issue Aug 21, 2024
…ion#1090) (ros-visualization#1091)

This is so we don't access uninitialized memory during
startup.

Signed-off-by: Chris Lalancette <clalancette@gmail.com>
(cherry picked from commit 51e576c5289a5d231f89c7593ded84c6ddade22f)

Co-authored-by: Chris Lalancette <clalancette@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants