17 minutes ago, Rutin said:

we will either use an auto retopology method or manually do it to create a low poly version,

CADs uses surfaces not a meshes. so you anityme have "as many as you want triangles model". Also it allow any model feature like fillets, holes, tiny geometric details and anithing else be turned off and on anytime. So it is algoritmically simplier to compare surfaces with turned on and off tiny details to make accurate displacement and normal maps for low LODs level, becouse CADs curved model have a information about whole surfaces, while triangular meshes dont have it information. Most of CADs have no it functionality  or using it under cover to simplify  visualisation of complexive assemblies, but it can be made by custom addons. Or by tool with CAD-like core intended to gamedev-specific needs. Again - existing CADs intended to general machinery modelling for actual production, but not for game production, so just not take care about very importent to gamedev features, that can be easily done using CAD core geometrical tools.

FWIW, there's AAA games out there that actually render models directly from curved-surface definitions, not triangle meshes...

14 hours ago, Hodgman said:

WIW,

of couse its not so easy to shift from idea "add normals and UV to triangle vertex coords" to idea "get anything from surface UV". At least it reduce size of data that required to describe glide surfaces and allow to have a continous LOD. Also curved surfaces can be rotated and projected before tasselation, so reduce calculations required for rotation of high-detailed geometry. Also surface data anycase required to match conjugations rules. Really triangular models  good for rendering only. For any other processing required a surface data. So renderinf from surfaces just eliminate huge sets of data that complexive to manage, becouse it have to have a sparse sets for LODs. Of  cource tasselation-based approach of surface rendering have a limitations in comparsion with native NURBSs rendering that home-grade hardware not support yet, but it anycase better than triangles. Realy triangles is NURBS of 1st order. To increase accuracy of glide surface it required to increase quantity of triangles at least lineary for each curved dimension. But also it can be done by increasing a order of base primitive without increasing a quantity of primitives. It is what splines actually do.

19 minutes ago, Fulcrum.013 said:

Of  cource tasselation-based approach of surface rendering have a limitations in comparsion with native NURBSs rendering that home-grade hardware not support yet, but it anycase better than triangles.

So the advantage you see in CAD is mainly about NURBS?

And you think hardware support for NURBS would make sense?

Why not just implement it? Why using silicon for something that has such a restricted use?

1 hour ago, JoeJ said:

And you think hardware support for NURBS would make sense?

Really professional hardware has start to support surface rendering many years ago, just at same time when first home-grade accelerators appeared. It uses robust integer bresenhaim-like approaches to render surfaces. But looks like it still to expensive for home usage.  Both D3D and OpenGL have a native support of surface rendering from its first version, but it no hardware available yet. I neveer seen a vcard with surface caps bit turned on, ever GeForces of 10x serie have it turned off.  

1 hour ago, JoeJ said:

So the advantage you see in CAD is mainly about NURBS?

Main advantage is more robust modeling concept at least for machinery and architectural objects. And resulting model allow to make most processing much eathier than triangular models, and also allow to make processing that triangular models not allow to make due to lost of surface date.

1 hour ago, JoeJ said:

Why not just implement it?

Tesselation based-approach require original NURBs to be pre-tesselated to Bezier curves/durfaces. It reduses disadvantages of triangles but not complete remove it. Also current hardware require to switch shader to triangular-based patches and rectangular-based patches. Also current hardware functionality disallow to have a variable count of contorol vertices for patches so planar surfaces have to have a same control points as curved, while flexible order of segments is a key feature of  NURBs. Anything of it reduses NURBs  flexibility so much, so using of it instead of triangles require about complete replace of sorting and other algos that preparing models for instanced drawing.  

Of cource it can be implemented, and currently im in progress on its. But it much complexive in comparsion with "just send primitives to pipeline"  technique that hardware-supported primitives have. I gues it why rendering from surfaces is not widely used yet.

NV had hardware bezier patches for GeForce 3. Then they removed it and i wrote them an email to ask for the reason. Mark Kilgard himself replied: "Nobody used it." I was not happy, because i used it as my primary primitive. (Also their very first GPU was surfaces only, but it was no consumer product, IIRC)

