The support we get through our Patreon page is a big thing for us. It is a donation system that really works and in the ideal future I would like to see engine development funded by this model. So we really appreciate your support on Patreon!

New Patreon tiers and rewards

• 

  Discord Role and Channel for Donors (5 USD / month):

  You get a “Donor” role on our Discord chat. The role gives your nick a special color, and access to the #donors channel on Discord.

  Make sure to connect your Patreon account to Discord (more info in Patreon article about this).

• 

  Mention in Credits and Stickers (10 USD / month):

  • Mention on the Credits page. Note: by default I will use your name from Patreon. if you want me to use anything else, or wish to remain anonymous, just write to me.

  • And stickers! After 3 months of being a donor on this tier, you get a collection of 4 stickers. Delivered anywhere in the world (just set your shipping address on Patreon).

• 

  Monthly Consultations (50 USD / month):

  In addition to the benefits from previous tiers, you are invited to a monthly meeting scheduled by Michalis for all Patrons on this tier. Please drop by and let’s talk! I can e.g. answer questions about the engine and help you with your project.

New Patreon goals

• 250 USD: We get tangible proof that we can fund engine development through Patreon!

  Right now we are hiring 1 developer (Andrzej Kilijański) at 1/2 FTE, paid from Michalis own pocket. As we reach further goals, I hope that money from Patreon can cover this cost — and allow to hire more people.

  Reaching this goal will also deserve a little dance of joy with my cat!

• 500 USD: We add a tier with T-shirts (more merch!) to our Patreon offering.

• 1000 USD: We hire additional person to our team (developer or gfx arist) to work regularly on the engine.

Why do we need your support on Patreon

Short story, looking into the past: Almost 2 years ago I decided to hire from my own savings Andrzej Kilijański to work part-time (regular 1/2 FTE) on the engine. And this was one of the smartest decisions I made. The amount of features we added to Castle Game Engine together with Andrzej in recent years is amazing, I’m proud that the engine is today on a completely different “level” than it was 2 years ago.

Looking into the future: We obviously want more. More dedicated people who can contribute regular time to the engine development. Programmers but artists too. And my ideal plan to make it happen is to get donations through Patreon to make it possible.

Business (companies) support

Though I called Patreon my ideal plan above, there are alternative plans and additional plans. First of all I would like to get companies to support the engine (possibly in exchange for on-going support or even a specific feature development, depending on the contribution level). I have plans to explore this (contact me if you have/know a company that would like to sponsor Castle Game Engine). In an ideal future, we get a diversity of supporters (both community and business) and with this — freedom to follow our priorities (to just make the best open-source game engine that features both a visual editor and a powerful code API).

Why changes?

As I outlined in a previous post about Patreon, I got a little dissatisfied with our current tiers and goals. I constantly feel I fail to make the things I promised —

• E.g. I don’t do much “secret” posts only for supporters on Patreon (because I prefer doing public posts, for everyone to enjoy).

• And I suck at making the features and videos requested by Patrons — it takes me way too much time to get to them, because in the meantime I do other features and videos that I consider “this has more urgent priority now”.

And I already started doing some late goals, paying no attention to whether we have achieved them financially:

• we have regular meetings on Discord called “open meetings” – next one is next week!

• I have Oculus and plan to add VR support,

• GitHub Actions and GitLab CI are a practical answer to the dream “continuous integration for free for everyone” that I wanted.

I hope that new rewards will be better 🙂 Thanks for reading and take care!

Look at our brand new features page, that describes important engine features with lots of screenshots! The summary of the features is also repeated on the main web page under the downloads.

I have various plans to improve the presentation of it, but at least now I believe we have a solid content 🙂 The page really reflects now the features I want to emphasize — including some things common to various game engines, and some features unique to Castle Game Engine. I hope this is a good promotional material to refer people to, if they want to know “what can Castle Game Engine give them”.

In the last few weeks, I made numerous other improvements to our documentation and website:

1. Blender page much simplified, talks about glTF (and not about deprecated castle-anim-frames alternative), has new screenshots.

