IFC support in Castle Game Engine

Posted on

IFC house model
Web demo of IFC format support

We’ve been extending in recent months our IFC support.

I talked about it at conference in Germany and I will talk about it at conference in Poland next week 🙂

General overview of what IFC is about:

  • You can open, save and manipulate 3D models in the IFC format. This is the standard 3D format used by the BIM (Building Information Modeling) industry and supported by tools like Revit, ArchiCAD, FreeCAD, BonsaiBIM (in Blender). It describes how real-world 3D objects are constructed, from cities and buildings to the individual furniture and appliances.

  • Using our engine you can open IFC files, manipulate their contents using “native IFC classes” (which means that your software works using the same concepts as the IFC specification), and save them back to IFC files.

  • You can develop browsers and editing tools for IFC files, and deploy them on all the platforms supported by our engine.

  • All the details, along with sample code, are documented on our IFC page.

New things we’ve done in recent months:

  1. Our IFC test files are published in demo-models.

  2. Our online converter supports IFC.

  3. Our command-line converter supports IFC, so you can do things like castle-model-converter simple_house.ifcjson output.stl

  4. We have basic knowledge of all IFC classes (thanks to reading their information from XSD) and for many of them (178 now) we have knowledge of all properties.

  5. IfcGridAxis, IfcGrid are handled and displayed now.

  6. New engine utility method:TCastleIfcMapping.ProductToNodes, used by ProductBoundingBox method in example.

  7. New algorithm for extrusions in IFC, simpler, more efficient, more correct in some cases.

    • Just use quads for sides + concave top/bottom caps, do not use X3D that tries to be “too smart” and e.g. rotates the spine.

    • Also optimized convex/concave extrusion top/bottom caps.

    • Also adjust circle slices based on radius, to make it more efficient.

  8. New efficient wireframe generation (e.g. for IfcBoundingBox, but also every other shape in CGE).

  9. IFC transformation handling fix.

  10. Much more optimized changing of IFC Translation by TIfcProduct.Translation.

  11. Better saving to X3D:

    • Fixed rotation defaults.

    • Reuse Coordinate node for IFC extrusions (across 2 X3D geometry nodes).

  12. Improvements to examples/ifc:

    • Button to view entire model.

    • Checkbox to toggle debug IfcBoundingBox display.

Have fun with IFC and 3D standards, and support our work on Patreon!

Comments on the forum (1) ➤

September engine progress: IFC, web, CastleHttps, VS Code debugging, zen mode, X3D 4.0 4.1, downloads mirror

Posted on

Impressive castle demo, in "Maximize Preview" ("zen mode")
Impressive castle demo, in default editor UI
Walking adventure on web
IFC house model

