File / Import BUGS

[Yorg]

Hi all,
As part of our plugin development of a Cross Referencing solution, I’m discovering what appear to be a number of bugs relating to the Import function.
The following is what I’ve reported, but I’d appreciate what you make of them and if you too have observed them:

IMPORT SKP BUGS REPORT.

Context:
We are attempting to build a workflow that will make SU / LO a viable end to end alternative to Revit and Archicad for medium sized, team based Architecture offices like ours.
This requires that team members can work collaboratively with SU by cross referencing each others models.
(I am aware of Trimble connect’s functionality. It is not a viable production environment solution - please contact me for details if you wish.)
We rely on the File / Import functionality as part of this.
This functionality is not performing consistently.

Expected Behaviour:
When File / Importing an SU file, the contents of the source file are made into one Component, which is named after the file name.
In the receiving file, the Import appears as an additional Component in the Outliner tray with the naming convention of “”
It also appears in the Component Definitions tray as “FileName”.
At Import, the Move tool is active, requiring the user to manually place the component in the desired location in the model space.

Issues / bugs Summary
1/ More than one Component is Imported from the source
2/ Wrong naming of Imported model
3/ Activation of the Move tool for placement of the Imported model is sometimes not offered - files are automatically placed

Issues / bugs Detail
1/
Please see jpeg “shot 1”. This shows the receiving file where File / Import will be used. Note in the Components tray the 5 Component Definitions existing in this model prior to Import.
Now refer jpeg “shot 2”. This shows the source file, which is named “MC364_Building”. Note in the Components Tray, “component#82” exists.
Now refer jpeg “shot 3”. This shows the receiving file after the Import has been executed.
There should only be one additional Component, namely “MC364_Building”.
However, there are two Components; the expected, as well as a ‘rogue’ "component#82

2/
Please see jpeg “shot 4”. The highlighted Component is the Imported Component. The file name of the source is “1_CONTEXT.skp”.
The expected naming is therefore “<1_CONTEXT>” in Outliner, and “1_CONTEXT” in the Component Definitions.
Note however that the Component has been arbitrarily named “<Group#689>”

3/
It is not predictable which source files will be automatically placed in the receiving file, rather than requiring manual placement, however once the behaviour is demonstrated it is consistently replicable. I have a number of files I can send if required.

IMPACT
When a team of people are Cross Referencing files into their model space in a production environment, the behaviour of the Import function must be reliable to give confidence that co-ordination mistakes don’t happen on live projects.
We need confidence to establish our production workflow exclusively in SU/LO or we must reluctantly join those using Revit or Archicad.

ATTACHMENTS:
Interface refuses upload.
Here are links:
https://drive.google.com/file/d/0BwtFDuzip8y4cmVqVnZpOGF4REU/view?usp=sharing
https://drive.google.com/file/d/0BwtFDuzip8y4SDNWWEU3RTlEaEE/view?usp=sharing
https://drive.google.com/file/d/0BwtFDuzip8y4M2VYMmVJTlpUb0U/view?usp=sharing
https://drive.google.com/file/d/0BwtFDuzip8y4NnhnQkpvS1AxN00/view?usp=sharing

[Yorg]

Hi Dan.
The bug report is not related to the plugin.
I am referring to native SU functionality, namely the use of File/Import.
Could you please re-read my post in light of that - I would welcome your perspective.

[DanRathbun]

I’ll just withdraw my comments then, as I thought this was with regard to extension implementation.

In your “shot3.jpg” it looks like there may be a planview hovering above the 3D house, but it is partly obscured by the Model Info dialog.

The only way anyone could tell what is amiss, is to be able to examine the files themselves. (I’m not volunteering, just saying that what you report must be reproduced by testers on the SketchUp team.)

So if you could find some smaller model files that show the “bugs” and post them here or in the 3d warehouse, it would help nail down what is happening.

[Yorg]

OK Thanks Dan, I’ll try and find some.

[Yorg]

Hi Dan,
I’m not sure how to send a personal message, but would you be kind enough to repeat your suggestions about what API commands might be useful? (What you withdrew from the post, that is.) I’d like to forward to our developer in case they trigger some good thinking - as we are having a few issues we need to iron out for the plugin dev.

[DanRathbun]

I didn’t save what I had said.

---

I think I suggested that ** I ** would instead use
Sketchup::DefinitionList#load
or
Sketchup::DefinitionList#load_from_url

… and then
Sketchup::Entities#add_instance
or
Sketchup::Model#place_component

You can present users a list of skp files by using either Ruby’s core Dir class:

files = []
Dir::chdir(some_path) {
  files = Dir::glob("*.skp")
}

Class: Dir (Ruby 2.2.4)

Then list them in a WebDialog for picking (if the array is not empty.)
Once picked, concatenate the path and picked file:

File.join(some_path,picked_file)

Class: File (Ruby 2.2.4)

OR,… use the UI module’s standard file picking browser dialog:

picked_file = UI.openpanel( "File to import...", some_path, "*.skp" )

Module: UI — SketchUp Ruby API Documentation

[Yorg]

I hear the “I” disclaimer, no probs

[Yorg]

It is possible I misunderstand native sketchup behaviour, or it has a bug - can you please tell me your understanding:
Is A or B what you understand as appropriate native behaviour?

When using File / Import,
A/ all the contents instanced in the model space of the source file are packaged into a component. This component is named by, either:

• the Operating System File Name or,
• if a value is populated in the Model Info / File Name field, it is named by that value,
  and becomes a Component Definition in the receiving file.
  Component Definitions that are not instanced in the source model space are not imported.

B/ As A, except all Component Definitions that are not instanced in the source model space are also brought into the receiving file as ‘loose’ / unpackaged Component Definitions.

(B is what I am witnessing, but does it make sense to package up what is instanced, and then bring in a bunch of unpurged stuff as an Import?)

[slbaumgartner]

I think that B is the intended and correct behavior.

You are importing a file, which includes all of the file’s contents whether currently used in the visible entities or not. You will get all component definitions, all materials, etc. Potentially, reusing those definitions etc in the new model is a reason for importing. Conversely, if they were leftover junk in the imported file, they should have been purged there before importing. SketchUp isn’t going to arbitrarily make a value judgement about why the unused stuff is in the file.

I think the wrapping of the imported visible entities has two goals: to prevent any loose (ungrouped) edges and faces in the import from unexpectedly affecting other loose edges and faces, and to help you distinguish what you just imported from what was there before. Once you are past those concerns, it is easy enough to explode the import.

[DanRathbun]

@Yorg

‘loose’ / unpackaged Component Definitions

This term makes no sense at all. There can be no such thing, as definitions themselves are the packaging of entities and attributes for reuse as instances.

[Yorg]

Hi Dan,
The inverted commas in ‘loose’ ask you to engage with the contrast between the ‘packaged’ import of instanced content into a Component named after the file name - given I know of no official name to describe them.

Perhaps you could ask for clarification rather than tell me I am being non-sensical?

[Yorg]

Thanks for that, that’s a very helpful perspective.