[x3d-public] Nurbs patch coloring

Tue Apr 7 07:48:42 PDT 2020

I have update the nurbs coloring example at

http://andreasplesch.github.io/x3dom/test/functional/uvGenCOORD.html

to show coloring according to control point colors defining a color
space surface (top) and coloring using default texture coordinates and
an equivalent pixel texture (bottom). I also added the locations of
the control points.

Note that four control points have the same location, in the center.

It is an interesting example because it shows how the two approaches
are not as equivalent as I initially thought. 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.

-Andreas

On Mon, Apr 6, 2020 at 8:29 PM Andreas Plesch <andreasplesch at gmail.com> wrote:
>
> I went ahead and gave the idea of a color space surface a try here:
>
> http://andreasplesch.github.io/x3dom/test/functional/uvGenCOORD.html
>
> This is an example where the interior control points are not on the
> evaluated surface. This is why there are no pure blue and green colors
> in the interior.
>
> Overall it seems feasible to do that.
>
> -Andreas
>
> On Mon, Apr 6, 2020 at 3:39 PM Andreas Plesch <andreasplesch at gmail.com> wrote:
> >
> > Dear Michail,
> >
> > it looks the use case would be lots of small nurbs with colored
> > corners ? It would be probably really helpful to see an example use
> > case.
> >
> > Viewer capabilities and conformance are important but secondary to
> > design and spec. decisions.
> >
> > The technical problems with "vertex" colors for control points are
> > that a control point location is not necessarily a vertex location
> > (perhaps it is along the borders but not elsewhere), and that it is
> > unclear how to map from  a control point color to a vertex color of
> > the final tesselated surface. Do you have something in mind on how to
> > determine the color of vertex of the triangle mesh given control point
> > colors ?
> >
> > Here is a thought experiment. Presumably, one could evaluate the Nurbs
> > in color space given the control point color coordinates, eg. compute
> > a parametric color surface. I think that means while tesselating the
> > geometric surface, compute also the point on the color surface for
> > each uv. It might work but I am not sure if it leads to expected
> > results. For example, one would have to clip the computed colors at
> > minimum and maximum saturation since the evaluation can generate
> > colors outside that range.
> >
> > BTW, I would not call obj simple and mature, especially as compared to X3D.
> >
> > Cheers, -Andreas
> >
> > > Message: 1
> > > Date: Mon, 6 Apr 2020 11:18:35 +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,
> > >
> > > many thanks for the detailed explanation.
> > >
> > > On Sat, Apr 4, 2020 at 1:23 AM Andreas Plesch <andreasplesch at gmail.com> wrote:
> > >
> > > > The simplest approach may be through a PixelTexture:
> > > > This is equivalent to listing the color in a proposed MFColor
> > > > controlColor field except for the formatting of the rgb colors.
> > > >
> > > > In addition, textures give you some control how to interpolate colors
> > > > and deal with borders.
> > > >
> > > > From an implementation perspective, translating the control point into
> > > > a texture like this would be probably the simplest approach because it
> > > > avoids having to compute a vertex color for all vertices of the
> > > > rendered, tesselated surface, typically an IndexedTriangleSet. Given
> > > > that it seems more appropriate to just use a texture in the first
> > > > place.
> > >
> > > 1) What you say looks quite convincing in theory, but AFAIK scenes
> > > with lots of small textures are not among typical use cases, so viewer
> > > implementations may have all sorts of problems at this rough untested
> > > edge, for example hitting the maximum number of textures.
> > >
> > > 2) Textures having more options then vertex colors instead of giving
> > > "some  control" may in fact give less control if viewers lack features
> > > or implement them inconsistently - and Michalis Kamburelis shows in
> > > his review of the state of texturing in the X3D world that there is no
> > > "if".
> > >
> > > 3) Personal (quite limited and likely outdated) example:
> > > I once had an ugly experience writing a OBJ exporter. It had access to
> > > color maps used by the main program, so I did not have to use a
> > > separate texture for every output quad and the ability of textures to
> > > give control of how colors are interpolated was put to some use.
> > > But "dealing with borders", i.e. "dealing away with border effects"
> > > across all the required viewers, getting exactly the specified colors,
> > > was a royal pain: as far as I remember I had to give up using boundary
> > > texels, get sure texture coordinates hit exactly in the middle of
> > > texels (so 0 and 1 were BIG no-no), make texture sizes pot etc. All
> > > that took place with OBJ, which, relative to X3D, is a simple and
> > > mature format.
> > > While all that mumbo-jumbo may be written off as one-time programmer
> > > effort, the output suffers in terms of readability by humans: instead
> > > of a point having color (1, 0, 0) it gets coordinate (0) in
> > > one-dimensional colormap texture, that due to viewer bugs and
> > > limitations becomes something like (3./512,3./512) in two-dimensional
> > > padded texture.
> > >
> > >  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 7
> > > ******************************************
> >
> >
> >
> > --
> > Andreas Plesch
> > Waltham, MA 02453
>
>
>
> --
> Andreas Plesch
> Waltham, MA 02453

--
Andreas Plesch
Waltham, MA 02453