Nested Layers

Showing 1-10 of 10 messages
Nested Layers tacarr 8/23/09 11:47 PM
I have read with interest the discussion regarding 'Layer
Containment'. Having built a rather large model using Layer '0' as the
'working' layer and then grouping and transferring to a new, named,
layer I have come across a problem when importing a component from,
say, 3D Wharehouse. The newly added component can have its own
layering convention and  when it is incorporated into the master model
the layers are just inserted into the layer listing causing,
sometimes, confusion within a carefully constructed layer list.

My suggestion is to enable the layer list to be 'nested' in a similar
way to the Outliner window, thus when a component is added the
associated layers are contained within the 'Master' layer. These sub
layers can then be viewed as required and not clutter up the original
model listing.

This, I feel, would greatly increase the power of the layer window by
simplifying the access to the elements of an imported component and
removing the confusion of an 'unruly' layer listing.
Re: Nested Layers mysearch 8/24/09 12:57 AM
I raised the initial question about layer containment, because like
yourself I am building a large model. I have also come across the
problem you have described, but feel that it is only one of several
issues that are problematic with SU when trying to develop larger
models. This comment is not meant to be critical of what SU has
achieved, as I am a big fan. However, I believe SU could be more
supportive of a more hierarchical approach to the management and
organisation of larger models.

For example, importing components can not only mess up existing
layers, but can equally affect the existing organisation of components
and materials for which there also no In-Model hierarchical structure.
I don’t know whether this forum has already discussed these issues or
whether the SU development team is in a position to address them, but
it would be useful to know whether any further discussion of the
following SU management interfaces is of any value:

o        Layers
o        Outliner
o        Components
o        Materials

Simply by way of an optimistic introduction:

Would it be possible for the interfaces listed above to operate in a
consistent fashion and support a hierarchical structure?

Would it be generally useful if a ‘model report’ could be printed or
preferably saved to a text file?

This report would list, not only the ‘model info’, but also all the
listed names used within layers, outliner, components and materials
within the model.
Re: Nested Layers jgb 8/24/09 4:03 AM
I too have had this problem, not only with components, but with
objects imported from my other drawings.  Layer0 is not so much a
problem as simply unnamed layer1 and layer2 objects.

To prevent that, I no longer use unnamed layers.  I use  a fairly
developed hierarchy of layers using numeric prefixes, to keep track of
the structure.  In that way I can create a master model (i.e. an
airplane) and then develop detailed separate sub models of complex
parts, such as the wings, passenger cabins, etc.  Each section of the
master drawing is given its master number, (i.e. 4.00 Wing) and in the
wing sub drawing, that is expanded to the various wing components,
such as 4.30 Engines.  That way when I move a detail back to the
master drawing, or pull in other major parts from any other drawings,
the layers all fall neatly into place.  No doubt, many using SU do a
similar construct.

However, incorporating other components or parts of other peoples
models will not fit my hierarchy.  In severe cases, I've had to do an
intermediate import to a blank sheet, redefine the layers and then
import to my drawing.

What should happen, though, is when any object is imported into any
multi layered drawing, SU should present 3 choices.
1- Import layers as is (the current default),
2- Change all incoming layers to layer0, which includes all nested
layered elements, and
3- Rename all/some incoming layers.

This is akin to deleting a layer in SU.  That would solve the problem.


On Aug 24, 2:47 am, tacarr <> wrote:
Re: Nested Layers Gaieus 8/24/09 5:49 AM
I second this one!

Re: Nested Layers tacarr 8/24/09 6:23 AM
Regarding jgb suggestions to transfer everything to layer 0 when
importing does not really satisfy the requirement.
Sometimes it may be preferable to keep the layer structure of the
imported model/component so by it being brought in
on, say, a preselected 'master' layer and retaining its own unique sub
layering could be advantageous.

Using this systen within the master model would also fall inline with
jgb's layering convention e.g. 4.00 Wing
would be seen in the listing whereas all sub layers would be
unexpanded. This could be carried down to lower levels
to further enhance the hierarchical discipline of the model.
Re: Nested Layers bob 8/24/09 12:28 PM
This seems a fair suggestion. Storing sub layers in a folder would
make the layer window more readable. Mysearch has a point too, by also
mentioning Components, Outliner, and (last but not least) materials.

It all seems to evolve around keeping all those things together and
under control. All the options in Sketchup asure lots is possible, but
that you also need to be very carefull.