This was a busy month, with lots of engine work and also a great conference in Germany organized by Sorpetaler. Let me then announce a bag of engine improvements and news all across the board from last month (and more):

  1. We’ve been working a lot in recent months on our IFC support.
    • More details about the IFC improvements will be announced later this week. Otherwise they would “dominate” this news post 🙂

    • For now, let me just say I talked about our IFC support at the conference in Germany and I will talk about it again at the conference in Poland next week. Catch me if you can!

  2. Web target improvements:

  3. We have a new unit CastleHttps to easily activate HTTPS support in TCastleDownload.

    • Easy to use, no need for any $ifdefs on your side.

    • Fixes HTTPS + FPC 3.2.x + Linux with newest SSL (because our CastleHttps pulls a fork of SSL for FPC 32x in this case).

    • Fixes CGE editor SketchFab auto-download functionality.

    • See URLs and networking docs for various pointers and examples using TCastleDownload.

  4. Our VS Code extension brings a major upgrade with version 1.4.

    • Your VS Code should update it to version 1.4 already.

    • New version has improved debugging support. See the Debugging section in the README for ways to activate it.

    • New version has been upgraded from plain JavaScript to TypeScript, which makes the code much easier to read and maintain.

  5. New “Maximize Preview” feature (“zen mode”) is available in our editor.

    • Use menu item “Edit -> Maximize Preview” or key shortcut Shift + Space.

    • It toggles the visibility of most things except the main preview of your application. So it hides / shows the hierarchy (left sidebar), object inspector (right sidebar), files / console (bottom panel). It allows to focus on the main thing: the preview of your game.

    • The key shortcut, Shift + Space, is somewhat consistent with similar Unity and Blender‘s features that maximize the panel under mouse. In our case, it always maximizes the preview window. In Blender, the shortcut is actually Ctrl + Space, but we didn’t want to take that, as Ctrl + Space is commonly used for completion in text editors, so (even though the CGE editor is not a text editor) we don’t want to conflict with that meaning.

    • We unofficially call it “zen mode”, as the spirit is similar to “zen mode” found in VS Code and recent Delphi versions: no distractions, maximize the one most important view.

    • This is based on similar idea by Andrzej KilijaÅ„ski he implemented for the terrain PR.

  6. “Open Engine Location in File Manager” button is now available in the editor “Preferences” dialog. It’s sometimes useful to explore engine easily, esp. since on Windows engine is installed to AppData which is by default hidden.

  7. Various X3D 4.0 and 4.1 support improvements:

    • Viewpoint nearDistance / farDistance support.

    • Validation of audio and volume rendering X3D 4.1 nodes.

    • With thanks to Don Brutzman and John Carlson for submitting lots of feedback in these areas, causing us to improve!

  8. We maintain a mirror of our releases at SourceForge (files of castle-engine project). You can download from there the same files as from GitHub releases.

    • Why? We found cases of networks where downloads from GitHub releases don’t work reliably (are often interrupted in the middle) while downloads from SourceForge behave reliably. Your mileage may vary — you have an option.

If you like what we’re doing, please support us on Patreon. Have fun making games!

Comments on the forum (3) ➤

Castle Model Viewer available on iOS, Android version updated too

Posted on

Castle Model Viewer on iOS
Castle Model Viewer on iOS
Castle Model Viewer on iOS
Castle Model Viewer on iOS
Castle Model Viewer on iOS
Castle Model Viewer on iOS

We have released Castle Model Viewer Mobile on iOS (iPhone, iPad) and you can get it right now from the App Store!

Open this link to the AppStore on your iPhone/iPad, or just search for “Castle Model Viewer” in the AppStore. We’re available in all AppStore regions (including US and EU).

You can open a number of built-in models (in X3D, glTF, IFC JSON and other formats we support). You can also open your own models, provided they are “self-contained”. More information about our features, and in particular about “Opening your own models” and what it means that “Models must be self-contained” is on Castle Model Viewer Mobile webpage.

The application is completely free, also no ads and no tracking, and it is naturally open-source and using our free and open-source Castle Game Engine.

In return, we ask that you consider donating to us and/or giving us a good rating on the AppStore 🙂

Of course, if you have any problems or questions, go ahead and ask. Various ways of contacting us are here, in particular you’re welcome to our forum or submit GitHub issue.

I’d like to thank Jan Adamec for working on this application, as well as on a lot of related iOS-specific improvements in Castle Game Engine. I’d also like to thank a sponsor (who wished to remain anonymous) for covering our Apple membership fee for 1 year. Much appreciated.

The Android version of the viewer was also updated, with:

We also added unit GameScreenShotArbitrarySize that shows how to take screenshots using FBO, in arbitrary resolutions (maybe larger than your monitor), maybe in multiple resolutions at once. Useful when some app store requires screenshots in a few particular resolutions.

Comments on the forum ➤

Ton of mobile (iOS, Android) improvements: iOS + OpenGL3, Google Play Billing upgrade, shadow maps precision, more

Posted on

Castle Model Viewer on iOS - dungeon
Castle Model Viewer on iOS - shadow maps
Castle Model Viewer on iOS - Spine JSON animation
Castle Model Viewer on iOS - chromatic aberration screen effect
Castle Model Viewer on iOS - SSAO and TouchSensor

