The old GTKRadiant video-game level program had two very useful and ridiculously easy to use mapping types I wish Rhino had. Such quick mapping made drawings with over 15,000 objects commonplace in the game industry.
Single Point Mapping
The first was basically single-point planer mapping for repeating textures. You applied a texture/material) to an object, set the rotation angle and scale. There was no virtual mapping objects like boxes or cylinders to match to your object.
Once you had it set right, you could lengthen/shorten one end the object, and the mapping would just feed out. There was no need to mess with the mapping again. Want a longer wall stud, just 1d scale it. Neither material nor mapping should have to be adjusted again.
Additionally, the textures were locked onto the objects during translations. Available widgets let you set the repeats, or clone the texture scenario from one object and paint in on others. Click to copy, and click, click, on each wall. Some editor versions even had a randomizer.
See: 6:30 https://www.youtube.com/watch?v=jQE1fjHkkZ0
The second type of mapping I wish we had was called “natural” mapping, in which a material is mapped and repeats along the H/V of a splined or would-be NURBS object. In other words, if you created a knot in a pipe polysurface, it could texture it!
See: 11:50 https://www.youtube.com/watch?v=ccNpyWtCVqE
Lastly, in many games rendering speed is vitally important, for this reason, a no-draw or “caulk” texture/material was created. Applying such a texture to non-visual or hidden surfaces of objects could vastly improve rendering and preview speeds. This one reason why I wish we had texture-per-surface without exploding.
You can draw a huge building and hide the bottoms of all the columns, of doors.
Such a texture was also used where z-fighting was a problem, such as a triangle laid flat tapering to no thickness.