2. Roadmap updated, because we have done a few things mentioned there! (lights, cameras, MainScene deprecation, RNL demo – done, physics – much in progress).

3. Text and fonts page updated to describe advised approach to render text and customize font in the engine.

4. API docs are now more friendly to mobile. I also removed the alternative apidoc-unstable version. We show now one API docs: the docs for the engine version that we recommend to download, which is now “the latest snapshot”. We also link to API docs more consistently now.

5. Patreon panel at the header, with clearly visible percent to next goal, updated to use current Patreon colors and watermark.

6. Better youtube URL, https://www.youtube.com/c/CastleGameEngine

7. Various other documentation updates – better screenshots, reflect that the default shading is now Phong, optimized page loading in many cases etc.

8. Merged Scene Graph (X3D) section into Documentation. Going forward, at some point I hope to merge it even with API docs.

9. We no longer link to obsolete Web3D 2015 tutorial (you can still find it on GitHub, but we don’t recommend it anymore).

I’m proud to announce a new Castle Game Engine feature: terrain components! A new TCastleTerrain component (TCastleTransform descendant) allows to visually design a terrain and you can of course use it from code or from editor and play with all the properties visually.

Terrain height data may come from:

• A smooth noise, generated with TCastleTerrainNoise. This employs a few techniques for nice terrain generation, summing a few octaves of noise and adding simple tricks to make it smooth and heterogeneous.

• An image (height map from image intensities), with TCastleTerrainImage. This is great to edit the heights in any 2D image editor – GIMP, Photoshop, or just Paint 🙂 etc.

• A combination of the above (sum, min, max, multiplication) using TCastleTerrainCombine. This effectively allows to make an “expression tree” to calculate terrain as a combination of multiple TCastleTerrainImage and TCastleTerrainNoise. E.g. you could use TCastleTerrainNoise but add TCastleTerrainImage to force some particular mountain or valley, or use TCastleTerrainImage to make the borders of the noise go smoothly to 0 (to seamlessly connect terrain to a perfectly flat plane).

The terrain component features a ready visualization that combines 4 layers of materials (colors, textures, with per-layer setting for metallic, roughness) in an interesting manner. Height and slope (how steep is the terrain here) decide what mixture of layers to show at each point. See TCastleTerrain component docs for details.

The example in examples/terrain/ now presents a terrain made using this technique. Terrains of course can be combined with skybox (TCastleBackground), fog (TCastleFog), trees (make multiple instances of a tree using TCastleTransformReference to make them ultra-light on resources), and water (using CGE shader effects in OpenGL Shading Language in X3D).

We also have a new behavior, esp. useful for trees on a terrain: TCastleStickToSurface. Use this when you want an object to stick to another object’s surface, even when one of them is moving. Nice to position trees on the surface of terrain.

Have fun with it! And note that this is just the beginning 🙂 I’m aware that to make terrains really nice to use we need a few more features. In particular on TODO are:

• tools to edit the terrain heights within CGE editor.

• tools to edit the terrain textures mixture (splatmap) within CGE editor.

• tools to plant trees and grass in CGE editor. You can kind of do it now, but it’s very manual.

• more specialized and efficient rendering algorithm. Right now terrain in the end is just a simple big mesh of triangles. It’s actually quite fast to render (because modern GPUs can handle big shapes) but it’s not a sustainable way to render huge terrains.

Here goes a list of recent Castle Game Engine improvements that I need to get off my chest 🙂 Overall I’m very happy with the engine state lately — we’ve done good features, we have big things coming (like new physics), and have good base and can polish the experience in many places. This resulted in recent improvements a bit “all over the place” as I test and polish 1st-user experience with e.g. our examples.

If you’re looking for an introduction to the engine, watch engine tutorial on our YouTube channel and explore our examples.

Please support the engine development on Patreon! We want to do everything from our roadmap and more!

Engine improvements done lately:

1. We now support reading mipmaps from KTX (Khronos Texture) files.

