You can now activate shadows by shadow volumes by toggling a trivial boolean property Shadows at the light source to true! This works (also) in editor at design-time.

This makes the shadow volumes we have documented here easily available, finally. No more messing around with X3D lights nodes.

A simple demo is in examples/viewport_and_scenes/shadows.

We also publish TCastleTransform.CastShadows property to control if some object casts shadows.

Future:

This is just the beginning of “really easy shadows”. I enjoy how simple API we have (just a checkbox really!) and how great it is to play with shadows in the editor. But we can improve the functionality underneath now 🙂

1. The most important TODO here is that we plan to expose shadow maps in the same way. Actually shadow maps should be in the future the default algorithm activated by Shadows (and toggling between shadow maps and shadow volumes should be done using an independent property like ShadowMode = smShadowMaps, smShadowVolumes).

   Shadow maps have a number of advantages — they do not require the shadow caster to be 2-manifold, they already work on both desktop and mobile (OpenGLES), they can be applied on multiple light sources independently with correct result.

   While we had shadow maps implemented for years, with some impressive demos (see features section) but they do not work (yet!) across scenes, which means that the light that casts shadow must be in the same glTF/X3D file as the shadow receiver. This makes them not suitable to use shadow maps on our light nodes.

   The plan is to, well, remove this limitation (#284). Shadow maps should work cross-scene, they should not transform the X3D graph (whole work done by CastleInternalShadowMaps should be removed) and the renderer should just take and use at rendering a shadow map information attached to any light (and the renderer should add using that shadow map to particular shape).

2. Shadow volumes for now carry a few limitations:

   • The unfixable limitation is that shadow caster has to be 2-manifold, i.e. every edge must have exactly 2 neighboring faces, so the whole shape is a closed volume. Both CGE and 3D authoring tools like Blender help you modeling such shapes — see Make 3D models of shadow casters geometry to be 2-manifold.

   • The current limitation of shadow volumes in CGE is that we allow them from only one light (so set Shadows to true only on a single light!)

     We could improve that, though note that it will increase the number of rendering passes, in general you need to do 2^shadow_volumes_lights passes. So this technique is really not feasible for multiple lights. (Shadow maps scale much better.)

   • A temporary limitation is that shadow volumes do not render properly on mobile (OpenGLES), we have a PR in progress to address that.

OK, not really a zillion 🙂 But I seriously addressed a few important issues with editor usability and I think these improvements have a big impact. Some important things are now more intuitive for beginners, some behave better for larger projects.

As usual, I encourage you to try the improvements immediately by downloading the latest engine version. And please support us on Patreon because we really rely on it.

Improvements:

1. The default editor tool now allows to select and modify both UI (instances of TCastleUserInterface) and 3D / 2D game stfuf (instances of TCastleTransform).

   In a broader context, the tools to operate on UI and transformations have been merged. There’s no longer a special “Modify UI” tool (that didn’t work on transforms). The tools “Translate” / “Rotate” / “Scale” remain, but now they work on both transforms (allowing to translate / rotate / scale them) or UI (in which case you can always translate + resize it).

   This makes using editor much simpler. You will no longer need to switch modes so often.

   Note: To operate on something (UI or transform) without changing the currently selected object, remember you can drag with Shift.

2. Hierarchy (left panel) is updated smarter, without rebuilding it from scratch. This makes adding / removing components experience much better: it will not reset the expanded / collapsed state of your components, it will not reset the scroll position within the hierarchy list.

3. We now show a label alongside selected UI components of size zero, to make them actually visible in the editor.

   This addresses a common situation with TCastleVerticalGroup and TCastleHorizontalGroup — they have by default size zero (since they have no children initially, and have AutoSize = true by default). While the zero size makes sense for them, but to the user it was confusing what is going on — you added a group, but nothing was visible?

   Now, newly added TCastleVerticalGroup and TCastleHorizontalGroup, while it still has size zero, is clearly visible.

   This also fixes analogous issue with TCastleImageControl, that has size zero by default, because URL of the image is not set initially, and Stretch = false (so control size matches image size, and there’s no image).

4. If you cannot resize or move a component, sometimes it makes sense to move or resize the parent. This in particular applies to moving/resizing a UI with TCastleUserInterface.FullSize or moving a UI under TCastleVerticalGroup / TCastleHorizontalGroup. Previously these operations were blocked, now they affect the parent.

5. If you cannot resize a component because it has property like TCastleButton.AutoSize, now we display this using a tooltip (when you try to resize it). So it should be more obvious that you can turn off properties like TCastleButton.AutoSize on many components to make them resizeable.

6. Important API cleanup: We now have TCastleUserInterface.Translation property, consistent with TCastleTransform.Translation.

   The previous TCastleUserInterface.AnchorDelta is a deprecated alias for Translation. The HorizontalAnchorDelta, VerticalAnchorDelta, Left, Bottom are deprecated.

   This change is fully backward-compatible. We deprecate some things, but they all continue to work as before.

Screenshot for this news post continues our tradition — “if you don’t have a perfect screenshot to illustrate your features, just find a pretty model on Sketchfab and show it rendered using CGE” 🙂 In this case, I searched for “smooth” and found this beautiful monster: Gears of War – Grinder by nataliedesign.

Our components TCastleDesign and TCastleTransformDesign just got a number of significant improvements. I added a context menu to them to edit, revert, and open a referenced design. I fixed drag-and-dropping of .castle-transform. I even made a safeguard to not crash when you recursively reference yourself 🙂

All of this and more is now documented in the manual chapter about TCastleDesign and TCastleTransformDesign and demonstrated in our new video:

Try them out and have fun! And if you like it — please support us on Patreon.

I am proud to announce I will give a talk about Castle Game Engine at GIC (Game Industry Conference) in 2 weeks!

The conference is at 7-9th October (Friday-Sunday) in Poznań (Poland). It’s full of talks and events for game developers, from all around the world, in any technology. I attended it 4 times in the past and really advise it, it’s full of good talks (and majority of them are in English, suitable for everyone, anywhere around the world). The conference is, as every year, close to PGA (Poznań Game Arena), a game expo aimed at broader audience interested in games.

Our talk is part of GIC agenda. The detailed timeline does not yet assign the talks to days, but for sure it will between 7-9th October (Friday-Sunday).

If you want to join us, go ahead and buy a ticket to attend in-person (our talk is at Intermediate level, so you need at least Developer Pass). I see that this year, they also offer tickets to watch online – Pay What You Like and support Ukrainian gamedev (the online tickets grant you access to all talks and even business meetings — see the website for details).

See you in Poznań! 🙂

You can now define a “component editor” class to add commands to the context menu when you right-click the component in CGE editor hierarchy. Detailed instructions and example how to do this are in manual: Add “verbs” to the context menu for given component.

A full working example application is in examples/advanced_editor/custom_component, it defines a verb “Reload URL” over sample TImageGrid defined in that project.

This feature is already used by some built-in components:

1. “Reset Transformation” is now available for TCastleTransform and all descendants.
2. “Reload URL” is available for various components that load things from files (TCastleScene, TCastleImageTransform, TCastleImageControl).
3. “Edit”, “Revert”, “Open” are available for TCastleDesign and TCastleTransformDesign. These new commands will be described in a separate upcoming post — they greatly enhance how you can reuse the designs.

Thank you everyone for joining last Saturday and participating in our open meeting!

1. Short summary: I did a recap of the recent work on the engine (I think it was too long, but that’s because we did a lot of stuff 🙂 ), Andrzej Kilijański presented his work on physics joints, I talked about plans and answered many questions.

   Thank you for all the questions. I tried to answer them live, then I collected them and answered again on Discord chat so you can read them starting from this message.

   One question also sparked a new example in engine: examples/animations/animate_bones_by_code. It’s a demo how you can animate bones (transformations) by code while a predesigned animation (predesigned in Blender, exported to glTF) still runs on the same 3D model. The README.md inside this example explains details (and also notes current limitations and how we plan to overcome them).

   It was also fun to experience “Access Violation” at one point during the presentation. This was an unwanted visitor 🙂 Of course it is fixed now.

2. Same time in +3 months! I am announcing our next meeting, on December 10th (2022; as usual this is Saturday), at the usual hour (15:00 UTC).

   I advise you to go to the meeting on Discord right now and click there on “Interested” and add it to your calendar (click on “…” to see “Add to Calendar” option on Discord event). You don’t want the timezone stuff to surprise you :), and adding it to your calendar this way makes it reliably accessible in your time.

