Archive: Super Ellipsoid


11th January 2004 10:54 UTC

Super Ellipsoid
I was trying to raytrace a super ellipsoid using whittaker iteration but these are the only parameters that I can get to work. Not sure if it's just the limited abilities of the Whittaker method or something wrong with my code. Anybody have any ideas or comments? I was hoping to make the shape morph according to the music but it doesn't look like thats gonna happen... If you want to mess around with the parameters, go to the bottom of the frame block and change e1 and e2.


11th January 2004 11:41 UTC

Hmm... I think its impossible to make it morph on beat, coz you have to recode whittaker iteration for every shape. But I might be wrong.

But this one could look very ok, needs some work.
oh yea, use alpha=-1/t; for blending, looks better


11th January 2004 12:08 UTC

I just had to toy around with it... killed your spooky rotation what nobody else uses around here and messed around with whittakers...
you still cant modify the disance, but its better now


11th January 2004 19:02 UTC

The great thing about a super ellipsoid is that the shape relies on two constants. If you change them then the shape changes.


11th January 2004 19:48 UTC

this is what I was trying to send you jaak.


12th January 2004 22:27 UTC

Anybody care to help??? maybe? any ideas on how to make to make it work for other variables of e1 and e2???


12th January 2004 23:32 UTC

The problem you're having is signs. pow(x,y) is not defined for x < 0 afaik. Replacing your iteration with the following fixes it here.

t=t - (pow(pow(abs(rx*t+ox)/a1,2/e2) + pow(abs(ry*t+oy)/b1,2/e2),e2/e1) + pow(abs(rz*t+oz)/c1,2/e1) - 1)*wh;

To raytrace every superellipsoid you will need tweaking though, because of the two extremes (cubish vs star).

Maybe you could start with a sphere or cube which encompasses the ellipsoid. You could pick the appropriate starting shape based on e1 and e2 and try various whittaker parameters. If you have some time you could determine the best parameters for a couple of values of e1 and e2, and then fit an analytical function through them to determine semi-optimal parameters for every value of e1 and e2.

Oh and you should replace a1/b1/c1 and e1/e2 by their reciprocals. Repeated divisions by constants are simply a waste of time.


13th January 2004 00:56 UTC

yeah that'd probably work, but when e1 approaches 0 the shape becames more and more unstable. Even if I do adjust the values of the whittaker constant, at e1=.2 parts end up disappearing at certain angles.

Crap. This is gonna be a lot harder to morph fluidly than I thought...


13th January 2004 01:03 UTC

Oh just to attract some people's interest... Here's a superellipsoid that's almost a cube. Sorry about the crappy texture and PLEASE don't bring up optimization crap. I know it's not optimized. That's because it barely works as is and I dont see the point in optimizing if it's easier for me to read and adjust this way. Thank you.


13th January 2004 01:04 UTC

errr forgot the file... I wish you could add files when you edit a message. Did two extra posts because of it... sorry!


13th January 2004 01:28 UTC

The main problem with e1 ~ 0 is that the potential/field values become very large.

Here's an image that can give you some insight into how Whittaker works (attachment).

Graph A shows regular operation. Initially, fixed steps are used to close in on the root. The parameter a in Whittaker determines the steepness of the diagonal lines, which is appropriate in this case.
Graph A also shows how a good initial guess can drastically reduce the amount of iterations: the first 6 iterations all have nearly the same step size. This why starting with a sphere enclosing the ellipsoid is a good idea.
Note also that if the curve were vertically inverted, then the slope would have to be opposite for it to converge on the root on the positive horizontal axis.

Graph B has much larger values, and the slope of the lines is not steep enough. The iterations skip over the root and end up in the last part, which would probably keep getting larger and larger. If this were raytracing, the shape would have become invisible.

Graph C shows a possible fix: by limiting the values and/or step size, you can prevent it from skipping over the hole.
However, it is still best to simply figure the right value for the Whittaker parameter which needs to match the order of size of 1/e1. Try figuring out the relationship between your found whittaker parameters and e1 and see if you can't come up with a formula.


If you're curious about how Newton-Raphson works, instead of a fixed slope, it uses the slope of the tangent to the curve at a specific point. If you apply this to my example curve, you'll notice its behaviour will be erratic unless the initial guess is already close to the root, which is why it's no good for most AVS applications.


13th January 2004 02:36 UTC

hmmm... That's pretty helpful. thanks again unconed. I'll see what I can work out.


13th January 2004 04:14 UTC

I worked out equations that work as long as e1=e2. I attached the file to this reply if you want to watch the superellipsoid morph to the music. Yeah I know the equations I came up with are pretty screwy but they work. If anyone can find some equations that work and are faster let me know. These are the numbers I was working with so have at if you care so please.

e1 | e2 || wh1 | wh2 | wh3 |
.2 | .2 ||.0004| .01 |.125 |
.5 | .5 || .01 | .1 |.333 |
1 | 1 || .1 | .1 | .5 |
1-2| 1-2|| .2 | .5 | .5 |

If e1 is close to zero and e2 goes close to 2 then the nice pattern is thrown off. I couldn't get e1=.2; e2=2; to stay very stable... .000066, .0005, .01 is about as stable as I could get it but it doesn't really stay a consistant shape... I dont know how I'd make equations so they'd fit the difference in e1 and e2... Any ideas?


13th January 2004 11:10 UTC

Just a thought: maybe you could first do a couple of iterations and converge on the symmetric superellipsoid which has the fattest of the two parameters. Then once you get close, switch to more specific parameters depending on the difference or ratio between e1/e2.
The advantage will be that because you'll already be quite close for e.g. e1, then you have more freedom in picking the whittaker constants for the later iterations to make the rest of the shape fit.


13th January 2004 17:27 UTC

Well the problem is some of those shapes just dont stay stable no matter what constants I seem to pick. Try finding constants for e1=.2; e2=2; The shape just doesn't work out too well...

I was also thinking about using the gmegabuf to save the values of t each frame and then using those as the starting values for the next frame. That way it'll be a more accurate guess than 0. That might help with the strict constant problem as well.

Since I had e1=e2, I took out that extra power since e2/e1=1, added some real shading, and fixed the texture mapping a bit. The shading (evaluated the partial derivative of the function) gets rid of most off the ugly edges except when the function changes drastically like the edges of the cubes. This should make the shape look more realistic.


13th January 2004 17:30 UTC

Not bad at all. The only real issue is the ugly wrapping due to atan2. If you don't mind symmetrical textures you should asin(sin()) it.


13th January 2004 17:44 UTC

Hmmm I never knew that trick. That realy helps get rid of that stupid hack line. I think I'll keep working on being able to change e1 and e2 separately, but I like being able to have the shading and I'm not so sure taking the derivative with that extra power is gonna be quite so easy or nearly as efficient as this one was.

The symmetric line seems to be rather wide though... this is how you use that trick right? x=asin(sin(iz/ix));


13th January 2004 18:02 UTC

No, you use asin(sin(atan2())).


13th January 2004 18:15 UTC

Whoa that helps out quite a bit. Any other ideas to add in that might help?

-Fixed the shading (forgot to normalize the vectors) so it looks better especially as in cube form.


13th January 2004 19:42 UTC

You might want to look at other raytracing presets. Mine, Jheriko's, Zevensoft, etc are probably the most technical.


14th January 2004 00:56 UTC

I posted a version in the presets subforum. I like how it turned out a lot. I gave you two credit in the comment. Also added contact information/website :) I'll keep working on the getting different values of e1 and e2. Thanks again.


26th January 2004 03:30 UTC

Originally posted by UIUC85
I was also thinking about using the gmegabuf to save the values of t each frame and then using those as the starting values for the next frame. That way it'll be a more accurate guess than 0. That might help with the strict constant problem as well.
Since Whittaker 'goes one way' using previous parameters as guesses will actually break your code. Maybe using a value slightly 'nearer' than the previous one might work though. It sounds like a good idea in theory since you could probably reduce the number of iterations required to something tiny like 2 or 3 and still get really nice results. I'll have to play with this idea when I get home tomorrow. :)
One problem would be that if someone changed the DM gridsize it would all go to pot.

26th January 2004 03:46 UTC

Let me know if you come up with anything useful. I've tinkered around a bit with it but haven't gotten anything yet.


26th January 2004 12:18 UTC

Jheriko: actually it might work... Whittaker still depends on the sign of the function, which flips around for single roots. If the shape doesn't change much between frames, it could be a good starting point (but multiplied by 0.9 or with a slight negative offset is a good idea).