As I mentioned in the news post 2 weeks ago, lately I’ve been following a trail of reworking and optimizing some renderer code. In particular this is important if you do skinned animation in glTF with bump mapping — which is a very common use-case. New features / optimizations:

• We support now explicit tangent vectors information, by new X3D node Tangent .

• We read from glTF tangents information. So if you export e.g. from Blender a glTF model that has normalmaps, it is beneficial to click the checkbox “Tangents” at export options — this way CGE will not have to calculate this information, so loading will be faster.

• We animate tangents correctly when skinned animation is used.

• We generate tangents once, at load, for the most common case of glTF with IndexedTriangleSet geometry, this makes rendering fast — even if you didn’t export with “Tangents”.

• When tangents are used, they are loaded to the VBO together with coordinates and normals (since they usually all change simultaneously during skinned animation).

• Coordinates, normals and tangents are updated using fast track to VBO: fixed for tangents, faster in case of no tangents.

• Memory usage and loading time of precalculating glTF animation optimized. Our approach is still memory-hungry, unfortunately, esp. if you have long-running animations. You will see in the log messages like "Memory occupied by precalculating "xxx" animation: yyy" if an animation eats more than 10 MB. The true solution for this (already planned, but post CGE 7.0 release) is to move the entire skinned animation calculation to GPU.

In an unrelated news, X3D 4.0 specification is getting finalized, with last public draft here. This includes the modification from Michalis to add PBR and many other material upgrades to X3D, making it also consistent with glTF.

You can now download Castle Game Engine for Raspberry Pi from our main page.

These are ready builds, with the editor, build tool, view3dscene already precompiled, so just download them and run bin/castle-editor and use CGE on your Raspberry Pi. Technically, they are just Linux/Arm builds, and will work on any Linux/Arm system — we simply call them “Raspberry Pi builds” as that is how most people will probably view them.

They are being compiled with the latest stable FPC (3.2.0) and Lazarus (2.0.10). You can however use them with any FPC and Lazarus versions supported by CGE.

• In particular, FPC that is included in current Raspberry Pi OS packages (3.0.4) works without any issues, so you can just do sudo apt install fpc and you’re good to go, CGE will work with it.

• You can also install Lazarus (like sudo apt install lazarus-ide) although you can use other editors to edit CGE applications too.

• All “normal” ways to install FPC/Lazarus on Raspberry Pi work. E.g. you can use fpcupdeluxe if you want FPC/Lazarus versions newer than the Debian packages.

The builds include latest CGE 6.5, automatically updated after every commit. We use a Raspberry Pi hosted by Mythic Beasts as a Jenkins slave (see about our Jenkins).

In time we’ll provide Linux/Aarch64(Arm64) precompiled builds too.

In this video I focus on the engine capabilities to render glTF and X3D content with a lot of graphic features. I show also glTF -> X3D conversion capabilities. This video has been originally made for Web3D 2020.

Two weeks ago I made a presentation about Castle Game Engine at a Debian conference MiniDebConf Online #2 “Gaming Edition”. I think it turned out to be a very nice video introduction to the engine, presenting the editor, creating 3D content in Blender, and even using Docker to create an Android build — all wrapped in 40 minutes. This is the best video introduction to CGE right now, so I really recommend watching it to everyone here 🙂

I added a simple demo to show our Compositing Shaders effects used in practice. The demo is available in examples/3d_rendering_processing/shader_effects.

The demo adds an Effect node by code, to a model loaded from glTF, and also shows how to manipulate custom effect parameter (which maps to GLSL uniform) at runtime. These effects use shader code (GLSL, running on GPU) that is automatically integrated with standard engine rendering shaders.

If you come from Unity then these effects are CGE analogy of Unity “surface shaders” (but much more flexible 🙂 ).

Last week we did an important fix for glTF skinned animation combined with normalmaps. It fixed the problem with incorrect lighting, but also made the code a little slower in case of skinned animation + normalmaps (we had to turn “off” one optimization). To counteract this, I’m reworking a relevant part of CGE renderer, to not only bring the old optimization back, but also optimize it even more, and bring other small improvements.

It’s a work-in-progress, but we already have:

1. Colors per vertex passing optimized (faster copy, 3/4 less data for RGB colors).

2. Custom shader attribute passing optimized (faster copy) and fixed for non-indexed primitives (see demo file).

3. Tangents and bitangents passing optimized (pass 2/3 less data due to not duplicating normal info).

Thanks to our glTF support, you can export to CGE from the latest 3ds Max and Maya versions. We have updated our documentation:

• Detailed instructions how to export from 3ds Max

• Detailed instructions how to export from Maya

Thanks go to Andrzej Kilijański for updating these pages!

Being an open-source engine, done by open-source fanatics, we of course remain committed to perfect Blender support 🙂 As a reminder, our Blender exporting documentation is here.

So we really want to cover all our bases here. Whether you like Blender or a big proprietary 3D modeling software from Autodesk — you can use Castle Game Engine.

An unorganized list of new things implemented in Castle Game Engine lately:

1. I started an important engine example: component_gallery. Right now it’s an extensive demo of TCastleButton possibilities. It will be extended with more pages soon.

2. We made significant image loading optimizations. Loading PNG is now much faster on platforms where we don’t use libpng (Android, Switch). Loading JPG is now faster everywhere.

3. We have a new API for getting/setting metadata on X3D nodes, with example in examples/short_api_samples/metadata/.

4. We bump our Android API to 29, to satisfy latest Google requirements. Our Docker images have been updated to contain the appropriate version by default.

5. AutoSizeToChildren reimplemented to be much more flexible, suitable for any anchor.

6. Selecting of dragon in 2D template fixed.

Thanks to a great work by Andrzej Kilijański, we now have a brand new way of using sprite sheets in Castle Game Engine: you can load sprite sheets to TCastleScene and arrange them within a TCastleViewport.

This means that you can load, display, transform, animate sprite sheets just like all other scenes. Refer to our manual, in particular chapters about loading, displaying and transforming, animating. Everything described there now just applies to sprite sheets.

This also means that you can arrange sprite sheets in CGE editor.

See the sprite sheets documentation for details.

To use this, you need to express sprite sheets in the Starling or Cocos2d format — but we have a plan to make this operation trivial using the CGE editor.

Demo files are in our demo-models repository, explore the cocos2d_v2, cocos2d_v3 and starling subdirectories.

As an additional cool bonus, you can also now load 2D images into TCastleScene. Underneath, we construct a simple textured rectangle that shows the image. This is also extensively documented.

A demo of using the new approach to easily build a game is coming too (you can observe a ticket).

Tomorrow (Sunday, 22 November) at 13:30 there will be a presentation about Castle Game Engine at MiniDebConf Online #2 (see schedule). Come and listen 🙂

Here’s a 37-teaser I made for it: https://michalis.xyz/nextcloud/s/mRjBQEmW429NB8Q.

And in the meantime, watch pretty videos from Enes Geven — upcoming mobile game, using CGE: