Are Directly Opened Component Files Exploded?

SketchUp Pro
1

864×751 150 KB

It’s supposed to be that way?
What is the reasoning for programming a DC to explode when SU is opened by double clicking it?

I can not imagine any circumstance where that behavior would be desirable.

The only benefit I can see is that the file name is automatically made.
I guess maybe that would be handy is if you where making tutorials using the 3DWH and you think the end user does not know how to name a file

The parent component is at the model level?
The attributes are still in the model?

So what does this mean?
If I define variables in the parent component they are still defined in the model?
Do they become some sort of global variable that can be called by other components?

I do not see any evidence that any attribute set in the parent is still “in the model”

I would sure like to hear an explanation of this.

2

This may help…

3

I’m not sure if I understand what way, you didn’t tell what you did to get there. Did you insert the dynamic component into a model, or did you open directly the skp file that is the dynamic component? By double-clicking, do you mean double-clicking the SketchUp launcher icon, or a skp file icon?

4

Yes that works fine for me, I do not have a problem saving components.

…but when I send someone else that component and they open SU by double clicking it then it is exploded.

What I fail to understand is -why?

What is the purpose behind making a component explode under any circumstance other than the explode command?

What does it mean when they say that it is exploded but the attributes are still in the model?

5

It means that they did not choose the terminology well.
And secondly, they should have chosen a separate file extension for component files, like: skc or whatever.

In your mind you are confounding a true skp model file and one that is ONLY meant to be inserted into another model file.

They are not really the same. There is some “black magic”* going on within the SKP file format, that you cannot see. This is why you cannot “see” the components context (the bounding box) or access the attributes that are really attached to the component’s “envelope” (to coin a phrase.)

The guys who created SketchUp thought they were saving something, time, cost, (I don’t know really,) but it would have been more understandable if component files had their own file extension, and if they loaded into a special “component edit mode” when directly opened.

So, in order to edit a component file,… you open a blank empty model, then insert an instance of the component, then edit it, then save the component back to the original component file. (Lastly, just discard the model that you used for doing the editing.)

  • Yes I know there really isn’t “black magic” in the file format. (I just want him to have the epiphany of the two uses of skp files.)
    The real “black magic” is actually in the insert and import commands.
1 Like
6

OK, given what I said above, let’s be more specific about some of your questions.

No one has programmed the component to actually explode. It just seems that an explode has happened, because the outer envelope of the component is hidden from you.

The components must be saved in a special way, so that they do not get inserted in models in a double-wrapped context.

The only reason you would open the component file directly is to edit the subordinate objects, groups or nested components.

As I said above, to edit* the attributes or change the orientation, etc., you would normally edit an instance of the component in a blank model, and re-save the component (as if creating it,) back to the same component file.

To be more specific… because it IS a component file, …

The parent component IS the model.
and
The attributes are shown attached to the model.

But to see (*or edit) the attributes, you need to use a attribute viewer plugin, like Aerilius’ Attribute Inspector.

7

To simplify Dan’s:
-To my understanding-
If you have a model file with several pieces, and you import it into another file, it is automatically all grouped into a single new group.
If that were to happen with component files, they would be double-grouped.

So, they are ‘unwrap’ in the component file, so when imported, it is auto-grouped once and proper.
So when editing in the component file, imagine you’ve already double-clicked and are editing inside the component.

Yes it’s slightly confusing how a Save-As component file is different.

8

When you open a skp model in SketchUp, you are “inside” the model’s bounding box. This is sensible because the whole model must be a container for all it contains (and can then have model attributes etc.). And when inserting a model into another model, you expect to insert it as one object.

So when you save a component as skp file, it becomes a model, and the component’s bounding box becomes the model’s bounding box. When – instead of inserting the component’s skp file – you open it directly, you are placed inside the component’s bounding box, which looks like it was exploded, but it is completely unchanged.

1 Like
9

Chris,

It seems you didn’t go read the entire post.
I’ll save you the trip.

