Exporting Assemblies with external references

[r-a-i]

Hi, kudos on this AddIn. Worked great for all f3d files but failed for files with external references. I see when I manually export files with external references, the output is an f3z file. I also see the code does not have any f3z file reference and could not find documentation on the Fusion API for this.

Exporting f3z files would be a great addition to this plug in so we can export all the files in bulk, including complex assemblies that have some external references and some internally defined components.

I'm happy to help extend the functionality to support files with external references but wanted to reach out to see if you can provide guidance.

[tapnair]

Hey thanks for all the work. I have been on vacation the last week so I apologize for the delay. Have you tested this? I don't believe it will work. The "local" translators only support single f3d files. Unless something has changed if you export an assembly with external references like this, they won't properly re-import. Can you confirm that it is indeed working as expected?

[r-a-i]

Hi,

Yes. I’ve exported my entire workspace and the exports worked well. I re-imported a few and they did work. I think the re-import referenced the original files that were still in the workspace. Upon exporting other project I even got the sense that once a file with references is exported, during the export, it pulled the references and exported those (but I did not test). My goal was to download my workspace for backup. And this seems to do it. I did not systematically test all the corner cases.

On Oct 18, 2020, at 10:30 PM, Patrick Rainsberry [email protected] wrote:

Hey thanks for all the work. I have been on vacation the last week so I apologize for the delay. Have you tested this? I don't believe it will work. The "local" translators only support single f3d files. Unless something has changed if you export an assembly with external references like this, they won't properly re-import. Can you confirm that it is indeed working as expected?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/tapnair/Project-Archiver/issues/22#issuecomment-711491111, or unsubscribe https://github.com/notifications/unsubscribe-auth/AD52PEKE3EM7VIJ533HVT5LSLOXFDANCNFSM4SNJ5C2A.

[tapnair]

Unfortunately, as I suspected, when trying to re-import f3d's that had external references exported through this app I am getting an error. It is possible to upload them, but the references would only point back to the original file. This means that the export is not really portable. meaning you could never "really" recreate the data in a new project from this archive. I think it is a bit misleading to offer this capability. What I will do is add the export for things like step and iges for these, but skip f3d exports. it would then be up to the user to trigger them manually through the ui to properly export f3z's. It should also be noted that only the top level assembly should be archived and duplicates of the children would also be created in that scenario.

[tapnair]

I like a bunch of these other changes you made though, so I'll still merge the commit, but then go back and make some more changes.

[r-a-i]

That seems consistent with what I see. I agree that this prevents portability. However, my ‘needs' for backup (not portability) do work when exporting designs for references.
In my case, I have probably hundreds of files with references, so having to back them up manually is not tenable. I recommend that instead of blocking it as before, you let the user decide (with a checkbox) if the want to export designs with external references (with the caveat that they are for backup and the references must also be exported independently).

On Oct 19, 2020, at 9:29 AM, Patrick Rainsberry [email protected] wrote:

Unfortunately, as I suspected, when trying to re-import f3d's that had external references exported through this app I am getting an error. It is possible to upload them, but the references would only point back to the original file. This means that the export is not really portable. meaning you could never "really" recreate the data in a new project from this archive. I think it is a bit misleading to offer this capability. What I will do is add the export for things like step and iges for these, but skip f3d exports. it would then be up to the user to trigger them manually through the ui to properly export f3z's. It should also be noted that only the top level assembly should be archived and duplicates of the children would also be created in that scenario.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/tapnair/Project-Archiver/issues/22#issuecomment-712200551, or unsubscribe https://github.com/notifications/unsubscribe-auth/AD52PEIPQBVBVCHSBUN5PCTSLRELRANCNFSM4SNJ5C2A.

[r-a-i]

Do you want me to create a Pull request for all the other changes?

On Oct 19, 2020, at 9:30 AM, Patrick Rainsberry [email protected] wrote:

I like a bunch of these other changes you made though, so I'll still merge the commit, but then go back and make some more changes.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/tapnair/Project-Archiver/issues/22#issuecomment-712201163, or unsubscribe https://github.com/notifications/unsubscribe-auth/AD52PEMN6AZJ42TWHPDRTWLSLREO3ANCNFSM4SNJ5C2A.

[tapnair]

I have them all incorporated in the refs branch. I started from your original pull request.

On Mon, Oct 19, 2020 at 11:34 AM Rodrigo Alvarez [email protected] wrote:

Do you want me to create a Pull request for all the other changes?

On Oct 19, 2020, at 9:30 AM, Patrick Rainsberry < [email protected]> wrote:

