Tips&Tricks in AVS

I love this forum. Many thanks sidd. 😁

value = value * (1-speed) + target * speed;

or

value = value + (target - value) * speed

page1
It's not answered there, though.
Is that what you wanted to say?
Then why don't you say it?
Say : There's a question on page1 that hasn't been answered.
Else it'll look like you've been randomly cutting&pasting again.

im more confused than normal..

/me agrees with sidhartha
For anyone who doesn't understand ths sign(var) function, it returns 1 when var>0 and -1 when var<0 and returns 0 when var=0.
sign(.3)=1;sign(1000)=1;
sign(-.4)=-1;sign(-103)=-1;
sign(0)=0;
I am sure this was mentioned somewere else, but I just finally figured that all out for myself.

thx, didn't knew that. 🙂

A few people asked for per pixel code in Color Modifier, this can be done easily by
putting a Buffer Save before Cmod (save&replace) and a "no movement just blend" DM with that buffer as input after it.

I found an interesting trick with a texer...

Make a greyscale picture that looks like a cloud (I stole a quake3 sky texture and faded out the edges) then make a 3d ssc with an 'n' value of about 10-20, colour it how you like, use the (masked) cloud texture as a texer and tada, easy cool looking fog.

Looks impressive over raytraced stuff if you sync the ssc.

s-t: actually, no it doesn't. it tries really hard but it never works. i used to have a lot of trouble with it cos for some reason it didn't always return the right numbers. i recently realized (thanks to the help of regwatch) that it returns slightly less than 1 or -1, so this sort of thing happens:
equal(sign(1)*10,10)==0
i don't know exactly how to make it work perfectly, but i do know that if you use abs(x)/x it returns the sign of x correctly.

thanks atero..
thats really useful
perhaps you should suggest this to justin while developments are underway.

That abs(x)/x will probably come in handy at some stage.. tho i cant think of what for at the moment.

gaekwad2: what?

Is there any way I can use rand to generate a random number on each beat, andf be able to use the random numbers in two different scopes? IE,

-Scope 1:

beat:

q=(rand(21)-10)*0.01;

-Scope 2:

q=(random nubmer that was generated in scope 1.

Is this at all possible?

yeah you can...

I'm not sure how to do it on pre-avs2.7 visualisations...but if you have avs2.7, I'm pretty sure you could just assign the random number to a reg##....eg:

beat (scope 1):

reg01=rand(100)/1000;

frame (scope 2):

x=reg01....or whatever you wanna do with it

Wow, I didn't know 2.7 could do that! Anyway, I'm gonna stick to 2.5 till Winamp 5 gets offically released. Any other ideas?

search for "random", there's an explanation somewhere (I just can't remember where)

While your using AVS 2.5 you could use an almost fake number generator.

(getosc(0.47,0,0)*8753%100)/500-0.1 - This function will take the sound value and do some modulos division to give you a random number.
Atero showed me this, and its very helpful when you want to syhcnronize ssc or dms.

real hue mod:
red=abs(asin(sin(-hue)))/$pi*4-0.333;
green=abs(asin(sin(-hue+$pi*0.333)))/$pi*4-0.333;
blue=abs(asin(sin(-hue-$pi*0.333)))/$pi*4-0.333;
hue is 0..2pi

i'm not sure about sat and lum yet, anyone care to experiment with this?

I've used sine waves to create hue but then you get large portions that are red, green, or blue... I've also done it with straight interpolation where the values change like this:

Red:
¯\__/¯

Green:
/¯¯\__

Blue:
__/¯¯\


As far as lumination goes, you interpolate all the values from (0,0,0) or black, up to the values of your main color, say (1,1,0), and then interpolate the remains up to (1,1,1) or white.

For saturation you interpolate your color down to (.5,.5,.5) or gray. I haven't really seen any set rules on how to change colors or anything but this is what I've gathered from the palettes they use in photoshop to let you pick colors. Obviously you can add a lot more to these if you want.

yar!

hue:
red=min(max(abs(asin(cos(-hue)))/$pi*4-0.333,0),1);
green=min(max(abs(asin(cos(-hue+$pi*0.333)))/$pi*4-0.333,0),1);
blue=min(max(abs(asin(cos(-hue-$pi*0.333)))/$pi*4-0.333,0),1);
sat:
red=red*sat+0.5*(1-sat); blue=blue*sat+0.5*(1-sat); green=green*sat+0.5*(1-sat);
lum:
red=red*min(lum,1-lum)*2+(lum-0.5)*2*above(lum,0.5);
blue=blue*min(lum,1-lum)*2+(lum-0.5)*2*above(lum,0.5);
green=green*min(lum,1-lum)*2+(lum-0.5)*2*above(lum,0.5);

