We’ve been busy in the last months developing our web target! If you haven’t already, check out our video about web support and also a free web game linked in this post

The new web developments:

1. Let’s start with something big: We have developed proof-of-concept portable version of Castle Game Engine editor that has some of our real editor’s functionality, but is fully developed usign our own UI and runs on the web.

   You can try how it works here.

   Please heed the warnings — this is only a “proof of concept”, it misses many features critical for real usage, including building or even saving your project when you reload the page. Use the “real” editor (developed using LCL, available only on desktops) for the time being. It will be a long time (definitely not in 2025, and not for 7.0 release) before this “portable editor” will become useful for real work.

   That said, this “portable editor” shows that it is possible in the future We will be able to just create games, fully in a browser, using Castle Game Engine and FPC. For now, you can create projects, edit views, with our own hierarchy view, object inspector and 3D manipulation. Some developments of it benefit also our inspector invoked by F8 that allows to investigate your view at run-time.

2. OpenUrl is now implemented on the web. it just opens the page using JS window.open.

3. We disable the “context menu” of browser over the HTML <canvas>, which means that using the right mouse button in web applicaitons is now possible.

   We still discourage from relying on the right mouse button in web applications (as it is not available on mobile), but at least it makes sense now on desktops. Note: that on Firefox, users can still use Shift+Right click to open the context menu.

4. We added castle-model-viewer-mobile to web-demos.

   You can view:

   • various pre-packaged 3D files (various formats — glTF, X3D, IFC…)
   • in various models (walk, examine)
   • switch animations, viewports
   • also you can view detailed WebGL information.
   • Cannot open arbitrary files yet — it will come!
5. More 3D demos now run thanks to shader fixes (and some temporary workarounds) on web:
   • Creature behaviors (our simple creature AI, fight with skeletons) (mouse look still TODO!),

   • Eye of Beholder

   • Third-person navigation

   Also we made progress of running more examples, like fps_game, terrain, test_rendering_opengl_capabilities.

6. Shader errors make warnings, not crash, on web. This matches behavior on other platforms (we need extra code to handle this, because on web we cannot rely on catching exceptions).

7. We added ApplicationProperties.CanCatchExceptions to easier handle platforms where this is false (web now).

8. We added Application.MultipleWindowsPossible, to help develop cross-platform apps with a single code. The applications can detect at run-time and change behavior on platforms where only a single window is possible (mobile, console, web).

9. Vampyre Imaging library is now used on web, just like on other platforms, to read some image formats. This adds some formats and has more optimized PNG loading (sometimes 2x over FpImage). Test with image_display example application.

10. New Kraft version was adjusted to work on web too, demo in physics_3d_shooter.

11. We no longer show logs in the page content. (This was using pas2js unit BrowserConsole).

    Now logs are only send to the browser’s console using JS console.log, standard facility how to report logs in web applications. This is better, because

    • browser’s console is not visible by default (user doesn’t see debug things),
    • browser’s console is toggable by developer and most web developers likely know about F12 already,
    • browser’s console has filtering, nice scrolling etc.

    It is still possible to restore BrowserConsole, by

    • uncommenting a symbol in tools/build-tool/data/web/program_js.lpr
    • uncommenting additional HTML things in tools/build-tool/data/web/dist/index.html
12. CastleEngineManifest.xml supports new option for the web HTML generation, <web html_contents="...">. Allows to easily add more HTML content to describe your application. Used by our “The Unholy Society” on web.

13. You can use castle-engine cache --target=web to speedup future compilation. See cache option docs.

14. We use auto_generated/CastleDataInformation.xml on the web, which allows to quickly enumerate and check for existence of data files. (Although our ZIP handling, responsible for our data on web now, can also provide this functionality now.)

15. Our automatic tests can run on the web!

    • We abort some tests on the web – that require platform to be able to catch exceptions.
    • We count all aborted tests.
    • We hide the checkbox “stop at fail” on the web (cannot work since web cannot catch exceptions).
    • The automatic tests is available to run if you want to test it yourself.

      Heed the warning from web page: Don’t be alarmed if a test seems to hang in the middle. The test TTestX3DNodes.TestGltfConversion indeed takes time, around 30 seconds, it knowingly does something quite unoptimal (converting large binary data in glTF to a textual representation in X3D).

