I've been playing around with how to render wireframe perspective-correct spheres using only canvas2d and ellipse math.
It's been fun, but I've soon come to realize that the ellipse() function has a very strange implementation with regards to the spec.
Indeed, the ellipse function takes 7 (or 8) arguments:
ellipse(x, y, radiusX, radiusY, rotation, startAngle, endAngle)
The startAngle is described as such:
The angle at which the ellipse starts, measured clockwise from the positive x-axis and expressed in radians.
Given a parameter 0 <= t <= 2 * PI, we can compute the position of the associated point on the ellipse like so:
let dx = radiusX * cos(t)
let dy = radiusY * sin(t)
let px = x + dx * cos(rotation) - dy * sin(rotation)
let py = y + dx * sin(rotation) + dy * cos(rotation)
And if we use startAngle = t, our ellipse will begin its arc at our point. But. But. t is NOT an angle, and definitely not the angle of our point from the x-axis of the ellipse. Apparently some people still call it the eccentric angle, but my point still stands.
(See here)
And indeed, if we try to make the arc of an ellipse start at a specific angle, we can see that the result is not what we expect, unless the ellipse is a circle (radiusX = radiusY) or startAngle is a multiple of PI / 2.
Here is an interactive demo I've put up so that you can witness the strange default behaviour.
My claim is that the function should always behave like it does in the corrected case with the current specification.
Either that or change the spec to talk about parameters t for startAngle and endAngle, and avoid saying they are angles, because currently they definitely are not.
Does anyone know how this implementation/spec came to be, if anyone reported this before and if not where to lead such a discussion?
Any other insight appreciated!
I found this related question but it's rather unsatisfactory as replies merely show how to correct the function, but don't discuss whether the spec or implementation should be corrected.
I've been trying to create a pure javascript version of the "plinko" game. I don't have a maths or physics background so everything I've picked up has been from google/youtube.
I'm trying to calculate the angle a ball should bounce at when making contact with an angled surface. I've got as far as calculating the angle of the ball at impact and the angle of the line its making contact with using inverse tan and the velocity x and y of the ball and line respectively. I then found the angle of incidence by finding the difference in the two angles, which according to snell's law should give me the angle of reflection relative to the line it has impacted.
However, having implemented this in code (or at least I think I have) the angles calculated and the direction of travel of the ball does not make sense. Here is the section of the code that deals with that:
var lineVelX = startPos[0] - endPos[0];
var lineVelY = startPos[1] - endPos[1];
var lineAngle = Math.atan(lineVelY / lineVelX) * 180 / Math.PI;
var ballAngle = Math.atan(window[ball].velY / window[ball].velX) * 180 / Math.PI;
var angleOfIncidence = ballAngle - lineAngle;
var newBallAngle = ballAngle - angleOfIncidence;
window[ball].velX = Math.cos(newBallAngle) * 2;
window[ball].velY = Math.sin(newBallAngle) * 2;
Hopefully, someone with a greater understanding of maths and physics can explain where I'm going wrong.
Here is a link to my code in jsfiddle.
Thanks in advance for the help :)
Edit: Ran the code on a more powerful computer and the grid rendered correctly. Possible hardware limitation? Computer where the problem occurred was a Samsung series 3 Chromebook. I'm thinking it has to do with trying to draw too many lines at the same time. Will test later.
I'm trying to draw a grid onto a canvas using the lineTo() method. The lines draw properly in the beginning, but any line that is drawn completely past 2048 pixels either down or to the right doesn't show up. Line going from inside this point to past it still show up on the other side, just lines that only are only drawn past the point don't show up.
Here's my JavaScript:
function drawGrid() {
//data.tiles is the map stored as an array of arrays
//tilesize = 60
var bw = data.tiles[0].length * tilesize;
var bh = data.tiles.length * tilesize;
ctx.beginPath();
for (i = bw; i >= 0; i -= tilesize) {
ctx.moveTo(i, 0);
ctx.lineTo(i, bh);
}
for (i = bh; i >= 0; i -= tilesize) {
ctx.moveTo(0, i);
ctx.lineTo(bw,i);
}
ctx.strokeStyle = "black";
ctx.stroke();
}
I've checked the data.tiles variable, and it's reading the right number. Really have no idea what I messed up here.
HTML Canvas has a maximum render area depending on your browser & hardware.
once you exceed these limits well your done pretty much.
try pre-rendering or use multiple canvas' positioned with CSS.
If you can see images drawn beyond 2048 then there's no reason a lineTo wouldn't be drawn also.
In the code you calculate bw and bh in different ways. You might check if this is a problem. If not, we'll need to see more code.
// bw uses data.tiles[0]
var bw = data.tiles[0].length * tilesize;
// bh uses data.tiles with no subscript
var bh = data.tiles.length * tilesize;
I am using Raphaël for the first time with little svg experience and I need someone who is really knowledgeable with these two to help me.
I have created a pie chart with dynamic sectors. The sectors can be resized by dragging on the round buttons. See this fiddle. I have only tested in Chrome and Safari which are the only required browsers.
The pie chart is not yet complete. The sectors can overlap. Please ignore this for now.
I was faced with problems, when the starting angle of a sector was greater than the ending angle. This is the case when the ending angle goes past the 0/360° mark. To solve this I made use of the path-rotation-parameter. I moved the sector forward while moving the angles back, until the end angle is at 360. You can see this in the fiddle in this function:
function sector_update(cx, cy, r, startAngle, endAngle, sec) {
var x1 = cx + r * Math.cos(-startAngle * rad),
x2 = cx + r * Math.cos(-endAngle * rad),
y1 = cy + r * Math.sin(-startAngle * rad),
y2 = cy + r * Math.sin(-endAngle * rad);
var rotation = 0;
// This is the part that I have the feeling could be improved.
// Remove the entire if-clause and let "rotation" equal 0 to see what happens
if (startAngle > endAngle) {
rotation = endAngle;
startAngle = startAngle - endAngle;
endAngle = 360;
}
sec.attr('path', ["M", cx, cy, "L", x1, y1, "A", r, r, rotation,
+(endAngle - startAngle > 180), 0, x2, y2, "z"]);
}
Although it works nicely, I'm a bit skeptical. Can this be solved without the rotation of the path? I appreciate any help or pointers.
Can this be solved without the rotation of the path?
Answer: Yes, it can. You don't have to change the rotation of the path at all. Unless I'm missing something, the following code seems to work the same as what you have in the fiddle:
function sector_update(cx, cy, r, startAngle, endAngle, sec) {
var x1 = cx + r * Math.cos(-startAngle * rad),
x2 = cx + r * Math.cos(-endAngle * rad),
y1 = cy + r * Math.sin(-startAngle * rad),
y2 = cy + r * Math.sin(-endAngle * rad);
//notice there is no "roation" variable
if (startAngle > endAngle) {
startAngle -= endAngle;
endAngle = 360;
}
sec.attr('path', ["M", cx, cy, "L", x1, y1, "A", r, r, 0,
+(endAngle - startAngle > 180), 0, x2, y2, "z"]);
}
Explanation: For my explanation, I will use the SVG terminology in the
W3 Spec and Raphael Reference Library. That is, while you use cx, cy, and rotation, these use rx, ry, and x-axis-rotation respectively.
In short, whenever rx equals ry, then x-axis-rotation is meaningless.
Look at this SVG. Use your browser's development tools, or save the SVG to your computer and use a file editor to edit it. Specifically, look at the last path element, which has four arcs in it. Try modifying the x-axis-rotation value on each arc. You will notice that the first arc (where rx and ry are both "25") never changes when you update x-axis-rotation value.
Why? This is because you have a circular arc. No matter how much you rotate a circle, it will still be the same circle. For example, hold up a glass in front of you so that the glass is horizontal to the ground, and you are looking directly down the glass. Now rotate/twist the glass with your wrist. Do you see how the circular shape you see stays in the same circular shape? Now set the glass on the table normally (so it is vertical and could hold a liquid). Now tip the glass over. You can see the obvious perspective change; it was pointing up, but now it is laying flat. That is what x-axis-rotation does.
Perhaps a better example is to just play around with the aforementioned SVG file. Play with x-axis-rotation on the arcs in the final path element. You will see the arcs being rotated around. That is what x-axis-rotation does.
Back to your code: Because you are dealing only with circular objects, the x-axis-rotation will make no difference on the final output. So long as you are only dealing with circular objects, you can hard-code it's value to zero without any worries. All you really needed to do is modify the angles, which you had done correctly.
Performance: I tried using JavaScript to time your sector_update function both with and without modifying the x-axis-rotation variable. The result? I saw no difference in performance. The majority of the time spent is on actually drawing the SVG, not on the math that determines it's values. In fact, all you are really doing in JavaScript is updating the code to set the value in the path element. At that point in time, the browser takes over with it's rendering engine to actually draw the SVG object. I suppose then it's a per-browser issue, as each browser has different rendering performance. But as for whether or not the x-axis-rotation value has any effect, my guess is no. If there is a performance hit (because the browser may have to do an additional floating-point operation), it is so incredibly moot because the overwhelming majority of the time is spent drawing the object, not calculating it's values. So I would say not to worry about it.
I hope that helps, let me know if I missed something or didn't explain something well enough.
I wrote a very simple collision detection demo:
http://jsfiddle.net/colintoh/UzPg2/5/
As you can see, the objects sometimes doesn't connect at all but yet the collision is being triggered. The radius for the balls are 10px so the algo triggered the collision whenever the distance between two balls center is less than 20px. I reduced it to 18px for a better visual but the empty collision still happens randomly. Am I doing something wrong?
It looks like you are not using the right formula for distance between two points. See http://www.purplemath.com/modules/distform.htm for a full explanation.
You are doing this:
this.ballCollide = function(balli) {
if (Math.abs((this.x) - (balli.x)) < (2*radius - buffer)) {
if (Math.abs((this.y) - (balli.y)) < (2*radius - buffer)) {
// Do collision
}
}
};
That's a square bounding box, not a circular one. To get a circular bounding box, you can do something like this, based on the formula in the referenced web page:
this.ballCollide = function(balli) {
var deltax = this.x - balli.x;
var deltay = this.y - balli.y;
if (Math.sqrt(deltax * deltax + deltay * deltay) < 2 * radius - buffer) {
// Do collision
}
};
See http://jsfiddle.net/UzPg2/14/ for a working example.
Note that a perfect circular bounding box is a much slower algorithm than a square bounding box approximation.
Following Jarrod Roberson's point (a perfect circle is always inside a perfect square), you'd do that by basically combining your original code with the code I posted, like this (and you could combine them both into one conditional switch if you wanted to):
var deltax = this.x - balli.x;
var deltay = this.y - balli.y;
var dist = 2 * radius - buffer;
if (Math.abs(deltax) < dist && Math.abs(deltay) < dist) {
if (Math.sqrt(deltax * deltax + deltay * deltay) < dist) {
// Do collision
}
}
See http://jsfiddle.net/UzPg2/21/ for a working example (I've left the buffer as your variable is called at 2, but I personally think it looks better with a value of 1).
There are also many other ways you can optimize this for speed if you need to, but Jarrod's suggestion gives you the biggest immediate speed boost.
You're only checking for collisions on two axis, x and y. You need to use Pythagoras' theorem to detect on all axis at the cost of efficiency. For example.
Your algorithm will detect a collision around the point where these two balls are, since if you draw a tangent line along the x or y axis from one ball it goes through the other ball: http://jsfiddle.net/XpXzW/1/
Here you can see where they should actually collide:
http://jsfiddle.net/wdVmQ/1/
If you change your collision detection algorithm to check for perfect collisions (it will be less efficient) you can get rid of your buffer too:
http://jsfiddle.net/ucxER/
(Using Pythagoras' theorem the formula for a collision is:
Math.sqrt((this.x - balli.x)*(this.x - balli.x)
+ (this.y - balli.y)*(this.y - balli.y)) < 2*radius
Also what Jarrod commented is very smart. You can speed it up by using a technique like that. Since the square root is only calculated when the balls are close to each other:
http://jsfiddle.net/bKDXs/