We’re proud to announce a new version 5.0.0 of Castle Model Viewer, previously known as “view3dscene”. This is our tool to view 3D and 2D models in many formats (glTF, X3D, VRML, Spine JSON, MD3, …), and it is powered by the Castle Game Engine.

Along with the viewer, we also release new version of Castle Model Converter (formerly tovrmlx3d), a command-line tool to convert models between various formats.

Underneath, all the released tools use the latest Castle Game Engine version which will soon be released too as 7.0-alpha.3.

New Castle Model Viewer features:

1. A ton of fixes and optimizations coming from using new Castle Game Engine 7.0-alpha.3. Some highlights (engine features that improve the viewer):
   1. Default fonts include a lot of common Unicode characters, so rendering text in local language in most cases will now just work “out of the box”.

      Almost all common glyphs are included, except the languages that have a lot of specific characters or require specific fonts: Chinese, Japanese, Arabic or similar. If you find your language characters missing, let us know, and we will likely “just add a few more characters” to the default font. Unless your language has really a lot of specific glyphs. If in doubt, really let us know, we will talk and see 🙂

   2. MD3 support improvements: multiple animations supported (we load animation.cfg). Choosing skins. Support for tags. Optimized loading.

   3. X3D 4.0 support improvements, e.g. proper metadata containerField handling for both X3D 4 and 3, and added new X3D 4.0 fields to various nodes.

   4. We changed how we deal with duplicate names in the input (like non-unique names in glTF content). We now rename non-unique node names on input (like glTF) to be unique on output (to guarantee to make valid X3D from valid input glTF).

      See docs: glTF files may have non-unique names, but we advise to generate them to be unique; eventually we’ll force them unique at loading. See also more details in the What to do with node names when importing e.g. glTF? document.

      And see demo of glTF including in X3D: avocado_and_exports. Here the Castle Model Viewer allows to work with the glTF file, despite glTF having duplicate names.

   5. Faster on modern systems, due to using only modern rendering features.

   6. Reliable on older systems, due to better tested “fallback mode” for old OpenGL workings.

   7. Fixes for shaders on older ATI GPUs.

2. Prettier panel icons and buttons.

3. Improved menu items to edit materials – you can now reset material, and create any material type (physical, unlit, Phong).

4. New conversion options of Castle Model Converter:

   1. Option to only validate (--validate)

   2. Read from stdin (with optionally providing the base URL to resolve relative URLs using --stdin-url=URL)

   3. Configure output float precision using --float-precision=DIGITS

   4. 2nd parameter to specify output file name (optional; if you still want to save to stdout, you can influence output type using --stdout-url)

   5. Option to save to STL (binary). Also available in our online converter and “File -> Save As…” in Castle Model Viewer.

   6. We plan to add glTF output to the converter soon.

   7. Converter is also packaged in big engine download, just like the viewer already was. So if you download complete engine, then you already have all our tools, no need to download the viewer and converter separately.

5. The viewer is packaged with a few example models, find them in the example_models subdirectory of the package. This is a small representative subset of our demo models.

New names – what, why?

As you see, we also renamed our tools. Summary:

• “view3dscene” is now Castle Model Viewer.

• “tovrmlx3d” is now Castle Model Converter. It’s still distributed along with Castle Model Viewer, it also still has an online version.

• “castle-view-image” is now Castle Image Viewer.

  Note that Castle Model Viewer can also open all supported images, and displays them as fancy rectangle in 3D 🙂 In contrast, Castle Image Viewer has a number of image-specific viewing and editing features (like testing is image tileable, or performing alpha bleeding (to fix blending)).

The new names should better reflect the features (current and planned) of our tools. In particular:

• Rename of “tovrmlx3d” to Castle Model Converter allows us to naturally add more output formats. We added STL, we plan to add glTF output soon. This means that Castle Model Converter will be useful to convert both ways, glTF -> X3D (right now) but also X3D -> glTF (soon!).

• New names make the association with our engine obvious. They communicate “we support all formats supported by Castle Game Engine” which is the point of the tools, they are the “core” CGE tools and will always support everything that CGE supports.

• New names avoid strict “3D” association. While we support many formats that are usually used for 3D, but the viewer (just like the engine) stays universal and supports also 2D formats. For example, 2D spite sheets, Spine JSON, Tiled maps and even simple images. You can also design and view 2D models in traditional “3D formats” like glTF or X3D.

Please support us on Patreon if you find our tools useful. Thank you!

If you find any issues with our tools, please report them using GitHub issues, or just talk to us on forum, Discord or other places.

We’re working on a big release of our tools soon! For this week, we have some new inter-connected developments:

