OK, so we have now 3 big things in-progress 🙂

1. I started to learn Snap packaging. It allows to create packages that work on any Linux distribution and has a connected central store of Snap packages where users can find packages. Both open-source and closed-source packages are allowed there, you can browse existing packages and see there’s a lot of good stuff there. You can always upgrade all your packages using sudo snap refresh. The package release is managed by us (i.e. we will be able to just update CGE there, to any version we want, without waiting for others). Personally, I use it on all my Linux installations now (Debian, Ubuntu, Arch Linux) to manage stuff that for this or that reason is not available in distros’ packages.

   The end result should be that we could tell all Linux users “You can install Castle Game Engine using sudo snap install castle-engine“.

   My current efforts are in view3dscene/snap subdirectory. I.e. I’m learning Snap packaging doing a package for view3dscene.

   Note: there’s also Flatpak with very similar goals. We’ll be looking into it too 🙂 My simple practical reason to target Snap first is that it seems to just have more “market penetration” in my eyes, looking at my apps I just see a number of things that are officially available (and regularly updated) through Snap. Ideally, CGE will be on both Snap and Flatpak 🙂

2. In the meantime, the work also continues in new-cameras branch. I’m improving now how does the navigation work, we even have a simple key F that works like in Unity — bring to focus the selected 3D/2D thing.

3. And in the meantime, Andrzej Kilijański works on physics branch. The physics just works cool in the editor now, and it allows us to trivially create new demos. There will be a new 3D and 2D physics demo using the new features.

New features available on master:

1. Nice colors for class name in editor hierarchy. The component name should “stand out” while the corresponding class name is dimmed.

2. Hidden the labels displayed over designer when selecting UI items. These labels were often causing more trouble than gain — as they obscured the actual things you were trying to select/move/resize.

3. Hidden names of subcomponents that you are not really supposed to edit. This applies to subcomponent names, like Perspective subcomponent within a camera.

Moreover, announcing some UI improvements available for a long time now:

1. TCastleButton.Alignment, TCastleButton.VerticalAlignment.

2. Safer look of exception messages and inspector invoked by F8. They will look reliably, always the same, regardless of how you customized the UI.

3. Configurable theme features: TCastleUserInterface.CustomTheme, FallbackTheme, ForceFallbackLook

For this post’s screenshots, I used a few models from Sketchfab. I wanted to test editor on “real” pretty models 🙂

1. Pony Cartoon by Slava Z.

2. 1975 Porsche 911 (930) Turbo by Karol Miklas

3. Abandoned Warehouse – Interior Scene by Aurélien Martel

4. Crypt Location by Bocharova

While we continue work on big features (cameras + navigation, see teaser screenshot in this post; physics in editor), here’s a bunch of smaller engine enhancements you can enjoy already:

1. The <compiler_options> in CastleEngineManifest.xml supports now detect_memory_leaks="true" (detects memory leaks with FPC, ignored by Delphi now), <defines> (best way to specify symbols; they can be put into both DPROJ / LPI reliably).

2. Calling make in CGE main directory (on Unix, or Windows with Cygwin) is now more useful: it will build all tools, including the editor, and place them in bin/. Thus it automates most of compiling from source page — great to quickly recompile CGE from source code.

3. Our Docker image was updated some time ago. Added php-cli, asciidoctor, bumped unstable FPC/Lazarus versions (to have TRegExpr change to UnicodeString).

4. New property TCastleImageTransform.Mipmaps available, to make images look good from a distance.

5. New TCastleTransform.ExistsInRoot property, TCastleTransform.ExistsInRootChanged virtual method. Use this to query whether object exists and all parents exist too.

6. We fixed CastleResources freeing, which could exhibit in crashes e.g. in examples/fps_game/.

7. Deprecated CastleRenderingCamera was causing too much trouble to maintain — removed. It was deprecated for quite some time already.

8. Removed Giftiz integration, www.giftiz.com no longer exists.

We have 2 big features in-progress right now:

