Tips to avoid meshing exporting in stripes?


Any tips on avoiding this mesh result?

I’ve been testing Sequoia to mesh large survey scans with mixed results.

The scans have been captured to a very high resolution (sub 10mm), and in real world coordinates (km’s away from origin). In areas far from the scanner location the resolution obviously reduces. regardless of the scanner resolution Sequoia still suggests a meshing radium of 200mm (I’m not sure how Sequoia calculates this suggestion?). If I try to mesh at a reduced radius I often get this ‘striped mesh’ result but not always. I have tried various precision values but it doesn’t seem to make a difference.

The example above shows the result when using Hacksaw to mesh. While some squares mesh fine others get exported with the striped result. They have the same settings applied to both so I cant think why one volume would work and the next not???

Where should I start looking?

  1. Should I increase/reduce the precision amount of the point loader?
  2. Do I have to shift the point cloud to origin to avoid rounding errors?
  3. Is it not recommended to go below Sequoias suggested meshing radius?
  4. Should I avoid hacksaw?

Thank you,



The stripes are the result of (unexpected) decimal precision loss. Since it is very far away from the origin, the point data has to be saved with high precision. Normally the Point Loader figures this out automatically, so I don’t think you have to change anything there.

When a Mesher is created with data far away from the origin, a UCS node is added to move the origin for the meshing at the center of the data. The Mesher itself only supports 32 bit floats for its vertex coordinates, so it has to operate in a local coordinate system close to the points, otherwise it would have a different set of issues (mesh surface would look noisy). This is similar to moving the Point Loader to the World Origin, except you don’t have to move anything.

I have to ask if you used Deadline to calculate some of these Hacksaw segments? We recently discovered that when a Hacksaw segment is calculated on Deadline, it does not take the UCS into account and loses precision due to the offset even if the point data looks correct. Calculating Hacksaw segments on the workstation should produce correct results.

Can you please clarify how the depicted segments were generated, and whether you used Deadline to mesh some of the data?

There might be other conditions where the UCS is not respected by the Mesher that we are not aware of. You can also try to set the Hacksaw Tasks preference from 0 to 1 to force a single segment to be processed at a time on the workstation if you are not using Deadline but are still getting variable results from multiple parallel tasks.

As for the radius, the suggested value is just a starting point and you nearly always have to adjust it down.


Thanks Bobo,

To clarify:

Points have been supplied as rcp- exported as .e57 format and read into Sequoia. I have kept the suggested precision (mag: 6248354.79 - precision: 0.00010)

I have been meshing using hacksaw locally on my workstation using max 16 tasks (workstation has 32 available processors). Max 32 tasks became too unstable and as you say deadline produced poor results and i gave up. Max memory is set to 80% of an available 128GB.

I am trying meshing again, this time i have set max tasks to 1 as suggested and will report back. (its worth mentioning the last process only completed 54 of 400 parts before crashing). I would have posted more images but i am restricted to one only

Thank you


Interesting note:

when setting max task to 1 its now started using all my cores… Is this the expected result?


No, something is very wrong. The goal is to have a single Hacksaw partition processed at a time. Normally, with Hacksaw Tasks Count default value of 0, the limit comes from the other Task counts for CPU etc. When set to 1, I would expect a single Task to be processed.

There is a possible threading instability we are trying to avoid in this test, hence my suggestion to limit to a single partition at a time. The actual meshing process is still mutli-threaded and would use a few of the cores.

You could go to the Options, set to Advanced, search for “Task” and set all possible task count limits to 1 from their defaults which are mostly around 8. Then see what you get…


silly me (i dont think id restarted Seqouia after changing tasks setting).

so far so good…

you can see only one tile has the striped effect - so using one task im getting a better result. Its a shame i cant use all my available cores


If i am limted to one core, would it be more efficient to not use Hacksaw?