Outdoor environments?

I’ve been looking at the CGE documentation and need a little clarification on some features relating to outdoor environments.

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?

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?

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?

If not, is there any chance that a feature such as 3D Tiles could be implemented? Much of its documentation went over my head, but it seems to be an extension of glTF to allow for streaming of large batches of meshes without losing accuracy with large numbers.

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?

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.

https://github.com/CesiumGS/3d-tiles

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 ( https://github.com/castle-engine/darkest-before-dawn , 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.

I’m far from an expert, but as I understand it, terrain built from height maps has elevation markers at equidistant points, whereas a standard mesh could have them wherever needed. However, it is probably easier to create LOD and streaming/paging code for meshes with a regular grid pattern.

I would eventually be handling quite large terrains, so would probably use dedicated terrain software such as World Machine, World Creator or Terragen. I may also import real world map data for a more natural look and to save time.

I checked the features of a few terrain generators and it seems most of them can export as height maps or meshes. I hadn’t thought to check that before as many game engines import height maps by default (even if they are converted to meshes internally).

I have decided to at least try CGE. It fits with at least two projects I have been meaning to start: learning Pascal and using my Raspberry Pi for something.

I’m not sure how difficult it would be to create my dream game with compared to Unreal Engine, Unity or Unigine, but trying something simpler in CGE would give me a better idea of that.

If I reach the stage where I need to (and am competent enough to) add new features to the engine is there currently a way to submit code as an optional plugin or module for others to use? Some of it would not be useful for every game, so it would be nice if there was a way people could enable and disable the code or not download it as part of the core.

1 Like

If I reach the stage where I need to (and am competent enough to) add new features to the engine is there currently a way to submit code as an optional plugin or module for others to use? Some of it would not be useful for every game, so it would be nice if there was a way people could enable and disable the code or not download it as part of the core.

The way we do it now is that, once you have something built “on top” of the engine, you can just create a repository of it that is independent of CGE, and I will very happily link to it on https://castle-engine.io/additional_components.php and post news about it and basically make sure that “everyone interested in the engine is aware of this optional component”.

I could also setup our Jenkins ( https://github.com/castle-engine/castle-engine/wiki/Cloud-Builds-(Jenkins) ) to automatically build, test etc. this optional component.

We don’t have a dedicated CGE-specific way to distribute such “optional components” (e.g. we don’t have something like Unity packages), because there are existing ways to use such additional component in your game:

These options are simple, and it is possible that in the future we will have something more fancy for this, especially if I see many such additional components appearing. It is also possible that some parts of the engine (like the Utilities for typical 3D games) will be “extracted” one day from engine core -> to an optional component in a separate repository. Anyway, it all depends on what happens – if I see many such optional components, for sure I will implement something more fancy than a simple list on https://castle-engine.io/additional_components.php .

1 Like

How smart is the system about including unused code when compiling?

For example, if I created a 2D game that only used sprites, would all the 3D routines for bump mapping, shadows etc. still be compiled into the final executable file?

This is handled by Free Pascal’s “Smartlinking” feature: https://www.freepascal.org/docs-html/current/prog/progse30.html

How smart is the system about including unused code when compiling?
For example, if I created a 2D game that only used sprites, would all the 3D routines for bump mapping, shadows etc. still be compiled into the final executable file?

We don’t have any system here aside from what the compiler does. The code that is used is compiled-in. For FPC, CGE is just a set of units.

In theory, it would be possible to avoid “pulling in” some code (e.g. glTF loader, if you don’t need to load glTF files). But it is not actually happening right now due to organization of units (CastleWindow by itself pulls a lot, and we include all formats loaders). Not including some other things (bump mapping, shadows that you mention) would be very very hard (require reorganization of features, and require extra steps to make them loaded), so it’s not practically possible.

Frankly, this is definitely not something I would like to focus on.

  • We’re already in a better situation than most engines, in that we can at least in theory make it happen in the future, because we just rely on compiler linking mechanism.

  • Other engines don’t care about it at all. With Unity, Unreal, Godot, presumably many others – you have no choice, the entire engine is always pulled in.

  • It’s not a problem for practical games. When your game data easily weights 100 MB, 1 GB etc. – it’s not practical to care about saving 1 MB or such on executable size. If you want to care about your game size, it’s much smarter to optimize data size.

Thanks. I guess if it does turn out to be an issue I can manually change the source code. In theory it would also be possible to do that with Unreal and Godot as the source code is freely available. Last time I checked, Unity source was behind a pay wall though.

I was mostly thinking about the Raspberry Pi. Although I have a Pi 4 with 4 Gb of memory, there are versions with less RAM that I would like to support if possible. Game data would hopefully be less of an issue as much of it should only be loaded when needed.

To optimize on Raspberry Pi (or really anywhere else), avoiding “linking-in code” is not really the solution. You don’t save (noticeable) amount of RAM by just having a smaller executable. You can spend a month of work and get executable that has 1 MB smaller size – and it completely doesn’t matter for an actual application that will inevitably allocate at runtime much much more than 1 MB.

To optimize on Raspberry Pi (or any other devices), it is really important what the code is doing. What is it allocating memory for (your data, effects used by your data), what is it calculating (processing your data, creating necessary resources for your effects, transferring your data to GPU). And in general we’re doing a lot of optimizations around this in CGE all the time (I just scheduled a news “Optimizations and improvements to our renderer” for this Monday :slight_smile: ). And there is always room to optimize more :slight_smile:

But it all comes down to “making the code smarter”. Sure, sometimes you can just cut some code “out”, but in general you cannot do it easily (code depends on other code to compile), and it’s also not really what you need (you need to use time/memory in more efficient way; there are many ways to do it without simply deleting a code that may be useful in other use-cases).