3. Longer summary:

   Michalis: Recent things done (with links to read more):

   1. New cameras. Design-time navigation, right click in 2D 3D. Default 2D and 3D viewport nice. More info in this video.
   2. Fog component.
   3. Terrains
   4. GitHub Actions / GitLab CI / Jenkins possibilities. See castle-game on GitHub and test-gitlab-ci on GitLab.
   5. Material properties plans: focus on AMD Compressonator, KTX.
   6. Better drag-and-drop support in editor.
   7. Not Quake demo – real-time multi-player game using Castle Game Engine + RNL.
   8. Patreon changes.

   Andrzej: working on physics joints.

   1. “Joint” connects 2 rigid bodies, such that the connection acts naturally when something collides with one rigid body. For example, hinge joint allows to make realistic behavior of door opening
   2. On Andrzej branch: You can configure joints in editor too.
   3. Customize joint anchor position, by dragging a gizmo.
   4. See transforms affected by joints as wireframe.
   5. Limits for joint rotation.
   6. Rope to hang something.
   7. Can be used to create a chain.
   8. Breakcable configurable.
   9. BTW: you can change whole rendering to wireframe.

   Michalis: Plans:

   1. Immediate plans: Review new physics component, review joints, merge. Optimize node’s memory usage.

   2. Plan for 2022 still mostly doable.

      Done already: cameras, physics (almost), lights, documentation + website improvements, 7.0-alpha2.

      Definitely will be done in 2022 (so before 7.0 release): AI behaviors (new fps_game), nodes optimization, Steam integration, 7.0 release!!!

      Maybe (important things which would be very cool): TCastleEnvironmentLight, materials customization, WebGL.

   3. Come listen to me at GIC in Poznań (Poland) – this October 7-9th.