Here’s what happens using Context Menu > Save As

When you save a component to a directory via Context Menu >Save As it creates a .skp model file.
However, SketchUp does a little magic trick in the process.
There’s a difference between a component .skp file created via Context Menu > Save As and a .skp model file created via File > Save

The difference is…
The .skp file created by Context Menu > Save As does not contain the component definition.
That’s because when it’s brought back into a model via the Components Browser or File > Import the entire .skp file becomes a component definition (file name and all) and if there were a like named component in the file it would end up a redundant copy nested inside.

10

Except that really does not make since.
If I wanted to import (groups) I would not open that component by double clicking it and having it create a new file. I would already be in the file I am working on and insert the new (groups) component from the component menu.

There is only one case that I can think of where you would open SU by double clicking a component and that is when you are interested in working on or looking at that component. But causing it to explode on opening just means that it has to have an extra shell placed around it.

For all practical purposes it is exploded because anything defined at the outer shell is gone. (All variables and attributes.)

No I open a component file to edit that component. Perhaps I am doing it wrong though -it sounds like you must make all your components with a blank outer shell.

Oh OK then they are still there -Interesting information -but if I need a plugin to view them what good are they?
I still see no advantage in having the attributes hidden at the model level but I assume there must be some reason for it.

As far as I can tell what you are saying is that the reason is:
SU does not distinguish between a component skp and a model skp

Yes I can see that you want a model skp to be at the top level -I guess it was just easier to not program a component skp to know what it is.

Thanks for the explanation guys, I was just curious.
The wording was not very good in that tutorial.

11

Once again, NO explode has occurred upon opening !

The “magic” was done when the file was created via “Save As Component”.
The “magic” will be undone when the file is inserted as a component.

This is not true.

The former definition’s entities collection has been saved as the new component files’s model entities collection. The former component’s attribute dictionaries collection, has been saved as the new component file’s model attribute dictionaries collection. The former definition’s origin has been saved as the new component’s model origin.

Nothing is gone.

To insist that exploding is occurring, just creates a mental block, that prevents you from understanding this concept. Forget the word and concept of “explode” with regard to this issue. It is bad wording that the original author of the tutorial, thought would somehow make people understand.

[quote=“ChrisStewart, post:10, topic:12248”]
Oh OK then they [attributes,] are still there … -but if I need a plugin to view them what good are they?
I still see no advantage in having the attributes hidden at the model level …[/quote]
This is not any different than dealing with attributes in a normal model. A plugin has always been needed to allow end users to view or edit them.

Attributes and their Dictionaries (as well as collections of the latter,) were not designed as end user objects. They were always meant as programmatic data objects, hidden “behind the curtain” but enabling plugins to do nifty visible things.

So nothing more nor less has been hidden.

In fact, “Dynamic Components” is an extension, which can be switched on and off, that provides a webdialog to view only specially named attribute dictionaries, if it exist, attached to component definitions and instances.

You will be surprised at the number of other attribute dictionaries attached to the model or other subordinate model constructs “under the hood.” Users are not normally supposed to know about them, because they are plugin data, and if altered, can break plugin functionality. Some of it is very fundamental, such as the GeoReference information.

Correct. This means that ANY model skp file can be inserted as a component, into another model.

This is exactly what happens when you use the Component Browser and grab someone else’s building model from the 3D Warehouse, and insert it into your model. The model skp from 3DW, is made into a component definition, and an instance of it is inserted where you point to have it inserted.

[quote=“ChrisStewart, post:10, topic:12248”]
The wording was not very good in that tutorial.[/quote]
Agreed. They are working on overhauling all the docs as we speak.

2 Likes
12

OK, what you are saying is that any variables and formulas that where in the top component are now at the model level.

If you do not want to call it an explosion fine

I see what you are saying -if I open it by double clicking it and then I save that file and then load it thru the component window the outer shell is still there -so the DC has not actually been exploded.

…but when the DC stops functioning and the outermost shell is inaccessible -it is for all practical purposes exploded in that SU session. In other word it behaves just like it has been exploded.

