I would like to work on this task.

This task has been assigned to Andromeda Galaxy. You have 72 hours to complete this task, good luck!

Hi,

I cannot find any general formula for the surface area of the ellipsoid, and as far as I can tell, even if it was derived at some point it would have to contain elliptical integrals. Can you please advise?

The claim on this task has been removed, someone else can claim it now.

This is a hint I posted to the brlcad-devel mailing list on this task that might help someone make progress:

This is a difficult one.  I don't know of a way to directly evaluate the surface area, but you could converge to a definably accurate estimate by sampling surface points.

For example, you could iterate over the x(u,v) y(u,v) and z(u,v) parametric representation described on Wikipedia, incrementing by maybe PI/4 for starters, and using the surface points as defining a surface tessellation.  You can sample the u,v in a way that creates quadrilateral patches (rectangles), which you can sum up easily.  You then recalculate with PI/(4+N) or PI/(4*N), for example PI/8 then PI/16 then PI/32 .. etc, and stop when the area summation converges to a solution within some defined tolerance (like 0.005).

Alternatively for that task, you could implement any one of the special cases A) e=0,n=0 or e=2,n=0 (boxes); B) e=0,n=1 or e=2,n=1 (four cylinder sections); C) e=0,n=2 or e=2,n=2 (prisms); D) e=1,n=0 or e=1,n=2 (a cylinder/cone); or E) e=1,n=1 (a sphere).  They're all individually pretty simple (and an opportunity to complete five different tasks). 

I would like to work on this task.

This task has been assigned to Andromeda Galaxy. You have 72 hours to complete this task, good luck!

While this algorithm is fairly slow, I have spent probably ~6hrs trying to optimize it (profiling says that a __signbitl linux function is taking the majority of the time); to do this, I have written a small tester program that has a geometry written in it and runs the algorithm on it. This version of the algorithm is very slow with precisions 1024; however, it returned an area less than 2 away from the correct area for all of the shapes that I tested it on. I would not mind doing a follow-on task to attempt to optimize it further; I would also like to do a follow on that involves writing tests for it.

The work on this task is ready to be reviewed.

Congratulations, this task has been completed successfully.

There were several issues with this patch, but I marked it complete because this is easily one of the hardest tasks in our list and your implementation looks functionally okay (though possibly some major bugs).  Here are some of the issues noted that you can fix on commit:

• _rt_superell_surf_area_box() should be static


• struct rt_superell_internal *sip should be const and passed as const in most places


• _rt_superell_c() and _rt_superell_s() are cryptic names


• sgn() is unnecessarily/unhelpfully truncated too


• sgn() returns an int, which means _rt_superell_c() and _s() will be doing integer math which doesn't look like what you intended.  should return a fastf_t or be a cast in the caller.


• can drop the _rt_ prefix for the static funcs -- use superell_ instead 


• any numeric constants should be documented (what/why) briefly, for example:




• _rt_superell_surf_area_general()'s two loops, why -pi to pi and -pi/2 to pi/2


• rt_superell_surf_area() has three: the initial 64, the *=4, and 0.005.  Why not initial 128 or 3 or 823482?  Why not *=2 or *=8 or *=123? 




• the 0.005 can probably be replaced with BN_TOL_DIST (which doesn't need a comment)


• you left debugging print statements (bu_log and printf)

A follow-on task has been posted: http://www.google-melange.com/gci/task/view/google/gci2013/5895393510424576

This was committed as r59250 with the changes that you suggested.