Visibility of Ladybug Tools 1.3 output in Rhino 7?

Kia ora koutou

I have in the last couple of days dealt a significant Rhino 7 frustration. This is the visibility of my LBT 1.3 graphics in the Rhino screens. When I first did this on my home development machine there seemed to be issues with what I would interpret from my AutoCAD days as a front and back cutting plane within which the graphs sometimes were visible. Switching view mode from wireframe to render and back again mostly solved this. I had no idea what to search for in a visibility or camera setting n Rhino.

On our student machines, the issue was even more frustrating. Nothing was visible.

What we have just discovered is that if we use one of the room or face attribute displays, that I have now added to the student modelling script to ensure a certain level of Quality Assurance, then switching these via a gate command fed through a custom preview, then the base model is made visible and the Rhino view settings are altered so all our graphs are visible!

I offer this first as a work around for this visibility issue, and then as a query to @mostapha and @chris in case this triggers some kind of inspiration as to what viewport settings might need to be set in Rhino 7 so they match Rhino 6.

The visibility controls:

The operational end of the visualisation:

M

Hi @MichaelDonn ,

I haven’t experienced any visibility issues on my end. Did the issue correspond to a certain recent update of Rhino? Also, is the issue just with mesh display and not lines/curves or Breps?

Kia ora @chris

We have recently upgraded the student system to Rhino 7. And in the process also developed the script we are using to run with version 1.3.0 of LBT.

What we found was that on some machines (mine at home for example) if we were zoomed back from the XY plane in Rhino all the objects - graphs, annotation and model shaded with heat loss etc were visible, but as we zoomed closer to a particular graph it disappeared. In perspective view we could see slices of the grahics on the XY plane, reminiscent of what I used to experience with AutoCAD/3DS Max in terms of cutting planes associated with a view camera. We could find no solution in the display commands / view controls for Rhino. I put this down mostly to my amateur status as a Rhino user. I could sometimes fix the issue by switching from wireframe representation in the Rhino window to Rendered view, and then back.

On the student computers the issue was worse in that no matter what we did the graphics, mesh, wires annotation etc did not appear.
We are using this version of Rhino 7:
image

Because I have, in the process of implementation of LBT 1.3.0 added some room/surface visualistions to enable the students to check their models prior to simulation, and because I have used the gate option to control when these visualisations are visible, I discovered that turning these on and off made all the output graphs, output text and heat loss per surface outputs from LBT visible!
So, when I run the script I produce these graphs:


If I zoom in, they disappear:

If I Turn on the face display options:

Connected to the following display object:

THEN, I get the graphs displaying again!

I now just tell students to do this…to solve the problem. According to my colleague, it seems that geometry (in)visibility in certain circumstances is a posted about issue for people outside of our school, so it seemed potentially of interest / use here.

What I was curious about, and hence my reason for adding you and Mostapha to my post, was that you may understand from your coding what actual setting in Rhino we are affecting by using your excellent visualisation tools.

Hi @MichaelDonn ,

This issues that you describe are definitely on the McNeel side of things and it looks like it has to do with the rendering of Grasshopper objects in the Rhino scene.

As a general rule, the LBT plugin doesn’t change any of the visibility or rendering settings and we leave that up to whoever is using the software. If the issue becomes a big pain point, it might be worth asking the question on the McNeel Forum. If you have a video clip of the issue, I am sure that would help explain it well.

Thanks for taking the time. I figured it was McNeel, but rather hoped you had some standard visibility code that might give me a clue - perhaps to then post to McNeel.

Nga mihi

m

Hi Michael -
I only have the legacy versions installed but if you could internalize something in Grasshopper so that LBT isn’t required (or, if the issue is still present when you bake to the Rhino document, a 3dm file) and post that here, I can take a look.
Also, please run the Rhino SystemInfo command and copy-paste the result here.
Thanks,
-wim

Hello @MichaelDonn just a question to find out if it might be related to some problem I’m having with Grashopper and the Display in Rhino.
Do you use a 3D connexion device or something familiar while this occurs?

Kia ora @Martin6

We have no 3D connection / connexion device attached. These are merely run of the mill Dell student lab machines

M

Hi there.

I have made a small discovery which I think centres the visibility problem in the mix of settings for Rhino 7 that we have created in running through the standard install, and the use of LBT 1.3. I have created a small animated visualisation to show what we encounter.

Essentially, the LBT 1.3 script creates all the input geometry, runs the analyses and outputs the graphics to Rhino 7. In this situation, controlling what we see in the standard Rhino ports is something over which we have limited control. Sometimes they are there. Sometimes not. When we first run LBT 1.3, not.

The script has a bunch of model visualisation tools provided to help the users visualise the model prior to running the model (e.g. a graphic representation of the rooms and their R-values). Turning these on and off seems to trigger the visualisation of the other objects. But even this is not reliable. Zooming in and out amongst the various graphics produces oddly variable visibility.

