Maybe you can try to merge the meshes, recompute the normals, then split them again.
It may not be the easiest of the workflow though if you have different models of legs and body.
You can visualize the normals in blender, in the 3D view, go into edit mode (hit tab) then hit “n” and a panel will pop on the right. In this panel you have a “Mesh display” section and you can check to display normals in it.
Yeah I just visualized my normals and saw a very small offset after joining the meshes to one.
(Difference between the double vertices normals)
I tried the workflow you suggested (merging, calculating normals and then seperating).
It does not work, as blender automatically adjusts the normals when splitting an object in 2.
What are the cloth junctions you mentioned?
We want to solve this problem, regardless of the solution.
We know that we could “hide” the feet inside a boot,
but it would cause us to have many faces which would have light calculation etc and never be visible.
Or can jMonkey adjust the culling to not do calculations for “hidden” faces?
Well let’s say your model has panties, the leg model has to start at the seam of the panties, while the panties themselves are in the body model.
Or indeed, overlap the meshes whit for example half a leg in a Boot.
Hidden faces are usually not rendered, but that’s not really a JME thing more an OpenGL thing.
Objects in the opaque bucket are sorted front to back. Meaning that objects closer to the camera are rendered first.
When rendering an object the depth information of the object is rendered to a depth buffer (at the pixel level). If when rendering a pixel there is already a depth value in the buffer below the current value, the pixel is not rendered. Basically if we already rendered a pixel that is in front of the current pixel, we don’t render it.
This usually greatly limit the overdraw of a scene.
That said when an object is “inside” another, as in the case of a leg in a boot, it might be some overdraw as the body might be sorted before the boot depending of the orientation of the cam.
Also…that doesn’t prevent the hidden vertices to be processed and sent to the gpu.
But all in all I’d be surprised that you notice a performance loss if you do this. Modern graphic cards eat vertices like mad, and that’s not really an issue.