I like a bunch of these other changes you made though, so I'll still merge the commit, but then go back and make some more changes.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub < https://github.com/tapnair/Project-Archiver/issues/22#issuecomment-712201163>, or unsubscribe < https://github.com/notifications/unsubscribe-auth/AD52PEMN6AZJ42TWHPDRTWLSLREO3ANCNFSM4SNJ5C2A .

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/tapnair/Project-Archiver/issues/22#issuecomment-712364547, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACT5ODPQW62DWOID2M35FTLSLSBDRANCNFSM4SNJ5C2A .

--

Regards,

Patrick Rainsberry

[tapnair]

I'm still not sure about the external refs, even if you were able to export them, you could never really accurately import them again. I'm not seeing the scenario where it is useful? If it only works to re-import them when all the children already exist in your project and are the ORIGINAL files. Maybe it is giving you peace of mind? But it really isn't, because if the data can't be imported, why bother exporting. Maybe I'm not being clear about what the consequences are when re-importing?

On Mon, Oct 19, 2020 at 11:33 AM Rodrigo Alvarez [email protected] wrote:

That seems consistent with what I see. I agree that this prevents portability. However, my ‘needs' for backup (not portability) do work when exporting designs for references. In my case, I have probably hundreds of files with references, so having to back them up manually is not tenable. I recommend that instead of blocking it as before, you let the user decide (with a checkbox) if the want to export designs with external references (with the caveat that they are for backup and the references must also be exported independently).

On Oct 19, 2020, at 9:29 AM, Patrick Rainsberry < [email protected]> wrote:

Unfortunately, as I suspected, when trying to re-import f3d's that had external references exported through this app I am getting an error. It is possible to upload them, but the references would only point back to the original file. This means that the export is not really portable. meaning you could never "really" recreate the data in a new project from this archive. I think it is a bit misleading to offer this capability. What I will do is add the export for things like step and iges for these, but skip f3d exports. it would then be up to the user to trigger them manually through the ui to properly export f3z's. It should also be noted that only the top level assembly should be archived and duplicates of the children would also be created in that scenario.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub < https://github.com/tapnair/Project-Archiver/issues/22#issuecomment-712200551>, or unsubscribe < https://github.com/notifications/unsubscribe-auth/AD52PEIPQBVBVCHSBUN5PCTSLRELRANCNFSM4SNJ5C2A .

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/tapnair/Project-Archiver/issues/22#issuecomment-712364205, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACT5ODI32PSAVW5FMB7DNCTSLSBATANCNFSM4SNJ5C2A .

--

Regards,

Patrick Rainsberry

[r-a-i]

Perhaps you are right and this is giving me a false sense of security, or is only useful in a few cases.

Let’s explore some cases:

1. The top-level file (the one with references) gets corrupted or deleted. In this case I can re-import it and rescue it.
2. The project gets corrupted or deleted. All the dependent files may be restored, and the top-level file may also be restored. In this case a. Components defined within the top level file would still be recovered. b. You are saying that the references will not be restored because even though the dependent files were restored, they will have some new file_id (or something) so they won’t be re-linked.

2a has some value. For me this is enough to justify the export of these files, because it allows me to at least backup those components. 2b is troublesome for sure. What do you see if you re-import a file like this? Does it fail ungracefully? Does it have empty or error-flagged components? If there is some manual way to even try to rescue this file (i.e. by re-linking external references) that would be useful (but not ideal).

You probably have way more visibility into the file structure Fusion uses on the backend. Maybe changing the way the references are linked is not complicated and you can influence whomever owns those functions.

Thanks so much for giving this issue all this consideration.

On Oct 20, 2020, at 1:50 AM, Patrick Rainsberry [email protected] wrote:

I'm still not sure about the external refs, even if you were able to export them, you could never really accurately import them again. I'm not seeing the scenario where it is useful? If it only works to re-import them when all the children already exist in your project and are the ORIGINAL files. Maybe it is giving you peace of mind? But it really isn't, because if the data can't be imported, why bother exporting. Maybe I'm not being clear about what the consequences are when re-importing?

On Mon, Oct 19, 2020 at 11:33 AM Rodrigo Alvarez [email protected] wrote:

That seems consistent with what I see. I agree that this prevents portability. However, my ‘needs' for backup (not portability) do work when exporting designs for references. In my case, I have probably hundreds of files with references, so having to back them up manually is not tenable. I recommend that instead of blocking it as before, you let the user decide (with a checkbox) if the want to export designs with external references (with the caveat that they are for backup and the references must also be exported independently).

On Oct 19, 2020, at 9:29 AM, Patrick Rainsberry < [email protected]> wrote:

