We (account: abiya-mt) have uploaded a definition that makes use of the C# script that associates a single geometry (mostly meshes in this case) with multiple transformations.
It is working correctly on our local PCs (the geometry is previewed correctly when selecting the SDDisplayGeometry component) but it seems there are some problems on ShapeDiver.
You can check the latest three definitions (private models) v0.41e, 0.41f and 0.41g - They are exacly the same, the only difference is that in some cases the output (Geometry with transformation) has been internalized before being output to the SDDisplayGeometry component.
version 0.41g: all the outputs (frame and patterns) have been internalized before being sent to the SDDisplayGeometry component - The geometry is displayed correctly as expected
version 0.41f: only the patterns have been internalized - the frame is computed. The pattern now shows up but there are also flat rectangles that are not in the definition
version 0.41e: all the output geometry is the result of the computation - The patterns do not show up and there are still flat rectangles
Is there a memory limit that is preventing the definition from working? Does it have to do with the fact that we are using Rhino 7? (I cannot test it with Rhino 6 at the moment). Or am I missing something else?
This doesn’t seem to be a memory limit as your models open and load fast. It is important to pay close attention to data management and tree branches when working with transformations.
Geometry and transformations have to be on correnspondig branches.
Make sure you manage the data trees without flattening and simplifying.
Send only relevant geometry to the transformation component and avoid Nulls or text.
Feel free to post a minimal version of the definition replicating this so we can have a closer look. You might also find following tutorials useful.
Thank you for the reply. I’m working on creating a minimal definition and checking the list you indicated, so far I’m still running into this issue: everything works if I internalize the transformations right before sending them to the C# script.
While I’m working on a minimal definition I’d have one question: is there a known case where the geometry+transformation is displayed correctly on the local machine (using the SDDisplayGeometry component) while not working online? Can’t SDDisplayGeometry be used as a debug tool?
You need to test upload for debugging as the transformations might work locally but managing the data tree is the key here. See issues with transformations in following posts:
I’m back with this problem. After many attempts - and the summer break - I managed to find out where the problems were/are:
1 - I was using a different version of the script - I can’t remember where I downloaded from - which was causing some issues. Do you have a place where we can safely find the latest versions of the various scripts you have published?
2 - NOT SOLVED YET: I’m running into issues when I need to combine a single transformation with multiple transformations. If the single transformation has a tree structure like {0;0} I can’t find a way to combine it in a way that works.
A circle (in red) is copied in a linear array along the X axis and then translated along the Y axis using an orientation transformation. This is the expected result:
It seems that the problem originates from the data tree structure ( {0;0} ) of one of the planes that generates the orientation transformation (this structure comes from the components used to create this plane). If I create the same plane from scratch then everything works.
I haven’t found a way to manipulate the data to combine the transformations correctly - I tried to use the Cross Referencing and/or manipulate the data tree structure before creating the orientation transformation, but these didn’t work.
Is there a way to solve this (apart from creating the transformation in a different way)?
Simplify the logic of your script not the data trees. As mentioned above, it can lead to surprising and undesired results. I tweaked your definition a bit and it works as expected.
Thanks for the reply and for the solution proposed.
My file was obviouosly a simplified example to show the issue. In your modified file, the list of transformations has exactly the same structure as mine, even if I get that the process that led to the result was simplified in your version.
Still, I find it a bit frustrating not to be able to know in advance if the combination of transformations will work or not - the “surprising results” you mentioned are not great when developing.
It looks the only way to know if it will work is to test upload it, which is not ideal, it’s like moving in the dark. It would be a very welcome update if the ShapeDiver Display Geometry component could show the same result shown on the ShapeDiver platform, or if there was a well defined “rule” to follow or something to inspect directly in Grasshopper.
However, now that I’m aware of this, I will change the development of my definitions accordingly.
Just make sure sure that meshes and transformations are on corresponding paths, ie. mesh on branch {0;0;1} is replaced with transformation on branch {0;0;1}.
Do not simplify trees as you did in your definition earlier. For example, branches {0;0;1} and {0;1;0} might get simplified to path {1} which looks fine to a human eye but computers don’t like it.
