https://www.violationentertainment.com/wiki/tiki-editpage.php?page=Buttertub
https://www.violationentertainment.com/wiki/tiki-index.php?page=Spline-cages(advanced)
Spline-cages (gMax & 'viohuman'22')
------
Against all popular belief, spline-cages definitely have a place in modelling, especially concerning supreme scalability as to be perfectly geared toward infinitely detailed LOD ranges, so naturally we're all about that. However, their infamy is truly deserved when it comes to how tricky they are to get correct and how confusing and frustrating they are to work with, as vertices become what are literally known as "knots". Compounding the challenge is that the only freeware way to actually do this is to use gMax, a software now over two decades old. Despite all of this, there are a couple of very important reasons to persevere along this path, and the whole reason this software earns a place in the team's development repertoire at all.
First of all is texture-mapping. Only gMax (3DSMAX) is capable of unwrapping splines at their base fundamental level, with the UV coordinates using the same bezier method and parametric curvature, able to be collapsed and precisely aligned to match all other UV unwraps of all other LOD stages. It's even possible to still exploit intentional warping, due to UV vertices having unique bezier handles to themselves. This is all a massive deal impossible to understate, and Blender is (still) not capable of doing this.
Secondly and just as important, the way in which it's possible to collapse the cage to a mesh at every stage. A specific axis is able to be subdivided in a consistent and logical way, along specific edges, while not the other, thus flowing along an angle. This is for cylindrical shapes to be subdivided by "slices" (angles) and not lengthwise redundantly, a trick not widely understood but which shouldn't need its importance explained. Although there are otherwise ways to clean this up if were not the case, it can't be automated and will require fixes to every model at every detail stage. Being able to control this from the fundamental spline-cage base, before it collapses to any stage, saves a harmful amount of monkeywork.
Once we realise this, and also realise that despite its age and being a very gimped version of it, 3DSMAX was the professional standard of its day, and these necessary tools fully remain in gMax, perhaps not even intentionally. With knowledge, focus and patience, it's still extremely useful, to say the least. The only remaining contention is the exporting functionality, and this is where some very esoteric practices come into play. After a ridiculous amount of research and experimentation, it turns out that not only can a variety of meshes be exported to and fro (multiple UVs, vertex colours and weights, animations, etc) but even actual splines themselves. Furthermore, a plethora of contemporary "MAXscripts" are potentially compatible. It turns out, its notoriety for being futile to export from, while understandable, is very far from the proven reality. It's very possible to even get a spline-cage from 3DSMAX to and from gMax. This means all bases are covered and a majority of the development still happens with gMax, available and free to all artists.
During that era, spline-cage modelling was fashionable trend for creating precise and highly-detailed vehicles, with Renault actually using spline-cages in the designing process of real cars. This made it synonymous and defacto approach to creating models of cars. Highly-detailed, real-world cars, specifically, almost only cars, up until this very day. It became a strange phenomenon cemented in the collective, just for cars. Due to the fact that the majority of a car surface doesn't necessarily require a clean unwrap or consistent texture-mapping, and one could do just fine using a procedural material even (although not advised) for real-time rendering, letting reflections do all the work. I suppose this is a reason why the texture mapping was never really an issue. It's a reasonable suggestion for making a racing game, but I propose to challenge the paradigm more extensibly, and ask the question - if a car, then why not anything else, why not a human character?
A quick note about "NURMS" and some similar approaches - splines are capable of "bezier corners" (control points being disconnected despite the vertex being welded) and integrated triangular spline-cells. This means a spline-cage is capable of characteristics like sharp concaves and truly folded geometry, as well as being truly compatible with legacy-friendly triangulated meshes, which is important for lower LOD stages being more conservatively factored, and even making the base cage itself capable of being directly converted to a mesh for export. Other methods such as using NURMS are undoubtedly more user-friendly and provide smoother results for less effort, but are not as technically versatile and as able to remain consistent as the spline-cage approach from which NURMS originated. Handling the control points of a bezier corner where multiple edges converge is anything from tedious to infuriating, in comparison, the benefits outweigh the challenges.
It's important to make a clear distinction, that the "viohuman" project is not for creating complete finalised characters all and only from spline-cages, but more accurately to use spline-cages as a "base", to be cleanly subdivided while retaining infinitely refined curves and contours. This is like a blank canvas for a complete character to be created from, and is not even suitable to create a bare naked human, just by itself. For this example, a varied range of displacements would be used with a varied range of techniques to apply them, possibly followed up with manual sculpting passes, to be very simplistic about it. A spline-cage is the foundation and character creation happens at a phase when it ceases being a spline-cage and actually becomes a complex network of patch objects, with each spline-cell becoming a patch object unto itself, all interconnected. By that phase of the process, the scalability and texture mapping becomes trivial while not creating any barriers to creativity.
A further range of techniques exist to handle semi-rigid objects that still deform and animate with the human character, heavier clothing and even armour, bandoliers, soft quivers, etc. Fully rigid objects (known as "accoutrements") are a separate matter more for the rigging phase of development, but even "almost-rigid" objects can have geometry features baked into the spline-cage, at its basic fundamental level, using a method called "cross-section", so that the features are fully integrated into the essential geometric form, with plenty of room (very intentionally) remaining in the unwrap channel to texture it all, whatever it is. Further techniques involve convenient remeshing and conformal shrinkwrapping of the head and face to perfectly match scans of real human beings, a concept potentially requiring a whole other essay.
.
.
.
And here it is, the 'whole other essay'...
In essence, a spline-cage, the bezier corners and knots and the subsequent quiltwork of editable patches are all much the same, in slightly different forms for very specific technical concerns. The crazy thing, and something else wildly esoteric and never intended as useable, is that simple low-poly meshes (much like that found in real-time graphics of the era) can actually be used to create a shape and then potentially transformed into a very functional spline-cage. The effort might not be worth the trouble, of course, but a clean and evenly topologised mesh can present very few obstacles, and as such the "viohuman" project not only descends from its original, but directly transitions forward through to this evolved workflow, turning the 2008 triangulated mesh version into a spline-cage for 2022 and beyond. All along, it never actually needed to be recreated.
The tricky part has been understanding how vertices from a low-poly editable mesh can be logically translated into knots of a spline-cage, which are two entirely different things. The important aspect is that the edges of a triangle are no different from a spline, except curved into S-shapes with 2 bezier corners and their handles. It's these individual corners and handles that dictate the form of each cell of the cage, that which was previously a quad of a low-poly mesh. A "smooth" result offered by the software is fine for only a single iteration, almost never a second or beyond. Converting every vertex to a bezier directly is only good for meshes where the topology is evenly dispersed almost to perfection, and it's impossible for it to intelligently average itself along every edge of every triangle or quad. A few MAXscripts exist to help with this and they are used, but the one true solution is something so obscure and abstract that only blind bulldozer power of deduction experiments resulted in it being stumbled across by accident.
So now a smooth and presentable spline-cage has been achieved but its potential only just beginning, we're presented with a galaxy of knots and all of their handles, one for each vector of every converging spline. One thing to definitely drive home the necessity to keep things simple is the performance drop due to just rendering the user interface viewport while examining this galaxy unfolded. Any artist quickly learns to use the hide function at a low level early on in hopes to get any work done. A lot of people would throw in the towel already, but each and every single one of those handles is capable of an (almost, and with a lot of catches) infinite amount of possible forms to curve and bend just one end of a spline, with another being equally capable at the opposing end. Also consider that adding loops and rings into topologically balanced areas of the cage is ridiculously simple, and with a lot of patience, unlimited potential, all easily scalable, all unwrapped and all capable of further refinements such as displacement and sculpting, is possible and well worth the struggle.
This struggle rears its ugly chops as bezier handles clash with the user interface, allowing only one to be manipulated at a time, and requiring multiple steps to wrangle unlike almost everything else. Working with them outright raw can (and definitely should) be mastered, but it is possible to script the entire scene to constrain the handle itself to a helper "dummy" object, bound together in 3D space, and then operate on the dummy objects instead of the handles, allowing for mass editing of multiple vectors at once, translating, rotating and even making use of some modifiers. This trick requires extra setting up and should only be done where and when necessary, but it's feasible that scripting could potentially automate this entirely. This doesn't mean that trying to create something great using spline-cages is any less confusing, it actually becomes a little more confusing, but the editing process has gone from torturous anxiety-inducing tedium to now just being a tolerable challenge, and the most painful parts are over.
With the texture-mapping stabilised in an unwrap channel already carefully splayed and organised, and a spline-cage now ready to be acquainted with the surface modifier and proceeding to an editable patch, displacement maps (bumpmaps) can begin to take action and effect. However, against all conventions yet again, not only a single textured displacement exists in a single texture space, but it's possible to have many different images being used in many different ways, all layered atop one another and all individually adjusted at any time. The modifier stack system in gMax is exactly like that of 3DSMAX, and displacement modifiers, selection sets, locational tessellation and meshsmoothing, along with some other tricks, allows an entire hierarchy of deformations to happen, right down to details such as individual veins, wrinkles and even hairs. Even gMax offers this huge advantage which allows displacement to occur on all conceivable levels of detail and avoid artifacts such as sawtooth and stairstep. Because the unwrapping process was already done at the spline-cage level, every displacement map is compatible with every model and potential character, no adjustments ever need to be made to the texture coordinates, and that's even true for every LOD stage that it will be collapsed and exported to. Really the central premise and purpose for this compartment of the workflow itself.
A well-crafted spline-cage with a mountain of displacement modifiers is good, but still not enough, and the spline-cage itself requires some specific adjustments that will result in dedicated geometry being available later in the process. This is done by either manually inserting new splines, rings or loops, or using the cross-section method which can infuse one spline-cage into another. This is typically necessary for clothing or any non-rigid features of the character design that require being rigged to individual bones of the skeleton and of the articulated figure, which is for ragdoll physics. Even something spanning large areas diagonally, completely at odds with the topological flow of the base cage. Because multiple unwrap channels are available, each selection of cells can share unique secondary channels used explicitly for displacements needed on geometry that is against the grain and framing of the original primary unwrap channel. The bumpmaps are usually dedicated images anyway, and this means it's no challenge to have sharp straight parallel texture features flow perfectly with the orientation of the unwrap coordinates of the secondary channel, giving perfect results of the displacement deforming the patch geometry it's assigned to, no matter how at odds with the character flow the feature is.
For human characters specifically, 99% of the concern is with the face, and there's little hope of me personally achieving fantastic results using only displaced spline-cages, although I will still try to, if for nothing else than distant background characters in a cutscene. It's not 2008 anymore and I am too rusty. To create realistic characters, the true aspiration is to use real human beings, and derive both geometric form and texture data directly from a real person. Seems so, but I don't think it's entirely the case nor a wise endeavour directly, for a variety of implications. To retain the purposeful topology of the spline-cage, retain the texture mapping, to ensure everything is absolutely consistent on a technical and mechanical level, perhaps even stylistically, and to keep propriety over the actual content if not all of its derivations, a different approach is key. Conformal shrinkwrapping can be used to relocate every vertex to the nearest-closest face or edge located underneath, processed after a push modifier has already inflated it like a balloon. A very simplistic explanation of what is a tricky technique requiring a lot of care. Combined with the reasonable expectation to be able to also bake textures from the outsourced assets, along with some other tricks to help a smooth transition for anything that is not a native element to blend into its target, there's no reason that a "viohuman" shouldn't look at least extremely similar to whatever scans we use this technique with, if not casually indistinguishable.
.
.
.
.
.
.
.
.
.