Optimizations and improvements to our renderer

Posted on


Last week we did an important fix for glTF skinned animation combined with normalmaps. It fixed the problem with incorrect lighting, but also made the code a little slower in case of skinned animation + normalmaps (we had to turn “off” one optimization). To counteract this, I’m reworking a relevant part of CGE renderer, to not only bring the old optimization back, but also optimize it even more, and bring other small improvements.

It’s a work-in-progress, but we already have:

  1. Colors per vertex passing optimized (faster copy, 3/4 less data for RGB colors).

  2. Custom shader attribute passing optimized (faster copy) and fixed for non-indexed primitives (see demo file).

  3. Tangents and bitangents passing optimized (pass 2/3 less data due to not duplicating normal info).

Comment on this post (2 comments now) ➤

Using 3ds Max and Maya to create assets for Castle Game Engine

Posted on

Export from 3ds Max to glTF using Babylon
Exporting from Maya

Thanks to our glTF support, you can export to CGE from the latest 3ds Max and Maya versions. We have updated our documentation:

Thanks go to Andrzej Kilijański for updating these pages!

Being an open-source engine, done by open-source fanatics, we of course remain committed to perfect Blender support 🙂 As a reminder, our Blender exporting documentation is here.

So we really want to cover all our bases here. Whether you like Blender or a big proprietary 3D modeling software from Autodesk — you can use Castle Game Engine.

Comment on this post ➤

Various improvements (component gallery started, image loading optimizations, metadata, more)

Posted on

Zrzut ekranu z 2020-11-28 04-00-17
Zrzut ekranu z 2020-11-28 04-00-24
Zrzut ekranu z 2020-11-28 04-00-12

An unorganized list of new things implemented in Castle Game Engine lately:

  1. I started an important engine example: component_gallery. Right now it’s an extensive demo of TCastleButton possibilities. It will be extended with more pages soon.

  2. We made significant image loading optimizations. Loading PNG is now much faster on platforms where we don’t use libpng (Android, Switch). Loading JPG is now faster everywhere.

  3. We have a new API for getting/setting metadata on X3D nodes, with example in examples/short_api_samples/metadata/.

  4. We bump our Android API to 29, to satisfy latest Google requirements. Our Docker images have been updated to contain the appropriate version by default.

  5. AutoSizeToChildren reimplemented to be much more flexible, suitable for any anchor.

  6. Selecting of dragon in 2D template fixed.

Comment on this post ➤

New comfortable way of using sprite sheets (and images) in viewports

Posted on

Sprite sheets in Castle Game Engine editor

Thanks to a great work by Andrzej Kilijański, we now have a brand new way of using sprite sheets in Castle Game Engine: you can load sprite sheets to TCastleScene and arrange them within a TCastleViewport.

This means that you can load, display, transform, animate sprite sheets just like all other scenes. Refer to our manual, in particular chapters about loading, displaying and transforming, animating. Everything described there now just applies to sprite sheets.

This also means that you can arrange sprite sheets in CGE editor.

See the sprite sheets documentation for details.

To use this, you need to express sprite sheets in the Starling or Cocos2d format — but we have a plan to make this operation trivial using the CGE editor.

Demo files are in our demo-models repository, explore the cocos2d_v2, cocos2d_v3 and starling subdirectories.

As an additional cool bonus, you can also now load 2D images into TCastleScene. Underneath, we construct a simple textured rectangle that shows the image. This is also extensively documented.

A demo of using the new approach to easily build a game is coming too (you can observe a ticket).

Comment on this post ➤

Upcoming Debian conference CGE talk, video from Web3D 2020 talk, engine improvements: new 2D geometry primitives, no more libGLU

Posted on

Michalis Kamburelis talking at Web3D 2020
  1. I’ll give a presentation about Castle Game Engine at MiniDebConf Online #2 “Gaming Edition”, an online Debian conference devoted to game development. The presentation is already recorded :), and I hope it is good. I focus on Castle Game Engine editor. I create a 3D level in Blender and put it in a 3D CGE game, I do some code editing, and I build a 2D game for Android too — all in 38 minutes. I hope it will serve as a nice introduction to CGE, from scratch, going over the core engine/editor features and showing how to use it in practice.

    Afterwards there will be ~7 minutes for live questions.

    My presentation starts on Sunday, 22 November, 13:30 UTC, see schedule.

    You’re most welcome to attend 🙂

  2. As a teaser, see the presentation about CGE + view3dscene for Web3D 2020 that was this Wednesday. This is 21 minutes, and focuses on graphic features we offer in view3dscene (I mention there CGE, but don’t go into details how to use it from developer perspective).

  3. I implemented some additional X3D nodes to describe 2D geometry: Disk2D, Polyline2D, Polypoint2D, TriangleSet2D.

  4. We no longer depend on libGLU, even on desktops where we use OpenGL (not mobile OpenGLES) by default. This was a long-time coming move. The remaining usage of libGLU in CGE eliminated:

    1. You can use TCastleScene with X3D geometric primitives (like TSphereNode, TDisk2DNode and more) to render “quadrics” (previously, 2 old CGE examples used libGLU for this).

    2. We have own routine to generate mipmaps for ancient GPUs (on modern GPUs, we use glGenerateMipmaps since a long time of course).

