I would like to make 2 changes to the RenderManager.renderScene method. The first would be either adding a null check at the start of the method - e.g.
[java] public void renderScene(Spatial scene, ViewPort vp) {
// If scene is null - stop rendering that branch of the scenegraph.
// This allows you to switch nodes on and off at will by overloading node.getChild and returning null.
if( scene==null )
return;
scene.runControlRender(this, vp);
…
[/java]
or alternatively moving the
[java] scene.runControlRender(this, vp);
[/java] line and duplicating it in each of the if instanceof blocks - thus avoiding the null check as instanceof handles that. Performance wise its a coin toss between a potentially unnecessary null check and 2 instanceofs - as so far I’m the only one wanting this - I guess this would actually be the prefered method - the other just makes it clearer that there should be no code before the first if statement.
The second would be changing the Node handling code from
[java] if (scene instanceof Node){
// recurse for all children
Node n = (Node) scene;
List<Spatial> children = n.getChildren();
for (int i = 0; i < children.size(); i++){
renderScene(children.get(i), vp);
}
[/java]
to
[java] if (scene instanceof Node){
// recurse for all children
Node n = (Node) scene;
int size = n.getChildren().size();
for( int i=0; i<size; i++ ){
renderScene(n.getChild(i), vp);
}
[/java]The reason for doing this is to allow a subclass of spatial to overload the getChild method to say if it should be rendered or not by returning null, and in doing so exclude whole branches of the scene graph.
You do rendering/not rendering via the cullhint, I dont think we need this hack 
Edit: Not processing parts of the scenegraph at all can be handled easily with attaching/detaching, its not a resource hungry process in jME3.
This is my first dabbling converting some of my JME2 stuff to JME3 - so forgive my ignorance, but as far as I can tell, the culling is only on geometry not on nodes?
Basically I’ve finally got some holiday time and am porting my BSP handling code (based heavily on the one by Renanse) - that made use of a BitswitchNode to dynamically switch nodes on and off based on a visibility set. This seems a really elegant idea to me as its all neatly enclosed in a single class - and all you have to change is a BitSet to turn stuff on and off.
Admittedly this is a single Node controling a lot of Geometrys - so I guess if rebuilding the graph is what I have to do then so be it. This just felt cleaner to me.
I guess I shall experiment further…
Thanks for the help tho 
Yes, as I said, you can simply detach a node if you dont want it to be processed at all. But a vanilla “Node” has nothing to process, so there is no use in ignoring it somehow, the updateGeometricState() and updateLogicState() calls are really not something to worry about. If you have your own Nodes that actually do something, you can either add your own switch for that processing or do the detach solution. Since only geometries can put any “strain” to the application and in fact we are talking about “rendering”, which is only applicable for Geometries, culling should be pretty much doing it for you.
Also, I dont exactly know if this “Node overriding business” should be taken to extremes. To manipulate Spatials there are “Controls” for example, these allow capsuling the modifying code a bit cleaner. Especially when overriding the basic methods of Spatial and Node one’s prone to mess up stuff pretty fast.
Well I have taken what you said on board, and am working on a different solution - I was just trying to keep my code changes to a minimum (selfish I know :D) but also felt this was a worthy request. Yes, a vanilla node has nothing to process, but it can potentially be a parent to a million other things that do - hence the early out is usually a preferable option and I just thought putting that as low as possible as simply as possible is usually the best solution.
My new approach will still be extending a node tho, but overloading the getChildren method and generating a new arraylist on the fly to pass back - bit more wasteful on memory/gc every frame, but I’ll worry about that later as I’ve not got anything actually running yet
Now you have mentioned it, yes I see an arraylist called “controls”, and looked at the surrounding code and the Control object - but not a single comment to say what it is there for and how it might be used tho.
It does feel more and more that using JME3 you have to log about a problem to find a solution that should maybe have been more obvious from the start? Kinda takes me back to my 8 bit days when the internet was but a dream!!!
Ahhh happy days (thru rose tinted glasses !!)
You really shouldnt hack the scenegraph this way… Just do it via attaching and detaching. You will mess things up when you return different lists etc. (recursive update will fail and more) Just have a node that attaches one or the other child to itself depending on whats happening.
About the controls, if you just look at the jME3 API, all this kinda stuff is done in the form of controllers, cant think of a better hint at that fact 