|
This post is not strictly about Castle Game Engine. It’s about X3D 4.0, which is going to be the next major version of the X3D international standard (see the current X3D standards).
X3D is a major building block of our engine. While you can use TCastleScene as a “black box” (just to load models and play animations), but sooner or later you will want to change something in the loaded model, using Pascal code. For example to tweak a material of texture parameter, or adjust what is collidable. You can even build an entire 3D scene from scratch by Pascal code. This is all possible because everything inside TCastleScene is an X3D node (just a Pascal class like TXxxNode) and you can create/modify X3D nodes at runtime, from Pascal. Examples of it are throughout our documentation (see Building and editing the scene, X3D overview, examples about 3D building, examples about 2D building).
The point of this introduction is that we care about X3D, we want X3D to be modern and expressive, because it allows to express more things in CGE. While we can (and do!) implement a lot of custom extensions to the X3D standard, but some things are just best if they can be added to the standard.
So I did that 🙂
Since a few months, I was working with the Web3D Consortium to add to the upcoming X3D 4.0 a number of modern rendering features. I wrote a pull request to the X3D specification with it all. The summary of this pull request is here: X3D version 4: New features of materials, lights and textures. A summary of this summary:
- New X3D 4.0
Materialnode is much more powerful, allowing to adjust all parameters by textures. It will also have dedicated fields to specify normalmaps (for bump mapping) and occlusion (ambient occlusion textures). -
New X3D node
PhysicalMaterialallows to express a Physically-Based Rendering parameters. It is compatible with glTF, and in fact is the basis of our PBR handling in glTF. -
New X3D node
UnlitMaterialis probably self-explanatory 🙂 It allows to define unlit material in a clear way. -
There is a lot of other stuff and details. Also, image-based lighting is coming, but probably not in X3D 4.0 but in X3D 4.1 (I simply didn’t have time to make it, even though I have initial sketch of spec and implementation too.)
Now the cool part: This is all already implemented in Castle Game Engine. And you already use it 🙂 When reading glTF, you are actually creating in memory a graph with PhysicalMaterial nodes. When reading Spine JSON, you are creating in memory a graph with UnlitMaterial nodes.
I have a number of examples of all the new X3D 4.0 features (in pbr subdirectory there). You can just open them with our view3dscene.
A draft of complete X3D 4.0 specification will be soon available for public. So you will be able to read all the details about the new nodes. And I did a presentation about it last Friday (July the 3rd, 2020), it was recorded and will be publicly available shortly 🙂 I’ll post about it here of course.
In related news, you probably noticed that I put a lot of work into perfect glTF support. I think glTF format is a great thing, and I want to support it 100%. To this end, we want to load everything in glTF into X3D nodes. I have prepared a documentation how does CGE convert glTF to X3D nodes. This should give you insight into various semi-internal things that happen when we read glTF. I wrote “semi-internal” because, while you will usually just treat glTF as a “black box” through TCastleScene, you can also tweak the resulting X3D nodes graph using Pascal code.
I think that in the end, we will have a perfect combination in our engine, by leveraging 2 big open standards: glTF and X3D, as a basis of our engine.
Oh, and if you have any questions about X3D (not specific to CGE), you can ask them on x3d-public mailing list where all people working on X3D listen 🙂