Various improvements: build tool, make, updated Docker image, smaller API updates – TCastleTransform.ExistsInRoot, TCastleImageTransform.Mipmaps

Posted on

Multiple cameras

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.

Comments on the forum ➤

2 big features in-progress, and small editor improvements available already

Posted on

System Information

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”.

Comments on the forum ➤

WasVisible: query visibility of scenes and shapes, RobustNegativeScale: support lighting with negative scales

Posted on

Detect visibility
  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).

Comments on the forum ➤

glTF improvements (normal scale, camera fix), mixing glTF with X3D using IMPORT / EXPORT

Posted on

normalScale in X3D
IMPORT / EXPORT to connect X3D and glTF
  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.

Comments on the forum ➤

FreeBSD build

Posted on

FreeBSD - CGE editor
FreeBSD - CGE editor
FreeBSD - CGE game

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.

Comments on the forum ➤

Physically based rendering (PBR) in X3D, using glTF with X3D 4.0 (recording of my webinar)

Posted on

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!

Comments on the forum ➤

Background (skybox, sky/ground color gradients) in Castle Game Engine – presentation video on YouTube and Vimeo

Posted on

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:

Comments on the forum (3) ➤

Design lights using Castle Game Engine: new light components and related features, with video!

Posted on

Lights in Castle Game Engine editor

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.

Comments on the forum ➤

Web3D webinar this Tuesday, Steam Deck test, documentation updates, PasVulkan tests

Posted on

Unholy Society using CGE running on Steam Deck

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.

Comments on the forum ➤

New Castle Tester – running all engine automatic tests on all platforms (desktop, mobile, Nintendo Switch…) with all compilers (FPC, Delphi)

Posted on

Castle Game Engine Automatic Tests

This screenshot will not win the #screenshotsaturday hashtag, but it took a lot of effort to achieve 🙂

Thanks to Andrzej Kilijański we have a big upgrade to our automatic tests application, available as always in tests/ subdirectory of CGE. Instead of using FpcUnit, the application can now use our own testing framework CastleTester that

  1. Is deliberately very compatible with FpcUnit (in fact, using some of its code).

  2. Tightly integrated with CGE, providing easy UI using CGE to run and display all tests results, and some extra utilities like CreateWindowForTest.

  3. Compiles and runs with both FPC and Delphi. All our tests now pass with both compilers. We made a number of fixes to Delphi support thanks to this (FPC support was being tested and flawless since a long time).

  4. Compiles and runs for all platforms we support. E.g. you can run the testsuite on Android, iOS, Nintendo Switch this way, by building the castle-tester for these platforms — just like any other CGE application.

As always, both Jenkins and GitHub Actions run all these tests automatically after every push. Jenkins even runs them with both FPC and Delphi 11.

Comments on the forum ➤