Grasshopper

algorithmic modeling for Rhino

Perp Frames Parameter Values vs. Divide Curve Parameter Values

Hi all,

I have noticed a discrepancy between the 't' parameter on curve perpendicular frame parameters and divide curve parameters and was wondering what is the cause of this? Even though you can read both parameters for the divide and perpendicular frames have the same values, the frames seem to flip from one end to the other end of the curve not really following the curve linearly.


t = 0


t = 1


Any one had this problem?

Thanks

Guima.

Views: 2450

Replies to This Discussion

Guima,

Your example is a little confusing. You're talking about the behavior of a single curve but displaying 2 curves.

You might want to investigate the "Reparameterize" toggle (Right-click on the "C" input of the Perp Frames, for example). Selecting "Reparameterize" will reset the domain range of the curve from 0 to 1.

-taz
As input must be selected curve with domain <0,1> (right click on curve -> reparametrize) else is this t=1 mean like distance from start point of curve.
Apologies I have found where I was getting a glitch. It is not on the parameters from both 'perp frame' and 'divisions'. To make it clear the images above as taz noted that they are confusing. What I am doing is the following:

- Above a rhino created curve (the 'U-Shaped' planar curve showed on the digrams) I am generating a cosino based curve that varies above and below the original curve on the Z axis waving along.

- The cosino curve is based on divisions (10) from the original one so if you look in plan (top view) they are not really coincident, where I have the corners from the original curve there is a deflection from the cosino curve.

- In order to fix this I have divided the original curve (lets say 100) and created planes perpendicular to the original curve. From the planes I have created rectangles that then generated surfaces. From these surfaces I have intersected with the cosino curve to gather Z coordinates in order to create a new cosino curve that would lay perfectly above the original curve.

That might not be a crystal clear description easy to read BUT THE POINT is that the glich is not on the parameters stated on the title and is on the SURFACES (using planar surfaces). They do not come in the same order as the rectangles, most problably I can fix that with a script? So I will do that no worries although, IS THAT A BUG? Surfaces from planar curves not following the original array sequence of curves? Image attached.

Many thanks from your replies, I can move on from now and fix it.

Should I delete this topic?

Guima.
Attachments:

RSS

About

Translate

Search

Videos

  • Add Videos
  • View All

© 2024   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service