As we’re preparing to release Castle Model Viewer on iOS, we’ve done a number of improvements to our mobile support for both iOS and Android:

  1. With big thanks to Jan Adamec, we have:
    • Upgraded our OpenGLES usage on iOS to OpenGES 3 (if only your system supports it; otherwise we still fallback to OpenGLES 2). This brings features like shadow maps to iOS rendering.

    • Fixed shadow maps precision on both Android and iOS.

    • Fixed screen effects using depth on iOS. (Though heed we still want to fix SSAO shader.)

    • Using this occasion, we want to mention that our Castle Game Engine iOS rendering is used in Jan Adamec‘s Room Arranger, a cross-platform application for designing your apartments and previewing them in 3D. Check it out, as a real application of our engine (through the library approach)!

  2. More iOS stuff:

    • Fixed opening associated documents on iOS when it causes launching the application.

    • Solve 2 AppStore validation issues if you used associated documents on iOS. So that your iOS application uploads smoothly to AppStore.

    • Added <ios override_icon=...> option to the manifest to enable specifying iOS-specific icon. This makes sense if you need to use a different icon for iOS than the other platforms (Android, desktop etc.), e.g. because your default icon has transparency (which is not allowed on AppStore).

    • Our iOS code migrated to use UISceneDelegate instead of deprecated AppDelegate. This makes our integration code follow latest Apple recommendations. Again with big thanks to Jan Adamec!

  3. More Android stuff:

    • We have upgraded Google Play Billing API to use version 8. This makes in-app purchases on Android follow latest Google recommendations and will pass validation when uploading application to the Google Play.
  4. More miscellaneous stuff, for both Android and iOS:
    • We have fixed our mobile Facebook integration, improving docs, tested on iOS and Android, and adding example examples/mobile/facebook_integration. It’s still admittedly a very simple integration, it’s main use-case is just to report application opening to Facebook Analytics. See it’s docs from Android services and iOS services.

Have fun with Castle Game Engine on your phone(s) 🙂 And if you like this, please support our work on Patreon. Thank you!

Comments on the forum ➤

Enjoy new examples: 3d_games/walking_adventure, 3d_games/dungeons_and_skeletons_fight and more

Posted on

fps_game demo
FPS game example
Demo from Delphi Summit 2025, with shadows
Demo from Delphi Summit 2025, with shadows
FPS game demo - props from Sketchfab
FPS game demo - props from Sketchfab

We did some rearrangement of our examples, to showcase better engine features and some good demos.

Note about engine size: Engine download size grew because of new demos.

  • We fought to keep this growth limited. We removed some old deprecated demos, to keep size lower. We removed all unused data and even decreased some textures from new demos and/or converted them to jpg. We also took care to not commit to GIT history large files, since GIT repo size grows even after things are removed.

  • But in total, some growth could not be avoided. Downloads are now about +80 MB bigger.

  • We hope that the increased engine size is worth it. The new demos are cool, and hopefully demonstrate nicely what you can do with our engine.

  • But we’re aware this is a problem in the long run. It would be nice to have a small engine download size. Some other game engines are also large (much larger than us!), but some others are small… it would be nice to get back to “small size” category. But at the same time we have a priority to provide you great examples, out-of-the-box, with the engine. We think (hope!) our existing examples are valuable.

  • Possibly, in the future our examples library could be auto-downloaded as you open each example, this would reconcile our 2 desires (to have “lots and useful and discoverable examples” with “have smaller engine download size”).

Like this? As always, we appreciate your support.

Comments on the forum (1) ➤

New example: get random image using Unsplash REST API

Posted on

Get random image from Unsplash
Get random image from Unsplash

We have a new example in our repository: examples/network/random_image_from_unsplash. This shows using our TCastleDownload to access Unsplash API and ask for a random image matching a given search term (like a “cute fox”).

The main part of the example is the unit gameunsplash.pas with a reusable class to download images from Unsplash.

There are 2 ways how this can be useful:

  1. You can learn how to use TCastleDownload with some REST API, to access the resources in an asynchronous manner (without blocking your application).

  2. And/or you can just use gameunsplash.pas unit in your own applications (feel free to just copy it, it’s on permissive BSD license) to get images from Unsplash.

    For example, you can use the images as randomized pretty background, or an image for a puzzle (to arrange puzzle pieces etc.)

    The images are generally free to use (see Unsplash license) for various, though not all, purposes. And there’s a ton of high-quality images.