If you host your projects on GitLab, this will be a treat for you: We have done, tested and documented an integration of CGE projects with GitLab CI/CD. In simple words, it means that after each commit and push, GitLab can completely automatically (and for free) build your project (giving you ready packages for Windows and Linux).

We have documented how to use GitLab CI/CD here. It’s really trivial — just add the .gitlab-ci.yml file to your repository, that’s it.

We have an accompanying project on GitLab castle-engine/test-gitlab-ci that shows it in practice.

Note about alternatives:

• Do you use GitHub? Use GitHub Actions with Castle Game Engine.

• Do you use Jenkins? Use Jenkins with Castle Game Engine.

As you see, I really like continuous integration/delivery. It’s a helpful automation doing a job for you and it’s really easy to set it up in various environments. I’m proud we have documented options to use it with Castle Game Engine.

It’s this weekend already!

Join Michalis Kamburelis and other Castle Game Engine developers, contributors and users at our 3rd meeting on Discord.

The meeting will happen at 15:00 (UTC timezone) on this Saturday, September 17th, 2022.

Simply join our Discord chat and go to #open_meeting channel.

You can just visit this link to land in the channel directly. Or use this link to see the event details (click on “…” to see options to add it to your calendar, mark it “I am interested” etc.).

Agenda:

1. Presentation of new CGE features. I’m sure we’ll have lots to talk about after our 7.0-alpha.2 release and I have more news coming this week 🙂

2. Our plans for the immediate future. I also hinted about them at the bottom of the 7.0-alpha.2 announcement — physics, memory optimizations.

3. Your turn! Everyone is welcome to take the stage:

   • Show what you are working on. Show your project, component, game, anything even loosely related to CGE is OK.

   • Any questions? We will be happy to answer them live.

P.S. The image in this post is of course Castle Game Engine editor showing pretty model from Sketchfab: SHIELD Helicarrier Meeting Room, by mohitpatel4078.

We are proud to announce the Castle Game Engine 7.0-alpha.2 release! After 18 months of intensive development since 7.0-alpha.1 we present a number of new features that upgrade the engine to a new level.

Go to our main page and follow the download links to get it now. You can also get the engine through itch.io.

Please support the development of the engine on Patreon. We count of your support to fund the development of the engine! Right now we hire developer Andrzej Kilijańśki (paid mostly from Michalis own pocket) who is responsible for many features in this release. Andrzej now works on new physics and joints components. We want to be able to hire more talented people, we want also to pay them from the funds on Patreon.

This is another stepping stone to a grand 7.0 stable release, planned (this time for real!) at the end of this year. Maybe there will be another alpha (7.0-alpha3) before that.

Notable new features in this release

1. Sprite sheet editor integrated inside CGE editor, using our own sprite sheet format (based on Starling).

   See sprite sheets (manual). Creating and using sprite sheets is also covered in recent CGE video tutorial.

   A large demo is in examples/platformer. It’s a complete platformer game that you can play, it is also released on itch.io.

2. More components you can place in a viewport:

   Simple geometric primitives: TCastleBox, TCastleSphere, TCastlePlane, TCastleCone, TCastleCylinder.

   Text, that can be in 3D: TCastleText.

   Image in a viewport: TCastleImageTransform.

   Reference the same transformation multiple times: TCastleTransformReference. e.g. to instantiate thousands of trees (see manual).

3. Components to configure fonts, from code and editor:

   TCastleBitmapFont, TCastleFontFamily, TCastleFont.

4. New sound components, they can also be used to design special sound in editor:

   TCastleSound and TCastleSoundSource .

