[x3d-public] X3D features missing, but desired, by a game engine

[Michalis Kamburelis]

Hi,

This is a wishlist of larger features that I would like to see in the
X3D standard. It's based on a similar list that Michael Aratow
encouraged me to write at the Web3d 2015 conference. Some of these
wishes have a solution in existing extensions (not just from Castle
Game Engine). Discussion and comments are most welcome:)

I emphasize that this is from the point of view of a game engine,
biased by my own views.

I tried to prioritize them, from the most useful.

1. Include CommonSurfaceShader in the official specification. For
specular maps (rust etc.) and bump mapping - to name the most popular
uses. Castle Game Engine has extensions specifically for bump mapping
too, but the InstantReality solution for this is more general, and I
want to implement CommonSurfaceShader in Castle Game Engine too.

  CommonSurfaceShader also "covers" many use-cases where one may
wonder about using shaders and multi-texturing. So it also makes
explicit shader code less necessary (mitigating the need for
"Programmable Shaders" component and my "Compositing shaders"
extensions). They also make X3D multi-texturing nodes less necessary
(mitigating the need to fix existing multi-texturing problems, as
mentioned on https://castle-engine.sourceforge.io/x3d_multi_texturing.php
).

  I'm very happy to see it on
http://www.web3d.org/wiki/index.php/X3D_version_4.0_Development :)

2. Make RGB and grayscale textures treatment equal. The goal is to
change the specification such that "grayscale texture" is for X3D
material mixing (aka "light calculation") used the same way as "RGB
texture with red=blue=green on all pixels".

  Current specification rule is weird for authors (it says that
grayscale textures mix, but RGB textures replace), it is uneasy to
implement (some image loaders do not expose the necessary information
about the image), and it is inconsistently applied in current X3D
implementations.

  My implementation (Castle Game Engine) does it against the current
specification, by default we just always multiply texture.rgb *
material.rgb, regardless if the texture is RGB or grayscale.
Knowingly, because the specification behavior was really
uncomfortable, for X3D authors too. This is the one place where I
allowed myself to knowingly go against the specification. See here for
more details: https://castle-engine.sourceforge.io/x3d_multi_texturing.php#section_default_texture_mode

  The above page also contains tests of this feature on various
implementations, and found it already inconsistently handled by other
browsers.

  It seems that a simple change to the specification (treat grayscale
textures same as RGB) would make things easier both for developers and
for X3D authors.

3. Shadows. At the beginning, just a single field is all that is necessary.

  - Consider Castle Game Engine "shadows" SFBool field (
https://castle-engine.sourceforge.io/x3d_extensions_shadow_maps.php#section_light_shadows_on_everything
)

  - Or, consider InstantReality "shadowIntensity" field (
http://doc.instantreality.org/tutorial/dynamic-shadows/ ). I like
InstantReality approach, and would gladly add "shadowIntensity"
version to Castle Game Engine too. Although it's not
physically-correct (in reality, if the light is completely obscured,
then you're always 100% in shadow...), and would be troublesome for
shadow volumes implementation.

  Many browsers implement shadows, but with varying levels of
capabilities, various implementations. That's understandable, as
there's no "perfect algorithm for real-time shadows", at least today.
It suggests that it's better to "start causiously" in the X3D
specification. Maybe include only a simple field (like "shadows" or
"shadowIntensity"), and delegate more improvements to future versions
of the standard.

4. Binary meshes. The ExternalGeometry and Shape Resource Containers
from X3DOM seem like a perfect solution, see
https://doc.x3dom.org/author/Geometry3D/ExternalGeometry.html . The
presentation about them on Web3d 2015 was very informative. The fact
that we call them "efficient", not only "compressed", is also noted
and appreciated --- the goal is fast delivery to GPU, not just
compression.

Best regards,
Michalis