WIP - Fast Remesh - [ need help with betatesting b4 submitting]

   6032   22   5
User Avatar
Member
720 posts
Joined: Feb. 2016
Offline
**UPDATE**
You can now try Fast Remesh, your feeback is very welcome, thanks!
Check this post please [www.sidefx.com]



---------------------------------------------------------------

Based on the vanilla Remesh Node, The new Fast Remesh is more performant and it comes improved with some quality of life features.

Key Features:
  • Up to 12.5x 25.5x faster than vanilla Remesh Node thanks to multithreading (measured on a 24cores machine)
    The input geo is divided into chunks to be remeshed independently and in parallel inside a compiled loop.
    The chunks are then fused back together.
  • Up to a 2.5x remeshing speed boost measured in a low specs dual cores laptop
  • Different options to split the input Geo into chunks: by automatic fast clustering, by connectivity, by user attribute, by UV islands.
  • Computes the Average Edge Length, with Target Size Presets in UI to easily set the target remesh size
    The average edge length of the input Geo is a good starting point to set the desired remesh size, instead of blindly typing numbers and running a remesh to see what they mean. It can prevent some unnecessary slow cooks! The average edge length is also useful to simply equalize the topology.
  • Advanced and Simple interface mode for faster user setup
  • Preserves UVs
  • Compatible with Safe Displace workflow (it won't break any a chain of layered safe displacements)
    Safe Displace is an upcoming entry for the contest, this tool lets you displace geometry avoiding self-intersections

Features to be added to Fast Remesh: (not necessary before contest deadline)
  • Target remesh size live linking with upstream geometry. For example, you might want any upcoming Geo to be remeshed with a target size of half of its average edge length. This is useful in PDG and wedging scenarios.
  • Estimate the expected polycount of the remeshing. This would be a great quality of life improvement: super useful for the user to have this estimate during the setup.
  • Maximum Polycount allowed. A threshold for polycount with automatic clamping of the target size. It could save a lot of time in automated workflows and prevent doomsday remeshing scenarios...
  • Auto Detect CPU specs (like in the TOP Scheduler). How many cores are available for parallel processing?
    This information is very useful to automatically setup the ideal number of chunks to split the geometry.
  • Adaptive remeshing like in the vannilla Remesh Node. I haven't checked yet if it can be implemented.
  • Noisy Clustering. A method to make clusters with noisier outlines that should produce a more natural topology around the seams.

    Bugs and issues
  • Some glitch in the UVs under certain conditions
  • Need for more reliable tools to improve the quality of the topology produced around the seams
  • Performance in some areas might be improved (fusing chunks, post compute normals, polydoctor alternative, user interface lag on heavy geos)
Edited by Andr - Sept. 30, 2021 19:08:42

Attachments:
performance_monitor.JPG (29.9 KB)
pigheadremeshed.JPG (190.4 KB)

User Avatar
Member
11 posts
Joined: Oct. 2020
Offline
Great job so far, and lovely documentation post!

You should take a look at Jake Rice's remesh hip [twitter.com], based on "Instant Field Aligned Meshes" paper by W Jakob.
Maybe it'd provide inspiration or could be substituted for the default remesh node.
Edited by volodXYZ - Sept. 13, 2021 07:38:45
User Avatar
Member
720 posts
Joined: Feb. 2016
Offline
I wish I can open a beta testing phase very soon, so to have some quality feedback to consolidate the tool before the deadline.

I attached screenshots of how the interface looks now.

volodXYZ
Great job so far, and lovely documentation post!

You should take a look at Jake Rice's remesh hip [twitter.com], based on "Instant Field Aligned Meshes" paper by W Jakob.
Maybe it'd provide inspiration or could be substituted for the default remesh node.

Hello Volod, thanks for the input, that project file is a bit out of my league of expertise for now! I don't know nothing about OpenCL.
However you made me realize that the same main concept of Fast Remesh, could be applied to the Subdivide Sop as well.
So I'll look into adding it to Fast Remesh. It's now a most wanted feature!

====================================================

New features have been implemented:
  1. Dynamic target remesh size mode. The user can set a live-linking with the upstream geometry, for more automated and wedging workflows.
  2. Custom Size Presets, by easily writing a list of multipliers for the computed average edge length.
  3. A smarter interface that automatically unchecks some toggle paramaters to bypass the unnecessary cooking of some heavy nodes. This is helpful especially when the user is operating on Minimal Interface Mode, and some toggle parms are not revealead to him (but they are still active).
    An example: if the pieces for the loop are identified by connectivity, there is no need for the Fuse Sop to cook after the loop (there is nothing to fuse!). Better to have the toggle to bypass the fusing automatically unchecked.
Edited by Andr - Sept. 15, 2021 11:42:01

Attachments:
interface_minimal.JPG (63.5 KB)
interface_advanced.JPG (85.8 KB)
interface_debugging.JPG (49.0 KB)

User Avatar
Member
720 posts
Joined: Feb. 2016
Offline
An issue I'm having is to make a good estimation for the final polycount after the Remesh.
Do you have any tip in this regard?

My method:
TotalArea_in: the Total Area of the Input Geometry (which is easily retrievable)
AVGprimarea_out: is the expected average area for the primitives of the remeshed Geometry.
Polycount estimation: is TotalArea_in / AVGprimarea_out .
To compute AVGprimarea_out we can use the formula for the area of an equilateral triangle given the side (the side is the target remesh size decided by the user).
As the Documentation reports, the Remesh Sop tries his best to output a topology made of equilateral triangles, with edge length as close as the Target Remesh Size.

The above method gives a very rough estimation, that even becomes less and less accurate as you increase the values for the of the smooth param, while it gain accuracy as you increase the Iterations.
I think of applying a Ramp to the computed estimation and then trying to manually match the curve of the polycount as it goes through higher values of Iterations and Smooth.
Edited by Andr - Sept. 16, 2021 12:07:55
User Avatar
Member
720 posts
Joined: Feb. 2016
Offline
Beta testing is open for everyone who want to try Fast Remesh.
I hope I can catch some critical bugs before submitting it to the contest.

Would be helpful to know:

1-) The overall ease of use and experience
2-) Is there anything broken?
3-) Is Fast Remesh actually faster on your machine and for your workflow?
4-) Does it produce any unexpected/ugly result?
5-) Is the documentation clear enough?
6-) Any feature you wish to be added in future version?