I can certainly see why attributes need to be defined at the model level but I see no reason why a DC should come in at that level when doing so breaks the function of the DC and those attributes are not usable to anyone without Ruby.

Now if those hidden attributes where accessible to DC’s as global variables I could certainly see some value in doing that. But I kind of doubt that Ruby programmers are initiating variables through DC’s when they can simply write a long list of variables to initialize.

I think it would be a great addition to DC to be able to have global variables and access to all ruby console functionality.

I understand -it just seems poorly done. Someone did not want to take the time to do it correctly.
I would not insert a model into another model by double clicking it. I do not think it is even possible.

If the same format is going to be used for both then an skp file needs to know if it is a model or a DC.

13

In a few words…

Insert the component from the component browser into a model and it is a whole component.

Or

Double click a component in Windows Explorer and you are opening the component for editing.

Double Click a DC Component within a model and you have opened it for editing. Where is the difference?

2 Likes
14

Thanks box,
When I double click a component from explorer I can not edit the component because the outer most shell is now at the model level and inaccessible.

The only way this would work is if a component is saved as a model file and not by right clicking the components context menu and doing a save as.

So I suppose the method is that if I intend to have the skp file opened by double click than I need to save it at the file menu and if I intend to have it loaded through the component window I would save it as a component.

Saving it from the main menu essentially adds another shell around a component which includes the settings for the entire workspace.

The only problem with this is that unless you are using the default settings the file size will grow substantially.

15

All I can add is you will come back one day and read this thread and slap your forehead.

2 Likes
16

I do not think so, what you are describing only works when the component is not a DC.

It would work fine on any component that was simply a collection of lines to be edited.

17

You are missing the point, a DC is just an elaborate component, if you are inside the wrapping it’s just a bunch of geometry and groups. Without the shell it is nothing. Same as any other group or component.
Once inside the skin you can fiddle with the bones but not the joints.

2 Likes
18

Once again, no it does not. But apparently you are choosing not to believe it.

Someday you’ll insert a DC component instance in a model, and explode it. Then you’ll start poking around and realize that the parts of the former instance, are now part of the model’s entities. You may go looking for the former instances attribute dictionary, and realize that it is not attached to the model,… and there is no longer a component instance context for it to be attached to, so it has ceased to exist. Even if you had a Ruby object reference to it in the console, that reference now returns a “DeletedEntity” error.

Then you’ll realize that directly opening a component file, and exploding a component, do not behave the same.

Let me say it simply! Stop double-clicking on component files, most especially Dynamic Component files. SketchUp is not designed for you to edit DCs this way.

I said what I said. There is no point in saying anymore, because you keep obstinately twisting what I say. Refusing to accept the truth, and making weird nonsensical statements about Ruby, global variables and programmers with regard to Dynamic Components. (You should know I have 32 years programming experience, and 7 of them coding Ruby for SketchUp. I just spent ~2 weeks coding an extension that enhances the functionality of Dynamic Components.)

1 Like
19

I understand that,
It is not that the current system is unworkable.

Double clicking it requires that the DC be wrapped in an additional blank shell. It also forces the user workspace to the component creators workspace.

…but I can see where sometimes you might want a component to set up its own workspace.

Of course the solution is -do not open a DC component by double clicking it from explorer.

24

I simple asked why we would want a DC to work the way it is stated in the tutorial I referenced.

The answer is: we would not.
We want models to work that way, we may want to make a tutorial work that way but in no case do we want a DC to work that way. We avoid this by not opening a DC by double clicking it. Or by wrapping an additional blank shell around it.

In most situations we do not open SU by double clicking a DC the only time we do that is when we are exchanging DCs through the web here or with other people.

The solution is to either change the behavior of skp files or make the tutorial better.

Example:
If I send you a word document as an email attachment you might open it by double clicking it. You would not expect all the formatting to be removed but that is what is essentially happening when the skp file is a DC and not a model.