Subd cars-

A couple weeks back, I was able to carve out a session to investigate how well and far the SubD system would let me convert my old tSplines model. The explosion of detached, heavy polysurfaces didn’t transfer through to anything I cared for. Rather than fight each and every isocurve-dense panel, I gathered it’d be a lot simpler to just redo it from square one natively in Rhino’s SubD. This move also served to REALLY see what the WIP could do… 2+ weeks and 305 SubD objects later, it’s SubDs aaaaaaaaaaaaaaallll the way down:


Following Holo’s rules, individual body panels.


One-piece factory OEM Style 35 rims. No shortcuts.


By this point, it was clear that Rhino SubD (RSD) stayed impressively light on its toes regardless of whether I wanted to model in box or smooth mode for however long I wanted. The tSplines predecessor would’ve started behaving sluggishly LONG before I had a chance to get here. Sluggishness directly impedes the ability to whip the model around and that’s primarily the reason why I never entertained the idea of body panels back then.


Guages, vent slats, knurled knob, shift boot. SubD, subd, subd, aaaaand subd. Yes, with ALL objects left visible AND in Rendered View, the model twirls around like nothing I’ve seen before. What manner of scorcery is this, McNeel? It can’t ALL be from the new notebook (8-core i9 5ghz, 32mb RAM, Radeon Pro 5600M 8GB)

I’ll toss any additional shots in a gallery post.

20 Likes

That’s thanks to Dr. @dalelear I think, he really optimized the SubD render mesh display performance for large models. Love your project!

5 Likes

Sounds great

I agree SubD performace is 10X better than Tsplines. I never liked Tsplines because it had (initially) very crude tools, and even though their tool set evolved a lot, the performance (and don;t get me started about stability) never delivered. Even today’s implementation in Fusion still cannot deliver in performance, part of that might be that they use shitty AWS cloud computers, instead of leveraging the power of our pro hardware.

We still have models where Rhino SubD slows to a crawl, Because the more we get, the more we want. 10 years ago we were happy to have smooth SubD in realtime in a shaded or ‘olde rendered’ viewport. Today the bar has moved, and we want to have this same smooth behavior on realtime PBR rendered models.

We are working quite extensibility in PBR these days and sharing our findings with McNeel’s dev team. They pointed this out in one of our chats a few months ago:

“Yes, this really drives Rendered mode crazy. SubD tires would make 26100 NURBS surfaces each. They also make 6681600 polygons each.”

We really think we need a per-object faceted/smooth override to take advantage of all the wonderful bells and whistles that keep making Rhino work harder that past decades’s workflows.

The “Gustojunk’s McNeel-troubling Squad” proposed this at the time:

But this probably needs a lot of +1s and likes to be youtracked …some day.

G

11 Likes

Ah… :thinking:

Thank you for sharing ~ :cold_face: