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.

1. Thanks to Matthias (Free Pascal meets SDL) we now support “mirrored repeat” mode for textures, for both glTF and X3D models. We also support X3D TTexturePropertiesNode.BoundaryModeS/T/R properties, which allow to request a wrapping mode — clamp, repeat, or mirrored repeat. (see TBoundaryMode)

   The way you would request it in Pascal is by creating and adjusting TTexturePropertiesNode like this:

   TextureProperties := TTexturePropertiesNode.Create;
   TextureProperties.BoundaryModeS := bmMirroredRepeat;
   TextureProperties.BoundaryModeT := bmMirroredRepeat;
   MyImageTexture.TextureProperties := TextureProperties;
   

   You can experiment with the example code that builds a mesh using Pascal to add there TextureProperties as above.

   Example X3D file utilizing it is in demo-models, file texturing_advanced/texture_boundary_modes.x3dv.

   Example glTF file using this is in Khronos glTF-Sample-Models, open glTF or GLB in dir 2.0/TextureSettingsTest.

2. Another related fix is that we fixed the default values of TTexturePropertiesNode.MinificationFilter, TTexturePropertiesNode.MagnificationFilter. By default, they now indicate to use minification/magnification specified in MyScene.RenderOptions, which means that merely adding a TTexturePropertiesNode doesn’t make the filtering uglier. This was fixed in X3D 4.0 some time ago (after my request) and CGE now follows, so we have a saner default.

The documentation about TextureProperties node was extended to mention it all.

We now use GitHub Actions to automatically test and build CGE, in addition to our existing CI with Jenkins.

The main advantage of GitHub Actions for us, from a high-level view, is that they are more friendly to new contributors.

1. They work in every fork (even before you do any pull pequest) automatically.

   Jenkins, OTOH, only processes the main repository and PRs to it. Jenkins doesn’t even know about a fork if you don’t ever make a PR.

2. You will see GitHub Actions execution for each commit, nicely presented in GitHub UI. E.g. if you do PR, and you break compilation with some particular FPC version, you will immediately see which FPC version was broken by this commit (detailed logs are also available).

   This was also true for Jenkins, but the GH Actions results just look immediately more informative, with a breakdown into which job failed. In case of Jenkins, you got short information that a job failed, and you needed access to our Jenkins to see all the details why it failed.

3. Execution of all GH Actions (workflows, that in turn contain jobs) is also publicly visible.

The instructions what to do after each push are in .github/workflows/test-and-pack.yml in repo. This is somewhat equivalent to the Jenkins instructions in Jenkinsfile. You can all see them and propose edits to them.

Our workflow uses the same Docker image as our Jenkins to have the same environment for builds.

We also experimented with setup-lazarus-environment action on plain Ubuntu image — and it worked mighty fine, it was trivial to run a GH Action using FPC/Lazarus on plain Ubuntu without having any custom Docker image. Still, we’d need to extend that “plain Ubuntu” with some tools we need for some automatic CGE tests, and in the end (esp. since as our Docker image is useful for other purposes too, like interactive building and Jenkins) it was easier to just use our Docker image in GH Actions.

To be clear, we still also use our beloved Jenkins, but we’re just exploring an alternative.

• Jenkins still gives us ultimate control over the whole process — configuration on master, ability to setup slaves in any way we like (we right now have Linux, Windows, Raspberry Pi slaves, and will soon resume macOS slave thanks to macStadium). E.g. it’s not a problem to have Windows slave with Delphi 11 Enterprise installled, or Raspberry Pi slave.

• It remains to be seen how much of it is worth “switching over” to GH Actions and how much should remain on Jenkins in the foreseeable future. I know that you can run GH workflows on self-hosted machines, but I suspect with this comes both the trouble and the power inherent in the fact that you maintain these machines, their resources like CPU and disk space, yourself. So for now, at least most GH workflows will be on GH-hosted servers, and we shall see how much this is really problematic to us and how much we enjoy it.

• There’s also a question of “money and control”, unrelated to the technical superiority of this or that solution. GH Actions are free for open-source projects (but the infrastructure is closed and depends on GitHub). Jenkins servers require maintenance (which I usually enjoy) and have a cost (paid by my company Cat-astrophe Games which shares some of the Jenkins infrastructure), OTOH Jenkins remains open-source and under our control forever.

