[x3d-public] [x3d] Spec Comment by on 19775-1: X3D Architecture - V4.0

Thu Jun 16 09:46:36 PDT 2022

Nice idea for profiles :)

There is a "Full" profile of X3D already which for me roughly equates
already to "Crazy Permutation Prototyping Profile".

To be serious, I do not think that X3D spec should include everything
possible for prototypes. This makes design hard, understanding (by authors,
implementors) hard and actual implementations hard. X3D is already the
biggest 3D spec (at least looking at open and semi-open specification
formats -- looking mostly at X3D, glTF, Collada, Wavefront OBJ, STL) and
it's kind of a problem. The (unfortunately somewhat correct) perception of
X3D is that it is "everything and a kitchen sink" model format. Actually
X3D is even a set of specifications ( https://www.web3d.org/standards ) and
I think most practical implementations deal at least with 4 X3D specs
(nodes, classic encoding, xml encoding, H-Anim for skinned animation). This
is too much :)

Compare this to glTF, which is like "carefully chosen feature set of really
important things, the rest is in extensions".

You need to have some experience with X3D to actually realize that you
don't really use these 150+ nodes from X3D spec in reality. Majority of X3D
models are using like 10-20 of most common X3D nodes.

I believe the right solution is to be careful with what we put in spec, but
at the same time encourage the extension process. This middle ground is
actually used by OpenGL, glTF, and probably many others. It is

- design a specification around the core important concepts

- leave the uncertain things (uncertain whether they are useful, uncertain
whether this format is the right place to define it etc.) to extensions.
This also leads to "formalize" vendor-specific extensions a bit, this way
vendors have a common place to talk about vendor-specific features and
maybe easier reach consensus "hey, this makes sense, let's all do this".

And then you drive the evolution of the standard by extensions. Extensions
may be vendor-specific. Extensions may become "approved by central body
(Web3D consortium -- well, in practice, people on this list)" -- which
means "we reviewed it, it makes sense, we welcome implementors to test it.
And finally extensions are the primary way to introduce new features to
spec (this is how most of OpenGL evolution happened, I think; even
ground-breaking additions, like shaders, started as just an extension at
one point).

And I think we're actually already somewhat doing it in X3D, just not in a
formalized fashion. That is, most X3D browsers have a set of
vendor-specific extensions, and they are documented. CGE, FreeWRL, X3DOM,
X_ITE, InstantReality --- we all have our vendor-specific documentation of
"X3D + our additions". And other browsers look at it, sometimes implement
it too, and sometimes these things do get upgraded to core spec features.
Or at least they inspire -- like CommonSurfaceShader from
X3DOM/InstantReality, that in the end was *not* included in X3D 4, but
instead we took ideas from it and transformed them to fit within "new
Material in X3D 4".

> Example I'm trying cubemaps to get regular texture treatment, including
multitexturing, and (stretch) combining cubemaps with 2D textures in a
multitexture. Why, where is the 'market demand'? There is none.

Actually for this specific case, there is a use :) The
GeneratedCubeMapTexture is essentially a way to do mirrors (on curved
objects). It makes sense to mix it with regular (base/diffuse) texture
which is usually 2D. It's not physically correct to just multiply mirror
into base/diffuse parameter like that, but it remains I think the easiest
way to get cool-looking mirror effect. Like

"""
Shape {
  appearance Appearance {
    material Material {
      diffuseTexture MultiTexture {
        ImageTexture { url "..." }
        GeneratedCubeMapTexture { update "ALWAYS" }
      }
  }
  geometry Teapot {
    texCoord MultiTextureCoordinate {
     texCoord [
      TextureCoordinate { ... set of 2D points ... }
      TextureCoordinateGenerator { mode "WORLDSPACEREFLECTIONVECTOR" }
    ]
  }
}
"""

Disclaimer:

- above is untested

- I used there CGE extension WORLDSPACEREFLECTIONVECTOR,
https://castle-engine.io/x3d_implementation_cubemaptexturing.php

- there should be (or is?) probably a better way to do this, without
MultiTexture. Because just multiplying mirror*normal diffuse is not really
a correct solution.

Regards,
Michalis

czw., 16 cze 2022 o 14:14 GPU Group <gpugroup at gmail.com> napisał(a):

