During the last few months, I was working with the Web3D Consortium to bring many material and lighting upgrades to the next version of X3D and of course to our Castle Game Engine.

I’m proud to officially announce the first results of this work, including implementation of many new rendering features in Castle Game Engine!

The initial documentation is summarized on this page – “X3D version 4: New features of materials, lights and textures”. With time, more documentation will appear in CGE, and of course X3D v4 specification will also eventually be available as a definite reference of this. The examples are in my x3d-tests repository, in pbr/ subdirectory.

New features:

• Physically-based rendering (PBR) using the new PhysicalMaterial node.

• Ability to render glTF models with physical materials. Test it by opening any glTF 2.0 sample model with any engine tool. You can e.g. try view3dscene from snapshots.

• Much enhanced classic (Phong) lighting model thanks to the enhanced Material node with lots of new fields for textures (emissiveTexture, normalTexture, specularShininessTexture, ambientTexture),

• More natural “unlit” rendering using the new UnlitMaterial node (very useful for 2D games, and better than previous approach of “Material with only emissiveColor non-zero”, see Why is UnlitMaterial useful for the detailed reasoning),

• Image-based lighting using EnvironmentLight node. This is in-progress now (not yet working).

All of this is implemented in CGE. We get latest X3D features in this area, while also becoming a reference implementation of these X3D concepts.

Backward compatibility

This change also pushed many fixes to the existing lighting shaders, to be pretty and 100% correct (in regards to both X3D 3 and X3D 4). This means:

• SeparateDiffuseTexture is now always “on”. This means that X3D Appearance.texture multiplies only diffuse factor (in Phong shading). So the emissiveColor or specularColor are not affected by the Appearance.texture.

  This was always (in all X3D versions, past and future) required.

  Note that Gouraud shading continues to work as before, because in Gouraud shading there’s technically no other choice: Appearance.texture must multiply everything (the whole result of lighting calculation).

• Using Material with only emissiveColor non-zero behaves now 100% correctly, following X3D equations.

  Previous it was not only an “optimized case of Material”, it also changed the behavior: Appearance.texture was multiplied with emissiveColor (as opposed to multiplying it by diffuseColor). Even when SeparateDiffuseTexture was true, even when Phong shading was used.

  It’s no longer the case.

  Bottom line:

  1. Appearance.texture now always multiplies diffuse factor of the Material, if possible (IOW in Phong shading). Only in Gouraud shading it behaves differently (as then it has to multiply everything).

  2. Use UnlitMaterial instead of Material to have unlit shapes. In case of UnlitMaterial, Appearance.texture always multiplies the emissiveColor. Other things (Color nodes) also behave more naturally for unlit case.

  So it’s simple now:

  • When using Material (Phong lighting model) -> Appearance.texture multiplies diffuseColor
  • When using UnlitMaterial -> Appearance.texture multiplies emissiveColor
  • When using PhysicalMaterial -> Appearance.texture multiplies baseColor

  Color and ColorRGBA nodes are also correct now. They replace the diffuseColor in case of Material — always. Previously, in case of only emissiveColor non-zero they were multiplied and by emissive factor, which was contradicting 2 points of spec. Now they replace the diffuse factor, always (whether “only emissiveColor is non-zero” or not).

Thanks to Eugene Loza work on the Steam release of “The Unholy Society”, you can now detect when joystick is being connected or disconnected.

Simply assign your own event to Joysticks.OnConnect and OnDisconnect.

By default nothing is done. But you can call e.g. Joysticks.Initialize to reinitialize joysticks, thus automatically accounting for the newly connected or disconnected joysticks. A demo of it is inside our examples/joystick/ application.

In games where joystick support is essential, or in “multi-player games on a single device” (many people playing on a single computer with multiple joysticks connected) you can use these events to automatically pause the game, display the player configuration screen etc.

This allows to meet Steam recommendations on joystick behavior.

iOS is the platform used by Apple iPhone and iPad devices. We’ve made a number of improvements to it, caused by upcoming The Unholy Society for mobile:

• New build tool options to build and deploy (“archive” in Xcode terms) iOS application from the command-line (in batch mode). For example, use castle-engine package --target=ios --package-format=ios-archive-ad-hoc to get an IPA file of your application, which can be uploaded to your devices or TestFairy. It is documented in the Castle Game Engine for iOS page.

• Suport for square compressed textures on iOS.

  Note: BTW, castle_engine_auto_generated.xml was renamed to CastleAutoGenerated.xml, following our conventions for other CGE-special files.

• FreeType support on iOS. This means you can freely load font files (TTF, OTF) at runtime on iOS. You don’t need to do anything special to activate it, just load font files as decribed in our manual and it will work on iOS.

We’re busy making view3dscene-mobile and The Unholy Society for mobile 🙂 This caused a number of Android-specific improvements to CGE:

• Important bugfix: glTF loading on Android fixed. To remind, glTF is one of our main 3D model formats.

• Initial alpha versions of view3dscene-mobile are available for download (as an APK file). Our model viewer, view3dscene, is coming to mobile! view3dscene-mobile was developed by Jan Adamec and Michalis Kamburelis long time ago. Due to Michalis being overworked, it still wasn’t released officially. I want to fix it soon!

• Fix for Android reading/writing files from “external storage” (anywhere outside of application data, like SD card): you need to include new service read_external_storage or write_external_storage to have proper permissions to do this on new Android.

• Fix for Android vibrations (demo in examples/mobile/simple_3d_demo/).

