As a great Blender fan, I was unhappy that since Blender 2.8 release we lost some integration features between Blender and Castle Game Engine. So I decided to fix the situation, and upgrade the support to a new level 🙂
It’s not all finished yet, one more big feature will come (spoiler: skinning in glTF)! But I can already announce various improvements to what you can do. The documentation about exporting to Blender also contains an always-up-to-date instructions.
castle-anim-frames can also now use the glTF format internally (instead of X3D) to export each frame.
Unfortunately the effect of castle-anim-frames+glTF is not perfect, because the generated frames are not “structurally equal”, so you will typically want to set “Frame Skip” to “zero”, otherwise animation isn’t smooth. But in effect the files will be huge…
A solution to the above will be support of skinning in glTF. Working on it!
I created some Blender demos (to test exporting to glTF and castle-anim-frames), see https://github.com/castle-engine/demo-models/tree/master/blender . They nicely show that glTF exporter is really good (so we want to use it, and advise it as the best exporter) and already exports various things (like PBR, unlit, normalmaps) correctly to CGE.
We now support glTF unlit materials in Castle Game Engine and view3dscene (using glTF extension KHR_materials_unlit, used by Blender -> glTF exporter).
In effect, the textures will not be distributed on other platforms, i.e. castle-engine package --target=xxx (see the build tool documentation) will automatically exclude the unused textures on target platform.
See the documentation for a precise description and example what to write in your data/material_properties.xml file to use it.
Our build toolrun command on Unix now supports a “wrapper script”, which allows to e.g. modify environment variables (like LD_LIBRARY_PATH) before running the application.
An example of such script would look like this:
# Include current directory in LD_LIBRARY_PATH, to find fmod dynamic library
./play_sounds "[email protected]" # <- replace this with name of your application
Executing castle-engine run will simply look for run.sh or <application_name>_run.sh script in the project directory, and executes it if found (instead of executing the compiled binary directly).
castle-engine compile and castle-engine package commands support the --ios-simulator option, to include the iOS simulator support. By default this is off, as including simulator support makes build longer (2 more platforms to compile for) and often it is not necessary.
This is meaningful only when building for iOS, that is with --target=iOS for the build tool.
Much enhanced classic (Phong) lighting model thanks to the enhanced Material node with lots of new fields for textures (emissiveTexture, normalTexture, specularShininessTexture, ambientTexture),
More natural “unlit” rendering using the new UnlitMaterial node (very useful for 2D games, and better than previous approach of “Material with only emissiveColor non-zero”, see Why is UnlitMaterial useful for the detailed reasoning),
Image-based lighting using EnvironmentLight node. This is in-progress now (not yet working).
All of this is implemented in CGE. We get latest X3D features in this area, while also becoming a reference implementation of these X3D concepts.
This change also pushed many fixes to the existing lighting shaders, to be pretty and 100% correct (in regards to both X3D 3 and X3D 4). This means:
SeparateDiffuseTexture is now always “on”. This means that X3D Appearance.texture multiplies only diffuse factor (in Phong shading). So the emissiveColor or specularColor are not affected by the Appearance.texture.
This was always (in all X3D versions, past and future) required.
Note that Gouraud shading continues to work as before, because in Gouraud shading there’s technically no other choice: Appearance.texture must multiply everything (the whole result of lighting calculation).
Using Material with only emissiveColor non-zero behaves now 100% correctly, following X3D equations.
Previous it was not only an “optimized case of Material”, it also changed the behavior: Appearance.texture was multiplied with emissiveColor (as opposed to multiplying it by diffuseColor). Even when SeparateDiffuseTexture was true, even when Phong shading was used.
It’s no longer the case.
Appearance.texture now always multiplies diffuse factor of the Material, if possible (IOW in Phong shading). Only in Gouraud shading it behaves differently (as then it has to multiply everything).
Use UnlitMaterial instead of Material to have unlit shapes. In case of UnlitMaterial, Appearance.texture always multiplies the emissiveColor. Other things (Color nodes) also behave more naturally for unlit case.
So it’s simple now:
When using Material (Phong lighting model) -> Appearance.texture multiplies diffuseColor
When using UnlitMaterial -> Appearance.texture multiplies emissiveColor
When using PhysicalMaterial -> Appearance.texture multiplies baseColor
Color and ColorRGBA nodes are also correct now. They replace the diffuseColor in case of Material — always. Previously, in case of only emissiveColor non-zero they were multiplied and by emissive factor, which was contradicting 2 points of spec. Now they replace the diffuse factor, always (whether “only emissiveColor is non-zero” or not).
In games where joystick support is essential, or in “multi-player games on a single device” (many people playing on a single computer with multiple joysticks connected) you can use these events to automatically pause the game, display the player configuration screen etc.
This allows to meet Steam recommendations on joystick behavior.
iOS is the platform used by Apple iPhone and iPad devices. We’ve made a number of improvements to it, caused by upcoming The Unholy Society for mobile:
New build tool options to build and deploy (“archive” in Xcode terms) iOS application from the command-line (in batch mode). For example, use castle-engine package --target=ios --package-format=ios-archive-ad-hoc to get an IPA file of your application, which can be uploaded to your devices or TestFairy. It is documented in the Castle Game Engine for iOS page.
Suport for square compressed textures on iOS.
Note: BTW, castle_engine_auto_generated.xml was renamed to CastleAutoGenerated.xml, following our conventions for other CGE-special files.
FreeType support on iOS. This means you can freely load font files (TTF, OTF) at runtime on iOS. You don’t need to do anything special to activate it, just load font files as decribed in our manual and it will work on iOS.
Initial alpha versions of view3dscene-mobile are available for download (as an APK file). Our model viewer, view3dscene, is coming to mobile! view3dscene-mobile was developed by Jan Adamec and Michalis Kamburelis long time ago. Due to Michalis being overworked, it still wasn’t released officially. I want to fix it soon!
Fix for Android reading/writing files from “external storage” (anywhere outside of application data, like SD card): you need to include new service read_external_storage or write_external_storage to have proper permissions to do this on new Android.
The game is using our Castle Game Engine for everything, of course 🙂 The programming part was done by two CGE developers — Michalis Kamburelis and Eugene Loza. And the complete game credits go to the whole Cat-astrophe Games team of course.
This is only the first part of adventures of our hero BonBon. Soon it will be available on mobile devices (iOS and Android) too! Subscribe to Cat-astrophe Games news to comment and learn more.
For example you can send these logs to a remote server. This CGE example shows how to do it. It assumes you have your own server with a simple PHP script somewhere (the PHP example script is also included in the sample code).
You can integrate your mobile game with TestFairy. It is a mobile testing platform that allows to distribute test applications easily (on both Android and iOS). It can also (optionally) gather logs from testers, their device details (phone model etc.), and even record videos of their playthrough.
Recently I did a little reading about what is “gamma correction” in computer graphics. It’s actually a simple concept with a simple implementation (at least in the basic approach), and I summarized my knowledge here: Gamma correction in X3D and glTF.