Tag: x3d

Particle system updates (custom shaders, web support), FreeCAD -> X3D exporter, documentation (exe size, 2D, easy link to API), geometry shader fixes

Posted on

Particle system
FreeCAD -> X3D, in Castle Model Viewer
Geometry shaders example
Michalis:)

Forgive us for a calm August without the usual weekly announcements, as Michalis spent most of the month on a family vacation. Stay tuned for an upcoming news post about a feature he made when his wife wasn’t watching: Android and iOS compatibility with Delphi 🙂

Until then, here are a number of announcements you can enjoy right now — with big thanks to everyone using the engine and building the ecosystem around it:

  1. Kagamma (Trung Le) has updated his GPU-based particle system for Castle Game Engine. New features, announced on the forum thread, are:
    • Custom shaders: Influence particle position and look using a PLUG system similar to our shader effects. See docs.
    • Web target support: see demo online.
    • Modify the built-in particle mesh in editor.
    • Rotation type support.
  2. Kagamma (Trung Le) also updated his alternative approach for particles in our engine: particles designed in Effekseer version 1.80.5 are now supported. Download the updated shared libraries for Windows, Linux and Android from here.

  3. Marco Mora posted about a new exporter from FreeCAD to X3D with Castle Game Engine extensions. See his forum post for a description and screenshots and the repository here. You can see pretty mirrors on the screenshot, using our X3D extension for mirrors on flat objects. Enjoy and post your feedback in the forum!

  4. We have documented how to optimize executable size (for all platforms) and committed a fix (no need for exports) that makes the generated Linux executables much smaller (~45%) out-of-the-box.

  5. We reworked the creating 2D games page of our manual. This was waiting too long for a “big 2D tutorial” — which may still come some day, but in the meantime, the existing page is hopefully sufficient: it presents a short 2D overview and refers to other pages (since a lot of engine concepts are just the same for 2D and 3D usage).

  6. As a small feature on our website, you can now use URLs like this:

    https://castle-engine.io/api?id=PASCAL-IDENTIFIER

    … and it will automatically redirect to the proper API docs of a given identifier. For example, use

    https://castle-engine.io/api?id=TCastleWindow

    to redirect to

    https://castle-engine.io/apidoc/html/CastleWindow.TCastleWindow.html

    This is nice when writing URLs from outside of our website, e.g. from Markdown files in our source code. Of course, you can also just “spell out” the full URL like https://castle-engine.io/apidoc/html/CastleWindow.TCastleWindow.html there, but using the shorter https://castle-engine.io/api?id=TCastleWindow is

    • A bit easier. You don’t need to think about which unit TCastleWindow is in. This is resolved when we handle the redirect.

    • More future-proof. If we ever move the identifier TCastleWindow from one unit to another, the simple URL https://castle-engine.io/api?id=TCastleWindow will continue to work.

    Note: if you update documentation on our website, this is not necessary! In AsciiDoctor files, just use cgeref:TCastleWindow[] and it will display a proper link to TCastleWindow, showing a warning (in development mode) if TCastleWindow is not found. See cge-www README about developing our website.

  7. Geometry shaders received a number of fixes under the hood. Everything works again, and the code is cleaner than ever 🙂

  8. Important fix for XML reading with Delphi — this was crashing our explore_impressive_castle demo.

  9. Fixed applying transformations if you modify TCastleTransform.Exists often. Previously, setting Exists to true during rendering but flipping it to false during updating was causing a surprising effect: we rendered old transformations. Now the rendering always shows the current transformation.

  10. Trying to open a 2nd TCastleWindow on the web, Android or other platforms that don’t support it will now result in a clear exception, with a message instructing you to check “Application.MultipleWindowsPossible“. This makes the situation cleaner than the previous “opening 2nd window works by accident, overriding the previous window rendering”. Demo is inside multiple_windows_and_viewports.

Enjoying the engine? Please support us on Patreon!

Comments on the forum ➤

Toggle visibility of a group of X3D / glTF nodes

Posted on

Free Modular Shed with interior - model by denniswoo1993 from https://sketchfab.com/3d-models/free-modular-shed-with-interior-30b1eb71bb0e4b889160f8283e1750c1

We support now visible field on various X3D nodes:

