[x3d-public] X3D minutes 4 DEC 2020: resolving X3D4 endgame issues
John Carlson
yottzumm at gmail.com
Sat Dec 5 11:37:49 PST 2020
Plug
https://www.pauldebevec.com/Probes/
Here’s where I get my HDR images from.
These images are popularly used with NVidia’s SDK, JOGL and my own “work”
on transparent rhodonea.
On Sat, Dec 5, 2020 at 1:28 PM John Carlson <yottzumm at gmail.com> wrote:
> Indeed, I have not tried to load scenes with multiple cubemaps may mean we
> need another solution. And indeed, I believe that GLSL may only support
> one cube map.
>
> On Sat, Dec 5, 2020 at 11:49 AM Don Brutzman <brutzman at nps.edu> wrote:
>
>> 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
>>
>> _______________________________________________
>> 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/20201205/25d9cbe0/attachment-0001.html>
More information about the x3d-public
mailing list