Does anyone know if it is possible to combine (for example) different CGContext paths to create a new combined shape as in this example?
Thanks!
I found a library that does Union operations on CGPaths:
https://bitbucket.org/martinwinter/vectorbooleancg
I haven't tried it yet, but the author of the CG branch of Vectorbool, Martin Winter, states that the union operation should be usable in its current form on iOS. I will add information when I get around to trying to implement it.
I doubt that there is an Apple lib that supports this feature.
What you need is a so called "union of two (or more) polygons", sometimes called boolean operations on polygons.
I would convert the CGPath to a polygon, probably you start creating a point array that contains your polygon points. That means to not use CGPathAddEllipse, but to approximate the shapes , by e.g a regular polygon with something between 64 and 256 vertices.
You can easily calculate the points of a circle or ellipse for yourself (using something similar to a*cos(t), b*sin(t) see wikipedia for ellipse "parameter formula")
Then you take one of the c libraries that provide these "union operation".
One of that is the LEDA lib.
Related
I'm a big fan of PaperJS, however, the library doesn't see much activity so we're looking at other tools, like KonvaJS, Fabric, and Pixi. We'd like to replicate the example here:
http://paperjs.org/examples/path-simplification/
in KonvaJS but we're not sure which class is the most appropriate? Should we use the line, which is described as a collection of points with tension, the path tool which is what we use in Paper, or the shape class? Does KonvaJS offer the same type of access to the bezier curve tools and shape border, blue line, found in the above-mentioned paper example?
Konva.Line requires a list of x & y passed into its points property as a simple array, then draws straight lines connecting those points. The tension property can be used to make the straight line joins more curvy.
Konva.Path expects you to provide a data property that is more like a list of SVG drawing instructions, so move, lineto, arc, etc. (See supported instructions list in Konva docs for Konva.Path.data here)
There is no built-in equivalent path-editing features to those in the demo you linked to - so no automatic anchors on the path control points and no Bezier handles. You would have to DIY those. Having said that, it would all be achievable - what I mean is the drawing of the control anchors and lines, the listening for mouse and drag events, and the final passing back of the SVG drawing data to the Konva.Path shape when the path's edit mode ends are all well supported in Konva.
As at May 2022, the Konva lib is well supported, with appropriately frequent (as Goldilocks would want - not too many and not too few), no ill-thought-out breaking changes, issues are responded to, SO posts replied to, and there is a busy Discord channel.
What's the best way to determine if a point is within a certain distance of a GEOJSON polygon? Should one use TurfJS buffer method (https://github.com/Turfjs/turf-buffer#turf-buffer)? Can one perform queries on the buffered polygon?
It's clear to me one could us the TurfJS' inside method (https://github.com/Turfjs/turf-inside) to determine whether a point is within a polygon. I'm just curious what the best approach would be for finding whether or not a point is inside of a buffered polygon.
For example:
I have a number of neighborhoods provided as a GEOJSON polygon files. I also have a set of locations/addresses for employees (already geocoded to lat/long coordinates). What would be the best way to see whether or not my employees live within 10 miles of a given neighborhood polygon?
Thanks!
Yes, you can use buffer in conjunction with inside to find points within 10 miles of something else, eg, expanding on the existing examples,
var pt = point(14.616599, -90.548630)
var unit = 'miles'
var buffered = buffer(pt, 10, unit)
var ptTest = point(-1, 52)
var bIn = inside (ptIn, buffer)
which should obviously be false.
In general, though, buffering is somewhat expensive, so you would not necessarily want to do this every time you run the query. There are a couple of things you can do to speed things up:
1). Pre-buffer your search areas
2). Use some kind of R-tree type index, which will first check bounding box intersection, and avoid lots of unecessary point in polygon operations. turfjs, which I hadn't heard of until seeing your post, uses jsts under the hood for a number of operations, including buffering. This library has an implemention of R-tree indexes that you could potentially use. Here is a fun example of this being done.
In general, in situations where you have a spatial (R-tree type) index in place, such as a spatially enabled database like Postgis on top of Postgres, you would use an operator like ST_Dwithin (geom1, geom2, distance) in a where clause to find all points within some distance of another geometry, and this would be very efficient as many candidates would be rejected for failing an initial bounding box test.
Really, it depends on the size of your data and frequency of queries. There is nothing, in principle, wrong with doing contains queries on a buffer. I hope I haven't created more questions than answers.
I'm using GeoScript to do that sort of calculations in JavaScript. It has a distance method in the geom.Geometry class which can return the minimum distance between two geometries. You could use that, or take a look at the source on GitHub to see how they do it if you want to roll your own solution.
Not a long question. Can anyone explain what the word "translation" means in the context of graphics? Thanks a lot.
Translation is just moving something (up, down, or sideways).
Move an object - don't rotate or scale or distort it, just move it
Translation, as said, is moving an object. This is one of the affine transformations (which means it doesn't distort the object). There are a few others, the 2D versions of which are described here. (Note that shearing, the final one listed, isn't affine).
It literally means to translate coordinates from one graph system to another using a mathmatical function.
In normal 2d/3d geometry this is accomplished by adding or subtracting values to move the origin of one system to the orgin of the other.
Ie - move the object from one spot to another.
(Ps this is somewhat simplified.)
I'm not math savvy, but this Mathematica plot caught my eye and I was hoping you could help me identify it.
I've searched the various functions and keywords found in the pictured code, but none of the results suggested anything specific to me about whatever algorithm is at work in this plot.
Sorry about the quality, it's a screen capture of a video
Looks like a Voronoi Diagram to me.
As others have noted, you're looking at a Voronoi diagram generated by Mathematica. You can see the Mathematica expression being used, and the key function is ListDensityPlot.
If you follow the latter link and open the "Neat Examples" section you'll see another Voronoi diagram. The key parameter there is InterpolationOrder→0.
Except for the two dots in the light-purple area (third from top left), one of which might be a video artifact, every coloured area has a single dot, and points in the field appear (both by looking at the diagram and guessing what the code means) to be coloured according to which of the dots they are closest to.
Which would make it, as #Moron has said, a Voronoi diagram.
True. Voronoi Diagrams can build that sort of "image".
Look for Voronoi Diagrams or Thiessen Polygons.
For instance:
An approach to compute efficiently the first intersection between a viewing ray and a set of three objects: one sphere, one cone and one cylinder (other 3D primitives).
What you're looking for is a spatial partitioning scheme. There are a lot of options for dealing with this, and lots of research spent in this area as well. A good read would be Christer Ericsson's Real-Time Collision Detection.
One easy approach covered in that book would be to define a grid, assign all objects to all cells it intersects, and walk along the grid cells intersecting the line, front to back, intersecting with each object associated with that grid cell. Keep in mind that an object might be associated with more grid-cells, so the intersection point computed might actually not be in the current cell, but actually later on.
The next question would be how you define that grid. Unfortunately, there's no one good answer, and you need to consider what approach might fit your scenario best.
Other partitioning schemes of interest are different tree structures, such as kd-, Oct- and BSP-trees. You could even consider using trees combined with a grid.
EDIT
As pointed out, if your set is actually these three objects, you're definately better of just intersecting each one, and just pick the earliest one. If you're looking for ray-sphere, ray-cylinder, etc, intersection tests, these are not really hard and a quick google should supply all the math you might possibly need. :)
"computationally efficient" depends on how large the set is.
For a trivial set of three, just test each of them in turn, it's really not worth trying to optimise.
For larger sets, look at data structures which divide space (e.g. KD-Trees). Whole chapters (and indeed whole books) are dedicated to this problem. My favourite reference book is An Introduction to Ray Tracing (ed. Andrew. S. Glassner)
Alternatively, if I've misread your question and you're actually asking for algorithms for ray-object intersections for specific types of object, see the same book!
Well, it depends on what you're really trying to do. If you'd like to produce a solution that is correct for almost every pixel in a simple scene, an extremely quick method is to pre-calculate "what's in front" for each pixel by pre-rendering all of the objects with a unique identifying color into a background item buffer using scan conversion (aka the z-buffer). This is sometimes referred to as an item buffer.
Using that pre-computation, you then know what will be visible for almost all rays that you'll be shooting into the scene. As a result, your ray-environment intersection problem is greatly simplified: each ray hits one specific object.
When I was doing this many years ago, I was producing real-time raytraced images of admittedly simple scenes. I haven't revisited that code in quite a while but I suspect that with modern compilers and graphics hardware, performance would be orders of magnitude better than I was seeing then.
PS: I first read about the item buffer idea when I was doing my literature search in the early 90s. I originally found it mentioned in (I believe) an ACM paper from the late 70s. Sadly, I don't have the source reference available but, in short, it's a very old idea and one that works really well on scan conversion hardware.
I assume you have a ray d = (dx,dy,dz), starting at o = (ox,oy,oz) and you are finding the parameter t such that the point of intersection p = o+d*t. (Like this page, which describes ray-plane intersection using P2-P1 for d, P1 for o and u for t)
The first question I would ask is "Do these objects intersect"?
If not then you can cheat a little and check for ray collisions in order. Since you have three objects that may or may not move per frame it pays to pre-calculate their distance from the camera (e.g. from their centre points). Test against each object in turn, by distance from the camera, from smallest to largest. Although the empty space is the most expensive part of the render now, this is more effective than just testing against all three and taking a minimum value. If your image is high res then this is especially efficient since you amortise the cost across the number of pixels.
Otherwise, test against all three and take a minimum value...
In other situations you may want to make a hybrid of the two methods. If you can test two of the objects in order then do so (e.g. a sphere and a cube moving down a cylindrical tunnel), but test the third and take a minimum value to find the final object.