5. Design lights, in CGE editor or from code, using new light components:

   TCastlePointLight, TCastleDirectionalLight, TCastleSpotLight.

   I also show this in recent CGE video tutorial. Also Phong shading is now default, making lights prettier.

6. Design backgrounds, with gradients and skybox:

   TCastleBackground component.

7. Design fog:

   TCastleFog component.

8. New camera and navigation handling:

   • You can edit TCastleCamera at design-time,
   • TCastleCamera is a regular TCastleTransform in a viewport,
   • you can have multiple cameras,
   • cameras can have children,
   • cameras can be children of something else,
   • adding navigation components is simpler.
   • See video about cameras and navigation.

9. Components to visualize terrains (TCastleTerrain) and generate terrain data from smooth noise (TCastleTerrainNoise) or image (TCastleTerrainImage) or a combination of them (TCastleTerrainCombine). See the examples/terrain. See this post for an overview.

10. While we don’t have a particle system available in CGE out-of-the-box, thanks to Trung Le (Kagamma) we now have a number of good options:

    1. GPU-based Particle System for Castle Game Engine
    2. Effekseer (Particle Effect Creation and Runtime) Integration

    See additional components for more components that you can use with CGE.

11. Ready files with documentation to use engine with GitHub Actions, GitLab CI, Jenkins. Just drop a file into your repo, and enjoy automatic builds!

12. Delphi support. Just configure in “Preferences” to use Delphi as compiler and/or Pascal code editor.

13. Build Debian packages for your projects (thanks to Eugene Loza).

14. Numerous smaller editor improvements:

    • Operating on files: double-clicking to open Pascal files (from file browser or output), easy creation of new states (with design and code), using any code editor (Lazarus, VS Code…).

    • Undo and other shortcuts in editor are now easier, like Ctrl+X, Ctrl+C, Ctrl+V, Ctrl+Z all do what you expect.

    • Choosing platform and release format in editor. You can even run Windows game build on Linux through WINE.

    • Various improvements to making custom components that also appear nicely in editor.

15. glTF improvements: step interpolation, cameras fix, normal scale handling, ability to pick subset of glTF.

16. Inspect your game hierarchy and logs at runtime — just press F8. See video about using the inspector.

17. Integration with Vampyre Imaging Library for most of our image formats. See examples/images_videos/image_display for a simple image display demo.

18. A few upgrades to our KTX image handling. We support now mipmaps in KTX, and ASTC compression.

19. Lots of Android building improvements, to make it as easy as possible..

20. Big macOS improvements. We now have Cocoa backend in TCastleWindow, and latest version of our engine is automatically rebuild and available for macOS users. See macOS (manual) and news about macOS.

21. A lot of documentation upgrades! The documentation is now up-to-date and nicely describes typical engine usage. A lot of new pages have been written, a of old pages have been rewritten or removed.

    Under the hood, most of the documentation is now using AsciiDoctor following my thoughts outlined here.

22. I’m also proud to list some deprecations and removals here. We managed to make the engine API more powerful but at the same time smaller and simpler to understand in this release! In particular:

    • TCastleWindow.SceneManager is gone. The TCastleSceneManager is deprecated. The advised new approach is to place TCastleViewport instance on TCastleWindow, you can trivially do it using code or in editor.

    • MainScene is deprecated. There’s no need to designate any scene as “main” for some engine features.

    • UseHeadlight is deprecated. You can add regular lights as children of TCastleCamera.

    • AutoCamera is deprecated. Design camera in CGE editor. To animate the camera, make it a child of animated bone exposed by ExposeTransforms.

23. This feature list is just a summary… All the engine news, from 7.0-alpha.1 announcement to today, span 130 news posts (!). Go ahead and browse them if you’re brave 🙂

Note: While this version is designated as “alpha”, the engine is ready to make production-quality, released games — in fact it already has been used for this.

For previous features, see already announced 7.0 features and 7.0-alpha.1 features.

Plans

For future plans, see our plans for 2022 and our roadmap. Immediate future plans are:

1. Integrate physics with joints from Andrzej Kilijański, see PR and teaser movie.

2. Optimize memory usage of X3D nodes. We’ve done the 1st stage: all nodes have auto-generated code to create all fields. So now we can revolutionize it.

Spread the word!

If you want to post about this release anywhere, of course go ahead — we depend on you to spread the word about the new release! You can let Michalis know (e.g. on Discord) where did you post it. Be sure to link, at least to the engine main page and to this news post.

If you’re looking for a shorter summary of new features (e.g. maybe because its more suitable to reuse somewhere) you can use the release summary from GitHub.

Have fun and create amazing games!

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!