SVOs and Point Clouds

StepResponse

CAD practitioner
Hi everyone,

I am new here and want to use the SVO and Point Cloud algorithms from Analysis Situs.
I have tried to get it to work from analysing the procedure in cmdDDF in the ASitus source code and also mobius.
However I couldn't get it to work.
How exactly would I use those algortihms to get an SVO and Point Clouds from step files, which I want to use for some machine learning and evaluation of volumes.

Thanks for all, great to have a tool like ASitus available!
 

Quaoar

Administrator
Staff member
Hello @StepResponse and welcome to the forum.

Can you tell a bit more about your planned architecture? There can be several ways of doing things:
  1. You copy & paste the sources of SVO, distance function, sampler, etc. into your code.
  2. You link against mobius and asiAlgo dynamically.
  3. You run analysis situs as a batch process.
I'd say that 2-3 are much better than 1, but there could be some obstacles, especially, with the batch run. Have you tried dynamic linking? How far have you gotten with your attempts to plug it in?
 

StepResponse

CAD practitioner
Thank you for your answer!

After quite some hours of work I have compiled asiAlgo for Linux and linked dynamically. (As mechanical engineer I had to learn all those things first...)
I managed to conclude how to implement the AAG from asiAlgo for example, however I don't know how to use the SVO Algos.
All I have at the moment is a asiAlgo_BVHFacets Object with my shape.
It shows the diagonal distance from the AABB but it still has a size of 0.

But I assume there is a lot more to do with DDF, SVO etc.
I'm not sure, which steps to take to get it to work.
 

Quaoar

Administrator
Staff member
Have you generated the facets in the first place? It can normally be done via asiAlgo_MeshGen (if I remember the class name correctly). Once you get the mesh (each face will get triangulated), you can build this asiAlgo_BVHFacets structure (it's the bounding volumes hierarchy) that is used in the signed distance function that drives the voxelization process.

The entire workflow is somewhat implemented in the ddf-build-svo command, but it relies on the existing triangulation you have in the viewer. When used programatically, make sure to generate facets manually first.
 

StepResponse

CAD practitioner
Thank you for helping me! generating a mesh and then building the DDF did the trick.
Generating a pointcloud worked quite nicely!
However I still have one problem. When generating an SVO, some Voxels on exposed sides are marked as "on" the shape despite not being. (See Image)
Do you know how to solve this without making it computationally too heavy? Reducing the max cell sized worked, but damands lots more resources.
 

Attachments

  • Screenshot 2022-03-26 132917.png
    Screenshot 2022-03-26 132917.png
    175.5 KB · Views: 12

Quaoar

Administrator
Staff member
Do the voxels marked as ON still have at least one corner inside the volume? It's the condition for this to work. Actually, I've been playing around with another SVO construction logic that gives quite different subdivision in certain cases. If you have time to wait a couple of days, I can try to make a branch or a patch for Mobius with this different splitting strategy. Not sure it will be exactly better, but this one would have a check for voxels intersecting with a boundary as a subdivision condition.
 

StepResponse

CAD practitioner
It doesn't seem like the voxel is touching the surface, but probably it is...
Maybe your different construction solution could improve things and i would appreciate seeing it in ASitus!
Thanks and have a nice weekend!
 

Quaoar

Administrator
Staff member
If you press "W" key on the keyboard, you will be able to see the internals of voxels. Cold colors (grades of blue) would mean a corner is inside.
 

StepResponse

CAD practitioner
Ok, here is one part, where the Problem occurs.
 

Attachments

  • Screenshot 2022-03-28 180439.png
    Screenshot 2022-03-28 180439.png
    696.9 KB · Views: 4
  • testPart.stp
    45.3 KB · Views: 3

Quaoar

Administrator
Staff member
I was adding this alternative logic of voxelization that has the following main differences from the original ADF:

1. It does not try to capture the distance field level set outside the boundary (ADF does that to allow for offsets).
2. It has new "distance threshold" parameter to split big voxels touching the boundary.

Currently, I am struggling with the voxels that lie ON the boundary but are not classified as such. It likely happens because of small imprecision or whatever round-off error:

1648622717579.png
I'll keep working on it a bit more.
 

StepResponse

CAD practitioner
Thank you for your efforts!
I suppose adding some tolerance to the classification reintroduces the problems again.
Maybe it can look at its neigbours if the points lies close to the boundary...
 

Quaoar

Administrator
Staff member
I tried to check if a voxel touches the boundary and this seems to give a better result:

1648672498093.png
1648672523626.png
1648672577339.png
1648672610788.png
1648672622406.png
1648672661766.png
1648672731175.png
Does that look like something you were trying to achieve?
 

StepResponse

CAD practitioner
Yes that is exactly what I would expect the voxelization to behave like. Awesome!
It would be great to have this alternative approach in ASitus available!

What exaclty is the difference between the first and fourth/sixth picture, one with a "chamfer" and the other with crisp edges. The max cell size?
 

StepResponse

CAD practitioner
It works like a charm!
After playing aroud a bit with the settings, the geometry gets captured very accurately!
For chamfers and fillets one would probably employ different techniques additionally...
Ithink this is a great addition to the voxelization pipeline!
Thank you very much.
 
Top