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

Low resolution of meshes? #15

Open
matraspe opened this issue Jul 25, 2014 · 5 comments
Open

Low resolution of meshes? #15

matraspe opened this issue Jul 25, 2014 · 5 comments

Comments

@matraspe
Copy link

Hi,

After successfully compiling and running cork (Windows 7 64) I was quite surprised to see the very coarse resolution of the objects: in the screenshot the result for the sample geometry (difference of ballA.off and ballB.off) is shown. Is there a setting of grid size or samples I have missed? Similarly coarse results occur for other custom meshes, too.

Thanks and regards,
Matthias

screenshot_corktest_meshlab

@gilbo
Copy link
Owner

gilbo commented Jul 26, 2014

That's very strange. Can you tell me what order the coordinates your model uses are? Is it very far from the origin?

There is a slight quantization for the purposes of arithmetic, but it a should be at the 10^-6 scale relative to the largest coordinate value, so it should be unnoticable.

-- Gilbert

On Jul 25, 2014, at 1:12 PM, matraspe notifications@github.com wrote:

Hi,

After successfully compiling and running cork (Windows 7 64) I was quite surprised to see the very coarse resolution of the objects: in the screenshot the result for the sample geometry (difference of ballA.off and ballB.off) is shown. Is there a setting of grid size or samples I have missed? Similarly coarse results occur for other custom meshes, too.

Thanks and regards,
Matthias


Reply to this email directly or view it on GitHub.

@matraspe
Copy link
Author

Thanks for answering: actually, the depicted example uses the sample data included with cork (ballA|B.off). My own data is somewhat translated from the origin, but in the range of 50-150 units.

@gilbo
Copy link
Owner

gilbo commented Jul 26, 2014

Ahh, I just noticed you're on Windows. In all likelihood there's something weird about how MPIR is being used that's breaking the code. This is very likely to be an arithmetic bug, so that's the obvious problem area.

-- Gilbert

On Jul 26, 2014, at 12:57 PM, matraspe notifications@github.com wrote:

Thanks for answering: actually, the depicted example uses the sample data included with cork (ballA|B.off). My own data is somewhat translated from the origin, but in the range of 50-150 units.


Reply to this email directly or view it on GitHub.

@matraspe
Copy link
Author

Yes, only MeshLab was running on Mac. Any chance to narrow it down? MPIR seems no fun... Do you have a prebuilt test binary for windows available? Thx

@gilbo
Copy link
Owner

gilbo commented Jul 27, 2014

Did you verify that MPIR is working? I don't have a test binary ready. I can try to poke around my windows box later.

On Jul 27, 2014, at 12:56 AM, matraspe notifications@github.com wrote:

Yes, only MeshLab was running on Mac. Any chance to narrow it down? MPIR seems no fun... Do you have a prebuilt test binary for windows available? Thx


Reply to this email directly or view it on GitHub.

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

No branches or pull requests

2 participants