1. We’ve made a big optimization to processing of large worlds (which means: many TCastleTransform in a viewport), that in particular benefits cases when you use shadow volumes.

   This changes how an important rendering code works. We now make 1 pass to collect all the shapes, and reuse results of this pass a few times — 2x without shadow volumes (because we render opaque and then transparent objects), 4x for shadow volumes (was 5x before the optimization, but I managed to completely remove one). This means that “traversing transformations” (which matters for large worlds) is 2x-5x faster now.

   This matters for a number of applications, in particular it is impactful for applications using shadow volumes and non-trivial amount of scenes: pirates demo for Dev Days of Summery 2024 or games like DSRally from DiDi.

   For some technical details, see notes in the GitHub issue and notes about AddRenderEvent (how to make custom rendering code now).

   (This was done over a month ago, but I finally got to announcing it: ) ).

2. We made a big refactor to the shadow maps processing.

   The immediate benefits are: much simpler code (using shadow maps is no longer entangled with texture coordinate generation in ProjectedTextureCoordinate) and fixes for some cases, like using shadow maps and occlusion texture.

   The more long-term benefits: This opens the door to finally improve shadow maps to work cross-scene and be trivial to activate from editor. The way forward is now clear: remove the TShape.InternalShadowMaps, pass the shadow maps when rendering, thus enabling the shadow maps from one scene to another.

3. Small inspector rendering optimizations, and FrameProfiler shows now also rendering time spent in DrawPrimitive2D and TDrawableImage.

4. Nintendo Switch version updated.

   While we cannot publicly share much details, the overview is simple: the very latest version of the engine is available and tested for Nintendo Switch, using the latest software stack for developing games from Nintendo). We also added “Run -> Platform -> Nintendo Switch” to the editor menu, so building can be done from GUI.

5. Improvement: In the design mode (that is, in editor), we always have precise collisions. You no longer need to worry to toggle TCastleSceneCore.PreciseCollisions just to select things in the editor.

6. Fix: Important fix has been pushed for physics. If you modify a transformation of TCastleTransform that has children TCastleTransform, and these children have physics behaviors (colliders, rigid body) then it’s automatically OK now.

7. Fix: Saved JSONs are a bit shorter. No need to write JSON object for a vector / color with default value.

8. Fix: Container.MousePosition during Motion events could be wrong due to recent Motion events collecting. It’s OK now. This also fixes mdRotate option of the TCastleWalkNavigation.

9. Fix: Billboards in multiple viewports are now rendered OK. This also fixes lights gizmos in editor, when using camera preview. This also fixes lights gizmos in editor in terrain demo blinking.

10. Improvements: examples/lazarus/model_3d_viewer for various UI improvements.

11. Improvements: default .gitignore for new projects is improved to ignore some files produced by Delphi.

A recording from my presentation in 2023 is now available on YouTube. This talk is titled “Advanced Castle Game Engine: forms, 3D generation, shaders, customization” and I presented it at ITDevCon conference in Rome almost exactly 1 year ago. I go through important CGE features:

1. You can put engine rendering on Delphi FMX form.
2. You can create and modify X3D nodes using Pascal, to build or modify 3D models — e.g. to display something from external sources (e.g. some machinery state) or to procedurally generate worlds.
3. Compositing shaders using shader effects — original and powerful way to write shader code in our engine.
4. Registering custom components in the editor — a gateway to extending what you can do in the CGE editor.

More:

• Slides from the talk are available here,
• recording of the 1st talk (preceding it and introducing our engine, editor, coding in Pascal, physics) is here,
• all collected resources (slides, recordings, examples) from past conferences are here.

Enjoy, and if you like it please support us on Patreon!

Today’s news is a combo of new things 🙂 I am back from 1.5 weeks of conferencing (first in Germany then in Poland). I have fresh energy, new demo and slides for you to enjoy!

