I wanted to do a quick thing for a friend wherein I’d have a grid of spheres in which each sphere would be colored a single color according to a bitmap “overlayed” over the entire grid (I also raised the spheres but that’s essentially independent of the coloring and not where the problem lies).
I thought at first that I’d use the image sampler to attach some sort of “user info” to each sphere and then reference that info in a Brazil material but I couldn’t find anything in Brazil that would reference the user info so I was scratching my head for a while until I thought that if I set all the UV coordinates in each sphere mesh according to it’s relative position in the grid, then when I used the bitmap texture in Brazil with that bitmap, the entire sphere would map to the proper position in the bitmap texture and presto - each sphere would be colored correctly.
So I used a C# component to implement the following code:
private void RunScript(object mesh, object U, object V, ref object A)
{
Mesh meshIn = (Mesh) mesh;
Mesh meshOut = new Mesh();
double u = (double) U;
double v = (double) V;
meshOut.CopyFrom(meshIn);
meshOut.TextureCoordinates.Clear();
for (int i = 0; i < meshIn.TextureCoordinates.Count; i++)
{
meshOut.TextureCoordinates.Add(u, v);
}
A = meshOut;
}
and then pipe in the UV values from the output of the Grid component (using the Paneling Tools plugin for GH). So I tried this and in the Rhino display it looked great:
But when I actually tried to render, this is not what I saw at all:
Actually, when I did a closeup on the render it showed the moose bitmap being displayed on each sphere individually - as though no UV mapping had been applied by my C# component at all. Here is the GH script:
and the single material for all the spheres simply had a bitmap texture with a colored version of the moose head. Oh, the value of the number at the lower left is 10 which means that the grid is across a square from (-10,-10) to (10, 10).
Does anybody have any idea why this isn’t working? I could maybe get what I want by coloring the vertices in the sphere meshes and then using the VertexColor texture in Brazil but I haven’t tried yet and I’d still be left wondering why I’m getting different values between the rhino display and the Brazil render. If I am correctly setting all the UV coordinates to the same value then it should be impossible to get anything but a solid color on each sphere.
I’ve included a zip of the gh file, bitmaps and Rhino file. It requires the panelling tools (though they’re only used for getting an array of points which could also be done easily by Subdivide Surface on a rectangle). This works fine in Rhino and V-Ray as long as I have them as the current renderer when I bake. Rendering in Brazil seems to permanently screw up the scene and any renders afterwards will produce the same erroneous result as Brazil.
If you set the texture mapping on the spheres to Planar and use the bounding box option to set the size it works. I bet if you set the mapping in the script portion of the GH file to planar you can avoid this post process… but I’m not sure how that would be written.
Hey Brian - thanks for helping me with my last question and the quick response! Always nice to have a great, responsive support staff!
I think (though not sure) that what you’re saying is overlay the entire group with a planar mapping which will project the bitmap onto the group as a whole. This really isn’t what I’m looking for. This causes details in the bitmap to be mapped onto individual spheres so that each sphere is multi-colored (at least the ones which cross edges in the bitmap) whereas I want each sphere to be a single color - the color of the point the center of the sphere rests at in the original bitmap - i.e., to “pixellate” the image using the spheres. Here is a closeup from the proper render in Rhino render:
Notice that each sphere has a single uniform color (actually some look a bit multicolored but these are shadows, not textures). This is why I set all the UV coordinates to map to that individual point in the original bitmap - a triangle with all three UV coordinates set to a single spot in the bitmap should come out uniformly in that color and since I’ve set all the UV coordinates in the mesh to that single spot, the entire mesh should come out with that color as it does in other renderers. The planar mapping that you’re suggesting strips out all the UV coordinates which I’ve carefully set in the C# component of the grasshopper script.
I thought that potentially it was due to exact equality between UV coordinates in all vertices on the sphere (even though I can’t imagine why this would cause a problem) but I tried jiggling them by a small amount and the problem persists.
The most worrying aspect of it is that Brazil seems to be actually changing the UV coordinates on the mesh since once it gets hold of the spheres their UV coordinates seem to be permanently changed so that Rhino renders differently depending on whether Brazil has rendered the scene before or not. Try the following experiment - set the current renderer to rhino, bake and render - everything is as I want it. Save the file. Reopen the file with rhino set as the current renderer - everything looks fine in the preview. Change the renderer to Brazil - everything screws up without even a render, and if you do render the render is bad also. Save the file, change the current renderer to Rhino and read that file back in. It’s goofed up so just by changing the renderer to Brazil something (which appears to be the UV coordinates) gets changed and that change persists through a saved file. This seems pretty bad to me.
I’ve asked the Brazil developers to take a look at this but in the meantime I have a workaround that will help.
1- Select the mesh spheres and Ungroup
2- With all the meshes selected use Join to make them one mesh
3- Run the ComputeVertexColors command on this mesh
4- Replace the color texture in the assigned material to a Brazil Vertex Colors texture
5- Render with Brazil
Thanks again Brian! I made one brief foray down the vertex coloring route which didn’t seem to work out but I didn’t pursue it very far. I’ll revisit. A slight problem with it is that I probably want to use the mapping again in other places. In particular, I was thinking of using it to guide the emissive component so the spheres making up the moose glow. I don’t think I’ll be able to do that using vertex color. Anyway, it’s worth checking out just to familiarize myself with that aspect of Brazil.
I hate to keep harping on it but, again, the crazy thing to me is that Brazil doesn’t just give a bad render - it seems to destroy UV coordinates in the process. A render should be a read only operation with respect to the scene being rendered so that seems really something you’d want to avoid/fix. If it does get fixed, I’d love it if you could give me a heads up.
This is a bug in the C# SDK for creating texture coordinates. The problem is that the TextureCoordinates.Clear function doesn’t clear enough information. I have logged a bug and I hope this will be fixed in the next service release.
Did get it going with vertex colors though I made it part of the C# script rather than doing it manually in Rhino. Final result is what I was aiming for though it’s not quite as cool as I’d hoped it might be. That’s my own fault though…
