Hello JME Community!
I want to ask a foolish question!
Can Jmonkeyengine Handle Large Projects like big terrains, upto 2000+ animated npcs mid poly, particles, physics, etc.
I want to create a game like Delta Force 1998 with some Arma like features, it will take much time.
Have anybody tested Jmonkeyengine.
I am Unity Full time Game Dev and I haven’t tested Jmonkeyengine capabilities. I love Java programming that’s why choosing JME for my personal project and I can’t trust Unity what they have done recently.
Hardware requirements that I have just in my
mind are i5 6th gen and GTX 1060 3gb minimum. For playing on normal settings
I’m sure it can… if you code it properly It all depends on your skills. If you are going to just add 10x10km2 land mass and populate it with the stuff you mentioned, all at once in the scene graph and have it all display as it is in a single view… It is not probably going to work. With any engine.
I already tested huge terrain with objects and sure.
tho im not sure about animations, would need test this too.
About physics, its all about design too. Simple example are collision shapes, the more simple the faster it work. (for example heightmap based terrain physics shape will work many times faster than generated mesh based physics space)
Also its all about how huge terrain will be. Myself i also plan to have huge terrain so i split Physics Spaces / Terrains / Pathfinding(navmesh) into Grids.
So for example if someone shoot rocket and terrain get modified to have “hole”, then navmesh will update only for little part, physics CS the same. But anyway most games do not even have features like this.
Good example is Mythruna game where you also have Huge terrain that is even voxel based so its even harder to make it work good.
Seperate from the question of if JME can; do you need to. Usually large complex worlds only load things near the player and on-demand load other things as the player walks around. (Think chunked terrain and npcs only loading within a render distance)
I don’t want to see 2000+ npcs and terrain at same time. But imagine if at same time 500 npcs firing at each other, some rockets, bullets and other things, that what I was asking. You know Minecraft also have huge world but you don’t see all at once. So, that’s my point. Thanks for reply by the way.
I understand that. Actually I tested Godot but it failed in same scenario.
I just want to say that what if more than 500+ animated npcs come close where player can see all of them. They start fighting at same time. Will JME be able to handle it. Unity can. I have tested unity. But I don’t want to make my own game with unity.
Thats true, but please note you can not only “hide them” but also optimize based on distance from camera.
For example closest one will have 40 bones, while middle one 20, while far one 10, even more far 5, and too far is just not rendered/existing at all. (and well, for big battles i would start from 10-20 bones really and not many verts anyway - verts are even more important than bone amount here)
And its not just about bones but also Verts.
Imagine GPU need calculate per every bone every vert there to move based on animation stage.
Less vers / less bones are helfull for sure. So you can try make LOD system like this to optimize it.
Im not sure if there is any other bottleneck in JME, maybe there is related to sending params into GPU.
But what is funny is that you could even split half animations as software and half as hardware. So some would be done on CPU and some on GPU.
About GPU one im just not sure how JME send animations into ti, but if its “per-frame” to update skeleton data, then the bottle-neck might be mainly about shader uniform. (and here someone might help how it was in JME)
Got it. That’s what my dream project will do in months to just show a playable demo. But I love your work. Specially PBR terrain demo video. Keep it up
But just without Riccardo Occlusion Parallax or water/etc features i added.
And also because indeed its nice, there is also github issue for it:
The thing is my one do not use tri-plannar that is most problematic it seems. (and ofc i can share code who need)
Personally by design i know i will just place “objects(rocks/etc)” on big slopes similar like Skyrim/Fallout did it, so i just didnt cared about tri-plannar. (funfact: even Starfield cave entrance is just rock object with teleport to cave map)
But it would be awesome if @yaRnMcDonuts idea to make tri-plannar one could work.
Occlusion Parallax should at least work with non-triplanar layers, but even if I do get it to work with tri-planar it would probably be too expensive to be worth doing for more than 1 or 2 triplanar texures at a time, if at all.
So I plan to make the things like occlusion-parallax and tri-planar a per-layer setting (i.e. UseTriplanar_0, UserTriplanar_1,etc etc… UseParallax_0,UseParallax_1 etc etc) so it will be easier for jme devs to improve terrain quality without sacrificing as many resources.
This is certainly one way to do things, although once triplanar can be enabled for a single texture slot, then it should be very cheap to toggle tri-planar for just 1 or 2 layers that get painted on non-flat areas as long as those layers also don’t use occlusion parallax. So hopefully triplanar won’t be something that devs have to avoid for big terrains anymore.
Its also important to remember to not get too hung up on the visual detail of the bare terrain. It is very easy to do this early in the development process, since there is usually a long period of time where your game will contain a lot of bare terrains in the demo/prototype phase.
But eventually your maps will be filled with buildings and live NPCs that are the real focal point of the scene. And the majority of your terrain will be covered with small-detail geometries like grass, flowers, rocks, sticks, etc so the player will often not even notice the tinierl details on the terrain in most places. And, often times, the resource usage of adding more detail to a large terrain will be higher than the resource usage of adding more 3d foilage to the world, and these 3d foilage models (if created to match you terrain textures properly) should also do a good job at making the ground look like its popping out and will make the player struggle to tell the difference between what’s 3d and what’s a flat texture.
My two cents are that I can not see a bottle neck in JME, if you can code and especially know how to write smart shaders you should be fine. I have a lot of respect for anyone who does not get lost in Unity, but you have to keep in mind that it hides a lot of stuff for you.
In Unga Munga I have up to 400 guys running around. They are powered by their own neural networks and there is a lot of statistics going on in the background. And even with tons of debugging and logging going on, both the GPU and CPU have no trouble maintaining 60 FPS on my five year old no thrills desktop.
But more than in Unity, you must understand what you are doing and how to get the right processing unit do the heavy lifting.
For instance: in Unga Munga you see the grass bending where ever the little guys walk. And the water foams at the shore and around the litte guys. That is all non standard shader work. The terrain shader of the little planet the guys live on is also a custom shaders that are especially designed to work with a globe. It can have ice caps on the poles and a tropical zone at the equator.
In Unity you don’t need to bother with instancing geometry. In JME you will need to master this if you plan to have any fun with your 2000NPC on screen. I wrote my own custom instancing shaders so I could do more smart things, like giving each guy a color without the penalty uniforms will take.
Getting the 3D to be great is a lot of work, but JME gives you full control to get this done. And still takes a lot of basics out of your hands. There is not really a reason why a Java based engine would underperform a c++ engine when it comes to getting the GPU to work. And all 3D calculations Java does are fast enough.
I am currently most pleasantly surprised with the speed of the game logic that is entirely dependent on Java. It handles 400 brains with each over fifty nodes with ease, with all the statistics that is going on too.
I agree. When i first switched to jme3. My simple game would not run 60fps, i took several peoples idea on what to do and added it to my code and it started running over 120fps… my old engine was different, and could run 60fps in the style i wrote it, but not for jme. Once i converted it to jme style, it ran even faster.
Its making changes because it worked for that engine doesnt mean it will for this engine, but that doesnt mean the engine can not do the same thing, it just needs to be done differently.
It all depends on your skills. If you are going to just add 10x10km2 land mass and populate it with the stuff you mentioned, all at once in the scene graph and have it all display as it is in a single view… It is not probably going to work. With any engine.