1. First of all, I have merged to CGE master branch an initial design of TCastleMoveAttack component that allows to easily define a creature AI. The idea is to attach this behavior to any TCastleTransform and make it behave like a typical FPS games enemy — it will walk toward (configurable) enemy, it will make a short range attack, it will run away from enemy when low on health etc.

   It cooperates with the TCastleLiving behavior that represents something that has hit points and can be dead / destroyed. You will typically add TCastleLiving to each enemy (otherwise enemy is indestructible) and to the player (camera or avatar, depending on if you make a 1s-person or 3rd-person view).

   It is configurable what is the enemy for each TCastleMoveAttack — they can track and attack any TCastleLiving. So they can attack the player, or fight with each other — lots of fun possibilities!

   There are some important TODOs remaining to be finished in this regard, so I emphasize that the way this component works will change (in particular, the movement will change to follow physics). Do not use it yet for bigger projects — though you can certainly use it already to have some fun 🙂 I also emphasize that this is not the only way to make enemies logic in Castle Game Engine — you can always code your own logic, creating new behaviors (see e.g. “3D FPS Game” template for a starting point).

   The existing documentation for now is in API reference of CastleLivingBehaviors unit and you can take a look what the examples do:

   • examples/creature_behaviors
   • examples/fps_game
   • New demo project from “Zlot Programistów Delphi” conference last week
2. Enjoy the new demo project mentioned above from “Zlot Programistów Delphi”: Demo game using Blender, Sketchfab, Quaternius models, TCastleMoveAttack.

   It’s a complete game with level designed using Blender, level props from Sketchfab, enemies from Quaternius, enemy logic using TCastleMoveAttack and TCastleLiving. The game code shows simple things like game “win” (you “win” the game when you reach a certain invisible box in the level), game “lost” (when player’s life drops to zero), walking with mouse look, shooting at enemies.

   The example is naturally compatible with both FPC/Lazarus and Delphi.

3. Finally, the slides from my presentation at “Zlot Programistów Delphi” 2024 are available.

   Note that they are in Polish, as the event is mostly in Polish. If you have trouble translating anything, and want to learn it, just let me know 🙂 Some of the topics overlap with slides I used for my Cologne lecture so you can find some explanation there too.

I’ve done a presentation about our engine at FPC & Lazarus meeting today in Köln, and I think it went really well. I had more time than usual, so after an introduction to the engine, I could go in more depth about some recently added features, including:

• TCastleComponentFactory (with some cool improvements announced last here, demo usage in examples/space_shooter.)

• Our new Steam integration. More about it in a dedicated news post coming soon!

• Our new (work in progress, but already cool) TCastleMoveAttack component, providing out-of-the-box working creatures AI (so they can walk toward a configurable enemy, attack, run scared, die… typical “FPS-game enemy” logic in a ready tweakable component). See also our roadmap about it. It’s not yet finished, but it does work (on a walk-attack-behavior branch, see new examples/creature_behaviors version there). I showed some initial fun and promising results — see the slides below for screenshots!

The slides from the talk are available here. They are also embedded below:

Cthulhu fhtagn! This news post contains a collection of Cthulhu renderings I posted in recent years — it turns out I post quite a lot of Cthulhu stuff. Usually, when I don’t have a perfect screenshot to illustrate a news post, I just pick something pretty rendered using our engine — it turns out that often this “something pretty” is Cthulhu for me 🙂

Completely unrelated to the screenshots, here are a few new features we’ve added to the engine lately. And if you like what we do please support us on Patreon!

1. Our command-line build tool has a new option unused-data to perform a crude analysis of what data in your project is possibly unused.

   This means that some files inside the data subdirectory of the project have been detected as unused, so they don’t seem to be loaded by code or required by other data files. This means that keeping them inside the data subdirectory is possibly needless. Files inside the data subdirectory (that are not excluded by the CastleEngineManifest.xml rules) are automatically packaged with your application (for example, if you create an Android APK, or a package to ZIP for desktop platforms). If you have some unnecessary files there, then possibly you distribute more than you need, and you could have a smaller application.

   To test this use command-line to enter your project and just execute castle-engine unused-data.

   I emphasize that this is crude analysis. It uses some assumptions that may be wrong, definitely are sometimes wrong, and they may result in errors in both ways (some unnecessary files may be undetected; some detected files may actually be used). Don’t trust this analysis without your own judgement. But it may be useful in some clear cases, when there are easy and obvious ways to optimized your applications size. If some files are indeed unused, consider moving them outside of data (e.g. to subdirectory like data-source) or excluding packaging them by CastleEngineManifest.xml rules, or even removing them (you have them in version control anyway, right?).

   This mechanism allowed to make CGE download size smaller by 30 MB recently 🙂 So yes, it is practically useful (albeit not magic, savings are not that big).

