Shadow volumes: new WholeSceneManifold option, fixes and docs

Posted on

Shadows in editor
Shadow volumes
WholeSceneManifold demo in editor
WholeSceneManifold demo
Select Non-Manifold in Blender
  1. A new feature of our shadow volumes is that you can turn on TCastleRenderOptions.WholeSceneManifold to say that the whole scene must be a closed volume (2-manifold), not necessarily each shape.

    This makes especially sense if your model is, as far as geometry in a 3D authoring tool like Blender is concerned, a single mesh but with different materials. For glTF and X3D (and finally GPU), such mesh must be split into multiple shapes. The whole scene may be thus a closed volume (2-manifold) even if each shape is not.

    The details of when you may want to use this are described in our documentation and example examples/viewport_and_scenes/shadow_volumes_whole_scene_manifold.

  2. An important fix was done to our algorithm that culls shadow casters in case shadow volumes are cast by directional lights. Previously sometimes the shadows could disappear when the shadow caster was not visible — causing funny artifacts (shadows unexpectedly disappearing) in certain views. This is fixed now.

  3. Interaction of frustum culling (TCastleScene.SceneFrustumCulling, TCastleScene.ShapeFrustumCulling), distance culling (TCastleScene.DistanceCulling) and shadow volumes is now simpler and more reliable. If we render shadow quads for something, then we have to also render the shadow caster.

  4. As part of this work, we’ve also removed long deprecated properties TCastleScene.FrustumCulling and TCastleScene.OctreeFrustumCulling. They allowed to configure details… they weren’t really ever useful to configure, in my experience. We recommend to use instead a simpler boolean TCastleScene.ShapeFrustumCulling for a long time now, and even this is usually something you don’t really need to care about. As always, make a noise on our forum or Discord if this change affects your project in any way. From my experience, all usage of these old properties can be just removed — tweaking them most likely didn’t have any effect on the performance anyway.

    Removing these old things allowed to make this code simpler, for shadow volumes fixes described above, and also for upcoming rework how shapes are rendered.

  5. Finally, our shadow volumes documentation was much improved.

    The details about X3D nodes and fields have been moved to a section at the bottom, as likely not relevant for most CGE users. The information how to use it all using Pascal and CGE editor is now prominent.

Comments on the forum ➀

Use Delphinus to install Castle Game Engine in Delphi, also simplified Delphi packages

Posted on

Castle Game Engine 3D in Delphi FMX form

We have a new comfortable way to install Castle Game Engine packages and paths in the Delphi IDE: use Delphinus!

Delphinus is an open-source package manager for Delphi. You can point it to an existing CGE installation using “Install from folder” from Delphinus GUI, and in turn it will

  • Install CGE design-time package that provides the TCastleControl component.

  • Add unit paths to Delphi IDE, to make CGE units available in all your projects. No more need to manually add a long list of CGE paths to your Delphi settings (or each project). And upgrading or uninstalling the CGE package using Delphinus will update the Delphi settings accordingly.

The whole process of installation using Delphinus is outlined here.

By the way of doing this, I have also simplified our Delphi packages. The split into 3 packages (base, vcl, fmx) wasn’t really beneficial (since these were design-time only packages anyway, it is OK to put both VCL and FMX variants in one package) and it actually caused problems for Delphinus (see here). So I simplified things: CGE Delphi package is now just literally one package, castle_engine.dpk. See packages/delphi.

Be sure to remove previous CGE packages from Delphi to avoid problems. Use the “Component -> Install Packages…” menu item in Delphi IDE to get a dialog where you can remove the packages. Then install the new castle_engine package (by Delphinus or manually) to get back TCastleControl component, for both VCL and FMX.

BTW, free Delphi Community Edition has been recently updated to version 11.3. If you want to give Delphi a try, now’s a good time πŸ™‚

Comments on the forum ➀

Big rendering refactor: fully modern OpenGL support (3.3 core profile), mobile OpenGLES more functional (3D textures, occlusion query, more OpenGLES 3 features), ancient OpenGL better (reliable fallback to even 1.1 rendering in VMs), modernized GLSL code

Posted on

fps_game demo
Run parameters submenu
OpenGL information

We have made a few significant refactors of our low-level OpenGL(ES) code, to support better both modern GPUs, ancient GPUs and mobile GPUs. Everybody wins! πŸ™‚

Modern GPUs

