Camera and navigation rework almost finished. TODO: This news announcement is too long, we have too much new stuff to announce

Posted on

Camera from Sketchfab in glTF

I’m nearly done with the big amount of changes on new-cameras branch. Below is a draft news announcement that will become official (and more complete) soon!

TODO: This is too long to announce, too many things. And this is not even finished yet, there will be more gains from this in UI.

TODO: Record a movie about this.

New features of camera and navigation:

  1. During design-time (that is, in CGE editor) you use an internal editor camera and navigation to move around the scene, without automatically changing the camera / navigation that will be used later for playing the game.

    This gives you more flexibility in how you move in the world at design-time, and this gives us more flexibility to implement best navigation at design-time, without worrying what is best for run-time.

    In particular

    • Dragging with left mouse button over viewport now doesn’t change camera. This makes it safer to navigate, as you don’t accidentally drag transform when you want to change camera, or vice versa, because now they are tied to different mouse buttons.

    • Navigation at design-time is activated by pressing and holding right mouse button over a viewport. This is consistent with various other game engines.

    • Design-time navigation fly mode shortcuts:

      Change speed by mouse wheel, as well as + and - keys.
      Keep holding right mouse button to rotate using mouse look.
      Nove by ASWD.
      Move down/up by QE.
    • Also (Viewport menu):

      Home to view all
      F to focus selected (a bit like in Unity, yes :) )
  2. TCastleCamera is now a TCastleTransform descendant, and as such it can be placed on Viewport.Items now.

    The current camera should be assigned to Viewport.Camera.

    In general Viewport.Camera and adding camera to Viewport.Items are independent actions (it was a mess when we tried to make them too much “magically” auto-connected). But

    • for backward-compatibility, camera from old designs is automatically assigned as Viewport.Camera, so old designs just work

    • when creating new viewport from code (but not when deserializing and not at design-time), we add new unnamed camera (as Viewport.Camera, and to Viewport.Items)

    • when creating new viewport in editor (but not when deserializing) we add new named camera (as Viewport.Camera, and to Viewport.Items)

  3. Camera can have children, like any other TCastleTransform.

    This is nice to place something relative to camera, e.g. weapon in typical FPS games.

    It is also new advised way to make a “headlight“. Just add a light, like TCastleDirectionalLight, as camera child. That’s it. Leave Viewport.UseHeadlight as hlOff, or UseHeadlight=hlMainScene (default) and leave Viewport.Items.MainScene=nil (default). We don’t need MainScene, we don’t need UseHeadlight anymore. This way it is also trivial how to control or adjust the headlight. It’s just your component, change it freely to another light, remove it, change the light Exists property etc.

    The default TCastleDirectionalLight direction is -Z, conveniently, as this is also the direction along which the camera is looking at. So just dropping default TCastleDirectionalLight as a TCastleCamera is all you need.

    See examples/viewport_and_scenes/headlight/ for example.

  4. Camera can be a child of some other transformation, e.g. you can mount camera on a car, or attach it to a bone of your skeleton.

  5. You can create TCastleCamera instances, from code or from editor, and have as many as you need. Just set Viewport.Camera to the current camera. You can set this property freely, also to nil (for consistency, it must be prepared for “no camera”, e.g. if you destroy the camera; viewport rendering is not done in this case).

    It also auto-synchronizes Viewport.Items.MainCamera with Viewport.Camera, if they were synchronized already. In simple cases (if you don’t use multiple viewports) Viewport.Items.MainCamera and Viewport.Camera are always synchronized.

  6. We display a preview from selected camera. This way you can reliably move any camera. And you can reliably move things with respect to camera.

    You can pin the preview, make it larger/smaller, to control and display it as necessary.

  7. This also makes the AnimateTo of cameras more useful.

    You can now setup various cameras around the world in editor, and use CurrentCamera.AnimateTo(SomeCamera) to smoothly animate to them.

  8. Adding Navigation components (to use at run-time) is no longer “special”. Just use “Add User Interface -> Navigation/xxx” to insert navigation as child of viewport.

    No more special menu to do that (that was previously trying to do some needless automatic around it, removing/adding it to children, removing previous navigation etc.) Also there’s no longer a need to use TCastleViewport.Navigation. It’s a deprecated property now, that just adds/removes children, nothing more.

    Also Navigation Exists works as expected. You can have multiple navigation components within on TCastleViewport, they can even work “all at once” but in practice (with current navigation classes) you will want to use Exists to make only one of them active.

  9. New property TCastleNavigation.CheckCollisions is also available.