2. The Priority of a sound can be now configured on TCastleSoundSource and TCastlePlayingSound (in addition to being configurable on TCastleSound, as before). See the TCastleSoundSource.Priority, TCastlePlayingSound.Priority, TCastleSound.Priority properties. They are all multiplied, just like Volume and Pitch — see manual about sound for usage description. Thanks go to Dennis Spreen for implementing this!

3. We have extended TCastleComponentFactory.ComponentLoad with a powerful optional mechanism: if you pass an additional instance of any class descending from TPersistent, we will set the published fields of that instance to refer to the new components created by TCastleComponentFactory.ComponentLoad.

   The mechanism is really comfortable to use. It solves a common need when using TCastleComponentFactory.ComponentLoad: you want to access from code a subset of new components.

   See for example how rockets are instantiated in our space shooter example. Consult also API docs of TCastleComponentFactory.ComponentLoad, they discuss everything with example snippets.

4. We have added ApplicationProperties.FreeDelayed utility. As the name implies, it schedules removing a component soon. It’s a bit similar to TCastleTransform.RemoveDelayed with FreeItem=true (that also got important fix by the way), but using ApplicationProperties.FreeDelayed is more straightforward in some cases: you don’t need another TCastleTransform to schedule freeing.

   Example usage is in space_shooter demo.

5. We expose a few properties to determine the quality of generated spheres, cylinders, cones:

   • TCastleSphere.Stacks
   • TCastleSphere.Slices
   • TCastleCylinder.Slices
   • TCastleCone.Stacks
   • TCastleCone.Slices

   Note that there’s no TCastleCylinder.Stacks — cylinder doesn’t need it, it always has one stack.

6. “Copy URL” command is now available in the editor context menu when you right-click on a file in the bottom panel.

   Nice to easily paste the URL into Pascal code to load.

   For files within data, it will use a protocol castle-data:/. Like castle-data:/gamestatemenu.castle-user-interface, castle-data:/level.gltf.

   For files outside of the data subdirectory, it will be reguar file:/... URL with absolute path on your system. Like file:///home/michalis/sources/castle-engine/lynch/demo-images/lynch_screen_1.png. This is naturally less useful: you should not place hardcoded paths in your code, as they work only on your system.

7. Slowly but surely we modernize our joysticks (gamepad) API. We have now separate TJoystick.LeftAxis and TJoystick.RightAxis. Test how they work in examples/deprecated_to_upgrade/joystick demo. See our roadmap for joystick API plans.

A new option at TCastleFont is available that activates distance field font rendering. Using it is trivial: just set up TCastleLabel with custom font in TCastleFont, following the manual about text and fonts. Then toggle TCastleFont.DistanceField checkbox to true.

This is an alternative technique for rendering fonts which results in font having better quality if you “upscale” it, that is: render large font size (e.g. because TCastleLabel.FontSize is large, like 100.0) but the underlying font texture is small (that is: TCastleFont.OptimalSize is smaller, like 30.0).

The font rendered using distance field fonts always remains “crisp” on the edges.

The technique, at least in our current implementation, has some drawbacks — see TCastleFont.DistanceField API documentation. Never the less, it definitely results in a more crisp text look in many practical cases.

An extreme examples of it are available in (maybe even a bit too extreme, it shows actually some issues) is the new example: examples/fonts/distance_field_fonts.

This feature has been implemented largely by the late Eugene Loza. We miss you.

If you want to listen to Michalis in person rambling about Castle Game Engine, now you can!

1. I will be at FPC & Lazarus meeting in Köln, Germany on October 10-11, 2024. My talk plan is here.

2. Just a few days later, I will be at Zlot Programistów Delphi (“Delphi Programmer’s Meeting” in Polish) in Mszczonów (very close to Poland’s capital city Warszawa) on October 15-16, 2024.

3. Let me add a honorable mention: I will not be present at Web3D 2024 conference this September (starts in a few days), but I know that Don Brutzman (thank you!) will mention our engine and tools. So watch the event carefully if you can 🙂

   You are welcome to read my document Castle Game Engine and related tools for content authoring using X3D (and other 3D formats). Don has an impossible task of summarizing this document in about 10 minutes 🙂 (12 pages, and this is a summary of just one thing we do — X3D authoring, not even the actual core engine features).

