[x3d-public] Nurbs control points, preweighted or not ?
GPU Group
gpugroup at gmail.com
Thu May 21 07:18:41 PDT 2020
in case Joerg aka MUFTI's email doesn't get through here's another copy
"""
Hi,
> 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)?
For the rendering the answer is simple:
If (X3d4V.is_Incompatible_with_X3DV3_and_VRML97_AMD1()) // really a danger ?
if (isX3dv4())
render_the_X3dv4_way()
else
render_the_X3dv3_way()
For the modelling/data_display the answer could be: "ask the user somehow".
It only needs to use the right rendering for different X3D versions.
It makes no difference how to display controlPoints in the white_dune
"FieldView": browsers usually do not show the contolPoints.
If browsers should use the controlPoints (e.g. for picking and dragging),
today extra X3D/scripting-code is needed and you begin the have X3D browsers
as modeller tools (eg. you are near to need a load/store thing in the
browser).
Is there a plan to make a new NurbsController node without coding ?
so long
MUFTI
"""
On Thu, May 21, 2020 at 7:18 AM GPU Group <gpugroup at gmail.com> wrote:
> 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/5d7a73f9/attachment-0001.html>
More information about the x3d-public
mailing list