More new features, done BTW:

  1. Editor improvements: Smaller gizmos

  2. Editor improvements: Show whether whole vector/color has modified state properly, e.g. see if Translation value is not bold or not

  3. glTF interpolators with unique names

  4. Inspector on F8 shows modified props (non-default value) more emphasized (blueish background for now)

  5. TCastleVectorXxxPersistent is now a TCastleComponent descendant, it can have owner, it can react to csLoading, it can and should be SetSubComponent(true), it is deserialized better: sets the final vector at once.

Backward compatibility notes:

  1. At the center of this change, is that TCastleCamera is now a TCastleTransform descendant. This generally makes it more powerful (e.g. you can add child objects to camera) but also makes some changes to API:

  2. TCastleCamera no longer stores “initial” vectors. Just like all TCastleTransform, it just stores current position/direction/up, delegating to some other code management of “initial” vs “current” state, if you need that.

  3. TCastleCamera.Position is deprecated. Use now Translation, not Position. Or WorldTranslation to get it in world-coordinates.

  4. TCastleCamera.Update now follows the signature of TCastleTransform.Update, thus it gets extra RemoveType parameter.

  5. TCastleCamera had some specialized GetView / SetView overloads. They have been removed — because they would be confusing now.

    TCastleCamera.GravityUp is always in world space.

    To get/set camera vectors, you should usually use GetWorldView / SetWorldView to operate in world space. The GetView / SetView, defined in TCastleTransform, continue to operate in local space. The new code should usually be updated from GetView / SetView to GetWorldView / SetWorldView — because almost always you want to query/set camera in world coordinates, not in local coordinates. This way you support the case “camera can be a child of something else”.

    So you should usually upgrade this code:

    // OLD
    MainViewport.Camera.GetView(Pos, Dir, Up, GravityUp);

    into this:

    // NEW
    MainViewport.Camera.GetWorldView(Pos, Dir, Up);
    GravityUp := MainViewport.Camera.GravityUp;

    And this code:

    // OLD
    MainViewport.Camera.SetView(Pos, Dir, Up, GravityUp);

    into this:

    // NEW
    MainViewport.Camera.SetWorldView(Pos, Dir, Up);
    MainViewport.Camera.GravityUp := GravityUp;
  6. TCastleNavigation had some deprecated GetView, SetView, Position, Direction, Up.

    They have been removed now. You should use Camera.GetWorldView, Camera.SetWorldView in most cases now.

  7. World.CameraXxx deprecated functions have been removed:

    function CameraPosition: TVector3; deprecated 'use MainCamera.Position if MainCamera <> nil';
    function CameraDirection: TVector3; deprecated 'use MainCamera.Direction if MainCamera <> nil';
    function CameraUp: TVector3; deprecated 'use MainCamera.Up if MainCamera <> nil';
    function CameraGravityUp: TVector3; deprecated 'use MainCamera.GravityUp if MainCamera <> nil';
    function CameraKnown: Boolean; deprecated 'use MainCamera <> nil';

    Because you should now usually upgrade to MainCamera.GetWorldView or WorldTranslation.
    In general you have to now be aware that camera that world and local coords,
    just like everything other TCastleTransform.

    Same for TCastleSceneCore, removed deprecated:

    function CameraPosition: TVector3; deprecated 'do not access camera properties this way, instead use e.g. Viewport.Camera.Position';
    function CameraDirection: TVector3; deprecated 'do not access camera properties this way, instead use e.g. Viewport.Camera.GetView';
    function CameraUp: TVector3; deprecated 'do not access camera properties this way, instead use e.g. Viewport.Camera.GetView';
    function CameraViewKnown: boolean; deprecated 'do not access camera properties this way, instead use e.g. Viewport.Camera';

    Also TCastleViewport.XxxCamera methods that actually talked about navigation (and not Camera) are removed. They have been deprecated for some time, and right now could be quite confusing. So removed:

  8. The already deprecated methods to auto-create the navigation have moved to separate deprecated class TCastleAutoNavigationViewport. The base TCastleViewport is free from their complication (that turned out to be useless, in most cases).

    This applies to you if you use AutoNavigation, NavigationType, ExamineNavigation, WalkNavigation.

    We advise you to instead create navigation explicitly, in code or in editor, like

    MyWalkNavigation := TCastleWalkNavigation.Create(...);

    But if you really need automatic management of navigation you can still use TCastleAutoNavigationViewport.

