Month: May 2021

New components in Castle Game Engine that you can place inside the viewport

We have a few new components in CGE, working perfectly with CGE editor:

• TCastleBox
• TCastleSphere
• TCastlePlane
• TCastleCone
• TCastleCylinder
• TCastleText

You can add them inside editor. They descend from TCastleTransform, so add them somewhere inside your Viewport.Items hierarchy, and they are 3D (e.g. TCastleText can be freely rotated in 3D, unlike 2D-only TCastleLabel). They expose a lot properties you would expect:

• size,
• material (simple properties to set material type and main color),
• texture (and normalmap),
• toggle visibility of sides/bottom,
• double-sidedness,
• rendering options (wireframe etc.),
• text size,
• text spacing,
• text alignment (horizontal and vertical).
• Notable TODO: the TCastleText font (and it’s quality, to avoid it being blurry at large sizes) is not yet adjustable. See below about plans.

Using these primitives allows to quickly set up some 3D environments in CGE editor. I think it is extremely useful for quick prototyping of 3D content, creating a scene from a composition of simple primitives or adding simple primitives to something more complicated (e.g. to TCastleScene using glTF). You don’t need to use Blender to create trivial 3D things 🙂

Previously this all was possible, but not always comfortable, and not in CGE editor. You can of course create 3D geometry primitives by directly creating X3D nodes, and you get extra flexibility (you can e.g. customize all material/texture parameters — our above primitives expose only a simple API to adjust material/textures). But this approach is not available visually, in the CGE editor. We have various ideas to “converge” these 2 approaches — one is to introduce a visual editor for X3D nodes, but adding this inside a CGE editor to make it really “seamless” is not easy task. Moreover, the experience showed that simpler CGE API, that hides X3D nodes and some of their complications, is often much simpler to use — so we play both sides, making X3D API simpler to use in CGE, while also hiding X3D in many places.

Upcoming new CGE components (that will work perfectly in CGE editor)

1. Non-visual components that can be still designed in CGE editor.

   • Components to set font properties (URL to ttf/otf file, LoadingSize to have larger texture but with less blurry characters). You will be able to assign these to TCastleLabel.CustomFont (already existing but not useful in editor, only from code) and upcoming TCastleText.CustomFont . This will be an upgrade of existing TCastleFont and other CGE font classes.

   • New component TCastleComponentGroup only to group non-visual components, if needed.

   • Ability to save in editor non-visual components to .castle-component file. Any TComponent descendant is OK. We already have this in code (ComponentLoad, ComponentSave). This will give us equivalent to TDataModule you may know from Lazarus/Delphi.

2. Behaviors (descendants of TCastleBehavior) that extend parent TCastleTransform.

   • TCastleBillboard (already done, but we need to expose it in the editor).

   • TCastleSoundSource (already done, but we need to expose it in editor, and make some changes applied better, without restarting sound).

   • TCastleMoveAttack (easy creature AI; half-finished in CastleBehaviors unit for now).

   • Physics components (TRigidBody, TCollider and descendants) expressed as behaviors, and with auto-size by default. IOW, you will be able to design and test CGE physics in our editor!

3. Lights. Using internal scenes with X3D lights underneath, using gizmos to manipulate lights like in view3dscene lights editor.

   • TCastlePointLight
   • TCastleSpotLight
   • TCastleDirectionalLight
   • TCastleEnvironmentLight (image-based lighting)

   • We already have the basis for all we need, but we need to fix issue 280 to make it functional.

   • To make shadow configuration on lights easy, we’ll need to improve additional stuff, both in shadow maps and shadow volumes.

4. Camera as TCastleTransform descendant. If you need it right now, just use my draft implementation of this idea in class TCastleCameraTransform inside examples/creature_behaviors/. Just copy this class interface+implementation to your code.

Our build tool got a few minor improvements/fixes lately:

• Build tool now supports executable_permission attribute to package some additional files with Unix executable bit set. In general useful by applications that have more than 1 executable. Used now by view3dscene manifest so that it packages tovrmlx3d binary with executable permissions.

• Build tool now warns if you try to use absolute path in search_paths in CastleEngineManifest.xml . This is almost always a mistake, you want to use relative paths.

• Many updates to CastleEngineManifest.xml docs.

• Fixes to castle-engine generate-program.

  On Windows, we need to use stricter wildcard matching in CastleFindFiles, so that "*.pas" does not match files like "bla.pas~~~something" (by default, Windows API, used by Pascal FindFirst/FindNext, only looks at 3 first characters of the extension).

• Various improvements to our Makefile and Jenkins to just rely on the build “all across the board” and not use some shell scripts.

A small but important improvement to our CGE editor: Now various commands that open Pascal files can use your custom editor, configured in Preferences -> Code Editor. By default we keep invoking Lazarus but you can now freely change it.

This affects a few editor commands:

• menu item Edit Unit…,
• menu item Edit Unit Associated With Open Design (F12),
• opening newly added unit at New Unit…,
• opening Pascal file by double-clicking in Files browser,
• menu item Open Project in Code Editor (previously called Open Project in Lazarus)

Note that it means you don’t even need to install Lazarus and you still have a 100% functional CGE editor integrated with your favorite code editor. For CGE applications using TCastleWindowBase (which is what we advise by default) you don’t need Lazarus or LCL, “bare” FPC installation is enough.

With huge thanks to Trung Le (Kagamma), we have a new 3D particle system for CGE, and serious upgrades to the existing 2D particle system:

