Hello, there are only “few” objects in my world but the framerate seems very low to me. Maybe it’s because i don’t use different “threads” for different things (i just don’t know how to do this). Are there some fundamental techniques that should be used to keep the framerate high and where can be found documentation to learn them ?
The first question is why you need 9149 objects for such a simple image.
ToDo: Optimize the number of objects.
Do you also do a bunch of calculations in update ()?
In my opinion, threads are not the problem or the solution.
See:
The framerate doesn’t change even if I have no calculations at all in my simpleUpdate. Maybe I can optimize the number of objects a little bit but i’m sure that I will have to handle about 10.000 objects in the end.
I see many red dots, its not just just about this objects.
Still like mentioned above, Geometry = drawCall, OpenGL drawCall itself require some procedure that cause lower framerate for you.
So in Games, for example All building is as single Geometry, same about Grass, Grass chunk is single geometry. This is how it should be done in default ways. Geometry Batching is keyword here
you should basically do same.
Question: Do All of your objects use physics? 10 000 objects use physics at same time?
Question2: What do you want achieve in general? ( we might know generally better way )
2 Likes
Just a hunch, is it always 30, and are you running an old JME (pre 3.4.0), using jme3-lwjgl3 and trying to cap your framerate at 60 (using settings#setFrameRate).
If you are, there was a bug that the capping went wrong and effectively capped you at 30ish
That’s the problem or at least a big part of it.
The reason is that every object calls into the driver, which means the OS needs to do stuff etc pp, which just takes time, if that should happen 10k times per frame (which would mean you’d only have 0.1ms per call at 1 FPS; you can do the maths easily, especially considering that one object does more than one call).
What is your background, this looks like CNC/3D Print to me?
The two main techniques are Batching and Instancing that help there by basically only rendering one (or really just fewer) objects, but combining the vertices (you have 22k triangles, that is like low poly for most games, like even a sword has more).
How dynamic is the scene?
Minecraft (Voxel Worlds) have some sophisticated engines to remove the invisible sides of the cubes and also (and this is where it may be important for you): update parts of the “big combined” mesh fast enough.
If you’d just batch that all together, it may freeze the application for a few seconds and then run fast. This works fine, if that combination rarely changes, but if one cube changes every frame, it’s not feasible and things get more difficult.
You can also try instancing, it’s like Draw Array and passes an array of positions (for objects that have the same material and geometry)
I’m not quite sure which “objecs” I should reduce. Is it just the number of nodes or are there other object-types that are critical?
Nodes are non-critical but each Geometry is rendered separately.
This especially weighs in when you build something out of lots of boxes instead of combining them
Thank you very much for the information. At the moment I use a new geometry for every mesh. When I use only one geometry for ten meshes, it should run faster, shouldn’t it?
You would have to combine the meshes. One mesh per geometry.
Geometry = draw call
Mesh = mesh data sent to draw call
Material = shader configured for draw call.
You can use this as a rule of thumb for performance.
For example:
10,000 Geometry objects each with their own mesh and their own uniquely configured material will be the most expensive. 10,000 separate draw calls with 10,000 separate shader setups, and 10,000 separate “vertex buffer uploads”.
Where as 10,000 geometry objects each sharing a mesh and material is still 10,000 draw calls but the data only has to be uploaded once. (It’s not exactly as simple as that but close.)
But the best is when you combine your mesh data into few (or one) meshes… then you reduce the number of draw calls. That will have a huge impact… and it’s why games like Minecraft or Mythruna can get away with looking like they show millions of boxes. Because they are actually just showing a handful of meshes full of visible faces.
1 Like
Indeed I use a new Material in every new Mesh and always make a new Geometry. The easiest thing to change for me ist the Material. So I will try that first. I will tell you if it worked out well.
Materials that use the same shader will have almost no impact.
Your meshes are the single biggest impact. That is where ALL of your performance problem is.
My pedigree:
I do really crazy geometry stuff and get really good performance.
2 Likes
Just if someone wants to know what my program does, here’s a short video
https://howatherm.hartechcloud.de/index.php/s/owitXdsByqBTsdG
Password is “JME-Forum”
SOLVED: I managed to reuse the meshes for different geometrys and the framerate ist now about 10 times faster. When using extruded objekts that only differ in length, I now use the same mesh with the lenght of 1 unit and use the setLocalScale() method to change the length of the geometry.
5 Likes