I have managed to load and display an external gltf file hosted on S3. Great!
However, when I add another component to the grasshopper canvas - a simple curve - and re-upload, I only see the curve and not the external geometry. I have set both the curve and the external display component to preview and the grasshopper setting to only preview the selected component is off (not sure that makes a difference).
So, in summary, I can render an external geometry, and I can render a curve, but not both at the same time.
Here is a snapshot of part of the grasshopper canvas. The curve renders correctly with the glTF2.0Display component. The external geometry is downloaded (I can see it in Chrome DevTools), but is not renderer. If I remove the glTF2.0Display component, then the external geometry is renderered.
I just tested this case and it worked as expected. Could you please share a minimal definition showing your setup so I can help further investigating this issue?
@mathieu1 I believe the scale disparity issue is actually related to ShapeDiver assuming that the DocumentUnits are meters. When this is not true, combining the output of a GrassHopper definition with an “External Display” component (glTF) leads to a size mismatch. In my case, the document units are set to mm and when ShapeDiver treats mm as meters, the output of the definition is so big that the External glTF geometry isn’t rendered at all (perhaps simplified away).
As I spent several days tracking this done, I believe it would be worth noting in the documentation for the External Display component, and possibly elsewhere.
My fix was to scale all of the components I want to render in Grasshopper by a factor of 0.001. Thus, in Rhino they appear tiny next to my glTF model (which by the glTF standard is always in meters), but in ShapeDiver they appear in the same scale as the glTF.
Ideally, one could specify the document units in the Grasshopper definition, possibly as a ShapeDiver configuration component. This would also be necessary if you wanted to introduce some sort of measurement tool in the UI.
Have you tried making use of the Tolerance Settings component? Make sure to have a look at the documentation article, in particular the yellow section, before you add it to your definitions.
Could you confirm that glTF geometry imported through the External Display component is also interpreted with the units specified in the Tolerance Setting? The documentation mentions geometry imported with “Import Geometry”, but doesn’t mention the “External Display” component.
(When I include the Tolerance Setting in my definition it has no effect, which leads me to believe the units are used to interpret both the Grasshopper output and the imported glTF geometry.)
This should indeed be the case, and if it does not work then we would consider it as a bug. I will try to create a test case for this when I have a moment; meanwhile let me know if you encounter any issues.
If it is true, it would explain the issue I observed earlier which I solved by scaling my Grasshopper outputs with a Scale component.
I think it is unexpected to scale glTF models. The specification of the glTF format is clear that the units are meters:
Interpreting the units of a glTF in a way that is inconsistent with the specification can result in surprising and really difficult to find issues. Here is an example workflow that would break (basically what happened to me):
Set document units to mmImport geometry “G” from a 3D scale
Create a Grasshopper definition that builds on point inputs from “G” (later internalized)
(At this point, in Rhino, everything lines up.)
Add a ShapeDiver External Display component that sources geometry G in glTF format
Upload the definition to ShapeDiver
Expected output: The Grasshopper output geometry is in a consistent scale with the imported glTF geometry.
Actual output: The imported geometry is 1000 times smaller than the Grasshopper output. In some cases, the imported geometry is not even visible so that it is not obvious that there is a scale issue (it can be easily confused for a S3 access issue, or a CORS issue, or something else).
Let me know if I understand correctly: since the glTF 2.0 specification specifies meters as units for storing geometry, you would expect the External Display component to take this into account, as well as the units specified in your Grasshopper model (using the Tolerance Settings component), in order for the viewer to scale the glTF in the scene from their native meter unit to the unit you specified.
Does that sound like a sensible way forward?
Alternatively, we could just add an input to the External Display component that allows to specify a scaling factor.
Yes, exactly: scale the glTF from their native meter unit to the units specified in Tolerance Setting (or the default, if the component is not used).
Allowing the scale to be overriden seems like a separate topic, and if it were to be used as a fix for the aforementioned issue, it would seem more like a workaround to me. It would also not prevent the confusion as some users would still expect the imported glTF to be in meters as per the spec (and potentially not realize there is a scale issue to begin with). Besides, I think scaling can already be achieved through an Import Geometry component which can be pointed to a URL (and made invisible if desired to avoid showing a file upload parameter).