1. First of all, I want our tools to be able to output various model formats, not only X3D. My goal is to be able to write glTF files, with as much features as possible. Thus utilizing glTF as both excellent input (right now!) but also output format (soon!) across our tooling.

   While the glTF output is not ready yet, this week I’ve done a big first step. I added a new trivial output format STL (common file format used in 3D printing) and made our tools capable of this alternative output format.

   This means:

   • The implementation of SaveNode procedure in the engine is now nice and flexible, supporting multiple possible model output formats.

   • Castle Model Viewer has a simpler “Save As” dialog that allows to choose any output format, in particular STL.

   • Castle Model Converter allows and recommends to specify a 2nd parameter, the output filename. The extension of the output determines it’s type. This is usually simpler than outputting to stdout. (But if you still want to output to stdout, you can influence output format using new --stdout-url).

   • Our online model converter can also output STL now.

   • Some old and no longer useful things were removed or deprecated. We removed --force-x3d option from Castle Model Converter (it’s no longer necessary, the output type already indicates when VRML->X3D upgrade is necessary). We deprecated --write-* options of Castle Model Viewer (better use now Castle Model Converter for command-line tasks). We deprecated --encoding, as output type (extension) determines already if it’s X3D classic or XML encoding.

2. Connected to above: we have great new engine API to register custom model formats. Use RegisterModelFormat and TModelFormat to register format that can be saved/loaded to X3D node. 100% of existing formats were remade to use the new system, resulting in simpler code of the engine too.

   The formats you register this way, can be loaded using LoadNode or TCastleSceneCore.Load and saved using SaveNode.

   Here’s an example how to register Wavefront OBJ reader. Use it as a template — but don’t register exactly this format, as we already handle Wavefront OBJ in the engine 🙂 Remember to associate also extensions with MIME type by extending global UriMimeExtensions dictionary.

   function LoadWavefrontOBJ(const Stream: TStream; const BaseUrl: String): TX3DRootNode;
   begin
     ...
   end;
   
   var
     ModelFormat: TModelFormat;
   initialization
     ModelFormat := TModelFormat.Create;
     ModelFormat.OnLoad := {$ifdef FPC}@{$endif} LoadWavefrontOBJ;
     ModelFormat.MimeTypes.Add('application/x-wavefront-obj');
     ModelFormat.FileFilterName := 'Wavefront (*.obj)';
     ModelFormat.Extensions.Add('.obj');
     RegisterModelFormat(ModelFormat);
   end.
   

3. Finally, we also changed our strategy to deal with name duplicates on input (like non-unique names in glTF content). We now rename non-unique node names on input (like glTF) to be unique on output (to guarantee to make valid X3D from valid input glTF).

   The result is that valid glTF on input (which means: with possible non-unique names for glTF stuff) should always result in valid X3D on output (which means: X3D node names have to be unique).

   See docs: glTF files may have non-unique names, but we advise to generate them to be unique; eventually we’ll force them unique at loading. See also more details in the What to do with node names when importing e.g. glTF? document.

   And see demo of glTF including in X3D: avocado_and_exports. Here the Castle Model Viewer allows to work with the glTF file, despite glTF having duplicate names.

A small note (bigger news will come this weekend 🙂 ): If you use GitLab CI, following our recommended setup, and rely on GitLab-hosted runners (available for free for all projects), be sure to update your tags to use new runners:

• For Linux runner, use saas-linux-small-amd64 instead of just linux. More possibilities and info in Hosted runners on Linux GitLab docs.

• For Windows runner, use saas-windows-medium-amd64 instead of just windows. More info in Hosted runners on Windows GitLab docs.

Our Test GitLab CI and Castle Game Engine project has been updated with this change, see latest .gitlab-ci.yml.

A new feature, small but invaluable, for navigating large designs in our editor: easily find component by name.

1. Use editor menu item “Edit -> Find” (Ctrl + F) to see a text box where you can type component name.

2. Typing anything there, like camera, will search and select the first component matching given name (as a substring, ignoring case, so e.g. it will find MyCamera1).

3. Pressing F3 (or using menu item “Edit -> Find Next”) searches for next occurrence.

4. Just press Ctrl + F again to hide the search bar. Or leave it be — you can just ignore it and keep working, it will not change your selection unless you explicitly type something into the search bar or press F3.

This allows to move around in a larger designs much easier. An example is the platformer example – see “play” game design.

We have another feature planned to streamline working in large designs: easily hide behaviors or non-visual components (like fonts). By default, our component hierarchy may seem “deeper” than in other game engines because our hierarchy by default contains also behaviors (which in e.g. Unity are delegated to the object inspector). This has some benefits (for both code, and editor copy-pasting, our “behaviors” are just regular components, you can create/copy-paste/drag then just like e.g. TCastleTransform components; they also have names). But the downside is that our hierarchy tree looks “deeper”. We plan to have checkboxes to just easily hide this complication and/or move it to the right sidebar.

