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.

This post is not strictly about Castle Game Engine. It’s about X3D 4.0, which is going to be the next major version of the X3D international standard (see the current X3D standards).

X3D is a major building block of our engine. While you can use TCastleScene as a “black box” (just to load models and play animations), but sooner or later you will want to change something in the loaded model, using Pascal code. For example to tweak a material of texture parameter, or adjust what is collidable. You can even build an entire 3D scene from scratch by Pascal code. This is all possible because everything inside TCastleScene is an X3D node (just a Pascal class like TXxxNode) and you can create/modify X3D nodes at runtime, from Pascal. Examples of it are throughout our documentation (see Building and editing the scene, X3D overview, examples about 3D building, examples about 2D building).

The point of this introduction is that we care about X3D, we want X3D to be modern and expressive, because it allows to express more things in CGE. While we can (and do!) implement a lot of custom extensions to the X3D standard, but some things are just best if they can be added to the standard.

So I did that 🙂

Since a few months, I was working with the Web3D Consortium to add to the upcoming X3D 4.0 a number of modern rendering features. I wrote a pull request to the X3D specification with it all. The summary of this pull request is here: X3D version 4: New features of materials, lights and textures. A summary of this summary:

• New X3D 4.0 Material node is much more powerful, allowing to adjust all parameters by textures. It will also have dedicated fields to specify normalmaps (for bump mapping) and occlusion (ambient occlusion textures).

• New X3D node PhysicalMaterial allows to express a Physically-Based Rendering parameters. It is compatible with glTF, and in fact is the basis of our PBR handling in glTF.

• New X3D node UnlitMaterial is probably self-explanatory 🙂 It allows to define unlit material in a clear way.

• There is a lot of other stuff and details. Also, image-based lighting is coming, but probably not in X3D 4.0 but in X3D 4.1 (I simply didn’t have time to make it, even though I have initial sketch of spec and implementation too.)

Now the cool part: This is all already implemented in Castle Game Engine. And you already use it 🙂 When reading glTF, you are actually creating in memory a graph with PhysicalMaterial nodes. When reading Spine JSON, you are creating in memory a graph with UnlitMaterial nodes.

I have a number of examples of all the new X3D 4.0 features (in pbr subdirectory there). You can just open them with our view3dscene.

A draft of complete X3D 4.0 specification will be soon available for public. So you will be able to read all the details about the new nodes. And I did a presentation about it last Friday (July the 3rd, 2020), it was recorded and will be publicly available shortly 🙂 I’ll post about it here of course.

In related news, you probably noticed that I put a lot of work into perfect glTF support. I think glTF format is a great thing, and I want to support it 100%. To this end, we want to load everything in glTF into X3D nodes. I have prepared a documentation how does CGE convert glTF to X3D nodes. This should give you insight into various semi-internal things that happen when we read glTF. I wrote “semi-internal” because, while you will usually just treat glTF as a “black box” through TCastleScene, you can also tweak the resulting X3D nodes graph using Pascal code.

I think that in the end, we will have a perfect combination in our engine, by leveraging 2 big open standards: glTF and X3D, as a basis of our engine.

Oh, and if you have any questions about X3D (not specific to CGE), you can ask them on x3d-public mailing list where all people working on X3D listen 🙂

We present a new Castle Game Engine component TCastleThirdPersonNavigation. You can use it easily with TCastleViewport to have a working 3rd-person navigation. This means that you control an avatar with keys (ASWD QE), and the mouse orbits around the avatar, who is displayed and animated in front of the camera.

Features:

• You can move the camera around the avatar and control the avatar in various ways. All the inputs are configurable.

• Avatar can run, crouch, with collisions, with gravity.

• Camera follows avatar smoothly and avoids being blocked by walls.

• Mouse can optionally also “aim” the avatar, which makes it easier to rotate the avatar. OTOH, it makes it harder to look at avatar’s front, e.g. at avatar’s face.

• You can look closer/further at the avatar.

• Avatar can have gravity enabled, so it can fall down and climb stairs correctly.

It is all documented in our API. There’s a lot of published properties to play with.

You can trivially use it with CGE editor. Just select a viewport and, using the menu, change the Navigation to be TCastleThirdPersonNavigation. Remember to also assign the Avatar property.

The full demo is in engine sources, in examples/third_person_camera. Just download the latest engine and open “examples/third_person_camera/” project in the CGE editor.

The examples/fps_game was also updated to show how to use 3rd-person navigation together with TPlayer and TLevel classes. Just uncomment SetupThirdPersonNavigation call in the sample code to have it working.

This work has been sponsored through Castle Game Engine Patreon. In particular thanks to Ramazan Geven and Robert Daniel Murphy for donating and requesting this feature! If you like what I’m doing — please support me on Patreon. Thank you!

Great news: New major version of FPC (Free Pascal Compiler), the compiler of our game engine, was just released. New features are documented here. You can get it e.g. from SourceForge or using latest fpcupdeluxe.

Castle Game Engine is of course 100% compatible with it. I was watching and testing FPC SVN branch leading to this release. So I encourage everyone to upgrade their FPC installations. As always, we recommend using CGE with the latest FPC stable.

Note: Following our supported versions docs, you can also use some older FPC versions (we will maintain compatibility with FPC >= 3.0.2). So you don’t have to upgrade, for now we promise to keep compatibility with FPC 3.0.x for the next CGE release.

Note: if for some reason you have to stick to the old Castle Game Engine 6.4, I maintain a v6.4-fixes branch with minimal CGE 6.4 changes to make it compile with FPC 3.2.0. Although I would encourage everyone to upgrade to latest CGE that will soon be released as CGE 7.0 with ton of new features.

Our Docker image has been updated to include FPC 3.2.0, and actually use it by default. See also Jenkins docs.

Gamma Correction and Tone Mapping are now implemented in Castle Game Engine. They can be trivially controlled by global variables GammaCorrection (by default it is on for PBR materials) and ToneMapping.

Gamma Correction is a way of making lighting calculations more correct (see e.g. here and here for explanation; my analysis of various implementation is here).

Tone Mapping is just a fancy name for nice-looking color processing, that makes the final look more visually pleasing. It is independent from the gamma correction (technically), although they both “change the scene colors” so are often considered together. We now implement 3 tone mapping operators (based on glTF sample viewer): see TToneMapping. Note that you can easily do your own color processing (thus providing functionality equivalent to these tone-mapping operators) by using Effect node like in this example: tone_mapping.x3dv from demo models.

I wrote a new manual chapter about Gamma Correction documenting all of this, and my description of gamma correction in various engines was also extended.

We introduced TCastleSceneCore.DefaultAnimationTransition property.

This is a really easy way to request animation cross-fading (blending) which makes changing animations look much smoother. Just set this to some non-zero value to have smooth animation change. It’s the time in seconds, often it’s reasonable to start with something small like 0.1.

This is also configurable in the CGE editor (as it’s a published property). Our “New Project” template 2d_game is using it.

And it’s available in resource.xml file for the creature. Our examples/fps_game/ is using it for the “knight” creature. Like this:

<model url="knight.gltf" pool="10" default_animation_transition="0.25">
  <idle   animation_name="Idle"    />
  <walk   animation_name="Walk"    />
  <attack animation_name="Attack"  />
  <die    animation_name="Die"     />
  <hurt   animation_name="Damaged" />
</model>

This also brings improved switching to the default state (like idle or walk) after Attack/Hurt. This makes animation change smoother for creatures using resource.xml, whether you use default_animation_transition or not.