[x3d-public] Nurbs for x3dom

Tue Sep 4 15:19:35 PDT 2018

It does make sense to start thinking from a high level and have
abstract, ideal goals. On the other hand, it is also important to get
to a functional level with a reasonable amount of effort.

On Tue, Sep 4, 2018 at 12:57 PM Joseph D Williams <joedwil at earthlink.net> wrote:
>
> OK, and I stand with the idea that the objective is documentation for active NURBS geometry using nurb notation to describe the geometry and the animations. The nurbs is mainly a short but still precise and eadable way to define some active sets of geometry using a specialized notation, which is of course rendered as triangles and lines just like if it was defined as some other standard x3d geometries.

The difference is that most/all other x3d sets of geometry can be
decomposed into triangles in a straightforward manner. NURBS are
designed to be smooth, which is the opposite of faceted, polygon
defined geometry. Unfortunately, this distinction is very important.

>
> Given that Nurbs is not supported on a hardware level
>
>
>
> I don’t think that matters but would actually be surprised if true – lots (all?) of x3d stuff existed before widespread hardware level support. Of course it is runtime intensive because the player needs some special deep coding support to produce actual active rendered geometry from the x3d user code. Please find and use the best of the x3d players to validate whatever user and execution code you are using and let’s look for x3d stuff that does not line up tight with gltf and ogl

I think you are saying that it is not true that it is necessary to
have Nurbs support on the GPU directly. I think I heard the argument
that VRML was a little too far ahead of hardware capabilities to
become more widely adopted at the time. On the other hand, it is still
around.

Many Nurbs tessellation/rendering articles start by saying that Nurbs
are nice but not GPU supported. They continue to then say that is why
the described method is important. The deep coding support is exactly
the issue and requires compromises and trade offs.

Here is an article which describes a GPU based evaluation method which
is more or less what I had started to think about:
https://graphics.c.u-tokyo.ac.jp/hp/wp-content/archives/cad07kanai.pdf

Perhaps there is actual GLSL code somewhere for this method.

> Of course the x3d definitions are intended to provide a way to document and produce live stuff in a scene. If the geometry cannot be animated except by transformation of its parent, and, it is reasonable to expect that a typical player can handle x3d user code for some ‘static’ nurbs but not big parts of x3d nurbs, then maybe time to have a level of support capability that does not require nurbs fields that are used as animation interfaces? Which of the ins and outs and inouts are special?

I think a lower level of support may make sense which does not require
control point in flow. This way the focus of the renderer can be
instead on higher quality rather than higher animation frame rates.
The tessellation fields would also need to be inert since a change
requires a complete retessellation.
The knots fields are not animatable anyways.

-Andreas

