Midpoint circle algorithm - Revision history

Iandiver: /* Jesko's Method */ Typo: "low-performate" -> "low-performance"

2025-05-27T17:29:45Z

Jesko's Method: Typo: "low-performate" -> "low-performance"

← Previous revision		Revision as of 17:29, 27 May 2025
Line 103:		Line 103:
	The algorithm has already been explained to a large extent, but there are further optimizations.		The algorithm has already been explained to a large extent, but there are further optimizations.

	The new presented method<ref>For the history of the publication of this algorithm see https://schwarzers.com/algorithms</ref> gets along with only 5 arithmetic operations per step (for 8 pixels) and is thus best suitable for low-~~performate~~ systems. In the "if" operation, only the sign is checked (positive? Yes or No) and there is a variable assignment, which is also not considered an arithmetic operation.		The new presented method<ref>For the history of the publication of this algorithm see https://schwarzers.com/algorithms</ref> gets along with only 5 arithmetic operations per step (for 8 pixels) and is thus best suitable for low-performance systems. In the "if" operation, only the sign is checked (positive? Yes or No) and there is a variable assignment, which is also not considered an arithmetic operation.
	The initialization in the first line (shifting by 4 bits to the right) is only due to beauty and not really necessary.		The initialization in the first line (shifting by 4 bits to the right) is only due to beauty and not really necessary.

Olisykesss: /* growthexperiments-addlink-summary-summary:3|0|0 */

2025-02-25T23:39:51Z

Link suggestions feature: 3 links added.

