Hah!

Wonderful news then. I will update today and take a look whether its been added and if so will jump on testing it right away.
Thanks for the info!

Early findings:
I have found and tried this from Sidefx Labs and must say that for now I have no idea how their segmentation is supposed to work, because it doesnt seem to work or I cant get it to work.
For now, I have recreated your approach with segmentation through scattered points/copied sphere and sampled attributes from those. As that approach was a lot cleaner and reliable.

The rest of the tool seems to work fine for now.

Hello Milan,
the new clustering parameter let you type the number of primitives for each cluster, and then it determines the number of clusters to process. So you don't really know the amount of clusters you are processing.

I have your very feeling about it, now it seems less intuitive.
The old method let you decide directly the numbers of clusters, so you could fine tune it based on the amount of physical cores available to your machine.
I've found that for good performance you should set the number of clusters to (Number of Logical Cores * 10).
For my machine I normally set it to 480 (having 24 physical cores and 48 threads)
Setting a higher number won't improve performance and would just decrease the quality of the output.
This is my experience with my machine, it might vary with yours.

cheers

Trying to use Labs Fast Remesh in a solver and it always crashes. Has anyone tried it?

coccosoids
Trying to use Labs Fast Remesh in a solver and it always crashes. Has anyone tried it?

Hi, can you upload a simple hip file?

Andr

coccosoids
Trying to use Labs Fast Remesh in a solver and it always crashes. Has anyone tried it?

Hi, can you upload a simple hip file?

Here is a small example:

Thanks, I can reproduce the crash.
A temporary workaround is to append a Clean Sop node just after Fast Remesh so to remove the degenerate primitives that seem to be causing the issue.

Also, be aware that you are producing self-intersecting geometry (have a look inside the geometry)

Andr
Thanks, I can reproduce the crash.
A temporary workaround is to append a Clean Sop node just after Fast Remesh so to remove the degenerate primitives that seem to be causing the issue.

Also, be aware that you are producing self-intersecting geometry (have a look inside the geometry)

Thank you! I will have a look at how the Clean Sop can help. To be honest I've seen those intersections, and was wondering how to remove them -however I think anything that could help remove them would also maybe negate the speed gains?

coccosoids

Andr
Thanks, I can reproduce the crash.
A temporary workaround is to append a Clean Sop node just after Fast Remesh so to remove the degenerate primitives that seem to be causing the issue.

Also, be aware that you are producing self-intersecting geometry (have a look inside the geometry)

Thank you! I will have a look at how the Clean Sop can help. To be honest I've seen those intersections, and was wondering how to remove them -however I think anything that could help remove them would also maybe negate the speed gains?

You made me rmb that I should really finalize and release a new version of `Auto-Fix Self-Intersections Sop`, which could help in your case. As you guessed, it adds computation time (even if the detection of the intersections uses a similar parallelization approach as Fast Remesh).

You can try the 1.1 version and see if it works for you, but it's a little bit clunky.
https://www.sidefx.com/forum/topic/82432/#post-373294 [www.sidefx.com]

ps. in your scene, I noticed that you use Labs Fast Remesh in `target length` mode and so computation time increases at each solver step as the total area of your mesh progressively increases.
You could consider to explore other options, like a target polycount maybe.