First of all, I’m proudly attaching a few images of various games using Castle Game Engine running on a real iPhone:)

Our build tool got some significant improvements lately. I hinted about some of them in the recent “Easy compilation for iOS” announcement, but actually there’s more, and some of them benefit all platforms 🙂 Here are the details:

1. Using the "castle-engine-output" directory for compilation temporary files (.ppu, .o), and for Android and iOS projects. The advantages:

   • The compilation files are kept per OS/CPU, so they can be reused more (no need to recompile everything just because you switch platforms).
   • The Android project is in a predictable location (not in some /tmp/castle-engine-), which is useful to run ‘ndk-gdb’.
   • The iOS project is in a predictable location, which is useful to run XCode.

2. Project files (lpr) for Android, iOS (and soon — for others too) can be auto-created. So you really don’t have to write anything to recompile your project for a new platform. You only need to provide game_units in CastleEngineManifest.xml, and make sure your units initialize Application.MainWindow . Make sure you define game_units in CastleEngineManifest.xml.

3. Android packaging process fixes and updates.

   • CGE code fix for using (exact) FPC 3.0.2 to cross-compile to Android.
   • The build tool no longer requires so many things (from Android SDK and NDK) on $PATH. It can guess everything’s location now from ANDROID_HOME (your SDK location).
   • Much improved wiki page about installing Android dependencies. In particular, it contains now screenshots how to use the “SDK Manager”, that is integrated in “Android Studio” and replaces the old “android” GUI tool from previous SDK versions.

4. iOS-specific improvements:

   • The iOS wiki page was much improved and updated, to describe the process of compiling to iOS.
   • The src/library/compile-iOS.sh script was reworked and updated. Many changes, but in principle it should generate exactly the same thing:)
   • The "castle-engine compile --target=ios" is available, and generates a ready libxxx.a to be inserted into an XCode project.
   • CastleWindow “library” interface (used for iOS in a library) simplified.
   • Package any game for iOS! Just run "castle-engine package --target=ios" and you get an XCode project, that compiles out-of-the-box in XCode, and can be tested and published from XCode. You can add --mode=debug if you like.

Trivially easy compilation of your games to iOS!!!

You can now take any Castle Game Engine game, and recompile it for iOS (iPhone, iPad) easily. No need to write *any* iOS-specific code. Short instructions:

1. Follow iOS documentation to get FPC, with a cross-compiler, for iOS targets.
2. Inside CastleEngineManifest.xml, define game_units="...", listing the necessary game units to be included in your lpr. It’s often just a single unit, that pulls other units along as dependencies.
3. Run "castle-engine package --target=ios --verbose" in console.
4. Open the resulting project in XCode. From XCode you can build it, run it in a simulator, publish… I emphasize that the project builds out-of-the-box on Xcode, zero modifications on your side are necessary. Just open the project, and press “Run” button in XCode.

I will be posting more details (and polishing some rough edges) soon 🙂 Learn more about the build tool (“castle-engine”) and CastleEngineManifest.xml at these wiki pages. I just updated them with information about --target=ios and game_units.

Many thanks go to Szymon Stoma and Ten Square Games for making Apple hardware available to me, making it all possible!

And a great many thanks to Jan Adamec, who made the initial iOS work in our engine! Everything I did was just rehashing of that work, to integrate it with the build tool.

1. I was working intensively on support of CommonSurfaceShader (aka “material on steroids”) in view3dscene and Castle Game Engine, and the following features have been added:
   • specular maps (vary specular color throughout the surface, e.g. making it selectively shiny or “rough”)
   • shininess maps
   • ambient maps
   • configuring displacementFactor for parallax bump mapping
   • support for reflectionFactor and transmissionFactor in ray-tracer

   This is all added to the previous features: support of basic factors (similar to the standard Material features) and normal maps (bump mapping). Bump mapping was also improved a bit.

   The demos are inside bump_mapping/common_surface_shader subdir (you can download complete demo models contents from GitHub). You can open them using the latest view3dscene from snapshots. Or you can just compile the engine from GitHub

   The updated CommonSurfaceShader information is here. The fields marked in bold there are supported in view3dscene / Castle Game Engine. There’s also a lot of text that may help you understand how CommonSurfaceShader works:)

