Is there a way to make less obejects [SOLVED]

I have a tiled based level setup and quite some moving objects (physical objects which fall down if you walk over it or stand underneath). This moving objects can’t be batched bc then they cant move anymore. An object typically consists of 9 - 100 tiles depends. Is it possible somehow to combine them to one object? Reason I ask is on my older laptop it’s a problem as soon I have over 400 objects. Even on newer ones with a less powerful gpu it’s a problem to have more than 1200 objects (Boss room).
Not sure if this is a thing and if it is I hope I find someone which did it and in best case has some examples laying around.

By objects do you mean geometries? If so yes, having 1 geometry per tile will not be performant. You can either merge geometries (using GeometryBatchFactory.optimize) or use a custom mesh (Custom Mesh Shapes :: jMonkeyEngine Docs)

1 Like

Your path forward depends on where the time is being spent.

Instancing or batching won’t help if it’s not a rendering problem but a physics problem.

You may be able to gain some insights by opening the in-game profiler (F6 by default I think)

Rendering-wise, I’ve had scenes with many thousands of objects without issue. So it might be the physics that is giving you trouble… and then combining objects would only hurt you.

1 Like

are you sure its about objects(Geoms) amount and not physics?

ofc, more Geoms = more drawCalls = the slower game.

But for physics it can be opposite, the more complex collision check(bigger Geoms Collision Shapes / More complex) = the slower game

so need to be carefull here.

if by “tiles” you mean terrain mostly, ofc i would merge them into 1 Geometry per some chunk, BUT most importantly i would use OPTIMAL Physics Collision Listener / Shape for it. Like for JME Terrain there is HeightBased Collision one, you should have something optimized for your tiles i assume.

When i also had Destroyable Voxel walls work process, i needed use peoper physics shapes to make it work without freezes / lower fps.


Thanks, @richtea, @pspeed, @oxplay2 for your input, this will help me on my path to success.

Atm, it looks like the bigger the object counts the bigger the drop in frames per second. I just removed the tiles and the performance goes quickly to acceptable. So I assume it is the number of objects. On newer HW this absolutely no problem, but on older it is. Or on laptops with a weaker graphics card.

I will of course as well inspect the physic (I use dyn4j, so it’s not even 3D physics), as I have a couple of listeners for certain effects and stuff.

1 Like

I think we would need to know a lot more about how your scene is constructed to help further. It just seems strange to me.

Original Mythruna would sometimes have 2000-3000 objects in the scene and performance never dropped below 60 FPS on 10 year old hardware.

If you are GPU bound a profiler won’t show it, but if theres something weird going on that is burning a bunch of CPU power using a profiler may be a path forward

Edit; now i think about the general computer performance monitor may tell you if you are GPU bound or CPU bound (or for that matter disk IO bound)

There is a graphical profiler built into JME that will show you how much time each frame is spent on the GPU versus update, etc…


You guys were right, kind of. So on my new Windows PC, it is 11ms CPU and 0.47ms GPU for the problematic level. In “regular” levels it is 5ms GPU and 0.47ms GPU.
My physics system is totally bored with 0.23ms CPU
But the SpatialUpdate has 5ms which is almost half of the frame time. Any thoughts on this? Beside that my laptop is really really old :slight_smile:

On my Laptop it is 24+ms CPU and 12ms GPU.

We don’t know enough to help further, I fear.

I have to find out what this SpatialUdpdate is and who or what cals it. I guess.
I always thought than many objects is not so good as it has to be copied from CPU to GPU, that’s why I focused more on that first.
Anyway I have now a good tool to visualize the load. That’s perfect. Learned something :slight_smile: