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

Michalis Kamburelis michalis.kambi at gmail.com
Thu May 21 05:47:47 PDT 2020


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



More information about the x3d-public mailing list