In preparation for The Unholy Society on iOS…

1. Packaging of textures specific to given platform by the build tool has been fixed, to really package only textures useful on given platform.

2. The build tool auto-generate-clean subcommand was improved: by default it cleans only unused files in the auto_generated subdirectories. Call the castle-engine auto-generate-clean --all to clean all current auto-generated files.

3. Vibrations on iOS now work.

1. With the help from Valgrind, I made a few significant optimizations to the engine animations, in particular affecting the skinned animation of glTF:

   • We update VBOs during animations much faster (we upload it more directly when possible, without recalculating some useless structures along the way).

   • Some primitives are kept in GPU much better (previously we wasted GPU space sometimes, needlessly duplicating some data instead of uploading it to GPU without transformation).

   • OptimizeExtensiveTransformations and InternalFastTransformUpdate make sense, and are enabled for fps_game, I’ll work on making them “just done by default” ASAP.

2. I have introduced a pool of items for fps_game — more functional and more optimal solution to manage creature instances. The example knight creature in fps_game already uses it.

3. I added a limited support for PBR specular-glossiness parameters. It’s converted to PBR metallic-roughness parameters at import (this means it is limited, e.g. we cannot handle specularGlossinessTexture). It’s far from perfect, but at least the result looks sensible for models that contain only pbrSpecularGlossiness specification, and no pbrMetallicRoughness parameters.

More work on perfect glTF support in Castle Game Engine follows 🙂

Things done lately related to glTF:

1. Our engine demo examples/fps_game/ uses now glTF format for both level and creatures. So you can just export from Blender to glTF, using standard Blender exporter.

   While X3D is still a great scene graph format our engine… But as a file format, glTF today wins, with much more capable Blender exporter, that already supports animations, PBR, textures, normalmaps and more. So we advise this approach.

2. Placeholders (detected for levels defined in level.xml) now account for Blender-> glTF behavior.

3. New orientation value otUpYDirectionZ, following Blender -> glTF behavior and both Blender and glTF conventions of “where is front”.

   This will be default soon. Changing this default will break compatibility, but we really want to make glTF a first-class citizen for us.

4. CastleLoadGltf unit with public GltfForcePhongMaterials. This makes sense for people that want to easily upgrade their pipeline to glTF, but are not ready for PBR yet.

5. New X3D extensions: ValueTrigger (compatible with InstantReality) andShape.collision field (set to "BOX" to collide as a box easily).

6. Saving X3D (in particular after glTF -> X3D conversion), now creates unique names for all X3D nodes if needed. This makes sure that model is saved preserving all DEF/USE references and routes (DEF/USE references cannot be always preserved in case names are not unique; in case names are empty, DEF/USE references cannot be preserved, and also ROUTEs cannot be recorded).

7. Fixed rendering animations defined by resource.xml with one scene for all animations.

8. Fixes to glTF skinned animation transformation in some cases.

9. Fixed normal vectors during glTF animations (normals need to be interpolated too).

10. Optimized animations: Store and use X3D Shape node bboxCenter, bboxSize, don’t recalculate useless octrees when not needed.

I’m working still on optimizing glTF skinned animation speed. It’s still a work in-progress (CGE now does various unnecessary things, causing a slowdown; and we don’t apply skin on GPU yet).

• Sketchfab addon for Blender is lots of fun. You can search and download Sketchfab models straight into Blender and then export from Blender to glTF and open it in our engine. On the side you can see screenshots when I had some fun with it 🙂

  Thank you go to Blender Guru (Andrew Price) for mentioning this cool thing in his newsletter.

• To test performance, I implemented a GltfForcePhongMaterials toggle. It’s somewhat internal now, in X3DLoadInternalGLTF unit, and I don’t know yet whether I will make it “official” (move it to non-internal unit). Toggling it to true will force glTF importing to use old Phong materials, which are uglier, but may be much faster than PBR materials (esp. when you use Phong lighting model with Gouraud shading).

  Time will show whether this will be useful. Anyway, you have the possibility to test it now. You can already use view3dscene from snapshots to toggle it (menu item View -> Load glTF materials as Phong (Faster, Requires Reload)).

Perfect glTF support is now my major task. It quickly became obvious that glTF is just a great asset format for our engine, it works beautifully with Blender and you can find plethora of sample glTF models on the Internet.

• Sketchfab contains a lot of models in the glTF format, both free and paid. I’m having lots of fun testing Castle Game Engine on them 🙂

• Google Poly also has some glTF models. Although most of them are a rehash of glTF sample models from Khronos.

• We have improved rendering of per-vertex colors (Color and ColorRGBA nodes in X3D) for glTF compatibility. The per-vertex colors can now modulate (not only replace) the default colors.

