Different results

Here have one more problem:
that`s how model looks in Rhino

everything is fine
, on your platform
2024-06-10_16h01_57 - fine as well

and loaded through API

as you can see on last image gems have certain offset, like it moved away from ring center all of them but the first one in a list.
To orient gems I`m using script I got from support.

Also we got a problem that somehow changed Indexing of “uid” and “material” formats of geometry output.

can it be controlled by grasshopper solution or we need just to develop solution on JS?

Which version of the viewer API are you using?

Could you post an example ShapeDiver model that looks as expected on the platform and a sample page where the same model embedded looks different?

The ids of assets can always change between two uploads. We recommend identifying geometry and materials by name. You can name geometry by naming the Display component you are using, and you can name materials using the Name input of the glTF 2.0 material component.

Correction about my above message: the uid of outputs stays the same between uploads, as long as the components in Grasshopper are not replaced: Outputs on the API

In any case, I would still recommend a name-based approach as I suggested above.

Which version of the viewer API are you using? - we are using 2.40.0

We have an entire site based on the second version. Although we have a complete solution for migration, it does not fit our partner’s needs. He is still considering migrating to the third version, which may take some time. We hope it happens ASAP.

We need to understand why copying nodes from a fully functional Grasshopper script to another results in different outcomes, even though the same techniques are used. Specifically, we need to identify which nodes could be causing these issues.

The main problems is that we can’t apply custom material via the API anymore, and unexpected offset of Gems and it doesn’t give any kind of error, so we cannot track it down. Data output nodes work well, and we can collect all needed data. The problem seems to be with the C# node using the API in version 2.4.

Through testing and debugging, we found that the only difference is an index issue. We would appreciate any guidance on resolving such issues.

This issue might be related to the glTF version output by your definition. For backwards compatibility, some outputs still output glTF 1.0 if you don’t explicitly switch them to version 2.

You can try to use the top-level ShapeDiver menu item “Set default glTF version” and switch to glTF 2.0 in your document, which should ensure that all outputs use the same glTF representation across your various definitions.