has to be done in that order or else things go fuxery. hue=0..2pi, lum/sat=0..1.

could be sped up/simplified, but i'm too lazy right now....

<edit> fixed the hue filter, before it was -pi..pi

i made a demonstration preset...forgot to attach it :F

(nPostCount+=1)

You mind explaining all that junk? It seems rather excessive to me...

Apparently there are 2 types of HSL color spaces. Atero's is used by eg Windows whereas eg Gimp uses a different HSV scheme that can be calculated this way:
red=(min(max(abs(asin(cos(-hue)))/$pi*4-0.333,0),1)*sat+1-sat)*lum;
green=(min(max(abs(asin(cos(-hue+$pi*0.333)))/$pi*4-0.333,0),1)*sat+1-sat)*lum;
blue=(min(max(abs(asin(cos(-hue-$pi*0.333)))/$pi*4-0.333,0),1)*sat+1-sat)*lum;

yarhar!

i fixed the hue thing again. befoe it wasn't scaled right.
red=min(max(abs(asin(cos(-hue)))/$pi*6-1,0),1);
green=min(max(abs(asin(cos(-hue+$pi*0.333)))/$pi*6-1,0),1);
blue=min(max(abs(asin(cos(-hue-$pi*0.333)))/$pi*6-1,0),1);


<edit> i THINK this is the last fix. the hue setting on the luminosity bar wasn't right.

My particle 🙂

>>>>>> ini:

xd=reg00;yd=reg01;xx=rand(50)/100;

yy=rand(50)/100;xa=xx;ya=yy;

sigx=1;sigy=1;n=2;

ff=if(exy,.99-(rand(10)+1)/100,ff);



>>>>>> per-frame:

// render

x=xp;

y=yp;

red=abs(xa)*10;

green=red*.5;

blue=0;

// movement delay

xa=if(exy,xx,if(i,xa,xa*ff));

ya=if(exy,yy,if(i,ya,ya*ff));

// offset

xp=xd+(yy-ya)*sigx;

yp=yd+(xx-xa)*sigy;

// reset

exy=below(xa,.01);

// start

xd=if(exy,reg00,xd);

yd=if(exy,reg01,yd);

// end

xx=if(exy,rand(50)/100,xx);

yy=if(exy,rand(50)/100,yy);

// speed

ff=if(exy,.99-(rand(10)+1)/100,ff);

// direction

sigx=if(exy,above(rand(10),5)*2-1,sigx);

sigy=if(exy,above(rand(10),5)*2-1,sigy);

Make a texer2 like this with a faded particle image between 50x50 and 65x65.
Now copy this Texer2 ~20-30 times, make a couple with smaller images, and you have a firewerk-style!

Than change reg00 and reg01 (better from SSC with n=0) to move the source of particles!

[edit] plese do not use in your pack *directly this piece of code*, I'll be using it in BuggyAVS-2 😛. Get the idea and make your own 🙂 [/edit]

CHESS

I can make my fastest chess!
My old chess is slow, because it was an superscope with w*2 points... 🙁

...but now it have two movements, and two points. 😉

oh, and one more, related to 2.8 now:

if you want to switch enable/disable effectlist on mouse click, use this code:

o=m;m=getkbmouse(3);

e=if(m&bnot(equal(o,m)),bnot(e),e);

enabled=e;

...this way even if a user holds a mousebutton down for many frames, the enable state won't change until next click.

Want to know the exact value of a "random" number?
The new text offers to write reg## numbers!

example:

SSC:

 init:

n=2;

 frame:

t=t+$pi*.01;

st=sin(t);

reg01=st;

 point:

x=i*2-1;

y=st;

Text:

ypos= $(reg01)

Hey, if you want the number of seconds elapsed after starting the AVS preset, use:
init:
sec=gettime(0);
frame:
t=gettime(sec);

A guide to Cubic Ligation

For this, d/l the attached file (Cubic Ligation) (It also includes the txt file)
it is NOT the same thing as the one in the forums. do NOT replace.

Prerequisite knowledge : SSC knowledge, 3D SSC knowledge, global variables.

