Get assemblyContext from InterferenceResult entities

[runeruiterkamp]

Hello,

I've ran into an issue using the results from an interference analysis, I'd like to perform an interference check between multiple occurrences (not components!). This seems to work fine and gives correct results, however, when parsing the created InterferenceResult object I'm unable to determine which occurrences are interfering, only the components.

The InterferenceResult contains two bRepBodies, entityOne and entityTwo. I am able to see which component they belong to using res.entityOne.parentComponent.name, but I'm interested in finding the occurrence of this component which is responsible for the interference. A bRepBody is supposed to have an assemblyContext which returns the occurrence in the assembly, but this is always null for entityOne and entityTwo. Is there a way to connect entityOne and entityTwo to their respective occurrences in the assembly?

Below is a code snippet in which I try to determine which occurrence is interfering. (Note: my code works perfectly when there's only unique components)

...
interferenceInput = design.createInterferenceInput(interferenceCollection)
                results = design.analyzeInterference(interferenceInput)  #execute interference analysis
                #TODO find a way to indentify interference results (components vs occurrences)
                for res in results:
                    res = adsk.fusion.InterferenceResult.cast(res)

                    if res.entityOne.parentComponent.name == occurrence.name.split(':')[0]:
...

I am fairly new to fusion360 and it's api so this problem might be caused by a misunderstanding of how occurrences, components, and bodies are connected, but I feel like there should be a way to see which occurrences are interfering using the api, since the UI interference analysis does give occurrences as results, instead of their components:

(notice the ':1' and ':2' indicating which occurrence is interfering, as opposed to only returning 'Part-2' using the api.

A solution I'm considering now is to loop through all occurrences in the assembly and if there are multiple occurrences per component, copying these occurrences into new components with unique names, but this doesn't seem very efficient to me.

I hope I've explained the issue well enough

Thanks in advance and kind regards

[kandennti]

Hi @runeruiterkamp .

I understand what you mean.

I was able to confirm that the entityOne and entityTwo in the InterferenceResult are nativeObjects, not proxies, when I tried the sample here.

https://help.autodesk.com/view/fusion360/ENU/?guid=GUID-{3749239A-22E9-4943-A63F-70C8F2C6CC1B} 

Sorry, this is not a solution to the problem, but it is what I have been feeling lately.

This is a relatively recent topic.

https://forums.autodesk.com/t5/fusion-360-api-and-scripts/quot-failed-to-get-owner-occurrence-transf... 

I believe this is also a proxy related issue.

I also believe that this is also related to the proxy.

https://forums.autodesk.com/t5/fusion-360-api-and-scripts/issues-replacing-joint-geometryororiginone... 

I didn't mention it there, but even though a proxy was passed, the receiving joint was switching to a nativeObject.

I think that for us script developers, proxy is a difficult mechanism to understand.

I also strongly feel that proxy is a mechanism that is difficult for API developers to understand.

[runeruiterkamp]

Hi kandennti,

Thanks for the reply. It does seem to be a proxy issue, like you said, the entityOne and entityTwo seem to be native objects, and only reference the component, the assemblyContext is always None. I'm now just wondering if this is intended and there's a solution I'm not seeing, or if this is a bug in the API. Especially since it is possible when doing an interference check through the UI.

I'll look through the discussions you linked.

For now I've created a script which looks for proxies and copies them into a unique component: for example part-2:2 will be part-2_2:1. But it feels more like a workaround than a solution, especially since the new component's bounding boxes disappear during runtime and only appear when the script has finished... (its minPoint and maxPoint are both 0, 0, 0)