Hi RMA team,
As you are all preparing for the massive update of SubD tools, could you please make you that you also hook up the SubD object-type to be able to use commands like:
Draft analysis
Emap
ShowEdges
BoxEdit
CageEdit
When working with SubD objects these are essential tools to evaluate and edit geometry.
Thanks,
Gustavo
SubD modelling is one of the big big ways of modeling complex, organic forms and do that with an easy and fast workflow.
We need a smooth tool and a smooth preview like in maya for the subDās.
I would suggest McNeel to look at subD/mesh modeling in Maya and the tricks the not continued T-Splines was able to do.
In my opinion, this capabilites need to be implemented into Rhino for their core mission: to be a modeling tool for designers.
And please make the mac version catch up with the win version asap.
It is happening all the time.
Have you checked the current Mesh Utilities in the v7 WIP?
Hi, we are working on mac versions in our company and there is the Rhino mac v6 wip.
So thatās a bit of an issue for us.
As a student I worked with Rhino and T-Splines and with that Rhino was really nuts in terms of designing complex geometries intuitively.
Maya has great mesh smooth and preview, bridging, insert edge loop ā¦ tools and we have still an old license laying around. But it has no future for designers if it keeps being that expensive meanwhile you donāt need 80% of all the animation/rigging tools.
Mesh Utlities in v7 WIP has bridging and edge loop insertion too. Many of what T-Splines did can be done on meshes with v7 WIP. The current command list is: Append, Bevel, Bridge, DuplicateFaces, Extrude, InsertEdge, InsertPoint, RetopoSelect, RetopoUpdate, SelEdgeLoop, SelEdgeRing, SelFaceLoop, Slide, Stitch, SubdivideFace and Thicken.
My point is that eventually this will also be in the Mac version.
The v6 WIP for Mac will mark the point that code bases are pretty much the same, and there should be more or less feature parity.
Hello Nathan
I donāt have v7wip installed so I canāt check but I seem to recall, back when sub-D was first mooted, there was talk of an alternative filleting tool using it. Is this the case or am I just imagining things.
@Tone not sure I am aware of that discussion. Do you mean fillet for mesh? Perhaps the Bevel command?
I donāt recall that either (but then I havenāt been paying detailed attention to the Sub-D project), but thereās two problems with that. First of all itās actually very difficult to get exact circular geometry with sub-ds, it naturally flows into a more organic shape. This is also why I personally donāt particularly care about it.
The other, more serious, issue is that sub-d is an entirely different object type from breps. Itās possible to convert a sub-d into a brep quickly and with high accuracy, but not the other way around. Sub-ds also arenāt a type of surface that could be part of a brep, surfaces in Rhino must have a topologically rectangular uv-domain, and sub-ds can be much more complicated than that. In short; there are no good ways to convert a brep into a sub-d and there are no good ways of embedding a sub-d into a brep.
Filleting an existing sub-d shape which has creases on the other hand should be relatively straight-forward. Either the weights of the crease edges can be lowered, or a few additional edges can be inserted into the control-mesh.
I think your thinking makes sense for a lot of applications, but also this is why I particularly do care about Ub-D for industrial design surfacing/cosmetic work. Radial fillets and G1 transitions are not very aesthetically pleasing. Most refined products these days donāt use these forms unless the product is defined specifically by being prismatic and ābrutalistā. Or unless is designed but mediocre designers in Solid-sort-of-works.
With organic forms and higher degree topology we do still however need to have exact circular/planar/offset details (like a cylindrical rod inside an axle for a rotational hinge or translation piston) and this is where a hybrid approach with live-booleans make sense.
Iām mentioning this David, because as a starting point it would be very cool to do these live-boolean objects between Nurbs/SubD in Grasshopper. We ājustā need a few definitions in place. So we can have a workflow like this: https://youtu.be/PSxYbd1_INU
What do you think?
Cheers,
G
SubD capable tools with a Solid Kernel, like Autodesk Fusion often deal with two separate geometry stacks as well.
Modoās Mesh Fusion uses polygon based SubD and afaik tesselated quadric geometry to add the sort of detail which is notoriously difficult to add with SubD methods alone.
Autodesk Fusion and other Nurbs packages use limit surface based geometry in their SubD workspace and convert to Brep in another workspace. Here one may further modify the Brep with parametric tools (cut holes,apply fillets, shellā¦) One may however switch back to the Sculpt-workspace and modify the input geometry. The updated version of the cage replaces the pre-existing Brep, all parametric features get re-applied.
Of both methods the Node based Mesh Fusion approach sure is more interactive.
thanks for the explanation Holger!
I want the live/realtime intersector/boolean interaction of Mesh Fusion, but without their limitations: quads only, fucked-up interface, extremely unreliable and unstable. Down right unusable for any serious work.
Iām ok if all the live interaction is a proxy/mesh preview approach and then ābakeā only once you want to commit something. Of course having always the ability to go back to the live operands (mixed topology types) and make changes and re-bake. ā¦this is why maybe Grasshopper is the way to get this done in a manageable way. I cannot even imagine the UX complexity to try to do this in the Rhino interface.
I have only limited knowledge of the math behind all this, but I think, and please correct me if Im wrong, Nurbs can be converted to T-Splines and vice versa. With some development T-Splines should be able to have creases. Has anybody any insight on this? Which route is McNeel taking with their SubD approach? Polygon or T-Splines?
Found this and I think it looks really promisingā¦at 6:30 it gets pretty interesting, as they (seem to) combine Nurbs and SubD and even fillet their surfaces.
I really hope that McNeel will be an innovator with their SubD technology and not just put together something that Blender could do 10 years ago.
Imagine a SubD tool that can toggle between smooth and faceted, but also use creases, and additionally toggle crease fillets and edit radius size or change fillets to chordal fillets or G2 blendsā¦
The whole reason for Fusion 360s existence and its market share, is the fact that McNeel again were to blind to realize the potential of the original T-Splines PlugIn. So I hope they step up their game for V7!
What market share? I donāt know a single designer (I only hang out with good ones) that uses that tool.
I can make T-splines, and its current implementation in F360 crash with anything more complex than a coffee mug. Let alone that lately it fails to convert any polygonal model with medium complexity unless all faces are quads. And itās slower that molasses. I think McNeel is doing a lot better than that already from a topology and stability standpoint.
What you are saying is demonstrably incorrect.
I might be described as a Tsplines power user, in fact I purchased my first Rhino license for the express purpose of getting Tsplines into my work flow.
I describe Tsplines to my peers as a āpolysurface management toolā, allowing you to design and modify a joined collection of surfaces and let the software take care of the flow between them.
All of my projects involve some sort of smooth organic shape as the base body form, with some sort of mechanical āhard pointsā.
Now with grasshopper my work flow runs like this:
Define the hard points in the design
Create a Tspline of the body work
Write a grasshopper definition that Booleans the hard points with the body work.
Once the above is set up I can then modify either the hard points or tspline at will and get an updated model in seconds.
I currently use tsplines with V5 for most of my work and V6 for anything stand alone nurbs.
Tho I use Tsplines for 95% of my design work I actually do not like T points at all. I prefer to run full length loops rather than end them at T points. Under the hood Tsplines runs them full length anyway, and just hides them until you convert to a brep.
I also avoid triangle faces and try to keep to nurbs friendly four sided faces.
For now I my projects work fine in V5 and using a legacy plug in, but I will need a replacement solution in the future.
Must have tools for me from tsplines:
symmetry planes, I use up to 3 per model depending on the design.
point, line, face control with gumball
insert edge
extrude edge and extrude face
delete faces and bridge to create holes
thicken command for offsets (available in grasshopper a must)
I think thatās it for a min useable product. Once my current workload backs off Iāll install V7 WIP and see how SUBD is going. Hopefully it will be able to replace Tsplines for me.
Cheers
DK
Somewhat wrong, mostly correct. Thereās an accuracy issue, especially around star-points as far as I know. But even if you could convert a nurbs patch into a sub-d and back without issue (you almost can), that still doesnāt solve the problem with complicated trims. A nurbs trimming curve may be very detailed while the control-net of the surface is very simple. Sub-ds do not have trims so youād have to add a lot of control-net density around complex trims and creases. This makes the sub-d control net unmodifiable by hand.
Neither. Weāre implementing a limit-surface approach. Each face in the control-net becomes a single analytically accurate surface patch. Some more details are explained in the document posted waaaaay up in this discussion.
Weāre coming pretty late to this sub-d thing, so itās unlikely weāll start outperforming established packages any time soon. However our take on it is somewhat different from programs like Blender. Weāre more concerned with accuracy and fabricability than with organic modelling. If you want to model a face or a tree-trunk, Rhino probably isnāt the best choice, with or without sub-ds.
Hello Nathan
Yeah, I was afraid I might have been dreaming. I didnāt mean to imply it was said by someone from McNeal: just that it came up as a suggestion in a thread somewhere. Never mind.
The thing is, that in early design stages as far it comes to architecture or design - you donāt really care about precision. You care about doing things quick and effectively so you can present it to your customers and establish comunication.
Once things evolve and designs get more serious and are approved, then the NURBS-modeling process of Rhino is fine.
But in the beginning, when you think about different solutions and want to model and modify them quickly then the whole Mesh/sub-D thing is extremely important.
You want to quickly smooth, edit, add, distort without wasting too much time.
Modeling things precisely is important once a competition has been won, a client has approved and a company wants to produce an idea.
In my opinion Modo, Maya and Blender do this early process better and I donāt see why Rhino should not implement that capabilities asap. Espescially because it is a pain importing and exporting 3d-models between diffferent software packages.
My suggestion is that McNeel should take this topic extremely seriously.
You really should try the Mesh Utilities in the v7 WIP. It is a different process from Blender (trust me, Iāve modelled for quite some time in Blender), but it is shaping up quite nicely. These tools should work well with SubD eventually.
Hi, All ( not @nathanletwory in particular)
<rant>
Can anyone please confirm these are WIP commandnames to be changed for sure before release?
But since it would not be the first time that poorly though about commandnames end up in the release:
Most if not all of the above commandsnames are generic terms that can apply to any type of geometry.
There is for example already enough confusion about ExtrudeCrv and ExtrudeSrf.
At least name it ExtrudeMeshFace or something. Do not hold it off until later because it has proven to not happen.
You are creating a very powerful versatile new toolset with just the first handful of command already starting out ambiguous. Is someone at RMA responsible for the naming of the tools, doing a proper estimate of future expansion and of possible conflicts and ambiguities?
Does anyone even consider finally cleaning up the complete mesh toolset including toolbar organization and button design. Purging or fixing not working tools like the mesh booleans and intersections.
If the GUI aspects of this SubD endevour is going to be build upon the current implementation of mesh related features and command, itās starting of on a patched-up feeble foundation, unable to bear the load of the subD toolset that is -hopefully- going to be expanded into many more commands and features.
As for the commandnames:
A commandname as generic as Append can just as well be functioning like Join or BooleanUnion
Bevel is for chamfering solids right?
Bridge is to connect 2 curve ends right?
DuplicateFaces is like Extract with the copy option right?
InsertEdge, not sure what that does, something to split brep faces?
InsertPoint, but we have InsertControlPoint right?
I could go on but I assume the message to be clear:
Do not assume thing to be fixed at the end, keep in mind that command naming and GUI design is the fist thing users encounter when engaging is the new SubD features. Even for those only checking out the WIP progress every now and than. If that look and feel getās less love than the hard brain-crunching work the developers put in, you start off at a disadvantage for users will assume the features to be as āwippyā they appear looking at GUI aspects like naming, the lack of a toolbar and confusion about what is new.
Why not create a SubD toolbar tab in the WIP. Fill it with just text buttons if need be, but at least it expos it to those trying the WIP. It will be extra effort to update the toolbar before (each) release but at least itās development goes in sync with the expansion of the toolset and at the end itās already there. No need to fix stuff that was not foreseen or never thought of in the first place
</rant>
Note that this comes from a user -myself- who used to spend many hours exploring new features en enhancements. The last couple of years Iāve spend less and less time modeling and currently Iām almost exclusively programming with demanding goals set. This leaves me with almost no time to do that kind of exploration.
There must be many users like me with no extra time at hand to explore and discover. I think it wise to make this as accesible as possible. Most users do not even come here, those who do and actively search for new SubD commands are even fewer. If a regular user would open up the WIP on a late friday-afternoon, just to check it out, he or she should be welcomed with the latest new implemetations. Theyās see a new toolbar tab named SubD. Click it and find buttons with unknown tools. There would be a first button that fires up their browser showing preliminary tutorials on Rhinoās new SubD toolset ( made by RMA this is just an examle). Or link to documentation
I think with some effort to make stuff discoverable right from the WIP toolbars and not on a forum or elsewhere, much more user will be encouraged to try and test new features.
Thanks
-Willem
I started working on such a toolbar (see my post on Mesh Utilities in v7 WIP). I suppose we could already add the current one, even with my coder art icons in, and have @marika_almgren make nicer ones when she gets to itā¦
I leave it up to @Jussi_Aaltonen and others to give an opinion on the command names.