To use this example, you need an API key (“access key”) from Unsplash. Don’t worry, it’s rather trivial (and free) to obtain it 🙂 Please follow the instructions in the README for details.

This is based on an actual fun application I (Michalis) did this week for our family! We have a monitor playing a role of a “wall clock” powered by the Raspberry Pi, showing clock with a nice background using TablissNG extension (a fork of it, that refreshes image from custom URL every 15 mins). I wrote a simple Pascal application to randomize the image, choosing randomly from a collection of our private photos and pretty images from Unsplash matching terms like “cute fox”. My daughter loves this 🙂 Note that Pascal application just exposes the image on local server, I deliberately made the separation between “display of image” (using TablissNG) and “choosing the image” (using my small Pascal program) to enable more future experiments with various fun ways to use these images.

I hope you enjoy it 🙂 And if you do, we appreciate your support on Patreon!

Comments on the forum (3) ➤

Android: Updated applications (Castle Model Viewer, Platformer…) in Google Play, on the engine side: upgraded Google Play Services to v2 and Android SDK to 35

Posted on

Castle Model Viewer Mobile - Dungeon in Examine Mode
Castle Model Viewer on Android
Castle Model Viewer - cat
  1. Castle Model Viewer for Android version 2.8 has been released! This brings:
    • Support for IFC format right in our mobile viewer.

    • Small UI improvements: better button order (left-most changes model), show more built-in files.

    • Opening ZIP files underneath doesn’t create temp directory on your device. Internally, this is achieved by using TCastleZip to open ZIP files. The TCastleZip class also makes code simpler, and compatible with both FPC and Delphi.

    • Fix: No more crashes on Android 15 (on some devices, like Google Pixel 6a, argv is broken after Android upgrade).

    • Fix: Take into account safe borders on left/right.

    • And all improvements and optimizations from the Castle Game Engine done recently. Including target Android version bump, mentioned below.

  2. All other Castle Game Engine applications on Google Play have been upgraded as well, to include all the latest improvements from the engine, including the target Android version bump.

  3. On the engine side, we have migrated google_play_games service to use version 2 of the Google API. New applications uploaded to Google Play are required to use this version.

    Please note that v2 is somewhat less functional than v1. E.g. there’s no way to explicitly request sign-out. It’s just how Google made it, and we have to adjust, see migrating to Play Games Services v2 about all changes.

  4. We also bump the “target” Android version to 35, as required by Google Play. This will be required by Google Play since 31 August 2025, see Target API level requirements for Google Play apps. Nothing in practice changes for you because of this (it doesn’t affect minimal version supported).

If you like it, we appreciate your support on Patreon. We also appreciate a good review for Castle Model Viewer on Google Play and our other apps!

Comments on the forum ➤

Lazarus packages: moved, renamed

Posted on

lazarus-installnew-31
Installing Lazarus package with TCastleControl - 2
Installing Lazarus package with TCastleControl - 3
Registering Lazarus packages

We did a few moves and renames to our Lazarus packages.

After upgrading to the latest engine version, be sure to run again “Register Lazarus Packages” button (from the “Preferences -> FPC and Lazarus” in our editor, as documented in our Lazarus docs).

Note that the existing applications will continue to work even without you doing the above, because new packages provide the old names too. But we advise to just use new names from now on.

The short version of the changes: Lazarus packages are now in the packages/lazarus/ subdirectory of the repository, with some better names.

