Export COLLADA "selection only" not working!

Exporting a COLLADA (.dae) file with one group or component selected, with “Export only selection set” checked from the export options menu… it doesn’t work, no file is created!

I have tried various groups and components to no avail. 2021. Please help urgently!

Or is there another way to mass-export many components, where each keeps the axis system from the main model? This is for importing into Lumion for an “animated phasing” animation.

Export selected is broken, this is a known bug of 2021 which effects exporting in all file types. Export model still works. Current work around is to select only the object/objects you want, copy to clipboard, open a new file and paste in place to maintain the objects relation to axis. Then export that entire file.

This is proving a major issue for me. I’ve just got round to switching over to 2021 and have found the DAE Exports aren’t working correctly. I tried to copy and paste in place to another file but the exported file still contained errors in placement. I hope this is fixed soon as I’ve now had to roll back to 2020.

Yeah. I spent about ten times the time I’d allocated to this project because I was copying and pasting in place, then saving a .skp. For 569 individual files!

That’s extreme! Sorry to hear it. This needs to be fixed soon.

Ouch 569 files?. Do you have a working earlier version of SketchUp? This function is only broken in 2021, any previous version exports selections correctly. If you Save As your working file in 2021 you can save it as any previous version file type, then open it in that version and export .dae selections from there.

FYI, SketchUp Make 17 is still available for free download HERE and it exports collada selections just fine. If I had to export 500+ items I would be saving the main file as 17 format, opening in Make 17 and exporting selections from there. Just a thought.

2 Likes

Cant Sketchup just release a patch or something?

It is something we know needs a fix. I can’t tell you when an update will be available. When it is available you won’t be able to stop me talking about it.

Don’t expect a fix anytime soon. I firmly believe all the good developers have left Trimble and they’re dealing with interns trying to decipher things. I have two repeatable and traceable crashing issues that are a complete pain in the *ss because they cause SU2021 to shut down unexpectedly when closing a file that’s located on a network drive, and after sending probably a hundred bug splats or more, there are no fixes for those in almost five months. So issues that don’t result in crashes and that have work-arounds will not be put at the top of their to-fix list. I reported this same “export only” issue months ago, hence my jumping in and commenting here months later.

This whole subscription model thing to produce predictable income so that Trimble can develop more efficiently and quickly, seems to have been complete horsesh*t. Sorry Colin. I’ll bet anyone on your dev team that I could have traced and fixed my two crash issues by now in my spare time, so I have no sympathy for your devs. And I’d pay more for Pro if I could depend on it not crashing. It’s an amazing app. But this crashing really screws up productivity and wastes the time of people that depend on it.

Do not save directly to the “cloud”.

Local network drive. SU should have no problem with it, but SU has code in a C++ destructor from the @Last days and I’m sure it either hasn’t been maintained, someone made a mistake, or Apple made a change that is either has a bug or that hasn’t been accounted for within the old @Last code. Most likely, a change was made in SU2021 that affects the order of class destruction, and the two repeatable bugs I see are dangling pointers that aren’t being handled properly.