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

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.

• (DONE!) Include PBR (PhysicalMaterial and related concepts) in the official X3D specification

  • What is PBR and why do we want it in X3D?
  • How to add PBR to X3D?
  • 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

(WORKING ON IT) Next priority

• 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.

• 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

• Clarify "Projective texturing" component (that's actually high priority, it has to happen before X3D 4 release, but it's not on Michalis' head to do this :), I will only watch to make sure it is done)

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

• Shadows

• KTX

• Clarify the usage of quotes and backslashes for MFString and SFString in XML encoding

• 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.

No longer relevant

• (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 obsolte. 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.

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.