Where are Proxies in the object model?

[graham.wideman]

I am trying to find where proxy objects show up in the Fusion 360 object model.

From the docs, (notably "Documents, Products, Components, Occurrences, and Proxies" (http://help.autodesk.com/view/fusion360/ENU/?guid=GUID-88A4DB43-CFDD-4CFF-B124-7EE67915A07A) proxy objects are what implements the ability for Fusion to portray a single component multiple times.

While the possibly multiple instances of a component are represented by Occurrence objects that reference the actual Component, the details (sketches, features etc) of the instances are represented by Proxies that point to their corresponding details ("nativeObject") in the actual Component. At least, if I understand the docs correctly.

We can see in the API Reference that the many object types which may be found contained in a Component (such as Sketch and all the SketchXxx objects, all the xxxConstraint objects, all the XxxFeature objects, and the JointXxx objects) all have the nativeObject property that allows then to serve alternatively as proxies. So far so good.

From the above-mentioned page, and the object model (https://help.autodesk.com/cloudhelp/ENU/Fusion-360-API/images/Fusion.pdf), I think I understand that the main "component tree" is implemented like this diagram:

[Fig 1]

which is a slightly redundant portrayal, and really reduces to this recursive pattern:

[Fig 2]

Now, from page "Documents... Proxies", I note that properties for bRepBodies (shown in blue) that probably implement this pattern of proxy --> nativeObject:

[Fig 3]

So I would expect that other parts of a component would be proxied (as shown in red) like in this diagram:

[4]

However, Occurrence contains no properties like sketches, features and so on.

So that's where I'm stuck. Not knowing where those proxies are to be found undermines my whole understanding of the basic skeleton of Fusion! Any clues?

[PinRudolf]

I cannot be of much help here but maybe my view on this inspires you to find the answer that you are looking for.

Maybe, the body proxy is much more designed for something that has not been mentioned since it does not fully function (yet):

Using the example of 1 component; a simple board. I might have 2 occurrences of the board next to each other. Obviously when I change the component both occurrences should change with it.

However, there could be a way of changing the 3d shape (the body) of a single occurrence without changing the component: you could drill a hole in the occurrence on the assembly level. From a assembly point of view this would make sense when you want to make sure the hole and component always align. However, when you try this Fusion will actually change the component instead of the occurrences body-proxy. Which makes me think they might plan to be able make changes occurrences' body proxies in the future.

Note that Inventor does something like this. You can create a hole through a single occurrence without changing the actual component. I have not looked at the Inventor API much but I think that Autodesk tries keep these two API's similar. There is an article on lumps which make me say that; the lumps do not have much of a function in Fusion 360 but you can access them through the API. They are however needed in Inventor.

...Or a sketch proxy might be part of Fusion but it might not be exposed in the api. Maybe?

[graham.wideman]

@PinRudolf

Thanks for your comments.  I too have found that multiple copies of a component in a design (that is, a component with multiple Occurrences) behave counterintuitively. It's as though the only point to multi Occurrences is to be able to set separate positions/orientations. It seems like other operations just affect all occurrences the same. For example, in a completely separate component you can create a cut extrusion that impinges on one Occurrence of some other multi-occurrence component. But it cuts all the occurrences of the other component, as though the cut operation is performed on the  underlying component, which then appears in all instances.

This is unlike multiple imports of some component from another design.

As to your comments on the Body proxies. I can see how they would be useful for providing the positions in global space of the individual bodies in an occurrence.

But what I'm really looking for is the proxies that pertain to all the other kinds of objects.

[BrianEkins]

The proxy objects are shown in the object model because there aren't special objects for proxies.  The programming objects represent both real and proxy objects.

Let's look at the simple example of a BRepFace.  I've created the body shown below in a component.  It's a "real" body and the component owns the body.  If we focus on the red face and query it to find the coordinates of its four corners, those corners are returned relative to the component coordinate system, which is shown.  The red face is a BRepFace and because it's the "real" face the nativeObject and assemblyContext properties of the BRepFace object will return None because the BRepFace object represents a "real" face.

Now let's look at the assembly that contains two instances of that component.  The two instances are shown below, along with the assembly coordinate system.  The "real" geometry for these parts exists in the part component and not in the assembly. Each occurrence in the assembly is referencing the component and displaying the part at the location and orientation defined by the occurrence.  In this example, we have two red faces in the assembly and if I get the BRepFace object the represents either of the faces and query it for the corners, they'll be returned as if that face exists in the assembly and the coordinates will be returned with respect to the assembly coordinate system.  That's because that BRepFace is acting as a proxy.  It's representing the "real" face in the context of the assembly.  I can use the assemblyContext property to find out which occurrence it's defined by and the nativeObject property will return the "real" face.  

If the user selects a BRepBody object that's in any component other than the root component, you'll get back a BRepBody that is acting as a proxy for the real BRepBody.  Getting faces or edges from that BRepBody will also return proxy objects.

Hopefully, that helps.

[graham.wideman]

@BrianEkins  I greatly appreciate the time and effort in your reply. However -- you've covered the part I already knew. You've described the bRepBodies collections of Component and Occurrence, as I diagrammed in my Fig 3 in the original post. (Did you perhaps answer "Why are Proxies in the object model?", instead of "Where"?)

What I'm looking for is where to find all the other objects that are equipped to be proxies such as Sketch and all the SketchXxx (such as point and line) objects, all the xxxConstraint objects, all the XxxFeature objects, and the JointXxx objects), which all have the nativeObject property (and AssemblyContext method) that allows then to serve alternatively as proxies. Which I expected to find as in my Figure 4, but did not.

Now, if you have some idea on those -- do tell!

[BrianEkins]

Sorry, I should have read your original question again.  Proxy objects are directly available through the API in only a few cases.  The first is from user selection.  If the user selects anything that's not in the root component, you'll get back a proxy object.  Obviously, this can't be represented in the object model chart.

Another place where proxies are available is for occurrences.  If you use the occurrences property on the root component it will return "real" occurrence objects but when you use the childOccurrences property on the Occurrence it will return a collection of Occurrence proxies.  These represent the occurrences as if they exist in the root component.

I think the only other place where proxies are directly returned is using the bRepBodies property of the Occurrence object.  This will return a BRepBody proxy and when you traverse that body to get its related objects, they'll also be proxies. That relationship isn't shown in the current object model diagram but should be.

For a proxy for anything else, you can't get it directly by traversing the object model but instead will need to create it by using the createForAssemblyContext method on the object.