We have now much better support of new OpenGL features. If we have shaders, we know we have shaders from “core”, and we initialize them with the same code everywhere. Same for FBO (Framebuffer Object). Most new GPUs support now OpenGL 4.x. So for many things, we can just assume that modern OpenGL will have them in “core”.

So we have implemented a code path using 100% “core profile” OpenGL 3.3 context (using deprecated stuff is prohibited). To force using it, set TGLFeatures.RequestCapabilities to rcForceModern. Or pass command-line option --capabilities=force-modern . Or in CGE editor click “Run -> Run Parameters -> Force Modern Rendering Context (–capabilities=force-modern)”.

Our upgraded renderer:

  • Automatically converts quads to triangles as modern OpenGL(ES) API don’t support quads.

  • Uses image formats without luminance, instead we use texture swizzle.

  • Creates and uses Vertex Array Buffer.

  • Queries OpenGL(ES) extensions in new way

  • Uses shadow samplers following OpenGL(ES) core

The default is a smart choice. We create a “compatibility” context, and

  • if it has a new OpenGL version — we will actually use only the new API , just like from “core” profile. As mentioned above, OpenGL >= 2 implies a lot of things (VBO, shaders) and we will use them. Later versions also imply some nice things, e.g. OpenGL >= 3 implies FBO.

  • However, if the provided OpenGL version will be low (< 2), we will automatically set GLFeatures.EnableFixedFunction to true, and follow ancient fixed-function rendering path.

This makes the approach “automatic”, and it is indicated by (default) TGLFeatures.RequestCapabilities value of rcAutomatic.

Our treatment of old GPUs is now simpler

If you don’t have OpenGL 2, then we assume you also don’t have a lot of other things (we will not even try to use them through old extensions). Without OpenGL 2, we assume you never have shaders or even VBO. To be precise, GLFeatures.Shaders is now always a simple negation of GLFeatures.EnableFixedFunction, same for GLFeatures.VertexObjectBuffer.

This makes things actually better for these ancient GPUs: it means that their support is more reliable. It is easier to write and test one simple “ancient fixed-function” code path when it doesn’t have so many variations. And you can test it easily: just set TGLFeatures.RequestCapabilities to rcForceFixedFunction from code. Or pass command-line option --capabilities=force-fixed-function . Or in CGE editor click “Run -> Run Parameters -> Force Ancient Rendering Context (–capabilities=force-fixed-function)”, then run as usual (F9 or click the button).

Rendering on such old systems supports unlit or Phong lighting. Some modern rendering features are not available (like PBR or shadow maps), but simple games will manage.

The renderer was really tested with actual OpenGL 1.1 implementation available on some Windows 2016 servers πŸ™‚

Switching between modern and ancient OpenGL

We have a new command-line option --capabilities=automatic (or
--capabilities=force-fixed-function or --capabilities=force-modern). It is available in all CGE applications (TCastleApplication.ParseStandardParameters handles it, and it is called from CastleAutoGenerated unit).

We also have a new menu items in CGE editor to easily set it “Run -> Run Parameters -> …”.

view3dscene and the CGE editor itself also support these options. So you can test how does editor behave on ancient OpenGL implementations, just run it like this: castle-editor --capabilities=force-fixed-function.

Mobile

Finally, the end result is also good for OpenGLES (usually on mobile, though it also works on desktop if you want). It is more consistent now with desktop OpenGL, bringing many rendering improvements to OpenGLES and simplifying the code in the process too. E.g. shadow maps now just depend on OpenGL ES 3, and use almost the same code as on desktop OpenGL, with shadow samplers in GLSL.

I wrote more about mobile improvements in this post.

Testing

I have also added a test application examples/research_special_rendering_methods/test_rendering_opengl_capabilities/. It exercises all rendering methods:

I have also extended default OpenGL 1-line report to contain vendor name and “modern rendering” (not GLFeatures.EnableFixedFunction), since they are important information about your GPU. It looks like this now:

Rendering Initialized: OpenGL 4.6 (Nvidia) (modern rendering: True) (for more info: LogGLInformationVerbose:=true)

The verbose report (the one you see if you enable LogGLInformationVerbose, you also can see it in CGE editor, use “Help -> System Information”) is also improved in many ways — more relevant stuff reported, better order.

Also our GLSL usage in now more modern

We advise you to not declare any #version in your GLSL code, and internally we will add a modern #version and also define a few macros that turn lowest-supported GLSL versions into modern versions. See CastleGLShaders unit for more comments.