Full list of changes and their reasons:

  1. We moved Lazarus packages to subdirectory packages/lazarus.

    Reason: This is consistent (sibling) to Delphi packages in packages/delphi, and good for TMS Smart Setup, and likely just more obvious to both Lazarus and Delphi users.

  2. We rename packages to add _engine. So we have

    • castle_base.lpk -> castle_engine_base.lpk
    • castle_window.lpk -> castle_engine_window.lpk
    • and so on.

    Reason:

    • Avoids having castlewindow.pas and castle_window.pas (the latter just auto-generated package unit) being too close to each other. They are completely unrelated units.
    • New names are consistent with Delphi packages (which always had the _engine part).
  3. We rename castle_components to castle_engine_lcl. So in addition to adding _engine, we change components -> lcl.

    Reason:

    • The components word there was confusing for a long time. Because this is not the only package with “components”, other packages (including base) also provide components (though they don’t register them now in Lazarus component palette, but they did in the past). However, this is the only package that depends on LCL and thus provides TCastleControl that uses LCL. This package may provide more LCL components in the future.
    • It also makes name of alternative_castle_engine_window_based_on_lcl.lpk more obvious. Now alternative_castle_engine_window_based_on_lcl.lpk depends on castle_engine_lcl.lpk — which looks obvious and natural.
    • We have planned to do this rename for quite a while now. We mentioned it in TCastleControl docs and packages README that “this should probably be renamed to castle_lcl” already.
    • This seemed to be a good moment to do this, as we go with rename/move anyway.

Note that the packages/lazarus/README.md has been updated to reflect it all. We also updated Lazarus docs, TCastleControl docs and everything else we found.

Comments on the forum (3) ➤

14 engine improvements from June/July — window sizing docs, TCastleAbstractPrimitive and TCastleImageTransform extensions, cubemaps and 3D textures in all texture slots, VS Code integration improved, rendering optimizations…

Posted on

Window with castle model
Cubes test
Cubes test

Presenting a big batch of engine improvements done last ~month. Lots of small things. Everyone, pick what you like 🙂 Upgrade to the latest engine version and enjoy them all!

