This wiki collects some Michalis Kamburelis thoughts about the X3D standard for 3D models. I'm the author of Castle Game Engine, a game engine using X3D intensively (both as internal scene graph, and as the primary format to interchange 3D models).

Important X3D missing features and bugs

This is a wish-list of larger things that I would like to see in the X3D standard. Some of these wishes have a solution in existing extensions (not just from Castle Game Engine). I emphasize that this is from the point of view of a game engine, biased by my own views.

High priority

• Image Based Lighting (EnvironmentLight node). EnvironmentLight (image-based lighting). I initially planned to do it along with PBR for X3D 4.0, but just didn't have time. See notes on X3D version 4: New features of materials, lights and textures.

• Express everything from glTF nicely as X3D nodes.

  I want to be able to express everything that can be expressed in glTF 2.0 using X3D nodes. glTF is quite great, it was designed by Khronos -- people who know what features a modern 3D format should have. Blender->glTF exporter is already much better (supports PBR, animations, metadata...) than Blender->X3D exporter. I strongly believe it should be possible in the future to convert glTF -> X3D node graph without losing any information.

  I document current knowledge about Converting glTF to X3D on this wiki. It contains various bits (some smaller some larger) that I want to handle, to "align" X3D with glTF.

  See glTF Inline in X3D.

  As part of this effort ("handle all glTF features perfectly in X3D") we now finalize Skin node in Castle Game Engine to match the glTF skinned animation capabilities (and simplicity :) ): https://castle-engine.io/skin .

• Binary meshes

• What to say about gamma in X3D spec? See:

  • Gamma correction in X3D and glTF,
  • Gamma Correction in Future X3D,
  • Gamma Correction in Castle Game Engine,
  • Gamma Correction in X3DOM

• Improve the way we can submit specification changes: Allow to propose the specification improvements publicly, using something like GitHub pull requests

Lower priority

• Deprecate some unused and badly specified MultiTexturing specification pieces. See also Multi-texturing problems (description, along with test cases and screenshots)

• KTX

• Incompatibility in how relative URLs are resolved, when used together with EXTERNPROTO

The "lower priority" doesn't necessarily mean that something is not important (e.g. shadows are very important for a modern game engine). But not everything urgently needs to be in X3D specification. E.g. Castle Game Engine has our own extensions to define shadows, and that's somewhat OK. Sure, it would be better to have cross-browser way to "talk" about shadows in X3D, but lack of it is not a big problem in practice.

Lowest priority

• Consider also other extensions from Castle Game Engine that could be generally useful in the X3D standard.

• (this was done, from what I recall, by others; double-checking would be appreciated though) Clarify "Projective texturing" component

DONE, or no longer relevant

• (DONE!) PBR (PhysicalMaterial node), and Material extensions allowing to use normal maps, specular texture, emissive texture etc.

  • I actually managed to tackle most of these things :) My prose to address this is now part of X3D 4.0 (2nd working draft). It is summarized in X3D version 4: New features of materials, lights and textures.
  • Design notes: Include PBR (PhysicalMaterial and related concepts) in the official X3D specification
  • Design notes: What is PBR and why do we want it in X3D?
  • How to add PBR to X3D?
  • Design notes: Note that the ideas described on How to add PBR to X3D? deal also with the question "how to add CommonSurfaceShader features to the X3D specification". In a perfect world, we do not add the CommonSurfaceShader node itself, but we make it's features available through other fields (extending Material and Appearance with new fields).
  • Specification changes, to include PBR and related features

• (DONE!) Make RGB and grayscale textures treatment consistent

• (DONE) UnlitMaterial, see Why is UnlitMaterial useful

• (SUPERSEDED BY PBR CHANGES) Include CommonSurfaceShader in the official X3D specification. This was my proposal when I was not thinking about PBR yet, and I only wanted to upgrade the existing Phong lighting model. Consider this proposal as obsolete. Better focus on what I described in How to add PBR to X3D?.

• (DONE) Do not deprecate "Programmable Shaders" component. This is DONE, i.e. we will not deprecate this component, thanks to a voice from me and others.

• (DONE) Shadows

• (no longer relevant; X3D spec did it differently) Clarify the usage of quotes and backslashes for MFString and SFString in XML encoding

• (DONE) Tangent node in X3D

License

Consider all the ideas and prose on this wiki under public domain, free to be included in X3D standard or anywhere else.

The X3D testcases in https://github.com/michaliskambi/x3d-tests are under permissive Apache 2.0 license. If needed, I can re-license them on public domain too -- let me know.

Any comments and suggestions (to this wiki or testcases) are welcome, you can submit them e.g. as issues to this GitHub project.