T-Splines

[giannissc]

Are there plans to support t-splines as well on truck?

Also seeing how t-splines are a superset for NURBS and subdivision surfaces (hope my understanding is correct :p ) would it make sense to make all modelling centre around T-splines?

[ytanimura]

T-spline is patented by Autodesk. https://patents.google.com/patent/US7274364B2/en It seems to use it with Rhino. We need to check the conditions of availability. It is not immediately supported.

[virtualritz]

One thing that may be an alternative is to use OpenSubdiv's BFR API to create a patch mesh from the subivision surface (sds). I.e. the limit surface is approximated by piecewise parametric surfaces (b-spline/bezier patches) which can be represented by Truck.

In a parametric setting you would have a life connection between the polygon cage that defines the sds and the resulting patches (stitched together at their non-naked edges).

I did a Rust wrapper for parts of OpenSubdiv a while back but I didn't wrap the API part that generates piecewise parametric surfaces. OpenSubdiv will get a nice, official Rust wrapper eventualy as part of the ASWF effort to oxidize the VFX library ecosystem anyway.

I think T-junctions as a feature are overrated (the one thing that makes T-splines special). The most common use case is really having a mesh that originates from a polygon/sds modeling system on which you want to do some BREP operations (or vice versa). And that can be covered with what OpenSubdiv's BFR API offers right now (and w/o any patent/licensing issues).

[johschmitz]

I agree with @virtualritz. Could the term "subdivision surface" or "subdiv" be added to the issue title in order to avoid duplicates?

[ytanimura]

One motivation for creating a shape processor from scratch is to provide a wasm module that can be handled in the browser for small models. There are cases of transient code that cannot be made wasm, or cases where the code is parallelized and accelerated only in native, but basically everything is ideally designed to work in the browser. Maybe I am just uninformed, but I think it is reasonably hard to run code that includes FFI on a browser. Therefore, even if it were to be implemented, it could only be used in a limited way, and I am not very positive about it.

[virtualritz]

Yeah, no idea how hard it would be to cross compile C++ to wasm that later sits behind an FFI for Rust.

That said, I don't think it's an issue, at the beginning, if a feature like subdivision surface support sits behind a feature flag that must be disabled to build truck for wasm.

[lynaghk]

The linked T-spline patent is now expired.

[eliasboegel]

T-splines would be extremely useful for me. If thats a feature that could be developed, that would be phenomenal!

[virtualritz]

See my comment above. I think it much more useful to have support Catmull-Clark-subdivision surfaces-as-patch meshes.

What would T-Splines enable that CC-subdivision surfaces would not?

[eliasboegel]

See my comment above. I think it much more useful to have support Catmull-Clark-subdivision surfaces-as-patch meshes.

What would T-Splines enable that CC-subdivision surfaces would not?

Please correct me if I'm wrong here. My understanding is that CC subdivision surfaces can't represent exact conical sections because these surfaces are still described by non-rational splines. Given that NURBS are a special case of T-splines, T-splines would be able to handle exact conical sections with subdivisions.

[virtualritz]

My understanding is that CC subdivision surfaces can't represent exact conical sections because these surfaces are still described by non-rational splines.

That is true. However, what are the practical implications? If you design a part that has conical sections that need to be perfect (vs approximated to something not distinguishable for the human eye) you are likely solving an engineering problem, not a design problem.

I.e. you are working on a mechanical part and you would simply use actual NURBS geometry for these parts.

I guess I'm saying: show me a part where using T-splines made more sense than using a combination of NURBS and live connected patch meshes originating from a CC-sds. :) In the latter case you are still free to take a cylinder and subtract it drill a perfect quadratic (circular) hole anywhere, e.g.

Also note that T-splines have topological limitations (quads only) that CC-sds do not (and which specifically matter when you design organic stuff, e.g. product design).

One of the latest papers of some people at the forefront of T-spline research is scattered with examples that are very much suited to be done with existing sds-technology. I.e. they don't require T-splines ...

[eliasboegel]

My understanding is that CC subdivision surfaces can't represent exact conical sections because these surfaces are still described by non-rational splines.

That is true. However, what are the practical implications? If you design a part that has conical sections that need to be perfect (vs approximated to something not distinguishable for the human eye) you are likely solving an engineering problem, not a design problem.

I.e. you are working on a mechanical part and you would simply use actual NURBS geometry for these parts.

I guess I'm saying: show me a part where using T-splines made more sense than using a combination of NURBS and a connected patch meshes originating from a CC-sds. :)

Also note that T-splines have topological limitations (quads only) that CC-sds do not (and which specifically matter when you design organic stuff, e.g. product design).

The people at the forefront of T-spline reasearch have specifically have many and also their latest paper scattered with examples that are exactly suited to be done with existing sds-technology. I.e. they don't require T-splines ...

Yes, its definitely a niche use-case and confined to engineering. My motivation here comes from a fast growing field of finite element analysis where the geometry is directly CAD geometry (e.g. some type of spline). In this context, exact conical sections and T-junctions in the "mesh" are very helpful: exact conical section representation is important since there are several problems that are very sensitive to the accuracy of the boundary geometry description (e.g. fluid dynamics), and T-junctions are useful for adaptive (local) mesh refinement. Moving towards a common geometry description between CAD and FEA is a very attractive goal for a variety of reasons (from the computational engineering POV). I don't know the amount of work that goes into supporting T-splines over other alternatives, but I can at least give some motivation to look beyond just design use-cases for a new CAD kernel.

[virtualritz]

Fair enough. I didn't know and I see your point. I also learned something. Thank you for taking the time to explain your motivation.

I will open a separate issue for sds support in truck. ☺️

[PeterDessev]

Hey all, though I would add that I am currently working on T-mesh and T-NURCC implementations for truck. The fork is public and can be seen here. Let me know what you guys think.

Currently, I have only implemented some of the very rudimentary logic for T-meshes as described in the original paper on the subject, however, more is on the way!

[virtualritz]

This is awesome! 🤩

I do have to bring the naming issue up again though.

Unlike pretty much any other language, Rust has clear guidelines on naming structs.

E.g. it should be Tspline, not TSpline.

See also this post on the rust mailing list which IMHO nails why this is actually great and shouldn't be a point on contention, even if you're not a fan (I wasn't at the beginning but have since changed my mind). 😁