2. Automatic texture generation can be instructed to generate mipmaps for textures. Mipmaps allow trilinear filtering that looks good when the texture may be seen from various distances (typically useful for textures on 3D models, but there are cases when it makes sense for 2D too).

3. ASTC compression is done to KTX format and using AMD Compressonator.

   This is our general direction for the future: We like KTX format (open standard from Khronos), we like open-source Compressonator with lots of output options. We will push our automatic texture generation to utilize these 2 (Compressonator to KTX) consistently for everything where possible. Other formats (like DDS) or tools (like NVidia texture tools ver2, with a proprietary successor in ver3) will get lower priority.

4. Our Docker image now contains AMD Compressonator (to generate textures) and GitHub CLI (to interact with GitHub from continuous integration jobs).

5. We’ve done a number of macOS fixes. They all can be tested using macOS build available prominently on our main page. The macOS build is done automatically by Jenkins and contains the latest CGE. Fixes:

   • Fixed crashes when clicking on lists in editor,

   • Fixed error message about -psn_... at 1st run,

   • Added ability to set CGE location (useful if you run CGE editor from zip downloaded from the Internet, which will be the most common case here). This may also be useful on non-macOS platforms.

   • By default we package app bundle to zip. You can change it though.

6. I’ve done some thinking and made a documented decision to not try to rename nodes to be unique when loading (glTF, X3D, others).

7. Following the above decision, I extended TCastleSceneCore.Node and TX3DNode.FindNode methods. Simpler and allow to search by class criteria too. Deprecated some old alternatives.

8. Last but not least, TCastlePlane.Size gets a trivial but compatibility-breaking fix: it is now treated as total size in both dimensions. This means that size = (10, 10) results in rectangle around (0,0,0) that has size 10, for example from X = -5 to X = 5, and from Z = -5 to Z = 5. This is consistent with TCastleBox.Size and more natural.

   Previous interpretation resulted in larger rectangles. Size = (10, 10) resulted in rectangle around (0,0,0) that has size 20, like from X = -10 to X = 10.

Screen for this post shows Invincible and Mark Grayson 3D models from SketchFab created by ASideOfChidori. As usual when I don’t have a perfect screen to illustrate the current news post, I go ahead and pick something cool that can be rendered by Castle Game Engine 🙂 I did watch the Invincible lately and enjoyed it a lot. You can download the glTF file from SketchFab for free and play with it yourself, just drop it on a 3D viewport.

A few improvements to the drag-and-drop experience in our editor:

1. You can drag-and-drop from “Files” to “Hierarchy” panel. This will add a child to the currently selected item in the tree view.

2. You can drag-and-drop images from “Files” to the central design area even when you’re not over a viewport. From such image, we will create TCastleImageControl. You can also drag-and-drop with Shift pressed to force creating a TCastleImageControl (instead of the default TCastleImageTransform) even when dragging over a viewport.

3. You can drag-and-drop also .castle-user-interface files (will create a TCastleDesign that references them) or .castle-transform files (will create TCastleTransformDesign that references them). If you want to test it out, see e.g. examples/advanced_editor/advanced_loading_designs project.

4. I also reported drag-and-drop bug with cursor on Lazarus GTK2 widgetset that affects us.

In effect (summing up previous and new features):

You can drag-and-drop various files from “Files” to “Hierarchy” or central design area.

• You can drag-and-drop scene files (like glTF or X3D files) on the viewport to create TCastleScene.

• You can drag-and-drop sound files (like WAV or OggVorbis) on the viewport to create TCastleTransform with TCastleSoundSource.

• You can drag-and-drop images (like PNG or JPG) on the viewport to create TCastleImageTransform or on anything else (or hold Shift) to create TCastleImageControl.

• You can drag-and-drop UI designs (.castle-user-interface) to create TCastleDesign.

• You can drag-and-drop transform designs (.castle-transform) to create TCastleTransformDesign.

Enjoy, happy dragging and dropping 🙂

