Simplify assembly to part with API

Simplify assembly to part with API

relicseekerharry
Advocate Advocate
262 Views
4 Replies
Message 1 of 5

Simplify assembly to part with API

relicseekerharry
Advocate
Advocate

Hello Forum,

 

I have been trying to make a plugin for my web application in C# that simplifies an assembly into a part then exports it as .stp. So far, I have been able to do the .stp stuff just fine.

 

However, the simplification part is eluding me. I have been using Inventor 2025 Help | Derived Parts and Assemblies | Autodesk as a reference, but cannot add the uniformDef as a derived part as the input is an assembly. The following is the top part of my ExportSTP method, before the working STP logic:

 

public void ExportSTP(Document doc)
{
            var inventorApp = _inventorApplication;
            var startDir = System.IO.Directory.GetCurrentDirectory();

            var fileName = System.IO.Path.Combine(startDir, "Output.stp");
          
            PartDocument derivedPartDoc = null;

            try
            {
                if (doc.DocumentType == DocumentTypeEnum.kAssemblyDocumentObject)
                {
                    LogTrace($"Attempt to create derived part from assembly {doc.File.FullFileName}");

                    var tempPartPath = System.IO.Path.Combine(startDir, "DerivedPart.ipt");

                    derivedPartDoc = (PartDocument)inventorApp.Documents.Add(DocumentTypeEnum.kPartDocumentObject, inventorApp.FileManager.GetTemplateFile(DocumentTypeEnum.kPartDocumentObject), true);

                    // create uniform scale definition
                    var uniformDef = derivedPartDoc.ComponentDefinition.ReferenceComponents.DerivedPartComponents.CreateUniformScaleDef(doc.FullFileName);
                    uniformDef.ScaleFactor = 1.0;

                    // cast type for DerivedPartComponents.Add()
                    DerivedPartDefinition derivedDef = (DerivedPartDefinition)uniformDef;

                    derivedPartDoc.ComponentDefinition.ReferenceComponents.DerivedPartComponents.Add(derivedDef);
                    derivedPartDoc.SaveAs(tempPartPath, false);

                    LogTrace($"Successfully created derived part {derivedPartDoc.DisplayName}");

                }
            }
            catch (Exception ex)
            {
                LogError($"Failed to derive part: {ex.Message}");
                return;
            }

It doesn't necessarily have to be a derived part - just as long as there is no way to split the .stp output back into assembly components. With just my .stp logic, I have been able to download an assembly as .stp then open it in Inventor and get all the components back, which is what I need to prevent.

 

The target workflow for the above snippet is: Input .iam -> simplify to .ipt -> convert and export .stp

 

Any help on reaching my goal would be greatly appreciated, thank you!

0 Likes
Accepted solutions (2)
263 Views
4 Replies
Replies (4)
Message 2 of 5

WCrihfield
Mentor
Mentor

Hi @relicseekerharry.  This is not something I do by code regularly, but I have a decent understanding of how it is done by code anyways.  In Line 21 of your example code above, you are using the ReferenceComponents.DerivedPartComponents Property, when you should be using the ReferenceComponents.DerivedAssemblyComponents Property, because you are 'deriving in' an assembly file, not a part file.  And the DerivedAssemblyDefinition Type variable should be created before that line, with that line setting its value.  That way you can set further property values of that definition object, before using it to create a new DerivedAssemblyComponent.  One of the properties of the definition you may want to make sure to set is the DerivedAssemblyDefinition.DeriveStyle, to either the DerivedComponentStyleEnum.kDeriveAsSingleBodyNoSeams or DerivedComponentStyleEnum.kDeriveAsSingleBodyWithSeams value, to make it all one part, instead of the 'multi-body' variation.  That way it most likely will not be interpreted as representing an assembly, instead of a part later by the TranslatorAddIn.  Then later, it may be necessary to use the DerivedAssemblyComponent.BreakLinkToFile Method, so it can not trace its origins back to an assembly file.  Just my initial thoughts.

Wesley Crihfield

EESignature

(Not an Autodesk Employee)

Message 3 of 5

relicseekerharry
Advocate
Advocate
Accepted solution

Good morning Wesley, thank you for your detailed explanation. 

 

I achieved desirable effect with Shrinkwrap and opening the output doesn't seem to be traceable to an assembly as the solid bodies show no parents. However, it does have two solids which wasn't expected, especially considering kDeriveAsSingleBodyNoSeams was used! I have attached the output .stp for reference - originally Autodesk's sample wheel assembly

 

public void ExportSTP(Document doc)
{
    LogTrace("Simplify assembly then export STP file.");

    var inventorApp = _inventorApplication;
    var startDir = System.IO.Directory.GetCurrentDirectory();

    var fileName = System.IO.Path.Combine(startDir, "Output.stp");
    var tempPartPath = System.IO.Path.Combine(startDir, "DerivedPart.ipt");

    PartDocument partDoc = null;

    if (doc.DocumentType == DocumentTypeEnum.kAssemblyDocumentObject)
    {
        try
        {
            
            LogTrace($"Attempt to simplify assembly: {doc.FullFileName}");

            partDoc = (PartDocument)_inventorApplication.Documents.Add(DocumentTypeEnum.kPartDocumentObject, _inventorApplication.FileManager.GetTemplateFile(DocumentTypeEnum.kPartDocumentObject));
            PartComponentDefinition partCompDef = partDoc.ComponentDefinition;

            ShrinkwrapDefinition derivedDef = partCompDef.ReferenceComponents.ShrinkwrapComponents.CreateDefinition(doc.FullDocumentName);
            
            derivedDef.DeriveStyle = DerivedComponentStyleEnum.kDeriveAsSingleBodyNoSeams;
            derivedDef.RemoveAllInternalVoids = true;

            ShrinkwrapComponent derivedComp = partCompDef.ReferenceComponents.ShrinkwrapComponents.Add(derivedDef);

            partDoc.SaveAs(tempPartPath,false);

            LogTrace($"Assembly simplified successfully to {tempPartPath}");
        }
        catch (Exception ex)
        {
            LogError($"Failed to simplify assembly: {ex.Message}");
            return;
        }
    }

 

0 Likes
Message 4 of 5

WCrihfield
Mentor
Mentor
Accepted solution

Hi @relicseekerharry.  Glad to hear you found a process that is working OK for you.  I just downloaded, opened, and reviewed the STEP file.  I am not really surprised by the results.  All bodies that were physically touching each other look like they were 'Joined' by Union type Boolean operations onto a single body.  However, the break disk (which got joined with the wheel rim) never touches the inner wheel hub or the break calipers/pads.  The hub, calipers, and pads are touching each other though, so they got joined together into one body, as expected.  These processes likely utilize the TransientBRep.DoBoolean method (and other similar methods) to perform the common 'Boolean operations' on all the bodies.  I'm not sure if switching the derived component style to the 'with seams' variation would make any difference, but could be tested.  Another setting/option that should definitely be looked into is the ShrinkwrapDefinition.CreateIndependentBodiesOnFailedBoolean Property.  I pretty much never use the shrink wrap variation where I work, but I do a lot of manual deriving of parts or assemblies into other parts representing purchased stuff, which are mostly used for visual aids in our larger assemblies.  I'm guessing that maybe setting  the ShrinkwrapDefinition.EnvelopesReplaceStyle Property could be set to the EnvelopesReplaceStyleEnum.kAllInOneEnvelopeReplaceStyle, but I'm honestly not sure how that works.  That type of definition does have a lot of interesting properties for helping to remove unwanted/unnecessary geometry in the final model though.  I'm just not sure if any of them match the exact scenario with that wheel assembly model.

Wesley Crihfield

EESignature

(Not an Autodesk Employee)

Message 5 of 5

relicseekerharry
Advocate
Advocate

Thank you for your advice - it's great food for thought. The plugin is intended for a much more complex and varied assembly in the future, but there won't be any "floating" parts that would create a second body. Further abstraction is definitely in the cards just as an extra layer of protection, but that can be tinkered with when working with the target assembly later on. 

0 Likes