Hi,
Happy with the VisSet additions.
Want to report a couple of issues i’ve found.
In LBT1.6 when i try to bake to Rhino i get the following error:
In LBT1.5 i was able to bake.
In LBT 1.5, when applying the Legend_2D_parameters component, the bake disregarded this legend and baked the “original” one. Is this how it is supposed to work?
Thanks,
-A.
UPDATE: Updated to pollination 1.22.0 and issue 1 is solved (thanks).
In the meantime i’ve found another issue/bug.
When using the LegendParCategorized this is how i get the legend (is ok):
Legend2DParameters with the VisSet component the order of the legend is inverted, like so:Thanks,
-A.
Thanks for testing this all, @AbrahamYezioro . It seems like we have one issue that is already resolved, one which may seem like a bug but is not really, and one real bug here.
Starting with the “seems like a bug”:
Yes. There is no native Rhino document object for 2D legends so they cannot be baked into the scene using only LBT-Grasshopper. However, the Pollination Rhino Plugin has a Rhino document object for an edit-able screen-oriented legend, which has a lot of awesome functionality thanks to @MingboPeng. Notably, there’s a whole UI for changing the legend parameters, which will also update the colored analysis geometry in the Rhino doc. So, with the Pollination Rhino plugin, you’ll be able to save your results in the Rhino document and come back later to tweak the visualization. I think we’ll also eventually allow bringing the results from Rhino into Grasshopper for further analysis/post-processing. But, whatever the case, we will definitely be supporting baking 2D legends for anyone that has the Pollination Rhino Plugin installed and you can follow the discussion about it here on the pollination forum.
For users of LBT-Grasshopper, I wasn’t sure whether it was better to bake it without any legend or with a 3D legend given that lack of an official 2D legend object. But 3D seemed better than nothing and let me know if you disagree.
This definitely seems like a bug but I would infer that it is specific to the Legend Parameters Categorized. If you have a file that recreates it, that will help me fix it faster. Otherwise, I’ll try to recreate it on my end soon.
Hi @chris,
Agree. Thanks for the explanation.
Attached an example.
LegParCategorized_VisSetIssue.gh (45.9 KB)
Thanks @chris,
-A.
So, the issue was bigger than I thought and it affects all vertical legends in 2D. I guess that I failed to see it because my test case had a horizontal legend. In any event, I just pushed a fix for it:
This one is probably big enough for me to update the installer and I’ll try to do this after the fix makes its way through the CI in an hour or so.
Hi @chris,
Updated to installer 1.23.0 and also with the Versioner, but … the issue is still there:
I’m doing something wrong?
Thanks,
-A.
UPDATE: I edited the legend.py manually according to the fix in the github and it works now. The file (legend.py) was not updated, meaning the installer (or versioner) for some reason is not updated either.
Hi @AbrahamYezioro,
@chris 's update is done after the installer 1.23 release. It should be included in the next installer release.
Thanks @mingbo!
I did, after the installer, an update with the Versioner … which didn’t worked either. Probably the change wasn’t yet synchronized. I’ll try again … or wait for the next installer release.
Thanks again,
-A>
Hey @AbrahamYezioro and @MingboPeng ,
There’s a hiccup in our CI and so the fix has not made it into a format you can get with the Versioner yet. Hopefully, I’ll be able to see this all through over the next couple of hours and then I can update the installers.
The fix is now available with the Versioner. I’ll be updating the installers shortly.
The new istaller (1.23.1) is not there yet but the Versioner is. Thanks!!
If i’m here, i want to ask about the _vis_set input. It is supposed to accept Lists but when i do input a list, i get an error. I reported this in a different thread. It looks like this. Wanted to plot 2 wind profiles, one with the original epw data and the other with the WindSpeed component.
Thanks,
-A.
FYI, @MingboPeng . I triggered a new release of the Ladybug Tools installer. So, the next time that you build the Pollination installer, the fix should be there.
Hi @chrisand @mingbo,
The 1.24.0 is out there now.
Thanks,
-A.
Hi @chris ,
I decided to report this issue here instead of opening a new thread.
ColorFaceAttr i noticed that two attributes are not showing correctly: U-Factor and R-Factor (see image above).Thanks,
-A.
Hey @AbrahamYezioro .
Sorry for the late response and I just pushed a fix that will get this to work correctly:
However, I’ll note that the particular property you’re looking at there is a bit different because it tries to give you the exact U-Factor of the geometry, including the angle at which it is oriented, how tall it is, and (if there is a frame on the window construction) how much window frame there may be given the window geometry. This is useful when you have a lot of skylights with different slopes or window constructions with frames.
But, more often than not, you’re better off just taking the Construction U-Factor instead of the U-Factor of the exact geometry. The Construction U-Factor is always taken for a vertically-oriented, 1-meter-tall sample of the construction. So it is tied to the construction layers and will not change with the geometry across the model. This makes it quick to calculate for large models and easy to display in other formats (like VisualizationSet). So, especially for your simple model there, I’d recommend just using the Construction U-Factor.
Thanks @chris,
I’m adopting your tip for using the Construction_U-Factor.
Saying that, FYI, the U-factor option gives me an error now in the VisSet component:
- Solution exception:Expected number of data set values (7) to align with the number of geometries (8).
Sometimes, the legend remains even though the error (i.e. if i choose first the Construction U-Factor, and then change to U-Factor, or any other attribute that doesn’t give an error).
Not critical, but to be checked.
-A.
Thanks @chris,
I don’t know if the update pass through or there is something else wrong. It’s still not working for me.
One difference with your example is that mine is built from scratch in GH, but i don’t think this should affect at all the output.
-A.
I just merged the fix a few minutes ago and it should now be available via the LB Versioner.
