[x3d-public] Mantis 27.4.9 NurbSet - Change child geometry model to X3DParametricGeometryNode
John Carlson
yottzumm at gmail.com
Sat May 14 17:21:30 PDT 2022
More teddy bear stuff on Mantis 700.
Since NurbsSet is intended for surfaces, why not keep it that way, and
propose a new Set for parametric geometry that isn’t Nurbs Surfaces when
the need arises. The main reason driving the change, as i see it, is to
share tessellationScale. That should be in the new Set as well.
I dont know how you’re going to get control points out of the extrusions
(control curves fields), especially when there are two sets of control
points to choose from, but i guess we can leave it up to the author and
damn the developers? I’m pretty sure the previous standard authors saw the
problem with the extrusions and neatly sidestepped it with the original
design; I fear we’re going to step on a banana peel of the new design.
I do see the desirability of including NurbsCurve in a NurbsSet, but it is
excluded by the draft standard! One may only have Nurbs surfaces in
NurbsSet, not Nurbs curves.
I realize that one can create a controlPoint by creating a field alias in
X3DUOM, “delegating to another field.” I’m not quite sure how this works.
I don’t know how to create aliases into another type, just the same type.
But yeah, let the developers figure this out.
Another problem I have with how things are is that one can potentially
include control points from anywhere, not just the edge/vertex control
point shared by the Nurbs surfaces when smoothing? (The draft standard
says control points on edges). Hopefully the developers will be able to
sort through this and provide good error messages. I don’t want to step
into this quagmire, and perhaps that’s why we haven’t seen more
implementations. I hope Schematron/X3DJSAIL/x3d.py/C* is up to the task!
Note that all shared control points between two surfaces must be on the
same side.
One more thing I’m thinking of is what if a tool creates NurbsSets like
laying out bricks. I didn’t any mention of this in the standard. Think
NurbsStrips, long strips of Nurbs surfaces, with each NurbsStrip offset
from the next. I would hope that the standard would support a
checkerboard style, but I’m not sure if this is required.
Im off to check on NURBS examples.
John
On Sat, May 14, 2022 at 1:36 AM John Carlson <yottzumm at gmail.com> wrote:
> Finally, my recommendation:
>
> Change nothing unless we want curves and possibly extrusions
> (pseudo-surfaces) to be in NurbsSet. Otherwise, proceed.
>
> On Sat, May 14, 2022 at 1:29 AM John Carlson <yottzumm at gmail.com> wrote:
>
>> I apologize that this was not in a comment to the website. It's easier to
>> follow a thread in email. Read the last paragraph if you want a conclusion.
>>
>> The X3D4 CD Extensible 3D (X3D), ISO/IEC 19775-1:2022, 27 NURBS
>> Component (web3d.org)
>> <https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-CD1/Part01/components/nurbs.html#NurbsSet> says
>> the tesselationScale affects Nurbs surface nodes: "The
>> *tessellationScale* parameter is scaling the tessellation values in lower
>> level contained Nurbs surface nodes."
>>
>> *Note: If the contained Nurbs *curve *nodes now possible, but illegal
>> in a NurbsSet are not scaled by the tessellationScale, things might get
>> confusing! But I kind of understand why they aren't! If NurbsSet only
>> contains surfaces, why not call it "NurbsSurfaceSet"?*
>>
>> I hope we have a good list of Nurbs surface nodes that people can add to
>> NurbsSet geometry for instead of relying on interfaces.
>>
>> Full text of NurbsSet:
>>
>> The NurbsSet node groups a *set of Nurbs surface nodes* to a common
>> group for rendering purposes only. This informs the X3D browser that the
>> set of Nurbs surfaces shall be treated as a unit during tessellation to
>> enforce tessellation continuity along borders. The *tessellationScale* parameter
>> is scaling the tessellation values in lower level contained Nurbs
>> surface nodes. A set of Nurbs surfaces that use a matching set of
>> *controlPoint* along the borders shall result in a common tessellation
>> stepping.
>>
>> The geometry represented in the children of this node shall not be
>> directly rendered. It is an informational node only. Surfaces not
>> represented elsewhere in the transformation hierarchy shall not be rendered.
>>
>> The bounds information is provided for optimization purposes only. A X3D browser
>> *may choose *[ Editor's note: Why Don is seeing non-smooth NURBS,
>> likely--but I'm not too familiar with the standard] to use this information
>> about when to apply trimming or smooth tessellation between patches based
>> on the bounds information (EXAMPLE only smooth when the viewer is
>> within the bounds).
>>
>>
>> So:
>>
>>
>> 27.4.3 NurbsCurve
>>
>> NurbsCurve : X3DParametricGeometryNode {
>> SFNode [in,out] controlPoint NULL [X3DCoordinateNode]
>> SFNode [in,out] metadata NULL [X3DMetadataObject]
>> SFInt32 [in,out] tessellation 0 (-∞,∞)
>> MFDouble [in,out] weight [] (0,∞)
>> SFBool [] closed FALSE
>> MFDouble [] knot [] (-∞,∞)
>> SFInt32 [] order 3 [2,∞)
>>
>>
>>
>> The above has controlPoint, has tessellation, but does not participate in tesselationScale?
>>
>>
>> I'm trying to understand the impact of: X3DNurbsControlCurveNode to surfaces that use it. The surfaces appear visually to be extrusions, and I now know that NURBS includes extrusions (surprise to me!) from reading the CD standard.
>>
>> I guess there's a use case for adding NurbsSwungSurfaces and NurbsSweptSurface to NurbsSets? Like outlining a X3DNurbsSurfaceGeometryNode? Sounds okay by me! It seems confusing that there are no controlPoints to smooth with! Or is it more like, what set of controlPoints? And no tessellation control!
>>
>> NurbsCurve2D
>>
>> can't be added to a NurbsSet, thank goodness!
>>
>> Are we okay now? As far as I can tell, the specification will work, but
>> implementers will have to deal with sticky problems smoothing controlPoint
>> between surfaces and extrusion surfaces. They'll have to somehow delegate
>> the controlPoint in the extrusions to a control curve (is this
>> specified?). And also excluding NurbsCurve from NurbsSet seems rather
>> arbitrary, which is a good reason to change the type of the geometry field
>> in NurbsSet. When we change the geometry field type, we lose the ability
>> to separate types of NURBS (curves, extrusions, surfaces) in the NurbsSet
>> geometry interfaces.
>>
>> Thanks,
>>
>> John
>> On Fri, May 13, 2022 at 10:13 AM Brutzman, Donald (Don) (CIV) <
>> brutzman at nps.edu> wrote:
>>
>>> Looking at the Interface Hierarchy shows what implements those types,
>>> confirming that only Nurbs nodes are involved. This also clearly
>>> identifies why we shifted the interface involved.
>>>
>>>
>>>
>>> +- X3DParametricGeometryNode -+- NurbsCurve
>>>
>>> +- NurbsSweptSurface
>>>
>>> +- NurbsSwungSurface
>>>
>>> |
>>>
>>> +- X3DNurbsSurfaceGeometryNode -+-
>>> NurbsPatchSurface
>>>
>>> +-
>>> NurbsTrimmedSurface
>>>
>>>
>>>
>>> Dick points out that someday in (some wonderful) future we might allow
>>> other geometry nodes to get smoothly aligned next to Nurbs nodes. That
>>> will be nice – but we are OK for now.
>>>
>>>
>>>
>>> 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 https://
>>> faculty.nps.edu/brutzman
>>>
>>>
>>>
>>> *From:* John Carlson <yottzumm at gmail.com>
>>> *Sent:* Thursday, May 12, 2022 7:39 AM
>>> *To:* Brutzman, Donald (Don) (CIV) <brutzman at nps.edu>
>>> *Cc:* X3D Public Mailing List (x3d-public at web3d.org) <
>>> x3d-public at web3d.org>
>>> *Subject:* Re: [x3d-public] Mantis 27.4.9 NurbSet - Change child
>>> geometry model to X3DParametricGeometryNode
>>>
>>>
>>>
>>> Understood, i am just trying to work through if there’s any parametric
>>> geometry which isn’t NURBS, and is thus now inclusive in this modified
>>> NurbsSet.
>>>
>>>
>>>
>>> Thanks!
>>>
>>>
>>>
>>> John
>>>
>>>
>>>
>>> On Thu, May 12, 2022 at 8:58 AM Brutzman, Donald (Don) (CIV) <
>>> brutzman at nps.edu> wrote:
>>>
>>> Please be assured, no new semantics and no new functionality is being
>>> proposed. We are addressing a Mantis issue that noted the NurbsSet
>>> definition was unnecessarily restrictive. We adjusted the specification
>>> interface to match that inclusive rationale.
>>>
>>>
>>>
>>> Changes to implementations are up to them. Since NurbsSet is a way for
>>> authors to communicate when various Nurbs nodes are coincident and
>>> potentially smoothable, it has no impact on functionality and might improve
>>> rendering appearance by enabling smoothed seams.
>>>
>>>
>>> Thanks for your review.
>>>
>>>
>>>
>>> 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 https://
>>> faculty.nps.edu/brutzman
>>>
>>>
>>>
>>> *From:* John Carlson <yottzumm at gmail.com>
>>> *Sent:* Wednesday, May 11, 2022 10:40 PM
>>> *To:* Brutzman, Donald (Don) (CIV) <brutzman at nps.edu>
>>> *Cc:* X3D Public Mailing List (x3d-public at web3d.org) <
>>> x3d-public at web3d.org>
>>> *Subject:* Re: [x3d-public] Mantis 27.4.9 NurbSet - Change child
>>> geometry model to X3DParametricGeometryNode
>>>
>>>
>>>
>>>
>>>
>>> Don, I'm a bit unsure of the new semantics for NurbsSet....it includes
>>> other parametric geometry nodes which aren't NURBS?
>>>
>>>
>>>
>>> Would ParametricGeometrySet be a better name than NurbsSet, or a good
>>> addition to X3D4?
>>>
>>>
>>>
>>> Is it counterintuitive to look for a "ParametricGeometrySet" inside
>>> NURBS sections?
>>>
>>>
>>>
>>> How does this impact browser implementations?
>>>
>>>
>>>
>>> I don't know if the standard includes parametric, implicit, etc.
>>> descriptions?
>>>
>>>
>>>
>>> Are we planning on dropping X3DNurbsSurfaceGeometryNode in the future?
>>>
>>>
>>>
>>> NURBS seems a bit specialized, but at least I know I'm looking for
>>> NURBS. Parametric seems *way* general, and should probably remain at the
>>> abstract level.
>>>
>>>
>>>
>>> I have no other issues that come to mind presently.
>>>
>>>
>>>
>>> I'm a bit leery of Mantis, so I will now review your next email. My
>>> summary: Can one include more than one abstract type in the allowable
>>> types? That is, allow both X3DParametricGeometryNode
>>>
>>> and X3DNurbsSurfaceGeometryNode sub node types for geometry?
>>>
>>>
>>>
>>> Thanks!
>>>
>>>
>>>
>>> John
>>>
>>>
>>>
>>> On Wed, May 11, 2022 at 8:06 PM Brutzman, Donald (Don) (CIV) <
>>> brutzman at nps.edu> wrote:
>>>
>>> NurbsSet should be inclusive about which nodes an author thinks can be
>>> rendered together as one smooth surface.
>>>
>>>
>>>
>>> - Mantis 27.4.9 NurbSet - Change child geometry model to
>>> X3DParametricGeometryNode
>>> - https://www.web3d.org/member-only/mantis/view.php?id=700
>>>
>>>
>>>
>>> - X3D4 Architecture, NURBS component, 27.4.8 NurbsSet
>>> -
>>> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-CD1/Part01/components/nurbs.html#NurbsSet
>>>
>>>
>>>
>>> Since X3DParametricGeometryNode includes X3DNurbsSurfaceGeometryNode,
>>> changed all three NurbsSet geometry fields from X3DNurbsSurfaceGeometryNode
>>> to X3DParametricGeometryNode.
>>>
>>>
>>>
>>> NurbsSet : X3DChildNode, X3DBoundedObject {
>>>
>>> MFNode [in] addGeometry [X3DParametricGeometryNode
>>> ]
>>>
>>> MFNode [in] removeGeometry [X3DParametricGeometryNode
>>> ]
>>>
>>> MFNode [in,out] geometry [] [X3DParametricGeometryNode
>>> ]
>>>
>>> SFNode [in,out] metadata NULL [X3DMetadataObject]
>>>
>>> SFFloat [in,out] tessellationScale 1.0 (0,∞)
>>>
>>> SFVec3f [] bboxCenter 0 0 0 (-∞,∞)
>>>
>>> SFVec3f [] bboxSize -1 -1 -1 [0,∞) or −1 −1 −1
>>>
>>> }
>>>
>>>
>>>
>>> This changes X3DUOM and possibly some implementations. Comments welcome.
>>>
>>>
>>>
>>> We current intend to accept this change as resolved once X3DUOM is
>>> updated.
>>>
>>>
>>>
>>> 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 https://
>>> 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/20220514/8d2449c9/attachment-0001.html>
More information about the x3d-public
mailing list