Editor improvements: F1 to open property documentation, selecting TCastleTransform, recent projects improvements

Posted on

Zrzut ekranu z 2020-08-31 00-14-53

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.

Comment on this post (3 comments now) ➤

X3D specification 4.0 draft, with Physically-Based Rendering materials supported by Castle Game Engine

Posted on


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:

Comment on this post ➤

Various improvements: project caption in editor, castle_indy package, CThreads, etc.

Posted on

Castle Game Engine editor - New Project dialog

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)
Comment on this post ➤

Weighted mesh (skinned mesh animation) in Spine

Posted on

Spine weighted mesh in view3dscene

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.


  • 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.

Comment on this post ➤