New TCastleSceneCore.Cache property allows to load the scene contents through a shared cache. If you have multiple TCastleScene loaded from the same URL, this is a sure way to speedup loading of them.

Testcase: examples/viewport_and_scenes/occlusion_culling, where I set up multiple buildings and creatures from the same glTF.

Alternative: You can actually achieve even more optimization (loading time, memory use) using TCastleTransformReference or (equivalent internally) just adding the same TCastleScene instance multiple times to the viewport. These techniques allow to really have one instance and just draw it multiple times — this is a much more powerful optimization, but also puts more constraints: all the referenced things must have the same animation, occlusion culling doesn’t work on them etc.

In contrast, using TCastleSceneCore.Cache is much safer, it doesn’t really change how things work at all from the developer perspective. Each scene may be in a different state, play different animation etc. We just internally load them faster. And it is simpler to use, just toggle the Cache checkbox and observe the speed boost.

Related: Do you want to measure the loading speed, e.g. to compare what do you gain by cache? See the advise about “profiling” in our manual. To cut the long story short, I advise to do Profiler.Enabled := true in your initialization, and observe the report about what takes time at initialization in the log. For more about TCastleProfiler, see the API docs.

How this cache works now, and what is the future: Right now, it works by internally storing the nodes graph in the cache, and instead of loading a file again — we can just do TX3DNode.DeepCopy to clone the graph. This is nice, but actually in the future it could be even better: if we change how our animations work to do not modify the graph, then actually all cached scenes could just use one and the same graph. This is a possible future optimization.

If you like this, please support us on Patreon!

You know the drill — our quarterly meeting on Discord, open to everyone, is this weekend! Join us and talk about Castle Game Engine 🙂

The meeting will happen at 15:00 (UTC timezone) this Saturday, March 18th, 2023.

Simply join our Discord chat and go to the #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. We have a lot of stuff from lately done features and I actually hope to add some more before Saturday 🙂

2. Our plans for the immediate future.

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.

   Do you have any questions? We will be happy to answer them live.

Our OpenGL and OpenGLES code is now more streamlined, which allowed to “unlock” various rendering features on OpenGLES.

This means we will use some features from OpenGL ES 3.0, if it is available:

• Occlusion Culling, that is also showcased in a new demo examples/viewport_and_scenes/occlusion_culling.

• 3D textures (example data in demo-models, look in texturing_advanced subdirectory).

• Using glBlitFramebuffer to get FBO results to image.

• Modern way to query OpenGLES extensions by index.

• Fixed, and more efficient than ever on mobile, shadow maps using shadow samplers in OpenGLES 3. I already mentioned shadow volumes and shaow maps improvements on mobile in past news.

• Loading DDS and KTX with explicit mipmaps (using GL_TEXTURE_MAX_LEVEL).

Note that we still require only OpenGL ES 2.0. The OpenGL ES 3.0 features are optional for us.

Moreover:

• Anisotropic filtering is now supported on OpenGLES, through an almost universally-available extension, just like on the desktop. See e.g. anisotropic_filtering demo. (Yeah, we should have a more comfortable way to adjust anisotropic filtering visually — I have 2 ideas about this, will explore them.)

• We also fixed support for rendering shapes that require 32-bit indexes. While OpenGLES 2.0 guarantees only 16-bit indexes (OpenGLES 3.0 bumps it to 32-bit), we now automatically deal with it inside a renderer, if necessary doing additional processing to enable bigger meshes even for OpenGLES 2.0. This can be tested using fps_game on mobile.

Many laptops come now with 2 GPUs: a slower one that consumes less battery and a “dedicated” GPU consuming more battery but capable of much better speeds, esp. when used with non-trivial 3D data. The CGE editor and your applications automatically use the “dedicated” GPU now.

More information about this feature, the documentation how to disable it, and how to upgrade your existing projects to follow: Dedicated GPU.

1. New component TCastleMask allows to define a mask (using an arbitrary UI control) and use this mask to limit rendering the children.

   The mask may be any UI control (or a composition of it). The colors do not matter, only which pixels are drawn by the mask. E.g. you can define a mask using

   • An image (TCastleImageControl) with alpha channel. Be sure to set TCastleImageControl.AlphaChannel to acTest.

   • A viewport (TCastleViewport), maybe even with something animated and/or 3D. Be sure to set TCastleViewport.Transparent to true.

   • A shape (like TCastleRectangleControl, TCastleShape).

   The masked children, in turn, can also be any UI control. So you can filter rendering of anything, even if it’s interactive (like a button) or 3D (like a viewport).

   TCastleMask.MaskRendering determines if the children are rendered where the mask is visible or (on the contrary) where the mask is not visible.

   See the example examples/user_interface/mask for demonstration.

