Four Steps To Create A Scalable Window

axis
components
dynamiccomponents
groups

#1

As an Architect I want to check different window types in my model. So my idea was to insert scale able windows in specific openings.

My experience is, it is quite easy to create a Dynamic Component of a window, but it is almost impossible to insert it to a model behaving nice.

This is what I learned:

  • My reading in developer minds is absolutely bad.
  • To make a window scale able it needs variables in formulas.
  • One is not able to fix a broken formula in the model unless going nuts.

What breaks a formula?
Nearly ever thing one usually works with

  • MakeUnique
  • SaveAs
  • CopyAs
  • Copy and Paste
  • Rename in Outliner
  • Rename in Component Attributes
  • Nested Instances
    Maybe more…

So, this is what I did to make my DC behave nice in the model.
Going back to the roots, you need a pen and paper concept, it will prevent you from swimming around by naming parts and setting size and positions.

  1. Step: Make a Template
    Model a basic window type with all parts needed. Only Groups, no Nested Instances, no Components. Save it as a Template. You can PushAndPull, Scale, Rotate as you like.

  2. Step: Make Components
    Start to model your DC window types with that so made template. Make all changes you want, feel free. Save the model as your window type (Model name). After that Explode the Groups one by one to make it a Component. Take care that all axis are in left-front-bottom-corner. Choose a wise name and never touch Outliner again. Outliner is SU part, Component Attributes is user part.

  3. Step: Add Window Container
    At this time you need a container for the parts to make it a window and as basic for variable parts. Choose a unique name (Container name) to keep control of the window types.

  4. Step: Add Attributes
    Now you can make the parts variable. For this add Attributes for Position and Size. The absolute position is greyed out. To make it relative add the formula all based on LenX, LenZ and frame thickness RD in the window container. Watch the parts moving or not, it helps to edit the formula if needed.

Note about groups:
Make sure all axis of each part is in front-bottom-left corner. Rotating a group will mess around. Explode it and make it a component, the axis will be placed correct and you can see it. Now the name apears in Outliner.

Note about axis:
My building models are made in TopView. To prevent my windows from spinning around inserted in a wall they are modeled in FrontView.

So far, so good. The window type is running well and behaves nice at scaling.

Step 5: Add DC window into a model
SU will add a new container and rename the parts according to the window types already in the model.

Important Note:
If there is any misbehavior, only edit in your basic component!

Note:
To save the component from the model use the first container.
To edit the frame thickness use the second container.

Reliability run:
The saved window type from the building model will have all attributes from the origin component and runs fine, as long as you don’t modify it…

F 2.skp (252.1 KB)

Edit
You can make a group to a component without exploding it. I changed the shortkeys G=MakeGroup, K=MakeComponent. The shortkey couldn’t make a Comonent from a group. I didn’t realise that.


Problem importing modified dynamic components
#2

Hard to follow the entire workflow, probably my bad. I can’t say much about (dis)agreeing with it. Probably I need some more coffee.
Two things though.

  • The window scales nicely to exact dimensions.
  • The window component’s axes could have been oriented better, meaning blue would be perpendicular to the window plane, according to the face (facade) you put it on. Better yet, make it a ‘Glue to’ component, maybe even with ‘Cut Opening’ property. Cutting an opening works on faces in the context of the window container (using TIG’s terminology here).

#3

Thanks for looking at.

For me that is a great missunderstanding. I made the blue axis of the building match the blue axis of the window. So it is much easier to position the window parts. I don’t have to rotate anything, it keeps me away from errors.

You can glue it by inserting the window. It dosen’t work the way I need.

For me it is much easier to Puch and Pull the opening in the wall, because I don’t know the wall thickness, even though it is different in every projekt.


#4

Wo3Dan, can you say more about why you would orient the blue axis perpendicular to the window plane? I tend to use the default standard of blue being up-down for my models and components because it seems intuitive and less prone to translation errors. OTH, I’ve seen several window components built lying flat, and wondered if there was some good reason to do that. What is your reason for suggesting this?


#5

Woodworkers (main reading public here) produce their windows and doors flat on the ground. That’s the way they work.

For architects and engineers the Z-axis is fixed in all structural engineering calculations.


#6

In regards blue axis, the reasoning is to match to xy cutting/gluing plane, however I found it better to have a separate opening component to cut multiple walls with the window attached (not part of the parent but set to scale able) with its normal z axis up, Again best of both concepts.


#7

