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

[Michalis Kamburelis]

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