Materials - when you have very carefully brought the number of
materials under control, it can be distressing to import a single
Warehouse component.
Outliner - you can not see your component hyrarchy separate of your
layer organisation, when you want to USE BOTH.
Component Window - should have a search function
Layer Window - lacks any functionality

It has been suggested, there should be a Window that more or less
combines both Outliner and the Layer Window. I think there is much to
say for that.
Re: Nested Layers tacarr 8/24/09 11:22 PM
A posting from msp in 'SketchUp Pro>Groups and Layers' describes the
problem of reassigning
a nested group to a new layer. This requirement could also be
incorporated within
the suggested 'Nested Layers Feature'
Re: Nested Layers mysearch 8/25/09 4:26 AM
I would have thought that the SU developers already have a blueprint
for nested layers, nested components and nested material that is
readily understood by all its users, i.e. outliner aka nested groups.
If you change the terminology of the anchor point from groups to
folder you have the universally understood concept of nested files/
objects of any description.

If so, allow users to created, rename and delete recursive anchor-
points, i.e. folders, in all 4 of the key management interfaces within
SU, i.e. outliner, layers, components and materials. This way you give
the flexibility back to the user to organise their models within any
hierarchical structure they wish. It also extends the consistency of
operation in-line with outliner to all management interfaces.

With regard to the idea forward by jgb and commented on by tacarr,
importing a component with all the potential implications on the
organisation of layers, components and materials, these could all go
into a default ‘folder’ within the respective interfaces without the
complexity of N options. From my experience it seems essential that
any reasonably sized model would have already organised their model
out of the default folders. After importing the component, the user
could then simply create an appropriate folder within each category,
i.e. layers, components and materials, that meets their needs.

N.B. The model report would also be a nice feature listing all named
> > > > > > removing the confusion of an 'unruly' layer listing.- Hide quoted text -
> - Show quoted text -
Re: Nested Layers jgb 8/25/09 5:03 AM
The issue of "folders" as part of a nested layer solution is nice, but
a complex (however desirable) undertaking.
It does seem to meld the Layout presentation of groups/comps with the
current simple layers list.  I have not used layout much at all, so I
can't really comment further on it.

There is a Ruby called "Layer Management" which almost does the
"folder" thing by allowing named groups of selected layers to be made
visible/invisible.  I use it but it would be more useful if it were
made part of layers, rather than having to call it up each time to use

The simple short term solution is akin to my suggestion.

tacarr said...
"Regarding jgb suggestions to transfer everything to layer 0 when
importing does not really satisfy the requirement.
Sometimes it may be preferable to keep the layer structure of the
imported model/component so by it being brought in
on, say, a preselected 'master' layer and retaining its own unique sub
layering could be advantageous."

I beg to differ.  Reassigning all to layer0 is only #2 of the 3
options.  Option #1, import layers "as is" does satisfy your
requirement.  And option #3 allows you to rename any 1, some or all
incoming layers, in any fashion you chose, before it merges and messes
with the existing layers.

Adding a materials "list by component/layer" would be too much to ask
for at this time.  There are far more important issues to solve for
the SU development gurus to spend their time on.  Near field clipping,
open gap polygons, on face but non-planar, hyper-zoom, are just a few
of the critical ones that have remained problems for way too long.

> > - Show quoted text -- Hide quoted text -
Re: Nested Layers mysearch 8/25/09 5:55 AM
The SU team must have already developed some sort of linked-list code
in support of Outliner. On the assumption that this code is of a
modular design, I would see no reason why it couldn’t be re-applied to
the other 3 major interfaces, albeit with some modification. If so,
the biggest effort might be testing and I would have thought that some
portion of the SU user based would willingly share some of this load
via alpha/beta test releases.

I will take a look at the ruby script indicated, but you do not seem
to describe it as a solution, more of a partial work-round. Equally,
you only describe your own proposal as short-term solution, which
presumably doesn’t address the impact on the existing organisation of
components and materials. While there may well be many issues on the
SU wish list, I would have thought that the overall management of SU
models, inclusive the ability to efficiently share components would be
of the highest importance as it seems to underpin the whole ethos of a
modelling community.

However, I recognise that it may appear that I am now on some sort of
Don Quixote crusade and it is possibly time for me to get back to
work. Still it would be nice to see some acceptance of the bigger
problem space and some strategic roadmap as to when it might be