Splinecage misconceptions
----------
The most common reactions I've had so far to varying extents (sadly, usually minimal) to the entire splinecage workflow I've been dedicating my life to for the previous two years.
- Blender can do this.
"Blender can do splines, splinecages and UV unwraps, but it can not do splinecages _with_ UV unwrapped texture mapping _and_ scale parametrically with those UVs in tact _and_ be collapsed by individual segments via individual axes. Blender is still not able to do all of this, even though Blender is central to the workflow overall."
- Sculpting can't be done on splinecage.
"This is technically true in a pedantic sense, but the splinecage is only an intermediate phase of content creation, and sculpting happens at a later phase when the asset is already in the form of an editable mesh. The sculpts are baked back into the texture and the splinecage can inherit everything if necessary, for displacements of real-time models. So the sculpting and high-end displacement stuff is not affected by the use of these splinecage techniques whatsoever."
- Rigging and animation is too much of a nightmare.
"Again only technically true and mostly the same as with sculpting. The rigging doesn't take place on the splinecage itself, only the editable meshes derived from the cage, although the actual cage represents edges and vertices present in every LOD stage and beyond, always guaranteed, and it's these vital points that an armature is rigged to. This means all animation is compatible with every LOD stage and vertex weights and heat is all that's needed to fine-tune issues with density. Rigging and animation also not affected."
- Inherent details can't just be modelled in.
"While things can't just be constructed into the splinecage like with non-parametric mesh modelling, there are still many tricks to achieving anything imaginable and certain things even allow exploits that are not otherwise possible. Cross-section technique is the primary skill and it's not as difficult to do as it is to understand. Quickly refining rings and loops in a neat way is also better with a splinecage and does not damage the parametric bezier curvatures at all. Because everything is derived from a low-poly mesh originally, anything is still possible at that fundamental phase because the mesh need only be as low-poly as its most simple logical form requires, which might not be so simple depending on the design."
- Shrinkwrap won't work on a splinecage, can't use scans.
"Finally, while also technically true, again this is taken care of during the editable mesh phases both before and after the central splinecage phase used to create all LOD stages. Exact shape of a human head to achieve such level of realism is a concept not really in the hands of modellers anyway and these days is mostly automated. By using that real data and applying it to the low-poly mesh that the splinecage will be created from, it already puts 99% of the accuracy in place for the bottom half of all LOD stages, and this is something more for the very high-end top-third of very high-poly character models, meaning that in reality only very few LOD stages require precise shrinkwrapping of real human scans for realistic characters. As for the texture-baking of real scans, it actually can't get any better than the hand-crafted tradition UV layout that the human bases already have, tried and tested for generations."
...
So a common theme, a huge misconception about the splinecage method is that it's somehow using _only_ splinecages to do _everything_ in some insane attempt at playing God, as though doing one thing instantly blocks all other techniques from being possible. A technique is one which not inherently incompatible with any other, infact very few. A splinecage is a way to keep everything parametric while retaining texture mapping and deploy to various complexities of that same asset, perfect for LOD. It's not a desert island to risk being stranded upon - it's a technique, a phase in the middle of content creation, a way to achieve maximum scalability, even to infinity.
.
.
.
.
.
.