[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:32:26 PDT 2020
Correction: Surface is:
r = A + B cos(C * phi) cos (D * theta)
Thanks,
John
On Sat, Jun 6, 2020 at 7:31 PM John Carlson <yottzumm at gmail.com> wrote:
> 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/d95e9bf5/attachment-0001.html>
More information about the x3d-public
mailing list