At the beginning of August, I made a presentation about View3dScene and Castle Game Engine, for Web3D webinar about X3D Browsers. The presentation is now publicly available:

Enjoy 🙂 I focus in the presentation on View3dscene features, which you get just by opening some X3D and glTF files, no coding (or knowledge of CGE API in Pascal) required. For CGE developers, all these features are available as part of our TCastleScene class, documented in a few chapters of the manual.

To focus on Castle Game Engine 7.0 release, I want to finish some important editor features.

1. Press F1 to open a WWW browser with the API reference of the selected property (when object inspector is focused) or at least selected component (in designer mode).

   It jumps to proper location in the engine API reference or (in case of standard property like TComponent.Name) to FPC reference.

2. I started working on editor “gizmos” to visually transform a TCastleTransform instance. This is my biggest feature missing from CGE editor before release.

   You can now select the TCastleTransform instance if you first select a viewport, and then go into “Transform Select” mode. A bounding box of the selected object, as well as object under the mouse cursor, is shown. As part of finishing gizmos, this will be improved more (I think we can make the “Transform Select” mode possible without first selecting viewport, and I want to visualize the box+center in a more universal way, to be always visible).

3. Small improvements to “Recent Projects” list: Detect projects on “recent” list with missing files, ask whether to remove them from list on opening, also update projects’ order properly.

4. If you’re on Linux (or FreeBSD) and want to have a nice menu entry for CGE and view3dscene, see here. Of course when installing from package (CGE is already in Debian, but for now an old version before editor) this would be automatically set up.

Our TCastleDownload class, for asynchronous downloading now rocks under Android. You can test it with e.g.

• examples/network/asynchronous_download (demo doing 3 simultaneous downloads)

• examples/network/remote_logging (demo sending logs to remote server using HTTP POST)

The screenshots in this post are from a real Android device:)

Our engine uses X3D nodes to express everything that is rendered in 2D or 3D inside TCastleScene.

That is why, as I announced previously, I was working on X3D specification to incorporate some modern rendering features in X3D 4.0, in particular Physically-Based Rendering.

I’m happy to announce that the result of this work is now available publicly. It is X3D 4.0 2nd working draft. Despite the “draft” specification version, it is something we actually implement in CGE right now, and thus the X3D 4.0 draft specification serves also as a documentation for CGE. In particular see:

• X3DOneSidedMaterialNode, which corresponds to CGE class TAbstractOneSidedMaterialNode. This is an ancestor for all materials, it specifies e.g. normalmap and emissive color.
• UnlitMaterial, which corresponds to CGE class TUnlitMaterialNode. As the name suggests, this is “unlit” (not affected by lights) material.
• Material, which corresponds to CGE class TMaterialNode. This is the “classic” Blinn-Phong lighting model.
• PhysicalMaterial, which corresponds to CGE class TPhysicalMaterialNode. This is the Physically-Based lighting model, fully consistent with glTF 2.0 PBR materials.

Various important improvements done lately in Castle Game Engine:

1. You can set project caption when creating a new project in CGE editor.

2. Our CastleClientServer unit (for TCP/IP networking) has been moved to a new Lazarus package castle_indy that depends on indylaz package. This makes our connection to Indy cleaner, and fixes the client/server example compilation. This entire section of the manual was also improved.

3. CGE applications (if you let the build tool to auto-generate your program file) on Unix now by default use CThreads, thus they can use TThread.

   This affects desktop Unix platforms, like Linux and FreeBSD.

   This means that

   1. asynchronous downloading (TCastleDownload with http, https) and
   2. music streaming (SoundEngine.LoadBuffer(.., slStreaming) with default OpenAL backend)

   … just work out-of-the-box. I suspect that more and more such features will appear in the future, so it makes more sense to make the default “threads work on Unix”.

   If you would like to disable CThreads for some reason, you can still do it by compiling with CASTLE_DISABLE_THREADS.

   FPC by default doesn’t use CThreads, to avoid linking with C library, to increase compatibility across Linux distros. But, as far as my experience goes, this argument is no longer relevant in 2020. I haven’t actually encountered any case when a binary FPC application cannot be transferred from one Linux to another due to CThreads API incompatibility. Reading one recent FPC bugreport about it I can conclude that the fear of “linking to C by default” is now more because of “unforeseen consequences”, not because of any proven visible problem that can occur on Linux in 2020. And that report is about FPC_USE_LIBC, while using CThreads should be a smaller issue.

   And note that CGE uses a few libraries that definitely change more rapidly than C library anyway (e.g. libpng, X, GTK, OpenGL…).

4. remote_logging example was redesigned:

   1. Should work on all platforms nicely now, doesn’t need console
   2. Shows nice UI with animation (to show that all HTTP stuff doesn’t cause any interruption in the main thread)

We add support for a major Spine’s feature: weighted mesh. Spine is a great 2D animation software, and this feature allows to have use it for skinned animation. It was implemented by Trung Le (Kagamma) — thousand thanks!

See the demo movie:

The sample files are part of our demo models. Simply get this repository, and explore examples in spine/weighted_mesh subdirectory. You can open the JSON files using view3dscene or any other engine tool to view scenes.

Details (from the pull request):

• Support for weighted mesh, by interpolating values between bone timelines.

• Make weighted mesh work with deform timeline.