Creating the (any) “Glue To” component flat on the ground is the easiest way, … or right on an existing face, say a window on an existing vertical face. Even SketchUp, in case of creating components on a face, thinks it’s right to orient blue perpendicular to that particular face. And in case of the extra ‘Cut Opening’ property it is even a necessity.. Why work against “nature”? The option to make a dynamic scalable window component still needs the blue axis perpendicular to the window plane.


#8

Why? For what?

My windows are glued to none, but they don’t ‘move around the corner’ by setting any while inserting.

What am I missing?

Edit:
I think I know now.
Modifyed my window flat, mend all broken formulas, glued to any, tested it inserting in a wall.
This is the answer:
Crash Report #88720
Crash Report #88733
To save my laptop from biting it, going in fitness center.


#9

the cutting or gluing plane is always on the xy plane therefore the blue axis for this component or group will always be perpendicular


#10

Got it.
In SU the height is green axis, and the blue axis is perpendicular. That’ s 2D.

So I tried to follow your advice.
Crash Report #89101
Crash Report #89119
Crash Report #89141
Crash Report #89219

What I learned:

  • I am able to make SU crash :slight_smile:
  • I’m not able to work against my physical understanding, I’m too old for that.
  • For me the height is the blue axis, that is perpendicular in 3D

Never change a running system:

  • I will leave my windows against SU-nature. They are running fine without rotating, exept “around the corner”.

  • I will never touch “glue to” or “rotate” in dynamic componants again to prevent SU from crashing.

Thanks you for reading.


#11

I have not bothered with “Glue To” or “Cut Opening” beyond a brief look because I determined that they would not be helpful for my purposes with the reusable components I’ve built. I will check them out, though, in case they come in handy in the future. Thanks.


#12

For designing the window another step is needed.

Lots of crashes were fixed with an update SU 2017 M1.


#13

There can be reasons why you might want the axis in other locations -for example you might want it in the center of a doors outer most component to make it easier to place.

I have never needed to match the cutting plane axis with the rest of the component axis -but can not say if it is an improvement or not.

Sorry to see you are having so many crashes. My system has been pretty stable but I do also sometimes get a crash when working with DC’s

Certainly a frustrating process to learn but seems like you are coming along well.


#14

Yes, it was real hard work. But now its fun again.


#15

@Barbara Looks like you have discovered what I discovered when I tried making DC windows and doors. It’s nowhere near as easy as it should be. The litmus test for me for something like this is: is it faster to make a DC and then make use of it or is it just as fast to work from scratch each time? I concluded it was probably faster to work from scratch. It certainly is a lot less frustrating! Another test might be how many people appear to have mastered the technique. Judging by the models in the Warehouse, the answer is not many. It’s a shame because the idea is a good one.

I found that a large part of the problem is that the interface is very clunky. You often find yourself scrolling up and down within the dialog box, having to remember references, etc. It can take a very long time to do something quite simple. If the developers could address that, the full power of DCs might be unleashed.

As it stands now, the system might be useful for a manufacturer as they only have a limited range of products to wrestle with. As a designer, I have an almost infinite number of potential components and I don’t use any one often enough to justify the time spent on creating a working DC.


#16

Good point.
Can you give some examples of a components that you would like to be dynamic and what they should do, in writing, not as not working DCs.? Just simple stuf to begin with. A scaleble window (length/height) of some type isn’t that hard to create.


#17

@Wo3Dan, you asked for it. Here is a very simple example.

A four room appartment needs 7 doors, 4= room, 1= kitchen, 1= bath, 1= entrance.
They have different wallthickness and different length, sometimes different heights.

I made my components with Follow Me, but still I have to scale them to optimize to the opening in the model, because it’s a little different from standard every time.

It would be nice to see the dimensions (maybe hover?), of course it has to be compatible with Generate Report.


#18

@Wo3Dan The commonest components would certainly be windows and doors. Here in the UK we have many different styes of both so a comprehensive library would need to be large just to contain each generic type. You then want to be able to adapt them to suit opening sizes. Stairs would be another.

I wonder if you meant scaleable? You could certainly take a generic component and scale it but the problem is that the scaling applies to everything whereas the point of a DC is to limit what gets scaled up or down.

Besides 3D components, 2D components are also useful for simple plans. I have already uploaded some DCs of them to the Warehouse and people do seem to find them useful. They are of course much simpler to create.

I would reiterate my point that the main bar to making DCs is the user-friendliness of the interface. The general rule applies that just because you can do something doesn’t mean you will. It has to be intuitive and non-frustrating! (One of my soapbox bugbears with the tech industry is that it often seems fixated on new “functionality” and too little concerned with usability).


#19

Can I have a look at them?


#20

@Barbara Sure. Just look up my user name in 3D Warehouse. It is Simon E. (don’t forget the full stop at the end!).