Hi MrMean
Have You considered using Quad instead of Your own rectangle trimesh construction (newTile) ?
On first glance You seem not to set texture coordinates in newTrap.
Hi, thanks for the reply.
Yes i have thought about using quads, however it is stated in the doc for quad that "The z-axis will always be 0."
however it is stated in the doc for quad that "The z-axis will always be 0." which means i cannot use quads to construct objects with 90 degree angles in them
What do You mean by 90 degree angles ?? if its like Your trap then Quad is fitting ! Just look at com.jme.scene.Skybox.initialize() without the zbuffer, renderque and cull wizardry.
If it's still not what You want then i'd suggest taking com.jme.scene.shape.Box and extend that to Your needs.
Winkman you are correct. i can't believe i missed this because i actually did try to use quads briefly.
So now i am using quads as tiles and i turned skybox in a quick and dirty trap class ( removed the top and made a few modifications regarding lightstate etc)
And i get the exact same problem. the textures that show up when i make a field of just tiles (or quads) disappear when i alternate between tiles and the new trap class.
Still using sharedNode and sharedMesh though. As stated before i am only trying to texturing the tiles the trap is random colored atm.
I am correct in assuming that the texture given to original spatial is used by sharedmeshes / sharednodes right?
I'll try using a .3ds model as a trap tomorrow. But this really has me puzzled.
Anyway thanks for pointing me in the right direction with the quads.
If you still want to help i can post my new code.
Maurice
Ok, post it and i'll have a look.
1 more observation if i add a texture to the coloredTile in the above code (either the same or a different texture) both textures show as they should.
Maurice
Thanks man.
I am glad to see your code does not differ that much from my own.
I did some testing to see why your code does the job and mine doesn't.
First thing is, you set a texture for the trap. I found that one myself too last night.
Second, you set a vboinfo.
Apparently either of those 2 causes the textures to render correctly. without them your program has the same texture problem as mine.
I wonder if this is a bug.
Ok, following code (kind of) works for me but there seem to be a flaw in the skybox.
If it's set to default size of 10x10x10 it culls the scene at it's borders
...had no time to investigate this further.
But i like it this way more (not directly at the edge of my field i mean)
Regarding the TestApp3, that doesn't seem right at all. I'm taking a look at this.
Glad to help 
I think vboinfo has nothing to do with it, but remained from me copy and pasting from TestSharedMesh
I too don't think this should happen, but maybe one of the dev's could help us out here ?
EDIT before POST llama replied before i could
Quote
Ok, following code (kind of) works for me but there seem to be a flaw in the skybox.
If it's set to default size of 10x10x10 it culls the scene at it's borders
...had no time to investigate this further.
But i like it this way more (not directly at the edge of my field i mean) grin
No, i don't agree with that, as the skybox itself get's culled this way if the frustum far plane isn't set far enough to cover the entire skybox.
Ok, I tracked the problem down. Because of SharedMesh, you were using the same Buffer for texture coordinates twice. That's a good thing to do, of course
But there was a bug relating to this, not in SharedMesh but in the renderer code.
The render caches what textures coordinates are loaded, so it won't overwrite the coordinates for a texture unit with exactly the same coordinates. Unfortunatly, when a geometry with a lower number of texture units set (0 in this case) was drawn, it would disable texture coordinates for all units with a higer number (all units in this case). Then for the next object, the render would look in the cache and see the right coordinates were already set, and do nothing. But it didn't check if the texture coordinates for that unit were enabled at all 
So, I fixed this in CVS. Thank you MrMean for the very clear test (that's the way we like 'em here). And thanks winkman, because the fact it did work with VBO gave me the hint I needed to find this bug (since VBO bypasses the code where the bug is in).
Again glad to help, even if unintentional.
Glad to be of help.
And thanks, both of you for the help / fix.
Maurice