I’m working now on multiple glTF features: finishing PBR, gamma correction, and optimizing glTF animations.

Coldzer0 is working on an integration of Castle Game Engine and QuickJS, a powerful JavaScript engine.

1. Check out this demo how to use JavaScript as a scripting language in your game. It shows how to execute a JavaScript from a Pascal program, and also provide some functions to be called from JavaScript (and handle them in Pascal). So we have a bi-directional integration with JavaScript.

   The QuickJS demo by Coldzer0 is based on SnakeGame by Eugene Loza. In the original game, you control a snake using the keyboard. In the QuickJS demo, you control the snake by implementing an A.I. using JavaScript, like this: data/movement.js. See the demo README for details.

2. As a next step, Coldzer0 is working on exposing Castle Game Engine API in JavaScript. The idea is to allow to code a complete game using JavaScript, if you prefer/know this language better than our Pascal 🙂

   Similar to how other engines expose integrations with various programming languages, we’re open to exposing our APIs in other programming languages than Pascal. To remind, you can already use a subset of CGE from the C and C++ languages. Michalis is happy that more integrations will appear 🙂 The more people can use our engine -> the better for the engine future.

   Here’s a movie showing instantiation and usage of TCastleTimer from JavaScript:

glTF 2.0 skinned animations work! You can export such animations from Blender and a lot of other software.

Sample models:

• Khronos glTF sample models include some skin animations, like CesiumMan, Fox, BrainStem.

• Sample skinned animation created in latest Blender (2.82a). Exported to glTF using standard Blender -> X3D exporter, without any tweaks or custom exporters necessary. Just export and it works 🙂

As a great Blender fan, I was unhappy that since Blender 2.8 release we lost some integration features between Blender and Castle Game Engine. So I decided to fix the situation, and upgrade the support to a new level 🙂

It’s not all finished yet, one more big feature will come (spoiler: skinning in glTF)! But I can already announce various improvements to what you can do. The documentation about exporting to Blender also contains an always-up-to-date instructions.

1. Our castle-anim-frames exporter is fixed now, to work with Blender 2.8.

   castle-anim-frames can also now use the glTF format internally (instead of X3D) to export each frame.

   Unfortunately the effect of castle-anim-frames+glTF is not perfect, because the generated frames are not “structurally equal”, so you will typically want to set “Frame Skip” to “zero”, otherwise animation isn’t smooth. But in effect the files will be huge…

   A solution to the above will be support of skinning in glTF. Working on it!

2. I submitted Blender patches to fix X3D export with modifiers and fix X3D export of “backface culling”. They are in review now.

3. I created some Blender demos (to test exporting to glTF and castle-anim-frames), see https://github.com/castle-engine/demo-models/tree/master/blender . They nicely show that glTF exporter is really good (so we want to use it, and advise it as the best exporter) and already exports various things (like PBR, unlit, normalmaps) correctly to CGE.

4. We now support glTF unlit materials in Castle Game Engine and view3dscene (using glTF extension KHR_materials_unlit, used by Blender -> glTF exporter).

5. I submitted pull request to the Blender glTF exporter to fix exporting without “Skinning” (used by our castle-anim-frames exporter internally).

6. Finally, you can load animation from a set of static files using URL like xxx@counter(3).obj to load xxx001.obj, xxx002.obj, xxx003.obj etc. Blender exporter to Wavefront OBJ allows to export such animations.

1. When you use our auto-generated compressed and scaled textures feature, you can now indicate that certain compression formats are only useful for certain platforms.

   In effect, the textures will not be distributed on other platforms, i.e. castle-engine package --target=xxx (see the build tool documentation) will automatically exclude the unused textures on target platform.

   See the documentation for a precise description and example what to write in your data/material_properties.xml file to use it.

2. Our build tool run command on Unix now supports a “wrapper script”, which allows to e.g. modify environment variables (like LD_LIBRARY_PATH) before running the application.

   An example of such script would look like this:

   #!/bin/bash
   set -e
   # Include current directory in LD_LIBRARY_PATH, to find fmod dynamic library
   export LD_LIBRARY_PATH="${LD_LIBRARY_PATH}:libraries/x86_64-linux/"
   ./play_sounds "$@" # <- replace this with name of your application
   

   (This example is directly from FMOD for Castle Game Engine docs.)

   Executing castle-engine run will simply look for run.sh or <application_name>_run.sh script in the project directory, and executes it if found (instead of executing the compiled binary directly).

3. castle-engine compile and castle-engine package commands support the --ios-simulator option, to include the iOS simulator support. By default this is off, as including simulator support makes build longer (2 more platforms to compile for) and often it is not necessary.

   This is meaningful only when building for iOS, that is with --target=iOS for the build tool.

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