电子书上给了个例子，抄一抄，加深下印象，也验证下以前的想法对不对
对于场景实例
其中"ss"加上数字代号来标识这些Stateset对象，后面括号中的两个参数分别表示setRenderBinDetails的两个设置项("-"表示空字串，"R"表示"RenderBin","D"表示"DepthSortedBin"
即
ss03->setRenderBinDetails(0,""); //缺省设置
ss11->setRenderBinDetails(0,"");
ss13->setRenderBinDetails(-1,"RenderBin");
ss14->setRenderBinDetails(1,"RenderBin");
ss15->setRenderBinDetails(10,"DepthSortedBin");
ss16->setRenderBinDetails(10,"DepthSortedBin");
关于状态集，对于叶节点_geode3,以及所有六个几何对象均设置了关联的渲染状态集(StateSet),且几何体1，2共用一个stateset。osg中所有的Drawable几何体对象都会自动关联一个StateSet对象，无论用户是否在陈鼓中设置。
进入渲染后台后，OSG将为这个场景生成“状态树",它是由”状态节点“StateGraph和渲染叶RenderLeaft组成。
上图的状态根节点和局部状态节点都是由状态树自动生成的。其中后者的主要工作是保存和维护一些渲染后台自动创建的渲染属性；而全局状态节点则保存了一个名为_globalStateset的全局渲染状态集对象，它的取值是场景主摄像机的StateSet.。换句话说，任何对状态树的遍历都将首先及至场景主摄像机的渲染状态，然后才是各个节点的渲染状态，这就是_globalStateSet的功用所在。
状态树的构建规则
1，状态树是根据渲染状态stateset来生成的，那些没有设置Stateset的场景节点不影响状态树的架构
2，场景中的Drawable对象在状态树中被置入分别的渲染叶(RenderLeaf)中，而一个或多个渲染叶必然被一个状态树末端的节点StateGraph拥有。
3，共享同一个渲染状态的Drawable对象（图中的_drawable1和_drawable2)在状态树中将置入同一个末端节点。
可见，我上节中考虑的是错误的，以为和场景图架构相同，其实毫不相干。
生成状态树的同时，OSG渲染后台还将生成对应的渲染树，其组成为一个RenderStage和多个RenderBin,如果都是默认状态(渲染顺序0），则所有状态树的末端节点（其中必然包括一个或多个渲染叶）都会按遍历顺序保存到渲染树根节点（渲染台）中，即可构建渲染树完毕。然而，由于对场景中部件得渲染树顺序
可见，setRenderBinDetails()的值有0，-1，1，10共四种。
如果叶节点3 _geode3也设置为1，且用"RenderBin"或者”DepthSortedBin"方式，按照指定的渲染顺序号来绘制，那么在渲染树_geode3节点及其附带的几何体将构成更复杂的结构形式，如
ss03->setRenderBinDetails(1,"RenderBin");
虽然ss03和ss14的渲染细节设置完全一样，但是由于关联ss03和ss14的节点之间是父子关系，它们不能放入同一个渲染元，还取决于两个Stateset对象在状态树中所处的层次。
感觉和我以前想象的还是有区别的。
电子书上的总结，抄一抄。
osgUtil::StateGraph:状态树的分支节点（状态节点），负责管理和绘制场景树中的一个渲染状态（StateSet)对象，末端的StateGraph节点还负责维护一个渲染叶RenderLeaf列表。
osgUtil::RenderLeaf：状态树的叶节点（渲染叶），负责管理和绘制场景树末端的一个几何体（Drawable)对象。
osgUtil::RenderStage:渲染树的根节点（渲染台),负责管理默认渲染树徐的所有末端StageGraph节点（附带渲染叶），并保存了谦虚渲染和后续渲染的渲染台指针列表。
osgUtil::RenderBin:渲染树的分支节点（渲染元）,负责管理自定义渲染顺序的末端StateGraph节点（附带渲染叶)；渲染树的根节点和分支节点只能有"RenderBin"和"DepthSortedBin"两类子节点，但可以根据不同的渲染顺序号衍生出多个子节点，它们在渲染时将按顺序号升序的此粗执行绘制。
大概明白了，就这样吧
