Some edge from SubDEdge.ToNurbsCurve() method return null after editing the SubD.
For grasshopper, re-executing the code some time after the SubD is triggered find the edges “fixed”, like it needs some time delay after SubD edit before all edges are ready to be casted to nurbs curves.
@dale can you replicate this?
Any idea how to reliably extract SubD edges (ToNurbsCurve) in rhinocommon?
To who should I ask?
And… I’m doing all this because there are no methods to get SubD normals at surface points (control polygon mesh normals are too different), so combining the initial tangent of many edges would at least let me recalculate the normal…
Then, I’ll also use the curves themselves.
SubD rhinocommon methods are stil far behind…
I somehow still hope some change will came to Rhino 8… but I am probably wrong, am I?
Will some change come with 9? 10?
I can repeat this. The problem is localized to Grasshopper, as this simple Python script works as expected.
import Rhino
import scriptcontext as sc
def test_riccardo():
filter = Rhino.DocObjects.ObjectType.SubD
rc, objref = Rhino.Input.RhinoGet.GetOneObject("Select subd", False, filter)
if not objref or rc != Rhino.Commands.Result.Success:
return
subd = objref.SubD()
if not subd:
return
for edge in subd.Edges:
curve = edge.ToNurbsCurve(True)
if curve:
t_vals = curve.DivideByCount(10, True)
[sc.doc.Objects.AddPoint(curve.PointAt(t)) for t in t_vals]
else:
Rhino.RhinoApp.WriteLine(edge.Id.ToString())
sc.doc.Views.Redraw()
if __name__ == "__main__":
test_riccardo()
I have not had time to dig into this. But I’ve logged the issue so we can investigate.
I’m used to the GREAT accessibility McNeel gave to users/developers to a wide set of classes and methods to virtually do anything with c#. Everything’s perfect!
Everything but SubD’s. As said here.
SubD normals? (as said, I’m extracting edge curves becase no avail normals… )
SubD parameter + EvaluateAt?
SubD.Faces.Add?
SubD ToNurbs custom packing?
Still no iterator for SubD.Vertices. (looping .Next for thousand of vertices is slow)
GH Pointdeform sill has no idea what is a SubD.
an so on…
Maybe the situation via c++ is totally different, but from c# the difference of SubD methods from the rest of rhino libraries is huge. … like, done by someone else with different “motivation”…
I feel like the only idiot screaming at a wall trying to make up stuff around SubD.
There are any plugins for more editing tools for Rhino SubD? Any kind of tool. Edit. Freeform, etc…
Are those made with c++ or c#?
SubDs are not parametric surfaces, so evaluation functions like PointAt(s,t), NormalAt(s,t), etc. make no sense and will never exist. That said, are you looking to do?
I’ll need some clarification on this - thanks.
I’ve logged the request; not sure this will be any faster than walking the linked list.
new methods are limited to “ControlNet” stuff, aka the equivalent mesh, which I wouldn’t like to use but at least it could be a workaround, but it isn’t.
it’s limited to the center of the face.
What I currently need are the normals at surface or “LimitSurface” points, like:
To build anything real-time, passing through ToBrep is a no-go, and that would also lose all topology structure (which brep vertex is the corrispective of which subD vertex? pure hell)
This again is why I’ll use limit surface edges for each vertex to “guess” the local normal.
Yes, a BAD workaround.
Edges around a vertex are not sorted! So the re-calculated normal will be randomly flipped!
Any better idea? Please give advice…
I can imagine many uses of some methods like .EvaluateAt(t) or .NormalAt(t) … (with t being a class containing face ID + a set of doubles to define the internal location, similarly to UV for surfaces).
“make no sense and will never exist” … that’s a bad mindset, sorry… please … try a more flexible approach.
SubD outclassed Tsplines in many aspects (but not everything). Can Rhino and its SubD methods stop and pretend the competition will do the same? No.
Imho competitors will have internal or public methods for stuff like those EvaluateAt/NormalAt. If not today, tomorrow for sure.
Why we have Evaluate and NormalAt for surfaces?
… for the same reason we should have those methods for SubD and even for Breps!
I’m sure I’ve asked this before, and not only me.
This is related to “_SetPerFaceColorByFacePack” and “_PackSubDFaces” commands.
See:
Editing a SubD will result in a different “packing” of the faces. But that often “reorganize” the Brep topology radically, making it very troublesome to correct a project where I want to add a little edit to a big SubD shape that is later edited a lot with booleans and fillets.
If the SubD is a body:
“You added/removed a small detail near the nose? That’s too bad, all packed surfaces up to the feet now are different! Have fun!”
The image above is not a good example, but believe me, sometime a small edit result in a mess in the re-topologized brep.
I actually never use PerFaceColors , because it is a passive arbitrary information… I still have to do the design I need, whatever the packing is…
See the right object with the black band: if manual user per-face color was used in the packing, I would setup some “buffer” areas to limit this problem by a lot!
Or another solution. But please understand the problem and think about something.
(Creasing is not a solution…)
Thanks!
Yes, that’s the reason why I’m asking it: .Next IS slow.
We are working on “closest point” for SubDs. You should see this sometime in 8.x. I’m not sure what input will be - most likely something similar to what you describe.
Yes. And from your image, it looks like packing is working as expected. I understand the downstream issue.
From what I understand, @pierrec will be filling out the SubD classes in RhinoCommon. Perhaps he can comment on this one.
)
