First of all, what are the advantages of using glTF and X3D for terrain rather than height maps? Am I right in thinking that the former allows for overhangs, caves, tunnels etc. without needing to add extra meshes?
Just a note: X3D and glTF are not something “different” than height maps. All these things, in the end, are just meshes (mesh = “set of polygons we send to GPU”). X3D has a specialized ElevationGrid geometry, but in the end it is just rendered as a mesh.
There are specialized algorithms for terrain rendering – but we don’t use them in CGE (yet).
Height maps are also nicer (simpler) to edit than meshes. But, as we don’t have terrain editor in CGE yet, this difference becomes moot. (Once we have an editor, I expect it will use height maps but allow to convert to mesh, and to add additional meshes.)
Right now, you can use Blender (or other 3D authoring software) to edit terrains, and choice mesh/height map is then your choice of the workflow. Blender has tools to work with meshes, Blender also has tools with use mesh “like a height map” (proportional editing with locked Z axis, “ANT landscape” plugin), or you can even define terrain as a texture (using texture modifier on a flat mesh).
The advantages of this freedom are as you describe, indeed. Caves, overhangs etc. are not a problem when you have a mesh.
How about varying levels of detail in different sections? i.e. If a hill was flattened for a castle to sit on top, could that flat area use fewer triangles than a bumpy area of the same size?
That is also a task we delegate to 3D authoring software now. In particular, Blender’s “Decimate” modifier does exactly what you describe – it will automatically reduce the geometry in areas that are flat. You can simply use this modified, and export to glTF with “Apply Modifiers” selected, and the CGE will “see” a simpler version of the mesh than what you edit.
Just remember to not use too extreme values for “Decimate” – it requires experimenting, too extreme values can easily make too simplified/ugly mesh.
I also saw in this PDF file that X3D files can be streamed. Does that mean that larger terrains can be dynamically loaded and unloaded as needed?
No, I mean not on an engine level. (Though you could access network and build geometry at runtime. But making it happen automatically is not something in the engine, yet.)
As the https://castle-engine.io/miscella/cge_poster_abstract.pdf says,
“”"
4 Streaming
As we can load and save any X3D graph (to XML or classic encod-ing), the developer has tools to save the 3D world easily.
“”"
So I used “Streaming” to mean “serialization” really, sorry. I wanted to say there that you can save X3D content back to disk.
GitHub - CesiumGS/3d-tiles: Specification for streaming massive heterogeneous 3D geospatial datasets 🌎
I will read about it. I suspect the answer will be “yes, but it is some work – which can be done in your application, but our priorities for 2021 are already quite packed, so it will probably not happen at engine level soon”.
Are there any day and night cycle features built into CGE? I don’t recall any mention of timed movement of dynamic lights, but the docs are a little overwhelming.
How about weather? Is rain, snow, wind etc. available?
Neither of those things are in the core engine. But you can animate lights, you can animate background ( GitHub - castle-engine/darkest-before-dawn: Scary 3D game for Android and standalone, developed using Castle Game Engine , a very very old game now used shader effects to make sky lighter when you progress in the level – but please note that this is a very very old code now, it should not be a good example of engine API ).
So, weather and day/night effects are just something you can do in your application.
). And there is always room to optimize more