← Previous revision		Revision as of 23:39, 25 February 2025
Line 18:		Line 18:
	==Algorithm==		==Algorithm==
	{{Confusing section\|date=February 2009}}		{{Confusing section\|date=February 2009}}
	The objective of the algorithm is to approximate a [[circle]], more formally put, to approximate the curve <math>x^2 + y^2 = r^2</math> using pixels; in [[layman's terms]] every pixel should be approximately the same distance from the center, as is the definition of a circle. At each step, the path is extended by choosing the adjacent pixel which satisfies <math>x^2 + y^2 \leq r^2</math> but maximizes <math>x^2 + y^2 </math>. Since the candidate pixels are adjacent, the arithmetic to calculate the latter expression is simplified, requiring only [[Bitwise_operation#Bit_shifts\|bit shifts]] and additions. But a simplification can be done in order to understand the bitshift. Keep in mind that a left bitshift of a binary number is the same as multiplying with 2. Ergo, a left bitshift of the radius only produces the [[diameter]] which is defined as radius times two.		The objective of the algorithm is to approximate a [[circle]], more formally put, to approximate the curve <math>x^2 + y^2 = r^2</math> using pixels; in [[layman's terms]] every pixel should be approximately the same distance from the center, as is the definition of a circle. At each step, the path is extended by choosing the adjacent pixel which satisfies <math>x^2 + y^2 \leq r^2</math> but maximizes <math>x^2 + y^2 </math>. Since the candidate pixels are adjacent, the arithmetic to calculate the latter expression is simplified, requiring only [[Bitwise_operation#Bit_shifts\|bit shifts]] and additions. But a simplification can be done in order to understand the bitshift. Keep in mind that a left bitshift of a [[binary number]] is the same as multiplying with 2. Ergo, a left bitshift of the radius only produces the [[diameter]] which is defined as radius times two.

	This algorithm starts with the [[circle]] equation. For simplicity, assume the center of the circle is at <math>(0,0)</math>. To start with, consider the first octant only, and draw a curve which starts at point <math>(r,0)</math> and proceeds counterclockwise, reaching the angle of 45°.		This algorithm starts with the [[circle]] equation. For simplicity, assume the center of the circle is at <math>(0,0)</math>. To start with, consider the first octant only, and draw a curve which starts at point <math>(r,0)</math> and proceeds counterclockwise, reaching the angle of 45°.
Line 111:		Line 111:
	# t1 + y		# t1 + y
	# t1 - x		# t1 - x
	#: The comparison t2 >= 0 is not counted as no real arithmetic takes place. In two's complement representation of the vars only the sign bit has to be checked.		#: The comparison t2 >= 0 is not counted as no real arithmetic takes place. In [[two's complement]] representation of the vars only the [[sign bit]] has to be checked.
	# x=x-1 [x--]		# x=x-1 [x--]

Theki at 18:17, 8 January 2025

2025-01-08T18:17:56Z

← Previous revision		Revision as of 18:17, 8 January 2025
Line 1:		Line 1:
	{{Short description\|Determines the points needed for rasterizing a circle}}		{{Short description\|Determines the points needed for rasterizing a circle}}
	[[File:Midpoint_circle_algorithm_animation_(radius_23).gif\|right\|295px\|thumb\|Rasterizing a circle of radius 23 with the Bresenham midpoint circle algorithm. Only the green {{Color sample\|#00ff00\|description=}} octant is actually calculated, it's simply mirrored eight times to form the other seven octants.]]		[[File:Midpoint_circle_algorithm_animation_(radius_23).gif\|right\|295px\|thumb\|Rasterizing a circle of radius 23 with the Bresenham midpoint circle algorithm. Only the green {{Color sample\|#00ff00\|description=}} octant is actually calculated, it is simply mirrored eight times to form the other seven octants.]]
	[[File:Midpoint circle algorithm, radius 23.png\|thumb\|A circle of radius 23 drawn by the Bresenham algorithm]]		[[File:Midpoint circle algorithm, radius 23.png\|thumb\|A circle of radius 23 drawn by the Bresenham algorithm]]

	In [[computer graphics]], the '''midpoint circle algorithm''' is an algorithm used to determine the points needed for [[rasterizing]] a [[circle]]. It's a generalization of [[Bresenham's line algorithm]]. The algorithm can be further generalized to [[conic section]]s.<ref name="HearnBaker1994">{{cite book\|author1=Donald Hearn\|author2=M. Pauline Baker\|title=Computer graphics\|year=1994\|url=https://archive.org/details/computergraphics0000hear_r7z2\|url-access=registration\|publisher=Prentice-Hall\|isbn=978-0-13-161530-4}}</ref><ref>Pitteway, M.L.V., "[https://academic.oup.com/comjnl/article-pdf/10/3/282/1333509/100282.pdf Algorithm for Drawing Ellipses or Hyperbolae with a Digital Plotter]", Computer J., 10(3) November 1967, pp 282–289</ref><ref>Van Aken, J.R., "[https://ieeexplore.ieee.org/abstract/document/4055918/ An Efficient Ellipse Drawing Algorithm]", CG&A, 4(9), September 1984, pp 24–35</ref>		In [[computer graphics]], the '''midpoint circle algorithm''' is an algorithm used to determine the points needed for [[rasterizing]] a [[circle]]. It is a generalization of [[Bresenham's line algorithm]]. The algorithm can be further generalized to [[conic section]]s.<ref name="HearnBaker1994">{{cite book\|author1=Donald Hearn\|author2=M. Pauline Baker\|title=Computer graphics\|year=1994\|url=https://archive.org/details/computergraphics0000hear_r7z2\|url-access=registration\|publisher=Prentice-Hall\|isbn=978-0-13-161530-4}}</ref><ref>Pitteway, M.L.V., "[https://academic.oup.com/comjnl/article-pdf/10/3/282/1333509/100282.pdf Algorithm for Drawing Ellipses or Hyperbolae with a Digital Plotter]", Computer J., 10(3) November 1967, pp 282–289</ref><ref>Van Aken, J.R., "[https://ieeexplore.ieee.org/abstract/document/4055918/ An Efficient Ellipse Drawing Algorithm]", CG&A, 4(9), September 1984, pp 24–35</ref>

	==Summary==		==Summary==
Line 53:		Line 53:
	Just as with [[Bresenham's line algorithm]], this algorithm can be optimized for integer-based math. Because of symmetry, if an algorithm can be found that only computes the pixels for one octant, the pixels can be reflected to get the whole circle.		Just as with [[Bresenham's line algorithm]], this algorithm can be optimized for integer-based math. Because of symmetry, if an algorithm can be found that only computes the pixels for one octant, the pixels can be reflected to get the whole circle.

	We start by defining the radius error as the difference between the exact representation of the circle and the center point of each pixel (or any other arbitrary mathematical point on the pixel, so long as it's consistent across all pixels). For any pixel with a center at <math>(x_i, y_i)</math>, the radius error is defined as:		We start by defining the radius error as the difference between the exact representation of the circle and the center point of each pixel (or any other arbitrary mathematical point on the pixel, so long as it is consistent across all pixels). For any pixel with a center at <math>(x_i, y_i)</math>, the radius error is defined as:

	:<math>RE(x_i,y_i) = \left\vert x_i^2 + y_i^2 - r^2 \right\vert</math>		:<math>RE(x_i,y_i) = \left\vert x_i^2 + y_i^2 - r^2 \right\vert</math>

Smjg: /* Algorithm */sp/gm

2024-08-08T21:58:26Z

Algorithm: sp/gm

← Previous revision		Revision as of 21:58, 8 August 2024
Line 42:		Line 42:
	:<math>\begin{align} x_{n+1}^2 = x_n^2 - 2y_n - 1 \end{align}</math>		:<math>\begin{align} x_{n+1}^2 = x_n^2 - 2y_n - 1 \end{align}</math>

	Because of the continuity of a circle and because the maxima along both axes is the same, clearly it will not be skipping {{Var\|x}} points as it advances in the sequence. Usually it stays on the same {{Var\|x}} coordinate, and sometimes advances by one to the left.		Because of the continuity of a circle and because the maxima along both axes are the same, clearly it will not be skipping {{Var\|x}} points as it advances in the sequence. Usually it stays on the same {{Var\|x}} coordinate, and sometimes advances by one to the left.

	The resulting coordinate is then translated by adding midpoint coordinates. These frequent integer additions do not limit the [[performance tuning\|performance]] much, as those square (root) computations can be spared in the inner loop in turn. Again, the zero in the transformed circle equation is replaced by the error term.		The resulting coordinate is then translated by adding midpoint coordinates. These frequent integer additions do not limit the [[performance tuning\|performance]] much, as those square (root) computations can be spared in the inner loop in turn. Again, the zero in the transformed circle equation is replaced by the error term.
Line 107:		Line 107:

	So we get countable operations within main-loop:		So we get countable operations within main-loop:
	# The comparison x >= y (is counted as a ~~substraction~~: x - y >= 0 )		# The comparison x >= y (is counted as a subtraction: x - y >= 0)
	# y=y+1 [y++]		# y=y+1 [y++]
	# t1 + y		# t1 + y
	# t1 - x		# t1 - x
	## The comparison t2 >= 0 is ~~NOT~~ counted as no real arithmetic takes place. In ~~Two~~'s-complement representation of the vars only the sign bit has to be checked.		#: The comparison t2 >= 0 is not counted as no real arithmetic takes place. In two's complement representation of the vars only the sign bit has to be checked.
	# x=x-1 [x--]		# x=x-1 [x--]

Smjg: /* Summary */punc

2024-08-08T21:45:30Z

Summary: punc

← Previous revision		Revision as of 21:45, 8 August 2024
Line 6:		Line 6:

	==Summary==		==Summary==
	This algorithm draws all eight octants simultaneously, starting from each cardinal direction (0°, 90°, 180°, 270°) and extends both ways to reach the nearest multiple of 45° (45°, 135°, 225°, 315°). It can determine where to stop because when {{Var\|y}} = {{Var\|x}}, it has reached 45°. The reason for using these angles is shown in the above picture: As {{Var\|x}} increases, it neither skips nor repeats any {{Var\|x}} value until reaching 45°. So during the ''while'' loop, {{Var\|x}} increments by 1 with each iteration, and {{Var\|y}} decrements by 1 on occasion, never exceeding 1 in one iteration. This changes at 45° because that is the point where the tangent is {{Var\|rise}}={{Var\|run}}. Whereas {{Var\|rise>run}} before and {{Var\|rise<run}} after.		This algorithm draws all eight octants simultaneously, starting from each cardinal direction (0°, 90°, 180°, 270°) and extends both ways to reach the nearest multiple of 45° (45°, 135°, 225°, 315°). It can determine where to stop because, when {{Var\|y}} = {{Var\|x}}, it has reached 45°. The reason for using these angles is shown in the above picture: As {{Var\|x}} increases, it neither skips nor repeats any {{Var\|x}} value until reaching 45°. So during the ''while'' loop, {{Var\|x}} increments by 1 with each iteration, and {{Var\|y}} decrements by 1 on occasion, never exceeding 1 in one iteration. This changes at 45° because that is the point where the tangent is {{Var\|rise}}={{Var\|run}}. Whereas {{Var\|rise>run}} before and {{Var\|rise<run}} after.

	The second part of the problem, the determinant, is far trickier. This determines when to decrement {{Var\|y}}. It usually comes after drawing the pixels in each iteration, because it never goes below the radius on the first pixel. Because in a continuous function, the function for a sphere is the function for a circle with the radius dependent on {{Var\|z}} (or whatever the third variable is), it stands to reason that the algorithm for a discrete(voxel) sphere would also rely on ~~this~~ ~~Midpoint~~ circle algorithm. But when looking at a sphere, the integer radius of some adjacent circles is the same, but it is not expected to have the same exact circle adjacent to itself in the same hemisphere. Instead, a circle of the same radius needs a different determinant, to allow the curve to come in slightly closer to the center or extend out farther.		The second part of the problem, the determinant, is far trickier. This determines when to decrement {{Var\|y}}. It usually comes after drawing the pixels in each iteration, because it never goes below the radius on the first pixel. Because in a continuous function, the function for a sphere is the function for a circle with the radius dependent on {{Var\|z}} (or whatever the third variable is), it stands to reason that the algorithm for a discrete ([[voxel]]) sphere would also rely on the midpoint circle algorithm. But when looking at a sphere, the integer radius of some adjacent circles is the same, but it is not expected to have the same exact circle adjacent to itself in the same hemisphere. Instead, a circle of the same radius needs a different determinant, to allow the curve to come in slightly closer to the center or extend out farther.

	<gallery mode="packed" class="center" caption="One hundred fifty [[concentric circles]] drawn with the midpoint circle algorithm." heights="191px">		<gallery mode="packed" class="center" caption="One hundred fifty [[concentric circles]] drawn with the midpoint circle algorithm." heights="191px">

78.124.136.51: /* Summary */

2024-06-19T12:58:09Z

Summary

← Previous revision		Revision as of 12:58, 19 June 2024
Line 6:		Line 6:

	==Summary==		==Summary==
	This algorithm draws all eight octants simultaneously, starting from each cardinal direction (0°, 90°, 180°, 270°) and extends both ways to reach the nearest multiple of 45° (45°, 135°, 225°, 315°). It can determine where to stop because when {{Var\|y}} = {{Var\|x}}, it has reached 45°. The reason for using these angles is shown in the above picture: As {{Var\|x}} increases, it neither skips nor repeats any {{Var\|x}} value until reaching 45°. So during the ''while'' loop, {{Var\|x}} increments by 1 each iteration, and {{Var\|y}} decrements by 1 on occasion, never exceeding 1 in one iteration. This changes at 45° because that is the point where the tangent is {{Var\|rise}}={{Var\|run}}. Whereas {{Var\|rise>run}} before and {{Var\|rise<run}} after.		This algorithm draws all eight octants simultaneously, starting from each cardinal direction (0°, 90°, 180°, 270°) and extends both ways to reach the nearest multiple of 45° (45°, 135°, 225°, 315°). It can determine where to stop because when {{Var\|y}} = {{Var\|x}}, it has reached 45°. The reason for using these angles is shown in the above picture: As {{Var\|x}} increases, it neither skips nor repeats any {{Var\|x}} value until reaching 45°. So during the ''while'' loop, {{Var\|x}} increments by 1 with each iteration, and {{Var\|y}} decrements by 1 on occasion, never exceeding 1 in one iteration. This changes at 45° because that is the point where the tangent is {{Var\|rise}}={{Var\|run}}. Whereas {{Var\|rise>run}} before and {{Var\|rise<run}} after.

	The second part of the problem, the determinant, is far trickier. This determines when to decrement {{Var\|y}}. It usually comes after drawing the pixels in each iteration, because it never goes below the radius on the first pixel. Because in a continuous function, the function for a sphere is the function for a circle with the radius dependent on {{Var\|z}} (or whatever the third variable is), it stands to reason that the algorithm for a discrete(voxel) sphere would also rely on this Midpoint circle algorithm. But when looking at a sphere, the integer radius of some adjacent circles is the same, but it is not expected to have the same exact circle adjacent to itself in the same hemisphere. Instead, a circle of the same radius needs a different determinant, to allow the curve to come in slightly closer to the center or extend out farther.		The second part of the problem, the determinant, is far trickier. This determines when to decrement {{Var\|y}}. It usually comes after drawing the pixels in each iteration, because it never goes below the radius on the first pixel. Because in a continuous function, the function for a sphere is the function for a circle with the radius dependent on {{Var\|z}} (or whatever the third variable is), it stands to reason that the algorithm for a discrete(voxel) sphere would also rely on this Midpoint circle algorithm. But when looking at a sphere, the integer radius of some adjacent circles is the same, but it is not expected to have the same exact circle adjacent to itself in the same hemisphere. Instead, a circle of the same radius needs a different determinant, to allow the curve to come in slightly closer to the center or extend out farther.

104.228.105.47: /* Jesko's Method */

2024-05-04T21:35:01Z

Jesko's Method

← Previous revision		Revision as of 21:35, 4 May 2024
Line 103:		Line 103:
	The algorithm has already been explained to a large extent, but there are further optimizations.		The algorithm has already been explained to a large extent, but there are further optimizations.

	The new presented method<ref>For the history of the publication of this algorithm see https://schwarzers.com/algorithms</ref> gets along with only 5 arithmetic operations per step (for 8 pixels) and is thus ~~just~~ for low-performate systems ~~best suitable~~. In the "if" operation, only the sign is checked (positive? Yes or No) and there is a variable assignment, which is also not considered an arithmetic operation.		The new presented method<ref>For the history of the publication of this algorithm see https://schwarzers.com/algorithms</ref> gets along with only 5 arithmetic operations per step (for 8 pixels) and is thus best suitable for low-performate systems. In the "if" operation, only the sign is checked (positive? Yes or No) and there is a variable assignment, which is also not considered an arithmetic operation.
	The initialization in the first line (shifting by 4 bits to the right) is only due to beauty and not really necessary.		The initialization in the first line (shifting by 4 bits to the right) is only due to beauty and not really necessary.

DavidHolmes0: deployed {{Var|...}} for variables in a few places

2024-02-12T14:27:30Z

deployed {{Var|...}} for variables in a few places

← Previous revision		Revision as of 14:27, 12 February 2024
Line 6:		Line 6:

	==Summary==		==Summary==
	This algorithm draws all eight octants simultaneously, starting from each cardinal direction (0°, 90°, 180°, 270°) and extends both ways to reach the nearest multiple of 45° (45°, 135°, 225°, 315°). It can determine where to stop because when {{Var\|y}} = {{Var\|x}}, it has reached 45°. The reason for using these angles is shown in the above picture: As {{Var\|x}} increases, it neither skips nor repeats any {{Var\|x}} value until reaching 45°. So during the ''while'' loop, {{Var\|x}} increments by 1 each iteration, and {{Var\|y}} decrements by 1 on occasion, never exceeding 1 in one iteration. This changes at 45° because that is the point where the tangent is rise=run. Whereas rise>run before and rise<run after.		This algorithm draws all eight octants simultaneously, starting from each cardinal direction (0°, 90°, 180°, 270°) and extends both ways to reach the nearest multiple of 45° (45°, 135°, 225°, 315°). It can determine where to stop because when {{Var\|y}} = {{Var\|x}}, it has reached 45°. The reason for using these angles is shown in the above picture: As {{Var\|x}} increases, it neither skips nor repeats any {{Var\|x}} value until reaching 45°. So during the ''while'' loop, {{Var\|x}} increments by 1 each iteration, and {{Var\|y}} decrements by 1 on occasion, never exceeding 1 in one iteration. This changes at 45° because that is the point where the tangent is {{Var\|rise}}={{Var\|run}}. Whereas {{Var\|rise>run}} before and {{Var\|rise<run}} after.

	The second part of the problem, the determinant, is far trickier. This determines when to decrement {{Var\|y}}. It usually comes after drawing the pixels in each iteration, because it never goes below the radius on the first pixel. Because in a continuous function, the function for a sphere is the function for a circle with the radius dependent on {{Var\|z}} (or whatever the third variable is), it stands to reason that the algorithm for a discrete(voxel) sphere would also rely on this Midpoint circle algorithm. But when looking at a sphere, the integer radius of some adjacent circles is the same, but it is not expected to have the same exact circle adjacent to itself in the same hemisphere. Instead, a circle of the same radius needs a different determinant, to allow the curve to come in slightly closer to the center or extend out farther.		The second part of the problem, the determinant, is far trickier. This determines when to decrement {{Var\|y}}. It usually comes after drawing the pixels in each iteration, because it never goes below the radius on the first pixel. Because in a continuous function, the function for a sphere is the function for a circle with the radius dependent on {{Var\|z}} (or whatever the third variable is), it stands to reason that the algorithm for a discrete(voxel) sphere would also rely on this Midpoint circle algorithm. But when looking at a sphere, the integer radius of some adjacent circles is the same, but it is not expected to have the same exact circle adjacent to itself in the same hemisphere. Instead, a circle of the same radius needs a different determinant, to allow the curve to come in slightly closer to the center or extend out farther.

DavidHolmes0: italicized "while" to avoid confusion between pseudocode versus English. I found no entry in WP's Manual of Style to address this issue, so I copied the quoting from the article on while loops. Improvement from a more knowledgeable editor would be welcome.

2024-02-12T14:21:54Z

italicized "while" to avoid confusion between pseudocode versus English. I found no entry in WP's Manual of Style to address this issue, so I copied the quoting from the article on while loops. Improvement from a more knowledgeable editor would be welcome.

← Previous revision		Revision as of 14:21, 12 February 2024
Line 6:		Line 6:

	==Summary==		==Summary==
	This algorithm draws all eight octants simultaneously, starting from each cardinal direction (0°, 90°, 180°, 270°) and extends both ways to reach the nearest multiple of 45° (45°, 135°, 225°, 315°). It can determine where to stop because when {{Var\|y}} = {{Var\|x}}, it has reached 45°. The reason for using these angles is shown in the above picture: As {{Var\|x}} increases, it neither skips nor repeats any {{Var\|x}} value until reaching 45°. So during the while loop, {{Var\|x}} increments by 1 each iteration, and {{Var\|y}} decrements by 1 on occasion, never exceeding 1 in one iteration. This changes at 45° because that is the point where the tangent is rise=run. Whereas rise>run before and rise<run after.		This algorithm draws all eight octants simultaneously, starting from each cardinal direction (0°, 90°, 180°, 270°) and extends both ways to reach the nearest multiple of 45° (45°, 135°, 225°, 315°). It can determine where to stop because when {{Var\|y}} = {{Var\|x}}, it has reached 45°. The reason for using these angles is shown in the above picture: As {{Var\|x}} increases, it neither skips nor repeats any {{Var\|x}} value until reaching 45°. So during the ''while'' loop, {{Var\|x}} increments by 1 each iteration, and {{Var\|y}} decrements by 1 on occasion, never exceeding 1 in one iteration. This changes at 45° because that is the point where the tangent is rise=run. Whereas rise>run before and rise<run after.

	The second part of the problem, the determinant, is far trickier. This determines when to decrement {{Var\|y}}. It usually comes after drawing the pixels in each iteration, because it never goes below the radius on the first pixel. Because in a continuous function, the function for a sphere is the function for a circle with the radius dependent on {{Var\|z}} (or whatever the third variable is), it stands to reason that the algorithm for a discrete(voxel) sphere would also rely on this Midpoint circle algorithm. But when looking at a sphere, the integer radius of some adjacent circles is the same, but it is not expected to have the same exact circle adjacent to itself in the same hemisphere. Instead, a circle of the same radius needs a different determinant, to allow the curve to come in slightly closer to the center or extend out farther.		The second part of the problem, the determinant, is far trickier. This determines when to decrement {{Var\|y}}. It usually comes after drawing the pixels in each iteration, because it never goes below the radius on the first pixel. Because in a continuous function, the function for a sphere is the function for a circle with the radius dependent on {{Var\|z}} (or whatever the third variable is), it stands to reason that the algorithm for a discrete(voxel) sphere would also rely on this Midpoint circle algorithm. But when looking at a sphere, the integer radius of some adjacent circles is the same, but it is not expected to have the same exact circle adjacent to itself in the same hemisphere. Instead, a circle of the same radius needs a different determinant, to allow the curve to come in slightly closer to the center or extend out farther.

DavidHolmes0: minor improvement in English attempted

2024-02-12T14:17:36Z

minor improvement in English attempted

← Previous revision		Revision as of 14:17, 12 February 2024
Line 6:		Line 6:

	==Summary==		==Summary==
	This algorithm draws all eight octants simultaneously, starting from each cardinal direction (0°, 90°, 180°, 270°) and extends both ways to reach the nearest multiple of 45° (45°, 135°, 225°, 315°). It can determine where to stop because when {{Var\|y}} = {{Var\|x}}, it has reached 45°. The reason for using these angles is shown in the above picture: As {{Var\|x}} increases, it ~~does~~ ~~not skip~~ nor ~~repeat~~ any {{Var\|x}} value until reaching 45°. So during the while loop, {{Var\|x}} increments by 1 each iteration, and {{Var\|y}} decrements by 1 on occasion, never exceeding 1 in one iteration. This changes at 45° because that is the point where the tangent is rise=run. Whereas rise>run before and rise<run after.		This algorithm draws all eight octants simultaneously, starting from each cardinal direction (0°, 90°, 180°, 270°) and extends both ways to reach the nearest multiple of 45° (45°, 135°, 225°, 315°). It can determine where to stop because when {{Var\|y}} = {{Var\|x}}, it has reached 45°. The reason for using these angles is shown in the above picture: As {{Var\|x}} increases, it neither skips nor repeats any {{Var\|x}} value until reaching 45°. So during the while loop, {{Var\|x}} increments by 1 each iteration, and {{Var\|y}} decrements by 1 on occasion, never exceeding 1 in one iteration. This changes at 45° because that is the point where the tangent is rise=run. Whereas rise>run before and rise<run after.

	The second part of the problem, the determinant, is far trickier. This determines when to decrement {{Var\|y}}. It usually comes after drawing the pixels in each iteration, because it never goes below the radius on the first pixel. Because in a continuous function, the function for a sphere is the function for a circle with the radius dependent on {{Var\|z}} (or whatever the third variable is), it stands to reason that the algorithm for a discrete(voxel) sphere would also rely on this Midpoint circle algorithm. But when looking at a sphere, the integer radius of some adjacent circles is the same, but it is not expected to have the same exact circle adjacent to itself in the same hemisphere. Instead, a circle of the same radius needs a different determinant, to allow the curve to come in slightly closer to the center or extend out farther.		The second part of the problem, the determinant, is far trickier. This determines when to decrement {{Var\|y}}. It usually comes after drawing the pixels in each iteration, because it never goes below the radius on the first pixel. Because in a continuous function, the function for a sphere is the function for a circle with the radius dependent on {{Var\|z}} (or whatever the third variable is), it stands to reason that the algorithm for a discrete(voxel) sphere would also rely on this Midpoint circle algorithm. But when looking at a sphere, the integer radius of some adjacent circles is the same, but it is not expected to have the same exact circle adjacent to itself in the same hemisphere. Instead, a circle of the same radius needs a different determinant, to allow the curve to come in slightly closer to the center or extend out farther.