[x3d-public] Nurbs patch coloring

Fri Apr 3 15:21:49 PDT 2020

To be honest, I do not quite remember the context but I think I can
explain my earlier reasoning why "vertex" (control point) colors for
Nurbs are somewhat redundant. Perhaps this is also why such coloring
is currently not available in the spec.

Nurbs control points (for surfaces) define a 2d grid along u and v
dimensions. It is straightforward to color each control point with a
corresponding grid of colors, by using a texture and the default
texture coordinates. In fact, the default texture coordinates are
equivalent to the u,v coordinates of the control points. Here is an
example of a Nurbs surface defined by 3 control points in the u
dimension and 2 in the v dimension:

1 2 3
4 5 6

The numbers are indices into the coordinates array of control points.
Let's color each point:

1: white, 2: red, 3: white
4: red, 5: white, 6: red

Now the only step left is to define a texture image. The simplest
approach may be through a PixelTexture:

<PixelTexture image="3 2 3
0xFFFFFF 0xFF0000 0xFFFFFF
0xFF0000  0xFFFFFF 0xFF0000" />

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.

-Andreas

> Date: Fri, 3 Apr 2020 12:18:08 +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

> On Fri, Jan 26, 2018 at 4:36 AM Andreas Plesch <andreasplesch at gmail.com> wrote:
> >
> > If 2x2 textures would work, it.may be possible to use PixelTextures which could be constructed from the control point color information perhaps pretty directly. Actually, such a PixelTexture may be more appropriate  than a hypothetical controlColor MFColor field since the non control vertices would have to be colorized by some interpolation in a texture mapping like process anyways. But there may be an upper limit to the number of textures.
> > Combining the textures into a single image gives the browser and player a chance to cache the image which would be beneficial for loading it for each surface. In theory, a single texture could be shared on the openGL level by all surfaces. But it would depend on the x3d player's ability to optimize.
> > I thought I would mention that currently neither x3dom nor x-cite implement the NURBS component. So webgl limitations may be not be an immediate concern unless the goal is actually to target the web.
>
> Since X3D v4 is being codified, maybe the idea of coloring NURBS
> patches with "hypothetical controlColor MFColor field" instead of 2x2
> texture is worth revisiting, even if only to be rejected.
> The reasoning is the same: if a scene is built upon a mesh of NURBS
> (say bezier) patches, the author may have the same reasons to wish to
> assign colors to "vertices" of that mesh and have them interpolated
> within "faces" as in the common case of a triangle mesh.
> And having to always use textures instead of vertex colors has the
> same drawbacks.
> For example even the venerable OBJ format (that has that limitation)
> is being "de facto" extended to allow for vertex colors, their great
> usefulness (vis baking textures out of them) outweighing breaking
> compatibility with the long established standard.
>
> Sincerely, Michail
>
>
>
> On the positive side since 2018 NURBS got implemented in WebGL X3D libraries
>
>
>
> ------------------------------
>
> Message: 2
> Date: Fri, 3 Apr 2020 09:05:49 -0700
> From: Don Brutzman <brutzman at nps.edu>
> To: X3D Graphics public mailing list <x3d-public at web3d.org>
> Cc: Medical working group <med at web3d.org>
> Subject: [x3d-public] Volume Rendering visualization examples
>         improvement, X_ITE support
> Message-ID: <6cbb369c-2a27-a326-ed1d-f0362e044ff8 at nps.edu>
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>
> The Volume Rendering component of X3D Graphics international specification is a well established capability.
>
> We were happy to note that X_ITE recently (quietly) added support for X3D volume capabilities.  7 examples are shown on the following page.
>
> * X_ITE X3D BROWSER: HAVE YOU SEEN THIS?
>    http://create3000.de/x_ite/getting-started
>
> Screenshot attached of example rendering in X_ITE, taken from X3D Example Archives.
>
> All of the online examples have just been updated.  The models there were lacking the second component statement:
>
> * X3D Example Archives: Basic, Volume Rendering
>    https://www.web3d.org/x3d/content/examples/Basic/VolumeRendering
>
> * <component level='1' name='VolumeRendering'/>
>    <component level='2' name='Texturing3D'/>
>
> This second component is a requirement for use of ImageTexture3D node when otherwise within X3D profile='Immersive'.  Added an X3D Tooltip to help flag this issue.
>
> * X3D Tooltips: ImageTexture3D
>    https://www.web3d.org/x3d/content/X3dTooltips.html#ImageTexture3D
>    Warning: requires X3D profile='Full' or else include <component name='Texturing3D' level='2'/>
>
> TODO: add further diagnostics in other Quality Assurance (QA) tools.
>
> Future plans for X3D4:
> a. ImageTextureAtlas has been proposed, we will look at it again in upcoming weekly X3D working group meeting.
> b. Developmental work is investigating support for normal data, which is available already in the volumetric datasets already but is not explicitly supported in the X3D specification. Utilizing this information can improve rendering.
>
> Very glad to see continuing implementation support and consideration of new examples, especially in medical domain.  Have fun with X3D volume rendering!
>
> all the best, Don
> --
> Don Brutzman  Naval Postgraduate School, Code USW/Br       brutzman at nps.edu
> Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA   +1.831.656.2149
> X3D graphics, virtual worlds, navy robotics http://faculty.nps.edu/brutzman
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: VolumeRenderingX_ITE.png
> Type: image/png
> Size: 602121 bytes
> Desc: not available
> URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20200403/5fbe5175/attachment.png>
>
> ------------------------------
>
> 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 3
> ******************************************

-- 
Andreas Plesch
Waltham, MA 02453