• Well, for now I’m just having fun with more automation tools :), and just experimenting.

Thank you all for today’s meeting!

I think it went good, my only regret is that we want to have more participants! To facilitate this, I’m immediately announcing the next meeting, 3 months from now. Reserve the date! 🙂 Join our Discord right now and click “I’m interested” on the “2nd Open Meeting for CGE Users and Developers“.

Summary:

Things in progress:

1. light-components branch by Michalis, with lights (point, spot, directional) as components that you can visually add/modify in CGE editor; also more flexibility where lights are cast and received; also Phong shading by default, and limit of lights per shape increased to 64.

2. physics branch by Andrzej Kilijański, with colliders and rigid body components as behaviors, that you can add and adjust in CGE editor; also auto-size by default for colliders.

3. Testing GitHub Actions as another CI tool, in addition to our existing Jenkins.

Next plans:

1. Camera and navigation: a few inter-connected new features: 1. camera visible in viewport, 2. design-time and runtime camera and navigation separate, 3. navigate on right-click, like in other game engines (Unity, Unreal).

2. fps_game – AI using behaviors. Setup whole FPS game in editor. light-components branch actually already has example design how it would look like.

3. Publish CGE as a tool on Steam.

4. Assign and override materials in CGE editor.

5. CGE 7.0-alpha.2 release ASAP, CGE 7.0 in 2022!

As announced previously, we’ll have a meeting today, and everyone is invited!

Join Michalis Kamburelis and other Castle Game Engine developers, contributors and users.

The meeting will happen at 16:00 (UTC timezone) on Saturday, 5th March.

Meeting will be on our Discord channel #open_meeting.

• This is the direct link to the event on Discord. Right now you can click Interested button on this event and add it to your calendar (click on … to see the options).

• Simply join Castle Game Engine Discord before the meeting starts, and join that channel.

Please keep your mic muted when you’re not speaking, to avoid the noise 🙂

1. New utility TCastleTransform.RemoveDelayed to remove TCastleTransform but not immediately. This is great if you need to remove some TCastleTransform from children list, but you also iterate over the children list right now.

2. We no longer use windres utility, instead we generate Windows resources in memory using FPC’s units from fcl-res package.

   Our build tool now uses fcl-res units to actually build a resource file in memory, and write the resulting RES file. This means we can write the Windows RES file without the help of any external tool, and without creating some intermediate/temporary RC/manifest files. Everything happens in memory, in a cross-platform way.

   This is nicer for people with Delphi, who want to compile applications without the need to download windres from FPC/MinGW/MSys.

   This is also nicer for people doing cross-compilation from e.g. Linux to Windows. Previously this required Linux version of windres, which needed installation of MinGW binutils on Linux. Now this utility is not necessary.

3. MultiTexture features are now restored in shader renderer. All models from demo-models/multi_texturing and described on our X3D multi-texturing page now work with latest CGE and view3dscene.

1. Long time ago, we had to disable optimizations with FPC on Aarch64 (64-bit Arm) as they were too unstable. But were happy to revert this 🙂 With FPC >= 3.2.2, optimizations on Aarch64 work flawlessly, and so we enable them. This affects Android, iOS and macOS Silicon targets.

   The optimizations will remain disabled if the build tool detects you’re using FPC 3.2.0 and compile to Aarch64. You will see appropriate warning about it in the output. For this reason, we recommend that you upgrade to the latest stable FPC, 3.2.2.

2. Fix to usage of Compressonator on Linux: detect also lowercase compressonatorcli executable, following new Compressonator file naming in Linux.

3. Fix to usage of PVRTexTool. We adjusted compression format names to follow latest naming from PVRTexTool Command Line Options.

4. GameAnalytics SDK usage on Android upgraded to 6.2.6.

Continuing the recent trend of using “just a screenshot of CGE rendering some nice glTF model when I have no better idea for a news image” here are 2 renderings of phones. “Retro Phone” (Sketchfab) by Marek Picheta is licensed under Creative Commons Attribution. “Phone booth” (Sketchfab) by YJ is licensed under Creative Commons Attribution as well.