Dynamic Components

DCs are SU components that have a bunch of sub-components. And sub-components positions itself inside the parent using spreadsheet formulas. Any particular topics?
-    Curious about internal representation of DCs and how operations of scaling and transforms are affected in terms of the component model. How does scaling work in context of DCs? Relationship between a suite of hidden models.
-    Having all data and parameters in DCS. How close are we to IFC/BIM?
-    Namespace handling and attributes. Can’t say .., have to say “fred” to talk about parent.
-    Large quantity of DCs in a model – 20 copies of a certain DC.. A lot of duplicate sub components. Start getting problems, specifically in LO model. Performance and challenges.
-    Cut and shift door. Glue to a wall and you have to start over.
-    Awareness of each other (DCs) and be able to talk to each other and to know about model.
-    Potential for not having named copies of something like a picket in a fence, but just have more geometry.
-    Having to do scaling affects textures. Detached with scaling of materials as DC changes size.
-    Bunch of boards, scale, and couldn’t get it to work correctly.

Scott: How many people are architects? About 5. Residential designer? Industrial designers? Engineers? Mfg? Goal of DCs to create lightweight parametric model to work on top of components. Intentional decisions not to go into certain areas. Parametric components not easy in any event.
Once you understand internal model, can build almost anything. That’s the goal. Generic internal model.
IFC/BIM: Not intended to be hardcore BIM product.  DC doesn’t relate to IFC. Goal would be how to create _____ in SketchUp and take into revit. Can take simple stuff into Revit as formulas are similar. But the way you might represent the geometry is different in SU versus Revit. Is that true with Solid models? You could do that with a refactor of DCs, but not today.

  • In SU pro you can do a generate report and export attributes as HTML XML file. You could probably get workflows where you could draw something in SketchUp into a form that some other program would read. Talking about what attributes are…talking about formulas.
  • Creating a Tree (parametric – driven by parameters -- tree). Break into subcomponents first.  Three: Pot component, Trunk component, Canopy component. Group into Tree. Check our HC and Sketchucation. Write spreadsheet formulas that control sizes based on some parameters.  Age might be a parameter.  Height of trunk (LENZ) age/2.*12. Relate height of trunk to age of tree. Could so same thing with radius of trunk, position of canopy, size of canopy, etc. all driven off age.
  • Can you have parameters controlled by season of year? Day of year? There is a library of functions you can call. There are a few things of the SU model you can inspect such as sun angle. Not currently a formula for time of year. Could have second custom attribute Season that has four options. The grammar supported by Google spreadsheets is what is used.
  • 30 or 40 spreadsheet functions supported. Cannot currently use month/date to drive the component. Not currently supported. I want a 20 year old tree and I want the leaves to be gone in fall. Use “is hidden.” DC is a component with a bunch of subcomponents and you can start to imagine that there are a lot of things driven in that fashion.
  • Base attributes can affect other attributes. If you are in an environment where you have plug-ins, you can pass data into/out of  DCs. Rich’s point: attributes can be calculated off of other attributes. Weight of tree might be based on age/species. Calculate cost based on weight. We don’t have a year/month in base DCs, but the list of functions is extensible by Ruby programmers. Implement a method on certain module. Can type in to formula box (won’t just show up).
  • Obviously SketchUp is reacting to changes in variable values. There is no observer mechanism for attributes. Observer is only on DC in that it reacts to tools.
  • You can create a function in Ruby and the argument. Insert observer into the chain through Ruby.
  • Can a DC be given a sequential functions like have 4 door panels on a garage door open? Yes, the idea is create door, have 4 panels (each is sub component). And create global variable called % open. Do trig to figure out formula that is going to calculate.
  • Mitchell saw it early. He has built many DCs. He’s pushed it to the edge. Very complicated models. DCs are implemented in Ruby. Just like any other Ruby plug-in as size of model/operations grows, performance goes down. Dynamic conveyors, have 20, eventually you have to make them a solid model. Is there a way to fix it once you have it set at a size. You can explode it. Or there’s a ruby script that will remove all attributes. Every developer has a way to strip out stuff. Explode to base geometry and create new, fixed, component.
  • Would be nice (Todd) to have the ability to return to return it to its original state.
  • Whenever you are asking for a redraw it gets nasty. Rescale, reapply materials, or other tool operations. Have lightweight check to see if you need to redraw. If so, you do and its slow.
  • Hooked to your render quality too. Turn off shadows, turn off profiles, etc. Gain those same advantages. Even if a subcomponent is not visible its slower? You can select and hide stuff and it will be a little faster. Part of Goal of DCs is to take things that have millions of variations from a few simple selections. Cabinets are a good example. Just depends on use case. Can save time or be overkill.
  • Idea: have slider that has full affects, few affects, no affects for performance type. Scott does that with styles. Done.
  • Don’t want to repeat formulas. Wouldn’t want size formulas for each canopy in a tree in each subcomponent. You want that in tree component called “Canopy Radius” and run it once and ask subcomponents to ask for radius from parent. There’s only one level of separation. Can have attribute in parent (tree) called trunk!child.
  • You cannot do A!B!C.
  • Right now when you ask about parent, you have to name your parent. Fred!foo. If you move that subcomponent, you have to change a bunch of stuff. There is a parent keyword. You can do Parent!name of attribute to get it that way.
  • Its possible to embed a function in Ruby that can be referenced in an equation. Its also possible to store attribute strings. Is there anyone preventing someone for creating a syntax for traversing stuff.
  • You do want to be able to have a drawer ask cabinet something. But, you have to pass them all down.
  • Feature request (Scott): have a call that allows you to get to global attributes base.
  • Would be nice to have global namespace where you do “turn off handle” and they are all hidden. Two people recommended this. Could do this through ruby API.
  • No direct connection to BIM
  • Performance – do same things with DCs that you do with SketchUp Components.
  • Door. Convert to glue to component. SketchUp internally represents all Glue To component’s up as all green axis. SU internals think of glue to components as being on the floor. All formulas get screwed up if you think Z is up for a Glue To component. Create a door as a sub component of another door that’s the glue to component. I wouldn’t recommend that because you’ll quickly get confused.
  • Create glue-to components on the floor.
  • Could write ruby script that changes human space door to glue-to space door.  Swap Z and Y in every formula.
  • Model awareness of each other? Cabinet should be able to recognize cooktop. Smart rules based on adjacent things. Haven’t gotten to this one yet. Can do multiple selection in DCs. Global setting process.
  • Replicating geometry instead of copying subcomponents. No plans right now. Right now creates component instance instead of more geometry. Makes file bigger, so we’re not doing it.
  • In su when you have a regular component that copied, you have pointer. If each picket have intelligence then you get component. Move everything into parent so picket is “dumb,” won’t make new definions which won’t make new instances.
  • Material scaling as attributes. Feature request.
Comments