Getting NaN RGB values when remeshing -- why??

   1727   2   1
User Avatar
Member
88 posts
Joined: April 2020
Offline
Hello Experts,

I have a workflow in which I need to convert an input geometry to a VDB and then convert it back to polygons. It then gets transformed and colored in various ways. Later in the workflow I want to remesh it to reduce its size and turn it into a triangular mesh for a custom "save in 3mf" node.

My problem is that the mesh ends up with some of its RGB values being turned into not-a-number values. I don't understand why. Unfortunately, I can't just recolor it after remeshing. If I don't do the conversion to VDB and back to polygons, the problem goes away. Also, the problem only shows up with certain transformations and not others.

I am confused about what is going on and hope someone might be able to explain it to me.

I've attached a simplified workflow with a controller to turn on and off the VDB conversion and bad transformation. I've attached the input file geometry on which the problem is occurring. Also a screenshot.

Any suggestions would be most welcome.

Thanks!
Mary
Edited by mgbaker - May 6, 2022 16:24:49

Attachments:
bad color mesh.png (311.6 KB)
color mesh debugging.hip (118.6 KB)
peace.stl (29.2 KB)

User Avatar
Member
9380 posts
Joined: July 2007
Offline
I opened your file in 19.0.531 and don't see any nan values, this could be related
19.0.437
Some fixes and upgrades to remesh 2.0 sop:1. Substantial improvement on numerical precision away from theorigin, as well as safeguarding against NaNs everywhere.2. Correction of split ordering to guarantee termination forthe adaptive case (previously adaptive remeshing could freezeparticularly without a strict minimum edge length).3. Improved attribute interpolation.4. Added an option to automatically add UV seams to the hard edgesin order to respect UVs.5. Added the option to report the (subdivisions) of the hard edgesas an edge group over the output mesh.6. Added the option to report a triangle quality measure on eachtriangle (a number in 0 (terrible) to 1 (perfect) range).7. Second input now correctly functions as rest geometry.


but if you need to use 18.5 adding Attribute Blur with tiny step seems to fix it (as your incoming geo has very close to 0 area polys)
Tomas Slancik
CG Supervisor
Framestore, NY
User Avatar
Member
88 posts
Joined: April 2020
Offline
Thanks, Tomas! That sounds very likely. I guess this means I look forward to upgrading to version 19. And also that maybe it wasn't something I was doing wrong :-)

Thanks again,
Mary
  • Quick Links