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

cd castle-engine/tools/internal/pack_release/
./pack_release.sh freebsd x86_64

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.

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.