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

Michalis Kamburelis michalis.kambi at gmail.com
Sat Dec 5 17:49:03 PST 2020


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



More information about the x3d-public mailing list