In the past 24 hours, we have discovered an apparent cure: draw any object in the Rhino window. All the objects appear AND zooming in an out has no effect on visibility.

I have created a youtube demonstration of the phenomenon (not a solution, but a way of working around the issue, so if this provides insights into what Rhino settings we need to change, I would be ever so grateful):

1 Like

@wim I am wondering what internalise something in Grasshopper means?

I am not interested at all in being able to view in Rhino the geometry I create for input to LBT - I am only interested in the LBT visualisations of the objects.

The Rhino SystemInfo report is as follows:

Rhino 7 SR9 2021-8-10 (Rhino 7, 7.9.21222.15001, Git hash:master @ 190335c3fb65efe86c302714a8959a7dadfe667b)
License type: Educational Lab License, build 2021-08-10
License details: LAN Zoo Network Node

Windows 10.0.18363 SR0.0 or greater (Physical RAM: 32Gb)

Computer platform: DESKTOP (Hosting Remote Desktop session)

Standard graphics configuration.
Primary display: Microsoft Remote Display Adapter (Microsoft) Memory: 0MB, Driver date: 6-21-2006 (M-D-Y).
> Remote Desktop display device with 16 connection(s)
- Windows Main Display using connection #0
Primary OpenGL: NVIDIA Quadro K2200 (NVidia) Memory: 4GB, Driver date: 9-13-2021 (M-D-Y). OpenGL Ver: 4.6.0 NVIDIA 472.12
> Accelerated graphics device with 0 adapter port(s)
- There are no monitors attached to this device!

OpenGL Settings
Safe mode: Off
Use accelerated hardware modes: On
Redraw scene when viewports are exposed: On
Graphics level being used: OpenGL 4.6 (primary GPU’s maximum)

Anti-alias mode: 4x
Mip Map Filtering: Linear
Anisotropic Filtering Mode: High

Vendor Name: NVIDIA Corporation
Render version: 4.6
Shading Language: 4.60 NVIDIA
Driver Date: 9-13-2021
Driver Version: 30.0.14.7212
Maximum Texture size: 16384 x 16384
Z-Buffer depth: 24 bits
Maximum Viewport size: 16384 x 16384
Total Video Memory: 4 GB

Rhino plugins that do not ship with Rhino
C:\Program Files\Chaos Group\V-Ray\V-Ray for Rhinoceros\V6\VRayForRhino.rhp “V-Ray for Rhino”

Rhino plugins that ship with Rhino
C:\Program Files\Rhino 7\Plug-ins\Commands.rhp “Commands” 7.9.21222.15001
C:\Program Files\Rhino 7\Plug-ins\rdk.rhp “Renderer Development Kit”
C:\Program Files\Rhino 7\Plug-ins\AnimationTools.rhp “AnimationTools”
C:\Program Files\Rhino 7\Plug-ins\RhinoRenderCycles.rhp “Rhino Render” 7.9.21222.15001
C:\Program Files\Rhino 7\Plug-ins\rdk_etoui.rhp “RDK_EtoUI” 7.9.21222.15001
C:\Program Files\Rhino 7\Plug-ins\rdk_ui.rhp “Renderer Development Kit UI”
C:\Program Files\Rhino 7\Plug-ins\NamedSnapshots.rhp “Snapshots”
C:\Program Files\Rhino 7\Plug-ins\RhinoCycles.rhp “RhinoCycles” 7.9.21222.15001
C:\Program Files\Rhino 7\Plug-ins\Toolbars\Toolbars.rhp “Toolbars” 7.9.21222.15001
C:\Program Files\Rhino 7\Plug-ins\3dxrhino.rhp “3Dconnexion 3D Mouse”
C:\Program Files\Rhino 7\Plug-ins\Displacement.rhp “Displacement”

Just a quick update: while the work arounds work, it turns out they do so temporarily. I have looked through the whole NVIDIA display controls and the recommended Rhino settings for 3D display, and can find no reason for this occurring with Rhino 7 + LBT 1.3 but not Rhino 6 + LBT 1.2. In fact, I can find that if I have 4 windows looking in plan at 4 different parts of the Rhino XY plan to see different, widely spaced, graphs then work around 2 has to be done in each window.

NOTE: the temporary fixes are:

  1. turning on and off one of the LBT visualise surface attribute or room attribute widgets OR
  2. draw a simple Rhino object in the Rhino window where the LBT output graphs and graphics are supposed to be displaying

Kia ora koutou

I have today run the SystemInfo command before and after running one of the LBT visualise options. Prior to turning on and off visualise the ColourFaceAttribute viewing tool set to the Boundary_Condition attribute, none of the energybalance or other graphs were visible. Afterwards, they all were. However, the Rhino SystemInfo data saved to two separate files produced two identical files - there was no state change of Rhino apparently!