We also automatically define precision for OpenGLES fragment shader, if you didn’t do it automatically.

Debugging

You can use OpengGL debug context feature. Just set TGLFeatures.Debug.

Comments on the forum (9) ➀

Visual Studio Code and LSP server improvements

Posted on

VS Code running Castle Game Engine task

A big personal news from me is that I switched from using Emacs for almost-everything-I-do-on-computer to VS Code about a month ago. There have been a few reasons (yes, including this). I was exploring VS Code already, finally decided to see what happens if I try to use it for everything and now I’m happy with the switch. No big miracles happened, but I feel various things work in VS Code better out-of-the-box than my heavily-customized Emacs ever could. I hope that my clone in an alternative reality will maintain my ~20 years worth of Lisp code πŸ™‚

For Castle Game Engine, this sparked some small improvements that will likely benefit everyone who prefers to use general text editors (whether VS Code, Emacs, or Vim).

  1. I extended our VS Code manual, as I explored how to configure it best.

    I updated in particular how to configure VS Code “tasks”, such that pressing F9 basically does what it does in CGE editor: compiles and runs your project, letting you observe logs.

    I’m also looking forward to implement a dedicated Castle Game Engine extension for VS Code (and VS Codium) that integrates our LSP server (with CGE settings), and defines useful CGE-related tasks out-of-the-box.

  2. I improved our build tool with additional option (--windows-robust-pipes) useful for integration of build tool in any external tool (like VS Code) on Windows.

  3. I was also doing improvements to our Pascal LSP server, both for Emacs and VS Code and other text-editors. The server is now easier to configure, it auto-detects OS, CPU and fixes eventual setting of OS=windows (to win32 or win64).

Comments on the forum ➀

Simpler castle_base Lazarus package, no longer depends on Vampyre LPK

Posted on

image_display example

Going forward, CGE doesn’t depend on Vampyre packages LPK. We of course still (proudly!) use Vampyre Imaging Library for most of our image loading/saving needs, we just refer to these units a bit differently.

There’s nothing for you to do. You can uninstall VampyreImagingPackage.lpk and VampyreImagingPackageExt.lpk from Lazarus IDE if you had them only for the sake of CGE. Though you don’t need to do that (you will just ev. see a message from Lazarus that multiple packages define the same unit path, which you can ignore).

The base CGE package packages/castle_base.lpk already refers to all Vampyre units.

The goal is making installation procedure as simple as possible in all situations. The developers now do not have to be even aware about CGE-Vampyre dependency, so things are simpler if you compile from sources. Remember: if you get CGE binary package, then just use “Preferences -> Register Lazarus Packages” button (see installation manual) now and in the future, and then you don’t need to pay strict attention to what packages we use / don’t use, we will register all relevant packages.

For more information about our Lazarus packages, see packages/README.md.

Comments on the forum (7) ➀

DSDrive – a new racing game made in Castle Game Engine

Posted on

1
2
3
4
5
6
7
8

We’re proud to present DSDrive, a simple racing game developed by DidiSoft entirely with Castle Game Engine and Lazarus (and Blender and LazPaint). It is a car race game against 10 opponents and/or time on three different racetracks. In the box you can change the tires, refuel, adjust the brakes and adjust the wing angle. There are three different types of weather. Different views are possible.

You can download the game and the source code from the itch.io page .

All feedback is most welcome on the related forum thread!

Comments on the forum (3) ➀

Render 3D and 2D games inside Delphi VCL and FMX forms using TCastleControl

Posted on

Castle Game Engine 3D in Delphi FMX form
Castle Game Engine 2D animation in Delphi VCL form
Castle Game Engine 3D in Delphi VCL form
Castle Game Engine 3D in Delphi FMX form
Castle Game Engine UI in Delphi FMX form
Castle Game Engine UI in Delphi VCL form

We announced this feature already some time ago and you can watch my presentation from Embarcadero CodeRage 2022 about it. A lot of polishing work happened since then, so it’s time to announce it officially:

Castle Game Engine now offers a TCastleControl component that you can install in Delphi IDE and drop on a VCL or FMX form. It allows you to load any 3D or 2D object hierarchy (designed in CGE editor or just instantiated by code) and render it inside a Delphi form. Inputs (mouse, keys) are handled, animations play. You can embed a fully-featured game inside a Delphi form this way or you can use it to just add something small, e.g. a visualization of some 3D object (from glTF, X3D, MD3 or other formats) to an existing form design.

