It is true, there are points outside the Voronoi geometry. While I can't say for certain, I think it's because that some or all of the cell planes associated with those points are completely unbounded, so the script has no way of representing them as faces.

I used Selection(free) on all the previous examples. Selection (Bounding Box) was an attempt to reduce the number of unbounded points by adding "invisible" points at all the bounding box corners. In general, it doesn't really work.

All the points are construction points, yes.

I would like to see better 'enforced' bounding, absolutely. And I suspect that it's probably possible, but probably requires a lot more math than I've got in there now.

For dealing with "old" data, I suspect the script could be updated to actually delete the 'results' file where the Qhull output is placed before every run.

As for why you aren't getting results with your LSystem data, I'm not sure. If you want to post a scene I can take a look at it. If it's a ruby issue, I'll try to do something about it. If it's something inside Qhull, there won't really be much I can do.

I've tested the construction points grouped and it works just fine. I think your problem is that your points are too regular or all on one plane. I don't know why that causes a failure, it just does.

However, as far as creating what you call 'cracked' surface, the basic answer is that's not how voronoi is being represented here. Voronoi is a mathematical representation in which each barrier is equidistant from its nearest points, giving the telltale cobblestone appearance. What you are missing, however, is that along the boundaries of your sample area the cells are undefined. In all the images you see, the cells are just clipped off in a nice rectangular boundary. A similar method could be done in 3D (like the youtube video), but in this case, it's not. I'm not 100% on the math here, to be honest, but what I think is happening is the cell boundaries are being evaluated out until they "close" naturally, resulting often in long spikes. If you delete those spikes on a simple example, you will see that the cell boundaries do, in fact, lay equidistant between nearest neighbors.

The problem, I think, is that you are expecting it to look like a 2d cobblestone image, but the 3D representation just doesn't work that way without the artificial boundaries.

Here is a very simple collection of points from which I generated a convex hull, delauney (which appears to connect nearest neighbors), and voronoi. They all worked.

Just to clarify in your above examples, you say you used Convex->Large(100) and it didn't match your selection. As clearly stated, Large(100) creates 100 random points, and has no correlation what so ever to your selection. Only the choices with "Selection" in them use the selected items in any way.

Also, if Qhull (the 3rd party exe) fails, the script might use old data to generate the shape, which is why, despite the message, you may see a shape created.

voronoi_demo.skp

There will most likely be some performance hit, but it's not likely to be significant. My personal opinion is that if it is reasonable to code the appropriate "if" conditions (like version number), you are better off doing that. For a simple issue like this, probably irrelevant; for more complex code, you'll want to be more careful.

Can you post a small example scene?

Very "regular" results, like a cube, a sphere, all geometry in a single plane, usually won't generate valid results. It's just how the mathematics work.

Found it. pushing the middle mouse button invokes the orbit tool. But it also suspends and resumes the currently active tool. By handling the resume method and calling view.invalidate, I can force it to redraw the screen every time the orbit tool finishes and returns to the drawing tool.

I'm trying to make a tool that draws 2d shapes (view.draw2d).

def Draw(view)
    view.draw2d(GL_LINE_STRIP, [Geom;;Point3d.new(1,1,1), Geom;;Point3d.new(500, 0, 0), Geom;;Point3d.new(500, 500, 0)])
puts "update"
end

super simple, just to demo. It works, but it doesn't always work. When I orbit the view, there are times, often actually, where the lines are not drawn and the "update" message is not posted. Does anyone have any suggestions, tips, ideas? It didn't seem like there were to many tools out there using draw2d.

I've played around with getExtents, but what I put in there doesn't seem to make a difference. It probably only effects 3D drawing?

I'm not really familiar with "memory mapped" files, but I can imagine more or less what it is.
You will probably need a ruby script in SU that polls the memory to detect changes, and then control the geometry when there is a change. In order to poll the memory, you'll need a thread or a timer. However, from what I've seen, threads and timers don't work well, or at all, in SU. They tend to start out ok but stop after a very short period of time. So I think the biggest hurdle is to figure out how to poll the memory inside SU.