Comment on this post ➤

Various improvements (blending documentation, AvoidNavigationCollisions fix, buttonXxx renames, CastleXMLUtils example…)

Posted on

Ship in the bottle - Model by Loïc Norgeot from https://sketchfab.com/3d-models/ship-in-a-bottle-9ddbc5b32da94bafbfdb56e1f6be9a38 (Creative Commons Attribution-NonCommercial)

I’m happy to be swamped with things to announce about the engine! 🙂 So, after previous announcements this weekend, one more list of new stuff 🙂

  • We have an extensive documentation how blending (partial-transparency) works. While the engine tries its best, it’s not always possible to make blending automatically “just work”. This documentation should help you understand what and why you can tweak.

  • We have important fixes for edge-cases when handling MessageOK, progress bars or TCastleViewport.AvoidNavigationCollisions by Andrzej Kilijański.

    Moreover, Andrzej submitted a big PR that introduces a huge upgrade to handling sprite sheets in CGE. It is under review now (i.e., waiting for Michalis 🙂 ), stay tuned!

  • We have renamed mouse button names/types to buttonXxx and TCastleMouseButton. This way they do not conflict with LCL. The old names mbXxx still remain, but are now deprecated, and we will be able to remove them in later CGE (7.2?). Thanks to Eugene Loza!

  • In the editor, we now expose “Scene (Optimal Blending for 2D Models)”, which is just TCastleScene with Setup2D performed.

    It is better than the now-deprecated TCastle2DScene. Dealing with TCastle2DScene was sometimes uncomfortable: when you wanted to derive descendants and mix 2D and 3D models in your game. And existence of TCastle2DScene was not really justified: in the end, it is a completely trivial variant of TCastleScene, the Setup2D just sets "RenderOptions.BlendingSort := bs2D" (really, that’s it! nothing more needed for 2D scene).

  • I added an example of using CastleXMLUtils unit in examples/short_api_samples/xml_utils/.

  • Our Jenkins (see wiki docs) is now integrated with GitHub, and it sets “build status” on GitHub. This means we can quickly recognize failing commits, branches, PRs etc.

    ( It’s not always the fault of the branch/PR author, so don’t worry — I’m diagnosing all fails and will let you know if this is something you need to take care in your PR. )

Comment on this post ➤

Screen Space Reflections effect, enhancements to GLSL API for effects

Posted on


With many thanks to Kagamma (Trung Le), we now support screen-space reflections in Castle Game Engine! It is a cool technique that generates reflections completely in screen-space, using color and depth buffer information to look for the reflected color.

It is trivially easy to use, just toggle TCastleViewport.ScreenSpaceReflections boolean. As we don’t have material information available in screen space (yet, because we do not have deferred rendering), so everything in the whole viewport is reflective now. That said, the effect is extra pretty and just works “out of the box” on various scenes, so I’m sure it will find it’s use even in current “everything is reflective” form 🙂 You can configure glossiness for the entire viewport by TCastleViewport.ScreenSpaceReflectionsSurfaceGlossiness (in 0..1 range, by default 0.5).

You can also test it with view3dscene, just toggle menu item View -> Screen Effects -> Screen Space Reflections.

Our screeen effects GLSL API also got a small upgrade by the way. We now expose screenf_01_position varying and functions screenf_01_get_color(...) and screenf_01_get_depth(...) to quickly query the screen.

More upgrades to screen effects are coming. I would like to wrap screen effects in components, designable in CGE editor!

Comment on this post ➤

Render options configurable in editor

Posted on

Roseanne from "The Unholy Society", https://unholy-society.com/

You can now configure RenderOptions of every TCastleScene. Simply access it like MyScene.RenderOptions.OcclusionQuery := true. It is available also in the editor, as you can see on the screenshots 🙂 All the features are documented in TCastleRenderOptions class, in particular you can:

This mechanism replaces (and deprecates) previous Scene.Attributes.

As part of this rework, we also deprecate or even remove some stuff that had very low usage.

In particular, Scene.Attributes.OnRadianceTransfer and Scene.Attributes.OnVertexColor are now removed. They were causing quite a complication throughout the renderer, and were never ready for “production” usage due to being inherently slow (doing per-vertex work on CPU). Their effect can still be achieved by a simple utility that maintains the X3D Color node, updating it every frame. So if you need this (and can accept the slowness of per-vertex processing on CPU) you can still do it, our sceneutilities.pas example unit demonstrates this in practice, and is used by dynamic_ambient_occlusion and radiance_transfer examples. Feel free to reuse SceneUtilities in your projects in you need an upgrade path from the OnVertexColor and OnRadianceTransfer.

Comment on this post (4 comments now) ➤