Thanks again, @mostapha. I’ve added this thread to our McNeel internal conversation.
@EmmanuelR, do you know which version of Rhino 6 you were running before your update?
1 Like
Hello @wim,
I’m afraid I can’t but I can tell you that the version I used was the trial version downloaded around the 20th of june.
Thanks for your help
I’ve noticed too for the legend but in my case GH geometry never displayed in rendered view (unless it has already been baked in rhino).
Is there any settings I missed ?
In my case i kind of remember that the legend showed OK on the viewport a couple of versions ago. Right now i’m using Version 6 SR6 (6.6.18177.16151, 06/26/2018). Can’t remember the number …
I played around with the settings on Rhino … but can’t remember what was it. I’ve found some discussions in the Grasshopper discourse, specially some David Rutten comments.
-A.
@wim in particular and anyone else that is experiencing this issue,
I am pretty certain that this is a bug in Rhino 6 that was recently introduced. It seems that we have all been experiencing it since Tuesday and I’ve noticed that this is around the time when the last Rhino 6 update was checked for all of us (assuming that you use the default update frequency of the Service Release):
To give a more detailed description of the issue, the meshes are not totally black but just have very dark colors (it seem’s they are displaying at somewhere around 1/100th of their usual lightness). If you have a good screen quality, you should be able to make out some minor color variations in the mesh image here:
The correct color properties are there in the mesh and it seems to only be an issue with their display.
Baking the geometry and going over to rendered view seems to be the best recommendation that we have come up with on this thread so far (short of going back to Rhino 5). So this is what I would recommend to everyone for the time being.
@wim , let us know if there is anything else that we can do to help get the issue solved.
Hi,
I was in doubt of opening a new discussion or add to this one. Well …
This is not black geometry but related to display issues.
I’m checking a zone geometry types with the HB_decomposeByType component.
Next image shows that the Preview is OFF for the component. Only the Windows are shown with the PreviewGeometry. The color of the window was set with the ColorSwatch as blue. The image shows that for Wireframe and Shade display some windows are rendering as expected and some are not (white or magenta colors).
Next image, following above description, shows Rendering display. For this case ALL geometry shows, even though only windows are supposed to be.
-A.
Credits for the geometry to @bussey.philip. I was checking his discussion here, so decided to continue with this thread.
I’ve found another thing here following @chris comment on baking geometry.
If you bake the geometry it shows as already said. But if you delete the baked geometry on Rhino, THEN it will show fine from GH in the viewport on all display types (wireframe, shade, render).
Weird.
-A
I might have a wierd solution to view the meshes color properly.
I just noticed that if I forgot to hide preview of Cutom Previews linked to the Decompose Based On Type component (anyone follow me?), then you can see colors through surfaces who do have transparence. Here is the result :
Well we’re not going any further but I hope it can help you @wim to find where the issue is coming from.
So it seems Rhino 6 just pushed an update but this issue still is not fixed.
If we can’t get this fixed soon, I’ll have to write a workaround for the next release of Ladybug that bakes all meshes in to the scene and brings them back to GH. This will make me really sad.
@wim are there any updates on your end or anything that we can do to help you here like providing a snippet of code to reproduce the error?
I found a cleaner workaround (in lieu of baking the geometry) for those still experiencing the issue.
You can just pass the colored mesh through a “Deconstruct Mesh” Grasshopper component and then pass the result into a “Construct Mesh” Grasshopper component like so:
@wim , Knowing this, it seems likely that the bug is with the VertexColors setter in RhinoCommon, which is what Ladybug is using to color the mesh. From what I can see in the SDK docs, it doesn’t seem like this property is deprecated:
https://developer.rhino3d.com/api/RhinoCommon/html/P_Rhino_Geometry_Mesh_VertexColors.htm
Perhaps another way we can fix this is if we know what methods are being used to assign the mesh colors in the Native GH Construct Mesh component, we can use that instead.
@chris @wim @EmmanuelR ,
I just changed Ground plane settings to Custom and display works without any problem.
3 Likes
Following @OmidmRashidi, which showed the Rendering option on viewport, i checked the other 2 (Wireframe and Shaded).
Here is the setting i gave to get the display right:
-A.
8 Likes
Wonderful! Thanks for finding this solution @OmidmRashidi and thanks for confirming it @AbrahamYezioro . This makes any fix that I’d have to implement on our side a lot easier.
So, if we don’t hear any word from McNeel that the bug has been addressed, I’ll just have Ladybug_Ladybug automatically change this Rhino setting whenever it runs. So, whether the solution comes from McNeel’s end or ours, it seems we are just days away.
1 Like
Hi @chris, all,
I got back from my long vacation yesterday and have been trying to look into this today.
Other people at support at McNeel have been looking into it previously and I’m also trying to find you if that has surfaced anything…
I’m confused though. I do see an issue where GH geometry gets clipped - which I think is what has just been reported in this thread:
In a perspective view, with certain angels, I can get the complete graph to be visible in RH6 but it gets clipped when I rotate to other angels.
Is that the issue that is being reported in this (“Black geometry”) thread?
I ran the gh file that was posted here …
… on my hardware with (1) the Rhino version from before I left on vacation, then (2) updated Rhino, then (3) updated LB but never got it to display “Black geometry” as in the picture in that post.
So, at this point, I am wondering:
- are there 2 separate issues being discussed?
- are the display modes that cause the black geometry issue (wireframe and shaded were mentioned) factory-default modes?
Thanks for any clarifications!
wim
@wim,
Thanks for getting back ans start checking.
Those are 2 different issues. From my side i can say, and i may say this is the same for all other users involved in this discussion, that the issue 2 (black geometry) happens with the default factory settings. Until yesterday we get into changing the settings for all viewport modes (or at least the 3 more important) and then we started to get the right image on it.
About the clipping image i also get it but, as said, it is another issue and i’m glad you are taking care of it too.
Best,
-A.
1 Like
@wim,
I can confirm that the error (black geometry) is now solved, assuming you apply the settings described in this description. For the other issue, I can’t say
Thank you for getting this issue solved !
Best,
Well, thanks - but I haven’t really done anything.
In order for McNeel to be able to solve these issues, we need to be able to reproduce them and, so far, neither support in Seattle nor myself are seeing the black geometry issue. The clipping, yes.
Trying to narrow things down here, I’ve extracted the mesh from the first post where @mostapha reported the black geometry issue (here) and put it in this gh file: BRE VSC Analysis TEST_AY - Mesh only.gh (7.0 KB)
@AbrahamYezioro, can you confirm that this mesh displays black on your system with factory-default Shaded mode?
FWIW, the complete file shows like this in factory-default Shaded on my system:
@wim,
The file you attached looks fine in my machine using default values.
The thing is, as i reported above, that AFTER you did some manipulation with the mesh (bake, take it to another file as you did, and more) it looks fine.
BUT if you start creating some new mesh, then you get the issue. See the same file of yours with an added mesh.
BRE VSC Analysis TEST_AY - Mesh only 3DMap.gh (391.1 KB)
The images below show the differences.
Default Values. Your isolated mesh shows (a bit dark) but the new mesh doesn’t:
Changed Values (GPU advanced lighting ON):
Let me know if i can help further,
-A.
@wim ,
I just wanted to ditto everything that was said on the post this far and confirm that you will only be able to recreate the error if you build a mesh from scratch in Rhinocommon and assign colors to it using the VetexColors property on the mesh object. The easiest way that you can get such a mesh is with the ladybug components in Abraham’s file.
You also need to make sure that the GPU Advanced lighting is on, which as mentioned, is the Rhino factory default setting.
One way to solve this is just by making this not the factory default setting or having a Ladybug component automatically change this setting for the user. However, I imagine that there’s some reason why this is currently the default setting so, if you can solve it on your end, it’s probably best for all of us.
@chris, @AbrahamYezioro, thanks guys!
I think so, too.
Just to get that straight, the factory-default is that this setting is OFF - but I’m sure that’s what you meant.
I’ll get some more bigger brains at McNeel to look at this.
wim