If you like what you see, we appreciate your support on Patreon (we also have other ways to donate).

  1. We added a new documentation page Window size and fullscreen. Nicely explains how to change window size, fullscreen mode, anti-aliasing, and even (not recommended, we explain why) the OS-wide screen resolution.

    This is also linked from the new projects’ gameinitialize.pas template code. Previous template placed there a long comment — now it’s just a short concise comment with a link to the above page.

  2. Added TCastleAbstractPrimitive.TextureScale property, useful to easily scale the texture (in descendants like TCastlePlane, TCastleBox).

  3. TCastleImageTransform has new properties to make it lit and configure other options: TCastleImageTransform.Material, TCastleImageTransform.UrlNormalMap, TCastleImageTransform.RenderOptions. Details:

    • Material, can be pmPhysical or pmPhong or (as default, backward-compatible) pmUnlit.

    • UrlNormalMap allows to specify a normal map (for bump mapping).

    • RenderOptions allow to specify some rendering details. E.g. adjust bump mapping algorithm by RenderOptions.BumpMapping is useful.

    See this forum thread that caused these improvements and contains some testcases.

    And yes, we are fully aware that TCastleImageTransform and TCastlePlane features bring them closer and closer to each other. They both can display a textured rectangle in 3D or 2D, be lit or unlit, support various display options. For now, we think it makes sense to have both components, as they start from a different approach to sizing — it’s whether “image size determines the geometry size” (TCastleImageTransform) or “image is just an optional decoration, and never affects the geometry size” (TCastlePlane). It seems combining all their features would result in a complicated API… but we will keep an eye on this.

  4. We have enabled using cubemaps and 3D textures (nodes like TImageTexture3D, ImageCubeMapTexture) to be used in any material “texture slot”. For example, they can be used to define a TPhysicalMaterialNode.EmissiveTexture, TMaterialNode.SpecularTexture and more now.

    Previously, some of the material texture slots supported only 2D textures and the 3D / cubemaps were allowed only in the “main” slot (which was: TPhysicalMaterialNode.BaseTexture, TMaterialNode.DiffuseTexture, TUnlitMaterialNode.EmissiveTexture). This limitation no longer exists, all material slots allow 3D and cubemaps.

    Note: There is still some special code for the “main” slots, so e.g. ShaderTexture is still not supported in all slots. With time, we want to get rid of all such constraints, feel welcome to submit issues / ping us about it.

    See this issue for sample testcase.

  5. We allow customizing the proposed_unit_prefix in project settings. This makes sense if you don’t want your unit names to start with Game (e.g. because you’re not making a game).

  6. We have improved physics interaction with TCastleTransformReference. We warn when collider / bodies are inside. We calculate bounding box properly when collider is at TCastleTransformReference.

    See this forum thread for some notes and tests that caused this.

  7. Our pasls (used for the code completion by our VS Code extension) has been improved:

  8. I spend some time with Valgrind optimizing a few engine low-level operations. This was fruitful. Per-frame work (rendering) is in one testcase now 0.579 fraction of the old one (so it’s almost ~2x faster).

    For this work, I used the “many cubes” testcase on GitHub – michaliskambi/many-cubes which followed from the “Drawing Many Cubes Faster” forum thread.

    The gains do not translate to all possible applications that easily, so don’t expect a 2x FPS increase in your applications now… but maybe you will notice some speedup 🙂 So give new engine a try, let us know (e.g. in the forum thread) about your tests and speed. You’re also welcome to provide us “testcases to optimize” (though try to keep them real-life, not contrived :). This helps, when I can just run profiler on some something concrete, and advise what to adjust (in your code and/or in the engine).

  9. Moving / resizing window (TCastleWindow) on WinAPI is now fixed to be smooth.

    For details what we do, what was wrong, and how we fixed it see this GitHub issue.

  10. We have internally a nice WinAPI messages debugging feature. Compile with CASTLE_DEBUG_WINAPI_MESSAGES symbol defined.

  11. We had to bump requirements of our Raspberry Pi 32-bit (Arm) builds. They require now Bookworm OS version. This matches now builds on all other systems (Linux on regular x86_64, and Raspberry Pi 64-bit (Aarch64)).

    Before 2025-06-13, we provided binaries for 32-bit Raspberry Pi (Arm CPU) in a version compatible with older GLIBC, including the one in Debian’s bullseye (to support older Raspberry Pi 4 32-bit installations). However, this gets hard, as DietPi removed some old images which we relied on, by this GHA action. We migrated to use official images from raspberrypi.org.

  12. We expose now TX3DNode.WaitForRelease and NodeRelease, simpler and with more obvious names alternatives to TX3DNode.KeepExistingBegin, TX3DNode.KeepExistingEnd, FreeIfUnusedAndNil.

  13. Fixes to castle-editor-portable editing 2D game template with Spine, and more general: DataDirectoryInformation and ApplicationDataOverride interaction fixed.

  14. To improve the comfort of cloning from GIT the engine, we now limit our paths to 130 (previously, our longest path reached 165). This decreases changes you will run into trouble on Windows, with Windows long paths or GIT on Windows long paths disabled.

    See resources like How To Fix ‘Filename too long’ Errors in Git on Windows for details, linked also from our compiling from sources. These problems can be avoided by better Windows and GIT configuration, but it’s not default, so we improved the engine to minimize the chances you run into this.

Comments on the forum ➤

More scenes are shadow casters for shadow volumes out-of-the-box, because of the auto-detection of 2-manifold scenes

Posted on

Demo from Delphi Summit 2025, with shadows
Demo from Delphi Summit 2025, with shadows
Alpaca, bull, shadows and WholeSceneManifold
Throwing chickens demo

(Yes, it’s a 3rd news about Castle Game Engine in 3 days. More to come — we have a backlog of things to announce! Brace yourselves 🙂 )

We introduced an algorithm to detect 2-manifold scenes better, meaning that all scenes that are really 2-manifold (even if not all shapes inside are 2-manifold) are automatically shadow casters for shadow volumes.

This improves shadow volumes usage experience. You no longer have to mark such scenes with TCastleRenderOptions.WholeSceneManifold.

