Recently I did a little reading about what is “gamma correction” in computer graphics. It’s actually a simple concept with a simple implementation (at least in the basic approach), and I summarized my knowledge here: Gamma correction in X3D and glTF.
I made a cool online tool using Castle Game Engine:
It allows to
- Convert from any format supported by Castle Game Engine (glTF, X3D, VRML, Wavefront OBJ, STL, Collada, 3DS, MD3, Spine JSON…).
… into X3D, in XML or Classic (VRML) encoding.
Underneath, it uses tovrmlx3d (command-line application distributed
together with view3dscene).
It’s free to use for everyone. It’s of course open-source, both the tovrmlx3d and view3dscene, and a set of scripts (PHP, Docker and shell scripts) to make it work as an online tool in a secure and reliable way.
More information on the tool page. Give it a shot, test your models on it! 🙂
We now support Spine “Free-form Deformation”, which allows to animate (deform) the mesh by moving particular vertexes around. This is a great feature to animate e.g. facial expressions.
A demonstration how it works in CGE is here. An instructive video how to create FFD animation in Spine is here. We also have a sample model using it inside our demo models, in spine/free_form_deformation.
Big thanks go to Trung Le (kagamma) for implementing this!
Thanks to Andrzej Kilijański, our physics integration is now secure from the “spiral of death” that could occur when the physics simulation takes a long time to calculate (and, in effect, physics would need to account for larger and larger time spans, taking even more time).
It works automatically, but you can adjust Viewport.Items.PhysicsProperties.MaxPhysicsTicksPerUpdate to tweak it.
I made lots of updates to our manual and CGE examples, such that they describe the most advised way to use CGE API (after recent refactors). Almost everything now uses the TCastleViewport and TCastleWindowBase and initializes navigation and camera in a simple way.
As the 2019 is ending, it’s a good moment for a summary. What did we achieve, and what do we want in 2020?
- First of all, I’m very happy with a huge number of new engine features. This includes CGE visual editor, significant improvements to the important APIs (viewports, cameras, user interfaces), Nintendo Switch support, glTF support.
This leads me also to our most critical TODO for 2020: We really need to release the next CGE version 7.0, as a “stable” version. Yes, it will be called 7.0 (not just 6.6) — we have a number of new major features (and some unavoidable incompatible changes).
The release-blocker now is making the “gizmos” to allow to comfortably transform
TCastleTransformin the editor.
I want to say enormous “thank you” to everyone who contributed to the engine in 2019, or made games using CGE. In particular big thank you goes to the Eugene Loza, Andrzej Kilijański and Kagamma for your pull requests and all the conversations.
This point also leads me to another TODO: I want to manage our work better. We want to make the best open-source game engine, and I’m not going to stop until we get there 🙂 For this purpose, I created public Trello boards to manage CGE work. If you’d like to join CGE on Trello, just let me (Michalis) know. Everyone is invited.
Note that Trello is not supposed to replace GitHub issues. GitHub is still great to submit bugs (issues) or PRs. But Trello may be better to organize tasks (by task here I mean ““something that needs to be done”, which isn’t always a bug, and some tasks have complicated dependencies — some tasks are blocked by other tasks, have subtasks etc.). I feel that Trello is great to manage such tasks.
Technical most important features to implement in 2020:
Delphi compatibility. You asked for it, and it’s started. It will open us to a whole new pool of engine users (and potential contributors).
Support glTF skinned animations. glTF is becoming the de-facto standard for interchanging 3D animated models. We already support glTF, but we miss this important feature.
Physically-Based Rendering. I’m leading the X3D 4.0 specification changes related to this. We want to finish the spec in January, and later implement PBR in CGE.
That’s it, in summary. Of course I have more plans 🙂
Have the best 2020! Let’s make good code, and good games. We are open-source, we love writing code, we love telling stories, we love designing fun games. Let’s do it:)
This week I finished the last big engine API change before the next release!
TCastleSceneManager is now deprecated: instead you should use TCastleViewport to display 3D models. This makes things much simpler, and it allowed me to make
TCastleViewport defaults much better.
A simplest working source code demonstrating this (it will compile — get the engine and test it!) looks like this:
uses SysUtils, CastleWindow, CastleSceneCore, CastleScene, CastleViewport, CastleCameras, CastleVectors; var Window: TCastleWindowBase; Viewport: TCastleViewport; Scene: TCastleScene; begin Window := TCastleWindowBase.Create(Application); Window.Open; Viewport := TCastleViewport.Create(Application); Viewport.FullSize := true; Viewport.AutoCamera := true; Viewport.AutoNavigation := true; Window.Controls.InsertFront(Viewport); Scene := TCastleScene.Create(Application); Scene.Load('data/bridge_final.x3dv'); Viewport.Items.Add(Scene); Viewport.Items.MainScene := Scene; Application.Run; end.
See the CGE examples: 3d_rendering_processing/view_3d_model_basic.lpr for a complete code with some additional comments.
The advantages of the new approach:
- The API is simpler (easier to explain and use).
Previously, TCastleViewport was in most practical cases reserved for “secondary viewport”, that shows something also visible in the “primary viewport”. The “primary viewport” was TCastleSceneManager with
DefaultViewport = true. This entire complication (and complication of terminology – “how is scene manager different from viewport”) no longer exists.
Now you just use TCastleViewport to display a world (composed from a tree of TCastleTransform and TCastleScene). Period.
To have multiple viewports (cameras) display the same world, simply assign the
Itemsproperty of one
TCastleViewportto another. You can also create your own
TCastleRootTransforminstance and assign it to as many
TCastleViewport.Itemsproperties as you want. Demo of this is inside CGE examples: 3d_rendering_processing/multiple_viewports.lpr.
So all previous use-cases are covered in a more natural way.
Moreover, this allowed me to minimize compatibility break while still changing some defaults. Since
TCastleViewportwas so seldom used, we change it’s default properties:
- TCastleViewport.FullSize is now by default false
- TCastleViewport.AutoCamera is now by default false
- TCastleViewport.AutoNavigation is now by default false
FullSize=falsedefault is consistent with all other UI controls. This way it is less surprising (when instantiating from code or in CGE editor).
AutoNavigation=falseare better defaults after recent camera refactor. The “false” default on these properties makes more sense — while the auto-detection is nice for quick demos, it is bothersome and sometimes surprising for non-trivial applications, so it’s best to have the auto-detection “off” by default.
TCastleSceneManagerthese defaults do not change (as it would undoubtedly cause a lot of breakage, since you use
TCastleSceneManagerso much in existing applications).
2. TCastleWindowBase, TCastleControlBase
- This way you don’t have a default viewport (scene manager) instance, which avoids some traps (the default navigation may catch some keys), and it is often not necessary.
This way you create the TCastleViewport yourself, as many as you need. So you have more power over the engine. This way it is clear that TCastleViewport is just a regular user-interface class: you can create it as many times as needed, you can position and resize it however you like.
Rafael Campos submitted a new game using Castle Game Engine. Race against the clock to complete the three tracks: park, city and beach. In order to win you will must evade the obstacles and your competitors.
This game was submitted to the game jam “I’m using a lot of assembly language” also hosted by Rafael. 50% of game code is assembler (14000 lines of ASM code), which main objective is the subdivision of 3D triangles.
By the way, I also reworked our Gallery, and added various missing entries. It is now split into:
November/December engine improvements:
We no longer use the GtkGlExt library on Unix. It was not necessary (we had a code to initialize OpenGL directly using glX on X11, and it is simpler). And this way user has one less library that needs to be installed before our application can be run.
You can specify in CastleEngineManifest.xml to build using lazbuild. This way our build tool and editor run under the hood lazbuild instead of “bare” FPC. It’s quite useful if your application uses some Lazarus packages (like LCL). For caveats see the documentation of
New version of model_3d_with_2d_controls example shows how to use CGE editor within Lazarus (LCL) application. We design CGE UI in CGE editor, and then load it into
TCastleControlBaseon a regular Lazarus form.
Reimplemented TCastleInspectorControl, it is much more useful now to inspect the UI hiierarchy. Just add it to your window like
Window.Controls.InsertFront(TCastleInspectorControl.Create(...)). Toggle visibility with F12.
I’m working on introducing PBR to X3D specification, and then to CGE! We’ve talked a lot, and my pull request to introduce it into the Web3d specification is in-progress. We also have some initial examples how it will look like. In short: there will be a new node
Log file location changed on Windows: We cannot assume we can write into the directory of the exe (because we cannot, e.g. if exe is in read-only “Program Files”). Instead we write into the log in user config directory. You can use LogOutput to print this value. See the new, extended manual page about logging.
We’re proud to present a new game made using Castle Game Engine: Bricks Color Pick. It’s a new approach to the classic arkanoid games, with a twist: there is no paddle. The challenge is to switch the color of the ball to match the bricks. You need to do it quickly — because the ball will bounce all around the level using physics.
Made by Andrzej Kilijański who also wrote a lot of articles about Castle Game Engine. Andrzej also submitted a number of pull requests related to our physics support (based on Kraft) — and now we know why 🙂
Check out the game on your Android, it’s completely free!
We were incredibly busy lately, preparing the release of The Unholy Society for PC (Windows, Linux) and Nintendo Switch. It’s a game by Cat-astrophe Games, using Castle Game Engine, programming by two of CGE developers — Michalis Kamburelis and Eugene Loza. Check out our trailer and game information on the game page and wishlist us on Steam!.
In the meantime, we have a number of improvements to the engine from November:
We have exposed methods to perform “mouse look”. They can be used to make mouse dragging without being constrained by window borders. New demo of both dragging methods is available in examples/2d_standard_ui/dragging_test.
We support a new Spine feature to export a single atlas for multiple skeletons. It’s quite cool, often allows to significantly reduce the total necessary atlas sizes. To use it, you need to open Spine file through an URL like this:
my_animation.json#atlas:my_atlas_nameinstead of just
my_animation.json. See our Spine documentation for details.
New OrientationInterpolation2D allows more efficient 2D rotation interpolation. It is automatically used by Spine animations.
Our build tool allows to configure package format by
--package-formatoption (allowed values for now are: default, directory, zip, targz). You can also configure whether version number appears in the resulting filename by
Application.ParseStandardParameterswill now automatically handle the
--log-filecommand-line option, that allows the user the configure output log file. Note that, in order to make this work, you should not call
InitializeLogbefore command-line options are parsed. Our examples, like portable_game_skeleton, show how to do this.
The default sound “importance” is now 10, instead of “maximum”. This seems much more reasonable. See our new docs of sounds XML files.
To celebrate #ThankYouPatrons day in the weirdest and most-programmer-friendly way possible, today we merge into the “master” branch of Castle Game Engine a big refactor of the camera code! This is a huge work, started 4 months ago, and causing 110 new commits.
It includes a number of new inter-connected features:
The API to control the camera (viewer position, direction, up, projection etc.) and navigation is now much simpler. Check out API docs about new
You can now configure both camera and navigation visually, using the CGE editor.
When you select a viewport (most usually a
TCastleSceneManagerinstance), or anything inside a viewport (like a
TCastleScene), there will appear a new set of buttons on the toolbar. The “hamburger” button there contains a menu with useful operations to configure camera and navigation. The “initial” camera vectors will be stored in the design, as well as the chosen navigation component.
(The buttons to translate/rotate/scale scenes are not yet handled — coming soon!)
We split previous camera class into two concepts, TCastleCamera (“what is current viewer position/orientation and projection”) and TCastleNavigation (“how to handle user input to change the viewer position/orientation”).
This caused a lot of work to make it right, and also to keep backward-compatibility as much as possible. I’ll list reasons for making it in another post — it’s a story in itself.
We provide easy means to turn off “auto-detection” of camera and navigation. Just set
I recognize now that this “auto-detection” is sometimes undesired or even surprising. I would advise most games to set both
AutoNavigationto false right after creating
TCastleSceneManager. CGE editor will do it by default too, soon.
TCastle2DSceneManageris now deprecated, as it is useless. You can now easily request orthographic camera with
Setup2Dmethod, or just set yourself
Camera.ProjectionType= ptOrthographic and configure
Camera.Orthographicproperties). This makes things much simpler. We never needed any special class for 2D, our
TCastleSceneManageris for both 2D and 3D — now it’s obvious 🙂
It is now configurable which camera (from which viewport) controls “central” features like headlight, X3D ProximitySensor, audio listener. Set
CGE editor received a number of smaller improvements along the way. E.g. you can now duplicate (Ctrl + D) transformations/scenes too, assigning
SceneManager.MainSceneand other references works.