Could someone explain to me what is wrong?
Is this a bug or I made a mistake?
For me both results are wrong. t (parameter). If t=1 point should be at the end of the curve.
BTW, for some reason t also accepts negative values and values above the length of the curve. The component becomes orange but the point continues to follow an imaginary curve.
I think you forgot to reparameterize “C” input.
Where does it say the input should be pre-processed anyhow?
Perhaps reparameterization wasn’t properly done by GH
Thanks @HS_Kim, it does work this way.
There is @DavidRutten 's blog post with a detailed description of the Curve domain.
When creating a virtual component Evaluate curve, how can I reparameterize?
from Rhino.Geometry as rg
crv need to be of type Curve
I create both curves (in Rhino and GH) with the same definition. how could the parameters be different?
Another thing is in this article. t=0 is always start of the curve, and t=1 is always full length of the curve.
true for Bezier, false for Nurbs.
Nurbs can consist of many subcurves. The parameterization is up to knotvector, and is arbitary. Usually domains in Rhino are close to the curves length. The spacing between the knots is important not the number.
furthermore curves have no real end. The domain usually expresses the visible part
Ok, but both nurbs both same approach when creating them, by control points degree 3, 5 control points in Rhino and GH give different curves (knotvector-wise). This is inconsistency and it causes problems with you start using these curves.
mhh. Grasshopper has no own implementation. Its Rhinocommon. The domain is up the command if you do not feed a knotvector. There are differences which makes sense, but its not obvious from outside and its definitely not trivial. Its no inconsistency, the topic is just more difficult as you might expect.
I agree it’s not apparent and not easy topic. But if you create the same thing in RH and GH the result should be the same and it is not.
I usually stay away from evaluate curve or PointAt unless you reparam first or you obtained the t value from something like closest point. Better to use normalized length. Use the .PointAtNormalizedLength method. For start or end use .PointAtStart and .PointAtEnd. Also note doing something like .5 on a reparamed curve will not necessarily be the mid point when using evaluate parameter - it will be the middle of the knot vector. .5 on normalized length will be the actual middle of the curve. (There is an evaluate length component that demonstrates normalized length).
I am doing the same, but GH and RH apparently have different methods of creating the curve. Giving different values for the knotvectors and this is inconsistency.
i recently switched to use domain.min and domain.max for endpoints
don’t know, no system is perfect. If you know about it yet, this may prevent further issues.
This might be the way to go in my case:
Yes I have two different cases one with Nurb curves and one with Nurbs surface that GH and RH produce different default values for the KnotVectors and the difference especially in the surface is huge.
you might use Ilspy to read how gh and rc is doing it and you can download opennurbs, find the invocation from rc in it. So basically its all open source…