> Thanks Michalis great someone knows openGL.
> -Doug
> deprecation > I see x3d as something for prototyping, so it would have
> some rarely-used-in-practice features, and allow crazy permutations, which
> game engine designers could try and pick the things they need for their
> game engine. Perhaps there could be a Game Engine Profile for things
> actually used at scale? Example I'm trying cubemaps to get regular texture
> treatment, including multitexturing, and (stretch) combining cubemaps with
> 2D textures in a multitexture. Why, where is the 'market demand'? There is
> none. Except clearing out special cases in the code makes it more general,
> more crazy permutations possible. Perhaps there could be a Crazy
> Permutation Prototyping Profile which still has full permutations of
> Multitexturing?
>
> On Thu, Jun 16, 2022 at 5:12 AM Michalis Kamburelis <
> michalis.kambi at gmail.com> wrote:
>
>> 1. I interpreted the "FACTOR" in CGE/view3dscene just like FreeWRL. That
>> is, "FACTOR" indicates to use MultiTexture.color / MultiTexture.alpha. I
>> see I even call it "constant factor" in CGE/view3dscene code, to make a
>> point that it is constant for the whole "execution" of this MultiTexture
>> calculation.
>>
>> I think this was invented to correspond to old fixed-function OpenGL
>> "glTexEnvv(GL_TEXTURE_ENV, GL_TEXTURE_ENV_COLOR, ...)".
>>
>> I believe the spec should be fixed, the existing sentence indeed is
>> incorrect, as there are no "factors at particular stages".
>>
>> From
>>
>> """
>> The texture argument is the factor (color, alpha) from the texture
>> provided for the current stage of the MultiTexture node.
>> """
>>
>> ->
>>
>> """
>> The texture argument is the factor from MultiTexture node <i>color</i>
>> and <i>alpha</i> fields.
>> """
>>
>> 2. There's no alignment here with glTF -- glTF doesn't have MultiTexture.
>>
>> And, also because there are numerous problems with X3D MultiTexture
>> unfixed for many years and it doesn't seem it is used by authors, I
>> proposed in https://castle-engine.io/x3d_multi_texturing.php and
>> https://github.com/michaliskambi/x3d-tests/wiki/Deprecate-some-unused-and-badly-specified-MultiTexturing-specification-pieces
>> that we just deprecate parts of it (leaving only some core functionality
>> subset, to just sum and multiply textures).
>>
>> Regards,
>> Michalis
>>
>> śr., 15 cze 2022 o 18:48 Brutzman, Donald (Don) (CIV) <brutzman at nps.edu>
>> napisał(a):
>>
>>> Thanks Doug… am not sure.  Have shared with x3d-public for further
>>> scrutiny.
>>>
>>>
>>>
>>> Michalis, when defining FACTOR, can we say things more clearly to ensure
>>> good alignment with glTF approaches?
>>>
>>>
>>>
>>> all the best, Don
>>>
>>> --
>>>
>>> Don Brutzman  Naval Postgraduate School, Code USW/Br
>>> brutzman at nps.edu
>>>
>>> Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA
>>> +1.831.656.2149
>>>
>>> X3D graphics, virtual worlds, Navy robotics https://
>>> faculty.nps.edu/brutzman
>>>
>>>
>>>
>>> *From:* GPU Group <gpugroup at gmail.com>
>>> *Sent:* Wednesday, June 15, 2022 9:28 AM
>>> *To:* Brutzman, Donald (Don) (CIV) <brutzman at nps.edu>
>>> *Cc:* x3d at web3d.org
>>> *Subject:* Re: [x3d] Spec Comment by on 19775-1: X3D Architecture - V4.0
>>>
>>>
>>>
>>> Sorry I was reading the committee draft, SELECT arg2 has been corrected
>>> in Draft International Standard.
>>>
>>> But the confusion on the other one, FACTOR is still there
>>>
>>>
>>> in freewrl looks like we've been using Multitexture.color and .alpha
>>> when source is FACTOR.
>>>
>>> And those values are provided once by Multitexture for all stages
>>>
>>> Hypotheses:
>>>
>>> H0: freewrl has been doing it wrong
>>>
>>> H1: spec is unclear
>>>
>>> "FACTOR"
>>>
>>> The texture argument is the factor (color, alpha) from the texture
>>> provided for the current stage of the MultiTexture node.
>>>
>>>
>>>
>>> On Tue, Jun 14, 2022 at 2:35 PM Brutzman, Donald (Don) (CIV) <
>>> brutzman at nps.edu> wrote:
>>>
>>> Thanks Doug.  Entered as Mantis 1397
>>>
>>>
>>>
>>> * Mantis 1397: Fix typo Table 18.3 — Multitexture values for mode field
>>>
>>> * https://www.web3d.org/member-only/mantis/view.php?id=1397
>>>
>>> *
>>> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-CD1/Part01/components/texturing.html#t-MultitextureModes
>>>
>>>
>>>
>>> Change applied in git, ready for editor review/resolution (when Dick and
>>> I next get together).  This should make it time for ISO DIS submission,
>>> they are currently reviewing figures prior to acceptance.
>>>
>>>
>>>
>>> all the best, Don
>>>
>>> --
>>>
>>> Don Brutzman  Naval Postgraduate School, Code USW/Br
>>> brutzman at nps.edu
>>>
>>> Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA
>>> +1.831.656.2149
>>>
>>> X3D graphics, virtual worlds, Navy robotics https://
>>> faculty.nps.edu/brutzman
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: x3d <x3d-bounces at web3d.org> On Behalf Of Spec Feedback
>>> Sent: Tuesday, June 14, 2022 1:15 PM
>>> To: x3d at web3d.org
>>> Subject: [x3d] Spec Comment by on 19775-1: X3D Architecture - V4.0
>>>
>>>
>>>
>>> -- Submitter indicates that this comment may be public: *Yes* --
>>>
>>>
>>>
>>> Comment on 19775-1: X3D Architecture - V4.0
>>>
>>> 18.4.3 MultiTexture
>>>
>>>
>>> https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/components/texturing.html#MultiTexture
>>>
>>>
>>>
>>> -----------------
>>>
>>> "SELECTARG2"   Use color argument 1
>>>
>>> Arg2
>>>
>>> should be
>>>
>>> "SELECTARG2"   Use color argument 2
>>>
>>> Arg2
>>>
>>> -----------------
>>>
>>>
>>>
>>> Submitted on Tuesday, 2022,  June 14 - 1:15pm by  (Doug Sanden )
>>>
>>> IP: 23.17.48.2
>>>
>>>
>>>
>>> See: https://www.web3d.org/node/1694/submission/6179
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>>
>>> x3d mailing list
>>>
>>> x3d at web3d.org
>>>
>>> http://web3d.org/mailman/listinfo/x3d_web3d.org
>>>
>>> _______________________________________________
>>> x3d-public mailing list
>>> x3d-public at web3d.org
>>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>>>
>> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20220616/3629cdd7/attachment-0001.html>