Well i need three texture coordinates, but jme3 supports only 2 so far. No Problem I though time to start some code digging and implementing it, then posting it as a patch. Well actually it’s a problem 
I have hard problems to locate where the low level loading happens.
MeshLoader.pushTexCoord seems to only load 1, however there are already two supported. Question is where does the second come from O.o? If someone could give me the right direction I would like to continue .
We could support as many as needed …
I can understand when people are asking for 2 coords, one is for the color map and another for the lightmap, but why would you need 3 texcoords?
Special needs. The normal problematic with AtlasTextures is that, you cannot use Repeating textures in the model at all, since thw whole atlas would be repeated.
→ Solution
texcoord1 the orginal texture coordinates before atlas generation
texcoord2 the startpoint for the texture in the atlas.
texcoord3 the endpoint for the texture in the atlas.
The repeating is then done by mapping the texcoord 1 with modulo 1 into the area defined by texcoord2 and texcoord3
Due to texcoord2 and texcoord3 staying the same over a complete model the interpolation normally done between the vertex and the fragmentation shaders makes no problem. (sharing vertixes is a bit more inefficient due to this, however the minimal performance loss because of this is greatly compensated because there are far less renderstate switches.
@Momoko_Fan, there could be a lot of use for multiple texCoord, let’s say diffuse, lightmap, glowmap for example ( for now glowmaps use the same texcoord as diffuse, but it could be useful to use a second set of coord to have smaller textures etc…)
Also anyone can come up with an idea to use them really…
If we are going to support 3 texcoords, I say we go for the full amount of 16?
Note that you can pack your start point and end point into a single texcoord, by using Vector4 texcoords. This is also more efficient than submitting additional attributes to the GPU.
Yeah but somewhere in the code i found a texcoord dimension 4 not supported todoe/exception thing. And I will change that later.
Basically support for 16 would be just a bit of copy paste from the above changes, but why 16 it’s depending on the gpu as far as I know (modern nvidias have 64 texture units), and I can’t really find something that needs more than three coordinates.
We are trying to stay compatible with OpenGL2 GPUs, which do not support 64 texture units or even close.
It seems 8 texture coordinates is a good number and is also the maximum number supported in OgreXML, so thats the amount I committed in the recent patch.
Well I doubt anyone could use 64 units anyway, they are more for automated parralel execution of far less textures, just say thats possible