[x3d-public] Nurbs control points, preweighted or not ?

GPU Group gpugroup at gmail.com
Thu May 21 06:18:40 PDT 2020


Here's a snippet from an earlier email on freewrl-develop from Joerg aka
MUFTI:
"""
> http://web3d.org/pipermail/x3d-public_web3d.org/2020-May/012644.html
> - something about pre-weighted or not

There are no examples which use important weights, for testing. The github
issue below has the torus example.

The decision how to use NURBS has been made years ago by the
blaxun/bitmanagment broser.
With a modeller tool like whiite_dune you show the contolpointa, but not
with a browser...

A simple example of a shape using different NURBS wieghts is a sphere
converted to a NumrbsPatchSurface
with white_dune:

#X3D V3.0 utf8
PROFILE Interchange
COMPONENT NURBS:1

Transform {
   children
     Shape {
       appearance Appearance {
         material Material {
         }
       }
       geometry NurbsPatchSurface {
         uDimension 9
         vDimension 5
         uKnot         [
           0
           0
           0
           0.250000
           0.250000
           0.500000
           0.500000
           0.750000
           0.750000
           1
           1
           1
         ]
         vKnot         [
           0
           0
           0
           0.500000
           0.500000
           1
           1
           1
         ]
         controlPoint DEF Coordinate1 Coordinate {
           point           [
             0 -1 0
             0 -0.707107 0
             0 -1 0
             0 -0.707107 0
             0 -1 0
             0 -0.707107 0
             0 -1 0
             0 -0.707107 0
             0 -1 0
             0 -0.707107 -0.707107
             -0.500000 -0.500000 -0.500000
             -0.707107 -0.707107 0
             -0.500000 -0.500000 0.500000
             0 -0.707107 0.707107
             0.500000 -0.500000 0.500000
             0.707107 -0.707107 0
             0.500000 -0.500000 -0.500000
             0 -0.707107 -0.707107
             0 0 -1
             -0.707107 0 -0.707107
             -1 0 0
             -0.707107 0 0.707107
             0 0 1
             0.707107 0 0.707107
             1 0 0
             0.707107 0 -0.707107
             0 0 -1
             0 0.707107 -0.707107
             -0.500000 0.500000 -0.500000
             -0.707107 0.707107 0
             -0.500000 0.500000 0.500000
             0 0.707107 0.707107
             0.500000 0.500000 0.500000
             0.707107 0.707107 0
             0.500000 0.500000 -0.500000
             0 0.707107 -0.707107
             0 1 0
             0 0.707107 0
             0 1 0
             0 0.707107 0
             0 1 0
             0 0.707107 0
             0 1 0
             0 0.707107 0
             0 1 0
           ]
         }
         weight         [
           1
           0.707107
           1
           0.707107
           1
           0.707107
           1
           0.707107
           1
           0.707107
           0.500000
           0.707107
           0.500000
           0.707107
           0.500000
           0.707107
           0.500000
           0.707107
           1
           0.707107
           1
           0.707107
           1
           0.707107
           1
           0.707107
           1
           0.707107
           0.500000
           0.707107
           0.500000
           0.707107
           0.500000
           0.707107
           0.500000
           0.707107
           1
           0.707107
           1
           0.707107
           1
           0.707107
           1
           0.707107
           1
         ]
         uClosed TRUE
         vClosed TRUE
       }
     }
}
"""

On Thu, May 21, 2020 at 7:02 AM Michalis Kamburelis <
michalis.kambi at gmail.com> wrote:

