OK folks, this is (almost) it!:) We will be announcing the grand engine 6.0 release next weekend! Everything in the engine is ready, so you’re welcome to test now the engine version from GitHub and report last bugs:) Everything should compile and work everywhere. We have many automatic tests performed by Jenkins, but they never cover everything, so please do test the engine yourself — in particular, test your own games too.

Below is the last batch of announcements about the smaller new-and-not-yet-announced engine features. It covers work from the last 2 months which was not yet announced properly on our social channels:

New features, in X3D (and view3dscene and demo-models):

1. Shape.shading = “WIREFRAME” possibility in X3D. Allows to render something as a wireframe. For now works on Box and Sphere, but eventually all the geometry shapes will honor it. This is the new, portable to OpenGLES, way of making 3D stuff wireframe. It is a start to implement, in the future, all wireframe-related features on OpenGLES (see OpenGLES TODOs). It is used to debug bounding volumes for creatures/items on all platforms.

2. X3D fields “slices”, “stacks”, “divisions” added to X3D primitives to control their triangulation. The old node KambiTriangulation, which was only consistent with the ancient VRML 1.0, is simply removed now.

3. You can use normalMaps from a MovieTexture. This is a nice technique when you have a mostly flat surface (that can be rendered using a simple flat geometry) that has some small animated features that play with lighting. Like a water surface, or a water (or blood, or anything…) dripping from the wall, or boiling hot lava or such.

   The sample models are available in demo models (GitHub):

   • demo-models/bump_mapping/test_animated_normalmaps.x3dv
   • demo-models/water/water_shaders.x3dv (this was also possible previously, using shaders).

   You can test them in view3dscene. Use the “Edit -> Lights Editor” to move the light’s location, to see that it’s a dynamic technique — everything changes when lighting moves.

   You can use Blender’s “Bake” to bake normalmaps from an animated procedural texture. You can bake a series of normalmaps using the Python script embedded in the .blend file demo-models/water/water.blend, or using the Blender addon “Animated Render Baker”.

4. view3dscene new menu items “Set Up (and Gravity Up) +Y” and “Set Up (and Gravity Up) +Z”

5. Demo models now contain more impressive “path tracer” demos in https://github.com/castle-engine/demo-models/tree/master/lights_materials/raytracer . New files are “office”, “graz”, “bowl_of_soup” — they were used to generate some screenshots on raytracer gallery.

New features, in engine API:

1. CastleRandom: Our custom, fast, wrapped in a class, random number generator. Can be used everywhere where the speed of random number generation is important, and / or when you want to use a couple of separated random number generators (for example, for use in different threads). By Eugene Loza​ (thousand thanks!).

2. RenderStyle on every control is “rs2D” (even on scene manager and viewports, to behave naturally with other controls). This makes it easier to order UI stuff, previous rs3D option was rather counter-intuitive. If you want to revert to old behavior temporarily, set SceneManager.RenderStyle := rs3D .

3. New component TCastleTimer. Cross-platform timer, working as our TUIControl, available both with Lazarus forms and with CastleWindow. See demo in examples/2d_standard_ui/timer_test/timer_test.lpr .

4. TTimerResult, TProcessTimerResult, TSoundType are now opaque types.

5. BlendingSort is bs3D by default.

Many improvements to the webpage

The new website is visible on https://castle-engine.io/ . Some highlights:

1. More streamlined main page (just “Download” the engine)

2. Documentation: Nice “Getting started” page, “Documentation” drop-down menu, many new manual pages, sidebar prominent on the left

3. Much improved “Exporting from Blender” page. We have there many new features, too — a new exporter to castle-anim-frames (able to export any Blender animation — armature, shape keys, even physics and particles!), and script to render skybox and cubemap environment maps.

4. X3D scene graph: Mentions extensions later, nice page about shadow volumes, links to API docs for nodes.

5. New engine logo, thanks to Paweł Wojciechowicz (from SODA studio​ and Cat-astrophe Games)​!

6. “Tutorial” renamed to “manual”, that’s a much better name I think:)

7. New pages like planned features.

New examples:

1. examples/3d_rendering_and_processing/build_3d_tunnel example, by Eugene Loza (thanks!).

2. examples/3d_rendering_and_processing/cars_demo (for manual about TCastleScene)

3. examples/2d_standard_ui/zombie_fighter/zombie_fighter (for manual about UI)

4. some examples moved to examples/research_special_rendering_methods/ subdirectory. Read research_special_rendering_methods/README.txt to know why.

Fixes:

1. QuadSet and IndexedQuadSet rendering on OpenGLES fixed.

2. TGooglePlayGames.RequestPlayerBestScore fixed.

