[x3d-public] X3D minutes 5 June 2020: Web3D 2020 papers deadline, mantis issues, refining some field names

John Carlson yottzumm at gmail.com
Sat Jun 6 17:31:32 PDT 2020


While Sphere, etc.  are mathematical and X3D supports mathematical
surfaces, how do I put in a surface below into X3D:

r = A + B cos(C * phi) cos (D * phi)

Spherical coordinates, and A,B,C,D vary over time or interactively. Plus
there may be prismatic effects.

There are several ways I know how to do this:

1.  User provides a mesh. I have done this before.  It is too slow for a
100x100 IFS (20000 polygons I think).
2.  User provides sphere, and positions and normals are determined in a
shader.  I have done this.
3.  Provide mathematical equations in FVRML/FX3D (BS Contact).  Someone has
provided proof-of-concept. As far as I know, I cannot provide a MathML
expression which renders a surface in a web browser.  Contributions welcome
here.
4.  Do it in Mathematica.  I have become aware that this may be
possible--prior to recently, Mathematica choked. I have not seen
interactive manipulations of A,B,C,D values, which I have in X3DOM.  There
are buttons not sliders for interactivity.

5.  Crank out an OBJ file with math.  I have done this.
6.  Create a mesh in Blender, import OBJ to PlayCanvas, use a vertex shader
to change surface.

Ideally, I would like to do a mathematics equation representation. However,
I am unsure at this point if internal surfaces are visible with a raytrace.
I had confirmed to myself before that finding internal intersections was
not possible with Newton's Method. I have not tried other methods, instead
I have moved away from that towards polygons.

7.  Do raytracing of mathematical equations in a graphics card.  Not
attempted yet. I do not have  an adequate graphics card yet.  I would
probably have to provide my own surface-ray intersections.   Then the
question becomes, what's a good intersection finder?

8.  Use XML3D?   comments welcome.

