Closing trimmed voronoi curves?

I've (along with a colleague) created a fairly rudimentary city building voronoi command, that populates a given region with a random scattering of points, and from those points creates a voronoi which is then in turn trimmed using the region inputted at the start.

At this stage everything works smoothly (picture 1). Using these curves I then want to offset to create a road network, offset once more to create a building depth and then loft to create the final building.

Unfortunately the voronoi curves along the edges are open curves from where they were trimmed, and as a result the offset fails to work correctly (not suprisingly) but I can't seem to find a method to close up the curves using the bounding area to close them? I've tried region difference/union/intersection as well as join curves to no avail.

At this point the only thing I can think of is to avoid the trim, check where the curves intersect and create points and then use those points to create a line and close the outer curves in that way, although that would ruin the curvature of the region.

Any suggestions?

Attachments:

did_voronoi_picture1.jpg, 338 KB

Replies to This Discussion

Permalink Reply by Luis Fraguada on January 7, 2010 at 6:12am

can't you trim the bounding area with the trimmed voronoi cells? You can test to see if the curve is closed and if its not, then try to intersect with the bounding cell to get the necessary segment...

Permalink Reply by Daniel Illum-Davis on January 7, 2010 at 6:19am

Trimming the bounding area with the Voronoi cells just results in getting the same bounding area back again. If there was a way to split a surface up perhaps then I could create a surface from the bounding cells, split it using the voronoi and left with the cells I require.

I'll try the checking if closed and intersect method now. I would be nice if the voronoi bounding box component would accept various shapes rather than just a simplified box representation of the curve you select, and use it to create closed cells.

Permalink Reply by David Rutten on January 8, 2010 at 4:31am

Hi Daniel,

"I would be nice if the voronoi bounding box component would accept various shapes".

The Voronoi solver has been highly optimised, and at present it can only deal with convex polygons. I'll add another component which allows you to supply a curve, and then I'll use the convex hull of the curve control points as the boundary. Would that work?

--
David Rutten
david@mcneel.com
Poprad, Slovakia

Permalink Reply by Daniel Illum-Davis on January 7, 2010 at 7:11am

Had limited success with region intersection. In the end it it did leave me with a series of joined curves (as far as I could tell), BUT it was taking 56,000ms to calculate the intersects, so thats obviously not ideal. May end up baking the basic curves, manually joining them in Rhino and then using grasshopper for the offsets and extrudes/lofts.

Permalink Reply by Mattias Eriksson on January 8, 2010 at 2:33am

Hmm liked the problem and had a stab at it. As far as I can tell this works pretty well. What it does is trimming the region by the voronoi; trimming the voronoi by the region and then joining them after weeding out all the empty trees (i.e. cells outside the region and so..)

/Cheers

Attachments:

ForumVoroniod_0057.ghx, 116 KB

Permalink Reply by len tak on May 15, 2017 at 5:14am

thanks mattias, this works like charm, and it is extremely fast compared to generating boundary surfaces for region intersect that i've have been using before.

Permalink Reply by David Rutten on January 8, 2010 at 4:33am

Region Boolean operations are ultra slow. Basically it converts all curves to trimmed BReps, then performs a sort of solid boolean on the BReps, then extracts the edges again.

Yesterday I started writing a set of functions that operate directly on 2D curves and which should be somewhat faster. This is not trivial stuff to write, so I doubt the new functions will be quite as foolproof as the old ones, but they should be faster.

--
David Rutten
david@mcneel.com
Poprad, Slovakia

Permalink Reply by Daniel Illum-Davis on January 12, 2010 at 5:59am

David,

"The Voronoi solver has been highly optimised, and at present it can only deal with convex polygons. I'll add another component which allows you to supply a curve, and then I'll use the convex hull of the curve control points as the boundary. Would that work?"

It may do, although trimming by region works just as well, it was more trying to simplfy the steps required to fit a voronoi curve to a region.

The main 'problem' were the cells lying on the region boundaries and being unable to make them intersect/work with the region that trimmed them (with ease) in order to create closed curves, hence the suggestion that the boundary component could use curves and negate the extra commands I'm using now. Unfortunately in 3D modeling/rendering/et al there's never going to be that magic button that does all the hard work for us.

Mattias, thank you very much for that solution. Thanks to some nasty little virus I managed to infect the PC at work with I'm having to reinstall all my software and get back on schedule, so hence the late reply. I'll give your solution a go once I get back up and running, but looking at the pictures it seems to do exactly as I wanted.

Permalink Reply by Daniel Illum-Davis on January 12, 2010 at 7:31am

Just tested your solution mattias and it's rather wonderful. The only issue I've had is grasshopper's(seemingly?) reluctance to trim/cull reliably with lots of curves at once (as in, some of my curves remain blank rather than having a nice trimmed voronoi in them). I had the same issue with multiple curves so I'm certain its that rather than your solution.

I'm not sure if its purely a question of size, number of curves or what, but has anyone had some experience with solving this?

Permalink Reply by Mattias Eriksson on January 14, 2010 at 2:08am

Well, I'm not sure if there is a problem since I haven't experienced any of them. But it is to be expected that some of the paths are empty or even contain multiple cells.

1. If a cell lie entirely outside the trimming region it will be empty since the TrimREgion command will return a null-result and the definition cleans away empty branches with the Clean(Clean Datatree) component.

2. A branch will contain multiple cells if the region somehow turns back into the cell and splits it in two. The same path index will contain double "cells", so if you are somehow accessing the branches and only using the first cell you will be the other "half" of a split cell.

This could easily be fixed by flattening the data, and (if you want a datatree rather than a list) remap them. Hope it helps.. a little..

Permalink Reply by Rafael Martin on January 19, 2010 at 9:43am

Hey guys,

I'm just having same problem.
Couldn't with any of yours tips resolve my problem.
My voronoi, when offset, still breaking curves.
Try everything that I've found here, with no success.
Hope it's a bug, and will be fixed soon.

R.

Attachments:

Untitled-1.jpg, 823 KB

Permalink Reply by Mattias Eriksson on January 28, 2010 at 6:06pm

Ah, now I get it. Sorry for the late reply but I've been on holidays surfing =). Doesn't seem like it is a problem with the code per se, but rather a conflict with how offseting works.

When you shrink a closed polycurve with the offset command it seem natural that there is a limit where the new polycurve would turn into a point = at the centre of the area. Since the function offsets all curves from their initial position with a distance it is possible to offset curves beyond this point, then the offset command wouln't be able to keep the lines joined. Unfortunately the command always seem to fail well before this point, and I have no clue to as why that is.

Easiest fix is to avoid small edge cells... or just cull all bad ones and give them some special treatment, they are probably to small to contain a building anyway.

You should be fine as long as the offset is a small part of the distance to the cell centrum, although there seem to be a problem when the start/end point of a closed curve is excluded as a result of an offset, due to the line it belongs to being too short.