I’m using the GH connector to send some stuff to Speckle; when sending Breps I get an ugly version of the geometry being shown in the viewer, however if I explode these in Breps in GH and send the resulting surfaces I get nice clean geometry. This matches what I get when I send the geometry via Rhino. Is this a bug, or is it just how Breps in GH get translated?
I feel like this is related to ambient occlusion we’ve recently implemented. Just to be sure, can you share the stream or Rhino/Grasshopper file you used?
@lukxfnz we’re thinking this might be a problem with the normals of the geometry, are you able to check?
Otherwise if you share the model we can have a look as well
The viewer has the capability of rendering materials with the following properties:
Diffuse (aka base color)
Opacity
Metalness (aka reflectivity)
Roughness
Emissivity(EDIT: looks like the viewer doesn’t render this one, but other apps can)
However, the question is, does our GH connector send all these material properties?
GH is not my area, but from the quick test I’ve just performed, it doesn’t look like we send any render material data; No color, transparency, or anything.
I’m not sure if this is a bug, or if GH simply doesn’t have access to Rhino’s Render Materials. Hopefully @AlanRynne knows more.
I do however know that from our Rhino connector, we output all these properties, at least for Rhino 7.
For Rhino 6, just diffuse color, emissivity, and opacity (faked for a few presets)
@Jedd Thanks a lot for your answer… I noticed that the objects exported from rhino can store the textureCoordinates that allow some sort of reflectivity on the viewer. Can we send this as extended properties of an object from grasshopper?
Grasshopper doesn’t send any material data because grasshopper-generated geometry does not have any of that data by default.
On the Rhino SDK, material’s are not attached to the Geometry object but rather to the RhinoObject they are wrapped in. Since Grasshopper does not use these RhinoObject instances (rather the raw Rhino.Geometry classes) the only solution here would be to create Speckle Materials in grasshopper and attach those to the already converted Speckle Meshes in their renderMaterial property. This can be done by using our extend node, or with in a simple Python script for more flexibility without the need of referencing our libraries.
As for the texture coordinates, those are in fact attached to the Meshes themselves, but grasshopper does not compute texture coordinates, and as far as I’m aware any grasshopper-generated mesh will have no texture coordinates by default. There are ways to generate them on the Rhino SDK (and some Grasshopper nodes afaik) but this falls out of my area of expertise.
You could also attach a list of texture coordinates by extending the objects, but I’d recommend setting them in Rhino before converting to Speckle.
Final thought:
As I was writing this I realised there is one edge case where we could be sending materials: referenced geometry from a rhino document. In this case, I’m fairly certain we could attach the material automatically from Grasshopper, but that will only work if you don’t further process it in Grasshopper (as it will loose the reference)