iFrame visualization bug

Hi all,

I just want to report a bug that happens quite frequently using iFrames.

If you look at this screenshot, you can see that the pattern is ‘interrupted’ at some point:

This of course does not happen in the grasshopper model.
In fact - it does not even happen in the shapediver model.

When I export the geometry, it is correctly exported as it is supposed to be:

Since the geometry are exported correctly it is not a big deal. However, it is a bit annoying since it can confuse/frustrate the end user.

Cheers
Matteo

Can you send a link to the model that is producing the issue?
And can you tell me what kind of curves you are sending to the viewer? If you are sending nurbs curves, it is likely that the discretization of the curve by our viewer does not always produce the visual results you are expecting. You can always try to convert nurbs curves to polylines before sending them to the output components (just like nurbs surfaces should be converted to meshes).

Hi Mathieu,

this happens across most (if not all) of my models.

Yes. The problem is indeed related to NURBS curves, which I usually visualize by just leaving ‘Preview On’ on the relevant GH component. In this specific case, I suspect converting the Nurbs to very dense polylines just for visualization purpose may burden computation times a bit too much for my liking. I may give it a try, but I can also live with this problem for now.

Is Nurbs visualization something that you plan to work on in the future, or is it just going to stay like this because of feasibility reasons?

Cheers

In the upcoming new releases of our viewer and geometry backend we are dropping support for transferring display geometry for geometric objects which are not discretized. This means all continuous geometric objects like NURB curves or surfaces will be converted to meshes or polylines by our Grasshopper plugin, using default settings. In case those default settings are not giving good results for your application, the conversion can be done before feeding the geometry to the display component (or to a component which has preview turned on).

Reasoning for this: We had been using an extension to the glTF 1.0 transfer format, which allowed us to transfer NURB curves and surfaces. These objects were then discretized client-side, which turned out to be troublesome for various reasons (performance, inconsistent results).

Note: While we are dropping support for transferring continuous geometry meant for displaying in the WebGL viewer, we are adding support for transferring all sorts of geometric objects used in Grasshopper by means of sdTF.

1 Like