#layer_group ⇒ Object (Layer Group methods ?)

l#layer_group-instance_method

Browsing the new features because of SU2020, I just noticed that there is a “new” instance_method in the Ruby documentation.
Is this intentional? Was that there in the past? Does anyone know what this is? Or something will come…?

Looks like an error. There is no description of what it does, example or anything.
2020-01-29_11h24_43

Yes
I thought it was still being updated.
I can imagine some potential …

image

6 Likes

We’ve requested them for like … forever. So don’t be surprised if, at the least, some testing is going on.

In the UI they’d be now called “tag groups”. (But the class names are not renamed in the APIs. Renaming would break code.)

Mainly they’d be an organizational aid, allowing sets of tags to be expanded and collapsed in the inspector list.

But also some users want each group to have a toggle that affects all objects that use it’s subordinate tags. That could be useful or cause confusion. But I’d leave it up to the users to find the best way to use them.

The main question I’d have is, would it be possible to have nested groups, should there be, and if so how many levels?

1 Like

If you allow nesting in the first place, I think it should be recursive to any level (well, it must fit into your computer memory). I think any choice of maximum nesting would be an arbitrary choice. There is nothing inherent about 3 nesting levels that makes it more logical than 4 or in 4 that makes it more logical than 5 and so on.

What is the max nesting level of groups or components ? It could be same for Layers/Tags…
But I believe, not need more than ~5-10, otherwise will be confusing even on the UI.

I can agree that it would look weird in the panel with too many nesting level and too much indentation, but in such edge case I think we can just allow it to look weird. I think most models wont use nesting at all, some will have one or two levels, a handful 3, som rare ones 4 and so on.

I think this is a good analogy. In some cases it doesn’t make much sense to have more than 2-3 levels, in others you can have 10 and that makes total sense.

The most extreme case I can think of right now would be someone building a set to photograph several products, including carpenter drawings.

Sections
  A
  B
Plan
Photography
  Overview 1
  Overview 2
  Products
    <some product ID>
      Front
      Side
      Detail
      Context
    <some product ID>
      Front
      Side
      Detail
      Context
    <some product ID>
      Front
      Side
      Detail
      Context

I’m sure someone could come up with an example where additional levels are appropriate.

1 Like

for historic reasons I think tag name length may cap nesting depth …

nested_tag_name = %w[Photography Products <some product ID> Context]
may_be_an_issue = nested_tag_name.to_json.length >= 60

I recall some sort of ‘MAX_LENGTH’ being hardcoded for javascript bridge ‘Generate Report’, ‘DC’ and others…

but, this could be poor memory on my part or something fixed with HtmlDialogs…

john

Except that tags are used for controlling visibility, and so each object in the rendering view must have it’s tag object checked for it’s visible? property. Any nesting adds a visibility tree which the rendering pipeline must walk inspecting “superior” tag visible? properties.

Keeping levels to some safe maximum may be desirable for rendering speed sake.

While that is true such rule doesn’t have to be enforced by the software itself. Performance also suffers from a high polygon count but SketchUp doesn’t have a hard limit where it tells you you already have X polygons and thus cannot add more.

True, and I am always in favor of the user using software they way the wish and need.