Community
Fusion API and Scripts
Got a new add-in to share? Need something specialized to be scripted? Ask questions or share what you’ve discovered with the community.
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

How do I tell if a sketch curve is normal, projected (purple) or from cache?

6 REPLIES 6
Reply
Message 1 of 7
ross.korsky
355 Views, 6 Replies

How do I tell if a sketch curve is normal, projected (purple) or from cache?

I'm having a real hard time programmaticly figuring out how a curve was drawn - what i mean is detecting if a curve is human drawn (blue/black ones) projected (purple) traced from a face when sketch was created (very faint ones) or if a curve is in the "from cache" state (yellow).

 

Anyone know how to dig this information out?

 

Really I'm trying to find the outside loop in a sketch created from a solid's plainer face. Additionally I'll need to be able to offset that outside loop "out" and offset all other loops "in". I'm creating a script to produce a kerf compensated DXF for laser cutting. I'm resorting to projecting an edge from the outer loop of a face into my sketch to give me some way to identify which sketch loop corresponds to the faces outer loop - such a projection is supposed to tell you what curves it created, however in this case no curves are created - instead Fusion simply converts one of the face trace curves into a projection curve. I'd like to be able to find this curve so i can call Sketch.findConnectedCurves to get my hands on the outer loop.

6 REPLIES 6
Message 2 of 7
ekinsb
in reply to: ross.korsky

If I understand what you're wanting to do, you should be able to use the isReference property to determine if the curve is a regular sketch curve or was projected from another entity.  If this property is True, it's linked to another sketch entity.  You can find the entity it's linked to by using the referencedEntity property and you can break the link by setting the isReference property to False.


Brian Ekins
Inventor and Fusion 360 API Expert
Mod the Machine blog
Message 3 of 7
ross.korsky
in reply to: ekinsb

Using isReference I cannot discern between curves that were created implicitly with the sketch (e.g. if you create a sketch by clicking on a face) and curves that were explicitly projected.

Strangely enough I observe non-symetric behavior when i setup a loop going through the curves and called .deleteMe on everything that .isReference reports True on vs when i run the loop deleting things isReference reports False on. One of these scenarios leaves only my projected line while the other either left all lines or deleted all lines, I forget which - i've been trying so many things.
Message 4 of 7
ekinsb
in reply to: ross.korsky

There isn't a difference between the curves automatically projected into the sketch when you pick a face to create the sketch on and the curves created using the Project command.  We plan to add support the ability to create a sketch without automatically projecting the edges into the sketch.  What I've done to work around this before is that immediately after creating the sketch I delete all of the sketch curves and then I begin projecting the edges I care about.  I think that's easier than writing code to figure out which automatically projected edge is what I want.  The automatically projected curves can also interfere with creating profiles I want when I'm drawing other geometry on the sketch.


Brian Ekins
Inventor and Fusion 360 API Expert
Mod the Machine blog
Message 5 of 7
ross.korsky
in reply to: ekinsb


@ekinsb wrote:

There isn't a difference between the curves automatically projected into the sketch when you pick a face to create the sketch on and the curves created using the Project command.


Well, the UI knows there's a difference so I expected there would be some way to tell the difference via the API... Especially given how the API is written - it looks very much like it is the exposure of internal implementation as opposed to a pure extensability interface (take for example the way one has to Loft or Extrude something by creating the *Input object first).

 

Anyway, I can accept that there is no way to discern between the lines - I guess this helps explain why when I export a DXF file all of the line types are on a single layer 😉

Message 6 of 7
ekinsb
in reply to: ross.korsky

You're right about there being some difference between the two types of projected curves because Fusion does color them differently but they both support the same capability that they're projected from an edge and you can break that link.  It wasn't a difference that we noticed or considered to be important enough to spend the effort to expose it through the API.

 

The API is NOT just a wrapper over the commands and the UI.  Internally in Fusion there are "request" functions which do all of the actual hard work.  They're the "internal implementation".  When you create an extrusion using the UI, the command collects all of the required information and then calls the request, passing that information.  The request does all of the work to create the extrusion and you end up with a modified model and a new transaction that bundles all of the work into a single undo operation.  When using the API you still need to provide all of the same information and then the API calls the same request as the UI.  The fact that the API uses "input" objects to collect the required input is solely an API design choice.  We could have had several functions with lots of arguments instead.  It was felt that the "input" objects would provide some familiarity to Fusion users and would be easier to use.  And more importantly the input object technique provides for more flexibility in the future.  For example, if a new option is added to the creation of an extrude we can just add a new property to the input object instead of having to create a new set of functions to add an additional argument.


Brian Ekins
Inventor and Fusion 360 API Expert
Mod the Machine blog
Message 7 of 7
ross.korsky
in reply to: ekinsb

The clunkyness I feel comes from this code pattern (From SpurGear):

def createExtrude(prof, thickness):
    extrudes = newComp.features.extrudeFeatures
    extInput = extrudes.createInput(prof, adsk.fusion.FeatureOperations.NewBodyFeatureOperation)

    distance = adsk.core.ValueInput.createByReal(thickness)
    extInput.setDistanceExtent(False, distance)
    return extrudes.add(extInput)

 

 

I would prefer to see a builder pattern at use over the template object(?) pattern. With a little behind the scene magic (dependency injection) the following syntax is possible, and in my opinion much more "user" friendly 😄

 

def createExtrude(prof, thickness):
    extrusion = newComp.features.extrudeFeatures.createInput(
        prof,
        adsk.fusion.FeatureOperations.NewBodyFeatureOperation)

    distance = adsk.core.ValueInput.create(thickness)
    extrusion.setDistanceExtent(False, distance)
    return extrusion.execute()

The main change here is that the extrusion input object retains a reference to the 'extrudeFeatures' instance so that the .execute method can call .add(..) for me so I don't need to interact with 'extrudeFeatures' a second time. A secondary change is that it'd be nice if ValueInput.create could just figure out the type I gave it - all three forms of the .create method return the same type, could we just let function overloading sort out the details? Better yet allow the script to provide a number or a string anywhere it expects a ValueInput, the API should be able to create these behind the covers simply enough.

 

 

I realize this is my opinion and there may be technical reasons why this cannot be done. I hope I'm not overstepping my limits here - I love that Fusion 360 has such a powerful API, I just wish it wasn't so heavy weight to use. If you're interested, and if you think it'd be helpful, I have a lot more opinions about the API I can share - perhaps another channel would be more appropriate than this forum.

 

Yes, as I'm sure you've guessed, I'm in the software field myself.

 

Can't find what you're looking for? Ask the community or share your knowledge.

Post to forums  

Autodesk DevCon in Munich May 28-29th


Autodesk Design & Make Report