I’m pretty sure that MOI is also a NURBS modeler, it has a very good mesh exporter although.
Unlike Rhino, MOI is a mesh modeler.
That is totally and 100% not true…
Actually, MoI can’t even import meshes normally, it’s 100& NURBS, but users have written an OBJ importer so you can get your cage mesh in. It simply creates one NURBS patch per polygon. There also are some scripts for basic polygon-like modelling (working on the assumption that a patch equals a polygon), but the main idea is to model in a real SubD modeller and only use this script to import and convert to NURBS.
The developer of MoI, Michael Gibson, actually is a very well known guy when it comes to Rhino…
I knew Michael when he worked here years ago.
I haven’t seen him in a number of years.
I was basing my mesh comment on the description from his own MOI Web site:
“MoI is also a fantastic complementary tool for a polygon-based artist since its CAD toolset and advanced boolean functions enable extremely rapid creation of mechanical or man-made type “hard surface” models. The icing on the cake is MoI’s unique polygon mesh export that generates exceptionally clean and crisp N-Gon polygon meshes from CAD NURBS models.”
Yes, it has one of the best polygon exporters (from NURBS) I’ve ever used.
Many companies I worked with I recommended it simply for that single function. And the export is even multithreaded…
I used to hate NURBS but MOI made me “see the light”…
Hi John, You made the right assumption from that description, based on your background. …but what Michael means is that Moi is a good companion product for people working on mesh modelers. What makes it a good companion? You can model mechanical forms much faster and explicitly with Moi (Nurbs] than extruding cubes around in a mesh modeler. And then you can export back as mesh with great ngon settings for clean and near-subD-friendly (some manual tweaking always required) meshes.
In fact mesh items can’t even exist in Moi. They are only previewed at export time.
Best wild guess time-frame would be Rhino V7.
So we are taking about 2020 and beyond time frame (5 year release cycle as per history timeline here)
Looking at the release cycle of Fusion 360 from Autodesk (every 6-8 weeks) my guess is Fusion is not going going to catch up but leap frog you guys if you continue with such insanely long release cycles…
But it is logical: with thirty developers who have to deal with many aspects it is normal that the development times are prolonged in time.
Even with a dozen developers in more the SubD, for example, would have been already implemented, and instead we have to wait another years!
I recommend you load a semi complex (not a spoon) low-poly model in Fusion 360 (out of compassion, I won’t challenge you to build it from scratch there) and then convert it to their version of SubDs. Try a few edits. Come back and report what you’ve found
The T-splines technology (what they call sculpting) is integral part of Fusion and is used to build models of all complexity. See this: https://gallery.autodesk.com/fusion360/projects (you are kidding yourself if you think people only build trivial models with it)
Rhino needs this and should have had this by now. T-splines was acquired by AD in 2011…
From my post 18 days ago:
Hi John, I don’t like to say “user” , but what can the people do on this side of the software to help its move forward?
@Holo has made some great tools, with little time.
I tried Clayoo, it seemed ok. I had more Rhino crashes than any time I could remember. That is what would be good with sub-d built by Mcneel than a third party . It would function as Rhino does now (very stable).hat off to you all for that.—Mark
Context from the past: We all know Tsplines (this happened just 10 years ago http://www.tsplines.com/news-blog/59-t-splines-board-of-directors-announced.html) …we helped Rhino helping them. We all know its technology (advantages and limitations) and its founders, who are very nice loving people BTW.
Many of us own the Rhino Tsplines plugin, have used it, we have even helped them greatly get it better in terms of workflow and functionality. They reached enough maturity to be visible by ASDK and be successfully (for the Tsplines team) acquired.
Back to the present: If you are thinking they have the magic bullet you should use it, but my sincere recommendation still stands: load a semi complex, try some edits. FYI, out of curiosity, I updated my subscription to see how performance is today’s with current build. Nothing like first hand experience.
I’m do not have the luxury to spend time to experiment with F360 atm. Can you elaborate a little on how well in your opinion a complex model is handled?
Not much directly beyond discussing it here.
It is a long-term project. It not like we can license a set of tools, write a U/I, and implement it quickly. We have to write the core code and through the incremental WIP process, mold a set of tools that are useful and intuitive to as wide an audience as possible.
I think generally, people don’t have any grasp or understanding of the massive development effort required.
As it seems very likely T-splines (and possibly Clayoo in time too, if it suffers the same fate as T-splines) won’t work in V6, it might be worth considering speeding that up a bit, or you may find that people will take up V6, albeit slowly.
I don’t have the impression that most Rhino users depend on T-Splines, but perhaps I’m wrong here… --Mitch
Bob and the developers will decide how to best allocate resources to provide the best tools we can in the shortest time possible, but everything is a trade off.
It makes no sense to throw everything we can at one new feature at the expense of everything else.
My comment applied to a whole raft of plugins really, not just T-splines. Rhinoworks, VSR Shape, T-Splines, Scan and Solve, etc etc. I won’t be in a hurry to move to V6 if it means that I lose that lot.
It does seem a flaw in the Mcneel armour. Say, tomorrow, another developer turns up on the Rhino scene and announces another silver-bullet plugin. The good folks here all get on board, help out with growing it and making it useful (as G’s comments). What’s to stop those developers doing exactly the same thing as those that came before? Rhino is the long term loser, as all we do is strengthen the opposition.
T-Splines for Rhino end of life
Yeah, kind of agree here…
I’ve got most of those, and am resigned to the fact that I will probably have to keep running V5 for some time to come. Hopefully the proposed upgrade options for V6 won’t inhibit this option? If it does, than I’d have to consider buying a whole new licence for V6. I might pause for thought over that.
The good thing about the Rhino plug-in approach, is that lots of new and different ideas can be tested out, even if the best do get skimmed off. At least it maintains an affordable software option for small businesses.
If McNeel direction is steered to incorporate missing features, albeit slowly, I get the feeling that at least they will be incorporated well and that long-term it is still a positive outcome.
Feels like T-Splines went a long time ago now though, and work has only recently started on an in-house alternative?
We were very focused on getting the Mac Rhino rolled out during that time frame. Then when TDM Solutions was purchased by Stuller, and nothing else was on the horizon to replace it, we decided to move in that direction. It’s on the back burner now while getting the rest of the V6 big chunks finished up.