16. Lots of updates to the web page documentation and docs linked there. The wasmtime usage docs updated.

17. We optimize now binary size using wasm-opt, which achieves 1/3 size optimization and very noticeable loading speed improvement and very noticeable run-time execution improvement!

    We perform this optimization completely automatically for “release” builds done using CGE build tool / editor. I.e. we just run wasm-opt, if found on $PATH, after FPC made the WASM binary. See section Optional, for extra size/speed optimization: Binaryen (for wasm-opt tool) in docs. We show a simple log what was done:

    wasm-opt found, using it to optimize the release build.
    ...
    Optimized .wasm file in 84.64sec, size decrease 34% (from 43.04 MB to 14.61 MB).
    

    All the demos on web docs have been optimized with wasm-opt now.

18. castle-engine package --target=web makes sense now, packages to zip the dist/ contents.

19. We updated everything to follow FPC rename wasi -> wasip1.

20. We also submitted to fpcupdeluxe a fix for the rename wasi -> wasip1, and it’s already applied to the fpcupdeluxe master branch on GitHub.

    However, be aware that (as of now, 2025-05-24) the fpcupdeluxe release (precompiled binaries) with this fix is not available yet. Which means that we recommend you to take fpcupdeluxe master sources and just build it yoursef. FpcUpDeluxe is straightforward to compile with Lazarus.

21. We also submitted Pas2js fix for TJSProgressEvent.Total, already merged.

22. Fixes using WebGL extensions, enabling extensions like anisotropic filtering on WebGL.

23. This is something we made already in ~February, but didn’t announce it properly yet. Here it goes: Web platform automatically embeds custom fonts, to allow you use font files (TTF / OTF / WOFF) in web applications.

    This is our initial attempt at solving the need “allow to use custom fonts (from TTF / OTF / WOFF) without the need for FreeType”.

    Why do we need to solve it?

    • One reason is that getting FreeType to work on all platforms, including mobile (Android and iOS), consoles (Nintendo Switch right now), web (WebAssembly) is a maintenance burden. It is possible!, the FreeType C code is very portable, and for web there are JS alternatives like https://github.com/opentypejs/opentype.js/ . But it is still additional work.

    • Note: We explored one additional avenue, using “EasyFreeType” bundled with LCL (we could extract the code from LCL). This is using pure Pascal solution, based on a very old FreeType source (they originally wrote FreeType in Pascal) from ~1997. Why did we reject this solution? Well, “very old … from 1997” does not sound good from a security perspective or from feature-set perspective We need support for at least TTF / OTF / WOFF. We need a solution that accounts for more font formats that may appear.

    • We note one more reason: even if we got FreeType working everywhere at zero maintenance cost, this is still not optimal. Loading font from a FreeType requires to do some job (processing the font file to generate a texture). This takes time, and for distance field fonts it takes even longer. It would be better to just distribute the result of the processing (font texture), IOW: move part of the work from runtime to pre-processing.

    Our current solution to this on web relies on the “embed font by generating Pascal code”. For all the TTF / OTF / WOFF files we find in your data, we generate Pascal unit, which is compiled-in into the application (this is invisible to you, we use this unit from auto-generated web library).

    This works… but we identified a number of issues with it.

    • From a high-level view, this goes contrary to our idea to discourage “embedding by converting to Pascal code”. Maintaininig conversion like texture-font-to-pascal is a burden. And we don’t really need to convert font to Pascal code, we only need to convert it to another data file, jus a file in a more friendly format (something we can read without FreeType). IOW, “embedding to Pascal” needlessly tries to solve 2 things (how to distribute, and how to read) when we only need to solve one (how to read).

    • Practical problem: this generation is not influenced by application needs now. The information about the desired optimal font size, character set — is inside the design, in TCastleFont. Not inside the TTF / OTF / WOFF that we process. So we process with some hardcoded size and “common Unicode” character set, for now — but this is not flexible for all uses.

    • Another practical problem: this generation doesn’t work on Windows now. Because build tool on Windows cannot use shared libraries, which is our easy solution to avoid locking project DLLs by accident. We can invent a better solution to this (build tool should not use project DLLs).

    More information about how we plan to solve it: see web docs, find the section about fonts in “Plans (TODOs)” there.

And that’s… not everything. But we will announce some URL handling improvements, which were also done to benefit the web platform, in a separate news post.