Do you see where I'm caught between a math representation and a mesh
representation? A mesh is too slow, but has the capability of showing
internal intersections.   An equation is quite fast (took 1 hour to show a
frame in 1986.  Latest raytracing tests (quite few years ago) were 2
minutes per frame, but currently not capable of seeing internal
intersections (where a surface intersects itself).

It would be *really* cool if I could spin/modify the surface with touch and
pinch interactions.  Currently, I use sliders, similar to X3DOM.  I do have
LeapMotion and Kinect.

Don wrote:
>Meanwhile John C., you added a comment there which is out of place since
the issue only relates to Cone Cylinder Sphere.  Here it is - if you think
it belongs elsewhere then let's figure that out and apply to another issue,
if relevant.

>>"You may want to say something about the mesh being modified in the
vertex shader, which is what I am doing. Instead of restricting to a
radius, allow the shader to modify position and normal. Or just go with a
mathematical expression is OK with me, as long as I can achieve sufficient
quality."

On Sat, Jun 6, 2020 at 6:38 PM Don Brutzman <brutzman at nps.edu> wrote:

> Here some decision followup actions, making continued progress.
>
> On 6/5/2020 11:33 AM, Don Brutzman wrote:
> > [...]
> > -----
> >
> > 3. Mantis issues
> >
> > As discussed in several email threads on x3d-public, we will be
> reviewing and resolving multiple issues today.
> >
> > [2.0] Mantis Issue Tracker
> >        https://www.web3d.org/member-only/mantis/my_view_page.php
> >
> > Today's added discussion at
> > https://www.web3d.org/member-only/mantis/view.php?id=1280#c2587
> >
> > [2.1] Mantis 1280: Add quality parameter for Geometry3D primitives
> >        https://www.web3d.org/member-only/mantis/view.php?id=1280
> >
> >> If we go general, can we effectively encourage satisfactory engine
> implementation?
> >>
> >> Defining tessellation parameters (e.g. 24 24 indicates 24 divisions
> laterally and vertically) gives knowledgeable authors some control - but
> only when displaying base cases.
> >>
> >> Handling silhouettes and shading without roughness artifacts leads to
> mathematical representations, at any resolution and any proximity.
> >>
> >> There is no requirement for mesh implementation, for example parametric
> surfaces are allowed.
> >>
> >> If a Sphere is accompanied by a TouchSensor, for another example, the
> author is expecting the selection point to be a sufficiently close
> approximation to the geometry's surface, not necessarily a point on the
> initially computed tessellation (which may have been far away at low
> resolution). Once again this leads us towards appropriate refinement for
> the rendering, and mathematical representation of the primitive.
> >>
> >> If we go for mathematical representations, no further improvements will
> be needed to X3D specification (perhaps forever) when such artifacts are
> found in future scenes.
> >>
> >> We agreed to add no quality parameter, and encourage each implement to
> consider how the present best-quality geometric rendering in all cases.
> >>
> >> Suggested specification prose:
> >> "This geometry node is fundamentally a mathematical representation.
> Displayed geometry shall have sufficient rendering quality that surface and
> silhouette edges appear smooth, including when textures are applied."
> >
> > Accepted.  Dick and Don will apply changes, then change status to
> Resolved.
>
> Renamed issue to "Define rendering quality for Geometry3D primitives" for
> clarity.
>
> Applied prose and style changes to specification, committed to github.
>
> Dick and I will review during next week's editors meeting and likely
> accept it then.
>
> Meanwhile John C., you added a comment there which is out of place since
> the issue only relates to Cone Cylinder Sphere.  Here it is - if you think
> it belongs elsewhere then let's figure that out and apply to another issue,
> if relevant.
>
> "You may want to say something about the mesh being modified in the vertex
> shader, which is what I am doing. Instead of restricting to a radius, allow
> the shader to modify position and normal. Or just go with a mathematical
> expression is OK with me, as long as I can achieve sufficient quality."
>
> In general we are very sparing in use of Mantis, only reflecting
> distillation of mail list discussions.  That way spec editors have a clear
> record of issues and resolution.  Thanks, but... mail list is best place to
> work out pros/cons/alternatives.  We do everything openly in order to work
> towards consensus.
>
> > ---
> >
> > [2.2] Mantis 1304: allowing animation of Cone, Cylinder bottom/side/top
> >        https://www.web3d.org/member-only/mantis/view.php?id=1304
> >
> > Discussion:
> >> The initializeOnly accessType might be considered a vestige of early
> rendering difficulty.
> >>
> >> This parameter variability is commonly implemented in modern rendering
> engines.
> >
> > Accepted.
>
> Applied change to X3D XML schema, DOCTYPE, X3DUOM, tooltips, etc.
>
> Applied change to github specification.
>
> Updated Mantis.
>
> > [2.3] Mantis 1264: NavigationInfo type TURNTABLE HELICOPTER GAME FREEFLY
> >        https://www.web3d.org/member-only/mantis/view.php?id=1264
> >
> > We discussed how these issues are being considered in Web3DUX Working
> Group.  It looks like most or all have potential value for the
> specification and X3D authors.
> >
> > An added possibility is that certain modes might be considered optional,
> lowering barriers to compliance.
>
> Interesting, we hadn't thought of this before.  Wondering though, does
> that add value to authors from a component perspective, however?  There are
> always variations in support among implementations.  Current Navigation
> component says
>
> * Table 23.2 — Navigation component support levels
>
> https://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/navigation.html#t-supportlevels
>
> Level 1 - NavigationInfo: type support for at least "ANY", "FLY",
> "EXAMINE", and "NONE".
> Level 2 - NavigationInfo: type support for at least "ANY", "FLY",
> "EXAMINE", "WALK", "LOOKAT", and "NONE".
> Level 3 - All Level 2 Navigation nodes: All fields fully supported.
>
> So it looks like any optional characteristics are already handled pretty
> well already.  Thus don't expect to designate any navigation types as
> optional.
>
> > A survey of these types and general support for all NavigationInfo type
> support is appropriate.
> >
> > Noted related issue:
> >
> > [2.4] Mantis 1301: check geospatial navigation to see if NavigationInfo
> modes are sufficient
> >        https://www.web3d.org/member-only/mantis/view.php?id=1301
> >
> >> Geospatial navigation is special in that it has to work in proximity to
> the surface of the Earth, at high altitudes, and in outer space.
> >>
> >> Further consideration is definitely needed for how geospatial
> navigation types are consistent - or consistently extending - other
> NavigationInfo type definitions.  Related issues identified.
> >> Looking at and comparing how Cesium and Google Earth handle these cases
> is appropriate.
> >
> > Wishing best of success to Web3DUX Working Group in continuing efforts.
> >
> > -----
> >
> > [2.5] Mantis 1194: 23.4.4 NavigationInfo - VIEWALL should be a required
> navigation behaviour
> >        https://www.web3d.org/member-only/mantis/view.php?id=1194
> >
> >> 16
> >>     VIEWALL is curious in comparison to other navigation modes in that
> it is a one-time action.
> >>
> >> Perhaps this functionality is more appropriate as part of Viewpoint?
>
> _that_ was the crucial insight and understanding of the problem, which
> emerged thanks to group dialog.  hooray!
>
> >> Perhaps this functionality is best implemented as a builtin Viewpoint,
> similar to default Viewpoint (at position 0 0 10). How might an author bind
> and unbind this?
> >>
> >> Perhaps there might be a ViewAll node, which an author can bind via
> Browser object or similar mechanisms. Perhaps even multiple nodes:
> >> <ViewAll description="North side of island"/>
> >> <ViewAll description="South side of island"/>
> > Note that we would need this capability in OrthoViewpoint as well.
> >
> >  From 3.3 spec:
> >
> > 23.4.6 Viewpoint
> >
> > Viewpoint : X3DViewpointNode {
> >    SFBool     [in]     set_bind
> >    SFVec3f    [in,out] centerOfRotation  0 0 0   (-∞,∞)
> >    SFString   [in,out] description       ""
> >    SFFloat    [in,out] fieldOfView       π/4     (0,π)
> >    SFBool     [in,out] jump              TRUE
> >    SFNode     [in,out] metadata          NULL    [X3DMetadataObject]
> >    SFRotation [in,out] orientation       0 0 1 0 [-1,1],(-∞,∞)
> >    SFVec3f    [in,out] position          0 0 10  (-∞,∞)
> >    SFBool     [in,out] retainUserOffsets FALSE
> >    SFTime     [out]    bindTime
> >    SFBool     [out]    isBound
> > }
> >
> > Possible addition:
> >
> >    SFString [in,out] scope "" [as defined, or "VIEWALL"]
> >
> > Functionality is to zoom position back/in towards center of world's
> bounding box until everything is within display bounds.
> >
> > What about:
> >
> >    SFBool   [in out] viewAll     FALSE
> >
> > Same functionality to zoom position back/in.  For non-orthographic
> Viewpoint, orientation changes to point at center of scene; OrthoViewpoint
> orientation remains unchanged. Other fields remain the same.
>
> Am really liking the SFBool viewAll field as the simplest and most
> comprehensive solution we have considered to date.  It can meet all
> functional requirements.  It exactly fits into existing X3DViewpointNode
> requirements without requiring complex changes in implementations.
>
> The mantis issue already describes the algorithm.  Am ready to add prose
> to specification...
>
> Proposal added to Mantis 1194:
>
>    SFBool [in out] viewAll FALSE
>
> "When viewAll is set TRUE or a viewpoint is bound with viewAll TRUE, the
> current view is modified to change centerOfRotation to match center of
> bounding box for entire visible scene, change orientation to aim at that
> point, change type to EXAMINE, and then zooms position in or out until the
> scene is fully within the current viewing window. Changing navigation type
> resets viewAll to FALSE."
>
> Subject to confirmation/denial, am ready to add to specification and
> validation assets.
>
> > ----
> >
> > Nicholas described the great and numerous difficulties that arise from
> Viewpoint and NavigationInfo being separate.  A major long-term challenge
> is whether we might unify this functionality.
> >
> > Note that the two nodes can be tied together as follows:
> >
> >      <Viewpoint DEF="view23" description="A beautiful spinning sneaker"/>
> >      <NavigationInfo DEF="nav23" type='"EXAMINE"'/>
> >      <ROUTE fromNode="view23" toNode="nav23" fromField="isBound"
> toField="set_bind"/>
> >
> > Perhaps there is a syntactically way to say in a functionally equivalent
> way
> >
> >      <Viewpoint DEF="view23" description="A beautiful spinning sneaker">
> >         <NavigationInfo DEF="nav23" type='"EXAMINE"'
> containerField='navigation'/>
> >      </ViewPoint>
> > and also
> >      <Viewpoint DEF="view24" description="An unfashionable untied
> sneaker">
> >         <NavigationInfo USE="nav23"/>
> >      </ViewPoint>
> >
> > ... which provides unambiguous unchangeable navigation fields for this
> viewpoint.
> >
> > Note that binding + unbinding a Viewpoint equivalently binds/unbinds the
> associated NavigationInfo, reverting simultaneously to previous Viewpoint
> and also previous NavigationInfo.
>
> Still makes sense.  Implementable today via single ROUTE as shown above -
> thus easily implemented by X3D players.  This design-pattern relationship
> becomes even more reliable/unbreakable by associating NavigationInfo with a
> Viewpoint as an SFNode field.
>
> Proposed specification addition:
>
> 23.3.1 X3DViewpointNode
> 23.4.5 OrthoViewpoint
> 23.4.6 Viewpoint
>
> SFNode [in,out] navigation NULL [NavigationInfo]
>
> "The navigation field defines a dedicated NavigationInfo node for this
> X3DViewpointNode which remains independent of the NavigationInfo binding
> stack."
>
> Entered as new issue
>
> * Mantis 1305: add Viewpoint field for dedicated NavigationInfo
>    https://www.web3d.org/member-only/mantis/view.php?id=1305
>
> Subject to confirmation/denial, am ready to add to specification and
> validation assets.
>
> > Another approach, more programmatically,
> >
> >      Browser.getBoundViewpoint.whatever
> >      Browser.getBoundNavigationInfo.whatever
> >
> > TODO: search for prior Mantis issue, also Nicholas write it up please.
>
> Not finding Mantis issue.  Ready to add once written up.  These two
> approaches together hold major promise for simplifying navigation designs
> by authors.
>
> > -----
> >
> > [2.5] Mantis 904: ShaderPart, ShaderProgram: incorrect value list for
> type field
> >        https://www.web3d.org/member-only/mantis/view.php?id=904
> >
> > Deferred.
> >
> > -----
> >
> > 5. Refamiliarization discussion: will soon retackle the following
> issues, driving towards closure on potential field-name changes for X3DUOM
> in X3D4.
> >
> > Any red flags or suggestions/precautions are worth considering.  We aim
> to improve X3D4 internal consistency.
> >
> >
> =============================================================================
> > [3.0] X3D Scene Authoring Hints: Potential future changes for improved
> consistency of field names
> >
> https://www.web3d.org/x3d/content/examples/X3dSceneAuthoringHints.html#fieldNameChanges
> >
> > Ongoing work for X3D Version 4 and X3D Unified Object Model (X3DUOM)
> makes a number of candidate optimizations possible and (in most cases)
> desirable. Consistent X3D scene-graph architecture across multiple file
> encodings and programming-language bindings is important.
> >
> > The following consistency changes to SFNode/MFNode field names in X3Dv4
> might reduce the number of containerField variations by more than half.
> Further simplification benefits are foreseen for X3D4 implementations, X3D
> authors, and X3D Ontology field disambiguation.
>
> Stand by for action, will tackle all of these this month as part of X3DUOM
> normalization.
>
> Please holler if you have any objections, warnings or concerns.
>
> > a.    CADFace issue Mantis 1234 to change unnecessarily different
> containerField='shape' and rename as containerField='children' instead.
> >
> > b.    Collision: content model definitions for contained nodes are
> insufficiently strict. See issue Mantis 1149.
> >
> > c.    DISEntityTypeMapping: enter Mantis issue to change unnecessarily
> different containerField='mapping' and rename as containerField='children'
> instead.
> >
> > d.    CollidableShape: enter Mantis issue to change unnecessarily
> different field name containerField='shape' and rename as
> containerField='children' instead.
> >
> > e.    ComposedCubeMapTexture, TextureBackground: enter Mantis issue to
> make six sets of field names identical for contained textures, e.g.
> backTexture becomes back etc.
> >
> > f.    GeoLOD: see issue Mantis 920 to change unnecessarily different
> field name containerField='rootNode' and rename as
> containerField='children' instead. Also enter Mantis issue to implement
> object interface X3DUrlObject.
> >
> > g.    GeoMetadata: enter Mantis issue to implement object interface
> X3DUrlObject.
> >
> > h.    LoadSensor: enter Mantis issue to change unnecessarily different
> field name containerField='watchList' and rename as
> containerField='children' instead. Child node restrictions can achieve a
> functionally equivalent effect and improve the object-oriented design.
> >
> > i.    ParticleSystem: enter Mantis issue to change unnecessarily
> different field names colorRamp, texCoordRamp and rename as regular
> defaults color, texCoord instead. Also allow TextureCoordinateGenerator as
> an alternative to TextureCoordinate for that child node.
> >
> > j.    Nodes in the Programmable shader component all field names deserve
> a further close look. While everything works correctly, node naming is
> confusing and clarity is certainly improvable.
> >
> > These changes will be considered by Web3D Consortium members with
> subsequent review by the X3D Community. Companies, institutions, agencies
> and individuals are invited to Join Web3D Consortium to participate and
> influence this important continuing evolution of X3D.
> >
> =============================================================================
> >
> > TODO: link past X3D Working Group minutes on this topic.  Tradeoff is
> extra-descriptive naming versus consistent naming - not any changes in
> functionality.
>
> Didn't find specific minutes on this topic in 2020, believe it actually
> came up several times in context of XML containerField (i.e. field) names.
>
> * [x3d-public] X3D minutes 6 MAR 2020: X3D4 special meeting on PBR, issue
> progress,
>    Metadata containerFIeld defaults for XML encoding
>    https://web3d.org/pipermail/x3d-public_web3d.org/2020-March/011863.html
>
> * [x3d-public] X3D Working Group agenda 31 JAN 2020: X3Dv4 issues, XML
> Metadata containerField,
>    consolidating mismatched field names
>
> https://web3d.org/pipermail/x3d-public_web3d.org/2020-January/011744.html
>
> * [x3d-public] X3D minutes 24 JAN 2020: X3Dv4 Interchange-profile Text,
> visible, displayBBox,
>    XML Metadata* default containerField
>
> https://web3d.org/pipermail/x3d-public_web3d.org/2020-January/011710.html
>
> > Backwards compatibility remains an important concern to ensure that we
> don't break existing content.  Some changes (for relatively rare
> occurrences) will be listed when converting X3D3 content (or
> implementations) to X3D4.  So all naming refinements need to be well
> documented for authors, implementers, content and tools.
> >
> > Subject to ongoing discussion, I expect to begin applying changes to X3D
> Schema/DTD/X3DUOM on an issue-by-issue bases for further testing.  You've
> been warned...  8)
> >
> > Thanks in advance for all insights and help.
> >
> > -----
> >
> > The topics may have seemed obscure, but we accomplished some
> fundamentally valuable progress together.
> >
> > I have a few TODO items to confirm close correlation and good
> consistency between minutes, email record and Mantis issues.
> >
> > Next week: glTF and Physically Based Rendering update by Michalis
> Kamburelis, hopefully recording and publishing this briefing.
> >
> > Have fun with X3D!  8)
>
> 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/20200606/71f0fd9c/attachment-0001.html>


More information about the x3d-public mailing list