[x3d-public] X3D minutes 4 DEC 2020: resolving X3D4 endgame issues; light intensity
John Carlson
yottzumm at gmail.com
Sat Dec 5 15:15:02 PST 2020
We shouldn’t disallow what possible with an intensity > 1. But we should
remember intensity > 1 was originally done with multiple exposures. The
point being we originally got more realism by combining exposures.
John
On Sat, Dec 5, 2020 at 5:06 PM Don Brutzman <brutzman at nps.edu> wrote:
> 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
>
> _______________________________________________
> 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/1ceaa940/attachment-0001.html>
More information about the x3d-public
mailing list