approximating circle with given number of segments

Is there better way to calculate circle from radius and num of vertices? My solution compute sin and cos for every vertex. Is it necessary?

void getCircle2D(Vector2 * perimeterPointsArray, int32 numOfPo开发者_JAVA技巧ints, Vector2 & center, flt32 radius)
{
    ASSERT(numOfPoints >= 3);
    flt32 pieceAngle = MathConst::TAU / numOfPoints;
    flt32 iterAngle = 0;
    for (int32 i = 0; i < numOfPoints; ++i)
    {
        perimeterPointsArray[i] = Vector2(radius * cos(iterAngle) + center.x, radius * sin(iterAngle) + center.y);
        iterAngle += pieceAngle;
    }
}

Your suggested approach should be the usual method to do it. But maybe you can come up with an iterative computation using the following addition theorems (see Wikipedia):

sin(a+b) = sin(a)*cos(b) + cos(a)*sin(b)
cos(a+b) = cos(a)*cos(b) - sin(a)*sin(b)

Where in your case a is the previous angle (whose cos and sin you just computed) and b is the constant angle step (whose cos and sin are also constant, of course). So something like this could work:

void getCircle2D(Vector2 * perimeterPointsArray, int32 numOfPoints, Vector2 & center, flt32 radius)
{
    flt32 pieceAngle = MathConst::TAU / numOfPoints;
    flt32 sinb = sin(pieceAngle), cosb = cos(pieceAngle);
    flt32 sina = 0.0, cosa = 1.0;
    for (int32 i = 0; i < numOfPoints; ++i)
    {
        perimeterPointsArray[i] = Vector2(radius * cosa + center.x, radius * sina + center.y);
        flt32 tmp = sina * cosb + cosa * sinb;
        cosa = cosa * cosb - sina * sinb;
        sina = tmp;
    }
}

Here you only have to compute one sin and one cos (that could even be precomputed if the number of points is known at compile time).

@yi_H I don't know if the circle rasterization algorithm is really suited for floating point circle approximation, but maybe in floating point it generalizes to the above mentioned iterative computation.

You don't need sin and cos:

Midpoint circle algorithm. It's for pixel graphics but should be very easy to modify it to create verices. Of course this only makes sense if the number of vertices is comparable to the number of pixels (say an order of magnitude smaller).

You could calculate half the points and then mirror around the X center.