Slope Calculations Question

[orinn]

As always thank you for this incredible program.

I'm trying to calculate slope for a parking lot. Basically I'm interested in anything over a 2% slope. I used a height grid to get my lowest Z, calculated normal's, then convert normal's to dip/dip direction SF. When I look at dip (degrees) the numbers seem to be set at intervals. If I look at the values they go

Degree - Slope %
0.6379 = 1.11
0.6482 = 1.13
1.4491 = 2.53
1.4727 = 2.57
1.9755 = 3.45
I'm hoping to better define what falls under and over 2% slope.

I'm not sure why the calculations for degrees jump instead of a smooth transition. Is there a better way to go about this?

[daniel]

There are two possible causes:
[*] if you are computing the normals on the 2.5D cloud output by the Rasterize tool, then maybe the sampling is the cause?
[*] otherwise it may be due to the normals compression scheme we use (in order to store the normals on 2 bytes instead of 12 ;). This compression scheme works very well for visualization purposes (as the eye can't make the difference) but it may be the cause of those intervals (however I would have expected to see more regularly sampled angles in this case).

Can you maybe share your cloud (or a part) with me?

[orinn]

I considered that it might be the Rasterize tool, so I ran normal detection without using it, still have the same problem.

In the link below is the parking lot with normals detected via height. I have tested it with plane and triangulation and see similar results with the numbers.

Link to .bin
https://eco3d.egnyte.com/dl/xIsxyDrTXH

Edit: I also tried running the cloud through meshlab for normal detection, and then back through cloud compare. problem persisted.

[daniel]

Okay, the issue was indeed the limited number of orientations due to the coding of normals on 15 bytes (which only allows for 32K directions).

I've upgraded this to 21 bytes (= 2M directions) so as to get a much finer result:

cc_high_res_normals.jpg (132.68 KiB) Viewed 4144 times

You can test this with the latest beta version (I've just updated it).

(of course the result also depends on the way you compute normals - the bigger the radius is, the more uniform the normals will be)

[orinn]

Wow, that really makes a big difference. It looks amazing, thank you very much sir.