Do you like reading super-long news posts with lots of new engine features? If yes, we appreciate your support on Patreon or other ways to donate. Thank you!

We have a number of improvements to announce, so welcome to another “bag of improvements all around the engine” news post! Take a look around, see if you find something you like As usual, all the announced improvements are already part of the latest downloads.

1. TCastleComponentFactory is now a non-visual component registered in the editor, so it’s easier to use it. You can just add the factory instance to your view, point it using TCastleComponentFactory.Url to the design that you want to spawn multiple times, and then from code use TCastleComponentFactory.ComponentLoad to spawn multiple instances of the same thing.

   For examples using TCastleComponentFactory like this, see examples/audio/game_3d_sound (the TntFactory: TCastleComponentFactory) or simple_3d_scanning_fun from conference-pascal-cafe-2025 (the FactoryGamepads: TCastleComponentFactory).

   There are more examples in the engine using TCastleComponentFactory, though some create TCastleComponentFactory by code. Like examples/space_shooter. This approach is also of course fine (it is always OK to create in code what can be done in the editor), it depends on what is more comfortable in given case.

2. We have upgraded Kraft, our physics engine to follow the latest developments done by Benjamin “BeRo” Rosseaux. This brings new optimizations and features (see below).

   The upgrade is quite substantial, from version last synchronized on 2019-08-26 to 2025-03-10. We hope to keep in-sync more often in the future, which should be easier because we isolated most of our customizations to separate files like castlekraft.inc and castleinternalkraftoverrides.pas. Our changes revolve around adjustments to platforms and compilers not supported by Kraft, like web, Delphi on Linux or Nintendo Switch. Some of those rely on linking Kraft with some CGE utilities, e.g. for time.

3. Following the Kraft upgrade, we expose a new method in Castle Game Engine: casting a sphere using physics. See TCastleAbstractRootTransform.PhysicsSphereCast, TCastleRigidBody.PhysicsSphereCast. This is similar to casting a ray, but now you move an imagined sphere in a certain direction.

   This is great for implementing navigation using physics. And it synchronizes our “master” branch with the new physics-based navigation components developed by Andrzej Kilijański. Effectively, we have merged part of this PR into master, with some changes and newer Kraft.

   And yes, this means that eventually merging these new physics-based navigation components is closer now. We still want to do some work first (I outlined next TODOs in this comment), but we are getting there. Of course tests are welcome, and if you’re impatient you can also just try to use the components from the PR

   Aside from this PR, a simple example using PhysicsSphereCast is already available in the engine as part of examples/viewport_and_scenes/collisions.

4. More physics improvements? Sure Our TCastleAbstractRootTransform.PhysicsRayCast, TCastleRigidBody.PhysicsRayCast methods have been extended to support layers. They just get an additional parameter CollisionLayers: TPhysicsLayers, by default AllLayers. Customize it to test for collisions only with a subset of your bodies.

   This also synchronizes our work from 2 branches, the new navigation components and hit-api-upgrade. Our master branch gets new features, and other branches get closer to master

5. Thanks to Vlad (phomm) you can now disable compiling-in support for some formats that you don’t need, to reduce the exe size of your applications. See how to use the CASTLE_xxx_SUPPORT_DISABLE symbols.

   See also PR for more details how much you can gain and why. And also for some thoughts from Michalis “decision paralysis” where I wondered should be do it this or that way

6. We fixed iOS building and TestFairy integration. Ups! Without oversight of the CI/CD such mistakes can happen. I added to TODO to make automatic test of iOS building through GitHub Actions soon.

   This has been done as we work on Mobile Castle Model Viewer version for iOS! Stay tuned for more details.

7. Our build tool unused-data analysis can now optionally remove some unused files.

   Please heed the warnings there before using it! In short, keep your stuff in a version control Which is in general a good idea anyway.

8. We have improved some functionality around images:

   • You can now load image created in code to TCastleImageTransform using TCastleImageTransform.LoadFromImage.

   • We have TDrawableImage.Create overload to create a drawable image with undefined initial state. Just provide the size and format, no need to provide initial contents as TCastleImage instance. Great if you want to fill TDrawableImage with something later.

   • We added new example showing how to draw on an image efficiently and use the result as a texture: examples/images_videos/image_generate_and_use. This demonstrates the 2 above new features, and also presents our recommended way to draw on images using TDrawableImage, with GPU acceleration, with complete rendering features.

