Non-Visual Components in Editor

Posted on

Fixed-camera demo (with new sounds)
Non-Visual Components menu
Sound list editing (non-visual component design)

You can now edit any TComponent descendant in CGE editor. I expect to use it intensively to design basically everything in the editor.

The non-visual components registered automatically (and thus available by default in CGE editor) are:

  • Fonts: TCastleBitmapFont, TCastleFontFamily, TCastleFont — described in the previous news about fonts.

  • TCastleSound — describes a sound file to be played. More on this in the upcoming news about sounds and the updated manual chapter about it.

  • TCastleComponent which is like standard TComponent but it can have non-visual children components managed by TCastleComponent.AddNonVisualComponent method and friends. These “non-visual children components” do not do anything, but they are serialized along with the parent component, thus you can organize your information in a tree.

    Oh, and sound and font classes mentioned above also descend from TCastleComponent. And all visual classes, like TCastleUserInterface and TCastleTransform can have non-visual components too, so e.g. a UI design root, or a TCastleLabel, can “store” the reference to a font. This is all flexible, so you can use the system to arrange information in any tree you like.

We also have new menu items to create a design that contains only non-visual components:

  • Design -> New Non-Visual Component (Empty Component As Root) (root is TCastleComponent)
  • Design -> New Non-Visual Component (Custom Root)

E.g. you can use it to store TCastleFont or TCastleSound collection in a file.

An example of using this approach to manage a list of sounds is in examples/fixed_camera_game, the design file data/sounds/all_sounds.castle-component defines all the sounds. The code that handles it is in code/gamesound.pas file. This is our new approach to define a “repository” of sounds, and it will soon be documented prominently in the manual and will deprecate the existing approach to define sound repository by an XML file.

This is our preferred editing and serialization approach for every TComponent. And so our preferred serialization for everything is to use RTTI with TComponent, which makes our CGE editor “complete” in the sense that it is now more universal than only “editor for CGE UI / transforms”, it is now “editor for everything in CGE”.

The non-visual components can be saved / loaded to a file with .castle-component extension.

The TCastleComponent also exposes a nice general mechanism to serialize children lists, using TCastleComponent.CustomSerialization and TSerializationProcess. It is now used to serialize regular children (TCastleUserInterface children of TCastleUserInterface, TCastleTransform children of TCastleTransform) and NonVisualComponents children (of any TCastleComponent) and Behaviors (of any TCastleTransform).

We also improved related JSON serialization code. It’s now a bit simpler (no more special $Children code, the TCastleComponent.CustomSerialization now covers this use-case). We write $$ClassName earlier (JSON is more readable for humans), we don’ write empty $Children (JSON simpler for humans).

Notable Replies

  1. Nice! I will play with it soon to see if I could make my 3D particle system to work with these new features.

    One thing I miss from the editor is better way to navigate around (the default X3D camera is kind of clunky to work with, and require to make changes to the viewport if we want to switch camera modes) and grid / ruler feature (if we use it as particle editor).

    1. Cameras in the editor: Yeah, fully agreed, this is a high-priority to fix.

      It’s somewhat a consequence of the fact that we don’t have a special camera/navigation for editor, instead we just use the regular camera/navigation that will also be used in the actual game. This was simplest to implement, but indeed it lands us in uncomfortable camera navigation in editor. Se Trello

      This is my almost-highest-priority now. First I want to make upgrades to the documentation (to document editor usage and various new features around sound/fonts there). Then the cameras. Then, most likely, 3D lights editing in editor.

    2. Grid / ruler: Agreed. And it should be easy to add.

Continue the discussion at Castle Game Engine Forum

Participants