Unfortunately, as I suspected, when trying to re-import f3d's that had external references exported through this app I am getting an error. It is possible to upload them, but the references would only point back to the original file. This means that the export is not really portable. meaning you could never "really" recreate the data in a new project from this archive. I think it is a bit misleading to offer this capability. What I will do is add the export for things like step and iges for these, but skip f3d exports. it would then be up to the user to trigger them manually through the ui to properly export f3z's. It should also be noted that only the top level assembly should be archived and duplicates of the children would also be created in that scenario.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub < https://github.com/tapnair/Project-Archiver/issues/22#issuecomment-712200551>, or unsubscribe < https://github.com/notifications/unsubscribe-auth/AD52PEIPQBVBVCHSBUN5PCTSLRELRANCNFSM4SNJ5C2A .

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/tapnair/Project-Archiver/issues/22#issuecomment-712364205, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACT5ODI32PSAVW5FMB7DNCTSLSBATANCNFSM4SNJ5C2A .

--

Regards,

Patrick Rainsberry — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/tapnair/Project-Archiver/issues/22#issuecomment-712634004, or unsubscribe https://github.com/notifications/unsubscribe-auth/AD52PEMTSASKDF6PFLWOCHDSLUXLTANCNFSM4SNJ5C2A.

[r-a-i]

Hi,

I had some time today to play with this and ran some tests that confirm your concern, but also that there is some value in exporting models with references.

1. I created a new project, and within it, I created model A (with a box), model B (with a cylinder), and model C (with a pyramid). In model C, I also inserted models A and B.
2. I used Project-Archiver to export all 3df files (including Model C with references).
3. I deleted all files from the project.
4. I uploaded the three files. When I tried to open model C, I received a message about "Unresolved References." Model C did have the bodies (pyramid) I had defined, but it listed the two other models as "Unresolved" and labeled them red in the timeline. This confirms your concern that references don't get restored. This also confirms that the bodies/components defined within such a model do get restored. It's a half-rescue.

To me, the easy fix here would be to update Fusion so that when there is an "Unresolved Reference," the user can "redefine the reference" just like we do when we "redefine sketch planes" that are lost. Is there any glimmer of hope that we can make this feature request and push it through?

[tapnair]

It is definitely something we have talked about, but there are no timelines. I will tell you it is definitely not an "easy fix."

[r-a-i]

Thanks for all your consideration.

I can appreciate how something that may look trivial from the outside would actually require going into cavernous depths of a fragile code structure that was architected one way, but evolved another and would require complete restructuring or unforgivable hacking.

As per this issue. From my perspective, saving at least some of the components/bodies defined in a model with external references has value. I recommend allowing to save this files but giving fair warning to the users that the external referenced models are will not be recovered. This is how I’m using your scripts on my fork.

On Oct 28, 2020, at 9:18 PM, Patrick Rainsberry [email protected] wrote:

It is definitely something we have talked about, but there are no timelines. I will tell you it is definitely not an "easy fix."

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/tapnair/Project-Archiver/issues/22#issuecomment-718316020, or unsubscribe https://github.com/notifications/unsubscribe-auth/AD52PEP2K2HH65LS2Y66QGLSNDGHNANCNFSM4SNJ5C2A.

[tapnair]

Thanks for the feedback, I appreciate the opinion, but I am just not comfortable exporting data I know will be broken. Of course that is the beauty of open source code. You are absolutely free to modify it and use it in a way that makes sense to you. Of course other people can use your fork as well.

On Thu, Oct 29, 2020 at 10:10 PM Rodrigo Alvarez [email protected] wrote:

Thanks for all your consideration.

I can appreciate how something that may look trivial from the outside would actually require going into cavernous depths of a fragile code structure that was architected one way, but evolved another and would require complete restructuring or unforgivable hacking.

As per this issue. From my perspective, saving at least some of the components/bodies defined in a model with external references has value. I recommend allowing to save this files but giving fair warning to the users that the external referenced models are will not be recovered. This is how I’m using your scripts on my fork.

On Oct 28, 2020, at 9:18 PM, Patrick Rainsberry < [email protected]> wrote:

It is definitely something we have talked about, but there are no timelines. I will tell you it is definitely not an "easy fix."

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub < https://github.com/tapnair/Project-Archiver/issues/22#issuecomment-718316020>, or unsubscribe < https://github.com/notifications/unsubscribe-auth/AD52PEP2K2HH65LS2Y66QGLSNDGHNANCNFSM4SNJ5C2A .

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/tapnair/Project-Archiver/issues/22#issuecomment-719185026, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACT5ODLAKWKIPKVGEFOZVWTSNJDDBANCNFSM4SNJ5C2A .

--

Regards,

Patrick Rainsberry