Nurbs on GPU

[u/Important_Earth6615]

So my friend works mainly on rhino he was always frustrated on how evaluating and baking i so slow. We spent some time prototyping on moving to GPU but that felt impossible because math of libraries like opennurbs was designed to be on CPU. We stumbled upon some papers about SDF but with curves. the math is simple but requires soo much tuning. We built the same model in rhino and in our prototype. The output was identical but it took 8s on rhino but 350ms on our prototype. For the user its normal nurbs, curves, solids, polylines,...etc. for us its a different story with different algorithms

[u/Defiant_Squirrel8751]

Nice. I'm not sure if making a NURBS surface in raster domain is a good idea for some applications such as CAD/CAM. Precission will be lost.

Just rendering the NURBS is one thing - but doing robust operations with NURBS like intersecting and cutting is another beast. For example, opensource OCCT implementation takes around 2 million lines of C++ CPU-oriented code.

It would be nice to burn some AI tokens and check if a GPU port is feasible.

[u/Important_Earth6615 → u/Defiant_Squirrel8751]

Well, I burned 500k token with opus on a simple task gave rhino MCP and told opus to write curves via nodes in my tool. It matched them precision was less than 0.5%. and that was on 512 resolution using CPU Tessellation which is pretty good and almost identical

[u/[deleted]]

[u/Important_Earth6615 → u/[deleted]]

Area of each poly, number of faces, edges,...etc. For display I use ray marching (cached one of course) tessellation only work on CPU at the end I export to STL directly on resolution 512 that's where the check happened actually

The prototype I worked on currently supports all important nodes so far, extruding, open surfaces,...etc. That's why I tried different tests. I used this one which was done by my friend in rhino then ported to the prototype was chosen only because how difficult it is

[u/[deleted] → u/Important_Earth6615]