Everything is documented on TCastleControl manual page. The VCL and FMX variants of the component are practically equivalent, they are also practically equivalent to Lazarus (LCL) version of TCastleControl.

The short instructions are:

  1. Get the Castle Game Engine. Take a look at our installation manual if you have any questions.

  2. Install the components in Delphi IDE: Go to the packages/delphi subdirectory and open the AllPackages.groupproj there. It’s a group of 3 packages.

    First, you can build them all at once.

    Then install them. Make sure your target is “Windows 32-bit” and click “Install” on all 3 packages. The menu option to “Install” is available when you right-click each .bpl. (Again, remember to use “Windows 32-bit”; Delphi IDE is 32-bit, you cannot install packages when your platform is Windows 64-bit.)

  3. Then open the examples. They are in examples/delphi, one example for VCL one for FMX. These are regular Delphi projects, open them, play with stuff on form, compile and run (for Windows 32-bit or 64-bit).

    You can also open each example in CGE editor, to edit the 3D / 2D / UI designs there. Compiling from CGE editor runs Delphi command-line compiler under the hood — so you can hit F9 from CGE editor, or from Delphi, and it practically does the same.

  4. That’s it. Go ahead and have fun with the engine! πŸ™‚

    Follow the manual. If you want to use Delphi for everything — configure in CGE editor “Preferences” Delphi as your compiler and code editor. And open all the examples in examples/ subdirectory — all of them work with Delphi, though most of them do not use Delphi forms, they use our own TCastleWindow which is just a window filled completely with CGE rendering. Such applications are designed completely in CGE editor.

Since the initial announcement, we have improved input (mouse and key) handling on both VCL and FMX, we added code to avoid rendering FMX version at design-time (it seems FMX native components just cannot reliably render at design-time), and we improved how controls work with our views.

Let me know your feedback, about the new TCastleControl for FMX and VCL, and everything else! If you have any questions, hop onto our forum and Discord. And if you like this, please support us on Patreon!

Comments on the forum ➀

Editor improvements: color picker, display statistics, simple grid and axis

Posted on