1. physics branch, by Andrzej Kilijański, with new features related to physics and more comfortable usage of physics in CGE editor. This includes:
   • AutoSize for physics colliders,
   • rigid bodies and colliders that can be added and configured using CGE editor,
   • ability to test physics in editor at design-time,
   • API to apply physics forces using Pascal,
   • example behaviors that define persistent forces existing in the world.

2. new-cameras branch, by Michalis, with new features for cameras, including better camera and navigation in CGE editor. This includes:

   • TCastleCamera is now a TCastleTransform that exists in the world,
   • camera can have children,
   • camera can be a child of something else (like an animated bone, or mounted on top of a moving car),
   • you can have multiple cameras in the world,
   • we display preview of selected camera,
   • soon: separate design-time and run-time camera/navigation,
   • soon: activate navigation by right mouse button similar to other game engines.

In the meantime, we have small new features in the master CGE branch of editor:

1. New menu item “Help -> System Information” shows

   • Rendering (OpenGL) information
   • Audio (OpenAL) information
   • Other (CGE version, compiler, platform)

   You can view the information and easily save it to file (e.g. to attach to CGE bugreport).

   This is also synchronized with a cleanup in default log output that I did recently. Logs are much less verbose now by default, to encourage you more to use these logs yourself, for your game. The engine is supposed only to log some extremely crucial things (or warnings), to let the logs be most useful for your application. You can still set LogGLInformationVerbose:=true and TSoundEngine.LogVerbose:=true to have verbose logs, they are just shorter by default.

   Note a small trick I used there: as we need to initialize some OpenGL context to get OpenGL info, and we need to initialize sound engine to query it… I decided to have some fun, and not even try to hide it. So the “Help->System Information” plays a simple looping 3D animation and spatial sound, to visually/audibly also communicate that rendering/audio works 🙂

2. You can select multiple components with Shift in the hierarchy view.

3. The overloaded “Design” menu was split into “Design” and “Edit”.

1. You can easily query whether the scene or shape was (potentially, at least partially) visible in the last rendering event. This accounts for both frustum culling and occlusion culling.

   Use TCastleScene.WasVisible, TAbstractShapeNode.WasVisible for this.

   Demo is in examples/viewport_and_scenes/test_was_visible.

   See forum thread for history behind this feature.

2. You can use TCastleRenderOptions.RobustNegativeScale to make lighting work correctly even when combined with negative scale. By default, using negative scale causes trouble for lit objects (as the normal vectors are not coming from the right side) and backface culling. Using the RobustNegativeScale makes them reliable (at a small cost at rendering time).

1. In both glTF and X3D we implement now a feature to “emphasize / deemphasize normal map”.

   In glTF this is in material.normalTextureInfo.scale, in X3D this is in normalScale parameter of Material or PhysicalMaterial.

   The intuitive meaning of it is:

   • value = 1 is the default, regular bump mapping behavior.
   • values < 1 make normal map effect deemphasized (normal vectors in tangent space have XY scaled down, so they go to (0,0,1) in tangent space, as if the normal map was not used). Value = 0 cancels the normal map effect completely.
   • values > 1 make normal map effect emphasized (normal vectors in tangent space have XY larger).

   Demo file is in x3d-tests repo: pbr/enhanced_phong_material/bump_mapping_normalscale.x3dv.

2. glTF camera import was fixed.

   We mistakenly imported slightly wrong field of view and slightly wrong position. Usually these 2 bugs cancelled each other… almost 🙂

3. You can now use IMPORT / EXPORT to selectively take (and reuse as many times as you wish) parts of inner glTF models inside outer X3D file.

   I have documented this with details and examples in new section Interoperability with X3D inside our glTF docs.

I was playing with latest FreeBSD (after listening to an excellent talk about the troubles with FreeBSD which nicely discusses non-technical problems in large open-source volunteer-led project).

Naturally, I tested Castle Game Engine on FreeBSD and it works flawlessly 🙂

I made a release of current CGE for FreeBSD.

This was done just by

The editor, build tool just work, based on FPC and Lazarus that are available in FreeBSD ports (install just by pkg install fpc, pkg install editors/lazarus).

