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.

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;

   1 2 3 4

   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.