> Why is it that the BRep analysis component doesn't provide uv coordinates???
This is probably because a brep as a whole doesn't have its own uv coordinates (there no unique (1,5) uv coordinate for a brep) , it's made out of several surfaces, each with it's own uv coordinates. > My problem now is that it works great for one curve, but as > soon as I load the whole collection it freaks out and is only able to > select one surface for the whole collection. I'm guessing this is a data matching issue. If you've got a brep made out of 4 surfaces and a list of 10 curves, the first curve will be projected to the first surface, the second curve to the second surface, and so on, until you reach 4, then the 5th to 8 curves will be projected to the last (4th) surface. A workaround I'm thinking of (i don't know if it would work) is to use "cross-reference" and project all curves to all surfaces, then use the distance output to filter out unwanted points. If the distance is greater than 0.001 (or any other small number but greater than 0) then filter those points. If this workaround works i think that will solve the rest of the problems you mentioned. But if you really need lists within lists, hopefully in a couple of weeks max we will have this available in the next version of GH (this is not official of course, it's just a personal guess from the info released about the development of the plugin). On Jan 30, 12:22 am, Marc Syp <[email protected]> wrote: > Visose, > > Thanks for the tips... also regarding the preview shortcut. Very > nice. > > I've got it working fabulously for surfaces now. My next challenge is > to get it working with BReps as well. Some of my "surfaces" are > actually polysurfaces, and I'd rather not have to set my collection of > curves separately for each surface that makes up the BRep. Why is it > that the BRep analysis component doesn't provide uv coordinates??? > > As a workaround, I started developing a patch that explodes the BRep > and then analyzes the distance of the sample point to each component > surface, then selects the correct surface uv point for orientation > purposes. My problem now is that it works great for one curve, but as > soon as I load the whole collection it freaks out and is only able to > select one surface for the whole collection. Obviously this is no > better than exploding a BRep and feeding it through my original patch > (also not working). I would like it to analyze each point > individually as if in a discrete loop, but I think I'm having a > problem of list lengths and redundant values, or in the structure of > the patch itself. Any chance you can take a look and give me some > leads on how to pursue the logic of this one? > > The patches: > > http://grasshopper3d.googlegroups.com/web/Tornado-extruder.3dm?gda=cu... > > http://grasshopper3d.googlegroups.com/web/Khing-tornado-extruder2.ghx... > > Thanks in advance. > > Marc > > On Jan 28, 9:24 pm, visose <[email protected]> wrote: > > > Hi, > > The problem is that the uv input of the "Evaluate Surface" component > > is being fed by 3d points. Instead of using the "Brep CP" component, > > use the "Surface CP" component. This component has an extra output > > with the uv coordinates you need. Link this output with the uv input > > of the evaluate surface component. Besides, you don't need the "plane > > normal" component. The F (frame) output of the "evaluate surface" > > component is already a plane. > > > Since you've got many planes/points overlapping, I would also disable > > the preview of all the components (select all and press ctrl-shift-q) > > and from there enable the preview individually when you are working on > > them.
