[x3d-public] Nurbs patch coloring

[Andreas Plesch]

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