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.
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:
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:
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.
@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
Hi @chris,
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!
@wim,
i’ve just tested the new version you mentioned.
I can say that there is an improvement but not fully resolved.
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).
Thanks,
-A.
@wim ,
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.
Hey all + @wim
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?
S
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?
I have found a weird solution.
If I turn on the “Use advanced GPU lightning” option in DIsplay Options the colors are displayed even in shaded view.
!