9. Finally, we have made UrlEncode and UrlDecode public. Useful to construct URLs to arbitrary files, see TCastleZip.Files for example.

10. BTW, Delphi users, Delphi 12.3 is available and of course our engine was tested and works flawlessly with it. Don’t hesitate to upgrade

OK, and this is not everything. We still have a number of web and IFC improvements to announce in upcoming dedicated posts. And a new release of our Android apps are in-review. Stay tuned for more!

And if you like what we do, please consider supporting us on Patreon. We count on your support to keep the engine development active. Thank you!

P.S. As I didn’t have a perfect image for this news post, I typed “improvements” into Sketchfab and run with it The screenshot shows “Mars One” Mission 3D environment modeled by Admone and displayed using our Castle Model Viewer.

There’s a gift at the end of this news post

Almost a month ago (time flies fast!), I did a presentation at Pascal Cafe 2025, an annual FPC / Lazarus conference organized by Blaise Pascal Magazine. This time, I didn’t pick one topic for my talk, I decided to showcase a number of cool engine features. The common theme is “you can use the engine to make games for any platform, from any data, using any authoring software and workflow”.

Here are the the presentation slides: https://castle-engine.io/pascalcafe2025

After an introduction to the engine, I talked about:

• New web target development. (More information about progress on this in next news.)

• New IFC format support. (Again, we have more to say here, and it deserves a separate news post coming soon.)

• 3D scanning workflow, using your phone and Scaniverse, Polycam, glTF support, some cleanup in Blender and in the end naturally we load the environment into a Pascal application developed using our Castle Game Engine. Room interior, building exterior, asset like a cup or furniture… lots of 3D things with various sizes can be scanned, even with the simple Android / iPhone in your pocket. A very simple result is in this demo application.

• Our mORMot 2 integration example, which we already announced on this blog: Collaborative online editing of 3D world using Castle Game Engine and mORMot2.

Aaaaand…. One thing that I shown, and now I want to share it publicly, is I believe very cool: you can now play “The Unholy Society” online, in your web browser, for free. This is a game originally developer for Steam, Nintendo Switch, iOS and Android. Thanks to our web support, we could just recompile it and it works on the web!

So just play “The Unholy Society” now by clicking here.

Please enjoy it all and we appreciate if you can support us on Patreon. Thank you!

1. Last week I made a course teaching modern Pascal, organized by BSC (Embarcadero branch in Poland). We started from basics (structural and imperative programming, classes) and went on to advanced things (TComponent, various ways to deal with memory management, class references, generics, and more). It total, it was 2 days * 6 hours. Mostly lectures, i.e. “Michalis talking and showing”, but also with some time to do exercises in Delphi.

   I was happy to got very positive feedback from the participants! To let everyone benefit, I’m publishing materials from it:

   • Repository with all (38, as of now) examples: https://github.com/modern-pascal/modern-pascal-course

   • Slides (in Polish): Day 1, Day 2.

   We used Delphi during the course, but I made sure all information and examples is compatible also with the open-source FPC compiler. For this, we used FPC Delphi mode syntax.

   We use GitHub Actions to make sure this is true: all the examples compile with FPC and Delphi. I created a new GitHub organization for this, https://github.com/modern-pascal/, useful to use my self-hosted runners with Delphi across non-CGE projects.

2. To not stop above, I pushed an upgrade to our Modern Object Pascal Introduction for Programmers.

   This updates a few things, most notably adds a section Compilers and FPC “syntax modes” and adjusts all the text and examples to be relevant for Delphi too. Where the feature is FPC-specific (like CORBA interfaces or global operator overloads), we mention it clearly. Just like with Castle Game Engine, we want to support both compilers in all teaching materials.

   The examples in the book still use the FPC ObjFpc mode, with some differences between ObjFpc and Delphi modes. When using FPC, this is the recommended mode (default in Lazarus and CGE projects), so we want to show it, even though it’s a bit more work.

Have fun with modern Pascal! If you like this work, please support us on Patreon.

We’ve a made a new demo project using Castle Game Engine:

Throw a 6-sided dice, using physics, and cheat to make the outcome predictable. Before throwing the dice, you select the desired outcome, and we guarantee the dice will land the desired face “up”.

