Does NearestPoint have to actually find the nearest point? If all we want is the Distance? I only need a SDF from the geometry, but it seems like it’s REALLY slow to get that since I assume it would be computed once per InputGeometry, not once per NearestPoint or once per primative. Considering that NearestPoint appears to potentially return a whole bunch of stuff I don’t need (normal, position, etc), I’m guessing that that’s what’s going on. Am I missing a simpler alternative? I was hoping InVolume might give me distance, but it does not.
A signed distance field (SDF for those watching from the sidelines) is exactly defined as the distance from the lookup point to the nearest point on the surface. This means that there is no way to read the distance without computing the nearest point. We are not utilizing any discretization/voxelization in order to approximate the signed distance (hence why you don’t see any controls for voxel spacing distance, etc.). All (read: most) of the quantities output by the NearestPoint node are computed as part of the process of finding the closest point, therefore the overhead of exposing them is minimal.
I don’t really understand what you are getting at here.
Ok. The results are fine, and since I have to unroll the loops manually it’s not really practical to do a vertex color based renderer in Genome, but I was having a lot of fun trying. 
If you’re computing the exact closest point position, as you are, then I’m getting the expected results. Which is why I was wondering if there was an alternative that might be less sensitive to the number of faces.