- AVS
- Super Ellipsoid
Archive: Super Ellipsoid
UIUC85
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.
Jaak
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
Jaak
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
UIUC85
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.
UIUC85
11th January 2004 19:48 UTC
this is what I was trying to send you jaak.
UIUC85
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???
UnConeD
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.
UIUC85
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...
UIUC85
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.
UIUC85
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!
UnConeD
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.
UIUC85
13th January 2004 02:36 UTC
hmmm... That's pretty helpful. thanks again unconed. I'll see what I can work out.
UIUC85
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?
UnConeD
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.
UIUC85
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.
UnConeD
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.
UIUC85
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));
UnConeD
13th January 2004 18:02 UTC
No, you use asin(sin(atan2())).
UIUC85
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.
UnConeD
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.
UIUC85
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.
jheriko
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.
UIUC85
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.
UnConeD
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).