Page 1 of 1

SceneNode::getVisibility() / ::isVisible()

Posted: Tue Oct 25, 2011 4:55 pm
by Beauty
For SceneNodes it's possible to set its visibility or to flip its state.

* SceneNode::setVisible (bool visible, bool cascade=true)
* SceneNode::flipVisibility (bool cascade=true)

On the other hand there seems to be no possibility to read the visibility state.
I think it could be usable to add a function to read the visibility flag of a SceneNode.

The ManualObject class still contains such functions:
* ManualObject::getVisible() - Gets this object whether to be visible or not, if it has a renderable component.
* ManualObject::isVisible() - Returns whether or not this object is supposed to be visible or not.

If you think my suggestion is usable, then it would be fine when you add it to Ogre before official release of 1.8.

Re: SceneNode::getVisibility() / ::isVisible()

Posted: Tue Oct 25, 2011 4:59 pm
by CABAListic
This is a shortcut to calling setVisible() on the objects attached to this node, and optionally to all objects attached to child nodes.
SceneNodes don't actually have any information about visibility, they just forward that call to the attached objects. As such, it's problematic to define a getter for visibility on a SceneNode.

Re: SceneNode::getVisibility() / ::isVisible()

Posted: Tue Oct 25, 2011 6:05 pm
by Klaim
Maybe this function should be named in another way... like setObjectsVisibility() ?

And then you can add a recursive function to check if : bool hasVisibleObjects() ?
If the hierarchy is not insanely deep it should be fast, don't you think?

Re: SceneNode::getVisibility() / ::isVisible()

Posted: Tue Oct 25, 2011 10:38 pm
by Beauty
Thanks CABAListic, now I understand the sense, why there is no getVisibility() function.

I don't know where you did copy your quote, but it would be usable to add it to the official Ogre API description of SceneNode::setVisible().

Its current description is:
setVisible (bool visible, bool cascade=true)
-----> Makes all objects attached to this node become visible / invisible.
I suggest to extend the description and use this:
Makes all objects attached to this node become visible / invisible. It's a shortcut to calling setVisible() on the objects attached to this node, and optionally to all objects attached to child nodes.
If you agree to my suggestion:
Would you like to update the source code, please?

Re: SceneNode::getVisibility() / ::isVisible()

Posted: Tue Oct 25, 2011 11:48 pm
by CABAListic
? I took the quote from the API documentation, so... ;)

http://www.ogre3d.org/docs/api/html/cla ... 28d7c8195e

Re: SceneNode::getVisibility() / ::isVisible()

Posted: Wed Oct 26, 2011 11:05 am
by Beauty
Oh, now I see my own mistake.
I just read the description in the "overview" at the top of the page (instead of the "Detailed Description" section). :lol:

Re: SceneNode::getVisibility() / ::isVisible()

Posted: Tue Jan 07, 2014 6:13 pm
by def87
Sorry to revive an old post but I have the same problem...

Why is there still not getVisible() function for SceneNodes?
There IS a flipVisibility() function which internally must do a get/setVisible() to attached objects.

Re: SceneNode::getVisibility() / ::isVisible()

Posted: Tue Jan 07, 2014 6:19 pm
by c6burns
Because, as explained above, SceneNodes aren't renderable ... it's the attached objects that are. Also I think just no one ever submitted a patch for this. You could be the one :)

EDIT: Nevermind I was wrong, the setVisible method made it into SceneNode. There's just no getVisible/isVisible but it would be trivial to do and submit a PR

Re: SceneNode::getVisibility() / ::isVisible()

Posted: Wed Jan 08, 2014 7:10 am
by Kojack
Similar reason to why there's no getMaterialName on Entities or Meshes, because multiple child objects contain that data, not the one parent object.
If a scene node contains one attached object that's visible and another attached object that's invisible, what should getVisible() return?

Re: SceneNode::getVisibility() / ::isVisible()

Posted: Wed Jan 08, 2014 8:48 am
by c6burns
I assumed they want it to return true if any renderables are visible, but I don't rightly understand the use case of any of this myself. I keep hold of the pointers to my renderable stuff and control their visibility like that, which I assume everyone else does as well. While I don't see the harm in a patch, I don't see the use in it either.

Re: SceneNode::getVisibility() / ::isVisible()

Posted: Wed Jan 08, 2014 11:04 am
by def87
Ok, thanks to you guys I have to agree SceneNode::isVisible() makes no sense.

In my use-case there is only one renderable Object attached per node, so I will build my own utility function, something like:

Code: Select all

bool SceneNode::FirstAttachedObjectIsVisible( Ogre::String objecttype )

Re: SceneNode::getVisibility() / ::isVisible()

Posted: Wed Jan 08, 2014 2:24 pm
by Klaim
Instead of providing these functions in the scene node types, we should just provide algorithms to go through all the graphic objects attached to a node and it's childs and apply a provided callable on them. Provide depth and breadth variants of this algorithm.

That way it is easy to do almost anything with all the objects attached to a node and it's child node's attached objects without having to add functions to the node types each time we need a new function in the entities types.

Of course it's far easier to use if you can use a compiler providing lambdas, but at least you can do it with bind() or mem_fun() if you use a too old compiler.

I don't have enough time to do so but I could try something in the weekend if you don't already see how to do it.

Re: SceneNode::getVisibility() / ::isVisible()

Posted: Thu Mar 06, 2014 11:09 am
by simedj
Kojack wrote:Similar reason to why there's no getMaterialName on Entities or Meshes, because multiple child objects contain that data, not the one parent object.
If a scene node contains one attached object that's visible and another attached object that's invisible, what should getVisible() return?
sceneNode::hasAnyVisible() could be an option. I'm sure many of us have our own utilities with such things.