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 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.
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.
Thatsâ fine as long as we can have geometric sections we can keep drafting in (which, I think youâre also not against.)
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âŚ
john
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.
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?
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.