The build toolauto-generate-clean subcommand was improved: by default it cleans only unused files in the auto_generated subdirectories. Call the castle-engine auto-generate-clean --all to clean all current auto-generated files.
I added a limited support for PBR specular-glossiness parameters. It’s converted to PBR metallic-roughness parameters at import (this means it is limited, e.g. we cannot handle specularGlossinessTexture). It’s far from perfect, but at least the result looks sensible for models that contain only pbrSpecularGlossiness specification, and no pbrMetallicRoughness parameters.
While X3D is still a great scene graph format our engine… But as a file format, glTF today wins, with much more capable Blender exporter, that already supports animations, PBR, textures, normalmaps and more. So we advise this approach.
Saving X3D (in particular after glTF -> X3D conversion), now creates unique names for all X3D nodes if needed. This makes sure that model is saved preserving all DEF/USE references and routes (DEF/USE references cannot be always preserved in case names are not unique; in case names are empty, DEF/USE references cannot be preserved, and also ROUTEs cannot be recorded).
Fixed rendering animations defined by resource.xml with one scene for all animations.
Fixes to glTF skinned animation transformation in some cases.
Fixed normal vectors during glTF animations (normals need to be interpolated too).
Optimized animations: Store and use X3D Shape node bboxCenter, bboxSize, don’t recalculate useless octrees when not needed.
I’m working still on optimizing glTF skinned animation speed. It’s still a work in-progress (CGE now does various unnecessary things, causing a slowdown; and we don’t apply skin on GPU yet).
Sketchfab addon for Blender is lots of fun. You can search and download Sketchfab models straight into Blender and then export from Blender to glTF and open it in our engine. On the side you can see screenshots when I had some fun with it 🙂
To test performance, I implemented a GltfForcePhongMaterials toggle. It’s somewhat internal now, in X3DLoadInternalGLTF unit, and I don’t know yet whether I will make it “official” (move it to non-internal unit). Toggling it to true will force glTF importing to use old Phong materials, which are uglier, but may be much faster than PBR materials (esp. when you use Phong lighting model with Gouraud shading).
Time will show whether this will be useful. Anyway, you have the possibility to test it now. You can already use view3dscene from snapshots to toggle it (menu item View -> Load glTF materials as Phong (Faster, Requires Reload)).
Perfect glTF support is now my major task. It quickly became obvious that glTF is just a great asset format for our engine, it works beautifully with Blender and you can find plethora of sample glTF models on the Internet.
Similar to how other engines expose integrations with various programming languages, we’re open to exposing our APIs in other programming languages than Pascal. To remind, you can already use a subset of CGE from the C and C++ languages. Michalis is happy that more integrations will appear 🙂 The more people can use our engine -> the better for the engine future.
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).