Screenshot using Steampunk Camera by lumoize from Sketchfab.

Comments on the forum ➤

Editor improvements, UI improvements, in-progress Snap packages (Linux packages on any distribution), testing lights and 3D models from Sketchfab

Posted on

Cars from Sketchfab
New cameras and editor improvements
CGE lights and room from Sketchfab
Crypt from Sketchfab
Porshe from Sketchfab

OK, so we have now 3 big things in-progress 🙂

  1. I started to learn Snap packaging. It allows to create packages that work on any Linux distribution and has a connected central store of Snap packages where users can find packages. Both open-source and closed-source packages are allowed there, you can browse existing packages and see there’s a lot of good stuff there. You can always upgrade all your packages using sudo snap refresh. The package release is managed by us (i.e. we will be able to just update CGE there, to any version we want, without waiting for others). Personally, I use it on all my Linux installations now (Debian, Ubuntu, Arch Linux) to manage stuff that for this or that reason is not available in distros’ packages.

    The end result should be that we could tell all Linux users “You can install Castle Game Engine using sudo snap install castle-engine“.

    My current efforts are in view3dscene/snap subdirectory. I.e. I’m learning Snap packaging doing a package for view3dscene.

    Note: there’s also Flatpak with very similar goals. We’ll be looking into it too 🙂 My simple practical reason to target Snap first is that it seems to just have more “market penetration” in my eyes, looking at my apps I just see a number of things that are officially available (and regularly updated) through Snap. Ideally, CGE will be on both Snap and Flatpak 🙂

  2. In the meantime, the work also continues in new-cameras branch. I’m improving now how does the navigation work, we even have a simple key F that works like in Unity — bring to focus the selected 3D/2D thing.

  3. And in the meantime, Andrzej Kilijański works on physics branch. The physics just works cool in the editor now, and it allows us to trivially create new demos. There will be a new 3D and 2D physics demo using the new features.

New features available on master:

  1. Nice colors for class name in editor hierarchy. The component name should “stand out” while the corresponding class name is dimmed.

  2. Hidden the labels displayed over designer when selecting UI items. These labels were often causing more trouble than gain — as they obscured the actual things you were trying to select/move/resize.

  3. Hidden names of subcomponents that you are not really supposed to edit. This applies to subcomponent names, like Perspective subcomponent within a camera.

Moreover, announcing some UI improvements available for a long time now:

  1. TCastleButton.Alignment, TCastleButton.VerticalAlignment.

  2. Safer look of exception messages and inspector invoked by F8. They will look reliably, always the same, regardless of how you customized the UI.

  3. Configurable theme features: TCastleUserInterface.CustomTheme, FallbackTheme, ForceFallbackLook

For this post’s screenshots, I used a few models from Sketchfab. I wanted to test editor on “real” pretty models 🙂

  1. Pony Cartoon by Slava Z.

  2. 1975 Porsche 911 (930) Turbo by Karol Miklas

  3. Abandoned Warehouse – Interior Scene by Aurélien Martel

  4. Crypt Location by Bocharova

Comments on the forum ➤

Various improvements: build tool, make, updated Docker image, smaller API updates – TCastleTransform.ExistsInRoot, TCastleImageTransform.Mipmaps

Posted on

Multiple cameras

While we continue work on big features (cameras + navigation, see teaser screenshot in this post; physics in editor), here’s a bunch of smaller engine enhancements you can enjoy already:

  1. The <compiler_options> in CastleEngineManifest.xml supports now detect_memory_leaks="true" (detects memory leaks with FPC, ignored by Delphi now), <defines> (best way to specify symbols; they can be put into both DPROJ / LPI reliably).

  2. Calling make in CGE main directory (on Unix, or Windows with Cygwin) is now more useful: it will build all tools, including the editor, and place them in bin/. Thus it automates most of compiling from source page — great to quickly recompile CGE from source code.

  3. Our Docker image was updated some time ago. Added php-cli, asciidoctor, bumped unstable FPC/Lazarus versions (to have TRegExpr change to UnicodeString).

  4. New property TCastleImageTransform.Mipmaps available, to make images look good from a distance.

  5. New TCastleTransform.ExistsInRoot property, TCastleTransform.ExistsInRootChanged virtual method. Use this to query whether object exists and all parents exist too.

  6. We fixed CastleResources freeing, which could exhibit in crashes e.g. in examples/fps_game/.

  7. Deprecated CastleRenderingCamera was causing too much trouble to maintain — removed. It was deprecated for quite some time already.

  8. Removed Giftiz integration, no longer exists.

