New Features in Castle Game Engine 7.0

Visual editor
Village scene with outlines in glTF from Sketchfab ( <a href="https://sketchfab.com/3d-models/ftm-0970f30574d047b1976ba0aa6f2ef855" class="bare">https://sketchfab.com/3d-models/ftm-0970f30574d047b1976ba0aa6f2ef855</a> by Luis Fernandez )
Terrain with water and trees
Tiled isometric map
Tiled hexagonal map in "Strategy Game" demo
Escape from the Universe (Switch) - Japanese edition
The Unholy Society
Open-source, integrated with GitHub, GitLab, Jenkins

This page documents Castle Game Engine 7.0 new features. It’s a work in progress — as we work on making CGE 7.0 ready for release.

1. Plans and Timeline

  • We will make another alpha release in Q1 of 2024, called 7.0-alpha3. The new features are documented below.

  • We plan to release version 7.0 (stable) around the middle of 2024.

    See our roadmap for more long-term goals (not just in 7.0).

  • The most important feature after 7.0 release is the web target. This will be our focus for the rest of 2024. Our hope is to have web target working around Christmas 2024 — seems like a nice Christmas present :)

2. Features released so far

2.1. Already available in snapshot, will be released in 7.0-alpha.3

Not part of the engine release, but still cool to mention:

view3dscene and tovrmlx3d, our tools to view, convert and validate 3D models, also got many improvements.

  • tovrmlx3d now supports:

    • --validate to perform only validation (not conversion).

    • --float-precision to control output floating-point precision.

    • reading from stdin, and --stdin-url to specify input type and base directory.

2.2. Released in 7.0-alpha.2

See full 7.0-alpha.2 release announcement for details.

2.3. Released in 7.0-alpha.1

See full 7.0-alpha.1 release announcement for details.

2.4. Released in 7.0-alpha.1: Expanded version

3. Advise for upgrading: Upgrade your pipeline from X3D to glTF

While X3D is still our scene graph format (which means that everything you render is composed from X3D nodes in memory, which practically means: Pascal classes TXxxNode), our main file format is now glTF, not X3D (which means that we advise to export from Blender to glTF, not to X3D).

The reason for that is practical. glTF is just better now, as a file format:

  • Although X3D offers a lot of features, but the existing Blender -> X3D exporter is extremely poor. It doesn’t support many features (e.g. it cannot export animations, or even textures in the latest version).

  • Moreover, the existing Blender -> X3D exporter doesn’t support features which are CGE extensions or are only in X3D 4.0, like PBR or normalmaps. We had an extended CGE exporter (to X3D) for older Blender, but it was too much burden to maintain. We also had castle-anim-frames exporter, but castle-anim-frames is a poor solution compared to proper glTF skinned animation.

  • Existing Blender -> glTF is actively maintained (by Khronos together with Blender), and supports all the features we like. In particular PBR, all possible textures and normalmaps, unlit materials, animations by transformations, animations by skinning, by morphing, metadata (from Blender custom properties).

  • glTF ecosystem is more active. By this I mean that great quality glTF models can be found e.g. on Sketchfab.

  • glTF is much smarter about "binary data vs text data", which results in it being both simpler and more efficient. glTF uses a binary stream for data that should be uploaded to GPU (in particular everything per-vertex), and it uses JSON stream for other things. This makes glTF files much faster to load. In contrast, X3D text files encode 100% things in text (and thus are often huge and slow to load), unless one uses X3D binary encoding (which is not implemented in CGE, and probably will never be — as it is still poor compared to glTF, as it only speeds up parsing but data still needs to be repacked for GPU).

So it seems reasonable to "just switch to glTF". I can now rely on Khronos to work on Blender -> glTF exporter.

We advise you to use glTF for all your future games, instead of X3D, now.

You can, although you don’t have to, switch your existing games to use glTF too. Of course we continue to support X3D model format in 100%, so you don’t have to. Things to watch out for:

  • In case of Blender, both the X3D exporter and glTF exporters convert (by default) "up" from +Z to +Y. However, they do it in a little different way. In effect, if you design a creature following Blender "front" convention, then it will look toward -Z direction after being exported to X3D, but in +Z direction after being exported to glTF. To be precise, X3D output is rotated 180 degrees around (0,1,0) compared to X3D output.

    • For games using X3D exporter for creatures, call "TCastleTransform.DefaultOrientation := otUpYDirectionMinusZ". This was the default in CGE 6.4, but in CGE 7.0 the default is matching glTF convention, which is "TCastleTransform.DefaultOrientation := otUpYDirectionZ".

    • If you switch your level models from X3D to glTF, remember to adjust any position you manually define (e.g. in code). Adjust it by rotating 180 degrees around (0,1,0). (For positions, you can just negate X and Z coordinates to achieve this.) E.g. camera or lights positions, if you ever define them in code.

  • The glTF exporter will create materials using PBR (physically-based rendering). If you prefer to use Phong lighting model (because it is faster, or because it just looks better in your specific case) then you can define GltfForcePhongMaterials (global variable in CastleLoadGltf unit) before doing any loading. If you don’t -> remember that materials will just look different, and you need to manually adjust them (automatic conversion is not possible, as there are just different equations underneath).

To improve this documentation just edit this page and create a pull request to cge-www repository.

Copyright Michalis Kamburelis and Castle Game Engine Contributors.

This webpage is also open-source and we welcome pull requests to improve it.

We use cookies for analytics. See our privacy policy.