[x3d-public] Nurbs patch coloring

[Michail Vidiassov]

Dear Andreas,

On Thu, Apr 16, 2020 at 6:17 PM Andreas Plesch <andreasplesch at gmail.com> wrote:

> 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.

The Asymptote case is IMHO quite simple:
make the next step after flat lines/triangles/quads and segments, use
Bezier patches and curves, while the color interpolation stays linear,
as it was in the flat case.
The math argument is "a smooth surface composed of multiple Bezier
patches requires C^2 continuity of the geometry at the patch
boundaries in order to have smooth normals (and hence smooth
lighting), but only C^0 continuity of the colour".
Thus the gain form assigning colors to internal control points of a
Bezier patch while somewhat desirable in theory is considered for now
not worth the effort to implement and resulting overhead.

As you said earlier, what I want is similar to the effect of a 2x2
texture with linear interpolation (AVG_PIXEL), but without harassing
hardware textures and dealing with boundary problems.
(And artifacts of texture coloring with AVG_PIXEL that can be seen at
http://media.iaas.msu.ru/my_nurbs_texture_test.htm
Some of them are caused  by texture wrap mode set to "REPEAT", but
setting it to CLAMP or CLAMP_TO_EDGE breaks colors.
Such an example may be a good test case of how it is hard to
impossible to achieve with textures the effect of smooth color
interpolation between vertices.)
While your "idea to compute a color surface in color space using the
same Nurbs parameters as the geometric surface" took small code
changes to implement and solved my immediate problem nicely and covers
future use cases I can think of, I am not sure if it looks general
enough for X3D standard.
Would it look like an acceptable idea if applied to texture coordinates?
So some "NurbsColorCoordinate" allowing as much flexibility as
NurbsTextureCoordinate may be the result of trying to treat vertex
colors in a way as general as texture coordinates are being treated.
On the other hand the only feature of NurbsTextureCoordinate I would
like to see in "NurbsColorCoordinate" is the following:
"If a NurbsTextureCoordinate is undefined, texture coordinates are
computed by the client on the basis of parametric step size."
If the same is done to color coordinates, then the result is (if I get
it right) that linear mapping of 2x2 vertex colors.

Let me reiterate:
1) you approach - works, covers anything I need, but with overhead
2) linear interpolation - important special case IMHO worth separate
treatment, may be the default
3) "NurbsColorCoordinate" - to have the same level of flexibility as
with textures, but, to my knowledge, for no other reason

For NurbsCurve, NurbsSwungSurface, NurbsSweptSurface I can see how
linear interpolation of colors between endpoints can be used.

My thinking is affected by "small Bezier pathes/curves": if one wants
specific colors at specific points he puts vertices there and
interpolates between them. But linear interpolation also looks easy to
describe and understand. Is it hard to implement?

> 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.

An X3D model is assumed to be interactive and viewpoint may be changed
by zooming to some detail.
In some game-like scenario viewer can be reasonably prevented from
getting inside a dragon's machine-gun or be kept at sufficient
distance so he can be fooled by a texture. But it is not so when we
visualise data to explore it, not knowing in advance at what we'd like
to look.
The X3D spec speaks at length about possible non-fixed tessellation strategies.
So for a "truly vector graphics" the total number of triangles must be dynamic.

> Although the asymptote renderers seem very targeted, there may some demand for that.

Specific tools are created by scientists when there are no available
general ones to solve a particular task.
Are there X3D viewers that tessellate NURBS on the fly (do not
pre-tessellate once and for all at loading of the scene)?

In theory Bezier patches may be used to render other NURBS surfaces.
"Since direct evaluation of NURBS surfaces on the GPU is a highly
complex task, the usual approach for rendering NURBS is to perform the
conversion into Bezier surfaces on the CPU, and then evaluate and
tessellate them on the GPU." (
https://doi.org/10.1016/j.cad.2014.06.005 )

> 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.

Coloring by texture has its drawbacks.
1) It may not work right. Your example shows black in my browser.
2) 1x3 pixel texture is subject to boundary effects.
If we have color coordinate 1/6 the resulting color will be not some
weighted average of the first and the second colors, but the color of
the first texel, since we are right at its center. 1-d textures tend
to be unsupported by viewers.

Anyway utilising such high-level features of output format as coloring
by one the coordinates is opposite to Asymptote paradigm of operating
with independent simple and small primitives - not the only possible
or the universally best paradigm for a drawing tool, but a reasonable
one, one to have in mind when thinking about use cases for X3D.

Sincerely, Michail