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

Thu Jun 16 12:30:42 PDT 2022

right and I'm hoping I end up with fewer lines of code / fewer special
conditionals / easier to 'guess what the engine is doing' / less spaghetti
code by treating cubemaps as textures. 2D textures have 2D texture
coordinates to map into texture space. Cubemaps have a few different
mappings, and trying to get those mappings generalized - I haven't got that
figured out yet. I'll check your link thanks. -Doug

On Thu, Jun 16, 2022 at 11:06 AM Brutzman, Donald (Don) (CIV) <
brutzman at nps.edu> wrote:

> Thanks for suggested improvements to FACTOR prose.  I’ve applied this, we
> will review (and likely accept/resolve) during tomorrow morning’s regular
> X3D meeting.
>
>
>
> We’re not accepting any functional changes (such as deprecation) at this
> stage.  Possible for 4.1 of course.  Am expecting that getting good
> rendering implementations available to everyone will encourage authors to
> apply some of these lesser-known techniques.  Addition of glTF-rendering
> palette certainly helps too!
>
>
>
> Doug and Michalis, your dedicated work to improve X3D4 specification is
> much appreciated.  Thanks again.
>
>
>
> 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:* x3d-public <x3d-public-bounces at web3d.org> *On Behalf Of *Michalis
> Kamburelis
> *Sent:* Thursday, June 16, 2022 9:47 AM
> *To:* GPU Group <gpugroup at gmail.com>
> *Cc:* X3D Public Mailing List (x3d-public at web3d.org) <x3d-public at web3d.org
> >
> *Subject:* Re: [x3d-public] [x3d] Spec Comment by on 19775-1: X3D
> Architecture - V4.0
>
>
>
> 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
> <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcastle-engine.io%2Fx3d_implementation_cubemaptexturing.php&data=05%7C01%7Cbrutzman%40nps.edu%7Cf63c2bc632174712206d08da4fb7f87b%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637909949723831121%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=WyDi6RzEUUg2uuWdQxupJZDluBRGLwOuP0Wv4Wo%2BhVA%3D&reserved=0>
>
>
>
> - 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
> <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcastle-engine.io%2Fx3d_multi_texturing.php&data=05%7C01%7Cbrutzman%40nps.edu%7Cf63c2bc632174712206d08da4fb7f87b%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637909949723831121%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=pZjdj1uJB8NWoV%2FU1manN9jbWTsCnw%2FqXtG8U11XKg4%3D&reserved=0>
> and
> https://github.com/michaliskambi/x3d-tests/wiki/Deprecate-some-unused-and-badly-specified-MultiTexturing-specification-pieces
> <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmichaliskambi%2Fx3d-tests%2Fwiki%2FDeprecate-some-unused-and-badly-specified-MultiTexturing-specification-pieces&data=05%7C01%7Cbrutzman%40nps.edu%7Cf63c2bc632174712206d08da4fb7f87b%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637909949723831121%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=DI1%2FfSql2qIqlQO6LGgHSLqPVeW%2BKjd1mI3xjsRfELQ%3D&reserved=0>
> 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/62e7afe5/attachment-0001.html>