I’m researching the possibility to create game with areas like Quake levels (by the size, level of detail, mutability and interactiveness).
Quake levels are very small by today’s standards and there is no longer any reason to use BSP or the like for them. Just load them and let them render.
I think Blender is probably more or less fine for making such levels, too… there is a gltf exporter bug that makes it a little harder before 2.83 is released (it’s apparently fixed in 2.83). Others can provide tips on making the editing process easier (snapping, etc.) as I’m still learning myself.
I used to be really down on using blender as a level editor but I’m warming to the idea the more I get comfortable with some of the new features.
If you are used to the old-style Quake level editors that carved empty space out of an infinite solid then I’m not familiar with what’s current in that regard. (Though I do have a lot of experience with Quake levels from 20 years ago: Paul Speed's Java Projects - JQMap)
Thanks for quick reply!
Just load and render? You mean just load whole level as one object?
What if I level have many interactive surfaces, that need to be mouseclicked (raycasted)? Do I need to load them as dedicated objects? So it’s a manual work to split just decorative static (as a big object) and interactive surfaces?
What about mobile devices? I guess some engine-level optimizations may reduce battery usage even with Quake complexity levels.
Load it as one scene. Separate objects should still be separate objects. Break the level up spatially as makes sense. JME will then cull objects that aren’t in view.
Others can speak to mobile. Probably you want fewer separate objects in general and fewer vertexes/triangles in general.
Original quake levels were also loaded all at once as one giant object. They were just heavily split based on BSP slicing so that from any given point you knew what convex BSP nodes were visible. This is not required anymore as even phone GPUs are more than capable of handling what was in one single old-style quake level.
Heck, some modern gun models are more complex than some of those old quake 1 levels. 
I agree that modern phones very capable, but these capabilities drains battery when used. If I can use some optimizations to draw the same scene 10x energy efficiently, it means user can play 10x more time using the same battery. Or just play the game without worry about the charge.
As long as your level is subdivided into a reasonable scenegraph, jME will efficiently cull the scene for you without you having to use the same BSP approach the original Quake did.
Hm, I see. Do I need to organize this graph (links between objects) manually, or I need just to drop all objects of reasonable size to scene (something like scene.attach(piece) for each level piece) and engine will organize them in graph under the hood?
The engine does not organize the graph for you - if you attach 1000 pieces of a level to the root node, then with every frame it must check all 1000 pieces for culling. You do need to come up with some sort of structure for efficient culling, but it’s very open-ended. You’re not locked into using BSP.
I believe, this problem is very typical. So there should be automated ways to build this structure. Nobody cares?) Or is it just easy enough to code it in each project individually or just define manualy during level construction?
It’s more of a matter of every project has different needs. A BSP or an Octree or similar structure suits some games, but not others. Rather than the engine try to guess, each game is left to organize the scenegraph as it sees fit. In any case, these structures are not that difficult to develop.
@pspeed, @danielp, thanks for explanation!
The only question left is suitable level editor and level persistent format. As I understand, jME doesn’t suggest some universal level format and editor. But what formats are the most suitable and/or popular for such kind of levels?
jME can store complete scenes in the internal j3o format. You can use the jME SDK to produce/edit these files, or you can use Blender and load the levels from GLTF files. It’s really up to you - you can also use GLTF during development and then convert to j3o for release (j3o is a compact binary format that’s very efficient to load).
Edit: GLTF is the most popular external editor → jME format, and it’s also the most reliable and feature-complete.
Ok, I got it. thank you for operative help!
No problem at all. Good luck with your game - hope we’ll get to see screenshots soon!