[x3d-public] Nurbs patch coloring

Thu Apr 16 08:16:01 PDT 2020

Dear Michail,

thanks for your thoughtful response and going through the trouble of
applying the nurbs "vertex" color additions to your example case. Let
me first provide a full build of x3dom with these changes here:

https://5e986ab62dd47c00063c419a--x3dom.netlify.app/
https://5e986ab62dd47c00063c419a--x3dom.netlify.app/x3dom-full.debug.js

This should make it easier to test other examples.

Of course, smooth Nurbs surfaces are very useful. The question about
use cases was more about if vertex coloring is really that useful if
the necessary interpolation between control point colors is harder to
predict. But if you agree that this is the case for your use case of a
patchwork of small Bezier patches, then I agree that it is worth
considering as an addition to the standard. I think we will provide
the changes to x3dom soon with the dev version.

The CAD working group would be the body to involve in standardization.
Typically there are a lot of details to consider. For example, how
would vertex coloring apply to other Nurbs geometries ? Leave the
color interpolation method up to the specific browser or define it
more tightly ? Transparency ? Presumably, the idea would be to just
follow vertex coloring rules for vertex based geometries but this
needs some checking.

I took the liberty to add your example here for easier access:

https://5e986ab62dd47c00063c419a--x3dom.netlify.app/examples/functional/nurbs/bezierpatches.html

There is now a quick preview which uses the control points directly
without Nurbs interpolation. Since the control points are already
quite dense, the following incremental smoothing is a bit harder to
make out. It ends up with more than 700K triangles.

Let me also point to another technique for elevation coloring, eg.
coloring by one the coordinates. The idea is to use the coordinate
value directly as a texture coordinate, after appropriate scaling and
shifting.

Here is the example adopted to color by elevation, the y-axis:

https://5e986ab62dd47c00063c419a--x3dom.netlify.app/examples/functional/nurbs/bezierpatchesuvcoord.html

This uses TextureCoordinateGenerator mode='COORD' which makes the
local x and y coordinates directly u and v texture coordinates.
A TextureTransform shifts these then to the appropriate [0,1] range.
The texture is a (very small) 1x3 pixel image but could be any color bar.

You could swap the y and z control point coordinates to get the
intended elevation coloring.

Sincerely,

-Andreas

> Date: Wed, 15 Apr 2020 21:50:33 +0300
> From: Michail Vidiassov <master at iaas.msu.ru>
> To: X3D Graphics public mailing list <x3d-public at web3d.org>

> Dear Andreas,
>
> On Tue, Apr 7, 2020 at 5:50 PM Andreas Plesch <andreasplesch at gmail.com> wrote:
> > So it would make sense to add "vertex" coloring if there is a convincing use case.
>
> > I think the idea to compute a color surface in color space using the
> > same Nurbs parameters as the geometric surface makes the most sense.
> > In fact, I cannot think of another solution which is both general and
> > easy to implement. But it remains to be seen if this would be
> > practical since the resulting colors may be hard to predict/control.
>
> What is required to make the use case convincing?
> Wikipedia in its ultimate wisdom tells us "B?zier patch meshes are
> superior to triangle meshes as a representation of smooth surfaces".
> Using patchwork of Bezier triangular or rectangular pieces seems to be
> a quite common technique.
> Other forms of curved pieces are also used.
> Lots of references can be produced, but since NurbsSet is in X3D since
> v 3.0, it looks like it is already accepted  that handling objects
> composed from NURBS pieces is a thing to do.
>
> Surfaces composed of flat triangles or quads may have variable color
> applied to show some forth attribute that could not be mapped to
> coordinates, or highlight one coordinate (height) or some surface
> properties (curvature). Examples also abound.
> Since Bezier (NURBS) patch approximation is an improvement upon flat
> patch approximation I do not see reason for it to lack the option of
> getting smooth colors.
>
> > I think the idea to compute a color surface in color space using the
> > same Nurbs parameters as the geometric surface makes the most sense.
> > In fact, I cannot think of another solution which is both general and
> > easy to implement. But it remains to be seen if this would be
> > practical since the resulting colors may be hard to predict/control.
>
> In my case of cubic Bezier patches and linear interpolation of 4
> colors given at vertices (corners) of a rectangle this solution works
> nicely.
> I have to give color information as 4x4 matrix instead of 2x2, but
> that is a small price.
> As to the general case - my guess is that  the resulting colors on
> NURBS may be as hard to predict/control as the resulting texture
> coordinates, that are already in the standard.
>
> As to a (sort of) live test case:
> What am I trying to achieve:
> http://media.iaas.msu.ru/smoothelevation.html
> What I was able to do with your modified x3dom (rough and ready, just
> a proof it works for now)
> http://media.iaas.msu.ru/mytest.htm
> Where the example comes from:
> https://asymptote.sourceforge.io/gallery/3Dgraphs/
>
> Asymptote - program that started with drawing in 2D with cubic Bezier
> curves (as they are native to TeX and PostScript, it was a "MetaPost
> replacement") and later moved to 3D, where Bezier patches are used as
> building blocks for most surfaces.
>
> Sincerely, Michail
>
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
>
> ------------------------------
>
> End of x3d-public Digest, Vol 133, Issue 63
> *******************************************

-- 
Andreas Plesch
Waltham, MA 02453