[x3d-public] Nurbs patch coloring

[Andreas Plesch]

Hi Michail,

thanks for extensive response.

Just a few thoughts since I have to get back to other things:

I think the default texture coordinate for Nurbs surfaces may be
already what you proposed. So I think NurbsColorCoordinate may boil
down to constructing a texture image from the provided colors.

Dynamic tesselation is allowed but not required by X3D, for good
reason. There have been ideas on how to do that on the GPU but that
would require a larger effort and initiative, probably with sustained
resources. Octaga or BSContact may do it.

I am not quite sure about how linear color interpolation would work. I
think in uv space, for a given uv look up the closest control point
colors in u and v, and linearly interpolate colors. Is that what you
have in mind ?

Please file an x3dom repo issue about the black texture in the
example. Please add console (F12) messages.
https://5e986ab62dd47c00063c419a--x3dom.netlify.app/examples/functional/nurbs/bezierpatchesuvcoord.html

Creative texture coordinate use is rather common in computer graphics.

Why do you think the color space nurbs interpolation approach may not
be general enough ? Can you think about a Nurbs surface where this
approach could not be used ?

Parametric step size is only a hint in the X3D spec. Tesselation
details are up to the browser.

Cheers, -Andreas

> Date: Mon, 20 Apr 2020 13:16:04 +0300
> From: Michail Vidiassov <master at iaas.msu.ru>
> To: X3D Graphics public mailing list <x3d-public at web3d.org>
> Subject: Re: [x3d-public] Nurbs patch coloring
>
> 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
>