Preset movement math

[geozop]

I have usually found that when using a preset movement, it doesn't quite move fast enough, rotate enough at a certain distance, or something that doesn't quite make it useful for what I need; even though it was quite close. Unfortunately, it does not tell you the math/equations that are the presets. If those were known

Some movements are easy enough to figure out the equations (such as shift rotate left), but others (like blocky partial out) elude me. I assume other AVS creators have similar problems, so I thought a topic for reverse-engineering these movement could help everyone.

Some that I have "decoded":

big swirl out:
d=d-sin(d)/25;
r=r-0.2*(d-0.5)

medium swirl:
d=d+0.001;
r=r-0.025*cos(d*16)

sunburster:
d=d-(sin(d)*0.1*abs(sin(r*18)));
r=r+0.004
(I find that this works better than the preset, because ther preset has an up-and-left movement, in addition to the sunbursting)

swirling around both ways at once:
d=d+0.001;
r=r-0.1*cos(d*16+0.75)
(four times more than medium swirl, with a bit of an offset)

bubbling ******ds:
d=d-0.025*pow(1.33*sin(d*2*1.57)-0.25,4);
r=r-log(0.01+d)/100
(same thing as with sunburster, but the movement of the center did not look good without the r movement)

5 pointed distro:
d=d-0.1*sin(d)*abs(sin(r*2.5+1.57));
r=r+0.005
(it's a good likeness, but it's not as exact as I'd like)

I think blocky partial out can be done using rect coordinates... Slight fuzzify looks like it could be done like the swirl to center preset, except that the swirls are only a few pixels wide, rather than a third of the screen.

Hope that helped...

[Montana]

big thanks, (i think)

[UnConeD]

This one approximates the tunnel movement. The real 'tunnel' seems to have its rotation point slightly to the left of the center, but other than that it's near perfect.

df=d-.16;df=if(below(df,0.02),0.02,df);
d=d-sqr(df)*.23;r=r+0.035

A tip for decoding the movements is to create a preset that contains this:

-Effect List (Input: ignore / Output: replace)
Simple -> Oscilloscope Dots
Movement (Original)
-Effect List (Input: ignore / Output: subtractive blend 1)
Simple -> Oscilloscope Dots
Movement (Your own)

Now you will see the difference between the two movements. The brighter the picture, the worse you're doing. You should also see your movement as a 'black layer' over the original. It can help you decode the movement.

[Montana]

unconed, whatta hell u talking about
tunneling movement is
d=sin(d);r=0.05+r

[UnConeD]

I was "watta hell" talking about another solution for the tunnel which I found experimentally. You found a shorter one, nice. If you compare the two graphs (pop the formula in a superscope and plot them), you'll see that mine strongly resembles a sine-wave near 0-1.
I checked your solution with the two-effect-list trick though and it seems the rotation factor is slightly too high.

[Montana]

adjust 0.05 to the value you want then

[BlurPak2k1]

well i sound this out too.
but d=sin(d); and d=atan(d); have simular effect as well.

[UnConeD]

By the way I think it's (sorta) impossible to do blocky partial out for now. I remember AVS not providing width/height in the movement, so you could only make it work on one resolution.

Of course you can make something close, but the real idea here is to get exact copies right?

[Montana]

blur>> not really, d=sin(d) has a move "tunnel-like" depth, while d=atan(d), cuts the whole picture in2 4 parts,

unconed>> can u do the decode the "bleedin" movement

[TasZ69]

Bleedin

d=atan(d)*1.05;
r=.01+r;

I'm pretty sure this is it. i've got a slight problem remembering it right now.

[Warrior of the Light]

welcome to 2006.

the code for bleedin' is:
t = cos(d * $PI);
r = r + (0.07 * t);
d = d * (0.98 + t * 0.10);

[Mr_Nudge]

who uses preset movement anyway?

[Warrior of the Light]

oh, I see this is your first post here.. Welcome!

[TasZ69]

ya, that was my first. i'm using a friends internet cuz i don't have any, so i couldn't check to see i was right. mine's actually kinda close. it's something from a really old avs i made when i first got winamp (2.something I think). but ya, thanx for the welcome.

[Montana]

oh god at the noobness of me. i'm uberembarrased.

[StevenRoy]

Oh, it's possible to do a "Blocky Partial Out". I've recently experimented with some very similar effects in Movement code. The trick is to use extra variables to actually COUNT the pixels (instead of relying on sw and sh). For example:

nr=equal(y,yy); // "New Row" is 0 when y changes.
nx=nr*((nx+1)&3); // Either increment or reset nx (from 0 to 3)
ny=(ny+bnot(nr))&3; // Increment ny (from 0 to 3) when y changes
yy=y; // This is how we tell when it changes.

vx=if(nx,vx,x); // Save X and Y coordinates for each 4x4 square's
vy=if(ny-1,vy,y); // upper left pixel.

insq=(nx&2)|((ny-1)&2); // "In square" is 0 if we're in one of the 2x2 squares.
x=if(insq,x,(vx*7)/8); // If we are, perform the magic!
y=if(insq,y,(vy*7)/8);

Well, it's still not -exactly- like the BPO, but it's the best approximation I can come up with this late at night.

This pixel-counting trick is so unobvious (especially for something like a Movement that isn't dynamic!), I was -so- tempted to keep it a secret, just so that I could use it in a preset (for the compilation, of course) and then have a bunch of people thinking "How the heck did he do that?" ...I love when people think that!

But there it is.

I bet you guys (well, a few of you) can turn it into all sorts of nifty stuff now! Have fun!

[jheriko]

Originally posted by Mr_Nudge
who uses preset movement anyway?

I love movement. Good for making arbitrarily complex raytraces in realtime (given a small loading time) Also there are other nifty tricks you can do with its per-pixel accuracy which dynamic movement forbids with its terrible resolution. See 'Jheriko - There is no Spoon'.

StevenRoy: I hate to belittle your fantastic discovery, but why not use sw and sh? Counting those pixels is a good idea, but more work (code) for no obvious benefit (to me). I'd also be willing to bet someone has done the counting trick before since it is quite trivial.

BTW: Another good place to 'count pixels' is in a Dynamic Movement, althought the utility is somewhat different: you can 'count' the current position in the grid and use it to access (g)megabuf for whatever reason. (Creating a faster Whittaker solver maybe )

Anyway, maybe someone should lock this age-old thread now that the problems are solved and it is outdated?