Full source code and data are available at https://github.com/castle-engine/castle-dice-throwing.

• You can run the demo in a web browser, done thanks to our web target support.

• You can also download a precompiled version for Windows and Linux.

The dice trajectory is truly random, following physics and some initial (random) parameters. So, how is it possible we can guarantee the outcome?

• First we run the physics simulation without rendering it. It’s a very fast process, takes about 1/50 of the second (so you don’t even notice that we do this whole simulation when you press the button “Throw Dice”).

• Then we apply a local rotation to the dice, to change the simulated outcome (face that is up after simulation) into the desired outcome. Since a dice has the same shape (at least for our physics approximation, and for our human feelings; in reality of course the shape is a bit different from each side), no matter how you rotate it by 90 or 180 degrees around one the primary axis, the rotated dice will look equally good during the same trajectory.

• Only then we actually render the simulation. We simply play the previously-recorded physics simulation.

You can look at the source code, naturally, to see how this is done. The ClickThrow method with the nested procedures StartSimulation and RecordSimulation does the core job. If you build the example yourself, in debug mode (toggle it using the editor “Run -> Debug Mode” menu item, or command-line --mode=debug for the build tool), then additional “debug UI” will be visible, allowing you to tweak the physics parameters and also to perform the simulation without prerecording (so the outcome is unknown).

We hope that you enjoy this demo Recording the physics simulation (to later replay it) may have a number of use-cases, we hope that our demo makes it clear how to do it.

If you like this, please consider donating, for example by supporting us on Patreon.

We’re happy to announce a new demo project, showcasing our Castle Game Engine and mORMot 2 working together!

mORMot (1 and 2) is an open-source Pascal framework (just like our engine!) providing networking and database solutions, at a few layers. You can use it for ORM (easily synchronize and persist objects), classic client-server (HTTP REST communication), peer-to-peer communication (like WebSockets), database access and many other things.

We present a demo showcasing that Castle Game Engine and mORMot 2 can cooperate seamlessly, and together achieve something really cool:

https://github.com/castle-engine/castle-and-mormot-collaborative-editing/

The demo presents a collaborative editing of 3D world. Features:

• Multiple clients can edit a 3D world online.
• It’s synchronized using ORM with a server.
• The server in turn stores the world contents in a database (so it survives server restarts).
• Each client can add, remove, modify (move, rotate, scale) 3D objects in the world.
• The changes are immediately visible to all other clients.
• mORMot 2 takes care of all the network communication and database persistence.
• Castle Game Engine takes care of displaying: showing and updating the 3D world, allowing user to move/rotate/scale by nice gizmos (using CastleTransformManipulate), allowing camera movement in 3D.

Instructions to build and run the demo are in the README file. You will need the latest Castle Game Engine and mORMot 2. Latest versions, from GIT master branches of both projects, have been tested today.

In related news, we have recently updated our URL and networking documentation, and this was a great moment to mention mORMot at the latter. Check out new:

• URLs, loading (downloading) and saving
• Multi-player (networking) options

Enjoy, and as always — any feedback is welcome!

We implemented multiple improvements around TCastleTransformReference, making it easier to use, have more options, be more optimal and correct in certain cases. Overall, we think that after these improvements, you will use TCastleTransformReference much more often

The TCastleTransformReference is a component that allows to use the same TCastleTransform multiple times in the viewport. This can imply using the same TCastleScene many times or using a whole hierarchy of TCastleTransform multiple times in one viewport. The technique implies we point to the same TCastleTransform from multiple parents, so the same pointer is present multiple times in the TCastleTransform graph. This is sometimes a very powerful optimization: having a million TCastleTransformReference means you display a million trees, but we still have only one tree in the memory, with one set of GPU resources (VBO etc.). Rendering it will be fast and memory-efficient. On the other hand, this technique also imposes some limits: as all instances are really one object, it must have the same state, e.g. play the same moment of the same animation.

Our engine has other features to cache things between models (even when not using TCastleTransformReference, we cache textures, shaders, we make an effort to cache VBOs too). But using TCastleTransformReference triumphs (in terms of efficiency) everything: everything has to be shared across all references, because they are really just one object underneath.

What we effectively want to achieve by improvements below: encourage you to use TCastleTransformReference more often!

