Hide semantics
-
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