// Here some change log about the new main features implemented recently:

-) I've measured a case where Fast Remesh is over 25x (!) faster than the traditional Remesh Sop.
-) Now we have Polycount Estimation from the Target Edge Length input. The estimate starting accuracy is 0.8, reaching 0.99 in some cases (especially when you set the remesher for 5 iterations).
-) A report Label Parm to see directly the poly estimate in the parameter pane, while you are setting the Target Length.
-) Target Polycount Mode: now you can remesh a geo just by typing your desired polycount instead of using the target edge length (with an acceptable accuracy in the outcome)
-) Polycount Emergency Limit with autoclamping to avoid unwanted remeshing tasks of trillion of polygons (especially useful in Dynamic mode)
-) Initial documentation support
Edited by Andr - Sept. 30, 2021 19:54:24

Attachments:
Fast_Remesh_Asset_and_Examples.rar (432.6 KB)

User Avatar
Member
11 posts
Joined: Oct. 2020
Offline
I can already imagine scenarios were being able to set target poly count from an outside attribute would be a game changer.
It works really nice. Fantastic work!
User Avatar
Member
720 posts
Joined: Feb. 2016
Offline
Hello Volod, thanks for checking it and for confirming that it's working.
Do you find the lack of Adaptive remeshing a deal breaker for your typical workflow?
I really wanted to implement this feature before the deadline, but the early version is not very reliable so far.

cheers!
User Avatar
Member
194 posts
Joined: Sept. 2012
Offline
Hello

I found your tool very interesting indeed and I wish Sidefx will address soon that batch of essential nodes which are only single thread ... Not sure your tool is working when using a DOP and Sop Solver...
Vincent Thomas   (VFX and Art since 1998)
Senior Env and Lighting  artist & Houdini generalist & Creative Concepts
http://fr.linkedin.com/in/vincentthomas [fr.linkedin.com]
User Avatar
Member
720 posts
Joined: Feb. 2016
Offline
vinyvince
Hello
Not sure your tool is working when using a DOP and Sop Solver...

have you tried by any chance? I'd like to see an example, I don't see why it shouldn't work...
cheers
User Avatar
Member
4 posts
Joined: Feb. 2022
Offline
Dear Andr,
i tested your tool with Houdini 19 and inside the GUI everything works as expected. However when scripting the same test in python the fast remesher throws a segmentation fault.