• It’s available with an easy menu item (“Duplicate Linked”) and key shortcut (Ctrl + Shift + D),

• it behaves in a more intuitive way (thanks to ignoring target transformation by default),

• and if you change your mind — you can always “escape” from sharing by using “Edit (Make Independent Copy) Referenced Transform”.

The choice between “Duplicate” and “Duplicate Linked” comes down to answering “will I want to modify this clone”, and if the answer is “probably not” -> then “Duplicate Linked (TCastleTransformReference)” is an excellent choice. So you can use TCastleTransformReference and reap the benefits (i.e. enjoy smaller resource usage) when it makes sense.

Thanks go to DiggiDoggi for providing a lot of useful feedback, testcases and analysis that ultimately resulted in these improvements!

The changes are:

1. First of all, the display of reference (TCastleTransformReference) is no longer affected by the transformation (translation, rotation, scale) of the target (in TCastleTransformReference.Reference). This makes the relation between reference and target more intuitive. You can move target independently of the reference.

   You can adjust this behavior using TCastleTransformReference.ReferenceTransformation: rtIgnoreTransform is now the default, while rtDoNotIgnore restores the old behavior. And sometimes the rtIgnoreTranslation is useful, to ignore only translation but still apply rotation and scale from the target.

2. New menu item “Duplicate Linked (TCastleTransformReference)” is available in both the main menu (in “Edit”) and in the context menu (right-click on source transformation in the hierarchy).

   It creates a TCastleTransformReference that points to the selected transformation object.

   The shortcut is Ctrl+Shift+D, similar to Ctrl+D for the regular “Duplicate”.

   The behavior tries to be natural and nice for duplicating multiple times:

   • The created TCastleTransformReference has nice name, Reference + target name (with target numeric suffix removed, and new numeric suffix added for uniqueness of the reference).

   • Doing it when TCastleTransformReference is selected creates another TCastleTransformReference to the same target, not a TCastleTransformReference to TCastleTransformReference (which is technically possible but often not what you need in this case).

   • New TCastleTransformReference starts with copied transformation (translation, rotation, scale) but it is independent from the target (using new default TCastleTransformReference.ReferenceTransformation = rtIgnoreTransform). So it starts in good place and you can move everything in an obvious way.

   • Overall, the idea is that “hitting Ctrl+Shift+D multiple times does what you expect” (creating multiple references to the same target).

   Moreover, this is deliberately similar to Blenders’s command “Duplicate Linked” (Alt+D). The use-case in Blender is similar: create another instance, but sharing all the properties with the original.

   NOTE: The underlying implementation and capabilities differ between Blender and our engine for this functionality. Blender does “Duplicate Linked” by utilizing it’s separation between “Blender Object” and “Blender Mesh”. “Duplicate Linked” in Blender makes new “Blender Object” that links to the same “Blender Mesh”. Our “Duplicate Linked”, doing TCastleTransformReference, is a more powerful beast: we link to the whole source TCastleTransform, which can be any composition of transformations, scenes, behaviors. Still, we think that despite these differences — the basic use-case is similar.

3. Our manual has been updated to mention the new option: TCastleTransformReference, 3D tutorial with car.

4. Examples using TCastleTransformReference have been adjusted too:

   • examples/fps_game
   • examples/terrain
   • examples/viewport_and_scenes/billboards_blending_in_3d
   • examples/viewport_and_scenes/shadows_distance_culling
5. We have additional options in the editor context menu, when you right-click on TCastleTransformReference instance in the hierarchy.
   • “Edit (Make Independent Copy) Referenced Transform”
   • “Revert To Referenced Transform”

   In effect, you can easily “make real copy” (making the TCastleTransformReference act like a basic TCastleTransform container for that copy, and nothing more) or remove that copy. They work in a consistent way with analogous commands for TCastleTransformDesign, which is good.

6. We fixed a bug (crash in debug mode, missing texture in release mode) when you use TCastleTransformReference in certain conditions. Namely, when some references are within a given light radius, the others are not, then the shaders were not setup correctly. This is now fixed. See issue 664 for details and 3 testcases, one testcase is also part of our automatic tests now.

7. We improved optimzation around the TCastleTransformReference, to better account that when you have multiple references, some of them may be affected by different lights than others. See also the same issue 664.

