[x3d-public] Nurbs patch coloring

Michail Vidiassov master at iaas.msu.ru
Mon Apr 6 01:18:35 PDT 2020


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



More information about the x3d-public mailing list