Hide semantics
-
Just got bitten by this behavior which for my money is just wrong.
ComponentInstance A contains 1 child ComponentInstance B
A.visible? => true
B.visible? => trueall fine so far, but if I hide A, you can't see A or any of its children.
A.visible? => false
B.visible? => true (Not a very useful answer..) -
@adamb said:
Just got bitten by this behavior which for my money is just wrong.
Read it as B is visible to A perhaps?
-
TIG, that only checks for the first instance in the definition - that might be the wrong instance. One instance could be hidden, one could be visible.
-
@tig said:
B is visible inside A, but A is hidden so you can't see that !
Exactly. The original assertion was that it was plain wrong, but I think semantically it must be correct; whether it is inconvenient is another matter.
-
Al Hart had a similar thread on this topic http://forums.sketchucation.com/viewtopic.php?f=180&t=23806
.visible?is the inverse of.hidden?and refer to the Hidden property ofDrawingelements.Doesn't take into account layer visibility or parent visibility.
Accounting for layers is easy:
entity.hidden? || entity.layer.hidden?
or
entity.visible? && entity.layer.visible?But we're stuck when it comes to parent visibility.
Unless the entity in question is part of the current context. Then you can use model.active_path to trace back visibility. But if it's a random entity in the model - then we're kindof screwed I think. It's a severe flaw in the ruby API entity hierarchy. -
Except that there are often groups that are not unique.
I know it's not what you should do with groups, but I see them non the less all too often here at the office. Hence why I made the script to convert them to components. -
@thomthom said:
TIG, that only checks for the first instance in the definition - that might be the wrong instance. One instance could be hidden, one could be visible.
This works fine for Groups [when they are used properly - i.e. they are 'unique'].
Since you cannot select an Entity inside an Instance but only refer to it inside theinstance.definition.entities, then testing for it's visibility this way is pointless as there could be dozens of instances so hidden and some not - as you say...
I will modify the code to only look at parents that are Groups...
If it's in a Definition then it will return false if it's hidden in that definition but ignore any Instances' visibility... -
B is visible inside A, but A is hidden so you can't see that !
You need to test for nesting...
EDIT: update to ignore all but entity's visibility when it's inside a definition.def is_visible?(entity) model=Sketchup.active_model visible=entity.visible? return false if not visible parent=entity.parent while parent != model if parent.group? and parent.instances[0] visible=parent.instances[0].visible? break if not visible end#if parent=parent.instances[0].parent break if parent==model or not parent.group? end#while return visible end#def -
@chrisglasier said:
@tig said:
B is visible inside A, but A is hidden so you can't see that !
Exactly. The original assertion was that it was plain wrong, but I think semantically it must be correct; whether it is inconvenient is another matter.
But thats my point. The meaning of the words "is visible" means to most people - "is this thing visible" and not "what is the value of some boolean inside the implementation".
Reminds me of asking a programmer "Have you got the time?" and he says "yes". Not useful.
-
@adamb said:
@chrisglasier said:
@tig said:
B is visible inside A, but A is hidden so you can't see that !
Exactly. The original assertion was that it was plain wrong, but I think semantically it must be correct; whether it is inconvenient is another matter.
But thats my point. The meaning of the words "is visible" means to most people - "is this thing visible" and not "what is the value of some boolean inside the implementation".
Reminds me of asking a programmer "Have you got the time?" and he says "yes". Not useful.
Most people don't go ferreting around Ruby code; those that do should respect what ignoramus' like me respect as necessary pedantic semantics; that's all I was trying to put forward.
Pinky
-
To be pedantic you ask a question that doesn't have an answer... at least without 'qualification'...
Is A visible ? Well any Entity -A- can either be visible or be not_visible in its own right.
When A is in the Model that question is OK, since its context is the Model's Entities.
When A is inside a Group or a Definition the question is also OK - provided that it has the unspoken qualification that also applies to the Model - "Is A visible, in its context ?" - of the Group/Definition's Entities...
You cannot ask if A is visible when its 'in' an Instance - it is only ever 'in' a Definition. A Definition is really just like a sub-model that has Entities etc just like the main enclosing Model - the state [hidden et al] of an Entity within it is relative to those Entities NOT the main Model.
You can ask if a particular Instance is visible [it is after all an Entity in its own right!], but then getting the answer tells you nothing about the state of that Instance's Definition's Entities - some of which could well be hidden too ! -
Oh, all I was suggesting is if my reading lamp is on but my black out curtains are drawn, those outside have no idea whether my lamp is on or off. So I think the more interesting question is when to know whether the lamp is on or off. And why?
-
You can ask that very question, is the lamp on/off ? - but it is only useful in the context of the room.
Having drawn the blinds makes the lamp's on/off state irrelevant to those who are outside, but it remains relevant to those still in the room ?
-
@tig said:
You can ask that very question, is the lamp on/off ? - but it is only useful in the context of the room.
Having drawn the blinds makes the lamp's on/off state irrelevant to those who are outside, but it remains relevant to those still in the room ?Exactly ... so the question remains why those outside need to know ... particularly AdamB.
-
The huge missing method in SU, is being able to walk up hierarchy.
Why I want to know, is I have a particular Component. I want to find all instances of that Component that are visible? Its essentially not possible without incredibly slow processing in SU.
-
visible_components=[] definition.instances.each{|instance|visible_components<<if instance.visible?} ### visible_components is an array of all of that definition's instances that are visible ??????
-
Err, we're going around in circles here.
That snippet gives you all those instances that have visible?==true which is of zero use, since if the instance is inside something that is hidden, it too will be hidden.
The only way is to enumerate all instances then track back through the parts hierarchy for every instance - something the Ruby API cannot do.
But thanks for trying!
-
@adamb said:
Err, we're going around in circles here.
That snippet gives you all those instances that have visible?==true which is of zero use, since if the instance is inside something that is hidden, it too will be hidden.
The only way is to enumerate all instances then track back through the parts hierarchy for every instance - something the Ruby API cannot do.
But thanks for trying!
You can only establish the visibility of Entities.
An Entity can be raw Geometry etc, Groups and Instances.
That is what my snippet does.
You can work out if an Entity within a Definition is visible [that will be the same in all Instances of the Definition], BUT as you said... you can't tell if a particular Instance of that Definition containing that Entity is itself visible. There is no connection between the Definition's Instance's visibility, except insofar that the Instance is of the Definition ! It's the same Entity that's within the Definition in every Instance of it !
Instances of a Definition are simply 'markers' that refer back to that Definition: these 'markers' are Entities that can have their visibility set... There are no 'parts' in an Instance. These 'parts' [Entities] exist only in the Definition that the Instance is 'marking'... -
@adamb said:
The only way is to enumerate all instances then track back through the parts hierarchy for every instance - something the Ruby API cannot do.
I just think this strengthens the case for identifying components in a web dialog - use callbacks to hide them individually or in groups, set up inheritance rules, almost anything really. Also use their ids + attributes for import, material count, Internet communication (including search). And get free from the restrictions of Sketchup's layer/outliner system.
-
Having slept on this...
An Entity that is part of a Definition's Entities is a single 'thing'.
Instances of this Definition can be 'placed' within the Entities of a Model or even those of other Definition.
Instances are themselves 'Entities'...
These Instances are simply 'markers' and refer to the Definition - they have no 'contents' of their own.
Any properties that this Entity has [like visibility, material, layer etc] are set within the Definition's Entities and cannot be changed on an Instance by Instance basis as they don't exist.
Any Instance of the Definition containing this Entity can have individual properties [like visibility, material, layer etc] - some of these might even get reflected down the nesting - like 'material' which when changed on the Instance will affect the appearance of any contained Entities which have their material=nil, however the 'visible' property does not filter down.
Visible/hidden Entities within a Definition [that is seen as an Instance] remain visible/hidden independent of each Instance's 'visible' state - however, if the container Instance is 'hidden' then you cannot see it, and by logic you cannot see its contents - irrespective of whether or not they are visible/hidden within the Definition itself.
This is a logical setup.Let's say you have Entity called A [an Entity is unique, but of course it might itself be just one Instance of a Definition].
'A' is within a Definition and there are 6 Instances of this Definition within an Entities set.
2 of these Instances are visible the other 4 are not.
Thus you can only 'see' 2 representations of A.
However, there are 6 representations of A 'available' in the scheme of things - so, how do you get the number of visible A's ?
Remember you can't refer to a particular A in a particular Instance because there is only one A and that's inside the Definition.
If you mined down into the contents of every Definition in the Model to find A you will eventually get just one parent Definition returned because every Entity is unique - however, if A were an Instance then finding its Definition and then that Definition's Instances would give us a list of all Instances equivalent to A - however, they are NOT A itself, but a list of Instances of A's Definition - we can't confuse Entity-A and Definition-of-Instance-A - this would just make it more complicated to find them all, but it's not impossible.
For now let's assume we have a simple Entity A, and we have its parent Definition, we can now find a list of all of that Definition's Instances, and then from this list we can get lists of all of those Instances that are visible/hidden.
Thus we can say that Entity A exists 6 times in the Entities set, that it is visible 2 time and that it is hidden 4 time, simply by looking at the lists we just made of the parent Definition's Instances visibility.
Since we know which are the Instances displaying A we can find each of their locations and thus the location of the 'ghost' of A within them, since we know where A is inside the Instance's Definition...
However, if Entity A were hidden in its Definition then it would be always hidden in every Instance we looked at, so in that case, irrespective of the containing Definition's Instance visibility, A is 'hidden' in all 6 cases even when its container is visible...Not sure much of this is of any practical use...
Advertisement