Dunno what to say really - this stuff is somewhere between strange and funny.
With just a first tutorial I get over 500 polygons and 1k vertices shown in counter (DISCLAIMER: first tutorial has literally ONE box). It’s even worse in my own project. In testing I have 10*10 matrix of boxes which should be exactly 1200 polygons. Yet counter says it’s over 1600 of them…
Object counter is even more strange. 17 objects in first tutorial?
Anyone know where those numbers come from?
Each light causes the scene to be rendered again, upping the count. The stats display also has objects that are rendered.
I did notice this as well, also, I dont think this is just an problem on objects in screen.
If you have one object in blender with 4 vertices and import it in the engine, it will for some reason get much higher number of vertices showing in the scene manager, even if you try to make triangulated objects in blender, it gets much more vertices in the scene manager. I didnt have problems with performance with this engine, it seens to be just display bug thought.
I just test it, and if you import the blender standard box that has 4 vertices, in the scene management it will show 36 vertices… with 12 triangues…
normen
Well in First Tutorial:
wagfeliz
On the other hand in my own tests I use Ambient Lightning mostly (rarely directional light but no shadows). Also I’m testing performance now so I’m using jMonkey primitive shapes instead of actual models. So no importing stuff.
Also Vertices and Polygons seem to have no relation at all in those counters. Even though there should be observable relation (You should never get more vertices then polygons - in box example it should be 12 poly, 8 vert).
Additional question (not really connected to the strange counters behaviour): are faces that are out of field of view rendered? For example backface of the box?
About your question, the engine dont render the backfaces by default.
Also it automatically cut and dont render the objects out of the camera view.
As for objects I managed to deduce that (had 1000*1000 matrix of objects for a moment, and zooming in<>out progressively changed counters).
But for the faces: what about side faces? For example ones that are completely covered by another object? For example 2 exactly same-sized boxes touching each other: would common faces be rendered? Also by “backface” I didn’t mean the other side of face but the face on the other side of object.
There is no automatic oclusion culling in Jm3 , I needed once to implement it and have to do it manually :
About the normal culling, its automatic, if faces that are backside of your object will not be rendered, there is information in the docs and wiki about it.
Well in culling Wiki’s there’s only “out of view - behind camera” mentioned directly. And I’d like to be sure about both objects and single faces being covered by another object in scene (even though both are in front of me and pretty close to me) . Will such model / face be rendered?
And back to the vertices/polygons count - what’s wrong with this stuff? No lightning, not a thing in scene except 1 damn box and 500/1000?
As I said already, the stats display. Each letter has at least 4 vertices and two triangles.
Isn’t stats display made with niftyGUI or something? o.O
And more importantly - if I add my own GUI with buttons and stuff will it be also treated like gazillion polygons?
What do you think is the issue with that? Its just one object per line. Polygon count isn’t going to bring down your GPU any time soon, object count is. And btw, its “lighting”, “lightning” is the blue lines in the sky when a thunderstorm is going.
To be honest I thought the polygon count is important. That is I thought that having 100 objects of 10 poly is the same as having 10 objects with 100 poly (in terms of resources usage). Thanks for clarifying that 
As for lighting - I know - autocorrection did that 
That’s just because you don’t get how it works under the hood.
A vertex is not just a position, it’s the unique combination of all the underlying meshes buffers.
This means for the box example that a vertex is the unique combination of position, normal and texCoord.
One corner of the box is actually 3 vertices because there are 3 different normals and 3 different texCoord for one position.
So a box should be 24 vertices (I’m surprised you say 36 maybe I forgot an additional buffer).
Now for the faces: a face in opengl is a triangle. So a quad is actually 2 faces. So the box has 12 faces.
The stat view has 2 triangles for each letter. So don’t be surprised at the high number of triangles.
Fast calculation (if each vertex is copied as many times as there are polys that use it): Yes, in case of box it’s 36: 4 vertices have 3 polygons touching them and another 4 vertices has 6 polygons touching them. It depends on how every quad is cut in half
Anyway thanks for clarification. Good to know how it works deep down
As for performance then: what is the correct object count, poly count, vertex count to run on 60 FPS on common PC these days?
Here is a empty (no Geometry loaded) screen stats:
And here is the quote on the wiki that explain this discussion:
To interpret the numbers correctly, consider that the 14 lines of text themselves already count as 14 objects with 914 vertices. You need to subtract these values from the totals for smaller performance experiments.
Again, just read the whole tutorial before guessing something is “bugged”.
Read this link on wiki