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?
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.
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” ?
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.
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
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.
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.