We’re proud to announce the release of “The Unholy Society”, a quirky 2D adventure game by Cat-astrophe Games. The game is available right now on Steam (for Windows and Linux) and Nintendo Switch.

The game is using our Castle Game Engine for everything, of course 🙂 The programming part was done by two CGE developers — Michalis Kamburelis and Eugene Loza. And the complete game credits go to the whole Cat-astrophe Games team of course.

This is only the first part of adventures of our hero BonBon. Soon it will be available on mobile devices (iOS and Android) too! Subscribe to Cat-astrophe Games news to comment and learn more.

I added to our Castle Game Engine two very useful features for remote debugging:

1. You can register custom event on the ApplicationProperties.OnLog list. This allows to observe all the CGE logs (including warnings).

   For example you can send these logs to a remote server. This CGE example shows how to do it. It assumes you have your own server with a simple PHP script somewhere (the PHP example script is also included in the sample code).

2. You can integrate your mobile game with TestFairy. It is a mobile testing platform that allows to distribute test applications easily (on both Android and iOS). It can also (optionally) gather logs from testers, their device details (phone model etc.), and even record videos of their playthrough.

   For video and logs gathering in CGE, you need to use an Android service test_fairy and iOS service test_fairy.

   Note that TestFairy is a paid service. But they also have a free plan (Essentials Kit).

Recently I did a little reading about what is “gamma correction” in computer graphics. It’s actually a simple concept with a simple implementation (at least in the basic approach), and I summarized my knowledge here: Gamma correction in X3D and glTF.

I investigated how it relates to the glTF standard (and it’s sample implementation). Of course it will eventually find it’s way into Castle Game Engine and future X3D too.

I made a cool online tool using Castle Game Engine:

Convert your 3D models to X3D!

It allows to

• Convert from any format supported by Castle Game Engine (glTF, X3D, VRML, Wavefront OBJ, STL, Collada, 3DS, MD3, Spine JSON…).

• … into X3D, in XML or Classic (VRML) encoding.

Underneath, it uses tovrmlx3d (command-line application distributed
together with view3dscene).

It’s free to use for everyone. It’s of course open-source, both the tovrmlx3d and view3dscene, and a set of scripts (PHP, Docker and shell scripts) to make it work as an online tool in a secure and reliable way.

More information on the tool page. Give it a shot, test your models on it! 🙂

1. We now support Spine “Free-form Deformation”, which allows to animate (deform) the mesh by moving particular vertexes around. This is a great feature to animate e.g. facial expressions.

   A demonstration how it works in CGE is here. An instructive video how to create FFD animation in Spine is here. We also have a sample model using it inside our demo models, in spine/free_form_deformation.

   Big thanks go to Trung Le (kagamma) for implementing this!

2. Thanks to Andrzej Kilijański, our physics integration is now secure from the “spiral of death” that could occur when the physics simulation takes a long time to calculate (and, in effect, physics would need to account for larger and larger time spans, taking even more time).

   It works automatically, but you can adjust Viewport.Items.PhysicsProperties.MaxPhysicsTicksPerUpdate to tweak it.

3. I made lots of updates to our manual and CGE examples, such that they describe the most advised way to use CGE API (after recent refactors). Almost everything now uses the TCastleViewport and TCastleWindowBase and initializes navigation and camera in a simple way.

As the 2019 is ending, it’s a good moment for a summary. What did we achieve, and what do we want in 2020?

1. First of all, I’m very happy with a huge number of new engine features. This includes CGE visual editor, significant improvements to the important APIs (viewports, cameras, user interfaces), Nintendo Switch support, glTF support.

   This leads me also to our most critical TODO for 2020: We really need to release the next CGE version 7.0, as a “stable” version. Yes, it will be called 7.0 (not just 6.6) — we have a number of new major features (and some unavoidable incompatible changes).

   The release-blocker now is making the “gizmos” to allow to comfortably transform TCastleTransform in the editor.

2. I want to say enormous “thank you” to everyone who contributed to the engine in 2019, or made games using CGE. In particular big thank you goes to the Eugene Loza, Andrzej Kilijański and Kagamma for your pull requests and all the conversations.

   This point also leads me to another TODO: I want to manage our work better. We want to make the best open-source game engine, and I’m not going to stop until we get there 🙂 For this purpose, I created public Trello boards to manage CGE work. If you’d like to join CGE on Trello, just let me (Michalis) know. Everyone is invited.

   Note that Trello is not supposed to replace GitHub issues. GitHub is still great to submit bugs (issues) or PRs. But Trello may be better to organize tasks (by task here I mean ““something that needs to be done”, which isn’t always a bug, and some tasks have complicated dependencies — some tasks are blocked by other tasks, have subtasks etc.). I feel that Trello is great to manage such tasks.

3. Technical most important features to implement in 2020:

   1. Delphi compatibility. You asked for it, and it’s started. It will open us to a whole new pool of engine users (and potential contributors).

   2. Support glTF skinned animations. glTF is becoming the de-facto standard for interchanging 3D animated models. We already support glTF, but we miss this important feature.

   3. Physically-Based Rendering. I’m leading the X3D 4.0 specification changes related to this. We want to finish the spec in January, and later implement PBR in CGE.

   That’s it, in summary. Of course I have more plans 🙂

Have the best 2020! Let’s make good code, and good games. We are open-source, we love writing code, we love telling stories, we love designing fun games. Let’s do it:)