Weird, suddenly I can't access jmonkeyengine.org. If I remember correctly, per its documentation, this engine only does frustum culling. So if an object has any part inside the frustum the whole object is rendered. In case of multiple submeshes I don't know If each submesh is checked again the frustum, I think they aren't.

Correct me if I'm wrong but when a triangle isn't visible due to the direction it's facing, the vertex shader will still run for that triangle but the pixel shader won't, so invisible triangles should be cheaper than visible ones, correct? While triangles facing in the right direction but occluded by geometry nearer to the camera will go through the pixel shader only to get overdrawn latter. I think let the GPU overdraw things is still faster than a bad occlusion culling implementation. If I were to implement It myself I don't sure what to do about semi transparent objects and such. I will try to survive with Frustum culling for now, older hardware worries me but well...

I need to clarify that the corner shown in the screenshot It's not the whole chunk, I choose a spot with good illumination to take the screenshot, but the statistics shown in the debug box are for the whole chunk. I think we can safely conclude that the engine is rendering the whole chunk at once.

My recommendations in short form:
1) Find out if there is an occlusion culling mechanism in JMonkey engine and use it.
2) Find out if there is a static batching mechanism and make sure it is active for all your panels.
3) See if you could reduce the polycount of those panels... with proper optimization, the visible poly count should be okay, but I would rather use the polys for objects that make better use of it than just a displaced rock wall.

1) I think we are out of luck here.

2) There is, they call it GeometryBatchFactory, I think. I don't tried it yet.

3) As the base panel is very simple I can always just redo it again or I can use the Blender decimate modifier, that will reduce the polycount without noticeably affecting the mesh (most of the time). I wanted to confirm if my polycount is acceptable or not so I know if I can just leave It as It is now or if It needs to be edited again. OK, I will try to reduce polycount while It still looks acceptable.

A better measure in is a rolling statistic, perhaps once per second, with the minimum, average, and maximum times between display, in milliseconds. Perhaps you may see 3.24/5.43/5.98, which tells you all the frames are going along at a nice pace, or you might see 0.45 / 5.43 / 206.34 which means you've got a lot of very fast frames and occasional frames that are terribly slow.

I will try it, I think I can collect the per frame statistics in some kind of list/queue and then iterate through It each second to do averages. I don't know if the engine already does that for you.

I am not familiar with the JMonkey engine myself, but if it supports normal mapping (or shaders in general), I would suggest reducing the polygon count signifcantly and applying normal maps to imitate rocky walls. With the right textures and normal maps it would make your cave look a lot better without wasting too much GPU resources.

Well, I support that in theory (after all, 2000 quads per rock face does sound wasteful), I do see that normal maps might NOT be a good idea in this particular case.

The most common case will be the player travelling through the cave in First- or Thirdpersonview, which means the cave walls are seen at quite steep angles. Which is exactly where normal mapping starts to fail.

You could go with other, more complex shading techniques like parallax mapping (which again, starts to fail at steep angles), or try to solve the problem with tesselation and displacement mapping (which might not save you much performance though, is DX11+ only, and might be actually slower on older cards).

If you have the polygon budget for it, and a need for more interesting rock walls (for example there is not much more than rock walls in your level), I don't think its a bad choice. There is a tangible gain doing it with real geometry in this case, and modern cards do have the reserves for it, so why not.

@ TO: no occlusion culling -> ouch. That will hurt your framerate badly in your case. Which is a shame, you could benefit quite a lot from occlusion culling. I don't know if this is an option, but could you write your own occlusion culling system for the JMonkey engine? (I guess that would mean a TON of work to make sure the system performs well though)...

Failing that, you could optimize your level layout for the omission of occlusion culling. Spreading out the tunnels so there is no "hotspot" where lots of polygons can accumulate in your frustum, while other areas are practically empty (thus there are no sudden drops in Polygons rendered). Means you are less free in designing your level, but you might be able to keep the framerate steadier this way.

I would certainly look into batching. If it isn't a ton of work to use, and has no real downsides to it, just use it (it was a nobrainer in Unity, and could make a real difference).

About invisible polygons being cheaper to render... don't know about that. What I can tell you though is that there is a tangible difference of having to process 5 million or 500k tris, no matter if the same amount is visible. At least in Unity this holds true. If you have no occlusion culling going on, standing at the edge of the map and turn around, you will see your Framerate drop if the frustum is starting to include the further parts of the map, thus processing more tris, even if they are invisible.

There is of course one caveat: Viewrange. Depending on your viewrange, Unity would just ignore the tris outside of the viewrange.... setting the viewrange to something low might reduce this performance drop (at the cost of having lower viewrange overall, but given you run into troubles later, you could go all Nintendo 64 on your players, and make your level all foggy to hide the low viewrange).

The most common case will be the player travelling through the cave in First- or Thirdpersonview, which means the cave walls are seen at quite steep angles. Which is exactly where normal mapping starts to fail.

This is a valid point. I haven't considered that myself.

Regarding occlusion culling, this particular scenario seems like a good fit for using portals to me (narrow connected caves and corridors). I do not know how easy/hard it would be to integrate portals for occlusion culling in JMonkey though.