• Additional frames for better transition, this will make animation more accurate in certain situation (rotation and non-linear interpolation types) in exchange for longer load time and more memory consumption.

• Non-linear interpolation type (Bezier curve) for weighted mesh (both bone timeline and deform timeline).

• Add deprecated warning to skinnedmesh attachment.

Limitations:

• Due to the way we handle weighted mesh (by baking every transformations, including bones, into TCoordinateInterpolatorNode), we cannot have a mix of weighted mesh attachments and other types of attachment in the same slot.

pas2js can translate modern Object Pascal to JavaScript, making it possible to run Pascal code in a WWW browser. In the past, pas2js didn’t support generics, which made porting CGE to it troublesome, as we use generics a lot.

This weekend I tested recent pas2js support for generics, in particular with containers from the Generics.Collections unit. I tested 4 examples from my book about modern Pascal. …And the result is that everything just works! 🙂

This means that pas2js supports generics at a level we need for Castle Game Engine, so in general should be able to handle CGE Pascal code. Pas2js also supports WebGL rendering since a long time, since it can just call JavaScript API in a browser.

All this means that we have everything we need to port Castle Game Engine to WebGL! That is, your games could be recompiled to just run in a WWW browser. No installation, no extra steps for the user. Anyone can open your WWW page and the game works, with Pascal code being translated into simple JavaScript that browser can efficiently execute.

I will work on this feature intensively after CGE 7.0 release.

I’m proud to announce that my pull request to introduce a lot of new features to X3D 4.0 is now merged into the “master” branch of the X3D 4.0 specification. It introduces new rendering features that we already use in CGE:

• PhysicalMaterial node

• UnlitMaterial node

• lots of (Phong) Material node upgrades

• consistent RGB/grayscale texture treatment

• Appearance.backMaterial (and deprecation of TwoSidedMaterial)

All these changes are now on their way to the soon-to-be-published new X3D 4.0 public draft. And then to X3D 4.0 official release, after (I hope!) countless people will review it and point out all the errors I did 🙂

Companion documents / tests:

1. My summary of these changes.

2. Test files for this feature are in the my x3d-tests repository, in pbr/ subdirectory. I plan to work on them more — add some more, add reference screenshots, add XML encoding versions etc.

3. Almost all specified things are implemented in our Castle Game Engine and can be tested by view3dscene right now.

4. The reasons behind various decisions in the PBR specification are documented here.

5. We have documentation on how various glTF concepts map to X3D, and how Castle Game Engine does it.

The new class TCastleDownload allows to download data over http and https asynchronously, without blocking the main thread of the application. This means that you can trivially continue rendering and game logic, while some resource are being downloaded over the network.

I made a demo in examples/network/asynchronous_download/. It demonstrates multiple simultaneous downloads, and underneath a glTF animation is playing with smooth 60 FPS without any breaks.

The class supports all CGE URLs, like file, http, https, castle-data and more.

Manual chapter about networking was updated to reflect all new possibilities.

Features:

• The download can be observed (looking at Status, DownloadedBytes, TotalBytes).

• When it’s finished, look at Contents (if success) or ErrorMessage (if error, that is Status = dsError).

• We can read MIME type from server (can be used throughout our engine to designate file type).

• It’s actually a full-featured HTTP(S) web request. You can specify HttpMethod, like GET, POST, PUT etc. For POST, you can provide form data as PostData. Arbitrary HTTP headers can be specified using AddHeader.

More examples:

• examples/network/castle_download/ was reimplemented. It implements a simple command-line downloading tool (like wget or curl using our engine) using TCastleDownload.

• examples/network/remote_logging/ sends now asynchronous HTTP POST message using new TCastleDownload.

This feature was done thanks to your support on Patreon. It was requested by Peardox. Many thanks! If you like what I’m doing, please support our engine.

I have a few cool announcements about CGE features this weekend 🙂 Let’s start with a summary of new things done lately:

1. Fixed bold / non-bold display in CGE editor for Single properties. Bold in object inspector should always mean “different than default” intuitively.

2. I have started implementation of the EnvironmentLight X3D node, to perform image-based lighting. This is a work-in-progress. The eventual goal is to add such light to CGE, and to X3D 4.1, and to make it consistent with glTF image-based lighting extension. See X3D 4 plans and initial EnvironmentLight tests.

3. The run command of our build tool is now more useful on Windows. It shows the log, just like on all other platforms (desktop Unix, mobile…). So using castle-engine run on command-line is now very useful on Windows.

   Note that for most users, I would advise just using Run command in CGE editor. This also outputs log nicely.

4. Additions and fixes to CastleTransform API:

   • New Viewport.Items.WorldRayCast, TCastleTransform.RayCast methods. These allow to check “what collides with a 3D ray”. These are simpler alternatives to the old Ray method.

   • New WorldToLocal, WorldToLocalDirection, WorldToLocalDistance and equivalent LocalToWorld, LocalToWorldDirection, LocalToWorldDistance. These allow to easily transform things between TCastleTransform local space, and world space (which means “coordinate space of the complete TCastleViewport). These are simpler alternatives to the old approach of multiplying with the WorldTransform matrix.

   • A number of collision methods have been fixed to work in parent coordinate space (this was always the intention, but it was neither documented nor reliably working): Move, MoveAllowed, Height, LineOfSight, Ray.