@bob james said:

Any chance you could post that plugin?

Yes, but there are a few things that I want to check first.

If the two meshes are the same scale,ie grabed with the same zoom, the grids should be the same size and origin. Then you only need to delete the outer row/col in the overlap area as per John's procedure. I have successfully ran several test using John's procedure and the results is seamless.

No, you can avoid the torture if you like.

Maybe I've finally figured it out. By border, did you mean a border of a row/column of cells?

Apparently there are major differences between the Mac and Windows versions. There is no border, that I can find, that is left when the mesh is de-selected.

@driven said:

I've got a half done tutorial if your interested.

john

Please do because I'm missing something in the process.

Looks like I need to extend the faces vertically especially on the low side because, in yout test model, the bounding box of the mesh on the right surfaces momentarily on the mesh to the left which would result in some triangles along that edge not to be "cut" by the intersection.

Yes there are sometimes tiny usually vertical gaps because the meshes aren't exactly the same vertically or horizontally in the overlap areas.

It all depends on the order that it finds them in the model so the selection order doesn't matter.

Now that I know that order might be important, I will add an input so that the default order can be reversed.

@aceshigh said:

you did that manually?

No, with a plugin that I threw together last night. Check your PM inbox.

Here is how I did it. I created and grouped the four vertical faces surrounding the 1st terrain mesh using the bounding box corners. Then I did an intersect_with the faces and the 2nd terrain group and added the intersection entities to the entities of the 2nd terrain group. I then searched the entities of the 2nd terrain group for hidden edges that fell within the bounds of the 1st terrain group and deleted them.

I have given up trying to figure out why .start_operation/.commit_operation inclusion in my Bolt Maker plugin causes periodic bug splats. Even when that didn't happen, the undo capability was the same as if it wasn't included so no gain for the pain. The only commonality of the bug splats seemed to be that the first entity selected was a group with "Head Type:Cap" selected.

If you can figure it out, I would love to hear from you.

OOPS!!!! Sorry Bolt Maker fans. Dispite what I thought was adaquate testing, I found a problem while playing around with the plugin this morning. It has been corrected and a new copy posted.

TIG, Thanks for the info. As many times that I have searched through the Ruby API Document, I never saw that .add_instance could be applied to groups. It's always a good day when you learn something new.

CalypsoArt,

Stack away. Just posted update allows that and it drills holes through them all.

The bug splats and failures are caused by the usually benign start_operation statements.
I got a lot of those also until I removed them.

kybasche,

group_shell=model.active_entities.add_group()
ents=group_shell.entities
points_box=[[0,0,0],[5,0,0],[5,10,0],[0,10,0]]
      
face_box=ents.add_face(points_box)
face_box.pushpull(-20)
group_shell_copy=group_shell.copy#create a copy
tr=Geom;;Transformation.new([10,0,0])#copy location
group_shell_copy.transform! tr

In case you missed it, I posted an updated version yesterday that, if negative angular increment is entered, reverses the direction of the helix.

No there is currently no way to make it go the other way. I will take a look and see what I can do.

Is it just me or do you frequently have issues with start_operation and/or commit_operation. Recently I have been working on a plugin that after working without fail stopped working or bug splatted after I added a start_operation statement. Moving the start_operation statement up a few lines in the script allowed the script to run normally.

Is there a limit on the number of entity creations that can be undone with a single start/commit block?

Brodie, If I understand you correctly what you want to end up with is a beveled edge,ie inset 1" and raised 1". Is that correct? If so I think I have the solution.