Hi every one,and thnx for your attention 
.
I wanted to ask how mutch difference there is between using one big geometry that merges textures verticles and the rest, and using 2 smaller geometries .
Lets say i have a room and i have a table .I could merge them as most they do is stay there do nothing,or i could make roomGeom then tableGeom ,put them to one node .
Its just some times its really better to split some objects (geometries) in two or more ,and then mix or do other things.
But i try to no waste resources as my game is getting huge and do cool but complicated and probably expencive stuff.
Soo what i need to know is how mutch resources does it use to have 2 goems at a place of one. And does that really makes a difference?
It does make a difference, yes. Every separate geometry = one extra draw call (and probably state changes to switch textures/shaders), and unless you have very expensive shaders and/or an extremely high number of vertices draw calls are probably going to be your bottleneck. However, unless you’re doing this at a large scale (i.e., lots and lots and lots of sets of 2 geometries that could be merged into 1), it’s not a remotely significant difference. If your draw call count does become an issue, you can also use batching/instancing instead of manually merging models like this - you get the benefit of creating the models separately but you don’t get the expense of rendering multiple models in place of one.
Emm i tried GeometryBatchFactory.optimize
But now all geometries are moved at (0,0,0)
If i do move the at new coordinates will it break “optimize” ? or not? and how to move ? setLocalTranslation?
It says i need to use same material,but my geoms sheres nothing of a same,not material not texture.
You can only batch static geometry, I believe - once it’s batched you can’t move the individual pieces without re-batching the entire thing. It’s meant to speed up stuff that’s draw-call heavy but never (or only very rarely) changes. And in your case, since your objects do not share the same material/texture, you can’t use it. If you carefully plan your models/materials/textures, it’s an option you have for speeding up lots of static geometry, but (as you’ve discovered) it has plenty of its own drawbacks as well.
As with all optimizations, profile, profile, profile. Time your code and see what (if anything) slows your game down. (I’ve learned this the hard way - no matter how well you know your code, the real slowdown often is not where/what you think it is. Save yourself lots of time and headaches by measuring first so you know what problem you’re really trying to solve before you try to solve it.) Unless you’ve got hundreds of the same geometry on screen at once, batching won’t gain you much of anything, and without profiling your code first to see where your real costs lie you’ll be guessing in the dark about what the real bottleneck is. If we’re only talking about a few dozen geometries here, then the time you will spend reworking things to make batching work will cost you far more time than it is worth.
Hope that helps.
Thnx 
As alternative you could use the BatchNode class, which lets you after batching still move the individual childs you attached to that node. It’s pretty simple to use.
Here is the JavaDoc:
https://javadoc.jmonkeyengine.org/
But note, that this alternative will not give you the same performance speed up as if you would use GeometryBatchFactoy.optimize().