oops, I see the problem. I'll get a fix in when I get to work tomorrow.
Thanks for the fix, it works again 
Im still getting error in PhysicsPicker
Spatial target = data.getTargetMesh().getParentGeom();
The method getParentGeom() is undefined for the type GeomBatch
I just downloaded from CVS, if this error is being worked on already sorry I misssed it in the forums.
also I havent been able to connect to sourceforge to get the old physics system for days, anyone else having trouble connecting?
hi mud2005, cvs adress on sourceforge seem to has changed to "PROJECT_UNIX_NAME.cvs.sourceforge.net" as stated
somwhere in this heavily misused thread 
http://www.jmonkeyengine.com/jmeforum/index.php?topic=3246.0
it worked
glad I asked, weird place for important info like that.
Thanks winkman
I think these batches are great. I was using a node with multiple child meshes first to get the same effect, but this really cuts down on my mesh count :).
Just one question though about the multiple texturebuffers for each batch.
I am guessing there are multiple texturebuffers because you can add multiple textures to a texturestate. but didn't the amount of textures you could add to the texturestate depend on the amount of buffers on your videocard? Maybe if someone could explain to me what the actual benefit of having multiple texturebuffers for each batch is.
Thanks,
Maurice
The TextureBuffers are texture coordinates. So with several buffers you can have serveral coordinates. Eg. if you have a mesh of a face you can use one set of texture coordinates for the skin, and another for the eyes.
Right, but i would need to add the skin texture and the eye texture to one and the same texturestate and then apply it to the batch. Right?
And according to the api doc from texturestate
<code>setTexture</code> sets the texture object to be used by the
Yes you could do that too. It'll likely be slower though and there are some other issues…
You can get the number of texture units that support texture coordinates with TextureState.getNumFixedUnits() (or TextureState.getNumUnits() if you don't use the lastest CVS version of jME).
You can get the number of texture units that support texture coordinates with TextureState.getNumFixedUnits() (or TextureState.getNumUnits() if you don't use the lastest CVS version of jME).Yes, I found that line of code in a junit test after i made my last post. Apparently my ati mobility radeon 9000 has 6 of them.
Yes you could do that too. It'll likely be slower though and there are some other issues..
Please elaborate on those issues because this is exactly the reason why i am using these batches.
Also would it be worth the effort to dynamically decide if parts of my mesh can use a different texturebuffer or have to be put in a different batch?
Thanks llama.
Maurice
For example, if your batches overlap, and you draw geometry on exactly the same spot you can get z-fighting (the videocard won't know which texture should be drawn on that spot). All these issues can be solved though…
Wether it's "worth it", is up to you. You can always do it later though… multitexturing right now lacks some good tutorials.
For example, if your batches overlap, and you draw geometry on exactly the same spot you can get z-fighting (the videocard won't know which texture should be drawn on that spot).
Aha, so thats what i have been seeing when i place to boxes adjacent to each other. Cool name :D
Well if that's the biggest issue, i'm home free. none of my batches currently have an overlap.
I just had an idea, how about incorporating somekind of batch flattening into jme just like you have with renderstates. It could be triggered manually or automatically and jme could decide based on the amount of available texture units and the amount of textures in each batch to merge a couple of batches to make optimal use of all the available texture units. You would have offcourse the same problem with z-fighting but given a fair amount of batches you could always try to merge 2 different batches.
Maybe i'll try this for myself later on, see how big a performance increase i can get :D
Thanks llama
Textures in a single texture state are combined together, so you cant simply put together textures of more modells into single texture state, because then textures of one model would be visible on the other too. You can do it when using shaders, because the shader decides finally which textures to use, and not the texturestate. I have tried this kind of "optimization", putting together more textures into a single state, but it has not worked well for me. The basic problem is that you cannot know at the time when constructing the scene, which textures will be visible in the same view. So if the camera turns so that you see one model, but not the other, you will use textures of the first model from the texturestate, but will be setting but not actually using textures of the other model. Which is more than not optimal.
:’( Just when i thought i had it all figured out.
Thanks for the info vear.
Sorry, did not want to confuse you. Nor talk you off from experimenting.
MrMean said:
For example, if your batches overlap, and you draw geometry on exactly the same spot you can get z-fighting (the videocard won't know which texture should be drawn on that spot).
Aha, so thats what i have been seeing when i place to boxes adjacent to each other. Cool name :D
Well if that's the biggest issue, i'm home free. none of my batches currently have an overlap.
I just had an idea, how about incorporating somekind of batch flattening into jme just like you have with renderstates. It could be triggered manually or automatically and jme could decide based on the amount of available texture units and the amount of textures in each batch to merge a couple of batches to make optimal use of all the available texture units. You would have offcourse the same problem with z-fighting but given a fair amount of batches you could always try to merge 2 different batches.
Maybe i'll try this for myself later on, see how big a performance increase i can get :D
Thanks llama
I guess when batches completly do not overlap at all, the performance difference will be much more minimal. In fact, you'll probably only notice when your scene is limited by the factors you influence with this (mostly you save a bit of CPU use). So I wouldn't bother in this case.. The example I meant was more when the whole face is one mesh, and you want to put textures on different parts. Escp if some parts of the textures overlap (maybe you want the eyebrows to blend a bit with the skin under it for example).
Using seperate batches on the other hand can have advantages too, escp. if you have a big model, then some batches can be culled.
So, like I said, if you feel like experimenting, you can always do that.. even if only to understand jME/OpenGL better. But if you want to keep building a game, IMHO it's not needed to look into this at this point.