8. We exposed a new option to configure optimization: TCastleScene.TransformOptimization. It may be beneficial to use this for scenes where you change the translation often, and by a large amount: it will prevent recreating shaders needlessly. Much more details are in the TCastleScene.TransformOptimization and TTransformOptimization API documentation.

9. We fixed TCastleStickToSurface coordinate system (not really connected to TCastleTransformReference, although often used together, both TCastleStickToSurface and TCastleTransformReference make sense for planting trees on a terrain). Now moving the TCastleStickToSurface.Target (like a terrain) makes a proper effect, moving also trees.

10. Making the LOD work no longer requires TCastleSceneCore.ProcessEvents. The displayed LOD level is updated regardless of TCastleSceneCore.ProcessEvents.

11. LODs in scenes references by TCastleTransformReference work now perfectly. Each reference displays the correct LOD level. It’s not a problem that multiple TCastleTransformReference instances point to the same TCastleScene while displaying a different LOD level of this scene.

12. The example examples/viewport_and_scenes/level_of_detail_demo/ has been expanded with a demo of it, the README.md there was also updated.

Enjoy! And if you like what we do, please remember to support us on Patreon or in other ways. Have fun making games!

Enjoy a new video overview describing the latest development around web, ifc and zip support!

The video was supposed to be short, it turned out to be 44 minutes long, and it talks about many details. I hope you enjoy it! If you do, please support us on Patreon or in other ways and use our engine for your next game

Announcing a number of engine improvements from the last weeks:

1. We have a new class for ZIP handling: TCastleZip. Features:
   • Reading ZIP files from any TStream or URL (see networking about our URL support). Just open ZIP by TCastleZip.Open and read by TCastleZip.Read.

   • Create and write ZIP files. Again, with API consistent with our engine, supporting URLs and so on. Just open ZIP by TCastleZip.OpenEmpty and write by TCastleZip.Write.

   • Optionally register a URL handler, to read or write files inside a ZIP archive by just accesing URL with the given prefix. See TCastleZip.RegisterUrlProtocol for an example. Very comfortable to use ZIP throughout our engine. E.g. you can open TCastleScene using an URL that points to a ZIP file, and relative URLs in the scene (e.g. texture names from a 3D format like glTF or X3D) will be automatically resolved to files inside the ZIP archive. Everything else in our engine also in effect supports ZIP, e.g. you can use FileToString or StringToFile to access ZIP files as well.

     Examples are in the linked API docs and in improved examples/network/custom_url_handler.

   • Works with both FPC and Delphi.

   • Has been tested on really wild examples, to make sure it supports out-of-the-box also files with non-ASCII characters (spaces, Polish characters) with all compilers, for both reading and writing. You can see some of the testcases it passes in tests/code/testcases/testcastlezip.pas and tools/build-tool/tests/testtoolutils.pas.

   • Used also internally in our engine, so it’s really well-tested, we rely on the API being functional and implementation being correct. Our build tool uses it, for both packaging web data to zip, and for packing whole application release to zip. Web target also uses it at run-time to read data — castle-data:/ URLs are resolved to a ZIP file that holds your data on the web, by default.

2. Using TAbstractShapeNode.Shading with shWireframe value in Pascal (or shading=”WIREFRAME” in X3D) is now supported for all geometry node types.

   This is a new way for rendering things as wireframe. It looks pretty (quads and other polygons look good in wireframe, as we don’t display diagonals) and it works also on OpenGLES and WebGL (as it doesn’t depend on glPolygonMode).

   See roadmap about our wireframe plans. This a step towards uniform support for TCastleRenderOptions.WireframeEffect, also on mobile (OpenGLES) and web (WebGL).

3. We have added a new simple example examples/viewport_and_scenes/level_of_detail_demo showing how to setup LOD (level of detail) for your 3D models. This is a simple way to optimize rendering, by using simpler geometry for objects that are far away from the camera.

   If you are interested in details, we talk about LOD on the forum thread now too.

4. We support WOFF fonts throughout the engine. Our underlying FreeType already supported them, we just enhanced some filters (in dialog boxes) and improved our documentation to make it official.

   And by the way, our documentation about text and fonts has been improved in various small ways and documentation about localization (translation) is now on a separate page. Hopefully this makes things easier to find.

Do you like what we do? Please support us on Patreon or donate to keep the engine development going! Thank you!