Color picker used for light color
Color picker used for fog color
Color picker used for UI color
  1. Choosing colors inside CGE editor is now using a modern, cross-platform, comfortable color picker dialog. To see it, simply click on “…” in the editor object inspector to adjust any color — of user interface (like TCastleRectangleControl.Color), or 3D stuff (like TCastleAbstractPrimitive.Color), of background (like TCastleBackground.SkyTopColor).

    The new color picker dialog pops up, allowing you to configure color using HSV, RGB, allowing to copy-paste color as a hex value, adjust alpha, and it even shows sample code how to set the color using Pascal code.

    The dialog updates the resulting color in real-time, so you can watch the resulting color in the design as you drag any slider in the dialog. You can “Revert” the color (to the state before you opened the dialog), by default the color is applied without any extra action necessary. Moving the mouse out of the picker dialog also leaves the color applied — this is similar to color dialog behavior of e.g. Blender and Godot.

    Underneath, we use LCL mbColorLib components pack. Big thanks to mbColorLib authors (Marko Binić, Werner Pamler and to Andrzej Kilijański for integrating it in CGE!

  2. You can now easily display rendering statistics (FPS, draw calls, shapes rendered). Use the “Edit -> Show Statistics (F8)” menu item in the editor.

  3. For some time now, we have a simple way to display 3D grid and axis (X,Y,Z axes) in the editor: use menu item “Viewport -> Show Grid And Axis”. It’s just a simple initial implementation — in the future the grid and axis sizes should adjust better to your current view, so that they use a reasonable units, to not look too tiny/too huge in various cases.

Comments on the forum ➀

Physics layers – configure what collides with what

Posted on

Physics collisions on platformer
Physics layer choice in platformer
Physics collisions
Physics collisions
Physics names

I’m proud to announce new feature that enhances our physics: physics layers.

The idea is really simple: you can spread your objects (TCastleRigidBody) into multiple layers, and then configure which layer can collide with which. This way you can make certain things ignore other things. For example, maybe enemy_bullets should not hit other enemies or maybe enemies should not consider each other when walking (in some 2D games, it is normal that enemies can “pass through” each other).

There are really just 2 things to configure:

  1. At each rigid body, set the TCastleRigidBody.Layer to indicate the layer on which the body is.

    To help with this, you can add names and even longer descriptions to layers. Do this through Viewport.Items.PhysicsProperties.LayerNames. In the usual workflow, just click to configure LayerNames using “…​” button in the editor. The names and descriptions are only for the developer, to better document the layer meaning.

  2. Configure which layer collides with which using the checkboxes at Viewport.Items.PhysicsProperties.LayerCollisions. You can set them from code, or click on “…​” from CGE editor to configure them visually.

The simple usage example is in examples/physics/physics_3d_collisions_layers/. More involved example is in examples/platformer.

The documentation of this feature is part of the manual about physics.

Comments on the forum ➀

Web target – progress and plans

Posted on

WebGL

After the big engine release of 7.0 (coming really soon!), I’m dedicated to focus on adding the web target as a new engine platform.

The goal is simple: allow you to recompile more-or-less any application you wrote using Castle Game Engine (using TCastleWindow) to the web. So you can put your application on a website, as part of a normal HTML webpage, and users can play it instantly, without the need to download / install any native application or plugin.

How:

  • We’re using FPC WebAssembly target. Huge thank you go to the whole FPC team of course for making it possible!

    Possibly there will be some additional “glue” bits done using pas2js (such “glue” is necessary as WebAssembly doesn’t otherwise get access to JavaScript APIs available in a web browser).

  • We will render using WebGL 1.0, with optional WebGL 2.0 features. This is very similar to current rendering on mobile, where we use OpenGL ES 2.0, with optional OpenGL ES 3.0 features.

  • For audio, we will add a new sound backend using WebAudio. This will be the default sound backend on the web (like the OpenAL is now the default backend on non-web platforms).

    It is also possible our FMOD sound backend will also be ported to web, as FMOD supports HTML5. This would make FMOD a truly cross-platform sound backend, working on every platform we support in CGE.

    I recently wrote more about WebAudio in the context of X3D 4.0. Supporting advanced X3D 4.0 audio nodes is not our priority, but since WebAudio will happen anyway, on the web… they will open this possibility. There is also LabSound that provides WebAudio-like API on non-web platforms, and in principle it could one day replace OpenAL, making web and non-web audio handling closer.

  • For data delivery, we know we’ll have to invent a simple format to carry our game data as one big binary blob. The simple plan is to just pack game data into zip.

  • For development purposes, likely we’ll add a “Run simple webserver on localhost” feature, to allow you easily run WebAssembly applications. This can be done using a number of things, I like most the idea of using fpWeb which can instantiate a standalone HTTP server in just a few lines of code.

What we have now:

  • Branch webassm_platformer_test in CGE contains a code that compiles (but it is not functional yet!) for WebAssembly. This means that CGE compiles, and also build tool supports a new OS/CPU. So you can enter any CGE project, and execute on command-line:

    castle-engine compile --os=wasi --cpu=wasm32
    # or
    castle-engine compile --os=wasi --cpu=wasm32 --mode=debug
    
  • We’ve encountered FPC issue #40229 (Wasm32 symbol xxx without index value error) but it is now happily fixed πŸ™‚ Many thanks go to Nikolay Nikolov from FPC team for fixing, and Andrzej KilijaΕ„ski for preparing a code to easily reproduce the issue.

  • Trung Le (Kagamma) has been doing lots of work with CGE + FPC WebAssembly. His fork contains a branch wasm32-wasi-port with lots of active work. I absolutely expect that we’ll merge it to CGE webassm_platformer_test at some point, and then to master branch πŸ™‚

  • As noted by Trung Le (Kagamma), the important issue hanging on FPC now is #39547 (wasm32-wasi: Cannot create dynamic library). Go ahead and upvote it πŸ™‚

  • File-size tests are promising. Compilation of examples/platformer, which practically uses 100% of CGE units, yields a binary platformer.wasm that has 16 MB. Gzipped it has 3.4 MB.

    The gzipped size is really what matters — both web browsers and servers support gzip-(de)compression on the fly, you can also just put ready-gzipped version on the server and tell the browser to just decompress. So in all practical cases, users will download 3.4 MB, not 16 MB.

    Note that above is for a release build. The debug build weights 51 MB, and gzipped 12 MB. How is the debug build actually useful on the web — I am not certain now πŸ™‚

    We could also use Brotli, a newer compression method also commonly supported by web browsers and servers.

I want to thank everyone involved in this and let’s push forward! Web target is a really cool feature, from my talks I know it’s an important feature for many CGE users, and I feel we have it in our reach. Let’s keep coding and enjoy making games πŸ™‚

Comments on the forum (7) ➀