We can now read lights from the glTF file.

The lights have to follow glTF extension KHR_lights_punctual. It’s a popular extension supported e.g. by Blender -> glTF exporter. So you can just add lights in Blender, export to glTF, open in CGE, and the lights are there!

This works for “punctual” glTF lights, which are converted in a very straightforward fashion to X3D lighting nodes: PointLight, SpotLight, DirectionalLight.

Demos:

• demo-models/gltf/punctual_lights (open the glTF file there in view3dscene or adjust any engine example to open it using TCastleScene.Load).

• examples/fps_game (level now includes lights designed in Blender and exported to glTF).

• Editor template for 3d_fps_game (as above, the lights are now designed in Blender and exported to glTF).

A number of improvements all across the engine:

1. ApplicationProperties.ShowUserInterfaceToQuit. Useful to hide that “Quit” button on mobile. Used by the editor new project templates for 2D and 3D games.

2. Saving screenshot to the best location, automatically determined: Container.SaveScreenToDefaultFile, lower-level SaveScreenPath. This is important as you cannot assume that your application can write to the current directory when installed. This featue is also already used by the editor new project templates (press F5 in 2D and 3D games).

3. Viewport.TransformUnderMouse represents the current TCastleTransform under the mouse. It’s easier to use than lower-level Viewport.MouseRayHit.

4. The default orientation (important if you use TCastleTransform.Direction property to rotate your models) changed from otUpYDirectionMinusZ to otUpYDirectionZ. The new default makes us work out-of-the-box intuitively with glTF models.

   I wrote a lot of text why this change, although breaking compatibility, makes sense on our page documenting upgrade process from CGE 6.4. See also manual about it.

   If you use TCastleTransform.Direction and want to restore compatibility, just set TCastleTransform.DefaultOrientation := otUpYDirectionMinusZ; somewhere early (like in the Application.OnInitialize callback).

5. Our build tool now does output filtering to hide many useless FPC warnings that occur when using Generics.Collections. This is better than disabling these warnings through FPC command-line options, this way e.g. compiler will still warn about instantiating abstract classes.

6. view3dscene gets a new command-line option --project, automatically used by the editor if you double-click on a scene file in your project. In effect, the castle-data:/ protocol will also work as URL for textures etc. inside X3D, glTF and other files.

7. CGE editor has now context menu when you right-click on files section at the bottom. You can open file manager, delete the file, refresh the directory.

8. For PointLight / SpotLight, radius < 0 means “infinity”. This is useful to convert glTF lights, that may have range equal 0 to mean infinity. So we just convert 0 to -1.

9. New glTF tests:

   • Camera transformations can be animated too in glTF, it works in Blender exporter and CGE as well

   • Invoking glTF animations from X3D TouchSensor

If you click on “New Project” in the Castle Game Engine editor now, it will propose 4 useful templates:

• Empty

• 2D game

• 3D FPS game

• 3D model viewer

I advise everyone, new and old engine user, to check out these templates. You can get the latest engine version from our main page, as usual. Just unpack and run bin/castle-editor executable. (Or you can get the source code from GitHub).

I tried hard to make these templates small but also very useful as a starting point.

They show how to use most important engine features (design viewports, scenes, basic UI in the editor), advise using TUIState to split your code into states, show how to react to basic input (clicking on game field to do something).

Note that “3D FPS game” doesn’t use the item/creatures logic from the CastleCreatures unit, documented in the manual about utilities for typical 3D games. Instead the 3d_fps_game presents much simpler (but also more flexible to extend) approach to implement creature AI, by dealing directly with TCastleScene.

I have implemented a service that allows to easily query about the current user activity (walking, running, cycling etc.) on an iPhone.

Services are ways to enhance your applications with additional code that has platform-specific implementation and may link with 3rd-party library. See more about iOS services and Android services. You declare them in CastleEngineManifest.xml and then just build your application using our build tool.

We now have a new iOS service called activity_recognition. A demo is inside the examples/mobile/activity_recognition subdirecory of the engine source. The demo is cross-platform, however it will not report any activity on other platforms than iOS for now.

The Pascal API is documented in CastleActivityRecognition unit (in particular see TActivityRecognition class).

Hello everyone!

We have a big and important, but simple request. We’ve reworked the handling of the joysticks and gamepads in Castle Game Engine, with a lot of new features that include serious improvement of joysticks API, access to a huge joysticks database by SDL2 with hundreds of joysticks definitions, autodetection of joysticks, detection of connection/disconnection of joysticks, etc.

However, because we have very limited access to hardware, we are unable to test how well those new features work. And therefore we need your help to test if everything is working as expected on different hardware joysticks/gamepads.

You can download and build “joystick” project from “examples” in this fork: https://github.com/eugeneloza-clean/castle-engine. It is not yet merged into CGE master, but of course it will be — that’s why we ask you to help with testing!

Ready precompiled binaries for Windows 64 bit and Linux 64 bit are here.

If you have access to a hardware joystick or gamepad, please use this tool and tell us (e.g. using forum):

1. Your joystick name and operation system (Linux or Windows)

2. Name your joystick was detected in Castle Game Engine

3. If your joystick was correctly autodetected. If not, can you find your joystick in the list of joysticks and try using it?

4. Did the axes and buttons on your joystick corresponded to the axes and buttons displayed in the tool? Note, that the names of the buttons and exact joystick layout may be different, but right stick must be right and upper button must be the upper one.

Thanks a lot!

And thanks a lot to Eugene Loza for developing it all!

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.