2. I improved the default look of our sliders (TCastleFloatSlider, TCastleIntegerSlider).

   These sliders are quite useful, esp. for various demos and tools (view3dscene uses them to test animations and lights). Well, they no longer look ugly 🙂 and their design allows an optional label inside (useful to communicate to user exact numerical value behind the slider).

3. I implemented a special way of treating protected sides for images. By default they do normal 9-slice scaling but a new option allows to scale corners horizontally to match the image height: TCastleImagePersistent.ProtectedSidesScaling, pssMatchHeight.

   Admittedly it’s a bit easier to see than to explain with words, so if you’re curious, just try it out with an image like SliderBackground that has exactly circular left and right endings. Thanks to the new option, they will stay circular, no matter how you resize the slider.

X_ITE is an open-source JavaScript library to display X3D (and a number of other formats) in a web browser, using WebGL. It was recently extended to import additional formats, and render them straight away or convert to X3D. The supported formats are now: X3D, VRML, glTF (GLB), OBJ, STL, and SVG.

There is an accompanying online converter to X3D and a command-line converter x3d-tidy that perform the conversion using X_ITE underneath.

In a way, this is similar to what we do in Castle Game Engine, where we also load everything (like glTF) to X3D nodes, give you an online converter and a command-line and GUI converter.

But there’s also a big added value: X_ITE supports SVG. SVG (scalable graphics, create it e.g. in Inkscape) gets converted into proper geometry in X3D, so it remains scalable and can be used as part of your 2D or 3D game in CGE! This is what I enjoy about being part of an ecosystem and open formats like X3D — we get new features “for free” thanks to cooperation with others.

Note that in the generated X3D file, all objects will be placed at the same depth, Z = 0, at least right now. You may have to fix it to avoid Z-fighting in case SVG layers overlap. For simple cases, it is possible to do this by just manually editing the X3D file in any text editor. Assigning meaningful names to your objects in SVG, e.g. using Inkscape “Object Properties”, also helps. I have done it with a non-trivial SVG file (our engine logo) and the manual effort was ~easy 🙂

See the result of my play in demo-models/svg. It shows how to fix Z, I also add a shader effect to discard pixels outside of a circle in the middle, to “cut off” stuff that should not be visible in a circular engine logo.

I encourage you to test the converter and explore X_ITE in general. Many thanks go to Holger Seelig for an amazing work on this!

This is probably not the most sexy graphic effect announcement :), but the lines and points are useful to visualize a lot of things.

We have improved our glTF support to properly import points, lines (lines, line strips, line loops), and their materials.

We have also improved our X3D nodes capabilities by introducing TIndexedLineSetNode.Mode and TLineSetNode.Mode. This allows to comfortably and efficiently define lines, line strips, line loops in X3D.

Thanks to recent rendering code improvements, we can finally request “core” profile on macOS, to get latest OpenGL version (4.1 in my case) instead of being stuck with legacy OpenGL 2.1 on mac.

We request now a modern context on mac, both with TCastleWindow and TCastleControl. This applies to all our software — CGE editor, view3dscene, all your applications you build with CGE.

You can use the new TCastleRenderUnlitMesh utility class to render unlit 3D objects easily. It has a nice API when you want to render a set of vertexes and then forget about them — sometimes this is easier than setting up the shapes in TCastleScene. It may be especially useful for rendering debug 3D geometry, in fact view3dscene is already using it for this purpose.

An example usage is in test_rendering_opengl_capabilities example, in unit gamemymesh.pas.

Moreover, thanks to this class (and some other improvements I’ll describe in subsequent posts) we have upgraded our shadow volumes code, making it simpler and working with mobile OpenGL ES, without losing any performance. You can test shadow volumes on OpenGLES e.g. using examples/viewport_and_scenes/shadows or by creating a new project from “3D FPS Game” template.

And while we’re at it, our shadow maps code was also fixed. It now works on OpenGLES in much the same way it does on desktop OpenGL.

Note: This is not the end of shadow maps upgrades. They are still not as straightforward to activate as they should be, and they don’t cast shadows on multiple scenes. More work on shadow maps is coming 🙂

First, a reminder that our DelphiCon presentation is in ~3 hours, 2:00 PM in Central Standard Time. See DelphiCon 2023 to register, you can also just watch the live stream on Embarcadero YouTube. I hope you will enjoy it! I will be of course present during the presentation, go ahead and fire questions at me:) See also more talk information here.

Second: Game Industry Conference recently published a recording of my presentation there, from October 2022. It’s just 30 minutes, and it’s really a very different talk from DelphiCon, I talk about the engine high-level decisions (like glTF, X3D), motivation, thoughts on making open-source game engines (declarative, evangelism). The slides from GIC presentation are also available. So, if you can’t wait to see me :), I encourage to watch GIC 2022 talk now: