algorithmic modeling for Rhino
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
Tags:
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
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
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.
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....
Welcome to
Grasshopper
Added by Parametric House 0 Comments 0 Likes
Added by Parametric House 0 Comments 0 Likes
Added by Parametric House 0 Comments 0 Likes
Added by Parametric House 0 Comments 0 Likes
Added by Parametric House 0 Comments 0 Likes
© 2024 Created by Scott Davidson. Powered by