We’re busy doing a lot of things 🙂

1. The pull request with our own sprite sheet editor and format is in-progress. Thanks to Andrzej Kilijański!

2. New tutorial is being finished: using CGE editor, from scratch to a complete game. Thanks to Eugene Loza!

3. GPU-based particles in 2D and 3D. See forum posts about GPU-based 3D particle system for CGE (with editor), 2D particle system now supports GPU-based particles. Thanks to Trung Le (Kagamma)!

   Try it out already — I want to make dedicated posts about them, and also think about integrating into engine core in the future.

The new engine features available now as part of regular engine download:

1. CGE editor: Directory operations: create, delete directory from the editor. Proper refresh (to show new dirs on the left, available in both panels, done automatically too when switching applications).

2. CGE editor: Undo for properties changed by a dialog (thanks to Eugene Loza).

3. CGE editor: Easier textual input of TCastleTransform.Scale, you can just type a single float (by Andrzej Kilijański and Michalis).

4. CGE editor: Less alarming exception messages. Better behavior when opening invalid design files.

5. CGE editor: Remembers window state and sizes (thanks to Eugene Loza).

6. glTF: Support STEP interpolation in animations (you can try glTF-Sample-Models/2.0/InterpolationTest/ (from Khronos) to test).

7. glTF: Important reading fix, in particular visible on some Kenney glTF models.

8. Sprite sheets and images loaded to TCastleScene: by default do not force power-of-2 texture.

9. Physics: gravity strength, very useful for 2D game when often 1 unit is not 1 meter (thanks to Andrzej Kilijański).

10. Physics: capsule collider (thanks to Andrzej Kilijański).

11. Transform feedback (TGLSLProgram.SetTransformFeedbackVaryings) with demo in examples/3d_rendering_processing/transform_feedback.lpr (thanks to Trung Le (Kagamma)).

12. Theme images now use TCastlePersistentImage (thanks to Eugene Loza). Updated documentation about theme — the usage is now often simpler.

13. Fixes to handlings URLs with anchors (by Andrzej Kilijański and Michalis).

1. We introduce a new class TCastleBehavior which can be attached to any TCastleTransform to perform some job. You can create descendants of it (or use ready descendants of it in CGE) and override methods like Update.

   It’s a nice way to express some ideas. We right now feature TCastleBillboard and TCastleSoundSource build on top of this.

   The first demo is inside examples/creature_behaviors. Also our template “3D FPS Game” already uses it to define TEnemy class.

   If you come from Unity and are interested “what is the equivalent of MonoBehaviour in CGE” then the TCastleBehavior is now the best answer. Documented on CGE for Unity page.

   This is a work in progress!

   • First of all, editor can and will provide support to add and configure behaviors visually. It’s not a big deal, TCastleBehavior is just another TComponent descendant, our architecture of editor/serialization can handle it.

   • TCastleSoundSource can be even better, and it may become the most advised and easy way to setup sounds in CGE.

   • I’m working on TCastleMoveAttack (in CastleBehaviors unit) to provide out-of-the-box creature AI for games. And it will be a basis of new approach for creature AI in CGE, deprecating current CastleCreatures unit.

2. LoadNode overload that takes a TStream with scene contents, and MimeType as a String.

3. SaveNode, a better name for Save3D, with simpler API (Save3D has way too many overloads, and is now deprecated). With only 2 overloads, to save to URL or to TStream.

4. TImageTextureNode utilities to load images from any TStream or TEncodedImage instance, without the need to load from any URL: LoadFromStream, LoadFromImage.

   This simplifies some use-cases of TImageTextureNode, where you don’t have an URL (supported by CGE downloader) but you have a ready TStream or TEncodedImage with image contents. An alternative approach in this case is to use TPixelTextureNode, but this is sometimes cumbersome, as 1. converting at runtime between TImageTextureNode/TPixelTextureNode is bothersome, 2. serializing TPixelTextureNode to file is very verbose (using X3D SFImage text syntax).

5. I have extended X3D 4.0 to include alpha treatment parameters that correspond to glTF parameters: Appearance.alphaMode and alphaCutoff (in Pascal: TAppearanceNode.AlphaMode and TAppearanceNode.AlphaCutoff). So these are now handled in both X3D 4.0 and glTF in CGE. Testcases: in X3D in my x3d-tests, in glTF in glTF-Sample-Models.

6. New examples/3d_rendering_processing/transform_speed_test/ – speed test of many TCastleTransform instances.

7. Documentation how to implement new Android services.

   The above page is directed at Android services. For iOS, there is a shorter section here. But a lot of concepts are (deliberately) very similar between Android and iOS services.

We proudly present the first alpha pre-release of Castle Game Engine 7.0. It is time to break the long period of waiting since CGE 6.4!

We emphasize that it is a pre-release. We’re still working on a finished 7.0 release, where all the features are polished, all examples are reorganized to show the new approach, all of manual is updated to show editor usage etc. In the meantime, we feel (since a long time now) that what we have is fantastic, and a big step forward since the last CGE release.

If you prefer a video introduction, watch the video presentation embedded on our “Getting Started” page.

The most important new features are:

• CGE editor
• glTF 2.0 full support and realistic rendering upgrades
• Nintendo Switch
• Better API for viewports and cameras in TCastleViewport
• Third-person navigation (with avatar)
• TCastleDownload class, to make asynchronous (non-blocking) downloading
• Load sprite sheets and images to TCastleScene
• Big user interface classes improvements
• Easy serialization of components as JSON
• CastleSettings.xml file support
• castle-data:/ protocol
• TCastleBehavior to enhance TCastleTransform functionality like TCastleBillboard or TCastleSoundSource
• Many optimizations and profiling features
• New screen effects API
• Easy mirrors on flat surfaces
• Localization
• Animation blending improvements
• Many new notable examples
• Android support for Arm64, many new services, upgrades to build infrastructure
• iOS vibrations, GPU compression, IPA building, new services
• Physics detecting collisions, settings and triggers
• Sound backends, FMOD backend, LoopingChannel, sound streaming

The more complete list of changes is here. Even that longer list is just a summary — just browse our news to know all the details.

Along with the new engine, we also release view3dscene 4.0.0 and castle-view-image 2.0.0. These tools are packaged within the main CGE download (they will be automaticaly invoked if you double-click from CGE editor on a 3D scene or image), but you can also download them separately.

• New view3dscene 4.0.0 features include CGE improvements, like glTF support, X3D 4.0, Spine improvements, sprite sheets, animations panel (test animations, with cross-fading, simultaneous animations), dynamic batching and more. It also features a few new view3dscene options like “Edit -> Convert Inline to Group (pulls external content into this model)” and gamma correction configuration.

• castle-view-image 2.0.0 features CGE improvements, like removal of dependency on libgtkglext and libGLU.

1. We had a few methods that needlessly traversed whole TCastleTransform hierarchy. Reworking them was an optimization and also an API simplification (IOW, a “no-brainer” 🙂 ). Changes:

   1. TCastleTransform.Press, TCastleTransform.Release are now only called when TCastleTransform.ListenPressRelease is true.

      The need to process keys in TCastleTransform is very seldom (we only had 2 use-cases for it in the engine, one is in soon-to-be-deprecated CastlePlayer, the other was for X3D key sensors which are not very useful for normal engine usage).

   2. TCastleTransform.CameraChanged, TCastleTransform.UpdateGeneratedTextures, TCastleTransform.VisibleChangeHere virtual methods removed (their use-case is now implemented as an internal mechanism, tailored to factual needs, not needing to be recursive).

   3. TCastleTransform.Dragging removed (not needed, a simple Boolean internal field that tracks “whether something is between PointingDevicePress and PointingDeviceRelease” is enough).

2. CastleWindow GTK backend (default on Linux) can now initialize OpenGLES context using EGL. (Note that it was already possible with Xlib backend previously.)

   This allows to test OpenGLES rendering on desktops, just define symbol OpenGLES at compilation (e.g. by adding it to CastleEngineManifest.xml, or just tweak one line of src/base/castleconf.inc). And make sure you have OpenGLES installed (libgles2 package on Debian and similar).

3. Updated documentation about CastleWindow backends.

4. Optimized bounding box calculation for meshes (boxes are now a little less optimal, but much faster calculated; undefine FAST_MESH_BOUNDING_BOXES if you want to try again the old method).

5. Optimized GeneratedCubeMap with update=NONE (should take zero time, was accidentally consuming some).

6. Fixed LOD node behavior under transformation animation (testcase: navigation/lod_test.x3dv in demo-models).

1. We have new TUIState.WaitForRenderAndCall utility, especially useful to implement loading inside TUIState descendant.

2. Our examples/user_interface/zombie_fighter features now a demo showing loading progress (as a descendant of TUIState, which is our advised approach for loading screens now).

3. Whole examples/user_interface/zombie_fighter was remade to use editor.

4. We have a new UI control, available from code and in editor: TCastleTouchNavigation.

   This shows controls that you can drag to navigate within a viewport. Thus it allows navigation in a TCastleViewport on touch devices. It is a “reboot” of previous TCastleWindowTouch use-case, now expressed as UI control that can have any size, can be attached to any viewport, and in general is consistent with the rest of CGE.

   In a typical usage scenario, you just add it as a child of TCastleViewport, set FullSize=true, set Viewport to the parent. Then control the touch interface. It is easiest to call MyTouchNavigation.AutoTouchInterface := true to let it be automatically assigned. Set MyTouchNavigation.AutoTouchInterface := ApplicationProperties.TouchDevice to let it be automatically assigned, but only on touch devices (that do not have regular keyboard / mouse).

   See TCastleTouchNavigation API docs for more info. An example is in examples/mobile/simple_3d_demo.

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.