3. Fixes to: Collisions in view3dscene, bump mapping, shadow maps, OnScreenMenu.

4. TCastleButton size recalculation much optimized.

5. PlayAnimation on the same animation fixed.

I often emphasized that the strength of our engine is that it can work with any 3D authoring software. So, I added pages describing Exporting from 3ds Max and Exporting from Maya to our documentation, with screenshots documenting the process. I hope that this is useful.

P.S. In case you wonder, I’m still a 100% Blender lover:)

We can now read and render 2D maps designed in Tiled Map Editor. A demo, along with sample map data, is available in the engine examples/tiled/ subdirectory (if you take the engine from GitHub of course).

The logic is the unit CastleTiledMap — the class TTiledMap handles the map processing independent on any rendering and inputs, while TCastleTiledMapControl is a simple 2D control that allows to load and display a map.

This is all thanks to a large work by Tomasz Wojtyś! See the pull request #14 for details .

More stuff will come here — like support for hexagonal maps (I’m excited about this:).

You can now find a node in the engine Pascal reference, like TTransformNode, and:

• the Pascal description will include a short summary of node’s purpose,
• and the important properties (like Translation, Center, etc.) are visible,
• and (with time…) the properties will be documented too.

To make this prominent, we also link to it from our X3D components description (grouping component, for Transform node) (by “API reference” links). I want to emphasize this way that you can build and modify the X3D graph at runtime, which is a way to do many cool things with the engine:) Simple example of it is in the tutorial.

To make it possible:

• We have added previous node “helpers” (like “TTransformNode.Translation” helper, wrapping an internal “TTransformNode.FdTranslation”) as normal class properties. This was done by generating files inside the src/x3d/auto_generated_node_helpers/ .

• The node’s descriptions are specified directly in the src/x3d/x3dnodes_standard_xxx.inc files.

• The field’s descriptions are specified inside the src/x3d/x3dnodes_documentation.txt . It is added to the documentation using the PasDoc feature https://github.com/pasdoc/pasdoc/wiki/ReadDescriptionFromFile .

This is of course an ongoing effort, and help in documenting is most welcome!:) Be sure to consult with X3D specification and with our docs to document everything correctly:)

In the future: we *may* add some stuff automatically from X3D Tooltips (but they are not always as concise, or as good, as we would like).

Also in the future: we definitely will gradually hide the somewhat-internal properties FdXxx (first we’ll hide them from docs, and then we may just make them private). In most cases, users should not use them. But not everything yet has the non-FdXxx equivalent, in particular multiple-valued fields don’t have them yet, like FdGrouping.

A new utility “sprite-sheet-to-x3d” was added to the engine. Using it, you can convert spritesheet information into ready-to-use X3D file. Many thanks go to Trung Le (kagamma) for contributing this!

The utility takes a spritesheet with a description (what frames and animations are present in the spritesheet) and converts it into an X3D file. The X3D animations can be played with our simple PlayAnimation method (and friends).

The supported input formats are:

• Starling (.xml). Fully supported.
• Cocos2D (.plist). Covered most of important stuff, rare features are not supported (yet!).

See pull request #39 for more details!

The utility is in the engine sources, in tools/sprite-sheet-to-x3d/ . It can be compiled just like any other engine example, e.g. by executing the shell script tools/sprite-sheet-to-x3d/sprite-sheet-to-x3d_compile.sh . Enjoy!:)

It’s time to annouce some Castle Game Engine plans for 2017!

I have a LOT of things planned, with the main thing being that I will seek funding for the engine development more actively, and the community will be able to fund some larger features through Patreon. I would like to seriously make the engine popular and I would love to see more games being developed with it:)

THE ENGINE FEATURES PLANNED *REALLY SOON* ARE:

1. 6.0 release SOON, of course! Lot’s of features, new website (preview), even new logo!:)

2. Better iOS support (to be able to trivially recompile your project for iOS using our build tool castle-engine, like you can now for Android and desktops),

3. Basic physics, for our upcoming “Sad Sam” apocalyptic highway shooter/racer.

LARGER FEATURES, WHICH I HOPE COULD GET FUNDED THROUGH PATREON ARE:

1. Visual designing of the castle components inside a Lazarus form (like GLScene and FireMonkey 3d),

2. Animations blending (to smoothly fade in/out animation, with cross-fade between animations, for things played by TCastleScene.PlayAnimation),

3. Terrain engine,

4. Blender X3D exporter improvements,

5. Android Cardboard support, maybe also other VR devices — depending on demand, and my access to test devices,

6. Ready components to replicate data over the Interner, allowing to trivially get multi-playter functionality in your games,

7. Vulkan renderer, Metal renderer,

8. Batching of shapes that have equal appearance for start, to optimize the rendering,