1. The 2D particle system has now an alternative GPU-based implementation.

   It allows to render 1 million particles on the screen, with FPS still stable at 60 🙂

   Note: It is using Transform Feedback and some OpenGL 3+ stuff, so an OpenGL 3.3+ compatible graphics card is required, and it doesn’t yet work on mobile. But there is still a CPU-based compatible implementation, just use TCastle2DParticleEffect instead of TCastle2DParticleEmitterGPU, and it will work everywhere.

2. We have a new 3D particle system:

   • With a GPU-based implementation.

     As above, it is using Transform Feedback, so an OpenGL 3.3+ compatible graphics card is required, and it doesn’t yet work on mobile. There is no CPU implementation in this case, so it doesn’t (yet!) run everywhere where CGE is.

   • With its own 3D particle editor and JSON-based format to design 3D particle systems.

Both particle emitters nicely integrate in the editor — you can put them in editor_units in your CastleEngineManifest.xml, and they will register components like 3D Particle Emitter (GPU), 2D Particle Emitter, 2D Particle Emitter (GPU).

Get the linked repositories and run demos inside!

Both repositories are listed now on our gallery of CGE components. (Do you develop any components that may be useful for other CGE developers? Let us know and we’ll happily add your components there.)

See also forum posts about these developments: 3D particle system, Cge-2d-particle-emitter now supports GPU-based particle.

We change the license of our examples (stuff in examples/ subdirectory) to be more permissive. Namely, all our example code and almost all our example data are now covered by the modified BSD (3-clause) license. It’s a very permissive license that basically says “we keep our copyright, but otherwise do what you want with these files, modify them as you like, and you don’t need to show your modifications to anyone”.

This was always our intention, we want you to use the example code as a basis of your applications without any fuss.

More details, and precise legal words, are in our licensing terms and the modified BSD (3-clause) license text is here.

We improve the process of automatic texture downscaling. The automatic downscaling is determined by data/material_properties.xml file and documented here. The new features are:

• Ability to specify any set of scales, not necessarily a continuous range.

• Ability to specify that some scale values are packaged only for particular platforms. E.g. scale 3 (which means that each size is downscaled 1/4) may only be packaged for Android and iOS, and not for desktops. This is useful, as mobile platforms often have GPUs with more limited memory, so textures often have to be provided there with lower resolution.

New features are documented on manual page about “Auto-generated compressed and scaled textures”.

Thanks go to Eugene Loza for doing this! This is another feature pushed by upcoming The Unholy Society release on mobile 🙂

1. The navigation in 2D viewports (with orthographic projection and standard direction/up: -Z/+Y) is now much better. We have a new algorithm TCastleExamineNavigation.ExactMovement that makes the navigation more natural, and we have a dedicated TCastle2DNavigation class (descendant of TCastleExamineNavigation) to make the mouse buttons easiest to discover (just drag with left mouse button). You can assign the TCastle2DNavigation in editor too: just use the “hamburger” menu at the viewport (see the screenshot in this post).

   view3dscene also has now a “2D” navigation button.

2. We have a new PhysicsRayCast utility, to cast rays using physics engine (Kraft). It is used by examples/platformer/ now.

   Note that it is only a temporary state that we have 2 methods to cast rays: using Kraft (PhysicsRayCast) and not using Kraft (TCastleTransform.RayCast, MyViewport.Items.WorldRayCast — see examples/3d_rendering_processing/collisions demo). In the long run, we want to have a single API to cast rays, and it should always use physics engine, and it should be configurable “what is the current physics engine”.

3. Subcomponents in the editor (like TCastleTransform.Translation or TCastleScene.RenderOptions) are no longer gray (it was confusing, as one could think “gray means inactive”).

   Thanks go to Andrzej Kilijański for 1-3 above!

4. A lot of examples have been upgraded to follow latest CGE conventions: DesignUrl, CastleAutoGenerated unit, {$region...} comments and more.

5. Fixed a fascinating bug with blinking lighting in some cases (see here for details — normal matrix was flipping between 2 different values, due to a determinant of modelview matrix being very very close to zero).

6. A bug related to using Scene.StopAnimation right after Scene.PlayAnimation was fixed. See details.

7. Upgraded OpenSSL Windows DLLs to 1.0.2u from 1.0.2n.

We expose TUIState.DesignUrl (and some friends) as a more comfortable alternative to the TUIState.InsertUserInterface method. InsertUserInterface was a method used by many CGE applications to load a designed UI into a TUIState. Advantages of the new TUIState.DesignUrl approach:

1. It looks simpler. You do not need to think about UiOwner and FreeAtStop parameters passed to InsertUserInterface. You have TUIState.DesignedComponent to replace previous UiOwner.FindRequiredComponent.

2. It allows to trivially use new DesignPreload property, a powerful way to load state data in the constructor (instead of at start), which is sometimes desirable — this way state can later start instantly, albeit at the cost of longer application initialization time and larger memory usage (e.g. textures and images used by state are preloaded in memory).

All of CGE examples and templates have been adjusted to use the new approach.

Previous code looked like this:

procedure TStateMenu.Start;
var
  UiOwner: TComponent;
begin
  inherited;

  { Load designed user interface }
  InsertUserInterface('castle-data:/gamestatemenu.castle-user-interface', FreeAtStop, UiOwner);

  { Find components, by name, that we need to access from code }
  MyButton := UiOwner.FindRequiredComponent('MyButton') as TCastleButton;
end;

New code looks like this:

constructor TStateMenu.Create(AOwner: TComponent);
begin
  inherited;
  DesignUrl := 'castle-data:/gamestatemenu.castle-user-interface';
  // DesignPreload := true; // use this to preload design in constructor
end;

procedure TStateMenu.Start;
begin
  inherited;

  { Find components, by name, that we need to access from code }
  MyButton := DesignedComponent('MyButton') as TCastleButton;
end;