>
>
> Thanks Again, Andreas, NURBS is important.
>
> Best Wishes ,
>
> Joe
>
>
>
> From: Andreas Plesch
> Sent: Monday, September 3, 2018 6:07 PM
> To: Joe D Williams
> Cc: x3dom-developer mlist; X3D Graphics public mailing list
> Subject: Re: [x3d-public] Nurbs for x3dom
>
>
>
> Hi Joe,
>
>
>
> Octaga was mentioned as a good Nurbs implementation but I did not test
>
> it. I think most other x3d browser also have some support.
>
>
>
> Given that Nurbs is not supported on a hardware level, there is a
>
> necessary tessellation step. OpenGL has Nurbs support but also only on
>
> the CPU. WebGL does not have it.
>
>
>
> For real animation support it would be therefore necessary to use
>
> shader/cuda code to help with tessellation or perhaps raytracing as
>
> much as possible. I could not find existing shader code but there is a
>
> lot of research as it is a pretty obvious target, in the Nurbs,
>
> engineering domain.
>
>
>
> Thinking out loud, without really understand Nurbs more than as a
>
> remapping of UV space to XYZ space using polynomials, I suppose it may
>
> be possible in a fragment shader to determine the U and V of the
>
> fragment and then calculate the corresponding XYZ using the splines.
>
> These coordinates can be retrieved as an RGB float texture, and reused
>
> as vertices and triangulated using the UV connectivity, eg. UV
>
> neighbors should stay XYZ neighbors. So there probably would need to
>
> be UV rendering as well. This procedure will make ugly triangles but
>
> perhaps not too bad.
>
>
>
> Perhaps there is a way to avoid complete re-tessellation with new
>
> control points, eg. to efficiently calculate an adjustment of the
>
> existing mesh based just on the changes in control points ?
>
>
>
> I think there may be enough value, albeit perhaps not so much fun,
>
> with static rendering of Nurbs surfaces. Machine parts, nuts and
>
> bolts, engines and such do not deform easily :).
>
>
>
> -Andreas
>
>
>
> On Mon, Sep 3, 2018 at 5:55 PM Joseph D Williams <joedwil at earthlink.net> wrote:
>
> >
>
> >
>
> >
>
> >
>
> >
>
> > Animation and lines do not work.
>
> >
>
> >
>
> >
>
> >
>
> >
>
> > So, basically not current x3d Nurbs right out of the box. The x3d nurbs are designed to be animated, not simply as carriers for already composed piece of frozen art. Will look, but is there any conforming x3d implementation you have found? The current spec has been through a couple of technical revs up to now, but I don’t remember any thinking there is a level of capability for an x3d nurbs implementation about being able to use or not use the various nurb ins and outs supporting actual realtime animation using interppolators. Maybe what you have is a sort of process that takes some common nurbsburg characteristics and delivers it back to x3d as some other form of geometry. Looking for some examples, but please look for a tool that can play with real active [in,out] events, and, not sure there is an x3dom markup that just takes all our precious nurby [in,out]s and makes them []s, I hope.
>
> >
>
> >
>
> >
>
> > How about checking with the most world-reknowned vrml/x3d NURBS Component implementers? There has to be one or two somewhere.
>
> >
>
> >
>
> >
>
> > I memory is fading, but seems I remember some fun. If you don’t have SFNode [in,out] controlPoint(s) []    [X3DCoordinateNode] and stuffs like add/removeGeometry [NurbsSurface] and profiles and  trajectory, and add/removeTrimmingContour [Contour2D] and some usable realtime interpolators, then the tool is just a little geometry exporter maybe suitable for off-board making a frame of a video. Not much fun without the old ins-outs, and yes, some transparency. What we wish for is a complete documentation of collections and sets of nurbsthings over time, with the same sorts of best-practice data structures and animations as expected for any other x3d geometries.
>
> >
>
> >
>
> >
>
> > Thanks and All Best,
>
> >
>
> > Joe
>
> >
>
> >
>
> >
>
> >
>
> >
>
> > From: Andreas Plesch
>
> > Sent: Monday, September 3, 2018 1:04 PM
>
> > To: x3dom-developer mlist
>
> > Cc: X3D Graphics public mailing list
>
> > Subject: [x3d-public] Nurbs for x3dom
>
> >
>
> >
>
> >
>
> > Ayam is 3d modeler focused on Nurbs: http://ayam.sourceforge.net/ . It
>
> >
>
> > turns out that it comes with a functional implementation of Nurbs
>
> >
>
> > surfaces for x3dom which may be possible to adopt for the main x3dom
>
> >
>
> > distribution.
>
> >
>
> >
>
> >
>
> > As a start, for testing, I transferred the ayam js nurbs code to a
>
> >
>
> > x3dom Nurbs branch:
>
> >
>
> >
>
> >
>
> > https://github.com/andreasplesch/x3dom/tree/Nurbs/src/nodes/NURBS
>
> >
>
> >
>
> >
>
> > It works pretty well. Here is the Four Ducks web3d Nurbs example:
>
> >
>
> >
>
> >
>
> > https://rawgit.com/andreasplesch/x3dom/Nurbs/test/functional/nurbs/inline.html
>
> >
>
> >
>
> >
>
> > Many other examples work as well. Animation and lines do not work. The
>
> >
>
> > ayam code uses web workers for tessellating. Using a pool of more than
>
> >
>
> > 1 worker seems to be fragile.
>
> >
>
> >
>
> >
>
> > Here is another nice js Nurbs library:
>
> >
>
> >
>
> >
>
> > https://github.com/pboyer/verb
>
> >
>
> >
>
> >
>
> > But it would be most realistic to make the existing ayam code more
>
> >
>
> > robust and complete, at least first.
>
> >
>
> >
>
> >
>
> > - Define all x3d nodes in the standard x3dom way.
>
> >
>
> > - Investigate web worker crashes (perhaps in FreeWorkerThread).
>
> >
>
> > - less aggressive default tessellation.
>
> >
>
> > - try without web workers
>
> >
>
> > - investigate x3d text example crash (too many triangles?).
>
> >
>
> > - animation: skip when last tessellation not yet finished
>
> >
>
> > - curves. interpolators
>
> >
>
> >
>
> >
>
> > The common approach would be anyways to tessellate before exporting to
>
> >
>
> > X3D, and then use a binary format (binary X3D, SRC, glTF).
>
> >
>
> >
>
> >
>
> > Any feedback or contribution welcome, -Andreas
>
> >
>
> >
>
> >
>
> > [There is a lot of work on GPU based tessellation/evaluation as well.
>
> >
>
> > A common approach is to tessellate the non-trimmed patch and then use
>
> >
>
> > a texture mask to hide the trimmed portions.]
>
> >
>
> >
>
> >
>
> > --
>
> >
>
> > Andreas Plesch
>
> >
>
> > Waltham, MA 02453
>
> >
>
> >
>
> >
>
> > _______________________________________________
>
> >
>
> > x3d-public mailing list
>
> >
>
> > x3d-public at web3d.org
>
> >
>
> > http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
> >
>
> >
>
>
>
>
>
>
>
> --
>
> Andreas Plesch
>
> Waltham, MA 02453
>
>

-- 
Andreas Plesch
Waltham, MA 02453