Don't see the feature you need? Tell us on the forum:)
If you would like to see some feature implemented sooner, please support the engine development on Patreon!
Delphi compatibility (was planned for 6.6 release, postponed to 6.8)
As for the Delphi version: see here.
If you want to help in this effort by coding:
The suggested approach is to extend the existing "examples/delphi/base_tests/base_tests.dpr" to use more and more CGE units, fixing any Delphi compatibility that occurs (e.g. XML units, JSON units etc.).
The order of adding units can folow the map of dependencies. So first we make sure all/most from "base" compiles, then "files", then "images", then "fonts"...
Once we get to CastleUIControls unit compiling, we can implement TCastleControl on VCL and/or FMX, and actually display something.
Fully working visual editor
I outlined my details in this post. I want to edit things within Lazarus and Delphi (like GLScene and FireMonkey 3d), and I want to have a standalone editor (like Unity3d), and I want to edit at runtime too. And I think we can do it:)
More integration with physics engine. The details are listed in the manual about physics.
Mobile view3dscene (as Android and iOS application)
Associated with X3D and other 3D / 2D formats that the view3dscene (and Castle Game Engine) handles. Available in the App Store / Google Play Store. For free or for 1 USD (not sure yet; but definitely without ads, I really dislike ads).
I have not decided yet whether it would be based on our view3dscene source code, as desktop "view3dscene" contains a ton of GUI features that would not work comfortably on Android / iOS. Instead, we can develop a simple application that allows to open files, switch navigation type, turn on/off collisions and make screenshots (features that are available through the current view3dscene toolbar).
glTF format support and PBR
It supports meshes, advanced materials, animations. The file format is a readable JSON, but additional binary files are used to transfer coordinates, so it's fast to load from disk straight to GPU. It's also a Khronos format, so it's developed by people who really know what they are doing (the same people develop OpenGL[ES] and WebGL, Vulkan, KTX, Collada ...).
Because of this, it may (or already is?) become a widely supported 3D format across a range of 3D software. So we want to have really good support for it — reading all the features (including animations), and preserving the efficiency of binary-encoded meshes (to do this, we will probably invent some new X3D nodes).
Strategy of implementation (if you'd like to help, speak up!):
(This is already started in branch pasgltf:)
Create a unit
X3DLoadIternalGLTF, consistent with other such units e.g.
It should define a function
LoadGLTF that takes a URL and returns TX3DRootNode. See the examples in all other x3dloadinternal*.pas how to construct X3D graph, and read the documentation of our scene graph (X3D) to know what is possible.
LoadGLTF should be "registered", which for now just means that glTF should be added as a new format to X3DLoad unit. Just follow what other formats are doing (like STL) and add appropriate few lines.
LoadGLTF, read the file (using
Download(URL)) and parse it.
One approach to parsing glTF is to use Bero's PasGLTF. This is what I advice to try first. You will need to figure our the API by reading the source code and examples, but it should be straightforward. You will need to add PasGLTF along with dependencies (like PasJSON) to CGE source code, just like Kraft is added now (see in src/compatibilty/).
The stuff mentioned above is already started in branch pasgltf. You can use it, and CGE will be able to open glTF 2.0 files using PasGLTF, and output basic information about them on the log.
Only if PasGLTF will be unsuitable for some reason (but this is plan B, don't start with this!): We can also implement our own glTF reading. Just use FpJson (which is the JSON unit we already use for Spine loading and
CastleComponentSerialize) for the JSON part.
The initial task is to read meshes with transformations. I expect you will have to use nodes like
Once the above is working, we can look into more advanced glTF features:
Easily design a height map (X3D ElevationGrid node, with trees, rocks, grass). Saved and loaded as an X3D file.
Implementing this feature will most likely be split into a couple of small releases:
Edit the heights.
Edit the grass and trees and rocks.
Efficiently render huge amounts of grass and trees and rocks.
Implement nice shaders to show it, like this BareGame example.
What we have now: The engine includes a unit
CastleTerrain to generate terrains in various ways (most notably, from smoothed random noise). We have
examples/terrain/ demo to play around with it. We have the "Wyrd Forest" game that also uses
CastleTerrain, and also includes a simple editor of terrain settings.
What we need: Visual, interactive editor for the
ElevationGrid (the thing you get from
TTerrain.Node call). To make hills, valleys in a comfortable way. And comfortably plant there stuff (rocks, grass, trees...).
Blender X3D exporter improvements
Current Blender X3D exporter doesn't support animations, configuring collisions (X3D Collision node), 3D sound sources and more. We would like to fix it!:) This will be useful for everyone using Blender and X3D, not only with our engine.
Android Cardboard (VR)
Maybe also other VR devices — depending on demand, and our access to test devices.
Ready components to replicate data over the Internet
Allowing to trivially get multi-playter functionality in your games.
Maybe Metal renderer. Only maybe, as it's an API used by only one platform — iOS. So far, OpenGLES serves us good on iOS. In practice, this depends on the future, how much will Metal matter in a few years.
Maybe Direct3D renderer. Only maybe, as it's an API used only on Windows. So far, OpenGL serves us good. The rare platforms where OpenGL had problems on Windows are 1. really old right now (really old Intel GPUs), 2. we can consider using an OpenGLES->Direct3D bridge, like ANGLE, for them.
Help with this is most welcome. We have a simple example code that shows how you can start a new renderer: see new_renderer_skeleton.lpr. So get the engine from GitHub, and start changing the
new_renderer_skeleton.lpr. Just fill the
Larger scene processing and rendering improvements:
To smoothly fade in/out animation, with cross-fade between animations, for things played by TCastleScene.PlayAnimation.
Animation cross-fade time for creatures from resource.xml files could be configured using a CastleScript expression, so values like this could be possible:
fade_duration="0.5" fade_duration="animation_duration * 0.1" fade_duration="min(animation_duration * 0.25, target_animation_duration * 0.25, 0.5)"
Animation blending is already working, see here! However, it still has two TODOs for now (it does not yet work for castle-anim-frames or resource.xml).
Batching of shapes that have equal appearance for start, to optimize the rendering.
Make TCastleScene, T3DTranform and friends to be special X3D nodes
This would make the whole scene manager a single graph of X3D nodes, allowing for more sharing in code. The T3DTranform would be just like TTransformNode, but a little diferently optimized (but it would become toggable).
WebGL (HTML5) support
But this waits for the possibility from FPC to recompile to web (that is, JS or WebAsembly, probably through LLVM). Then our engine will jump on to the web platform. (Unlike the current web plugin, which is soon deprecated by all browsers, unfortunately.)
With a designer, probably.
Probably following the X3D "particle system" component, so it will be saved and loaded as an X3D file.
Example usage: blood, snow, rain, fire, smoke... 2D, 3D.
It would be nice to be able to export Blender particle engine to it, but possibly it's not really doable (different particle physics in Blender than X3D, we should go with own designer following more X3D).
(Note that we already have 2D particle system in CGE, see cge-2d-particle-emitter by Kagamma)
Support Material.mirror field for OpenGL rendering
(This feature is already in progress, but with somewhat different API: Instead of Material.mirror, we give you more straightforward way to use RenderedTexture for a mirror. This approach is different, doesn't look so perfect, but it has many other advantages, it is also more straightforward to maintain. So, for practical purposes, it replaces the Material.mirror idea.)
An easy way to make planar (on flat surfaces) mirrors. Just set Material.mirror field to something > 0 (setting it to 1.0 means it's a perfect mirror, setting it to 0.5 means that half of the visible color is coming from the mirrored image, and half from normal material color).
Disadvantages: This will require an additional rendering pass for such shape (so expect some slowdown for really large scenes). Also your shape will have to be mostly planar (we will derive a single plane equation by looking at your vertexes).
Advantages: The resulting mirror image looks perfect (there's no texture pixelation or anything), as the mirror is actually just a specially rendered view of a scene. The mirror always shows the current scene (there are no problems with dynamic scenes, as mirror is rendered each time).
This will be some counterpart to current way of making mirrors by RenderedTexture (on flat surfaces) or GeneratedCubeMap (on curvy surfaces).
Make a demo showing how to use Castle Game Engine together with RNL - a real-time network library, in Pascal, very suitable for games, by Benjamin Rosseaux.
Advanced networking support
Basic networking support is working already, see the manual.
Missing features / ideas:
Bear in mind that future engine version should work under both FPC and Delphi, so choosing one library that works under both FPC and Delphi is a plus.
So that you don't need to hang waiting for download.
The API design is already inside
look for the line "API for asynchronous downloader is below, not implemented yet".
Using threading (
TThread) to implement this is optional, as you can update the data
ApplicationProperties.OnUpdate in the main thread
(if only you use non-blocking API like LNet).
Note that you need to use non-blocking API anyway (as we must be able to cancel
the ongoing download, and you cannot instantly unconditionally terminate a running
Using threads may still be reasonable for efficiency (no need to slow down
the main thread), but then it should be 100% invisible to
the user of
TDownload class. From the point of view
of engine user, the
TDownload must be available in the main thread.
This will also enable cancelling the ongoing download.
Maybe add a "cancel" button to
CastleWindowProgress to cancel
ongoing view3dscene downloads.
(Low priority) Support for
ftp. By using LNet or Synapse, unless
something ready in FPC appears in the meantime.
Both LNet (through LFtp unit) and Synapse (FtpGetFile) support ftp.
(Low priority) Support for HTTP basic authentication. This can be done in our CastleDownload unit. Although it would be cleaner to implement it at FpHttpClient level, see this proposal. Or maybe just use LNet or Synapse, I'm sure they have some support for it.
(Low priority) Support X3D
(Low priority) Caching on disk of downloaded data. Just like WWW browsers, we should be able to cache resources downloaded from the Internet.
Note: don't worry about caching in memory, we have this already, for all URLs (local files, data URIs, network resources).
Easy way to use 3rd-person camera movement in your games.
Make 100% rendering features available on OpenGLES too.
Use Cocoa under macOS
We already have a native look and feel, and easy installation, under macOS by and using LCL with Carbon or Cocoa on macOS. Our programs do not have to use X11 and GTK under macOS.
However, the current solution is not optimal. Carbon is deprecated and only 32-bit (so memory is limited). Cocoa is not stable in LCL yet. Depending on LCL has it's own problems (mouse look is not smooth with LCL message loop).
The proposed task is to implement nice Cocoa backend
CastleWindow unit. You can of course look at LCL implementation
of Cocoa widgetset, but I expect that we can implement it muuuch simpler
(and more stable) as CastleWindow backend.
Contributions are welcome.
This is an easy and rewarding task for a developer interested in macOS.