I work with the Viking Ship Museum of Norway and they use Rhino to handle the scanned data of the artifacts, but when ever we split or explode a vertex colored mesh the colors goes away.
I have made a script to handle these files, split them and convert the colors to maps that are reassigned to the model.
And this works very well. But it is slow… and they have to reduce the meshes down to 600K for it to work. And being able to split and explode the meshes with out loosing the colors are key to a faster workflow.
I’m not finding this as a current bug in our system. Can you send me a sample please so I make sure we’re seeing the exact same thing? I’ll then get it documented for development to look at. Your solution is a smart one… but I agree it would be better to preserve the vertex colors when new objects are created after the split.
Hi Brian, any vertexcolored mesh will loose it’s colors when you split them.
Are you saying that this doesn’t happen in the inhouse build, or only that it is not filed as a bug?
PS! The tool that I made is not a workaround, it is a tool to convert vertexcolored meshes to color mapped ones. But I have to split them so they can be unweapped, and that deletes the colors, so I have to recalculate evey single vertexcolor after the split, and that takes a long time when the mesh is 600K.
I’ll include a super reduced version in a while, it is trying to reduce it in one instance while I run the plugin in another. It’s the battle of the threads…
Sorry for the confusion, I don’t have a mesh with vertex colors on the machine I’m on at this specific moment to test it so I just looked to see is a bug existed but found none. I will need to make or find a colored mesh to test this… but it is always best to have the exact file exhibiting the issue to pass on in a bug report. Sometimes the issue is specific to the model and sometimes not but it saves time to have the same model you are experiencing the problem with. Another example of where this may be needed is if the solution development comes up with worked on a simple test case but failed on a model of the complexity you are dealing with.
Glad you found that. Too bad you end up putting it on V6 but I understand that.
I am working on a Python RTree solution to speed up the search, but searching and recoloring 100.000 points still takes time… And I am sure you guys could do this superfast compared to anything I’ll ever manage to do. And I am just using nearest color.
I’m not exactly sure how this bug percolated to the top of my list, but it did. And, I’ve been thinking about ways to do this without a whole bunch of book keeping in extra arrays to preserve the vertex colors (VCs).
This problem actually impacts more than just VCs, it will have an impact on the result where any of the meshes in the input set don’t have a particular component. So if, for instance, you used a mesh that you imported via STL (which has nothing but vertexes, faces and normals) to split a mesh with texture coordinates (TCs) (and/or VCs) you’d lose them in the final result.
Here’s a potential work around for V5 (this also ought to work in V6 but I could automate this in the code there so the workaround would not be necessary). Can someone please try this and see if it would work for you? If it does, let me know and I’ll get it into V6.
In a paint program:
Make a .jpg file that is some sort of neutral color like a light gray. (This will be the color of the portion of the resulting mesh whose input mesh did not initially have VCs. So, if you use a boolean command, instead of split, you may want to use a color closer to the mesh that already has VCs.)
In Rhino:
2) Use List to check out any mesh that you’re not confident already has VCs (any single mesh missing them in the input set will prevent the entire result from having them).
3) Any mesh that is missing vertex colors, assign the .jpg you created in 1) as a texture.
3) If it is also missing TCs, you’ll need to create them first with the texture mapping stuff.
4) Run the command ComputeVertexColors (this uses the combination of the TCs and the .jpg to cook up the VCs).
5) At this point you can remove the texture if you wish, it no longer has a purpose.
6) Now perform the boolean operation. It should preserve the VCs.
Note: This does not help Explode (it must be a different problem since it only takes a single mesh as input) but I’ll look into that in V6 if the boolean steps listed above work for you in V5. Please let me know.
Hi Tim,
Thanks for looking into this. For those who work on 3D scan data this will be great news. The main focus on this topic was the ability to split a VC colored mesh and still keep the vertex colors, but I see that boolean operations would also be nice. Since you bring that up, I would solve uncolored VC’s by using a default gray, or warn the user with something like: “Vertex colors will be ignored since not all objects in this boolean operation has vertex colors.”
When it comes to splitting the mesh it would be nice if the new vertices had interpolated colors.
And of course it is better to have the nearest color than not having colors.
Did you try the method I described for V5? Did it work for you?
Internally this is how the stuff works (a generalization) so you’ll have a better idea of what’s going on. A lot of what you mentioned you’d like happens automatically.
Mesh split/trim/boolean all use the same fundamental code. The process only happens on 2 meshes at a time. If more than 2 meshes were part of the input set(s) the process below will happen multiple times. Each time using another mesh of the input set with the result of the previous operation.
Intersect the 2 meshes (This is the step that currently causes the most trouble with the current mesh boolean type operations, especially on face overlaps and when there are complicated edge/edge, edge/vertex or vertex/vertex intersections. Clean transverse intersections generally work ok.)
For all intersection points, interpolate TCs, VCs, etc. based on the barycentric coordinates of the new vertexes and the values of the existing ones. This happens before the meshes are merged together so the interpolation is only based on an individual mesh and is not affected by any of the other meshes. This is also why it does not really matter what color the VCs are set to unless you’re doing a boolean operation where part of the mesh with no VCs to begin with will remain in the result. Then you may want a color that is similar to the color(s) of the other meshes. Unfortunately, that will not be easily automated so I’ll probably just use a neutral light gray in V6. A user can bypass this by forcing his own VCs with the method I described for V5.
Merge the two meshes together. This is where the VCs were/are getting lost. Rhino (opennurbs) meshes have a 1 to 1 relationship between the vertex array and VCs, TCs, vertex normals, surface parameters, etc. When there is a count mismatch the latter arrays are emptied. You might have had one mesh with 87 vertexes along with 87 VCs and 87 TCs that got merged with a mesh that had 56 vertexes and 56 TCs but 0 VCs. The merged mesh would have 143 vertexes, 143 TCs and 87 VCs. Since the 87 didn’t match the 143, it gets set to 0.
The non-manifold edges of the merged mesh are examined to determine what faces to keep and what to throw away. This is the only part that differs between the different boolean/split/trim operations.
Add the result(s) back into the documents and remove the input.