CL is mostly a technical doodle for me, but hey, it turned out sexah :P
It only has two distinct scopes, an assigner and many drones.
By a little coding "magic" I was able to make the cube configure itself when more drones are added... nifty huh? 🙂
For tutoring purposes, I will assume that you know the "old" avs functions but has no idea on the new stuffs [namely loop(, gmegabuf(, assign(, and exec3(] Unlikely, but ah well. Read and learn. (please? :P)

/////----------\\\\\

First, the drones (or mindless cubes in this matter). They're any of the scopes after the comment inside the list.

The init only has the n value and a remnant from my SSC template (namely pi=acos(-1). Never deleted that for some reason...). The point part only describes the cube, rotations, and using skip for unnecessant points instead of simple blacking out. Nifty to me, but not sure about you - We won't go into that, but tell me if you think I should...

Anyways, on to the important stuff - The Frame section.
For flexibility, all of the scopes are the same, and yet they correctly fade and resize according to their number. This, people, is the one of the useful uses of global variables.
reg00 is a counter, going by 10s. The first drone increases reg00 by 10 once, so reg00 is 10 for that scope. The second scope adds another 10, so reg00 is 20 for that scope. Once reg00 reaches the last scope, it will pass through the assigner scope again. The assigner does some stuffs with the value and resets reg00 to zero and the cycle starts again. It works like a p-counter in a scope if you've done p2p coding before.

Next is r. It's just the size of the scope - It's simply the counter times "dif" (more on that when we get to the assigner). This is how the scope adjusts itself to the crowd sizewise 😉
Then there's c1. It creates the bw gradient from the first to last. What is reg08, you ask? It is only the final value of reg00 before it is reset. This way, you can get the upper bound of reg00 and a correct gradient can be made.

After that is the recall from the global array (gmegabuf). The assigned value counts down instead of counting up, more on that on the assigner section.
So why was the counting done in tens? Well, for easy recalling. The recalled variable is simply the max number minus the current number plus another number. since the former two are counted in tens, there are 10 possible subvalues for each number. The third number is the subvalue number. x-rotation is 1, y-rotation is 2, z-rotation is 3. Quite a bit easier to code than to have clusters dedicated to each rotation to me 🙂
There's also subvalue #6 in the c1 line - It's the onbeat whiting. Now go back to the point section. Scroll all the way down. As you can see, there's another gmegabuf section. The x-movement is subvalue #4, and the y-movement is subvalue #5.

After the gmegabuf(s, there's the rotation sines and cosines and the rgb assignment. If you need any tutoring there, you're looking at the wrong place.

So how does the delay effect happen? That's next, in the assigner.

(end drone section)

///-------\\\

Second, the (pretty huge) [and halfway 1337] assigner. It's the very first scope, if you don't know which one it is.

First thing that you get to see is what most people are meant to see - dif, the distance variable, and reg51, the aspect ratio. Nothing amazing there.

Now scroll down past the first comment block, down to reg01. If reg01 is now in the topmost line, you should be able to see the assigns.
This set of assigns (and any further ones that begin a line) are the initial settings of the rotations. The leader cube (smallest, right after the comment) gets to use this value directly.


Next, scroll until the first loop( is at top.
This is the heart of the delay effect (as are the later loops). This follows p2p assigning quite closely. First, there's reg00 as the amount of times it is repeated. A bit of an overkill, but I don't care :P (Seriously though, if you're using loop yourself, use the amount of loops needed plus one just in case. don't be wasteful and lazy like me. please?)
After the amount of loops, there's the exec3. I know that the help file only shows exec2, but exec3 exists. It's a bit like exec2 except that it executes two things before returning the value (of the third stuff).
First is the p-counter, assigned using - surprise surprise - assign(. Just think of the comma as an equal sign.
Second is the delay effect. It takes a certain part of an array and assigns to it the part of the array ten "steps" forward. (one step if you count the units as a subvalue like me). Because the assignment "sweeps" from zero up, the nth unit before the assigned unit needs n passes to be assigned. Since this is calculated per frame, it also takes n frames to be assigned, and so we have our delay effect. Gotta love niftiness.

A couple lines down is another assigner for x-y movement, then onbeat lighting.
You may notice by now the repeated p=0. Well, p is set to a much higher number at the end of each loop, so it needs to be reset.
Last is a familiar sight - reg00 and reg08/9. As you can see, reg08 is set to reg00 right before reg00 is reset to 0.

There's the onBeat, nothing special there.

//////

And that's... it I guess.
Implement as you will, no direct ripping thank you. Coin me too 😛

Challenge : Fix the delayed start if you wish. It's fixed in the final version 😉

Nice work!
Very efficiently coded.

Thanks for the tut nic 🙂