Comments on the forum ➤

2 big features in-progress, and small editor improvements available already

Posted on

System Information

We have 2 big features in-progress right now:

  1. physics branch, by Andrzej Kilijański, with new features related to physics and more comfortable usage of physics in CGE editor. This includes:

    • AutoSize for physics colliders,
    • rigid bodies and colliders that can be added and configured using CGE editor,
    • ability to test physics in editor at design-time,
    • API to apply physics forces using Pascal,
    • example behaviors that define persistent forces existing in the world.
  2. new-cameras branch, by Michalis, with new features for cameras, including better camera and navigation in CGE editor. This includes:

    • TCastleCamera is now a TCastleTransform that exists in the world,
    • camera can have children,
    • camera can be a child of something else (like an animated bone, or mounted on top of a moving car),
    • you can have multiple cameras in the world,
    • we display preview of selected camera,
    • soon: separate design-time and run-time camera/navigation,
    • soon: activate navigation by right mouse button similar to other game engines.

In the meantime, we have small new features in the master CGE branch of editor:

  1. New menu item “Help -> System Information” shows

    • Rendering (OpenGL) information
    • Audio (OpenAL) information
    • Other (CGE version, compiler, platform)

    You can view the information and easily save it to file (e.g. to attach to CGE bugreport).

    This is also synchronized with a cleanup in default log output that I did recently. Logs are much less verbose now by default, to encourage you more to use these logs yourself, for your game. The engine is supposed only to log some extremely crucial things (or warnings), to let the logs be most useful for your application. You can still set LogGLInformationVerbose:=true and TSoundEngine.LogVerbose:=true to have verbose logs, they are just shorter by default.

    Note a small trick I used there: as we need to initialize some OpenGL context to get OpenGL info, and we need to initialize sound engine to query it… I decided to have some fun, and not even try to hide it. So the “Help->System Information” plays a simple looping 3D animation and spatial sound, to visually/audibly also communicate that rendering/audio works 🙂

  2. You can select multiple components with Shift in the hierarchy view.

  3. The overloaded “Design” menu was split into “Design” and “Edit”.

Comments on the forum ➤

WasVisible: query visibility of scenes and shapes, RobustNegativeScale: support lighting with negative scales

Posted on

Detect visibility
  1. You can easily query whether the scene or shape was (potentially, at least partially) visible in the last rendering event. This accounts for both frustum culling and occlusion culling.

    Use TCastleScene.WasVisible, TAbstractShapeNode.WasVisible for this.

    Demo is in examples/viewport_and_scenes/test_was_visible.

    See forum thread for history behind this feature.

  2. You can use TCastleRenderOptions.RobustNegativeScale to make lighting work correctly even when combined with negative scale. By default, using negative scale causes trouble for lit objects (as the normal vectors are not coming from the right side) and backface culling. Using the RobustNegativeScale makes them reliable (at a small cost at rendering time).

Comments on the forum ➤

glTF improvements (normal scale, camera fix), mixing glTF with X3D using IMPORT / EXPORT

Posted on

normalScale in X3D
IMPORT / EXPORT to connect X3D and glTF
  1. In both glTF and X3D we implement now a feature to “emphasize / deemphasize normal map”.

    In glTF this is in material.normalTextureInfo.scale, in X3D this is in normalScale parameter of Material or PhysicalMaterial.

    The intuitive meaning of it is:

    • value = 1 is the default, regular bump mapping behavior.
    • values < 1 make normal map effect deemphasized (normal vectors in tangent space have XY scaled down, so they go to (0,0,1) in tangent space, as if the normal map was not used). Value = 0 cancels the normal map effect completely.
    • values > 1 make normal map effect emphasized (normal vectors in tangent space have XY larger).

    Demo file is in x3d-tests repo: pbr/enhanced_phong_material/bump_mapping_normalscale.x3dv.

  2. glTF camera import was fixed.

    We mistakenly imported slightly wrong field of view and slightly wrong position. Usually these 2 bugs cancelled each other… almost 🙂

  3. You can now use IMPORT / EXPORT to selectively take (and reuse as many times as you wish) parts of inner glTF models inside outer X3D file.

    I have documented this with details and examples in new section Interoperability with X3D inside our glTF docs.