2. In a (related) news, I have improved our custom Blender exporter to X3D. It now exports the CommonSurfaceShader, including various texture configurations like normal maps, specular maps and so on.

   This means that an artist can configure all the goodies mentioned above from Blender! Just export with “Use CommonSurfaceShader” checkbox, and the resulting file will include CommonSurfaceShader with all the parameters and texture configuration.

   The details are here.

   My notes about exporting X3D to Blender (part of the Castle Game Engine documentation) include a detailed description how to use this feature. See the “Extra material textures (normal maps, specular maps) with CommonSurfaceShader” section here.

   The modifications to the Blender exported are not yet submitted to the Blender developers, but they *will* be:) I want this to be present in Blender out-of-the-box.

   At the end, I wanted to emphasize that this work was sponsored by Castle Game Engine patrons on Patreon. If you like what I’m doing, please consider supporting me, through the page https://www.patreon.com/castleengine . This really helps me spend more time on the engine and view3dscene, and you can also request a particular feature. This month, Robert Daniel Murphy requested “easy export from Blender of normal maps and specular maps”, and look what cool things happened! 🙂

I was playing with the ray-tracer inside Castle Game Engine this weekend. Although the focus of our engine is real-time rendering (not a software ray-tracer), but there is a distinct pleasure when you’re able to generate pretty images without the help of OpenGL:)

New ray-tracer features:

• It can now use smooth normal vectors.
• Classic ray-tracer supports now 2D textures, with bilinear or nearest filtering.
• It looks at Background.skyColor.

You can try it out e.g. using view3dscene Ctrl + R (“Display -> RayTrace!” menu item). From code, you can use the CastleRayTracer unit.

The ray-tracer in CGE is still just a toy subproject for me. Our ray-tracer does not try to compete with professional, full-featured ray-tracing renderers existing today. But it is a nice demo that, using Castle Game Engine API, you can take a scene and create a decent ray-tracer, because

1. All the necessary information about the 3D scene is available,
2. You have a fast structure (octree) to perform ray collisions.

I hope that you enjoy it!:) If anyone here is interested in putting more work into this way of rendering (we have classic ray-tracer and a path-tracer), if you dream about creating a real, full-featured physically-based solution, than please join the development of CGE! I would happily see someone extend the CGE ray-tracer to render some really cool stuff! 🙂

An old gallery of images is here.

I’m proud to announce an initial implementation of CommonSurfaceShader in Castle Game Engine and view3dscene! CommonSurfaceShader acts as a powerful “material on steroids” X3D node, in particular with support for normal maps (bump mapping).

1. The documentation

2. The demos

3. To try this *now*, you can use view3dscene from our “nightly builds”. Or you can compile any of the engine tools (like examples/3d_rendering_processing/view_3d_model_basic ) using the engine code from GitHub.

This is happening thanks to the support on Patreon (https://www.patreon.com/castleengine). Robert Daniel Murphy sponsored improving the Blender exporter to be able to export normalmaps (and specular maps and similar) from Blender to Castle Game Engine easily. I took the idea a little further, and implemented it by adding the CommonSurfaceShader node to the engine, and then the Blender exporter will export an X3D file with the CommonSurfaceShader.

This way the Blender exporter will be improved for everyone, e.g. Instant Reality / X3DOM users will also benefit by having an exporter that can write CommonSurfaceShader.

More work is yet ahead (the Blender exporter, and the specular maps are not done yet). But the CommonSurfaceShader, with many basic fields, and normal maps, is supported now!

The CommonSurfaceShader works both for interactive rendering, and for our toy raytracer. It is also understood when editing materials in view3dscene (Edit->Edit Material->… menu items).

P.S. If you like view3dscene, or you’d like to request more view3dscene features like that, please support me on Patreon !:)

Recently I’ve been playing with fpcupdeluxe, a great tool to install FPC/Lazarus (stable, unstable…), with cross-compilers. I’m very impressed by it, and I wrote a wiki page documenting how to use it (in the context of Castle Game Engine, although contains some general notes too):