See you there!

We did a few updates to our terrains, set up by the TCastleTerrain component. You can play with them e.g. by exploring the examples/terrain or separate demo test-high-precision-terrains.

1. The code is simpler and more efficient by internally using the TIndexedTriangleSetNode node for rendering.

   This means always using 1 draw call to render entire terrain (unlike previous TIndexedTriangleStripSetNode rendering mode when Triangulate=true where each strip took 1 draw call; we considered using an OpenGL trick to connect multiple strips into one draw call by using degenerate triangles at strip start/end, but the TIndexedTriangleSetNode seemed more straightforward solution).

   The TIndexedTriangleSetNode also maps directly to GPU (unlike TIndexedFaceSetNode that needs triangulation, unlike TElevationGridNode that needs a proxy).

   The code is also simpler: we have just one rendering path. Previously, we had 2 approaches, and deprecated Triangulate was choosing which one we use.

2. Normals are calculated fast and are good for connected terrain patches.

   This was broken previously (in both Triangulate=true and Triangulate=false modes, although was supposed to work OK in Triangulate=true).

   Now it’s correct (and it is correct regardless of the deprecated Triangulate / new TCastleTerrain.TriangulationIgnoreHeights). Terrain patches will match (regardless of TCastleTerrain.TriangulationIgnoreHeights, terrains will maych even if their TCastleTerrain.TriangulationIgnoreHeights are different).

   Explore additional_noise_offset_test.castle-user-interface in examples/terrain to test this. The screenshot on the side shows 3 TCastleTerrain instances, but you see no weird lighting at the point where they connect, their normals match perfectly.

3. New TCastleTerrain.TriangulationIgnoreHeights property. This determines how we split quads into triangles.

4. Triangulate is now a deprecated alias to TCastleTerrain.TriangulationIgnoreHeights. If you used this to request consistent ordering — then new TCastleTerrain.TriangulationIgnoreHeights is just as good. If you used Triangulate for anything else — then it is probably not needed anymore, new rendering takes the best from previous 2 algorithms.

5. TCastleTerrain.Subdivisions meaning changed.

   They now determine the number of rows in columns in the mesh. E.g. subdivision (4,4) means 16 (4 * 4) quads and 25 (5 * 5) vertexes. This matches the Blender’s “subdivisions” parameter for grids.

Note: This post details changed done last month, even before 7.0-alpha.3 release. Yeah, we have a backlog of announcements 🙂

Next steps in terrains: synchronize, review and merge Base terrain editing tools for Castle Engine Editor pull request from Andrzej Kilijański to introduce a big new feature – terrain editing! Stay tuned and please support us on Patreon!

This is a cool new feature that allows you to use our editor in a bit non-standard way. Use the new menu item “Data -> Export Viewport to X3D, STL” to export the contents of the TCastleViewport to X3D or STL file.

To be clear, the main purpose of our editor remains to save the design to a Castle Game Engine-specific format (*.castle-user-interface, which is a JSON serialization of engine components, that can be later read back using CastleComponentSerialize routines). But this new feature allows to use our editor for other purposes. You can design a 3D or 2D world, export it to X3D or STL, and use it with a plethora of other 3D software. For example, you can:

• Open the X3D file in other X3D viewers, including viewers that can render X3D in a browser. Here’s a non-exhaustive list of software that can “consume” X3D files:
  • X_ITE that can render X3D in a web browser,
  • X3DOM, again able to render X3D in a web browser,
  • FreeWRL,
  • Our Castle Model Viewer,
  • Our Castle Model Viewer Mobile,
  • see X3D Resources for more tools. Many of them are free and/or open-source.
• Import the resulting X3D or STL files into other 3D software, like Blender.

Try it out! Just download the engine, create a new project (or open one of the examples) and use “Data -> Export Viewport to X3D, STL” to see what happens. Try out the new project template like “3D FPS Game”. Add there more engine components (see our documentation and in particular overview of components useful in the viewport) and have fun 🙂

In case of X3D, remember that:

1. The resulting file will refer to the resources (like models loaded in TCastleScene or textures) using relative paths. So you should keep the directory structure of the exported files intact, or adjust the paths in the X3D file manually.

2. The exported X3D files may use some X3D extensions, specific to our engine. You can just remove them as necessary to make the models compatible with other X3D browsers.

