I've been thinking about JME and reading it's source code. Firstly I'd like to say it's a very well made 3D engine. I'd also say that I'm some what of a noobie and don't know all about it, but I do have some ideas, however I'm not sure if they've been implemented…
Texture sorting for the whole scene graph is a idea I've had, so that instead of drawing the scene graph from root to child in a linear fashion, what you do is this, you take all of the nodes in the scene graph, sort them by texture, and then draw the nodes in that order using only 1 texture bind per all the nodes that use that texture…
Another thing is about the terrain, I've noticed that I can only make pretty small sized terrain, if you've played sierra tribes you know how efficient the rendering of a terrain map can be, so one idea is take your terrain generation code and generate a scenegraph for the terrain such that it generates a quad tree of the terrain…
And another idea is for static geometry, imagen you made a forest, now you could just send all those trees to opengl in floatbuffers, but that's not very efficient, instead make it so you can store all the trees in a class called something like StaticNode that has a method called buildBSP and then this generates a BSP tree for the static forest. This would also make shadow mapping less expensive if you plan to implement that some day…
Object in jME are usually drawn either from front to back (opaque objects), or from back to front (transparant object). Front to back is faster than "random" order, because pixels with a higher (further away) z-value won't have to be drawn. Back to front is required for transparent objects, because if you else you can't see what's behind them.
It's true that it's possible to follow the "natural order" of a node as well, in that case you might already get some RenderState optimizations (Textures are just one of those). There are certainly other factors that'd have to be taken into condisideration for an optimized render order, and it's certainly something for the future.
BSP is being worked on by mojomonk and renanse, and there has been some work on this from community members as well. As for really huge terrains, that's something I'm busy with myself, and I hope to release an experimental preview of this work (outside of the jME cvs though) soon. It's worth it to be noted however, that quad trees for terrain are already supported (take a look at TerrainPage)
Thanks for the reply.
I was just reading little bits of this article http://www.flipcode.com/articles/article_frustumculling.shtml and he mentioned that sphere culling is actaully faster then bounding box culling and that you can have a bounding box for a object but also have a bounding sphere around that bounding box, this would probably help out a lot with quad trees which are mostly rectangular… Depending on how you test a
bounding box against the frustum in jme this approach can actually save you up to 8 dot products per check…
jME supports Bounding Spheres, OBB and AABB.
what's AABB? XD
Thanks 
Axis Aligned Bounding Boxes