Newest version -- any way to hide all but parent?

In the older versions of Sketchup, I can hide or show the rest of the model, and I can hide similar components. When a model gets more complex though I would have liked to be able to hide everything but, for example, the parent and its descendants, or everything but the grandparent and its descendants.

Does the newest version of Sketchup have anything like this?

1 Like

I don’t think so. But it’s a interesting idea for a feature.

I cannot think of a Ruby plugin workaround.
API-wise, hiding an ancestor or it’s layer would also hide the current edit context because it is a descendant.

I’d love this to be possible.

What if, @DanRathbun , all the ancestors geometry would be put on a temp layer, all but current component/group parent’s geometry?

Using temporary layers is a really dirty work around. What is needed is a way to plug in to the rendering pipeline and change only how things are drawn without altering the physical model.

1 Like

All I can think of, is what I can understand as a user.

Controlling rendering pipeline for context display is probably not available even for you plugin gurus, or is it?

It is not but I hope it can be some day. Then we could have things like solid section cuts (Skalp) without modifying the physical model with new entities or affect the undo stack.

1 Like

Thats’ fine as long as we can have geometric sections we can keep drafting in (which, I think you’re also not against.)

1 Like

Powerful and useful as it might be, I fear that any mechanism to fiddle with the render pipeline would require a lot of expertise from the programmer to avoid totally messing up SketchUp.

Users could chose not to use a plugin if it does weird things to SketchUp. That’s the beauty of plugins.

You miss my point: it could require a high level of expertise for the programmer to get the plugin to work at all!

I still don’t get what you mean. How hard it would be to use as a developer mostly depends on how logical and sensible the API is designed to be and how well documented it is. Some parts of SU are extremely hard to work with because it’s so inconsistent and illogical even if the concept is incredible simple (e.g. coordinates). How complex something appears at first sight usually doesn’t matter that much.

That’s essentially what I mean. I think it would take a tremendous amount of effort on the Trimble team’s part to design and implement an API that provides direct access to the OpenGL rendering pipeline without a) exposing OpenGL programming concepts and requiring the programmer to understand them in detail, b) affecting SketchUp’s performance, and c) opening up a lot of opportunities to crash SketchUp.

currently, the SU team can’t even support AA on a mac with the new render engine…

I find it highly unlikely they would be keen to add API access to theirs or it’s source code…

to date the only way for an extension is to tap into the openGL stream and re-present it in a modified ‘masking’ viewport or in a separate window…

IMHO adding Layers or geometry has far less overhead and can always be saved out into a separate file if needed…


SketchUp does not have geometric layers. (I told you this before.) Besides it is not just the ancestor’s geometry, it is the ENTIRE rest of the model except for active context and parent. (You cannot use the “Hide rest of model” feature AND use a heavy-handed hierarchical hide plugin at the same time, as the built-in feature will override and hide the parent context as well.)

The changing the layer pointer property is MUCH more work than toggling the visibility property, because you have to create a hierarchical hash to remember every object’s layer property value. (so their layer pointers can be restored.) This means dynamically building a tree structured hash that mirrors the ENTIRE model object tree.

So, toggling the visibility property off is a much better proposition.

However, we are also talking about nested entities collections, which means definitions. Hiding the entities of a definition, hides them in ALL instances in the model. If there is more than one instance of the “parent”, you will not be able hide any of them via the API, leading to confusion.

I agree with Julia here display helpers should not modify the model. Doing so has ramifications with AutoSave and backup files, the undo stack etc.

Ya’all need to remember here that the end user will have multiple nested editing contexts open, so wrapping property changes in an undo operation and aborting is out of the question, for a workaround implementation.

This would need to be a native feature implemented on the C/C++ side in the render pipeline.

So, we are back to the original feature request

(1) How would the Model Info > Components panel need to change to make such a feature usable without being confusing ?

(2) Would some type of keyboard shortcut be wanted to toggle grandparent and parent visibility “on the fly” ?

1 Like

As we were talking about visibility… well I guess I’ll never fully follow everything about the inner workings of sketchup.

Model Info > Hide Show Component and Parent

We need a shortcut, but Hide Rest of Model shortcut doesn’t exist, we have to assign it, so we could assign to the new command too.

When I asked for this before, we talked about a breadcrumb menu. Something that would pop up at the top of the model and would allow us to hide seveal parent and children hierarchy levels.

That would be even more complex but would be nice to have. And it would probably work if Sketchup would remember last used settings. Example: Show only 2 parent levels and no child levels, besides current context.

There is a very useful plugin (from @TIG I think) that hides current context’s components… There could be one that only shows components too.

So, what I’m trying to say is that Hide rest of Model and Hide Similar Components could be deeply expanded to a lot of useful scenarios.

1 Like

The settings of the levels in Generate Report are now used for creating a report but such a setting could also be used for display of the model? In others words, let the user decide which levels they want to work in for the model. This could perhaps tackle problems when working in large models

1 Like

Why shouldn’t it expose OpenGL’s programmin concept? The parts of the API that are really difficult to work with are those that try to dumb things down in absurdity, e.g. how different coordinate systems are being used depending on if an entity is in the active entities collection, a parent to active the active entities, or in another entities collection, instead of just using the actual underlying values. Being honest and expose the underlying logic makes the concepts easier to understand and, in this case, existing documentation and tutorials for OpenGL could be used instead of everything having to be rewritten from scratch.

Of course it would affect performance more or less. The same is true for the existing API as well. The same applies to crashing SketchUp.

1 Like

What also happens with some cases of Sketchup usability. Thinking before users with the sole objective of looking simple, while being incoherent and thus hard to understand at a deeper level.

Take pushpull; Draw a shape and push pull it to a solid right? Wrong! Wrong in so many ways actually that it’s unbelievably wrong. Yet, for the first time user, it looks a simple solid…

It goes on my thesis around sketchup. Is it simple or does it look simple?

1 Like

I suspect that all the API is doing is exposing how the C side is working or must work.

True, these exceptions in how coordinates are handled may very well be coded in C and be the base of how the tools function long before the Ruby API was created. However it might also be created specifically for the API to “simplify” for plugin developers.