Can jME cut out non-displayed triangles other than using the Bound system?

More objects means move overhead processing those object. It uses more memory, more CPU and keeps your GPU waiting longer too. However, if you have to render a lot less triangles it can still be worth it. Escp. if your game is all graphics and CPU hogging gameplay, and you have a lot of memory. :wink:

So the trick is cutting your object at the right places. Also keep in mind that wether a triangle is inside or outside the viewport is not the only thing that matters! Triangles inside the viewport, that are drawn but then completly overlapped by other triangles are just as useless, but much more expensive than those that are never inside the viewport (the GPU does some very fast "culling" of it's own there of course, but yes what you're trying to prevent is they have to go to the GPU in the first place). That's why things like occlusion culling are on the TODO for jME.

Glad to know occlusion culling (ooh, so that's what it's called ^^) is in the works for jME. I'm sure there's a way to do something simple in the meantime, at least for objects that are completely obscured by another.

Well, simple is relative. For implementing, there's plenty of papers, examples, etc. out there. Still a lot of work. Technically, afaik all of those solution tend to rely on design time or pre-computed solutions, because it's too expensive to do it during runtime.

  1. CullState handles back facing triangles. I.e. your inside the sphere problem.
  2. Frustum culling handles objects that are outside the view frustum. You can set up your model in as many pieces as you wish (usually in your modeler), but jME will NOT automatically break up objects. This would be a case of the system trying to be smart for me and probably failing. Setting a model's nodes is the job for a modeler.
  3. Occlusion culling is on tap in awhile, but as llama mentioned, not a simple process. We need least fitting boundings to compare with the normal boundings, etc, etc. There's quite a bit to it.
  4. These 3 culling methods are all you really need with modern hardware. After awhile you are putting too much stress on the CPU to determine what to remove when the GPU could have just drawn it all already. Improvements can be made with tighter fitting boundings, properly split models, etc, etc.

That answers my questions well, thanks mojo :).

Havent tried in with JME, but with jogl you can assign a unique colour to the back face of an object and then use the colour for collision detection