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.
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 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.
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 !
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.
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:
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.
I assume that the version that you updated to was the final (i.e. not a candidate) Service Release 7. One of the developers lets me know that he pushed a fix that he believes will fix the black geometry issue into the RH6 SR8 branch. A first Release Candidate is available if you subscribe to the Service Release Candidate update stream in Rhino Options > Updates and Statistics > Update frequency.
Could you test with that version?
It would explain why I am not seeing the issue here - I’m running an in-house 6.9 version.
Remember to reinstate factory-default display mode settings when you test!
Using the default factory settings now shows the previous black mesh (good news) … but, the “good” mesh is now almost burn as for the color it shows. See above, circled red. This happens for all display types (wireframe, shaded, rendering).
As for the rendering display, you still need to use @OmidmRashidi’s advise in order to show the meshes (all of them): You need to hide the ground, otherwise nothing will be shown (as for both meshes on the above example).
Sorry for the confusion. Yes, the default state is to have the Advanced GPU setting OFF.
That’s good to know that one of the developers has pushed something for SR8 that is currently in the candidate version. I’ll test for myself once I get the chance and confirm whether I get something similar to @AbrahamYezioro .
I just tested the release candidate and the core issue has been addressed in my opinion. The mesh is displaying the correct colors whenever it is previewed from Grasshopper, which was the main cause of our concern.
@AbrahamYezioro , the burned mesh color only arises once you bake the mesh in shaded view. I could live with this except that, once the mesh is baked in shaded view, it changes how the original mesh is displayed in Grasshopper (the Grasshopper preview mesh displays with the burned color), which seems very buggy to me. So it seems we aren’t quite at a final resolution.
Still, in all cases, the Advanced GPU Lighting fixes the situation.
I just wanted to add that it seems McNeel seems to have implemented the fix in the latest service release. The burned mesh still happens when you bake the mesh without having the advanced GPU setting on but, otherwise, the core issue is addressed.
Going to bring this up again as a warning to the community, @KitElsworth and I have just discovered that with the latest release from 8/28/2018 (SR8 something something), the bake option is not working at all for meshes. Previous releases are working fine for me, and in all instances the use of the deconstruct and reconstruct mesh is working in gh preview.
Anyone else having issues with baking meshes in the latest series release - and suggestions for how to fix it?
There have been many changes to meshes and GH. Could you change your update frequency to check for Service Release Candidates and confirm that there are issues with version 6.9.18253.21101 that was released 2 days ago?