Grasshopper

algorithmic modeling for Rhino

Newbie query: illustrator file as clipping surface

This may be a rhino not a GH question...

I would like to be able to make trims in surfaces I am modelling using illustrator images

The attached illustrator file is an example. Illustrator recognises nested curves as interior or exterior to a surface and fills accordingly. So the image looks fine as an .ai or .pdf file.

However, rhino sees only the vector paths, not any fill surfaces.

Is there a way in GH to efficiently determine which polylines are nested and hence represent surface "holes"?

Clearly an exhaustive region test is possible but I suspect doing this with the graphic dataflow is going to be awkward and slow; I feel some VB coming on...

Am I missing something? Surely this cannot be such an uncommon need... I'd love to know if this has been elegantly addressed by others before rolling up the sleeves.


Advice appreciated.

Rod

Views: 1425

Attachments:

Replies to This Discussion

Hi Rod,

that's a pretty complicated set of outlines. If you import all those curves as individual objects and run the _PlanarSrf command, does that not give you the result you're after? It will probably fail if the outlines are intersecting, but I think PlanarSrf is supposed to work on curves like these.

--

David Rutten

david@mcneel.com

Poprad, Slovakia

Thank you so much for replying David; I will try this with some "cleaned" illustrator outputs. Illustrator outputs are however topologically "naughty" in that they often have self-intersecting interior loops. Cleaning these out manually will be a real pain.

OT I see you making very wide contributions in the forum. Kudos to you and the rest of the mcneel team for an epically elegant product. I've used a wide range of other 3D products for engineering technical and animation purposes but for some reason never looked seriously at rhino. With a couple of 3D and 2D fabrication projects in mind I came across GH for generative geometry and of course it's host, rhino3D. Wow, both perform at the highest level with GH unlocking interactive scripting in a way that is simply beautiful. Rhino shader GPU leverage is also well done. Both rhino and GH could benefit from some broader multithreading leverage; though I well understand a point you have made elsewhere that internal data structure instanciation makes this a little challenging. But there are ways to code around this (painfully); or just throw memory at it... I cannot be alone in running 32GB of 2133DDR3 - and it's painful to be waiting around with just one 4.2GHz core utilised while another 11 idle.

However, my credit card got a workout an hour after discovering the rhino/GH combo and I've no regrets. I've not had so much fun since Mathematica was released.

Its some decades since i worked with a dataflow language, so I was most pleased to find the essential tree data path management tools were comprehensive and effective if sometimes cumbersome. Your rate of innovation seems phenomenal; the new fields components are most intriguing. So much creative capability! This is a most exciting complement to my toolset and one I'm looking to put to serious work in the coming weeks.

Cheers. Rod

As long as the length of the loops is smaller than the length of any valid segment, you can use the attached file to automatically remove loops with a length less than 'x' units. This algorithm can probably be made smarter by also looking at whether segments are closed or not.

--

David Rutten

david@mcneel.com

Poprad, Slovakia

Attachments:

Thanks David - I'll give it a whirl...

I've found that the best way to get live-trace regions into Rhino is by exporting from Illustrator as a DWG rather than trying to open the AI directly. This will preserve the "holes" you describe. Once you get the filled regions into Rhino as Hatches, select all the hatches and choose "explode" to convert them all to trimmed planar surfaces.

You may also find that certain hatches fail to export; this is usually the result of the same kinds of self-intersecting loop problems you described above. If you convert your live trace to a live paint, then fill in the trouble regions with a slightly different color before export, in my experience almost all of these regions can be coerced into being less "naughty."

One last thing - you may find the command "CurveBoolean" to be a very helpful tool in selecting the regions that you want to be filled. 

Here's my stab at your file. Here's what I did:

1. run live-paint on your curves, filling in all black regions with a new color one by one

2. expand live paint, and delete all white-filled regions

3. export the file as a DWG with "maximum editability"

4. export the same file as a JPG or other image format

5. import the DWG into rhino

6. import the image into rhino as a pictureframe to use as an underlay

7. select all the curves

8. use the Hatch Command with "Boundary" enabled

9. Pick points in the drawing where there should be a hatch but isn't, using the image as reference

10. Complete the command, and explode all hatches.

If you needed the white regions as surfaces two, I'd recommend exporting them separately and using a similar process. Having duplicate outlines (one bounding the white, one bounding the black) throws off Rhino's curve boolean processing, which is used for the hatch command as well as the Planar Surface command in some instances.

Attachments:

Firstly David; wow! Getting up this morning and finding such a comprehensive response was waaay beyond my expectations. Thank you.


After my initial post I indeed twigged to the DWG export as a means to set up better initial surface logic, though this clearly was not eliminating self-intersects. Your algorithm looks good. I'll think about what is needed to automate the "error loop" findi / rectify in GH.

Clearly, careful image treatment in photoshop / illustrator goes a long way to ensuring there are not tiny loops that are particularly troublesome and managing the number of curves with closely located acute angles which are often the cause of self intersections. While I would have thought ensuring curves are bigger than a given minimum length would stop self intersection, it turns out the illustrator algorithm can create self intersections even on large geometries if there are objects relatively close to one another. The algorithm creates paths from object to object and self intersection is a common result.

So....  Your method gives a clean product - manually. and I am VERY grateful for that at least.

cheers

Rod

This takes a combination of your ideas and tries to automate some of the curve cleaning. Both in DWG and AI formats, illustrator scribes duplicate paths - many with realy very tiny self intersection glitches. Reconstructing as many non-duplicate, non-self-intersecting curves as possible is something GH can do - and I've attached a GH script to do this. There's still a lot of manual crufting since more complex illustrator files can have many improper path overlaps can mess up proper surface generation. But this at least makes a start.

Obviously, the cleaner the illustrator file to start the better....

Attachments:

RSS

About

Translate

Search

© 2024   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service