Hi SP,
when you supply the points for a surface, you have to supply them in
ordered row/column order. Thus, if you have a surface with 3 rows and
4 columns, your points must be in:
{0,0}, {0,1}, {0,2}, {0,3}, {1,0}, {1,1}, {1,2}, {1,3}, {2,0}, {2,1},
{2,2}, {2,3}
Then, the number that tells the component how many points there are in
the U direction is either 3 or 4 (try both, see which one gives you
garbage, then pick the other). If your counts are 1 off, the whole
thing won't work. Have you actually counted your lines? If your lines
are the result of a curve or surface division, note that divisions are
specified by number of STEPS, which means that the number of POINTS
you get is usually Steps+1.
--
David Rutten
Robert McNeel & Associates.
On Sep 30, 8:54 am, SP <[EMAIL PROTECTED]> wrote:
> Hi have just begun dabbling in Grasshopper
> and have been trying to generate a surface that
> comes from grid points that are actually line ends
> The length of the lines are contingent on distances from a prescribed
> point.
> The goal is that moving the point would change line lengths
> and correspondingly alter the surface.
>
> Have gotten to a point where the SrfGrid node picks up the line ends
> for point input.
> But feeding in any integers for U values creates runtime errors and
> ofcourse
> no surfaces are generated at all.
>
> I would be grateful if someone could help with this bottleneck and
> apologies
> if i missed a solution similar to my prob. in the earlier posts.
>
> Thanks.
