Collada import/export roundtrip (name field is exported but not imported)

Technical Problems
1

Right, I think a previous thread about this went downhill in more ways than one. Not sure why. I was legit enjoying the technical exchanges with @DanRathbun. I’m hoping to avoid rewriting everything in the previous thread because I did not save the text of any of my comments, and they were long.

The core issue is: when you export into .dae, the “name” comes through, but the name is not part of the import. The issue affects all SketchUp versions that I know, including Pro.

In a previous thread, we had identified the matter as desirable feature for inclusion, and I was hoping it could be qualified as an implementation bug.

I do think it is a bug. It is reasonable to expect fields exported to be imported. It’s actually odd when this is not the case as import and export features tend to mirror one another. So, I’m genuinely thinking this became a bug because it was a low-priority matter and a couple/few lines of code present in the export somehow failed to make it to the import.

So, I’m really hoping we can check with a member of the team if the matter is the result of intentional design or an unfortunate implementation bug before assuming either way.

About the relevant version of SketchUp. We’re developing a tool for a varied community. There are users of several versions of SketchUp, including Pro and, I imagine, existing or potential users via institutional licenses because it is a research-heavy community and that’s what universities and very large companies do. The issue is cross-version.

A little background. This might surprise many, but SketchUp is currently somewhat popular in the lands of quantum computing. Aspects of quantum computing are very graphical in ways that SketchUp can help (think pipes/conduits). Increasingly, though, the structures being created in SketchUp will need to be moved back and forth between SketchUp and other systems. So, I suppose what I’m saying is, addressing this issue could help cement the tool in a potentially large emerging market and, inversely, not addressing it might hamper adoption.

1 Like
2

To be more specific, … the .dae export writes a Collada version attribute of "1.4.1", which exports the SketchUp component definition name property (with spaces converted to underscores) to a Collada node name attribute, but does not export the SketchUp component instances name property to the Collada <instance_geometry> name attributes. (The latter was supported by the Collada version 1.4.1 specification as optional.)

Importing a .dae Collada file does not import either the definition or instance names into SketchUp. The definition name is a unique generated numbered name with "Component" prefix. The instance names are left unassigned (as empty strings.)

It is desirable that both export and perhaps giving the user the options via the import dialog whether to bring in the external names.

I’ll open a Labs issue (linking this forum topic) so that hopefully @TedVitale_SU or Tiago can log an internal bug (or whatever) report.

3 Likes
3

@DanRathbun
Thanks, buddy. It’s been a pleasure. Hopefully we’ll get to talk more in the future.

1 Like
4

Taking a look at the Collada code generated by SketchUp I can understand how we operate and some other stuff:

image
image1203×654 164 KB

image
image1190×627 112 KB

To @DanRathbun point, I don’t think a UI option is necessary as long as we define a default value for empty instances when exporting from SketchUp (example: ‘SketchUp_Instance_01’). This way, when importing back, we can recognize these placeholders and leave the Component Instance empty, as expected.

From my understanding, other solutions do not modify the instance value in Collada during simulations (or at least, they shouldn’t). That’s why I want to ensure SketchUp follows the same approach.

For any instance names that are not in the ‘SketchUp_Instance_XX’ format, we should populate the Component Instance with the Collada instance name. This ensures that when importing a Collada file from sources other than SketchUp, we maintain fidelity and roundtrip consistency.

Apologies if I’m not using the precise Collada terminology, but I hope the idea is clear. I’ve created a ticket to track this, so let’s see how things evolve.

5

Ah, okay I did not notice that the instance name was exported to the <visual scene> members. Regardless, it does not import back in.

I am not up on all the format for Collada, but it seems weird that the instance names are not attached to the <instance_geometry> elements. I thought that the <library_visual scenes> were for cameras and what are scene pages in SketchUp. Then again, Collada terminology may use a different mindset then SketchUp terminology.

(a) What I meant was that the user doing an import, may wish to decide whether or not to bring in external definition and/or instances names. I was playing “devil’s advocate” here.
This issue topic was begun by those users who DO want the external names brought in during import.

:man_shrugging: Maybe, everyone wants external names imported, but I like it when the user has control. Generally, changes like this (after some much time) are implemented as an option so as not to break existing workflows or extensions “in the wild”.

I do NOT understand introducing some unwritten protocol for representing an empty XML attribute. Wouldn’t the absence of the attribute or an empty attribute (ie, name="") be enough for the import to know to leave the SketchUp name property empty?

6

Leaving the name empty can lead to other solutions automatically adding a “node_01” or “instance_01” to that field, harming the roundtrip.

For instance, we already have logic in place to handle this in other file formats such as IFC, USDZ, and GLB. Matching different schema semantics with SketchUp’s logic is not always straightforward, but that’s what interoperability is about, not just creating geometries, but also ensuring data is treated correctly and consistently.

Let’s see how things progress. I really appreciate your time and effort on this issue :slight_smile:

1 Like
7

I think this is where this issue is difficult to deal with because it’s a little bug and a little (continuous) improvement.

Pending testing, the placeholder trick might suffice to address what I’ve been referring as a bug, which I think it’s better encapsulated as “enabling roundtrips”. It also seems possible to add a beautiful ReGex to capture terms currently used (like “Component” and “Component_#”, and maybe others depending on version). Should avoid any accidental breaking of processes out there “in the wild”.

Obviously, that’s selfish as it also seems a quick-to-deploy solution. That said, sometimes you can be both selfish and right.

Additionally, this suggestion I quote above (and I think another you made in the original post) do seem a fair (continuous) improvement consideration. Especially if there is an ongoing effort to keep exporters and importers up to spec. What I’ve seen some do in this cases, is introduce the improved version as new “Name2” function, then wait some years to withdraw the original.

8

Sorry, forgot to tag on previous reply. (Is it necessary to tag? Do you get notifications anyway?)

@tiagoricotta @DanRathbun

9

No and yes (as participants in a topic we get notified, especially if it is a reply or something we posted is quoted. Take note of the different kinds of icons in your avatar menu at top-right.)

1 Like