Those patches were quite similar to actual (more flexible) hardware tesselation, but meanwhile i would agree to remove even that as well, if it takes more than a tiny area of silicon.

I totally do not believe in those things anymore for rendering. Construction yes, but not rendering. Better give us more compute power and felxibility so we can implement what we need ourselves. (I think the same about RTX)

17 minutes ago, Fulcrum.013 said:

Of cource it can be implemented, and currently im in progress on its. But it much complexive in comparsion with "just send primitives to pipeline"  technique that hardware-supported primitives have.

Why not convert to triangles offline? (If you can say, i'd be curious...)

25 minutes ago, JoeJ said:

Why not convert to triangles offline?

To have a continous LODs and tiny models sizes. Really high detailed NURBS model require count of vertices comparable with collision mesh and not require nomals, UVs, tangents, bitangents, and so on into vertices. Just coords of control points and nothing else.

26 minutes ago, JoeJ said:

Those patches were quite similar to actual (more flexible) hardware tesselation

But NURBSes is not  a Bezier. It much better extension of Bezier introduced by Boeing at 80-х. nVidea never have a hardware suppot of NURBs at least on GeForce. Also tessilation to triangles have limited number of segments so make complexities with ajusting LOD level just at hardware level, it require to involve pretesselation to bezier patches. Again NURBS involves segments of different order, so optimal pretesselation to Bezier involve patches of different topology so optimally pretasselated surface can not be drawn using a single drawing call. Also nowadays appeared a T-spline extensions of NURBSes, that allow T-shaped control vertices topology be mixed with cross-shaped, that not fit to tesseletion topologies that hardware have. It allow to have a tesselation that twice better optimized to surface curvature and by the way describe a gaps into surface using spline core math, not involving additional curves to make a gap shape, so allow to draw a surfaces with gaps, that tesselation topologies unable to do without pretasselation to set of Bezier patches with gaps betwin them. 

Really tesselation shaders give a very basic Bezier support and better fit to other approach of sculptured surfaces - Chaikin's subdivision surfaces, than to controlled  surfaces like NURBSes. But nowadays T-Splines extension has joined NURBSes and Chaikin's surfaces to single powerfull mathematical tool for surface sculpturing that have advantages of both approaches. 

2 hours ago, JoeJ said:

NV had hardware bezier patches for GeForce 3. Then they removed it and i wrote them an email to ask for the reason. Mark Kilgard himself replied: "Nobody used it."

Of cource it can not be contributed on fixed pipeline that ever not have a Phong shading. Most of advantages, except continuos LODs, appears with per-pixel lighting.

Ok, makes sense. My own interest was always focused more on organic modeling and at some point i realized NURBS are not good for that, catmull clark is the best we have. (Unfortunately its not well suited to GPU tesselation either. Bet we do not want to retesselate every frame, so that's no real problem in any case.)

To make CC more suitable for technical modeling, i've added soft and hard creases. Until today i do not know a professional tool that does this well, and there are some unnecessarily complicated papers about it. For me the creases was just adding a few lines of code to the simple original algorithm to modify weighting. Results are good, you could model a car with a very low poly control mesh, but there is no advanced NURBS like ability to cut a hole into a surface.

CC is also not perfect. You need to be careful so the singularities don't show up. Artists still need to worry about things like edgeflow too much i think. But the parametric advantages you mention are given.

However, the real problem with LOD is not to keep details while zooming in, it is to suppress details when zooming out. So even a NURBS control mesh would not help there. Quadrangulation can help because it allows to move geometric details into texture space in many forms and runtime complexity is minimal. But for games we want a really low resolution control mesh, which is still an unsolved problem.

Also FWIW, there's already games leaving triangles behind:

http://media.lolrus.mediamolecule.com/AlexEvans_SIGGRAPH-2015.pdf

https://twvideo01.ubm-us.net/o1/vault/gdc2018/presentations/Aaltonen_Sebastian_GPU_Based_Clay.pdf