That's definitely good info, especially the model.edit_transform command, and helps explain the weird behavior when a component is open, but that's not really the issue.
Assuming no components are open or selected or anything, given the above configuration of multiple instances of a component with an image in it, the image commands (origin, normal) return different information for each instance, but only with certain models. (This is using a ruby script to gather up all the image info, not done manually) I'm accumulating the transforms down through the hierarchy just fine. If the image was a face instead, it works without problem, so it's not the model hierarchy transforms. It's the last bit, the image.
I guess it's kind of silly to look for an answer without really understanding what all the influencing factors are. At least now I know that SU modifies the transformation when a component is open; I didn't know that before, so thanks for that! Maybe if I can consistently create the circumstances, I'll post a scene and a ruby script to demonstrate what I'm getting at. Thanks!

Oh, I am, most definitely. The issue is that the transformation created for the Image is inconsistent. If I have 10 instances of the same component with the same image in it, each one might give me a different result when asked for it's origin. But it shouldn't right? Because it's inside the parent component, and because I'll be multiplying in the parent components transform, the image should have the same origin, normal, and zrotation for all the instances. But sometimes it doesn't. (And I can't figure out the difference from the times it does work and the times it doesn't)

And maybe related to that, as posted above, when you actually have a component open, the results are different than when you don't. I suppose there's no magic bullet until I can figure out what's different for the images that don't work...

That seems to be the issue. Like what I said in my first post, for some reason the point returned from the 'origin' method isn't consistent when it's inside a component, nor is the 'normal' method. Since those two, at least, are necessary to create the transform matrix of the image relative to it's container, in this case the component, then I can never get a correct transformation.

And it doesn't always happen. With some components, it works just fine, other times not.

Hm... it looks like using your code didn't solve my problem. Are you familiar with the trees from tomsdesk? The leaves are images, contained in a component, and that component is set to face-me. The issue is not so much getting the correct transform for an image, but getting a correct transform when the image is contained in a component.

Hi Alex, thanks for the link. Looking at your code, you are doing just about the exact same thing I'm doing except your scaling by width/pixelwidth, height/pixelheight. I'm not doing that, I'm just using width and height. I'll definitely try it out!

Hmm... that's promising. Maybe there's a more reliable way coming in from that direction...

Images have definitions?! That actually may help a lot... I'll have to take a look. Is this an unpublished method to retrieve it, or just one I've overlooked?

Oh, really? Huh, I always thought that, for normal geometry, it was always relative to the 'container' it's in. Of course that may depend on the commands you use. There may be some commands that return 'world frame' coordinates and some that return 'local frame' coordinates. Unfortunately, for images the commands are sparse.

But it doesn't look like the image.origin and image.normal methods are returning world frame coordinates or local frame. I'll check again and pay closer attention, but they seem to be relative to some "original configuration" of the image (which of course isn't available).

@ thomthom: I've noticed this exact same thing. I've never looked at it for faces, but images have the exact same behavior. Faces have the 'mesh' command which seems to produce the correct coordinates, normals, etc. But images don't have that.

Sorry if this has been discussed before. "Image" is a hard string to search the forum for...

Regarding the Image class:
I created an image, rotated around the x, then the z, then offset it. Then I made it into a component by adding a line, making the component, then deleting the line.

Image.origin (before making into component) {-62.8, 24.9, 25.6}
Image.origin (after making into component) {79.4, 0, 25.6}
ComponentInstance.transformation * Image.origin {-62.8, 24.9, 25.6}

exactly what you'd expect. The component transform matrix provides the extra scaling, position, etc. and the origin of the image is relative to containing component.
But when I copy that component into multiple instances, the Image.origin of every single copy is different! Even though the image is supposed to be an instance and therefore identical to all the others. And if I rotate the instance, the normal is different!

It appears to me that the origin / normal of all the instance copies are the difference from the position of the original image when it was turned into a component. Everything inside a container (group / component) is supposed to unaffected by the operations that occur outside the container. But images seem not to obey that rule when in components (groups work fine, but in groups each Image is a distinct entity).

So, does anyone know what the rules are for Images in components? Is there anyway at all to use them with consistency?!

Thanks!

Paul, WOW, absolutely wow. I hope to see that image on the TwilightRender.com gallery!

Nice... The name is a bit of... unfortunate... timing. It was picked long before the movie came out.

@chris fullmer said:

I'm just hoping that at some point I find the "register" button on their forums...

Registration is done on the front page of the website, http://www.TwilightRender.com. There should be a 'Create Account' link on the lower left side. The forum is tied into the website, so one registration works for both.

@dale said:

Sadly, appears to be windows only?

For now it's windows only, but we do hope to put out a Mac version as soon as possible.