[x3d-public] [x3d] Spec Comment by on 19775-1: X3D Architecture - V4.0
Brutzman, Donald (Don) (CIV)
brutzman at nps.edu
Thu Jun 16 10:06:16 PDT 2022
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-en
gine.io%2Fx3d_implementation_cubemaptexturing.php&data=05%7C01%7Cbrutzman%40
nps.edu%7Cf63c2bc632174712206d08da4fb7f87b%7C6d936231a51740ea9199f7578963378
e%7C0%7C0%7C637909949723831121%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiL
CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=WyDi6RzE
UUg2uuWdQxupJZDluBRGLwOuP0Wv4Wo%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
<mailto: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 <mailto: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-en
gine.io%2Fx3d_multi_texturing.php&data=05%7C01%7Cbrutzman%40nps.edu%7Cf63c2b
c632174712206d08da4fb7f87b%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C6379
09949723831121%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=pZjdj1uJB8NWoV%2FU1manN9
jbWTsCnw%2FqXtG8U11XKg4%3D&reserved=0> and
https://github.com/michaliskambi/x3d-tests/wiki/Deprecate-some-unused-and-ba
dly-specified-MultiTexturing-specification-pieces
<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co
m%2Fmichaliskambi%2Fx3d-tests%2Fwiki%2FDeprecate-some-unused-and-badly-speci
fied-MultiTexturing-specification-pieces&data=05%7C01%7Cbrutzman%40nps.edu%7
Cf63c2bc632174712206d08da4fb7f87b%7C6d936231a51740ea9199f7578963378e%7C0%7C0
%7C637909949723831121%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2
luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=DI1%2FfSql2qIqlQO
6LGgHSLqPVeW%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
<mailto: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
<mailto: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 <http://faculty.nps.edu/brutzman>
From: GPU Group <gpugroup at gmail.com <mailto:gpugroup at gmail.com> >
Sent: Wednesday, June 15, 2022 9:28 AM
To: Brutzman, Donald (Don) (CIV) <brutzman at nps.edu <mailto:brutzman at nps.edu>
>
Cc: x3d at web3d.org <mailto: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 <mailto: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
<mailto: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 <http://faculty.nps.edu/brutzman>
-----Original Message-----
From: x3d <x3d-bounces at web3d.org <mailto:x3d-bounces at web3d.org> > On Behalf
Of Spec Feedback
Sent: Tuesday, June 14, 2022 1:15 PM
To: x3d at web3d.org <mailto: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/componen
ts/texturing.html#MultiTexture>
https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/component
s/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>
https://www.web3d.org/node/1694/submission/6179
_______________________________________________
x3d mailing list
<mailto:x3d at web3d.org> x3d at web3d.org
<http://web3d.org/mailman/listinfo/x3d_web3d.org>
http://web3d.org/mailman/listinfo/x3d_web3d.org
_______________________________________________
x3d-public mailing list
x3d-public at web3d.org <mailto:x3d-public at web3d.org>
http://web3d.org/mailman/listinfo/x3d-public_web3d.org
_______________________________________________
x3d-public mailing list
x3d-public at web3d.org <mailto: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/6e365414/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5353 bytes
Desc: not available
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20220616/6e365414/attachment-0001.p7s>
More information about the x3d-public
mailing list