OK, I can see that the above description, while correct, may be confusing if you’re not familiar with how shadow volumes work. Let’s unpack this slowly 🙂

  • Shadow volumes is one of the algorithms to achieve shadows using Castle Game Engine. It’s right now the simplest one to use, you only need to have 2-manifold models and then flip the Shadows checkbox at the light source to true.
    • Note: The “simplest shadows algorithm to use” award will likely change to shadow maps in the future, once we implement a few improvements to it. See also recent news post about shadow maps plans.

    • But even then, both algorithms (shadow volumes and shadow maps) will remain useful and available and in our engine. They both have their advantages and disadvantages (how shadows look, performance and possible optimizations, what is valid shadow caster…).

  • For shadow volumes, only 3D objects that are 2-manifold can cast shadows. 2-manifold means that each edge has 2 neighbor faces. This is the most natural state for 3D models that represent real things, that have a volume and are watertight, though in practice many 3D models have only most edges with 2 neighbors. The shadow volumes algorithm strictly requires that all the edges of things that cast shadows have 2 neighbors.

  • We allowed already 2 ways to cope with 2-manifold requirement: either make all shapes 2-manifold, or use TCastleRenderOptions.WholeSceneManifold to treat whole scene (unchecked) as 2-manifold.

    • BTW, what is a “shape”? Shape is part of the scene, the simplest unit passed to the GPU.
      • In glTF, it’s a primitive.
      • n Blender, it’s a subset of Blender’s object with a single material.
      • In X3D, it’s literally the X3D Shape node, loaded to TShapeNode instance in our engine.

The new improvements means that you don’t need to touch TCastleRenderOptions.WholeSceneManifold if the scene is already 2-manifold.

Now, using the TCastleRenderOptions.WholeSceneManifold is only necessary if:

  • You want to force the scene to be shadow caster for shadow volumes, even if it was not detected as 2-manifold, Beware that rendering artifacts are possible in this case. However, we did find a number of cases when this forcing actually works properly (at least for the camera position/orientations that mattered in a given demo), despite scene not being a correct 2-manifold.

  • Or if you just want to speed up loading. Marking scene as TCastleRenderOptions.WholeSceneManifold avoids any automatic detection, the appropriate check “passes automatically”.

We took care to check that this auto-detection doesn’t cause any issues:

  • We checked it doesn’t cause unnecessary slowdown. We time it, showing in log if it would take more time > 0.01 sec (it never did in our tests).

  • We checked it doesn’t cause problems due to per-shape TCastleScene.DistanceCulling being disabled on scenes that are 2-manifold, but when shapes are not 2-manifold. The per-shape TCastleScene.DistanceCulling check is now really only done when shadow volumes are used, and scene is shadow caster, and whole scene is 2-manifold (but some shapes are not 2-manifold).

We have updated example on examples/viewport_and_scenes/shadow_volumes_whole_scene_manifold, along with README description and screenshots inside. Part of this demo now works “out of the box”, alpaca model is automatically a shadow caster.

We also updated documentation about shadow volumes. Many things have been upgraded, and naturally the section about 2-manifold objects (when they are detected, and when is RenderOptions.WholeSceneManifold useful) has been rewritten to reflect the current state.

We also updated the Castle Model Viewer menu “Help -> 2-Manifold Information (Shadow Volumes Casting)”. New colors of edges:

  • yellow: manifold edges in the same shape, so this edge connects 2 faces within the same shape.
  • white: manifold edges in the whole scene, so this edge connects 2 faces from different shapes.
  • blue: border edge that doesn’t have 2 face neighbors. If you have this, this scene cannot be (reliably) a shadow caster for shadow volumes, because it is not 2-manifold.

Testing shows that this detection makes sense in many cases (and avoids you having to toggle dangerous TCastleRenderOptions.WholeSceneManifold) but also it fails in many cases (so TCastleRenderOptions.WholeSceneManifold still has a use-case, there are often no noticeable artifacts despite model not being 2-manifold).

All in all, testing shows it’s a benefit, and doesn’t have any drawbacks 🙂

Sadly, it doesn’t mean we can get rid of TCastleRenderOptions.WholeSceneManifold (it would be nice to get rid of this dangerous checkbox, but it still makes sense).

Test it on your own projects and let us know (e.g. in the comments on the forum) how it works for you!

And if you like this work, please support us on Patreon. Thank you!

Comments on the forum (1) ➤