Comments on the forum ➤

FreeBSD build

Posted on

FreeBSD - CGE editor
FreeBSD - CGE editor
FreeBSD - CGE game

I was playing with latest FreeBSD (after listening to an excellent talk about the troubles with FreeBSD which nicely discusses non-technical problems in large open-source volunteer-led project).

Naturally, I tested Castle Game Engine on FreeBSD and it works flawlessly 🙂

I made a release of current CGE for FreeBSD.

This was done just by

cd castle-engine/tools/internal/pack_release/
./ freebsd x86_64

The editor, build tool just work, based on FPC and Lazarus that are available in FreeBSD ports (install just by pkg install fpc, pkg install editors/lazarus).

Note: This release is not rebuild automatically, unlike current Linux and Windows releases. But, well, let me know — we can make it rebuild automatically, if there’s interest! Otherwise, in a few weeks, this will be inevitably outdated. Of course you can always rebuild CGE from sources yourself on FreeBSD.

P.S. Don’t worry about low FPS on a screenshot — this was done in a virtual machine.

Comments on the forum ➤

Physically based rendering (PBR) in X3D, using glTF with X3D 4.0 (recording of my webinar)

Posted on

A recording of my presentation last Tuesday about X3D 4, PBR, glTF, and CGE is available. Watch it here:

The plan of the presentation, along with various links that I mention in the talk, is here.

This the 3rd YouTube movie from me this week. Do you think I can finally become an Influencer? 🙂 My cat says I do a great job!

Comments on the forum ➤

Background (skybox, sky/ground color gradients) in Castle Game Engine – presentation video on YouTube and Vimeo

Posted on

Enjoy a new video that demonstrates how to set up background (skybox etc.) in CGE editor:

Also, I uploaded our last 2 movies to the Castle Game Engine page on Vimeo. Should we use both YouTube and Vimeo? I will let you decide using the likes and comments 🙂 Here’s the embedded version of the same video on Vimeo:

Comments on the forum (3) ➤

Design lights using Castle Game Engine: new light components and related features, with video!

Posted on

Lights in Castle Game Engine editor

We’re proud to announce a big new feature in Castle Game Engine: new light components that allow to easily manipulate lights (from the editor and from Pascal code) and a number of related improvements.

I’ve made a video presentation that describes everything, enjoy! And read below the movie for more information.

New features details:

  1. New components to define light nodes: TCastlePointLight, TCastleSpotLight, TCastleDirectionalLight. Descendants of TCastleTransform, which can be easily added and manipulated from the editor and from Pascal code.

  2. New properties to control lights: TCastleRenderOptions.ReceiveSceneLights, TCastleRenderOptions.ReceiveGlobalLights, TCastleScene.CastGlobalLights.

  3. TCastleRenderOptions.PhongShading is now by default true. In short, it means that the lights look pretty. If you want to use Gouraud shading for efficiency, just change Scene.RenderOptions.PhongShading (see TCastleRenderOptions.PhongShading) to false.

    Note: using some features (normal maps, PBR, shadow maps) requires Phong shading anyway, and will override this.

    Note: Do not confuse Phong shading with Phong lighting model.

  4. TCastleRenderOptions.DefaultMaxLightsPerShape is now by default a big number: 64 instead of previous 8. Remember that each light has a cost, esp. as we use classic “forward rendering” right now in CGE. So try to limit the number of lights that affect given shape anyway, try to stay well below the 64 limit. The simplest way to do this is to use reasonable Radius on point and spot lights, and limit the number of directional lights that affect all scenes.

  5. SpotLight defaults adjusted, matching also X3D 4.0 changes: beamWidth by default is now pi * 3 / 16, so it shows a small falloff until cutOffAngle.

  6. Proper calculation and optimization of lights radius when lights are in a different scene than shape they shine on.

Coming soon: TCastleEnvironmentLight and shadows properties on lights, to easily activate shadow maps.

Do you enjoy this feature? Please support us on Patreon.

Comments on the forum ➤