[x3d-public] [x3dom-developers] Nurbs for x3dom

[Andreas Plesch]

I looked deeper at the Chrome 'Aw, snap' crashes with web workers, and
logging indicated Out Of Memory problems. I think  the issue may be
similar to https://bugs.chromium.org/p/chromium/issues/detail?id=782982
and https://bugs.chromium.org/p/chromium/issues/detail?id=800348 .
These are marked as fixed, and indeed, the latest chrome on linux
(Version 69.0.3497.92 (Official Build) (64-bit)) is much more robust,
even with 6 web workers. I still managed to crash a tab using the
http://www.web3d.org/x3d/content/examples/Basic/NURBS/StampX3dLettersIndex.html
example but this may be related to rendering since the tessellation
itself was successful. Using the Chrome Task Manager, the example uses
up 2GB of memory which seems extreme but there are almost 300k
triangles generated, and most is garbage collected later to get back
down to 800MB.

Anyways, this is good news, as it indicates that the web worker code
of the Nurbs tessellation overall works as intended.

-Andreas

On Mon, Sep 3, 2018 at 8:26 PM Andreas Plesch <andreasplesch at gmail.com> wrote:
>
> Hi Leonard,
>
> very helpful resources. I think the realistic goal would be to first
> just get the CPU, slow js tessellation working well enough, with the
> existing approach. Ultimately, I think it would be necessary to try to
> move as much as possible to the GPU. As you point out, it does seem
> challenging. Three.js, for example, does not do it.
>
> The previously linked verb code is probably pretty well optimized.
>
> I only tested chrome, on linux, and the tab crashes with the fred the
> bunny example when using more than worker but works with just one
> worker. The stamp x3d letters crashes even with just one worker, and
> also when reducing the tessellation level. The animated head example
> worked for some cycles before it also crashed but the other animated
> examples produce an exception (not a crash) presumably due to timing
> issue. I suspect both worker and memory, perhaps gpu issues. Chrome
> crashing at all is pretty hard to do in the first place. Let's see
> what firefox does. Overall, I think, the fragility can be addressed
> with a reasonable amount of effort.
>
> Animation may be ok with very low levels of tessellations but that
> misses then the point of nurbs.
>
> Let me respond to Joe and animation separately.
>
> -Andreas
>
> On Mon, Sep 3, 2018 at 7:34 PM Leonard Daly <Leonard.Daly at realism.com> wrote:
> >
> > Andreas,
> >
> > Great find.
> >
> > Am I correct in that you haven't had a chance to fully investigate the reasons for fragility? It looks like there are a number of ways you have found where the library fails (doesn't work as well as hoped) including # web workers and tessellation detail. Is animation even a reasonable consideration given the time it takes to tessellate a NURBS surface? It's probably the case that simple/careful animations on a limited NURBS would work, but something complex would not.
> >
> > A few resources on the issue of automatic and/or real-time tessellation.
> >
> > Maya has a mode for determining automatic tessellations. See the article at https://knowledge.autodesk.com/support/maya/learn-explore/caas/CloudHelp/cloudhelp/2018/ENU/Maya-Rendering/files/GUID-F4CCA0A7-C964-4BA5-AE5C-81A6696820F6-htm.html
> >
> > Intel has an article (and sample code) for doing tessellation in real-time; however, it's in C++: https://software.intel.com/en-us/articles/using-nurbs-surfaces-in-real-time-applications
> >
> > There is a research paper on efficient tessellation on trimmed NURBS at http://cg.cs.uni-bonn.de/en/publications/paper-details/balazs-2004-efficient/. I have not read this.
> >
> > This video shows the result of real-time tessellation on the graphics card. I don't know if this is standard WebGL calls (I think not), but it could be done as vertex shaders. https://www.youtube.com/watch?v=F9oLyOwbFp0
> >
> > This article claims 40,000 Bézier patches at 7-15 fps (almost real-time) on hardware almost 20 years old. I don't know how their equipment (SGI Onyx with three 200 MHz R4400 CPUs and a Reality Engine graphics accelerator) compares to web-browser technology today. http://gamma.cs.unc.edu/RENDER/render.html
> >
> > My quick review though these materials and others implies that constructing a general purpose algorithm is not easy; and perhaps to the level that the application needs to be tailored to a specific application (or perhaps input ranges) for things to work out real-time.
> >
> > Leonard Daly
> >
> >
> >
> > 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.]
> >
> >
> > --
> > Leonard Daly
> > 3D Systems & Cloud Consultant
> > LA ACM SIGGRAPH Past Chair
> > President, Daly Realism - Creating the Future
>
>
>
> --
> Andreas Plesch
> Waltham, MA 02453



-- 
Andreas Plesch
Waltham, MA 02453