We’ve made some small updates to how bump mapping (normal maps) work and wrote a nice simple documentation how to use bump mapping in our engine.

1. Advised reading: bump mapping (normal maps) in Castle Game Engine.

2. The default bump mapping is now bmBasic, this is much more natural than previous bmSteepParallaxShadowing.

3. Using the parallax bump mapping is also easier now. Once you place the height map in the alpha channel of the normal map, just set TCastleRenderOptions.BumpMapping to something like bmSteepParallaxShadowing and optionally adjust TCastleRenderOptions.BumpMappingParallaxHeight. See the docs.

4. Our old bump mapping example was completely reworked, to set up everything in the editor and is now much more straightforward. See examples/viewport_and_scenes/bump_mapping.

How to assign normalmaps to materials in Blender, how to export them to glTF and then observe normalmaps in Castle Game Engine. Bonus: I also describe how to bake normalmaps in Blender.

Another day, another video, I hope you like it 🙂

Andrzej Kilijański is working on joints in our physics in Castle Game Engine. This is a short video from our today’s session, constructing a quick 3D demo scene for hinges 🙂

(Watch on youtube).

Recently I was making various improvements possible thanks to new viewport and camera handling. If you haven’t already, see our video about Viewports, cameras and navigation!

Improvements:

1. Few fixes to automatic projection calculation. Long story short: you can probably leave TCastleCamera.ProjectionNear and TCastleCamera.ProjectionFar at zero in your projects, 2D and 3D. They should be always automatically calculated to nice values.

   1. Default perspective TCastleCamera.ProjectionNear doesn’t depend on world box (to not increase when some object flies/falls into infinity).

   2. Default perspective TCastleCamera.ProjectionFar is now ZFarInfinity, regardless of ShadowVolumesPossible (which were usually true). So there is no far clipping plane — easy to use. We were testing the perspective matrix with “z far at infinity” already a lot (as it was necessary for shadow volumes anyway), and there’s no perceived loss of Z-buffer precision because of it.

   3. Default orthographic TCastleCamera.ProjectionNear and TCastleCamera.ProjectionFar are much smarter now, looking at world bounding box.

   4. Optimized: Do not calculate useless ProjectionFarFinite, do not calculate ItemsBoundingBox when not necessary (never needed for perspective, not needed for orthographic when explicit).

2. We have deprecated TCastleViewport.AutoCamera, TCastleRootTransform.MainScene, TCastleRootTransform.UseHeadlight. I consider it a significant gain for the engine — in particular TCastleRootTransform.MainScene was a thorn in my side for a long time, it was unnatural we needed to designate some scene as “main” to activate some engine features.

   Now you can achieve (almost) all their functionality through other means. See their docs for pointers. And the engine usage is simpler when you don’t need to be concerned about setting MainScene etc.

3. Upgraded simple_3d_demo with new Blender models.

   New castle Blender model is also part of demo-models, see castle subdirectory.

4. Upgraded fog_and_distance_culling to use glTF model and of course new TCastleFog component.

5. Fixed crash in simple_3d_demo when accessing previews of data files with GeneratedCubeMap.

Fog can be now added and configured using TCastleFog component. The component is also available in CGE editor, so you add and configure your fog without even writing any code.

The usage is simple:

1. You add a fog component anywhere to the design using “Add Non-Visual Component -> Fog (TCastleFog)” in editor.

2. You set it as active for given viewport by adjusting the TCastleViewport.Fog property.

3. Adjust the fog parameters, like TCastleFog.Color and TCastleFog.VisibilityRange, as you wish.

4. Optionally, you can adjust the background color to match the fog color. The fog looks most natural in this case. You can just adjust TCastleViewport.BackgroundColor and leave TCastleViewport.Background empty (nil) for a simple background color. See more about backgrounds.

I reiterated this in a simple manual chapter about fog.

The fog behavior in combination with Linear color space (gamma correction) also changed. Fog is now applied in final (sRGB) color space, this allows to match fog color perfectly to background color or UI easily.