The workflow is as follows:
  1. Create a file node importing the OBJ geometry of the stanford bunny
    (https://graphics.stanford.edu/~mdfisher/Data/Meshes/bunny.obj)
  2. Connect fast_remesher to the file node (Keep all settings at default)
  3. Export the geometry of the fast_remesher node as OBJ

In python that translates to:

node_file.parm('file').set('bunny.obj')
node_remesh = node_file.createOutputNode('fast_remesh', 'fast_remesh_node')
node_remesh.setParms({'iterations': 1})
node_remesh.geometry().saveToFile('bunny_remesh.obj')

When setting iterations to 0 the code runs fine and the output "bunny_remesh.obj" is written. As soon as iterations is set to a value larger than 0 the code crashes on the commandline with a segmentation fault. Changing any of the parameters (type, target_type, targetsize and so on) does not help, as soon as iterations is larger than 0 the code crashes.

Do you have any advice on how to circumvent that problem?
Many thanks in advance,
BeyondDev
User Avatar
Member
720 posts
Joined: Feb. 2016
Offline
Hello BeyondDev,
thanks for the feedback on the issue.

Sorry for the dumb question, how do you create the python shell?
I never use python shells.

I tried to spawn one from an active Houdini session, added and executed those commands one by one, and did not have any segfault.
Is this your very same workflow?

cheers
User Avatar
Member
4 posts
Joined: Feb. 2022
Offline
Dear Andr,
thank you for looking into this! However, after yesterdays update to 19.0.539 the issue seems to have resolved itself. Now everything runs as expected, so i think it was something unrelated to fast_remesher. Still, thank you for the quick answer and best regards,
BeyondDev
User Avatar
Member
4 posts
Joined: Feb. 2022
Offline
Dear Andr,
sorry to bother you again, but this time i have found a geometry (attached to this post) that does not seem to work with fast_remesher. This is also reproducible inside the Houdini 19 GUI. Just import the geometry, add a fast_remesher node, set size-preset to -AVG- and iterations to 1. After that Houdini either freezes forever for me or crashes. Do you have any hints what might be the problem?
Many thanks in advance, BeyondDev

Attachments:
book_MA.obj (193.8 KB)

User Avatar
Member
720 posts
Joined: Feb. 2016
Offline
Hello,

please check the example file for a possible fix.
The issue was caused by some degenerate primitives in the source geometry.

The traditional Remesh Sop is also affected by this issue (Fast Remesh is built upon it).
I'm going to fill a bug report with the Support: maybe they can at least avoid freezing the session and throw a simple error instead.
Thanks for the feedback again, very useful.


ps. note that Fast Remesh doesn't really like low-res input geometry, with uneven topology.
So in this case you might need to pre-remesh it with the traditional Remesh Sop.
In the attached file, there's a comparison that show this
Edited by Andr - Feb. 23, 2022 11:38:15

Attachments:
freeze_fix.hiplc (161.0 KB)

User Avatar
Member
4 posts
Joined: Feb. 2022
Offline
Dear Andr,
that works perfectly, thank you very much! And the tip with the pre-remeshing is also very good, some of the input geometries i want to work with will be quite low-res.
Thanks for all the help!
Best regards,
BeyondDev
User Avatar
Member
1 posts
Joined: Oct. 2021
Offline
This is insanely fast. Awesome!
User Avatar
Member
6 posts
Joined: Aug. 2017
Offline
This is amazing!! Do you also have a none hdalc version but a hda version?
User Avatar
Member
720 posts
Joined: Feb. 2016
Offline
Hello,
I don't, but the good news is that Fast Remesh will be officialy part of the SideFX Labs collection, so you are going to have a fully commercial version of it.
ETA for the release should be very soon, at least this is what I was told few weeks ago.

Ps.
I have made also a Fast PolyReduce tool.
You can download for free the fully commercial version from Orbolt:
https://www.orbolt.com/asset/adn::dev::Fast_PolyReduce::1.1

Support/WIP page here:
https://www.sidefx.com/forum/topic/84519/ [www.sidefx.com]
User Avatar
Member
5 posts
Joined: Jan. 2021
Offline
Hello Andr,

Just wanna jump in and say that after running a few tests on my end, both your fast remesher and fast polyreduce are really impressive! Amazing job on both ends.
Have you heard any update from sidefx on when will they add this to sidefx labs?

Again absolutely impressive, thank you!
User Avatar
Member
720 posts
Joined: Feb. 2016
Offline
Hello Milan, thanks a lot!

Apparently Fast Remesh is the most hidden new feature of Houdini 19.5
You can find it already in the Labs collection for Hou 19.5
I recommend you to get the last daily build of the Labs, bc of a critical issue with the initial release of Fast Remesh for Labs.

I think the devs made a good job in the re-work of Fast Remesh: it seems to be a bit faster, the UI is simpler,and we have adaptive mode!

Regarding Fast PolyReduce, there might be the chance that one can use the new Labs Fast Remesh for fast polyreducing too... in which case porting Fast PolyReduce to Labs would be pointless.
I haven't tested yet, I don't have access to my computer these days..


Cheers
  • Quick Links