Entity.visible? vs entity.hidden?
-
Does anyone know it there is a difference between using
if (entity.hidden?)
or
if (!entity.visible?)
That is: Do they refer to the same thing, or does visible refer to other things (such as in an invisible layer, off screen, or something else I am not thinking of)?
-
Did a quick test:
e.visible?
reports true whene.hidden?
reports false. Looks like a bug. Ife
is on an invisible layer I'd likee.visible?
to reportfalse
, no? -
They are the opposite of the same thing. Think it's just so you can use whatever version reads the best in the given situation.
And it refer to the Hidden property which you see in the Entity Info window.To check if a entity is truly hidden or visible you need to check
entity.hidden? || entity.layer.hidden?
or
entity.visible? && entity.layer.visible?
-
@martinrinehart said:
Did a quick test:
e.visible?
reports true whene.hidden?
reports false. Looks like a bug. Ife
is on an invisible layer I'd likee.visible?
to reportfalse
, no?I wrote this routine to determine if an entity is truly visible.
It gets tricky because an entity in a nested group/component is invisible of any of the layers of the parents is off, (except for Layer0 which is always on in a component or group even if it is off at the top level).
In included both entity.hidden? and !entity.visible? - which is probably redundant.
def is_enitity_visible_in_sketchup(entity) #printf("is_enitity_visible_in_sketchup; %s\n", entity.layer.name) return false if entity.hidden? return false if !entity.visible? # Layer0 is only invisible at the top level if (entity.parent.class == Sketchup;;Model) return false if !entity.layer.visible? else if (entity.layer.name != "Layer0") return false if !entity.layer.visible? end#if #make sure each parent is visible parent = entity.parent while (parent.class != Sketchup;;Model) return false if parent.layer.name != "Layer0" && !parent.layer.visible? parent = parent.parent end#while loop end#if #printf("is_enitity_visible_in_sketchup; %s return true\n", entity.layer.name) return true end#def
-
entity.parent will return the definition or model where the entity is contained. It will never return the component instance or group instance.
-
@thomthom said:
entity.parent will return the definition or model where the entity is contained. It will never return the component instance or group instance.
You are right.
In our routines where we actually try to determine whether an entity is visible or not, we are drilling down into components and groups, and we keep a list of layer names as we drill down.
I have never really started with a specific entity in a nested set of groups and components and tried to drill up before.
Is there an easy way to find out what the containing instance is when you have an entity in a component instance of group? If not, then I will have to be careful to always keep track of layers and visibility as I drill down into the model.
-
I think this is one major issue with the SU structure and APIs. There's no way to backtrace. I think you would actually have to build a full tree list of the entities to be able to traverse backwards like this.
-
@thomthom said:
I think this is one major issue with the SU structure and APIs. There's no way to backtrace. I think you would actually have to build a full tree list of the entities to be able to traverse backwards like this.
OK - thanks thomthom.
Everyone else - forget most of this thread - except the original question"
@unknownuser said:
is entity.hidden? the same as !entity.visible (notice the ! sign)
And therefore should I save time and keystrokes by only using one of them?
I believe they both refer the the hidden state, and have nothing to do with layer visibility.
-
I understood that [probably wrongly]...
An object ishidden
if its set to be 'hidden' - i.e. not to be seen.
An object isvisible
if it is on layer that's switched 'on'... ? -
@al hart said:
I believe they both refer the the hidden state, and have nothing to do with layer visibility.
http://forums.sketchucation.com/viewtopic.php?f=180&t=23806#p202821
-
You are right [as thomthom said]
entity.hidden?
is the same as!entity.visible
You can also toggleentity.hidden=true/false
andentity.visible=false/true
-
@al hart said:
both refer the the hidden state, and have nothing to do with layer visibility.
Any reason not to declare
visible?
a bug? -
@martinrinehart said:
@al hart said:
both refer the the hidden state, and have nothing to do with layer visibility.
Any reason not to declare
visible?
a bug?I think the reply you would get is "By design".
From the manual on
Drawingelement.visible=
:@unknownuser said:
This method performs an opposite function to the hidden= method.
http://code.google.com/apis/sketchup/docs/ourdoc/drawingelement.html#visible=
I think a feature request for a different method that will return to whether the entity can be seen in the model or not is what we'd need to make.
Drawingelement.seen?
maybe? And more importantly, a method that will let us dig down backwards in the hierarchy of the entity tree. -
@martinrinehart said:
Any reason not to declare
visible?
a bug?Yeah, because maybe its actually hidden? that's a bug
Ruby likes to have duplicate methods for the same process. Seems like many methods are available in the positive and negative form.
Chris
-
@chris fullmer said:
Ruby likes to have duplicate methods for the same process. Seems like many methods are available in the positive and negative form.
Except that hidden and visible are real attributes of objects, and should not have been used as aliases. Using visible as an alias for not hidden is crap. Leave the sugar out of the API.
-
@thomthom said:
@martinrinehart said:
Any reason not to declare
visible?
a bug?At this point, if they some changed what it meant, it would break any scripts which were using it to mean "not hidden".
However, it would be nice if they added 1 to 3 of these new functions:
entity.is_visible? - not hidden, and not on a layer which is hidden (including groups and sub-components which are hidden or on layers which are hidden)
entity.is_in_current_view - is_visible? and also is visible in current camera view
entity.is_obstructed - is visible? but is behind something else which is not transparent.The last two are pie-in-the-sky, but the first one would be a useful function.
However, as I write this I see that part of the problem is what is meant by an entity. As I drill down through the database and think I am pointed at a single, unqiue entity, I am often pointed to an entity in a component definition, which, if the component is used more than once may be in hidden instances of the same component, instances of the component which are on layers which are off, as well as in an instance which is visible.
What is needed here is a entity identifier which include the "path" to get to the entity, so it truly represents a single unique entity in terms of the display.
-
@al hart said:
entity.is_in_current_view - is_visible? and also is visible in current camera view
entity.is_obstructed - is visible? but is behind something else which is not transparent.I think I would like at least these two to be part of the view object, and pass in an entity, not on the entity itself.
-
It seems visible? and !hidden? are not the same...
I've attached model. visible?==!hidden? for all entities except the deepest one.
Here is log from my Ruby window:m=Sketchup.active_model #<Sketchup::Model:0xb2ce678> m.entities[0].definition.entities[0].definition.visible? true m.entities[0].definition.entities[0].definition.hidden? true
and from my observation visible? is closer to the truth
-
You are testing the definition - definitions are not placed in the model and therefore can't be visible or hidden. ComponentInstances are what you need to test against.
-
@thomthom said:
You are testing the definition - definitions are not placed in the model and therefore can't be visible or hidden. ComponentInstances are what you need to test against.
Thanks for this remark, I'll adjust my code.
Since ComponentDefinition is inherited from Drawingelement, calling visible? and hidden? seems not to be some incorrect operation leading to undefined behaviour. Yes, they may not represent actual state of geometry, but this shows that visible? is not the same as !hidden? at least at implementation level, and thus can it be safely assumed that they are the same in all other cases?
Advertisement