https://github.com/castle-engine/castle-engine/wiki/fpcupdeluxe

In another news: Ten Square Games is helping us by lending Apple hardware with the latest Mac OS X! This is a great help towards the upcoming improvents of iOS in the Castle Game Engine (integrating it with the build tool better). Thousand thanks!

Castle Game Engine and view3dscene support now the STL format for 3D models, commonly used for 3D printing. This means that you can open these models using view3dscene, or the engine API (TCastleScene.Load), and you can convert STL files to X3D.

It’s a really simple 3D format (just vertexes with normals), and I think that the current loader (in file x3dloadinternalstl.pas) nicely serves as an example 3D file loader in our engine. It shows how to read binary and text files from a TStream instance using some helpers in our engine.

More information about the STL format is available in Wikipedia. We support both the text (ASCII) and binary formats.

Blender includes an exporter to this format.

Many sample models in the STL format, ready for 3D printing, can be downloaded e.g. from Thingiverse.

If you’d like to try it NOW in Castle Game Engine, you can download the view3dscene from snapshots. Or you can grab the source code of the engine and view3dscene from GitHub: https://github.com/castle-engine/castle-engine/ , https://github.com/castle-engine/view3dscene/.

We’re happy to announce Castle Game Engine 6.0.2 release!

Download it from our webpage.

This is a small, mostly-bugfix release. So we only have 6 new features:)

New features:

1. sprite-sheet-to-x3d tool: The animations duration is now calculated looking at the number of animation frames and the FramesPerSecond value. FramesPerSecond is by default 4, but it can be changed by the –fps= command-line option.
2. New test_local_characters testcase (inside examples/fonts/test_local_characters/), testing reading and rendering of international characters (Chinese, Russian, Greek…).
3. LoadAnimatedGifs, see an example GIF player🙂 It requires having ffmpeg installed, though, for now.
4. Better API around TextureProperties X3D node.
5. Automatic gzip extension recognition for URLReadXML / URLWriteXML (by Eugene Loza, thanks!).
6. Unix manpages for utilities can be generated (see doc/man/man1/ in sources). All utilities support now –help and –version options.

Bugfixes:

1. OpenGLES (mobile) fixes for Color and ColorRGBA nodes handling.
2. Removed the proprietary Chartboost and Heyzap jar files from the distribution. They were packaged by accident in our zip and tar.gz archives. Users should download them on their own, following links from Android components page.
3. Fix reading X3D files with IMPORT.
4. Fix UI in examples/fonts/html_text.lpr.
5. Various fixes for switching font at runtime. The test_local_characters demo shows that now everything works.
6. Remove the warnings from FPC 3.x around WideString convertions when dealing with XML units (by Eugene Loza).

Please check the downloaded file correctness!

Downloading the files from SourceForge may be unreliable now, in my tests. After downloading, please double-check the correctness of the downloaded castle_game_engine-6.0.2-src.zip file:

• the size should be precisely 126164527 ,
• the md5sum should be 7f6ccd3f4d6a2547299ea4dc9ef0ad15 .

I’m talking with SourceForge to have it fixed. Eventually, we may move our downloads to another server.

We have just released view3dscene 3.16.1. This is a bugfix release for an important bug that slipped in view3dscene 3.16.0 (most files using the IMPORT keyword failed to load with “Invalid type cast” message).

view3dscene is our open-source cross-platform X3D and VRML browser (and a viewer for other 3D formats). It is quite powerful tool on it’s own, to inspect 3D models in various formats — it can play animations, you can work in 3D worlds with collisions and gravity, it can play X3D scripts and more:)

All the comments are welcome, as always!

I improved our API reference. It now has a search box, and a navigation toolbar, making it look more like a normal part of the Castle Game Engine website.

Hint: I’m the maintainer of both Castle Game Engine, and PasDoc — an open-source documentation tool for Pascal 🙂 I actually enhanced PasDoc to make it possible. PasDoc has now three new command-line options and produces nice HTML5 output. If you use PasDoc in your own projects, you benefit too — you can now style the PasDoc output to fit your webpage! If you’d like to try PasDoc, go to https://github.com/pasdoc/pasdoc/wiki .