> Ups, resending with correct (new) Joerg's email address.
>
> @Joerg: The archive of this thread is on
> http://web3d.org/pipermail/x3d-public_web3d.org/2020-May/012644.html .
>
> As you maintain White Dune, which heavily exercises NURBS in VRML/X3D,
> I'm curious about your opinion on this. Should we keep compatibility
> in X3D 4.0 (have control points premultiplied by weights) or break
> compatibility (have control points not premultiplied by weights, which
> seems more consistent with the way NURBS values are commonly written
> down)?
>
> Regards,
> Michalis
>
> czw., 21 maj 2020 o 14:47 Michalis Kamburelis
> <michalis.kambi at gmail.com> napisał(a):
> >
> > As for changing this (breaking compatibility): I agree that changes
> > here are easy on the browser side (remembering they would need to be
> > under "if", like "if X3D version >= 4 then Point := ControlPoint *
> > Weight else Point := ControlPoint".). On the authoring tools side,
> > probably easy too.
> >
> > My main concern is that it would very easy to forget doing this on the
> > author side. And we could no longer give instruction "just change X3D
> > header from 3 to 4" top upgrade. Our instructions would have to
> > document this ("unless you use NURBS with weights, then remember to
> > also demultiply the control points when upgrading to X3D 4").
> >
> > I'm not strongly against it, just a little :) I welcome others opinion
> > here. E.g. what does White Dune author (adding Joerg  to Cc) think
> > about this? I'm not sure if you listen on x3d-public :)
> >
> > Regards,
> > Michalis
> >
> > czw., 21 maj 2020 o 12:38 Andreas Plesch <andreasplesch at gmail.com>
> napisał(a):
> > >
> > > I can understand the reasoning of keeping backward compatibility as
> > > much as possible. In this case, it would be important to add a
> > > sentence to
> > >
> > > 27.3.2 X3DNurbsSurfaceGeometryNode
> > >
> > >
> https://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/nurbs.html#X3DNurbsSurfaceGeometryNode
> > >
> > > 'Note that the controlPoint field values are given premultiplied by
> > > their corresponding weights.'
> > >
> > > after
> > >
> > > 'The control vertex corresponding to the control point P[i,j] on the
> > > control grid is:
> > >
> > >     P[i,j].x = controlPoint[i + ( j × uDimension)].x
> > >     P[i,j].y = controlPoint[i + ( j × uDimension)].y
> > >     P[i,j].z = controlPoint[i + ( j × uDimension)].z
> > >     P[i,j].w = weight[ i + (j × uDimension)]
> > >
> > >     where 0 ≤ i < uDimension and
> > >           0 ≤ j < vDimension.'
> > >
> > > But I want to stress that the decision was made that V4.0 does not
> > > need to maintain backward compabitibility and I think part of the
> > > motivation was to fix exactly these kind of legacy issues. It is a
> > > huge opportunity which will not come along for some time.
> > >
> > > It is also worth pointing out that the changes to existing Nurbs nodes
> > > in scenes are very straightforward and could even be automated. The
> > > required changes in browser code are also very straightforward,
> > > probably a few lines.
> > >
> > > The prose would also only need minor changes:
> > >
> > >     P[i,j].w = weight[ i + (j × uDimension)]
> > >     P[i,j].x = P[i,j].w * controlPoint[i + ( j × uDimension)].x
> > >     P[i,j].y = P[i,j].w * controlPoint[i + ( j × uDimension)].y
> > >     P[i,j].z = P[i,j].w * controlPoint[i + ( j × uDimension)].z
> > >
> > > Andreas
> > >
> > > On Wed, May 20, 2020 at 7:06 PM Michalis Kamburelis
> > > <michalis.kambi at gmail.com> wrote:
> > > >
> > > > I think that clarifying this in the X3D spec is a good idea. I
> > > > remember I was initially surprised by this X3D behavior, which caused
> > > > me to document it on
> > > >
> https://castle-engine.io/x3d_implementation_nurbs.php#section_homogeneous_coordinates
> .
> > > >
> > > > I don't think that we should break compatibility and change this in
> > > > X3D v4. Although it's a weird behavior of NURBS in VRML 97 and X3D,
> > > > but breaking compatibility is also something I'd like to avoid. I
> > > > don't think it's justified in this case.
> > > >
> > > > - Personally I try to keep X3D v4 "as backward-compatible as
> > > > reasonably possible". We want to be able to tell authors "go ahead
> and
> > > > change your X3D header from 3.x to 4.0, everything will still work
> the
> > > > same". If we would change NURBS calculation, then the existing NURBS
> > > > curves/surfaces (with non-1.0 weights) would render differently after
> > > > upgrading X3D version number in your model.
> > > >
> > > > - And I want to keep X3D v4 "as backward-compatible as reasonably
> > > > possible" to make new features more easily accessible. My imaginary
> > > > scenario looks like this:
> > > >
> > > >     - An author has now a lot of existing content in X3D 3.x .
> > > >     - X3D 4.0 is officially released, with cool new features X, Y, Z.
> > > >     - An author thinks "hey, my browser supports X3D 4.0 now, and X3D
> > > > 4.0 added this cool new feature X, I want to use it in my existing
> > > > models" (e.g. I want to change my materials to use Physical-Based
> > > > Rendering),
> > > >     - The first task an author has is now "before I can use X, first
> I
> > > > have to upgrade my model from X3D 3.x to X3D 4".
> > > >
> > > > So we want the upgrade path from X3D 3 to 4 to be as trivial as
> > > > possible ("just change the file header"), otherwise all the new X3D 4
> > > > features are more difficult to practically use for existing X3D 3
> > > > users.
> > > >
> > > > Regards,
> > > > Michalis
> > > >
> > > > wt., 19 maj 2020 o 16:20 Andreas Plesch <andreasplesch at gmail.com>
> napisał(a):
> > > > >
> > > > > Thanks, Michalis, for the quick confirmation. Should we use X3D
> v4.0 to change the undesired behavior ? v4.0 allows for backward
> incompatiblity.
> > > > >
> > > > > If the issue is not significant enough to break backward
> compatibility, there should be a sentence explaining the issue: "Control
> points are provided as homogeneous coordinates, eg. multiplied by their
> corresponding weights." or something like that.
> > > > >
> > > > > I can provide a spec comment if that is helpful, eg. if Michalis
> did not already provide one.
> > > > >
> > > > > Cheers, -Andreas
> > > > >
> > > > > On Tue, May 19, 2020 at 9:50 AM Michalis Kamburelis <
> michalis.kambi at gmail.com> wrote:
> > > > >>
> > > > >> See the documentation about this issue on Castle Game Engine:
> > > > >>
> https://castle-engine.io/x3d_implementation_nurbs.php#section_homogeneous_coordinates
> > > > >>
> > > > >> As far as I tested, all X3D browsers require points to be
> > > > >> "premultiplied by the given weight". Which is confusing and
> contrary
> > > > >> to how NURBS are usually expressed (it makes the operation
> > > > >> "intuitively pull the curve toward the control point" harder than
> it
> > > > >> should be, see my docs above), but that's how it is. View3dscene /
> > > > >> Castle Game Engine follow it.
> > > > >>
> > > > >> I have some simple tests of NURBS in
> > > > >> https://github.com/castle-engine/demo-models/tree/master/nurbs .
> > > > >>
> > > > >> Regards,
> > > > >> Michalis
> > > > >>
> > > > >> wt., 19 maj 2020 o 15:28 Andreas Plesch <andreasplesch at gmail.com>
> napisał(a):
> > > > >> >
> > > > >> > We came across a specification issue for Nurbs. It is unclear
> if provided control points should be provided
> > > > >> >
> > > > >> > A) already weighted, eg. premultiplied by the given weight, or
> > > > >> > B) if the browser, eg. the evaluation of the Nurbs should do
> the weighting, eg. the multiplication of each control point with the
> corresponding weight.
> > > > >> >
> > > > >> > At first glance, since the weights are provided separately, one
> would think the control points should be provided unweighted, eg. B). This
> is also how OpenCascade or Blender specify control points (
> https://docs.blender.org/manual/en/latest/modeling/surfaces/structure.html
> ).
> > > > >> >
> > > > >> > But tests using a torus Nurbs reveal all freeWrl, view3dscene
> and InstandPlayer expect premultiplied control points (case A). This is
> surprising but there may be a reason for that consistency. Perhaps a
> commonly used formula ?
> > > > >> >
> > > > >> > The spec. itself is silent on this.
> > > > >> >
> > > > >> > A) requires confusing redundancy, since the weight field is
> still needed for normalizing the weighted sum.
> > > > >> >
> > > > >> > I would prefer B).
> > > > >> >
> > > > >> > There are no examples which use important weights, for testing.
> The github issue below has the torus example.
> > > > >> >
> > > > >> > If A) is the consensus, the spec. needs to point out that
> control points are expected to be already weighted.
> > > > >> >
> > > > >> > Here is the related discussion:
> > > > >> > https://github.com/x3dom/x3dom/issues/1059
> > > > >> > https://github.com/andreasplesch/OCCToX3D/issues/8
> > > > >> >
> > > > >> >
> > > > >> >  -Andreas
> > > > >> >
> > > > >> > --
> > > > >> > Andreas Plesch
> > > > >> > Waltham, MA 02453
> > > > >> > _______________________________________________
> > > > >> > x3d-public mailing list
> > > > >> > x3d-public at web3d.org
> > > > >> > http://web3d.org/mailman/listinfo/x3d-public_web3d.org
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Andreas Plesch
> > > > > Waltham, MA 02453
> > >
> > >
> > >
> > > --
> > > Andreas Plesch
> > > Waltham, MA 02453
>
> _______________________________________________
> 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/20200521/7999afdf/attachment-0001.html>


More information about the x3d-public mailing list