Dynamo: 0.91RC (and earlier versions) "Geometry.ExportToSAT" size issues.

[dimven]

I've been observing some strange behavior with the "Geometry.ExportToSAT" node. First of all, when lacing is set to shortest and you feed in a list of geometries and a list of paths, the entire list of geometries gets exported over and over for each file path, effectively merging the list of goemetries into a single entity. The expected result is to have each individual geometry paired up with each individual path:

Setting the lacing to longest fixes this but it's still an unexpected result.

The bigger issue I'm having however, is that the exported file size varies a lot with the scale of the object.

In the above example, the file size increases only 4 times. In other cases (sometimes with a simpler geometry, sometimes with a more complicated one), I've seen the size increase 8-10 times with relatively minor changes to the scale of the object.

I thought the problem might be coming from the use of the "Geometry.Scale" node, so I decided to bypass it and got somewhat similar results:

Any idea why this is happening? Can you suggest any ways to bypass this increase in size? Is there a way to have a finer grained control over the size of the file? (something like a quality setting)

When I import these ballooned files in Revit, the project's file is increased even further than the total size of tha SAT.

P.S.
As a side note, the "PolyCurve.Fillet" node's "rightSide" input seems to change sporadically with the scale of the object too. I've got no idea what this setting does, but it'd be awesome if you could somehow eliminate it. (for example evaluate the number of segments in the resulting curve; the output's curve count should always be greater then the input's )

@kronz I guess this is another issue for the ASM bucket.

[kronz]

@aparajit-pratap @Randy-Ma Any insight on what is going on with the SAT export?

[mjkkirschner]

I think this has to do with the adaptive tolerance setting that ASM uses to tessellate the geometry which is directly tied to scale. on second thought maybe not, this is .SAT geo...

[aparajit-pratap]

@dimven could you attach the SAT and DYN files you used in this example so that we can reproduce and debug this scenario. Thanks!

[dimven]

I've posted the dyn files here:
https://github.com/dimven/SpringNodes/tree/master/Issues/6133
It's got the original example and a second shape, which I consider more complex. I must be doing something very wrong in the original, because the alternative form is not experiencing the issue when scaled:

[aparajit-pratap]

http://adsk-oss.myjetbrains.com/youtrack/issue/MAGN-10014

[Racel]

@dimven - Regarding your first question about the list of geometries and paths not matching up with shortest lacing, can you please try using a List.Chop and placing each geometry in a nested list and then performing the ExporttoSAT? This worked for me. Also, I tried to download your files and when I try to open in Dynamo 1.0, I am getting an error about the file being corrupt. Are you experiencing the same thing?

[dimven]

Hi @Racel

As I mentioned above, setting the lacing to longest mediates that issue. However, that shouldn't occur at all in the first place because the geometry input is defined as a singleton (i.e. a "var" instead of a "var:[]")

I've observed the same issue in 1.0.0 with a few other nodes that should work on a single item but instead process their whole input list as one entity:

The graph updates just fine to 1.0.0 for me. Your problem sounds like you tried to directly download it from Github. The problem with that is that GH adds some html gunk to the file. Try opening it first and then downloading it from the "Raw" button:

1.0.0 doesn't seem to improve things much. It looks like it introduces a new issue instead with the largest scaled geometry:

Warning: Geometry.ExportToSAT operation failed.
Unable to write entity list as sat : LEGACY_SAVE_DISALLOWED -- Saving new data to old format is disallowed (prepare data with SMI_APPROX_BODY).

The resulting sizes:

[Racel]

Thanks, @dimven - I was able to take a look at your file after downloading the raw data. I didn't realize github did that to files.

Regarding the ExportToSAT and BoundingBox nodes that take Autodesk.DesignScript.Geometry.Geometry as an input, I believe it is looking for a group of geometry. If you place each one of the geometries into a nested list using List.Chop, you can get the results that you want without having to do longest lacing. There are use cases for both workflows, for exporting a single geometry and a collection of geometry. In the past, we have dealt with this by creating 2 separate nodes, but what I suggest is that we add a boolean input to these type of nodes specifying if you want the node to treat a list of geometry as one thing or single things so that you don't have to use List.Chop. This would alleviate the need for a second node and reduce confusion. @aparajit-pratap @kronz @ke-yu @dimven - What do you think?

[aparajit-pratap]

@Racel i'm afraid I would have to disagree with you. I don't think the user should be expected to jump through hoops by massaging inputs using list manipulation nodes (like List.Chop) before passing them into a node in order to see the expected result. The node should just work as it is advertised to do. As @dimven rightly pointed out the same issue exists with the BoundingBox.ByGeometry node and again due to the same reason, i.e. BoundingBox.ByGeometry node again has 2 overloads, one that accepts a single geometry and one that takes in a collection and again the VM internally decides to pick the latter method to execute. I suppose we would have to address all such cases where there are overloaded methods based on single vs. array input argument. Btw what you used in your graph is Geometry.BoundingBox. This will work as expected even without the List.Chop as there's only one such node that takes in a single value. @dimven is referring to BoundingBox.ByGeometry.

[ke-yu]

This issue has been there for a long time. It is because of function overload with same amount of parameters. Though putting a node on canvas is a static behavior, function dispatch is purely dynamic, depending on the data that connect to the node, so @Racel 's suggestion of putting a boolean input won't fix the problem.

There are two ways to fix it. One way is to fix in the language to make the function dispatch be more static. That is, just like calling C++ template function, we could specify the expected parameter types when calling a function, e.g., foo<int[], Geometry[]..[]>(x, y) which explicitly tells the VM that I want to call function foo() whose first parameter type is int[] and the second parameter type is Geometry[]..[]. But there are couple of issues. Input could be heterogeneous and could be a jagged list, so shall we call foo<int>(xs) or foo<int[]>(xs) for input {1, {2, 3}, { {4}, {5} }}? Providing type hint is an extra overhead if writing code in code block node.

The other solution is simpler which I'm thinking about for a while. That is, not supporting overloaded functions with same amount of parameters.

Right now, as a workaround, I'd suggest to rename functions to different names.