Note: This release is not rebuild automatically, unlike current Linux and Windows releases. But, well, let me know — we can make it rebuild automatically, if there’s interest! Otherwise, in a few weeks, this will be inevitably outdated. Of course you can always rebuild CGE from sources yourself on FreeBSD.

P.S. Don’t worry about low FPS on a screenshot — this was done in a virtual machine.

A recording of my presentation last Tuesday about X3D 4, PBR, glTF, and CGE is available. Watch it here:

The plan of the presentation, along with various links that I mention in the talk, is here.

This the 3rd YouTube movie from me this week. Do you think I can finally become an Influencer? 🙂 My cat says I do a great job!

Enjoy a new video that demonstrates how to set up background (skybox etc.) in CGE editor:

Also, I uploaded our last 2 movies to the Castle Game Engine page on Vimeo. Should we use both YouTube and Vimeo? I will let you decide using the likes and comments 🙂 Here’s the embedded version of the same video on Vimeo:

We’re proud to announce a big new feature in Castle Game Engine: new light components that allow to easily manipulate lights (from the editor and from Pascal code) and a number of related improvements.

I’ve made a video presentation that describes everything, enjoy! And read below the movie for more information.

New features details:

1. New components to define light nodes: TCastlePointLight, TCastleSpotLight, TCastleDirectionalLight. Descendants of TCastleTransform, which can be easily added and manipulated from the editor and from Pascal code.

2. New properties to control lights: TCastleRenderOptions.ReceiveSceneLights, TCastleRenderOptions.ReceiveGlobalLights, TCastleScene.CastGlobalLights.

3. TCastleRenderOptions.PhongShading is now by default true. In short, it means that the lights look pretty. If you want to use Gouraud shading for efficiency, just change Scene.RenderOptions.PhongShading (see TCastleRenderOptions.PhongShading) to false.

   Note: using some features (normal maps, PBR, shadow maps) requires Phong shading anyway, and will override this.

   Note: Do not confuse Phong shading with Phong lighting model.

4. TCastleRenderOptions.DefaultMaxLightsPerShape is now by default a big number: 64 instead of previous 8. Remember that each light has a cost, esp. as we use classic “forward rendering” right now in CGE. So try to limit the number of lights that affect given shape anyway, try to stay well below the 64 limit. The simplest way to do this is to use reasonable Radius on point and spot lights, and limit the number of directional lights that affect all scenes.

5. SpotLight defaults adjusted, matching also X3D 4.0 changes: beamWidth by default is now pi * 3 / 16, so it shows a small falloff until cutOffAngle.

6. Proper calculation and optimization of lights radius when lights are in a different scene than shape they shine on.

Coming soon: TCastleEnvironmentLight and shadows properties on lights, to easily activate shadow maps.

Do you enjoy this feature? Please support us on Patreon.

This weekend news post will cover a few things 🙂

1. I will give a talk about X3D, X3D 4, PBR (Physically-based Rendering), and how it connects with glTF 2.0 and Castle Game Engine this Tuesday, 29th March. Head on to the Web3D site to register, the talk is free and open to join for everyone. Plan of the talk is here.

2. Thanks to Liam Dawe from Gaming On Linux, we have The Unholy Society, developed entirely in Castle Game Engine, running on Steam Deck! See the photo.

3. I was testing PasVulkan on my Linux system.

   This was in preparation for working on Vulkan renderer for CGE. While we don’t plan to add Vulkan support for CGE in 7.0 release, but it is something I definitely want to start in 2022. So I wanted to test and see how PasVulkan works, and we’ll likely use the Vulkan header from PasVulkan: src/Vulkan.pas.

   I made it work on Linux. If anyone else on Linux wants to try — my PR that adds necessary script for Linux is here. It should of course work on Windows too, out of the box.

4. Documentation:

   1. Improved (updated various tasks, clearer list) the roadmap page

   2. Added 2 sections to the Coding Conventions:

      1. Fix warnings (let the compiler help you write reliable code),
      2. Backward compatibility is important; having a consistent (easy to learn) API and useful features is even more important.

   3. Improved (simplified, updated) the macOS page.