9. JavaScript integration with X3D,

10. view3dscene as an Android application,

11. Delphi compatibility.

12. And of course we wait for the possibility from FPC to recompile to web (that is, JS or WebAsembly, probably through LLVM). Then our engine will jump on to the web platform. (Unlike current web plugin, which is soon deprecated by all browsers, unfortunately.)

Lot’s of ideas, as you can see! What is YOUR most-wanted engine feature? Or do you have your favourite feature already mentioned above? Please do comment!:)

You can use Blender “Bake” feature to bake normalmaps from a high-poly model to be applied on a low-poly model. You can create the high-poly model e.g. using the “Sculpt Mode” in Blender.

Such normalmaps can be immediately used as the “normalMap” texture for Castle Game Engine.

The resulting model reacts nicely to lighting. It has a detailed shading, just like the high-poly version. But the geometry comes from the low-poly version, so it’s still very fast to render. This technique is 100% dynamic: both the creature, and the light, may be animated in any way, and the shading changes correctly.

The sample model is available in https://github.com/castle-engine/demo-models/tree/master/bump_mapping/lizardman . You can open it in view3dscene, and use the “Edit -> Lights Editor” to move the light’s location, and use the “Animation -> Named Animation -> …” to run a particular animation. For now, use the view3dscene version from snapshots or GitHub sources.

To use this technique in your own models, you need to use the “normalMap” field of the Appearance.

• You can add it by manually editing an .x3d or .castle-anim-frames file, after exporting if from Blender.
• You can specify normalMap in the material_properties.xml file.

See the “normalMap” documentation and the material_properties.xml documentation. And see the examples in demo-models/bump_mapping/ from demo models.

This blog doesn’t contain all the news from 2016. They are all available only on our Facebook and Google+ pages. I was experimenting with various ways to publish the news before I arrived at the current blog.

We’re proud to present new Castle Game Engine release 5.2.0!

Be sure to also check out the slides and examples (data and code) from a tutorial about our engine given during the recent Web3d 2015 conference. They show (from the ground up) the creation of a simple 3D FPS game and 2D game.

The 5.2.0 release brings various improvements to the engine capabilities and API:

1. GPU texture memory profiler is now available. This tells you exactly which textures are worth optimizing (maybe scale them down, maybe compress for GPU, maybe remove alpha channel or convert to grayscale…). See TextureMemoryProfiler documentation.
2. Many improvements related to texture GPU compression (especially important on mobile platforms, where texture memory is precious):
   • New compression formats available: ATITC, PVRTC, ETC (in addition to previous S3TC formats).
   • Many more functions now accept GPU-compressed images.
   • LoadImagePreprocess allows to replace image URLs at runtime, to switch uncompressed texture files with compressed.
3. New capabilities for font rendering: scaling: TCastleFont.Scale, outline: TCastleFont.Outline, TCastleFont.OutlineColor, print in rect: TCastleFont.PrintRect, TCastleFont.PrintRectMultiline, TCastleFont.PushProperties, TCastleFont.PopProperties.
4. TUIState to help implementing simple UI mode switching (with possible stack).
5. New option android_project was added to our build tool to support custom Java and manifest code in your Android project. This allows to integrate your Android game with Google Games (leaderboards, achievements, save games…), biling, ads, analytics and anything else you want:)
6. Getting and setting fields of X3D nodes has now clean API. Just use LightNode.Intensity := 0.5 instead of ugly LightNode.FdIntensity.Send(0.5).
7. By default we use fcl-image built-in handling of PNG format. This removes the need to use/distribute extra libraries for handling PNG on any platform.
8. On Windows GUI applications, we will log to the xxx.log file by default, instead of trying to log to unavailable stderr. See the updated tutorial link about logging for details.
9. TCastle2DControl component for easily creating 2D games. Already contains a ready T2DSceneManager.
10. Encrypt/decrypt XML data using BlowFish. In the simplest case, just set TCastleConfig.BlowFishKeyPhrase property. This allows to encrypt your XML data, for example to prevent cheaters from easily modifying your game configuration variables in XML. It assumes that the particular value of BlowFishKeyPhrase you use is kept secret — e.g. it’s compiled and maybe obfuscated.
11. Numerous smaller new features: TGLImage.Draw3x1, TGLImage.Rect, TGLImage.ScalingPossible settable, TCasScriptExpression.AsFloat, TFramesPerSecond.MaxSensibleSecondsPassed, TCastleConfig.GetMultilineText (plus a few helpers for TCastleConfig to get/set RGB and RGBA colors), TRectangle.Align (plus related THorizontalPosition, TVerticalPosition), TCastleSceneCore.AnimationDuration .