3. While you can load the resulting X3D back inside the engine editor, this will be just a single component TCastleScene, not all the components you exported. Solution: If you want to use CGE editor for authoring X3D or other model formats, just keep the original CGE editor files (.castle-user-interface) around, as the “source” version of your 3D / 2D world and export it to X3D as many times as you wish.

All the features supported by the export are listed below:

• It can export to any format supported by the engine, which means X3D (classic or XML) and STL right now. We plan to support also saving to glTF.

• Exported file by default is saved as export.x3d or export.stl in the data directory of your project. This is comfortable, just double-click on it to open it in Castle Model Viewer.

• TCastleScene is exported (as X3D Inline node wrapped in the appropriate Transform node).

• Transformation hierarchy (TCastleTransform) is naturally exported as Transform nodes hierarchy.

• All the lights. E.g. TCastlePointLight is exported as X3D PointLight node.

• All the primitives: TCastleBox, TCastleSphere, TCastleCone, TCastleCylinder are exported as X3D Box, Sphere, Cone, Cylinder nodes.

• Text is exported (TCastleText to X3D Text with FontStyle).

• Cameras (TCastleCamera) are exported as X3D Viewpoint or OrthoViewpoint nodes, depending on the projection type.

• Background (TCastleBackground) is exported as X3D Background node.

• Our navigation components, like TCastleWalkNavigation and TCastleExamineNavigation result in an X3D NavigationInfo node. The X3D node offers a subset of functionality from our engine components.

• Fog (TCastleFog) is exported as X3D Fog node.

• Tiled maps, that is TCastleTiledMap, is exported as a collection of X3D nodes that express given map.

• Terrain (TCastleTerrain, see our demo examples/terrain) is exported.

• Images in the viewport (TCastleImageTransform) are exported.

An additional use-case of this feature is to debug what some engine routines are doing.

• While in some cases we create X3D nodes during the export (e.g. for viewpoints and navigation info, in which case we have somewhat similar but far from identical functionality offered by our components like TCastleCamera and TCastleWalkNavigation)…

• …but in other cases the export just “reveals” the actual nodes used to to render given things (this is the case with e.g. lights, primitives, fog and background).

Have fun with Castle Game Engine and X3D!

Announcing a few more important fixes from the last ~month. As usual, remember that all the bugfixes are available immediately in the latest download. And if you like what we do, we appreciate your support on Patreon!

Bugfixes worth mentioning:

1. Fixed scaling TCastleMeshCollider.

   Scaling the TCastleScene by just setting the TCastleTransform.Scale, like MyScene.Scale := Vector3(100, 100,100) will now affect the physics as it should. The associated TCastleMeshCollider will behave properly, following the scale change. You can test this by changing scale at design-time (in editor) or run-time (from Pascal code) of course.

   I added an interactive demo of this in examples/physics/physics_test_scaled_mesh_collider.

2. Saving of STL files from our tools (like Castle Model Viewer, Castle Model Converter) now accounts correctly for X3D shapes with CW (clock-wise) ordering of vertexes. This is important, as STL files must have CCW (counter-clock-wise) ordering of vertexes. Thanks to Jan Adamec!

3. Water shader important fix (for some GPUs). Affects water in our terrain example, lynch gamejam project, water in demo-models.

4. (Before 7.0-alpha.3 release): Fixed Delphi crash at exit in -dRELEASE.

5. (Before 7.0-alpha.3 release): Fixed editor occasional crash when closing a view with camera preview open (testcase: press Ctrl+W right after selecting the camera in viewport).

6. (Before 7.0-alpha.3 release): Fixed window resolution on Retina screens. We now behave properly on macOS Retina screens, and we render with full resolution (result is “crisp”, not artificially upscaled by macOS), and dragging window between monitors behaves OK too. Big thanks to Jan Adamec!

7. (Before 7.0-alpha.3 release): Fixed clipboard on macOS (with Cocoa backend of TCastleWindow). Cut/copy/paste work as they should. Again thanks to Jan Adamec. They also react to Command + C / X / V, not Control + C / X / V.

8. (This was a hotfix at 7.0-alpha.3 release, initial upload had a bug but was quickly replaced with good one): Fixed “Configure Delphi to use engine” menu item (from our Delphi integration) to handle gracefully paths with spaces.