[x3d-public] X3D minutes 4 DEC 2020: resolving X3D4 endgame issues; light intensity

Michalis Kamburelis michalis.kambi at gmail.com
Sat Dec 5 18:01:38 PST 2020


Oh, by "not for X3Dv4" (in relation to Inline.global idea") I meant "not
for X3D 4.0". I agree with you that this is good idea, I'd like to explore
it within X3D 4.1.

Regards,
Michalis

W dniu niedz., 6.12.2020 o 02:49 Michalis Kamburelis <
michalis.kambi at gmail.com> napisał(a):

> Um, the sentence "Typically lighting intensity values are within range
> [0,1] for consistent composability of multiple scenes with independent
> lights." was your prose, Don, that you wrote in an earlier message :)
> And I disagreed with it. As I wrote, I don't think that limiting
> intensity to 1.0 (or even recommending such a limit, while still
> allowing greater values) is useful.
>
> As for composability, I still don't see how it is affected. If I put a
> very bright global light in scene A, and you Inline it, then your
> scene has a very bright light, that also makes your shapes (outside
> scene A) very bright. And that is OK. Limiting intensity to 1.0
> doesn't change this use-case at all. The scene A can still have 1000
> of useless lights with intensity = 1.0, or a shape that obscures all
> your shapes. Bottom line is -- if you inline A, we assume you know
> what to expect from A, that was always the case with Inline usage in
> X3D.
>
> As for light scope: glTF has no idea of "scoped" lights as X3D. All
> light sources are like global=TRUE in X3D.
>
> As a side note, no 3D authoring tool (Blender, 3ds Max, Maya) have a
> concept of "scope lights" like X3D has (by connecting the scope to the
> transformation hierarchy). They all have different ways to define
> "light source that doesn't affect everything". This means that, while
> the idea of "X3DLightNode.global" is very good (it addresses an
> important use-case), unfortunately the interoperability with authoring
> tools is null.
>
> As for "Inline.global"... I think this is a nice idea (yeah, it has a
> use-case, as you describe). But not for X3Dv4. It may have a broader
> impact / implementation difficulty. I'd like to experiment with it
> myself.
>
> As for 8 lights limit: This limit still makes sense, IMHO. In
> CGE/view3dscene we by default have a limit of "8 enabled light sources
> affecting each shape", so it's a more relaxed constraint (we don't
> limit "all the lights" only "lights at each shape"). And developer can
> increase it (
> https://castle-engine.io/wp/2020/10/22/various-engine-improvements-lift-lights-limit-test-simultaneous-animations-fix-changing-tlevel-player-savescreenrgba/
> ). But anyway, the idea of such limit makes sense. Each light has a
> performance cost. Sometimes you can increase this limit to even 100,
> and it's still OK... but sometimes not. Also, the cost of lighting
> very depends on forward-rendering vs deferred-rendering (which is an
> "implementation detail" from X3D specification point of view).
>
> Regards,
> Michalis
>
> niedz., 6 gru 2020 o 01:38 Don Brutzman <brutzman at nps.edu> napisał(a):
> >
> > 1. Your rephrasing
> >
> > "Typically lighting intensity values are within range [0,1] for
> consistent composability of multiple scenes with independent lights."
> >
> > sounds great to me, thank you.
> >
> > Of relevance is that simple sentence makes it possible for an author to
> determine whether normal composition of arbitrary models can make sense.
> Am not trying to recommend a limit on intensity, simply having a norm
> defined means that abnormal is measurable and composition effects can be
> considered.
> >
> > Just for clarity when reading your response, "incorrectness" means
> outside spec limits, "ugliness" is eye of beholder, "shapes" are OK because
> they don't break other models, but unscoped global lighting can have a
> farther impact...
> >
> > ---
> >
> > 2. But that clarification actually in turn leads to other interesting
> questions:
> >
> > a. do glTF lights have maximum range limits associated with them?  In
> X3D, PointLight and SpotLight have radius values, but DirectionalLight has
> no range limit. (Special-case NavigationInfo headlight has visibilityLimit.)
> >
> > b. might we want to declare that any lights in a glTF model have local
> scope, meaning equivalent to X3DLightNode global FALSE, meaning that the
> light only affects peers and children within the current transformation
> hierarchy.
> >
> > Having a way for X3D scene authors to define global scope TRUE/FALSE for
> Inline content would give X3D authors an excellent degree of control over
> whether lights extend further than desired.
> >
> > Long-standing, currently problematic example: author inlines an X3D
> lamp, puts it on an end table next to the wall, but the lamp shines through
> the wall and illuminates the adjacent room unintentionally/unavoidably.
> Example model:
> >
> > * X3D Example Archives: VRML 2 Sourcebook, Chapter 09 Sensing Viewer,
> Figure 09 9 Desk Lamp
> >
> https://www.web3d.org/x3d/content/examples/Vrml2Sourcebook/Chapter09SensingViewer/Figure09_9DeskLampIndex.html
> >
> > (If you call the front desk in your virtual hotel because you are unable
> to sleep in a room that has become bright as a blast furnace, response to
> this FAQ would be "we are so very sorry sir or ma'am, X3D does not allow us
> to scope your neighbors' lights in the adjacent rooms"... 8)
> >
> > Potential new solution: maybe we should add the Lighting component's
> /global/ field to Inline?
> >
> >    SFBool  [in,out] global           FALSE
> >
> > This would seem to give authors full control over all side effects due
> to lighting when composing scenes, which is certainly better than merely
> stating expectations.
> >
> > Hope this makes sense, hope it might work for both X3D and glTF Inline
> models.  Giving authors control is always preferred whenever possible.
> >
> > ---
> >
> > 3. And another point of light... when we look at the profile
> requirements, there is a value in Minimum Browser Support for 8
> simultaneous lights.  This is not a limit, just a minimum needed to claim
> conformance to the profile.
> >
> > *
> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD3/Part01/interchange.html#t-OtherLimitations
> > *
> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD3/Part01/interactive.html#t-OtherLimitations
> > *
> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD3/Part01/immersive.html#t-OtherLimitations
> > *
> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD3/Part01/fullProfile.html#t-OtherLimitations
> >
> > This was motivated by performance considerations and (if I recall)
> OpenGl limitations in years past.
> >
> > Wondering: is 8 simultaneously enabled lights still a good value for
> Minimum Browser Support in our profiles?
> >
> > thanks...
> >
> > On 12/5/2020 3:27 PM, Michalis Kamburelis wrote:
> > >
> > >
> > > Don,
> > >
> > > I didn't address the issue of "composition of diverse scenes from
> > > multiple sources", because I don't see how this change (removing 1.0
> > > limit) makes any difference. That is, even if someone puts something
> > > incorrect/ugly etc. in an X3D scene, then indeed you have no choice
> > > but to "Inline" it as a whole (or not at all). This argument can be
> > > extended to anything, really :) E.g. if I put 100 light sources (with
> > > whatever intensity) in my scene. Or if I put one pretty 3D shape, and
> > > another ugly 3D shape in my scene. You indeed have to "Inline" it as a
> > > whole.
> > >
> > > Basically, when inlining, you have to assume that the inlined content
> > > makes sense. This was always the case.
> > >
> > > So, I admit I still don't agree with your rephrasing, even though it
> > > is "lighter" now:
> > >
> > > "Typically lighting intensity values are within range [0,1] for
> > > consistent composability of multiple scenes with independent lights."
> > >
> > > Recommending authors to keep intensity in [0,1] is a bad advice, in my
> > > eyes. The right advice is "choose intensity that matches the physical
> > > intensity of the light source". In case of the physical lighting
> > > model, in "17.2.1.1 Overview", we even say exactly what are the actual
> > > corresponding physical qualities. If you model an actual real scene,
> > > you could even just measure it with proper instruments -- and just put
> > > in X3D/glTF/Blender/etc. whatever value you have.
> > >
> > > That being said, the new "lighter" version of your prose is something
> > > I can "live with" :) So if, after reading my above arguments, you
> > > still think it is necessary -> go ahead :)
> > >
> > > Regards,
> > > Michalis
> > >
> > > niedz., 6 gru 2020 o 00:05 Don Brutzman <brutzman at nps.edu> napisał(a):
> > >>
> > >> Thanks for thoughtful continuing examination.
> > >>
> > >> No arguments, appreciated, you've provided excellent analysis
> justifying this kind of usage.  However still not seeing anything in your
> response regarding potential problems from composition of diverse scenes
> from multiple sources.
> > >>
> > >> I remain willing to agree to no upper limit on intensity (i.e. "i can
> live with it" consensus) but, in order to help avoid unwanted composition
> problems in larger X3D worlds combining arbitrary models, still think we
> need some kind of accompanying guidance regarding typical expectations.
> > >>
> > >> Updated draft prose follows, moved up higher into Concepts section,
> hopefully closer to resolution:
> > >>
> > >> ===========================
> > >> 17.2 Concepts
> > >> 17.2.1 Light source semantics
> > >> 17.2.1.1 Overview
> > >>
> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD3/Part01/components/lighting.html#LightSourceSemanticsOverview
> > >>
> > >> "Typically lighting intensity values are within range [0,1] for
> consistent composability of multiple scenes with independent lights. If
> multiple light sources illuminate a single geometric shape, the totals for
> color values computed at a given point may have an aggregated value greater
> than one. While light nodes having an intensity value greater than one can
> provide useful effects, careful consideration of model composability within
> larger external scenes is also worthwhile."
> > >> ===========================
> > >>
> > >> Acceptable?  Improvable?
> > >>
> > >> Perhaps worth remembering that if an author wants to add the loading
> a scene with overpoweringly bright lights, they have no remedy - no way to
> disable or dim lights contained within an Inline X3D or glTF model - so
> being aware of this convention when authoring composable models indeed
> seems worthwhile.
> > >>
> > >> p.s. FWIW whenever i see an upper bounds limit of numeric "8" i
> wonder if this is the infinity symbol rotated 90 degrees - no really, have
> seen this happen a few times when copying/pasting special characters into
> plain-text files!  doesn't seem to be a problem here, looks like an
> intentional value in the Unity documentation.
> > >>
> > >>
> > >> On 12/5/2020 2:14 PM, Michalis Kamburelis wrote:
> > >>>
> > >>>
> > >>> Don,
> > >>>
> > >>> Your arguments about the light intensity limit at 1.0 come down to
> > >>> "this limit seemed to work for us" :) And I see your point, because
> it
> > >>> *seemed* like it was a working solution. Although I will now argue
> > >>> that it was never a working solution :)
> > >>>
> > >>> The thing is, it was not really working (even with the Phong lighting
> > >>> model), if you try to create lights that reflect the reality, i.e.
> > >>> have a realistic falloff. The exact equations for "realistic falloff"
> > >>> in glTF are in
> https://github.com/KhronosGroup/glTF/tree/master/extensions/2.0/Khronos/KHR_lights_punctual
> > >>> , but within the X3D they can approximated simply by using
> > >>> "attenuation = 0 0 1". Simplifying, this means that you have an
> > >>> inverse-quadratic-with-distance falloff, that is you multiply light
> > >>> contribution at each point by
> > >>>
> > >>>       1 /  lightDistance^2
> > >>>
> > >>> Now, if you try to use such realistic falloff, you will see that
> > >>> intensity = 1.0 can only result in very very dim lights, i.e. these
> > >>> lights influence quickly goes to practical zero . You will not be
> able
> > >>> to express realistic lighting conditions at all.
> > >>>
> > >>> This is why I argue for removing this limit. It's not only about the
> > >>> physical lighting model, it applies to both Phong (Material) and
> > >>> physical (PhysicalMaterial) models. It's not about glTF consistency
> or
> > >>> Blender -- any description of physically-correct lights will allow
> for
> > >>> larger intensity values. Any authoring tool nowadays will also allow
> > >>> you to have lights with intensity > 1, if it supports realistic
> > >>> lighting.
> > >>>
> > >>> So it's not a theoretical discussion, the limit at 1.0 is actually,
> > >>> practically, a problem :)
> > >>>
> > >>> Hope this makes it clearer. The way to test it is just to create a
> > >>> dummy scene in Blender, add light sources, export to glTF and try to
> > >>> open e.g. in view3dscene -- you will immediately see that limiting
> > >>> yourself to "intensity = 1.0" is just limiting too much, you cannot
> > >>> create correctly bright scenes. Of course you could create a lot of
> > >>> light sources to simulate "one very bright light source", but then it
> > >>> comes at very large efficiency cost (each light source takes time to
> > >>> computer), for no good reason (as I bet that, for any practical
> > >>> renderer implementation, removing the 1.0 limit is almost no work).
> > >>>
> > >>> I just checked Unity, and they also allow larger intensity (
> > >>> https://docs.unity3d.com/ScriptReference/Light-intensity.html ),
> > >>> although they chose to limit it at 8.0. (Which is also an arbitrary
> > >>> limit, with no relation to reality -- I don't know why they chose
> > >>> "8.0", I assume it just made it easier to show in the editor as a
> > >>> range.)
> > >>>
> > >>> Regards,
> > >>> Michalis
> > >>>
> > >>> sob., 5 gru 2020 o 18:48 Don Brutzman <brutzman at nps.edu> napisał(a):
> > >>>>
> > >>>> Hi Michalis.
> > >>>>
> > >>>> For X3DLightNode /intensity/ field, the wording about "nominal
> lighting intensity" is trying to express "regular practice for light
> intensity" i.e. our usual authoring expectations, which remain unchanged.
> > >>>>
> > >>>> The point is that composability of X3D scenes has always assumed
> consistent use of lights.  This is not a mathematical issue.
> > >>>>
> > >>>> If everyone uses light intensity [0,1] as we have for oh-so-many
> years, things seem to work satisfactorily when X3D models and scenes are
> composed together.
> > >>>>
> > >>>> Potential problems:
> > >>>>
> > >>>> a. If someone decides "hey my models are very important so my
> lights will have intensity of 1000" then that has bad impact when loaded
> with other scenes.
> > >>>>
> > >>>> b. When someone's exporter/editor drops a decimal point on light
> intensity, it goes undetected by preprocessor validation and unflagged at
> run time, with the same bad impact when loaded with other scenes.
> > >>>>
> > >>>> c. When some other tool performs a "save as X3D" operation, they
> have no indication that their custom light conventions might need
> adjustment.
> > >>>>
> > >>>> d. Presumably if someone loads a glTF model with really bright
> lights, the same composition problems occur due to mismatched lighting
> schemes.
> > >>>>
> > >>>> Quality thus suffers from inconsistent practice, and such a lack of
> lighting regularity might significantly degrade X3D model re-use overall.
> > >>>>
> > >>>> Meanwhile, it has been noted in the working group teleconferences
> that current X3D specification already allows definitions of higher
> intensity for special effects, for example by putting multiple coincident
> PointLight nodes at the same location.
> > >>>>
> > >>>> Further, if there has been a use case that makes
> extra-high-intensity lights of practical value, it hasn't been communicated
> or shared yet.  Please advise if you have one.
> > >>>>
> > >>>> Personally I think it is a bad idea to change this limit, might
> agree if the words can strongly express regular practice so that norms
> remain understood.
> > >>>>
> > >>>> BTW, my nomination as first law of engineering: "if it ain't broke,
> don't fix it."  We have 23 years of successful practice preceding this
> recent proposed change.
> > >>>>
> > >>>> Perhaps better words that the initial attempt below can express
> this expectation for composition.
> > >>>>
> > >>>> ... Or perhaps "discretion is the better part of valor" and we
> should not let our mathematical creativity jeopardize what is already
> working well, i.e. /intensity/ range [0,1] as ever.
> > >>>>
> > >>>> Absent a use case other than "gee whiz granddad, everybody else can
> do it" - this change is not yet sufficiently justified for inclusion in
> X3D4.
> > >>>>
> > >>>> Thanks for continuing to share your opinions on this important
> matter.
> > >>>>
> > >>>>
> > >>>> On 12/4/2020 12:59 PM, Michalis Kamburelis wrote:
> > >>>>>
> > >>>>>
> > >>>>> As for the "phrasing of intensity values > 1": I admit I don't
> > >>>>> understand what this text is trying to say.
> > >>>>>
> > >>>>> - "Nominal lighting intensity and ambientIntensity values are
> > >>>>> typically limited to a range [0,1] for consistent composability of
> > >>>>> scenes."
> > >>>>>
> > >>>>> - "Consider maintaining nominal upper limit 1"
> > >>>>>
> > >>>>> What is a "nominal lighting intensity"? What is a "nominal upper
> limit"?
> > >>>>
> > >>>> rationale above.
> > >>>>
> > >>>>> The text is contradictory, basically claiming that values > 1.0 is
> > >>>>> absolutely OK, but at the same time suggesting to have them <= 1.0.
> > >>>>
> > >>>> No worries, in the minutes you are looking at meeting notes for a
> possible draft revision...  Sorry if there was an omission or error.  We
> are trying to make an informed decision, so rest assured that final prose
> will match final specified bounds in X3D4 specification, validation tools,
> X3DUOM, tooltips, test cases, etc.
> > >>>>
> > >>>>> As I explained in an earlier thread, I fail to see the reason to
> treat
> > >>>>> values of intensity > 1.0 in any way special. They go through the
> same
> > >>>>> equations. Browsers practically do not have to do anything to
> support
> > >>>>> them. The values > 1.0 also do not cause any additional problems
> > >>>>> (because final colors could be > 1.0 anyway, even in X3D 3).
> According
> > >>>>> to physical interpretation (given in the Lighting component, for
> > >>>>> physical lighting model) there's also no reason to limit them to
> 1.0,
> > >>>>> so authoring tools should not limit them either (Blender doesn't
> have
> > >>>>> any limit on light power).
> > >>>>
> > >>>> rationale above.
> > >>>>
> > >>>> of note is that our use cases for any arbitrary sharable model on
> Web are broader than Blender, which provides an excellent authoring
> environment for authors deliberately putting their models together.
> > >>>>
> > >>>>> Note that there's no reason to mix this with ambientIntensity. This
> > >>>>> one can stay, as in X3D 3, limited to [0,1]. It has no correct
> > >>>>> physical interpretation anyway, it's just a multiplier for
> material's
> > >>>>> ambient.
> > >>>>
> > >>>> Very good.  Thanks for feedback that X3DLightNode
> /ambientIntensity/ field can remain with [0,1] constraints, we weren't sure
> about that on the past two conference calls.  Agreed, no change.
> > >>>>
> > >>>>> Regards,
> > >>>>> Michalis
> > >>>>
> > >>>> p.s. am happy to discuss if that helps, please feel free to call.
> we need to lock this down by next Friday.
> > >>>>
> > >>>>> pt., 4 gru 2020 o 19:42 Don Brutzman <brutzman at nps.edu>
> napisał(a):
> > >>>>>>
> > >>>>>> Attendees: Vince Marchetti, Dick Puk, Don Brutzman
> > >>>>>>
> > >>>>>> Big agenda but milestone deadline is looming and all issues are
> familiar.  Thanks for all advance meeting preparation, we hope to proceed
> rapidly.
> > >>>>>>
> > >>>>>> We now meet one hour later than before:  09-1000 Pacific time.
> > >>>>>>
> > >>>>>> [0.1] Web3D Teleconference Information
> > >>>>>>
> https://www.web3d.org/member/teleconference-information
> > >>>>>>
> > >>>>>>> Please use the following link for all Web3D Consortium Meetings.
> > >>>>>>>
> > >>>>>>> Join URL:
> https://us02web.zoom.us/j/81634670698?pwd=a1VPeU5tN01rc21Oa3hScUlHK0Rxdz09
> > >>>>>>
> > >>>>>> Prior minutes:
> > >>>>>>
> > >>>>>> [0.2] [x3d-public] X3D working group minutes: scheduling,
> conference quicklook, specification work planning, X3D4 finalization
> > >>>>>>
> https://web3d.org/pipermail/x3d-public_web3d.org/2020-November/014002.html
> > >>>>>>
> > >>>>>> ---
> > >>>>>>
> > >>>>>> 1. X3D4 topics
> > >>>>>>
> > >>>>>> [1.0] X3D4
> > >>>>>>            https://www.web3D.org/x3d4
> > >>>>>>
> > >>>>>> Changes to X3D4 specification on members-only github are also
> being refreshed daily at
> > >>>>>>
> > >>>>>> [1.1] X3D4 Working Draft 3
> > >>>>>>
> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD3/
> > >>>>>>
> > >>>>>> Corresponding pristine text in preparation for Web3D Consortium
> member ballot is currently being autogenerated along with a log of both
> corrections and remaining issues.
> > >>>>>>
> > >>>>>> ---
> > >>>>>>
> > >>>>>> a. MIDI 2.0 and Web Midi accepted. Audio and sound changes
> complete, checked in.
> > >>>>>>
> > >>>>>> [2] [x3d-public] X3D4 Sound Component and MIDI 2.0 review:
> accepted for ballot
> > >>>>>>
> https://web3d.org/pipermail/x3d-public_web3d.org/2020-December/014188.html
> > >>>>>>
> > >>>>>> Many thanks for many reviews and multiple endorsements.
> > >>>>>>
> > >>>>>> ---
> > >>>>>>
> > >>>>>> b. Continued review and editing of prose for clarity in Lighting
> and Shape components, with focus on glTF support.
> > >>>>>>
> > >>>>>> [3] Various comments reading X3Dv4 current working draft (WD3 in
> GitHub repository)
> > >>>>>>
> https://web3d.org/pipermail/x3d-public_web3d.org/2020-December/014189.html
> > >>>>>>
> > >>>>>> No problems noted but more editing work needed.  Michalis has the
> baton for some technical clarifications, then Dick and Don will continue
> working on prose phrasing to meet ISO editorial conventions.
> > >>>>>>
> > >>>>>> *** TODO
> > >>>>>>
> > >>>>>> Note phrasing of intensity values > 1:
> > >>>>>> =====================
> > >>>>>>
> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD3/Part01/components/lighting.html
> > >>>>>>
> > >>>>>> 17.3.1 X3DLightNode
> > >>>>>> X3DLightNode : X3DChildNode {
> > >>>>>>
> > >>>>>>       SFFloat [in,out] ambientIntensity 1     [0,1]
> > >>>>>> or
> > >>>>>>       SFFloat [in,out] ambientIntensity 1     [0,∞] # Consider
> maintaining nominal upper limit 1
> > >>>>>>
> > >>>>>>       SFFloat [in,out] intensity        1     [0,1]
> > >>>>>> or
> > >>>>>>       SFFloat [in,out] intensity        1     [0,∞] # Consider
> maintaining nominal upper limit 1
> > >>>>>>
> > >>>>>>       SFColor [in,out] color            1 1 1 [0,1]
> > >>>>>>       SFBool  [in,out] global           FALSE
> > >>>>>>
> > >>>>>> Nominal lighting intensity and ambientIntensity values are
> typically limited to a range [0,1] for consistent composability of scenes.
> If multiple light sources illuminate a single geometric shape, the totals
> for color values computed at a given point may be greater than one. Using
> intensity values greater than one can provide useful effects and is allowed
> without error.
> > >>>>>> =====================
> > >>>>>>
> > >>>>>> ---
> > >>>>>>
> > >>>>>> c.  Gamma correction
> > >>>>>>
> > >>>>>> Of note in this long-running issue:
> > >>>>>> - no single entity (hardware, software, browser, author) can yet
> drive to a cross-platform solution.
> > >>>>>> - stating accepted expectation (gamma correction is expected)
> might lead to false sense of optimism.
> > >>>>>> - still complex but some further progress might be expected with
> XR activity next year.
> > >>>>>>
> > >>>>>> and realization that there is something we can mostly control:
> rendering screen to image, allowing visual checking/comparison and also
> unit testing.  No requirement that all browsers look exactly the same -
> rendering pipelines have some leeway - but at least we can test compare and
> keep improving.  Especially useful with addition of physically based and
> non-photorealistic (unlit) rendering.
> > >>>>>>
> > >>>>>> [4] [x3d-public] [...] Gamma Correction for X3D4 final draft
> > >>>>>>
> https://web3d.org/pipermail/x3d-public_web3d.org/2020-November/014103.html
> > >>>>>>
> > >>>>>> summarized as
> > >>>>>>
> > >>>>>>> There are 2 spec choices below: acknowledging norms by simply
> stating that gamma correction is typically expected,
> > >>>>>>> or else continuing to say nothing.
> > >>>>>>
> > >>>>>> Check consensus: adding no additional statement still seems most
> pragmatic? So "not" say we all...
> > >>>>>>
> > >>>>>> ---
> > >>>>>>
> > >>>>>> d. Putting default duration bounds on url refresh activity
> > >>>>>>
> > >>>>>> Clearly we don't want a lot of unclosed 3D scenes and window
> frames becoming zombie network loads (or even Denial Of Service DOS
> threats).
> > >>>>>>
> > >>>>>> [5] [x3d-public] X3D4 security-related field addition:
> X3DUrlObject refreshTimeLimit
> > >>>>>>
> http://web3d.org/pipermail/x3d-public_web3d.org/2020-November/014182.html
> > >>>>>>
> > >>>>>> with John Carlson's follow-on reply exploring rationale and
> examples further.
> > >>>>>>
> > >>>>>> Recommendation: include this field (X3DUrlObject
> refreshTimeLimit) as a prudent security precaution.
> > >>>>>>
> > >>>>>> ========================
> > >>>>>> 9.3.2 X3DUrlObject
> > >>>>>>
> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD3/Part01/components/networking.html#X3DUrlObject
> > >>>>>>
> > >>>>>> X3DUrlObject {
> > >>>>>>        SFString [in,out] description ""
> > >>>>>>        SFBool   [in,out] load        TRUE
> > >>>>>>        SFTime   [in,out] refresh     0.0 [0,∞)
> > >>>>>>        MFString [in,out] url         []  [URI]
> > >>>>>> }
> > >>>>>> [...]
> > >>>>>> =====================
> > >>>>>>
> > >>>>>> Proposed field for maximum refresh duration.  Note this is not
> the same as browser working its way through url list, and finding or timing
> out on any individual url, which is owned by the software implementation
> and the associated network protocol.
> > >>>>>>
> > >>>>>>        SFTime   [in,out] refreshTimeLimit  3600.0  [0,infinity]
> > >>>>>>
> > >>>>>> "The refreshTimeLimit field defines the maximum duration in
> seconds that /refresh/ activity is allowed to occur.  This field is
> intended to reduce potential risks associated with indefinite repetition of
> automatic link retrieval. Setting the /load/ field to TRUE resets the
> refreshTimeLimit clock. If refreshTimeLimit is exceeded then load is set to
> FALSE."
> > >>>>>>
> > >>>>>> Alternate names might be autoRefreshTimeLimit, together with
> renaming /refresh/ as /autoRefresh/.
> > >>>>>>
> > >>>>>> X3DUrlObject {
> > >>>>>>        SFString [in,out] description           ""
> > >>>>>>        SFBool   [in,out] load                  TRUE
> > >>>>>>        SFTime   [in,out] autoRefresh           0.0     [0,∞)
> > >>>>>>        SFTime   [in,out] autoRefreshTimeLimit  3600.0
> [0,infinity]
> > >>>>>>        MFString [in,out] url                   []      [URI]
> > >>>>>> }
> > >>>>>> [...]
> > >>>>>>
> > >>>>>> Absent further comment, we expect to proceed with this clarifying
> naming refinement.
> > >>>>>>
> > >>>>>> ---
> > >>>>>>
> > >>>>>> e. References review requested
> > >>>>>>
> > >>>>>> [6.0] [x3d-public] X3D4 endgame review: normative references and
> informative bibliography
> > >>>>>>            http:s//
> web3d.org/pipermail/x3d-public_web3d.org/2020-November/014122.html
> > >>>>>>
> > >>>>>> Note several replies that are not part of the thread per se.
> > >>>>>>
> > >>>>>> [6.1] X3D4 Architecture, Normative references
> > >>>>>>
> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD3/Part01/references.html
> > >>>>>>
> > >>>>>> [6.2] X3D4 Architecture, (Informative) bibliography
> > >>>>>>
> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD3/Part01/bibliography.html
> > >>>>>>
> > >>>>>> Continuing review welcome, thanks for several improvements
> received.
> > >>>>>>
> > >>>>>> ---
> > >>>>>>
> > >>>>>> f. ExternalShape, ExternalGeometry?
> > >>>>>>
> > >>>>>> ExternalShape handled by Inline.
> > >>>>>>
> > >>>>>> [7.0] X3D4 9.4.2 Inline
> > >>>>>>
> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD3/Part01/components/networking.html#Inline
> > >>>>>>
> > >>>>>> What about ExternalGeometry for glTF models, is it needed?  Not
> finding it in Mantis, wondering if there is no strong use case or maybe
> we've dropped a ball.  Wondering if this was an intentional omission or
> overlooked?
> > >>>>>>
> > >>>>>> Presumed use case: glTF file contains a mesh (perhaps a
> compressed mesh) and then X3D Appearance gets applied.
> > >>>>>>
> > >>>>>> Can we add this node?  If overlooked then it would have to be
> non-controversial and already have multiple implementations, at this late
> date...
> > >>>>>>
> > >>>>>> As of today it seems too late for X3D4, feedback welcome.
> > >>>>>>
> > >>>>>> ---
> > >>>>>>
> > >>>>>> g. Event Utility node clarifications
> > >>>>>>
> > >>>>>> Thanks Andreas for remembering this long-overlooked issue.
> > >>>>>>
> > >>>>>> [8.0] [x3d-public] X3D4 draft nearing readiness for ballot;
> Mantis 519 Event utilities, ignoring set_boolean false events
> > >>>>>>
> https://web3d.org/pipermail/x3d-public_web3d.org/2020-November/014185.html
> > >>>>>>
> > >>>>>> This applies to IntegerTrigger and TimeTrigger nodes, ignoring
> set_boolean FALSE improves logical understanding and simplifies event
> animation chains.
> > >>>>>>
> > >>>>>> Absent objections (none heard) will apply this straightforward
> change.  No problems with prior compatibility identified as a result of
> this logical refinement.
> > >>>>>>
> > >>>>>> Review led Dick and I to also look at related issue
> > >>>>>>
> > >>>>>> [8.1] Mantis 1183, 30.4.6 IntegerTrigger - Ambiguous response
> when integerKey field is reset
> > >>>>>>
> https://www.web3d.org/member-only/mantis/view.php?id=1183
> > >>>>>>
> > >>>>>>> Suggested clarification to ensure consistent implementations and
> expectations: append
> > >>>>>>> "Resetting the integerKey field generates a corresponding
> integerKey field output event."
> > >>>>>>
> > >>>>>> also related:
> > >>>>>>
> > >>>>>> [8.2] Mantis 1182: 30.4.3 BooleanToggle - Ambiguous response when
> toggle field is reset
> > >>>>>>
> https://www.web3d.org/member-only/mantis/view.php?id=1182
> > >>>>>>
> > >>>>>>> "Resetting the toggle field generates a corresponding toggle
> field output event."
> > >>>>>>
> > >>>>>> Absent objections, we plan to apply all of these related
> simple/sensible clarifications to X3D4 specification prose.
> > >>>>>>
> > >>>>>> ---
> > >>>>>>
> > >>>>>> h. HTML guidelines
> > >>>>>>
> > >>>>>> Draft still pending, initial entries have started.
> > >>>>>>
> > >>>>>> *
> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD3/Part01/htmlGuidelines.html
> > >>>>>>
> > >>>>>> More to follow on mailing list.
> > >>>>>>
> > >>>>>> ---
> > >>>>>>
> > >>>>>> i. Field name consistency
> > >>>>>>
> > >>>>>> The possibility of synonym names for inconsistently named X3D3
> fields looks to provide an excellent opportunity to regularize X3D4 scene
> graph for new authors, HTML5 X3D models, etc. without unintended loss of
> backwards compatibility.
> > >>>>>>
> > >>>>>> [8.0] [x3d-public] X3D4 finalization endgame: Field naming
> reconciliation as synonyms
> > >>>>>>
> https://web3d.org/pipermail/x3d-public_web3d.org/2020-November/014125.html
> > >>>>>>
> > >>>>>> Agree with Andreas note that GeoLOD should not have a synonym
> field for children since accessType is different.  Others appear feasible
> and deserve close checking based on rationale.
> > >>>>>>
> > >>>>>> This does not appear to be everyone's first preference, but does
> appear to be feasible (i.e. "can live with it").
> > >>>>>>
> > >>>>>> Dick is preparing general prose regarding synonyms for section 4
> Concepts.
> > >>>>>>
> > >>>>>> Previously attached to agenda was screenshot of how specification
> format for affected node interfaces might change.  We reviewed this draft
> during meeting, details below.
> > >>>>>>
> > >>>>>> [8.2] X3D4 32.4.2 CADFace
> > >>>>>>
> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD3/Part01/components/CADGeometry.html#CADFace
> > >>>>>>
> > >>>>>> Discussed that the synonym concept adds a greater burden on
> implementers, they have to be checked in multiple contexts, mixing/matching
> within a single model file is further difficult, other reasonable
> concerns.  Agreed that it is a different requirement that does not exist in
> X3D3.
> > >>>>>>
> > >>>>>> Vince can "live with" field name changing, but does not expect
> that implementers will ever really apply synonyms because of added
> complexity.
> > >>>>>>
> > >>>>>> Strictly speaking, the "call for consensus" was for field name
> changing.  That is what people said they could live with.
> > >>>>>>
> > >>>>>> There are too many implications associated with synonyms to be
> sorted out in short order as we try to finish. So we won't do synonyms
> (though nothing prevents an implementation from utilizing that design path
> if they like).
> > >>>>>>
> > >>>>>> Last last call, revisit next week.  For those who haven't
> answered "can I live with it" a response is welcome.
> > >>>>>>
> > >>>>>> ---
> > >>>>>>
> > >>>>>> 2. Specification release timing.
> > >>>>>>
> > >>>>>> Group discussion.  Looks like we need one more week.
> > >>>>>>
> > >>>>>> Additional items welcome.  Are any other finals steps needed to
> be ready to ship X3D4 for Web3D Consortium member ballot and Board of
> Directors approval?  We discussed details. Appears like we simply need to
> finish, all preparations for Web3D Consortium are in place.
> > >>>>>>
> > >>>>>> [9] Web3D Standards Adoption Process
> > >>>>>>         https://www.web3d.org/standards/adoption-process
> > >>>>>>
> > >>>>>> ---
> > >>>>>>
> > >>>>>> Having too much fun with X3D4 maybe... finish line almost here.
> > >>>>>>
> > >>>>>> 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
> http://faculty.nps.edu/brutzman
> > >>>>>>
> > >>>>>>
> > >>>>>> _______________________________________________
> > >>>>>> x3d-public mailing list
> > >>>>>> x3d-public at web3d.org
> > >>>>>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
> > >>>>
> > >>>> 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
> http://faculty.nps.edu/brutzman
> > >>
> > >> 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
> http://faculty.nps.edu/brutzman
> >
> > 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
> http://faculty.nps.edu/brutzman
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20201206/ccaa432c/attachment-0001.html>


More information about the x3d-public mailing list