I want to make a terrain (maybe realized with a mesh) that is stepplessly modificable ingame.
First I thought that it would be impossible because as you know, every mesh is made up of single vertices connected by triangles. So one option is to use really much vertices that you literally can modify the mesh in the way you want. But that´s no good choice for performance reasons I think. So is it possible in general?
Then I remembered to the game 'Roller Coaster Tycoon 3", where you actually can smoothly rise, lower and modify the landscape of your own theme parc in the way that you want. Ironically only my second thought was that offgame terrain edit tools as they are included in game engines also allow you to do so. How do they do that?
I saw a few games where you can modify the terrain only at certain positions, probably the vertices of the mesh.
My skills: I´ve got a very basic impression of what game development is like. For roughly one year I´ve taken a look at JMonkeyEngine, then Unity the most of the time, at Unreal Engine about a week and now I go back to JMonkeyEngine and appreciate it more than before. I know how to make Blender models, that was also one seperated part during this year. Projects: None so far. Achievements in Game Engine: One procedurally generated plane with a UV mapped texture, where I raised and lowered single vertices.
This is my first posting here.
Now I want to make the next step. Thank you for your attention
I think you can use an heightmap generated terrain to have great performance and enough precision,but i never had to do something similar so i don’t know if this will fulfill your requests.
use heightmap terrain which is already there, with many vertices
use smarter solution with a custom LOD generator at runtime (e.g. making detail where needed and simplifying again where not needed).
use tesselation (an advanced feature but easy to use). Don’t know if jME has that. You will want to generate normal maps and then tesselate depending on terrain features. OpenGL 4 has tesselation, I think jME 3.1 has something like that too, but don’t know.
make it similar to the old voxel terrains of the 1990s (Comanche etc.).
make it similar to the old voxel terrains but use point sprites (particles).
make it similar to the old voxel terrains in combination with simple heightmap where detail is low.
Yes, see @pspeed post about isosurface and marchincubes there is also the full source code attached. Someone took it and made a game you can find on steam, iirc the name is Rising World.
This could be what you are looking for.
Ah … are you looking for a terrain where you can drill holes and caves into the landscape? Then I told you wrong - my ideas are for terrain that basically has “height” and maximum of one height point at each geographical location on the terrain. If you are just looking for height-based terrain with very fine details in some of the areas then it’s what I wrote. If you want to carve holes, caves, etc. (more than one height point - e.g. two caves crossing under each other) then you need what Riccardo was pointing at - a modern voxel terrain!
Yes, I want indeed have a landscape that allows free modifying, perhaps with tools, including holes and caves. So I wanted to hear your ideas first.
Now my ideas: Using a heightmap-based terrain and make gaps that I fill with a mesh-solution, where a cave should be for example. I don’t know if it’s possible to combine a landscape and a mesh, but that’s one idea.
Another idea is to make the whole landscape with a mesh - but use some algorithm (that I have to develop somehow), that uses very few vertices where it is possible, and creates many new vertices where it is needed.
But if I want a whole smooth landscape, I’ll need quite a few vertices everywhere (because for certain reasons our world is mostly roundish but cubish), so maybe the first idea is the better. I don’t know - is a terrain rendered in another way than a mesh?
Now I have to figure out where to make the next step. Maybe it’s a good idea to familiarize myself with regular terrains in jMonkeyEngine first. No idea so far how to make “gaps” into a terrain and fill it with special meshes if needed.
PS: Ah one idea - if I have a good system that loads needed sectors and unloads unneeded ones, then maybe the first one with meshes could be possible, because it’s more flexible I think.
One important question: Until now I assumed that heightmap-terrains are better in performance than meshes. Is that true? Or is the terrain rendered in another way than a mesh? That could be an important point for the decision.
Much text, but for some reason I’m a person that creates knowledge by writing
Heightmap terrains in jME consist of meshes. The 1990s “voxel terrains” (e.g. Comanche) were no meshes. That is why they ran so fast on these old computers.
Heighmap-based terrain means that you can only have one height-point per geographical position. So that means no cave under a hill (would be three height-points - one for the hill, one for the cave’s ceiling and one for the cave’s floor).
Both the current technology (with meshes) and the 1990s technology (no meshes) use a heightmap. There are terrains that are not heightmap-based (e.g. full voxel terrains like in GSoC 2014 - Voxel Terrain System - #7 by FuzzyMonkey)
My search engine doesn’t really show something useful if I search for advantages of terrains in games.
Do you know what the advantages of terrains are and why they are used in games instead of simple meshes? Performance? Usability? Convenient Features?
Recently I found out, that Unity has a low vertex limit per mesh, that would it make impossible for me to use a mesh for my ingame world. Is it that? Do you know what the vertex limit per mesh is, in jME?
Limit depends on your index buffer limit: 65536 for short (int16), 4 billion (or so?) for int32.
You could just use multiple meshes if there really is such a limit in this other game engine.
I know that such limits exist in other engines (mainly number of bones for animated meshes).
I don’t understand why you say “that would it make impossible for me to use a mesh for my ingame world.”
I’d say: “test it, fool around, see if you make a great game or not” :chimpanzee_closedlaugh:
Yes, a mix of these:
Editors for heightmaps exist, so you can use them or write your own.
The heightmap approach is very simple (low complexity to understand, to code, to edit).
Performance: used to be a thing (e.g. triangle strips and LOD via terrain quads gave boost).
They can be generated at runtime which makes procedural generated landscapes easier.
You can quickly get the height at any point - which makes terrain-to-character-collision easy to calculate (if you don’t use the physics engine for that - which might be a good idea sometimes).
But of course you could come up with your own terrain or generate one in Blender with arbitrary shape (a “arbitrary mesh terrain” instead of a “heightmap based terrain”). Just know that the “number of draw calls” (i.e. number of meshes) is a thing - that means keep number of meshes low for best rendering performance. And know that the physics engine works better if you have fewer meshes (but “physics meshes” this is). So a quad-based terrain is often a good compromise…
Just know that you must watch your exact words. It was difficult to understand you.
Terrains are often meshes, but not of arbitrary shape.
Yes and they can get really big textures when used for terrains (so some clever trick is needed).
But I think the whole point of this thread is that he wants arbitrary shaped terrains.
There are some techniques and articles for that, but it’s a complex matter.
Full voxel terrains like in Voxel Terrain System
might be what you want.
Or you can use Another CSG solution
to cut holes into your landscape.
Or the point is really the smooth-something.
Then he should have a look at “point based rendering” or “raytracing with OpenGL”
and be prepared for some pain and very low frames per second.
Or how about that: normal maps with “parallax mapping”.
This simulates microscopic bumps and dents (small hills and valleys on the mesh).
That would expand normen’s idea of normal map.
Normen also made a youtube video demonstrating that parallax mapping.
Oh okay, so I haven’t read enough about it. Until now, when I heard of voxel terrains I thought to “blocky” games. I never thought that you can make realistic terrains with it. I will read further in that to know what this Voxel approach really is. It could be a really flexible technique to achieve what I want.
Thanks for your answers. It helps me to do the first step into it. That’s an important one.
Yes, “voxel” is not “block” (Minecraft).
You can extract arbitrary shaped landscapes like in: IsoSurface Demo - Dev blog experiment... (released)
This “isosurface demo” might even be converted somehow to be actually useful.
In its current form it has floating rocks in mid-air, which you must remove.
And you will want to change these isosurfaces at runtime to edit the terrain (currently procedural only).
You might ask in that thread of pspeed for details and possible solutions.
The other voxel-thing that I posted earlier was part of the GSoC (Google Summer of Code).
It uses marching cubes to extract arbitrary shape (like pspeed in his isosurface demo - same technique).
Marching cubes can be optimized like in the GSoC thing.
The original marching cubes is still quite blocky (no cubes, but always the same patterns).
I think there are 12 or so possible shapes if you take the original marching cubes.
The optimized versions of that algorithm give you more freedom for the resulting shape.
