How exactly can one calculate all required parameters for SVG path arc? Is there a source with a set of formulas somewhere available? A compendium without all the geometry background and without lengthly explanations?
I have been fiddeling with an online tool http://xahlee.info/js/svg_circle_arc.html but the resulting parameters seem to be all intervowen in some way.
For my specific application to draw an arc that has an appearence similar to the letter 'C', I exactly have four givens: The coordinates for the two ends of the arc, the height and the leftmost point:
Height: 29.0
Leftmost point: x=0 y=(29/2)=14.5
Upper end of the arc: x1=20 y1=6
Lower end of the arc: x2=22 y2=20
Now I want to write an absolute path:
<path d="M xx yy
A rx ry x-axis-rotation large-arc-flag sweep-flag x y"/>
This seems to be a hard task but I'm sure there is a way to derive everything from the givens.
Related
Does the technique that vulkan uses (and I assume other graphics libraries too) to interpolate vertex attributes in a perspective-correct manner require that the vertex shader must normalize the homogenous camera-space vertex position (ie: divide through by the w-coordinate such that the w-coordinate is 1.0) prior to multiplication by a typical projection matrix of the form...
g/s 0 0 0
0 g 0 n
0 0 f/(f-n) -nf/(f-n)
0 0 1 0
...in order for perspective-correctness to work properly?
Or, will perspective-correctness continue to work on any homogeneous vertex position in camera-space (with a w-coordinate other than 1.0)?
(I didn't completely follow the perspective-correctness math, so it is unclear which to me which is the case.)
Update:
In order to clarify terminology:
vec4 modelCoordinates = vec4(x_in, y_in, z_in, 1);
mat4 modelToWorld = ...;
vec4 worldCoordinates = modelToWorld * modelCoordinates;
mat4 worldToCamera = ...;
vec4 cameraCoordinates = worldToCamera * worldCoordinates;
mat4 cameraToProjection = ...;
vec4 clipCoordinates = cameraToProjection * cameraCoordinates;
output(clipCoordinates);
cameraToProjection is a matrix like the one shown in the question
The question is does cameraCoordinates.w have to be 1.0?
And consequently the last row of both the modelToWorld and worldToCamera matricies have to be 0 0 0 1?
You have this exactly backwards. Doing the perspective divide in the shader is what prevents perspective-correct interpolation. The rasterizer needs the perspective information provided by the W component to do its job. With a W of 1, the interpolation is done in window space, without any regard to perspective.
Provide a clip-space coordinate to the output of your vertex processing stage, and let the system do what it exists to do.
the vertex shader must normalize the homogenous camera-space vertex position (ie: divide through by the w-coordinate such that the w-coordinate is 1.0) prior to multiplication by a typical projection matrix of the form...
If your camera-space vertex position does not have a W of 1.0, then one of two things has happened:
You are deliberately operating in a post-projection world space or some similar construct. This is a perfectly valid thing to do, and the math for a camera space can be perfectly reasonable.
Your code is broken somewhere. That is, you intend for your world and camera space to be a normal, Euclidean, non-homogeneous space, but somehow the math didn't work out. Obviously, this is not a perfectly valid thing to do.
In both cases, dividing by W is the wrong thing to do. If your world space that you're placing a camera into is post-projection (such as in this example), dividing by W will break your perspective-correct interpolation, as outlined above. If your code is broken, dividing by W will merely mask the actual problem; better to fix your code than to hide the bug, as it may crop up elsewhere.
To see whether or not the camera coordinates need to be in normal form, let's represent the camera coordinates as multiples of w, so they are (wx,wy,wz,w).
Multiplying through by the given projection matrix, we get the clip coordinates (wxg/s, wyg, fwz/(f-n)-nfw/(f-n)), wz)
Calculating the x-y framebuffer coordinates as per the fixed Vulkan formula we get (P_x * xg/sz +O_x, P_y * Hgy/z + O_y). Notice this does not depend on w, so the position in the framebuffer of a polygons verticies doesn't require the camera coordinates be in normal form.
Likewise calculation of the barycentric coordinates of fragments within a polygon only depends on x,y in framebuffer coordinates, and so is also independant of w.
However perspective-correct perspective interpolation of fragment attributes does depend on W_clip of the verticies as this is used in the formula given in the Vulkan spec. As shown above W_clip is wz which does depend on w and scales with it, so we can conclude that camera coordinates must be in normal form (their w must be 1.0)
I need to draw in SVG parts of circle's circumference in different colours (please look at the picture below). Unfortunately I'm not good at SVG, so I found solution which is in my opinion very poor: I'm using describeArc() function from this post and I draw two paths - one colourful circle and, over it, white circle with smaller radius. For example:
PATH1 = describeArc(x=10000, y=5000, radius=3000, startAngle=45, endAngle=90)
PATH2 = describeArc(x=10000, y=5000, radius=2800, startAngle=45, endAngle=90)
and after inserting it into svg, I have:
<path d=PATH1 fill="red" stroke-width="0" />
<path d=PATH2 fill="white" stroke="white" stroke-width="100" />
It works, but for me it's the ugly solution. How can I do it better?
That function is called describeArc(), but is actually drawing a circular sector, not an arc.
I agree it is kind of ugly because you are unnecessarily drawing - and overdrawing - most of the sector. And you will get issues with some of the colours bleeding around the edge of the white. I assume that's why you are including the white stroke.
The solution is very simple. Change the describeArc() function so that it is only drawing the arc, and not the rest of the sector. Change the code as follows:
var d = [
"M", start.x, start.y,
"A", radius, radius, 0, arcSweep, 0, end.x, end.y
].join(" ");
Ie. remove the two "L" path commands that form the other two sides of the sector. In other words, use the answer by #opsb, not the #Ahtenus answer.
I have a weird issue in my bar graph realized using d3.js: the 1 px padding between each rectangle appears irregular. I gather either or both the width or x position are the culprit but i don't understand what i'm doing wrong: the width is a fraction of the svg area and the X position is obtained via a D3 scale.
I've put a demo here: http://jsfiddle.net/pixeline/j679N/4/
The code ( a scale) controling the x position:
var xScale = d3.time.scale().domain([minDate, maxDate]).rangeRound([padding, w - padding]);
The code controlling the width:
var barWidth = Math.floor((w/dataset.length))-barPadding;
Thank you for your insight.
It's irregular because you are rounding your output range (rangeRound). In some cases, the distance between two bars is 3 pixels and sometimes only 2. This is because the actual x position is a fractional value and ends up being rounded one way in some cases and the other way on other cases.
You can mitigate the effect but changing rangeRound to range, but that won't eliminate it entirely as you'll still get fractional pixel values for positions. The best thing to do is probably to simply increase the padding so that the differences aren't as obvious.
Given:
A point P, circle 1 and circle 2's positions and radii
What is:
The equation for T, the 'mix level' between color 1 and 2 (a value between 0 to 1)
Many radial gradient equations only apply to concentric circles or circles that share a position. I'm looking for something that matches the image below, created using Quartz (Core Graphics). I am writing a GLSL shader, but I need to understand the math first.
If this is in 2D, then you can write the parameters of the circle that your point lies on as:
x3=T*x1+(1-T)*x2
y3=T*y1+(1-T)*y2
r3=T*r1+(1-T)*r2
EDIT: Of course, that circle can be represented as:
(x3-xP)^2+(y3-yP)^2=r3^2
You can substitute the first 3 equations into the last (and remember that (xP, yP) is your point) to get 1 equation with only T as a variable that is quadratic in T, so it is easy to solve for T. Doing so gives us:
T=(-r2*(r1-r2)+(x1-x2)*(x2-xP)+(y1-y2)(y2-yP)
{+-}sqrt(r2^2*((x1-xP)^2+(y1-yP)^2)-2*r1*r2*((x1-xP)*(x2-xP)
+(y1-yP)*(y2-yP))+r1^2*((x2-xP)^2+(y2-yP)^2)
-(x2*y1-xP*y1-x1*y2+xP*y2+x1*yP-x2*yP)^2))
/((r1-r2)^2-(x1-x2)^2-(y1-y2)^2)
I know that that is a bit hard to read, but it is not actually that bad mathematically. It is just addition, multiplication, and squaring (which is really just multiplication).
I am trying to reconstruct original graphics primitives from Postscript/SVG paths. Thus an original circle is rendered (in SVG markup) as:
<path stroke-width="0.5" d="M159.679 141.309
C159.679 141.793 159.286 142.186 158.801 142.186
C158.318 142.186 157.925 141.793 157.925 141.309
C157.925 140.825 158.318 140.432 158.801 140.432
C159.286 140.432 159.679 140.825 159.679 141.309" />
This is an approximation using 4 Beziers curves to create a circle.In other places circular arcs are approximated by linked Bezier curves.
My question is whether there is an algorithm I can use to recognize this construct and reconstruct the "best" circle. I don't mind small errors - they will be second-order at worst.
UPDATE: Note that I don't know a priori that this is a circle or an arc - it could be anything. And there could be 2, 3 4 or possibly even more points on the curve. So I'd really like a function of the sort:
error = getCircleFromPath(path)
where error will give an early indication of whether this is likely to be a circle.
[I agree that if I know it's a circle it's an easier problem.]
UPDATE: #george goes some way towards answering my problem but I don't think it's the whole story.
After translation to the origin and normalization I appear to have the following four points on the curve:
point [0, 1] with control point at [+-d,1] // horizontal tangent
point [1, 0] with control point at [1,+-d] // vertical tangent
point [0, -1] with control point at [+-d,-1] // horizontal tangent
point [-1, 0] with control point at [-1,+-d] // vertical tangent
This guarantees that the tangent at each point is "parallel" to the path direction at the point. It also guarantees the symmetry (4-fold axis with reflection. But it does not guarantee a circle. For example a large value of d will give a rounded box and a small value a rounded diamond.
My value of d appears to be about 0.57. This might be 1/sqrt(3.) or it might be something else.It is this sort of relationship I am asking for.
#george gives midpoint of arc as;
{p1,(p1 + 3 (p2 + p3) + p4)/8,p4}
so in my example (for 1,0 to 0,1) this would be:
[[1,0]+3[1,d]+3[d,1]+[0,1]] / 8
i.e.
[0.5+3d/8, 3d/8+0.5]
and if d =0.57, this gives 0.71, so maybe d is
(sqrt(0.5)-0.5)*8./3.
This holds for a square diamond, but for circular arcs the formula must be more general and I'd be grateful if anyone has it. For example, I am not familiar with Bezier math, so #george's formula was new to me
enter code here
Without doing all the math for you.. this may help:
there are always 4 control points on a bezier.
Your curve is 4 beziers linked together with points 1-4 , 4-7 , 7-10 , and 10-13 the control points
for each part. Points 1 , 4 , 7 and 10 (&13==1) lie exactly on the curve. To see if you have a nice circle calculate:
center = ( p1+p7 )/2 =( {159.679, 141.309} + {157.925, 141.309} ) / 2
= {158.802, 141.309}
verify you get the same result using points 4+10 -> {158.801, 141.309}
Once you know the center you can sample points along the curve and see if you have a constant distance.
If you only have a single bezier arc with 4 points a useful formula is that the midpoint is at
(p1 + 3 (p2 + p3) + p4)/8. So you can find the circle passing through three points:
{p1,(p1 + 3 (p2 + p3) + p4)/8,p4}
and again sample other points on the curve to decide if you indeed have a near circular arc.
Edit
the bezier formula is this:
x=(1-t)^3 p1 + 3 (1-t)^2 t p2 + 3 (1-t) t^2 p3 + t^3 p4 with parameter 0 < t < 1
so for example at t=1/4 you have
x=( 27 p1 + 27 p2 + 9 p3 + 1 p4 ) / 64
so once you find the center you can readily check a few points and calculate their distance.
I suspect if you only want to detect nearly exact circular arcs then checking two extra points with a tight tolerance will do the job. If you want to detect things that are approximately circular I would compute a bunch of points and use the average error as a criteria.
If all your elements are circle-like then you can just get the dimensions through path.getBBox() and generate a circle from there. In this case I'm considering ellipses, but you can easily translate it to actual circle elements:
var path = document.getElementById("circle_path");
var bbox = path.getBBox();
var rx = bbox.width/2;
var ry = bbox.height/2;
var cx = bbox.x + rx;
var cy = bbox.y + ry;
var ellipse = document.createElementNS(xmlns, "ellipse");
ellipse.setAttribute("fill", "none");
ellipse.setAttribute("stroke", "red");
ellipse.setAttribute("stroke-width", 0.1);
ellipse.setAttribute("cx", cx);
ellipse.setAttribute("cy", cy);
ellipse.setAttribute("rx", rx);
ellipse.setAttribute("ry", ry);
svg.appendChild(ellipse);
You can see a demo here:
http://jsfiddle.net/nwHm6/
The endpoints of the Bézier curves are probably on the circle. If so, it's easy to reconstruct the original circle.
Another possibility is to take the barycenter of the control points as the center of the circle because the control points are probably laid out symmetrically around the center. From the center, you get the radius as the average distance of the four control points closest to the center.
One can define an ellipse as a unit circle centred on (0,0), translated (2 params), scaled (2 params), and rotated (1 param). So on each arc take five points (t=0 ¼ ½ ¾ 1) and solve for these five parameters. Next take the in-between four points (t=⅛ ⅜ ⅝ ⅞), and test whether these lie on the same transformed circle. If yes, whoopee!, this is (part of) a transformed circle.
Immediately before and after might be another arc or arcn. Are these the same ellipse? If yes, and the subtended angles touch, then join together your descriptions of the pieces.