Project grid on multiple surfaces

Rhino Rhino for Windows
1

Hello!

Is there a way to project a grid of curves on multiple surfaces and group each set of projected curves with each individual surface?

-Thomas

2

Hi Thomas - Project and Group… there must be more to your question - do you want this to be somehow more automatic?

-Pascal

3

I guess he wants to know if the curves that land on each surface can be grouped individually with only the surface they land on… I think that’s only possible via scripting, but it should be do-able. --Mitch

4

Yep! That’s it.

We use reference lines to position and align the construction in the real world x,y,z.
These lines are marked on the plates, so I project a grid to 1000+ parts and eventually unroll these parts. When unrolling it saves a lot of work if the curves are grouped to the surfaces.

5

Here’s something you can try…

"""Projects curves to a set of surface objects and groups the result
of the projection on the object with the object itself
Script by Mitch Heynick 16.02.15"""
import rhinoscriptsyntax as rs

def ProjectGroupCurvesObjs():
    objs=rs.GetObjects("Select objects to project to",8+16,preselect=True)
    if not objs: return
    
    crvs=rs.GetObjects("Select curves to project",4)
    if not crvs: return
    
    plane=rs.ViewCPlane()
    rs.EnableRedraw(False)
    for obj in objs:
        proj=rs.ProjectCurveToSurface(crvs,obj,plane.Normal)
        if proj:
            proj.append(obj)
            group=rs.AddGroup()
            rs.AddObjectsToGroup(proj,group)
ProjectGroupCurvesObjs()
6

Ok, your officially too fast! :smile:

Two questions:
-The grid lines contain object names: eg. V1, V2, etc. with this script the names disappear. (like Keep properties)
-We project grid lines from top, front and left view (frames, waterlines and verticals). The first time it works perfect, but when projecting the next set of lines it should add the lines to the existing group

If it is possible to project all lines at once it would be better of course!
(also, some objects are positioned in such way that they contain duplicates after projecting… so one direction should be prior to the other)

An example is attached.

grid.3dm (2.2 MB)

7

OK, this is considerably more complicated…

Keeping object names is is easy to implement. Are you looking to keep any other properties of the original curves (layer, color, linetype, etc.)?

This is more difficult - what can be done is to create a group for each surface object and then keep adding any projected stuff to that group… But - any object may be in one or many groups. So if a surface object is in more than one group, how to determine which one is to be used by the script is not 100% clear. It might be necessary to concoct a special set of incrementally numbered group names.

If the file is organized in a certain way, it might be possible to project all at once - but as project needs a direction, there needs to be an exact correspondence between the curves to project and the intended projection vector - for example, a specific layer would have a specific direction. Otherwise, it’s better to stay semi-automatic and choose the appropriate direction for each set of curves. It’s nice to automate, but sometimes too much automation can kill the flexibility of a function.

If they are exact duplicates, possible eliminate them, but while projecting curves on a surface from 2 different directions may create curves that “look” the same on-screen, they will likely not be considered by Rhino to be “exact” duplicates. In that case some form of checking for near-duplicates via curve deviation will be necessary.

–Mitch

8

Thanks for the quick and comprehensive reply.

Yep, that would be great.

All the information for one part (surface) can by combined to one group, we don’t have surfaces in groups.
If it is easier to work with blocks, that´s also great.

The current grid is just a result of working manual. If we have lets say 3 blocks of the different grids somewhere on the server, and we can determine for each object which direction is perpendicular to the biggest boundingbox length of an obejct, it would be better. So the script pick just one grid (x,y or z). In this case we get rid of the duplicates.

In the end we just need the parts with reference lines and the corresponding annotation. How we get there is open for improvement, with you experience I suppose we get a better process path :smile: