Chair Design → T-Splines → Unity

This being my first project investigating T-Splines I wanted to choose a suitable subject for the medium. So it is not really about ‘chair-design’, per se. The latter is simply a useful starting point as its ‘complexity’ is defined by a few double-curved geometric forms rather than the sheer number and interfaces of orthogonal elements – as typical of most buildings.

The thread is filed under the ‘Work-in-Progress’ sub-category of ‘Share’.

Furthermore, I wanted to anchor the exercise in some form of ‘reality’ rather than gratuitously produce a quirky shape – so my design is grounded in Henry Dreyfuss Associates’ ‘Humanscale’. I bought it in 1974 when it was first published and I’m glad to see it was revived via a Kickstarter campaign in 2017.

All output was generated using a basic T-Spline workflow:-
NurbsCurve.ByPoints -> TSplineSurface.BuildPipes
NurbsSurface.ByPoints -> TSplineSurface.ByNurbsSurfaceUniform -> TSplineSurface.Thicken
NurbsSurface.ByPoints -> TSplineSurface.ByNurbsSurfaceUniform -> TSplineSurface.Thicken
NurbsSurface.ToNurbsSurface -> TSplineSurface.ByNurbsSurfaceUniform -> TSplineSurface.Thicken
NurbsCurve.ByPoints -> TSplineSurface.ByExtrude -> TSplineSurface.Thicken
All Final Export:-
TSplineSurface.ToBRep -> Mesh.ByGeometry -> *.OBJ

I made extensive use of Custom Nodes and DesignScript as the project would have been a nightmare to setup and maintain using a myriad of Standard Nodes –
I do rely heavily on the latter, however, at the early prototyping stage.

Once again, final presentation output was via Unity’s environment with high-res capture using a 3X multiple of the screen resolution, cropped to a 4k x 2k image. To paraphrase Voltaire :-
‘The offline rendering best is the enemy of the real-time rendering good’.

The latter is more than adequate for my purposes.
In conjunction, I’ll be keeping a watching brief on the imminent ‘Oculus Go’ launch –
It might be an ideal entry-point for VR-based concept development work.

WIP Update 01.
Test to determine whether automated UV-mapping is adequate for application of materials with large-scale texture patterns. During the development process the idea is to keep manual intervention to the minimum.

There are obvious visual deficiencies with full automation and time penalties for full manual UV-mapping.

The primary alternatives are:-
A. Automation via script on separate components or a single combined mesh.
B. Manual UV-mapping on separate components or a single combined mesh.

Assuming the former is preferred at the rapid iteration stage then the workable secondary alternatives are:-
A1. Assign separate but identical materials to each component where required and adjust scaling and offsets to suit in the Inspector.
A2. Assign a single material to all components where required and adjust scaling and offsets to suit via a script assigned to each component.

In the above example A1 was chosen as adjustments could be monitored in the Scene View without needing to enter ‘Play’. A2 requires ‘Play’ to be run in order to update the materials even when Execute-In-Edit-Mode is added to the script.

Bottom-line is why bother with anything but full UV-mapping automation at the early stage of design? I guess it depends entirely on who the intermediary concepts are being presented to. In addition, the complexity of the surfaces will influence the decision.