Do you like what we do? Please support us on Patreon!

My presentation of engine mobile features at PascalCafe 2024 has inspired me to polish more our mobile features. There’s something cool coming soon (ups, did I just leak a link to early release only for the bravest testers? yes!).

For today, let me announce a few significant documentation updates around our engine:

1. Our Android documentation has been improved. I also added some screenshots from Android Studio, and this documentation now more explicitly recommends to just install Android Studio (not only Android command-line tools).

   Whole Android Studio is a larger download, but it is just worth it, in our latest tests. Even if you want to develop only CGE / Pascal applications for Android (not using Java or Kotlin), and you have already a favorite IDE (like VS Code, Lazarus, Delphi)… Android Studio is still very useful. It allows to easily install Android SDK (along with accepting Google licenses), allows to use Android virtual machines or mirror real Android device plugged over USB on your PC (very useful!), also contains already the proper Java version.

2. There’s a new documentation page Expose scene elements, like children transformations as TCastleScene children. It documents features, current and planned, of TCastleSceneCore.ExposeTransforms. It is a bit different from most of CGE manual, in the sense that in most of CGE manual, I generally document what engine features already exist and rock. In case of this page, while TCastleSceneCore.ExposeTransforms already exists (and rocks 🙂 ), this manual page also describes some plans about how it will rock even more in the future! I consider TCastleSceneCore.ExposeTransforms an important mechanism to enable a few use-cases in CGE.

3. I improved a bit networking manual chapter, in particular emphasized clearly that TCastleDownload can be used to communicate with backends over HTTP REST and documented the case of known memory leaks with Indy.

4. Our detecting memory leaks documentation is now more compiler-agnostic, spelling out available solutions in both FPC and Delphi.

5. I consolidated various slide shows about Castle Game Engine on slideshare.net. These come from various conferences where I spoke about CGE.

That’s not the end 🙂 I also wanted to point your attention to some wiki resources about Pascal I wrote in 2023. You can treat them as somewhat “companion” information to our Modern Object Pascal Introduction for Programmers book — maybe not good enough / not precise enough to be included in the book, but may be useful information / advise for all developers using modern Pascal:

1. Always use FreeAndNil

2. How to solve EAccessViolation error in Pascal

3. What are range and overflow checks (and errors) in Pascal

Happy reading everyone! 🙂 Do you like to read? Or maybe you prefer to make games? 🙂 Or both? Please support us on Patreon!

We’ve made a number of improvements to our CastleClientServer unit and the associated examples in examples/network/tcp_connection. The CastleClientServer allows to use a “classic” TCP/IP server/client architecture to communicate in Castle Game Engine applications. It relies on Indy — FPC developers will need to download it.

The examples in examples in examples/network/tcp_connection show a simple client and server that can exchange messages, as strings, reliably. The server and client(s) may run on any system (desktop, mobile) as long as they are reachable over the network — e.g. make sure you have the firewall properly configured on the server device.

Improvements done:

1. Big upgrade to the client/server samples in examples in examples/network/tcp_connection. UI is now designed using editor. Code is simpler and follows CGE conventions (all relevant code inside a view, TViewMain). We added buttons to stop server/disconnect the client, to test this flow. We show current state, including IsConnected.

2. Fixed CastleClientServer to be able to send messages with international characters (beyond ASCII).

3. Fixed IsConnected value for both server and client on Android — it was broken, now it’s good. As a consequence, also fixed sending messages from Android clients.

4. Fixed clean client disconnection/destruction on desktops (Linux, Windows, actually anything non-Android).

We’ve also tested various scenarios, including

• Android and Windows: Communication in both directions works. Both can be server and client(s).

• Android and Linux: Communication in both directions works. Both can be server and client(s).

Note that our engine is not committed to any particular networking solution. We use URLs and we have TCastleDownload for HTTP(S) requests, but that’s it for “core” engine features. We leave it open how you can make multi-player games, we just show you various examples — using Indy client/server discussed above, using RNL (see our demo not-quake), and we plan Nakama integration. See the networking manual chapter for an overview.

My presentation from International Pascal Congress in Salamanca, 2023 titled “Developing games and graphic visualizations in Pascal”, has just been published on YouTube (also embedded below)!

I encourage to watch it, I think it turned out quite nicely 🙂 It is a bit different from my usual presentations — it’s not only about Castle Game Engine (though I did feature our engine), I talked in general about rendering, about features a good game engine should have (IMHO!), about low-level and high-level Pascal rendering libraries, about Apus Game Engine (by Ivan Polyacov) and Benjamin Rosseaux (PasGLTF, PasVulkan, Kraft, RNL…) work. I just had an hour to talk about everything — so necessarily I go over many topics quite fast, but I hope you will enjoy the ride 🙂

