Changing curve types on GH Planar to Non-Planar

Hi all, this is the first time I am posting here.

I wanted to know if its possible to change curve types on GH.I am linking curves from Rhino to GH and depending on the type I get a very different outcomes where some components don’t work.

For example, if I try to use any of the curve evaluation components when I have planar curves, I get the following error message:

  1. Parameter is outside the curve domain, results may be unpredictable.

How can I overcome this? Any feedback would be appreciated, thanks in advance!

The error message indicates that the Parameter (t) input to the Evaluate Curve component is outside the domain of the curve at the Curve (C) input.

Check the domain of your input curves compared to the Parameter (t) you’re inputting.

To correct, you’ll need to reparamaterize your curves and/or adjust the values at the Parameter (t) input.


1 Like

IF you need something related with a t value … THEN the safest way is to set the Domain(s):

crv.Domain = new Interval(0, 1);

And then use t >= 0, t <= 1.

Same with u/v values for Surfaces or UnderlyingSurfaces in BrepFaces:

srf.SetDomain(0, new Interval(0, 1)); // in U
srf.SetDomain(1, new Interval(0, 1)); // in V

where u,v > = 0, <= 1

PS: for BrepFaces containment use the BrepFace.IsPointOnFace(u,v) Method

1 Like

why is that the safest? Or in other words, what’s unsafe about working with the original parameters? I also wonder if there is something against setting all parameters to the 0-1 domain, or is it simply a mapping trick and nothing really changes?

1 Like

Indeed it’s just a handy mapping trick. Otherwise you must inquire the crv/surf and set/restrict t accordingly.

if(t < crv.Domain.T0) {t = crv.Domain.T0; Print(“blah, blah…”);}
if(t > crv.Domain.T1) {t = crv.Domain.T1; Print(“blah, blah…”);}
result = crv.PointAt(t); [ or crv.TangentAt(t) or crv.SomethingAt(t); ]

Now … imagine having N crvs on hand. What should be the slider(s) min/max values? Or use 0-1 and do the Remap …

… which brings us back to the future (or forward to the past).

Moral: obvious


It makes me wonder: If there are no downsides to remapping, why curves and surfaces aren’t remapped automatically always then… what is the purpose of a -13.7878 to 122.3123 domain anyways? Can you think of a case where a remap is not wanted?

1 Like

Any div (points, pieces, cats, dogs etc) related task does NOT need/require any remap.

Oops! forgot to attach the thing: (142.9 KB)

BTW: take the challenge: (a) Add Face List support (meaning 2 dim Trees), (b) mastermind a “proportional” (on per Face Domain basis) U/V division policy AND (c) write something that yields various patterns (Pieces, Polylines, cats, dogs etc etc).


Hi Gijs,

Most commands try to set the domains so that it corresponds to size of the objects. The domain is just an additional information which might be useful in some cases.

Just a simple example: With a circle of radius=1 the domain ranges from 0 to 2*PI. If this circle is split then it is easy to recognize the original segment’s order/positions by the domains. If all segments would range from 0 to 1 it could be a nightmare.

There are also some methods in Rhino Common which work with “normalized” parameter space (0-1).

Also I seem to remember that some objects caused problems by simply reparametrizing it. Don’t know what it was exactly or if this “bug” has been fixed meanwhile.



Now that you say so, I also vaguely remember that…

1 Like