1. I made a nice new example to demonstrate our collision checking routines examples/3d_rendering_processing/collisions:

   • TCastleTransform.Move – move, with collision checking and wall-sliding
   • Viewport.Items.WorldBoxCollision – detect collisions with axis-aligned box in 3D
   • Viewport.Items.WorldSphereCollision – detect collisions with sphere in 3D
   • Viewport.Items.WorldRayCollision – detect collisions with ray in 3D

2. Sphere collisions are now more precise (at least when uniform scaling is used for transformations),

3. TCastleTransform.CollisionSphereRadius is visible in the editor,

4. Added various properties to Basic tab on editor,

5. Nicer editor behavior when toggling TCastleViewport.AutoCamera (or changing MainScene when AutoCamera=true), it will now immediately update the camera,

6. Fix editor main window hiding on Windows,

7. Fix editor crash when toggling multiple components property at once (remember: you can select multiple objects with Ctrl in the hierarchy),

8. Improved shadow maps cooperation with X3D 4 nodes.

1. We now read glTF extras data to X3D nodes metadata.

   In practical terms, it means that you can set custom properties in Blender, and then read it back in CGE using MetadataString and similar properties on nodes.

   We read “extras” data from glTF primitives, materials, cameras and transformation nodes. If you use Blender, it means we can read “Custom Properties” from Blender objects, meshes, materials and cameras.

   More pointers how to read custom properties defined in Blender are here. Our demo-models contain examples of Blender models with custom properties, see in subdirectories blender/custom_properties/ and blender/custom_properties_2/. Finally, reworked examples/short_api_samples/metadata shows how to read and write metadata in CGE.

2. Our metadata API was also a bit simplified. MetadataString can now be used easier (doesn’t have an index, use it like Node.MetadataString['my_name']), but we expose MetadataStringArray when you need an array (use it like Node.MetadataStringArray['my_name', 2]).

3. Shape.collision field supports "NONE" value. In Pascal you would set it as MyShapeNode.Collision := scNone.

4. We support a special custom property at Blender mesh: CastleCollision. It can have these values:

   • none — do not collide
   • box — collide as box
   • default — collide as precise triangles

   See the Shape.collision field linked above for more details.

   This way you can easily turn off collisions in Blender, or set collisions to use simple box for complicated shapes. Just set Blender custom property CastleCollision on a mesh.

   Demo usage in examples/fps_game/data/example_level level. The level defined there contains everything collidable + non-collidable water surface in one model, one glTF file, and the water is marked with CastleCollision=none.

5. Improved Detecting Memory Leaks Using HeapTrc documentation (done long time ago by Eugene Loza, now merged with notes previously in optimization manual chapter ).

6. Documented various X3D extensions added lately to have perfect glTF support:

   • Set shape bounding box (Shape.bboxCenter, Shape.bboxSize) (efficiency when animating shapes)

   • Make shape collide as a box or none at all (Shape.collision)

   • Mode to specify how per-vertex colors are applied (X3DColorNode.mode) (colors per-vertex like in glTF)

   • OrientationInterpolator2D (for efficient support of Spine 2D rotations)

   • Trigger multiple outputs of any type when some input is received (ValueTrigger)

1. You can now drag scene files (like glTF, X3D, images…) from the “Files” bottom panel onto a viewport. It will automatically create a TCastleScene instance with proper URL that displays this model.

   The initial translation is determined by the point where you drop the item, with some smart code that should account for both typical 2D (orthographic) and 3D (perspective) needs.

   • In case of 3D (perspective), we try to place new scene origin exactly at the 3D position at the drop point. Or just 10 units in front of the camera (if nothing was hit).

   • In case of 2D (orthographic), we try to place new scene origin 1 unit closer than the object present at the drop point. So the new scene is in front. In case nothing was hit, we place object at the middle of ProjectionNear and ProjectionFar (which will be 0 by default).

   Thanks go to Andrzej Kilijański for doing this!

2. Undo system now works for gizmo operations (moving, rotating, scaling of TCastleTransform) in the editor. Thanks to Eugene Loza!

3. Improved manual page about the editor.

   I am also encouraging everyone to watch Castle Game Engine – introduction to the engine and editor, which is our video introduction from Debian conference, already announced here 🙂 I have embedded this video on the manual page, as well as the getting started page.

1. New component TCastleTransformDesign allows to reference a xxx.castle-transform file inside a parent design. This way you can define a composition of TCastleTransform (including TCastleScene) inside an xxx.castle-transform file, and reuse it multiple times.

   It is similar to the existing TCastleDesign for user interface.

2. New example examples/advanced_editor shows:

   1. Instantiating multiple times UI design with TSerializedComponent, TCastleDesign

   2. Instantiating multiple times transform design with TSerializedComponent, TCastleTransformDesign

   3. Registering custom components (project-specific) to be available in editor

3. Finally, an important bug with using custom components in the editor on Unix was fixed.

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).