We also support very similar glTF extension KHR_node_visibility. The logic of this glTF extension directly maps to X3D visible field.

The main use-case is to toggle visibility of a group of visual things at run-time. From Pascal code in Castle Game Engine, you can find the TTransformNode that interests you using e.g. the TCastleSceneCore.Node method and then toggle the Visible boolean property. If you don’t know what transform nodes are available (e.g. because you load model in other format, like glTF) then inspect it, by first saving it to X3D using e.g. our Castle Model Viewer, and then open X3D in any text editor.

As a testcase, open x3d/visible_toggling.x3dv in our demo-models repository, https://github.com/castle-engine/demo-models/ . We recommend to just get the whole repository (git clone ...) to have all files. It shows spheres (some visible, some hidden by default) and allows toggling “visible” at runtime (using KeySensor.controlKey routed to “visible” fields).

For more notes see API docs on TAbstractGroupingNode.Visible.

TODO:

  • Both the X3D and glTF features specifications’ say to also disable light and fog nodes within a group that you made invisible. We don’t implement this yet — for now, the Visible field only affects the visibility of shapes. If you use this feature, be aware that we will toggle lights and fog in the future too.

  • In case of glTF, it would be great to also support KHR_animation_pointer. This is a bit like X3D routes: allows to animate almost every part of the glTF, in particular it allows to animate the visibility defined by KHR_node_visibility.

If you enjoy this, please support our work on Patreon!

Our screenshot shows house 3D model by denniswoo1993. Not really related to the feature described here, just something pretty arranged in our editor:)

Comments on the forum (2) ➤

New CastleTransformManipulate unit to move/rotate/scale 3D objects in your applications, wireframe “shading” toggle for IndexedFaceSet, Steam achievements fixed with Delphi, slides from my presentation in Bielsko-BiaÅ‚a

Posted on

Transform editing using CastleTransformManipulate
Transform editing using CastleTransformManipulate

You love the super-long news titles, right? 🙂 Again I have a backlog of announcements to do, to communicate everything happening around the engine development. There will be more news in 2024 (stay tuned for traditional “summary of this year, plans for next”), for today a bag of improvements to announce:

  1. We have a new unit CastleTransformManipulate with 2 new components: TCastleTransformHover (visualize the TCastleTransform we hover over) and TCastleTransformManipulate (visualize selection and move / rotate / scale TCastleTransform).

    Together, they allow you to implement selection / manipulation of 3D objects in your own applications just like the Castle Game Engine editor does.

    Their usage is rather simple:

    Practical examples of using them are in:

    Note: We still work on 2 examples above (we want to improve some things in IFC support, and we want to make mORMot example really support collaborative editing). But their usage of CastleTransformManipulate is now completely stable 🙂

  2. We support toggling any TIndexedFaceSetNode to display as wireframe.

    To do this, set TAbstractShapeNode.Shading to shWireframe using Pascal. If you’re unsure how to manipulate X3D nodes from Pascal, read Writing code to modify scenes and transformations manual, section 11. Building a mesh using code and X3D docs.

    Or, in X3D file, set shading="WIREFRAME" following our X3D Shape.shading docs. Test X3D file is shading_wireframe.x3dv.

    Wireframe display done this way is often useful for model debugging, inspection etc. While you can also construct lines explicitly (using TLineSetNode, TIndexedLineSetNode), it is sometimes more convenient to just define a regular mesh using TIndexedFaceSetNode and then toggle it (based on any condition) to wireframe.

    For some design decisions (e.g. why this is called “shading”) see Shape.shading docs.

  3. We have fixed Steam achievements usage (getting, setting) with Delphi.

  4. I made a presentation about our engine at the beginning of December at Meetup Delphi in Bielsko-Biała (Poland). This was a bigger presentation about engine features, physics, Blender, Sketchfab, Steam integration.

    Slides (in Polish) are here.

    ( If you don’t speak Polish, but you’re interested in the topics — slides from my previous presentation in Cologne are the closest equivalent in English. )

Comments on the forum (1) ➤

Copyright Michalis Kamburelis and Castle Game Engine Contributors.

This webpage is also open-source and we welcome pull requests to improve it.

We use cookies for analytics. See our privacy policy. Scarf Analytics