Slides from this talk are available here since a long time, along with my positive notes from the conference. See conferences page.

Watch the talk:

I had a great time at Pascal Cafe conference today!

I made a presentation introducing Castle Game Engine and then discussing some details about mobile (Android and iOS) development with CGE.

You can watch:

1. Presentation slides

2. Sample application (for slides “Physics and Coding” section)

We have a new example examples/viewport_and_scenes/mesh_update that may be quite useful to many developers. It shows two approaches to update a mesh at runtime. This has a lot applications — e.g. you may want to animate / deform the mesh following some algorithm or allow for some user interactions or game events to change the mesh.

Quoting from the example README:

This example demonstrates how to dynamically (as often as possible, to reflect e.g. time passing by) update the mesh of a 3D object, while still being efficient. There are 2 approaches:

1. Call TCoordinateNode.SetPoint as often as you want, e.g. from view’s Update method.

   In this example, every TViewMain.Update increases Time and then calls TViewMain.UpdateCoordinateNode. The TViewMain.UpdateCoordinateNode updates the coordinates of the 3D object, the Time affects the waves shape.

   The point here is that TCoordinateNode.SetPoint is very efficient. It only updates the necessary rendering resource (VBO contents in OpenGL) and doesn’t do any unnecessary work (doesn’t rebuild anything, doesn’t recreate any resource from scratch).

2. Use shaders. You can use our shader effects to add a vertex shader that changes the position of each vertex right when it’s supposed to be displayed.

   The advantage is that this is even faster because the Pascal code does almost nothing — we just pass the new Time value to the shader. The per-vertex calculation is done by GPU, and GPUs are ridiculously fast at this.

   On one test system:

   • The first approach (TCoordinateNode.SetPoint) was able to handle 100 x 100 grid with 60 FPS. But once grid size increased to 200 x 200 it dropped to 18 FPS (in debug) or 38 FPS (in release).

     Note that changing the height calculation (to avoid Sin in Pascal) does not significantly change these measurements. The Sin, and in general how the H is calculated in Pascal, is not a bottleneck.

   • And the shader approach could handle 1000 x 1000 grid with 60 FPS. At 2000 x 2000 grid it dropped to 20 FPS. So, it’s 100x more performant, if you look at the number of triangles it can handle while still maintaining 60 FPS!

     Note that changing the height calculation (to avoid sin in GLSL) does not significantly change this. Neither does debug vs release build (which makes sense, since the speed of Pascal code cannot be the bottleneck here).

   Note: For stress-testing, consider setting initial CheckboxShader.Checked in design to true, to start with more performing version immediately.

   The disadvantage is that Castle Game Engine is not aware of the calculated vertex positions (they remain only on GPU). So e.g. any raycasts or other collision queries will treat this mesh as if it was in the original position (flat plane in this example).

   An additional potential disadvantage is that you need to learn shading language, more specifically OpenGL Shading Language (GLSL). There’s a small piece of GLSL code in data/animate_mesh.vs.

I encourage you to experiment with this example and try to stress-test it. It should handle very large values of GridWidth and GridHeight.

We have implemented a simple approach to user interface batching to improve performance of UI rendering:

• You can easily activate it by Container.UserInterfaceBatching := true. See TCastleContainer.UserInterfaceBatching API docs.

• We also added a way to observe whether/how much do you gain. Look at class variable TDrawableImage.Statistics information. In particular use TDrawableImage.Statistics.ToString, or TDrawableImage.Statistics.DrawCalls, TDrawableImage.Statistics.ImageDraws. Display them in any way (e.g. on some label).

• There’s simple example examples/user_interface/ui_batching/ that shows how to use it. It also shows how it decreases draw calls from 57 to 21.

• The TCastleContainer.UserInterfaceBatching docs do try to “manage the expectations” and outline what to expect from it.

  The existing algorithm is simple. It can be beneficial — it’s nice if you have lots of TCastleLabel or TCastleImageControl with same image, rendered one after another.

  But it can also be pretty worthless. This approach helps with rendering some easy arrangements of UIs, where underneath we render a subset of the same image many times. It will not help if we keep changing images, e.g. when rendering buttons’ backgrounds and captions.

  Moreover, note that usual applications do not have a bottleneck at UI draw calls rendering. Probably, stuff like 3D and 2D game world is your main concern, not UI, and not UI draw calls 🙂 Remember to optimize smartly, where it matters.

Try it out, let us know how it performs in your project!

Do you like what we do? Please support us on Patreon!