Stuff like that MAYBE looks cool, but usually the artist has got no idea what he is doing. Using stuff because it looks nice is a lot less effective than making something because it does exactly what you want.
You dont need fancy math to make stuff look good yourself either. In fact that maths for constructing specific stuff is usually the most trivial sort, except in the case of DM.
I would iterate a list of tips for constructing superscopes.... but I have done it before enough times...
The 'fancy' stuff like rotation matrices and raytracing, are only half understood by most who use them. So don't feel down if you don't understand them properly or at all, neither do Tuggummi or PAK-9 or most of the rest... and they still make a ton of awesome presets.
OK ---- I GIVE UP! I'll take my chances and ask...
99 posts
Originally posted by jherikoHey! I understand fancy stuff!
Stuff like that MAYBE looks cool, but usually the artist has got no idea what he is doing. Using stuff because it looks nice is a lot less effective than making something because it does exactly what you want.
You dont need fancy math to make stuff look good yourself either. In fact that maths for constructing specific stuff is usually the most trivial sort, except in the case of DM.
I would iterate a list of tips for constructing superscopes.... but I have done it before enough times...
The 'fancy' stuff like rotation matrices and raytracing, are only half understood by most who use them. So don't feel down if you don't understand them properly or at all, neither do Tuggummi or PAK-9 or most of the rest... and they still make a ton of awesome presets.
Jheriko is right...
I can do fancy iterative (whittaker/newton)-raytracing,
but i cant figure out how to do raytracing the way Pak-9 does.
And Pak-9 doesnt like/understand the raytracing i do.
I can do fancy iterative (whittaker/newton)-raytracing,
but i cant figure out how to do raytracing the way Pak-9 does.
And Pak-9 doesnt like/understand the raytracing i do.
I know all the code that I'm using when it comes to SSC's.
But most of it I learned from ripping the sourcecodes from El-Vis en Nic01 to notepad, and then strip it down to the bit to figure them out. Then I tried to re-assemble them using my own variable names, shape, rotation, movement, colors etc.
Also, I can't create the main core of it by heart though, I usually use some of my (rather messy) templates.
The next thing is to know how to use the 'basic' modules of AVS (i.e. don't use invert and clear every frame at the same time). Old doesn't necessarily mean they're outdated. Experimentate and find out how to use a Water Bump and not make it kill the preset for instance.
Also, don't hesitate to experimentate. Before I created my first 3D SSC, I had created at least 50-60 not-working versions. Set a goal and go for it, one step at a time.
But most of it I learned from ripping the sourcecodes from El-Vis en Nic01 to notepad, and then strip it down to the bit to figure them out. Then I tried to re-assemble them using my own variable names, shape, rotation, movement, colors etc.
Also, I can't create the main core of it by heart though, I usually use some of my (rather messy) templates.
The next thing is to know how to use the 'basic' modules of AVS (i.e. don't use invert and clear every frame at the same time). Old doesn't necessarily mean they're outdated. Experimentate and find out how to use a Water Bump and not make it kill the preset for instance.
Also, don't hesitate to experimentate. Before I created my first 3D SSC, I had created at least 50-60 not-working versions. Set a goal and go for it, one step at a time.
I could never get the craxy DM work that some do, since I'm better with a SSC or a Texer than with something like a DM. I guess some people are better with some bits than others.
Originally posted by JFASISSC and Texer are naturally easier since you position points naturally. DM is hard becasuse you have to manipulate texture co-ordinates... which is pretty unnatural. Its like tying a load of stones to a flexible sheet in a grid, then deciding how far you have to move each stone to warp the sheet so it looks how you want. I advise ignoring it to start with if its not easy for you to work with...
I'm better with a SSC or a Texer than with something like a DM.
Ok, the issue comes down to being able to find ways to tye stones to a map. It's so abstract, and all or most of the guides I have read only scratch the surface, and leave all the discovering to the reader, not even like the good discovery, where you invent methods and such, but you have to figure out what every-single-thing does.
Originally posted by JFASIIts not hard to work out what DM does. If you look at any of the examples or experiment with simple stuff like x=x+1 x=x*2 etc... then you can work it out with out much head scratching. It basically allows you to slide/zoom/spin/warp the image depending on how each grid point's code evaluates.
Ok, the issue comes down to being able to find ways to tye stones to a map. It's so abstract, and all or most of the guides I have read only scratch the surface, and leave all the discovering to the reader, not even like the good discovery, where you invent methods and such, but you have to figure out what every-single-thing does.
There are plenty of guides for DMS floating around, i think very few of them really explain why it works... but they are good enough. PAK-9's programming guide has an excellent section on DM which describes how it functions and provides plenty of example code...
If you have any specific examples that you've been trying to figure out, maybe we could help you with those.
I'm fighting to resist the temptation to place UnconeD's famous line of brand name mazes...
So you're interested in 3D DM's then? I can help with that probably better than I can with 2D ones.
Really? That's very good news, since I kinda sorta get what the 2d Dm's are all about.
Well let me know what you need and I'll gladly explain somethings as best as I can.
Ok, I'm not quite sure if it's 3D or otherwise, but the nice metal blob effects that so many use:
Init
c=6.1 ; sza=0.15 ; r=0.9 ; szb=1.5 ;
Frame
asp=reg03 ; sec=reg00 ; vol=reg01 ; f1=1-sec*(0.5+vol*0.1) ;
spd=vol*sec*0.03 ;
g1=g1*0.9+getspec(0.05,0.5,0) ; g2=g2*0.9+getspec(0.1,0.5,0) ;
g3=g3*0.9+getspec(0.15,0.5,0) ; g4=g4*0.9+getspec(0.2,0.5,0) ;
g5=g5*0.9+getspec(0.25,0.5,0) ; g6=g6*0.9+getspec(0.3,0.5,0) ;
sz1=szb-g1*sza ; sz2=szb-g2*sza ; sz3=szb-g3*sza ;
sz4=szb-g4*sza ; sz5=szb-g5*sza ; sz6=szb-g6*sza ;
xts1=xts1*f1 ; yts1=yts1*f1 ; xts2=xts2*f1 ; yts2=yts2*f1 ;
xts3=xts3*f1 ; yts3=yts3*f1 ; xts4=xts4*f1 ; yts4=yts4*f1 ;
xts5=xts5*f1 ; yts5=yts5*f1 ; xts6=xts6*f1 ; yts6=yts6*f1 ;
xt1=xt1+xts1 ; yt1=yt1+yts1 ; xt2=xt2+xts2 ; yt2=yt2+yts2 ;
xt3=xt3+xts3 ; yt3=yt3+yts3 ; xt4=xt4+xts4 ; yt4=yt4+yts4 ;
xt5=xt5+xts5 ; yt5=yt5+yts5 ; xt6=xt6+xts6 ; yt6=yt6+yts6 ;
sxt1=sin(xt1)*r ; syt1=sin(yt1)*r ; sxt2=sin(xt2)*r ; syt2=sin(yt2)*r ;
sxt3=sin(xt3)*r ; syt3=sin(yt3)*r ; sxt4=sin(xt4)*r ; syt4=sin(yt4)*r ;
sxt5=sin(xt5)*r ; syt5=sin(yt5)*r ; sxt6=sin(xt6)*r ; syt6=sin(yt6)*r ;
Beat
xts1=(rand(131)-75)*spd ; yts1=(rand(131)-75)*spd ;
xts2=(rand(131)-75)*spd ; yts2=(rand(131)-75)*spd ;
xts3=(rand(131)-75)*spd ; yts3=(rand(131)-75)*spd ;
xts4=(rand(131)-75)*spd ; yts4=(rand(131)-75)*spd ;
xts5=(rand(131)-75)*spd ; yts5=(rand(131)-75)*spd ;
xts6=(rand(131)-75)*spd ; yts6=(rand(131)-75)*spd ;
Pixel
ax1=x*asp+sxt1 ; ay1=y+syt1 ; ad1=sqrt(sqr(ax1)+sqr(ay1))*sz1 ;
ax2=x*asp+sxt2 ; ay2=y+syt2 ; ad2=sqrt(sqr(ax2)+sqr(ay2))*sz2 ;
ax3=x*asp+sxt3 ; ay3=y+syt3 ; ad3=sqrt(sqr(ax3)+sqr(ay3))*sz3 ;
ax4=x*asp+sxt4 ; ay4=y+syt4 ; ad4=sqrt(sqr(ax4)+sqr(ay4))*sz4 ;
ax5=x*asp+sxt5 ; ay5=y+syt5 ; ad5=sqrt(sqr(ax5)+sqr(ay5))*sz5 ;
ax6=x*asp+sxt6 ; ay6=y+syt6 ; ad6=sqrt(sqr(ax6)+sqr(ay6))*sz6 ;
alpha=-ad1*ad2*ad3*ad4*ad5*ad6*0.75+1 ;
This is an effect that I see all the time. It comes from the below attachment (many thanks to Tuggummi for such a sweet pack):
Init
c=6.1 ; sza=0.15 ; r=0.9 ; szb=1.5 ;
Frame
asp=reg03 ; sec=reg00 ; vol=reg01 ; f1=1-sec*(0.5+vol*0.1) ;
spd=vol*sec*0.03 ;
g1=g1*0.9+getspec(0.05,0.5,0) ; g2=g2*0.9+getspec(0.1,0.5,0) ;
g3=g3*0.9+getspec(0.15,0.5,0) ; g4=g4*0.9+getspec(0.2,0.5,0) ;
g5=g5*0.9+getspec(0.25,0.5,0) ; g6=g6*0.9+getspec(0.3,0.5,0) ;
sz1=szb-g1*sza ; sz2=szb-g2*sza ; sz3=szb-g3*sza ;
sz4=szb-g4*sza ; sz5=szb-g5*sza ; sz6=szb-g6*sza ;
xts1=xts1*f1 ; yts1=yts1*f1 ; xts2=xts2*f1 ; yts2=yts2*f1 ;
xts3=xts3*f1 ; yts3=yts3*f1 ; xts4=xts4*f1 ; yts4=yts4*f1 ;
xts5=xts5*f1 ; yts5=yts5*f1 ; xts6=xts6*f1 ; yts6=yts6*f1 ;
xt1=xt1+xts1 ; yt1=yt1+yts1 ; xt2=xt2+xts2 ; yt2=yt2+yts2 ;
xt3=xt3+xts3 ; yt3=yt3+yts3 ; xt4=xt4+xts4 ; yt4=yt4+yts4 ;
xt5=xt5+xts5 ; yt5=yt5+yts5 ; xt6=xt6+xts6 ; yt6=yt6+yts6 ;
sxt1=sin(xt1)*r ; syt1=sin(yt1)*r ; sxt2=sin(xt2)*r ; syt2=sin(yt2)*r ;
sxt3=sin(xt3)*r ; syt3=sin(yt3)*r ; sxt4=sin(xt4)*r ; syt4=sin(yt4)*r ;
sxt5=sin(xt5)*r ; syt5=sin(yt5)*r ; sxt6=sin(xt6)*r ; syt6=sin(yt6)*r ;
Beat
xts1=(rand(131)-75)*spd ; yts1=(rand(131)-75)*spd ;
xts2=(rand(131)-75)*spd ; yts2=(rand(131)-75)*spd ;
xts3=(rand(131)-75)*spd ; yts3=(rand(131)-75)*spd ;
xts4=(rand(131)-75)*spd ; yts4=(rand(131)-75)*spd ;
xts5=(rand(131)-75)*spd ; yts5=(rand(131)-75)*spd ;
xts6=(rand(131)-75)*spd ; yts6=(rand(131)-75)*spd ;
Pixel
ax1=x*asp+sxt1 ; ay1=y+syt1 ; ad1=sqrt(sqr(ax1)+sqr(ay1))*sz1 ;
ax2=x*asp+sxt2 ; ay2=y+syt2 ; ad2=sqrt(sqr(ax2)+sqr(ay2))*sz2 ;
ax3=x*asp+sxt3 ; ay3=y+syt3 ; ad3=sqrt(sqr(ax3)+sqr(ay3))*sz3 ;
ax4=x*asp+sxt4 ; ay4=y+syt4 ; ad4=sqrt(sqr(ax4)+sqr(ay4))*sz4 ;
ax5=x*asp+sxt5 ; ay5=y+syt5 ; ad5=sqrt(sqr(ax5)+sqr(ay5))*sz5 ;
ax6=x*asp+sxt6 ; ay6=y+syt6 ; ad6=sqrt(sqr(ax6)+sqr(ay6))*sz6 ;
alpha=-ad1*ad2*ad3*ad4*ad5*ad6*0.75+1 ;
This is an effect that I see all the time. It comes from the below attachment (many thanks to Tuggummi for such a sweet pack):
Eeh, I wouldn't take my code as a example for study...
Im sure PAK-9 can tell you why 🙄
Im sure PAK-9 can tell you why 🙄
Yeah this example of metaballs isn't 3D though unconed did do a 3D metaballs preset. Basically metaballs is a lot like simulating electrical charges. So in concept you create several points that will produce a charge dependent on the distance to the origin of the charge. No matter how far the point being calculated is away from the center of the charge, there is still some amount of charge there. Then when you add in multiple charges you'll end up with a net charge from multiple charges.
Now for some mathy stuff. The equation of a circle (your charge radiates in a circle) is x^2+y^2=r^2. Now if you know the equation for the charge of an electron, 1/r^2, you can plug in the circle equation to get 1/(x^2+y^2)! Yay!
So now how do we make that idea useful. Well we can evaluate this equation for each point on the screen (or DM grid). So assume (x0,y0) is the origin of your point and (x,y) is the point you are evaluating. Simply take the difference and plug it in. 1/((x-x0)^2+(y-y0)^2)
Now if you want to do this for multiple charges you just evaluate the same point for all the charges and then add them together. You MIGHT need a scalar for this depending on how big of blobs you want. Any questions?
Now for some mathy stuff. The equation of a circle (your charge radiates in a circle) is x^2+y^2=r^2. Now if you know the equation for the charge of an electron, 1/r^2, you can plug in the circle equation to get 1/(x^2+y^2)! Yay!
So now how do we make that idea useful. Well we can evaluate this equation for each point on the screen (or DM grid). So assume (x0,y0) is the origin of your point and (x,y) is the point you are evaluating. Simply take the difference and plug it in. 1/((x-x0)^2+(y-y0)^2)
Now if you want to do this for multiple charges you just evaluate the same point for all the charges and then add them together. You MIGHT need a scalar for this depending on how big of blobs you want. Any questions?
A very good explanation with the charges! I never considered metablobs this way but it's really logic!
btw: for a deeper insight in electrical charges and the resulting potential see the Coulomb's Law 😉
btw: for a deeper insight in electrical charges and the resulting potential see the Coulomb's Law 😉
Originally posted by Tuggumminothing wrong with that code...
Eeh, I wouldn't take my code as a example for study...
Im sure PAK-9 can tell you why 🙄
Wow. That really explains a lot. Now can someone take a SSC and make a mass of points, like I see some do, or a Texer and make them dance around and fuse, or, like Tug does it, a DM that in some strange way (I still find DM a tad cryptic) make the image act like blobs?
TUG-MAGIC-SUPER-VOODOO-CODE!
It makes, absolutlynosensewhatsoever, but in some miraculous way it works!
It makes, absolutlynosensewhatsoever, but in some miraculous way it works!
I think its pretty slick, nut I think I might lose that impression with time, if you insist...
Anyway, the mose I look at it, the more I realize how the thing works.
Now for something that's really nuts, the smooth watery turbulent effect.
Init
--
Frame
x1=x1*0.9+x1a*1.1;
y1=y1*0.9+y1a*1.1;
x2=x2*0.9+x2a*1.1;
y2=y2*0.9+y2a*1.1;
s=s*0.9+s1*0.9;
c=c+0.02
Beat
x1a=(rand(1000)/5500)*2+x1a*0.5;
y1a=(rand(1000)/5500)*2+y1a*0.5;
x2a=(rand(1000)/5500)*2+x2a*0.5;
y2a=(rand(1000)/5500)*2+y2a*0.5;
s1=getspec(0,1,0)*0.2;
Pixel
x=x+sin(y*$PI+c-x1+s-cos(y*cos(c+s-y2)+x*sin(c+s-x2))-sin(r)*d)*(s*0.08);
y=y+cos(x*$PI+c-y1+s-sin(x*sin(c+s-x2)+y*cos(c+s-y2))-cos(r)*d)*(s*0.08);
d=sqrt(sqr(x)+sqr(y));
r=atan2(y,x)+cos(d*s+c)*0.02;
x=cos(r)*d*1.02;
y=sin(r)*d*1.02
Anyway, the mose I look at it, the more I realize how the thing works.
Now for something that's really nuts, the smooth watery turbulent effect.
Init
--
Frame
x1=x1*0.9+x1a*1.1;
y1=y1*0.9+y1a*1.1;
x2=x2*0.9+x2a*1.1;
y2=y2*0.9+y2a*1.1;
s=s*0.9+s1*0.9;
c=c+0.02
Beat
x1a=(rand(1000)/5500)*2+x1a*0.5;
y1a=(rand(1000)/5500)*2+y1a*0.5;
x2a=(rand(1000)/5500)*2+x2a*0.5;
y2a=(rand(1000)/5500)*2+y2a*0.5;
s1=getspec(0,1,0)*0.2;
Pixel
x=x+sin(y*$PI+c-x1+s-cos(y*cos(c+s-y2)+x*sin(c+s-x2))-sin(r)*d)*(s*0.08);
y=y+cos(x*$PI+c-y1+s-sin(x*sin(c+s-x2)+y*cos(c+s-y2))-cos(r)*d)*(s*0.08);
d=sqrt(sqr(x)+sqr(y));
r=atan2(y,x)+cos(d*s+c)*0.02;
x=cos(r)*d*1.02;
y=sin(r)*d*1.02
Sorry this is coming from WFC1:
Ok so I'll try my best at parsing through that code. A lot of the times it's hard to figure out what's really math and what's just some random handwaving Tug-ish magic. And I can't actually look at the preset cause I'm working but I just imagine that it's the usual swirls.
Frame:
This section is just interpolating between old and new points. (x1,y1) and (x2,y2) is your old points and (x1a,y1a) and (x2a,y2a) are your destination points. .9 and 1.1 are pretty much percentages though in this case they don't exactly add up to 1. But if you try this with a scope you'll notice that the points don't move in linear time. It's not always the same increment. Interpolating is used (this may not be all reasons, but they are good ones) because it's easy to implement as seen, and it's a lot smoother than linear movement. The c variable I'm just assuming is for added rotation on the trig functions. And the s variable is to get in a little beat detection in the swirl too (I think).
Beat:
This section is where (x1a,y1a) and (x2a,y2a) are chosen. So these points are going to be the destination points. s1 is going to be your destination s.
Pixel:
Ok so this part looks little hand-wavey magic to me. There might be more math behind it than I'm aware of though. Sometimes in order to simulate some randomness in the waves or swirls, you can throw in a bunch of sines and cosines and wierd ways to get more randomness. Like I said, it's kinda just mathemagic to get the right effect. The line where they set d is to find the distance to the origin. Then they set r (radius) as the angle from the origin (atan2(y,x)) and then add on what looks like a bit more mathemagic.
Ok so that's as much about this code as I can sift through. If someone else might enlighten us on the few parts that I don't really understand that'd rock. Anymore? You haven't posted any 3D problems. 😉 I think I said this before but I'm better at 3D if you have anything from that neck of the woods. Basic raytracing? Approximation methods for quartics or other shapes? Other crazy methods (ie the one I used to make the 3D shape in my icon)?
Frame:
This section is just interpolating between old and new points. (x1,y1) and (x2,y2) is your old points and (x1a,y1a) and (x2a,y2a) are your destination points. .9 and 1.1 are pretty much percentages though in this case they don't exactly add up to 1. But if you try this with a scope you'll notice that the points don't move in linear time. It's not always the same increment. Interpolating is used (this may not be all reasons, but they are good ones) because it's easy to implement as seen, and it's a lot smoother than linear movement. The c variable I'm just assuming is for added rotation on the trig functions. And the s variable is to get in a little beat detection in the swirl too (I think).
Beat:
This section is where (x1a,y1a) and (x2a,y2a) are chosen. So these points are going to be the destination points. s1 is going to be your destination s.
Pixel:
Ok so this part looks little hand-wavey magic to me. There might be more math behind it than I'm aware of though. Sometimes in order to simulate some randomness in the waves or swirls, you can throw in a bunch of sines and cosines and wierd ways to get more randomness. Like I said, it's kinda just mathemagic to get the right effect. The line where they set d is to find the distance to the origin. Then they set r (radius) as the angle from the origin (atan2(y,x)) and then add on what looks like a bit more mathemagic.
Ok so that's as much about this code as I can sift through. If someone else might enlighten us on the few parts that I don't really understand that'd rock. Anymore? You haven't posted any 3D problems. 😉 I think I said this before but I'm better at 3D if you have anything from that neck of the woods. Basic raytracing? Approximation methods for quartics or other shapes? Other crazy methods (ie the one I used to make the 3D shape in my icon)?
Oh yeah and about the metaballs stuff. I know you see everyone doing blobs from point charges, but really nothing is stopping you from doing lines or other crazy shapes besides a bit of algebra and trig. You could do metacircles or metalines or whatever. I guess I'll explain how I would imagine someone going about doing this. So before we had x^2+y^2=r^2 right? Well is we take the square root of both sides of the equation we get sqrt(x^2+y^2)=r. So you might notice now that r just is the distance to the point. Well this is where I think we have some room to roam in the world of math. The basic concept is that if you can find the distance between your point and the closest point on the shape, then you have your r and you plug it right back in to the equation 1/r^2. (bare with me cause I'm winging this as best I can) So say we want to do circles. The equations for parametric equations for variable size and position are {x0+r1*cos(t),y0+r1*sin(t)}. Now for this we would know (x0,y0} cause we would specify where the circle would be just like the points. r1 would also be specified. This leaves t as the variable. Now we want to find the distance between those equations and our point (x,y) so we can plug and chug. So we need to solve for t! If you just set x=x0+r1*cos(t) and bring some stuff to the other side you get (x-x0)/r1=cos(t) and (y-y0)/r1=sin(t). Now the problem I see right now is that if (x,y) isn't exactly on the circle or at least within r1 of the (x0,y0) we're gonna run into problems taking the acos() and asin(). But if we think about our circle, if we normalize our distance to be equal to 1 then we we'll get the same value of t!
If you understood that last little leap skip this paragraph cause I'm just gonna explain it better. So we're looking for t. acos() and asin() work for the interval [-1,1] because thats all cos() and sin() map to. So what we need to do is shrink this value down but retain the same angle so as not to mess with t. Make sense?
Ok so lets normalize! We need to divide by the distance to the origin so we get l=sqrt((x-x0)^2+(y-y0)^2). Then we just divide the distance (x-x0) and (y-y0) by l to normalize it! So we get cos(t)=(x-x0)/(l*r1) and sin(t)=(y-y0)/(l*r1). Now we can take the acos() or asin() of both sides to get t=acos((x-x0)/(l*r1)) and t=asin((y-y0)/(l*r1). You could use either one of these to get t and then plug this back into your parametric equations x1=x0+r1*cos(t) and y1=y0+r1*sin(t) etc to get the point on the circle closest to your point. Then use the distance formula r=sqrt((x-x1)^2+(y-y1)^2 and plug it into the original 1/r^2 equation! Rock! So that's a basic parametric curve implementation. I showed this method just so you can see the work with a parametric curve so you can try other ones and maybe know what you're doing.
However (for fun and efficiency), we can actually the do the above example a lot faster. t is really just the angle! So we know that the slope of the line from our point to the origin is just (y-y0)/(x-x0)=tan(t) right? Solve for t and you can just do atan2(y-y0,x-x0)=t which is better than regular atan() anyways. Now you have t so you can plug and chug like last time. Any questions?
Yeah metaballs (though they look nice) are over done so maybe some people can make some new blob objects after this?? Anyone?
If you understood that last little leap skip this paragraph cause I'm just gonna explain it better. So we're looking for t. acos() and asin() work for the interval [-1,1] because thats all cos() and sin() map to. So what we need to do is shrink this value down but retain the same angle so as not to mess with t. Make sense?
Ok so lets normalize! We need to divide by the distance to the origin so we get l=sqrt((x-x0)^2+(y-y0)^2). Then we just divide the distance (x-x0) and (y-y0) by l to normalize it! So we get cos(t)=(x-x0)/(l*r1) and sin(t)=(y-y0)/(l*r1). Now we can take the acos() or asin() of both sides to get t=acos((x-x0)/(l*r1)) and t=asin((y-y0)/(l*r1). You could use either one of these to get t and then plug this back into your parametric equations x1=x0+r1*cos(t) and y1=y0+r1*sin(t) etc to get the point on the circle closest to your point. Then use the distance formula r=sqrt((x-x1)^2+(y-y1)^2 and plug it into the original 1/r^2 equation! Rock! So that's a basic parametric curve implementation. I showed this method just so you can see the work with a parametric curve so you can try other ones and maybe know what you're doing.
However (for fun and efficiency), we can actually the do the above example a lot faster. t is really just the angle! So we know that the slope of the line from our point to the origin is just (y-y0)/(x-x0)=tan(t) right? Solve for t and you can just do atan2(y-y0,x-x0)=t which is better than regular atan() anyways. Now you have t so you can plug and chug like last time. Any questions?
Yeah metaballs (though they look nice) are over done so maybe some people can make some new blob objects after this?? Anyone?
Ok, if you want 3D dm's, UnconeD's ZeroGMaze is really what I wanted to decypher.
Init
t=0;rx=1.57;ry=1.57;rx=0;ry=0;rz=0;rxo=0;ryo=0;rzo=0;rxt=0;ryt=0;rzt=0;
Frame
t=t+0.2;
rx=rx+rxo-0.03*cos(t/9)*cos(t/20)*sin(sin(t/9));
ry=ry+ryo+0.03*sin(t/10)*cos(t/22)*sin(cos(t/31));
rz=rz+rzo+0.03;
cx=cos(rx);sx=sin(rx);cy=cos(ry);sy=sin(ry);cz=cos(rz);sz=sin(rz);
rxo=(rxo+rxt)*.5;
ryo=(ryo+ryt)*.5;
rzo=(rzo+rzt)*.5;
ox=sin(t*.5)*.5;
oy=sin(t*.53)*.5;
oz=sin(t*.57)*.5;
Beat
rxt=(rand(80)/320)*sign(-rxt);
ryt=(rand(80)/320)*sign(-ryt);
rzt=(rand(80)/320)-0.125;
Pixel
x=sin(r)*d;y=-cos(r)*d;
dx=x;dy=y;dz=0.6;
dx1=dx*cz-dy*sz;
dy1=dx*sz+dy*cz;
dy2=dy1*cx-dz*sx;
dz2=dy1*sx+dz*cx;
dx3=dx1*cy-dz2*sy;
dz3=dx1*sy+dz2*cy;
k1=abs((-1-oy)/dy2);
k1=if(below(k1*dy2,0),abs((1-oy)/dy2),k1);
k2=abs((-1-ox)/dx3);
k2=if(below(k2*dx3,0),abs((1-ox)/dx3),k2);
k3=abs((-1-oz)/dz3);
k3=if(below(k3*dz3,0),abs((1-oz)/dz3),k3);
k=min(min(max(k1,k2),max(k2,k3)),max(k1,k3));
ix=dx3*k-ox;iy=dy2*k-oy;iz=dz3*k-oz;
x=if(equal(k,k1),-ix,if(equal(k,k2),-iy,-ix));
y=if(equal(k,k1),iz,if(equal(k,k2),iz,iy));
ix=ix+ox;iy=iy+oy;iz=iz+oz;
d=sqrt(ix*ix+iy*iy+iz*iz);
alpha=2/d-0.4;
x=asin(sin(x*2.7))*.5;
y=asin(sin(y*2.7))*.5;
alpha=if(above(alpha,1),1,if(below(alpha,0),0,alpha));
What I realize that most 3D DMs do is take a texer or an image that resembles blur an syncronizing this with the DM. (I know this because I screwed around 😁) I'm expecting a lot of the DM to be just that.
Init
t=0;rx=1.57;ry=1.57;rx=0;ry=0;rz=0;rxo=0;ryo=0;rzo=0;rxt=0;ryt=0;rzt=0;
Frame
t=t+0.2;
rx=rx+rxo-0.03*cos(t/9)*cos(t/20)*sin(sin(t/9));
ry=ry+ryo+0.03*sin(t/10)*cos(t/22)*sin(cos(t/31));
rz=rz+rzo+0.03;
cx=cos(rx);sx=sin(rx);cy=cos(ry);sy=sin(ry);cz=cos(rz);sz=sin(rz);
rxo=(rxo+rxt)*.5;
ryo=(ryo+ryt)*.5;
rzo=(rzo+rzt)*.5;
ox=sin(t*.5)*.5;
oy=sin(t*.53)*.5;
oz=sin(t*.57)*.5;
Beat
rxt=(rand(80)/320)*sign(-rxt);
ryt=(rand(80)/320)*sign(-ryt);
rzt=(rand(80)/320)-0.125;
Pixel
x=sin(r)*d;y=-cos(r)*d;
dx=x;dy=y;dz=0.6;
dx1=dx*cz-dy*sz;
dy1=dx*sz+dy*cz;
dy2=dy1*cx-dz*sx;
dz2=dy1*sx+dz*cx;
dx3=dx1*cy-dz2*sy;
dz3=dx1*sy+dz2*cy;
k1=abs((-1-oy)/dy2);
k1=if(below(k1*dy2,0),abs((1-oy)/dy2),k1);
k2=abs((-1-ox)/dx3);
k2=if(below(k2*dx3,0),abs((1-ox)/dx3),k2);
k3=abs((-1-oz)/dz3);
k3=if(below(k3*dz3,0),abs((1-oz)/dz3),k3);
k=min(min(max(k1,k2),max(k2,k3)),max(k1,k3));
ix=dx3*k-ox;iy=dy2*k-oy;iz=dz3*k-oz;
x=if(equal(k,k1),-ix,if(equal(k,k2),-iy,-ix));
y=if(equal(k,k1),iz,if(equal(k,k2),iz,iy));
ix=ix+ox;iy=iy+oy;iz=iz+oz;
d=sqrt(ix*ix+iy*iy+iz*iz);
alpha=2/d-0.4;
x=asin(sin(x*2.7))*.5;
y=asin(sin(y*2.7))*.5;
alpha=if(above(alpha,1),1,if(below(alpha,0),0,alpha));
What I realize that most 3D DMs do is take a texer or an image that resembles blur an syncronizing this with the DM. (I know this because I screwed around 😁) I'm expecting a lot of the DM to be just that.
Ok well I'm not quite sure I'm capable of making it through all of his code. But I'll give it a try and if I can't figure out exactly what's going on I'll just explain the concept.
So I take it you're still a little confused about DM's. The best way I can explain it is, a dynamic movement moves the screen dynamically. Haha, ok so in other words you can shift, skew, rotate, scale, and a lot of other things with DM. All you do to make the DM do whatever you want is take the coordinates you are given, and set x and y to the coordinates of the texture you want. So in UnConeD's ZeroGMaze, he's just finding the new texture coordinates for each (x,y) point on the screen.
Ok so code:
Init:
Just reseting variables.
Frame:
This part is just setting up the camera movement and rotation. Note the cx,cy,cz and sx,sy,sz variables. These are used for 3D rotation. The rest of this jargon is just UnConeD's camera work which I can't really pick through. The ox,oy,oz is the actually position of the camera and the rest is rotation.
Beat:
This is adding beat detection to the rotations and movements of the camera. You can see they are added up in the frame section.
Pixel:
Ok so here's the fun part. This is actually where we start raytracing! So the idea of raytracing is just like it sounds. Instead of light coming from a light source and bouncing into your eyes, you trace all the needed light rays out from your eyes to the objects and light sources. So we have to setup rays that goes from our camera, through each point we are working with. That's what he does with the first too lines of code. So we define our lines with these equations: x=ox+dx*k; y=oy+dy*k; z=ox+dz*k; where (ox,oy,oz) is our camera's position, (dx,dy,dz) is the vector from the camera, to the cooresponding point on the screen we are working with, and k is a variable scalar that we need to find. Our task right now is to find the specific value of k, where our line defined by those equation's above , intersects our shape. So since we already setup the camera in the frame section the vector setup is next. We want our vector to be from the camera to the point on the screen we are working with. Remember that vectors contain nothing about position. Just speed and direction. You'll notice if you take out the first line of code, the rendering still works without it. So for our vector, we can just say that the dx and dy values just equal the point on the screen. Then dz can just be set depending on how you want your view to look like. Try variable sizes of dz!
Ok so we setup or vector and camera. Now we rotate the camera. This can be accomplished by just rotating the vectors since the vectors really define our field of view anyways. That's what lines 3-8 are doing. You can look up 3D rotation on TONS of sites so I won't explain it here.
Now we have the line exactly how we want it so it's time to find where our line intersects our object. The shape UnConeD is using is actually 6 planes. To be more specific the planes are defined as: x=-1; x=1; y=-1; y=1; z=-1; z=1; so we want to find where our shape intersects with these planes. Lines 9-14 are doing just that. In order to find the intersection we set our equations for our line equal to the equation for the planes. -1=ox+dx*k; 1=ox+dx*k; -1=oy+dy*k; 1=oy+dy*k; -1=oz+dz*k; -1=oz+dz*k; then we solve for our unknown k and get: (-1-ox)/dx=k; (1-ox)/dx=k; (-1-oy)/dy=k; (1-oy)/dy=k; (-1-oz)/dz=k; (1-oz)/dz=k; Lines 10, 12, and 14 choose which value of k to work with depending on where the intersection was for each set of planes. This is how he combines multiple planes into 1 dm. So once we narrowed all our options for k down to the one we want, we plug it back into our equations for our lines to get the point in 3D space where our line intersects! This value is stored into (ix,iy,iz). We can use this to get our texture coordinates. The next 3 lines are just messing with the texture coordinates a bit. d is set to the distance from the point of intersection to the camera. Then it is used in the alpha blending to blend out the texture if the point is too far from the camera. He does this because if you showed the texture all the way down one of those tunnels, it'd look really ugly and distorted since there's only so many rays headed down there. Try taking out blending and you'll see what I mean.
So that's pretty much the deep, dark, and cryptic workings of that preset. Does that help?
So I take it you're still a little confused about DM's. The best way I can explain it is, a dynamic movement moves the screen dynamically. Haha, ok so in other words you can shift, skew, rotate, scale, and a lot of other things with DM. All you do to make the DM do whatever you want is take the coordinates you are given, and set x and y to the coordinates of the texture you want. So in UnConeD's ZeroGMaze, he's just finding the new texture coordinates for each (x,y) point on the screen.
Ok so code:
Init:
Just reseting variables.
Frame:
This part is just setting up the camera movement and rotation. Note the cx,cy,cz and sx,sy,sz variables. These are used for 3D rotation. The rest of this jargon is just UnConeD's camera work which I can't really pick through. The ox,oy,oz is the actually position of the camera and the rest is rotation.
Beat:
This is adding beat detection to the rotations and movements of the camera. You can see they are added up in the frame section.
Pixel:
Ok so here's the fun part. This is actually where we start raytracing! So the idea of raytracing is just like it sounds. Instead of light coming from a light source and bouncing into your eyes, you trace all the needed light rays out from your eyes to the objects and light sources. So we have to setup rays that goes from our camera, through each point we are working with. That's what he does with the first too lines of code. So we define our lines with these equations: x=ox+dx*k; y=oy+dy*k; z=ox+dz*k; where (ox,oy,oz) is our camera's position, (dx,dy,dz) is the vector from the camera, to the cooresponding point on the screen we are working with, and k is a variable scalar that we need to find. Our task right now is to find the specific value of k, where our line defined by those equation's above , intersects our shape. So since we already setup the camera in the frame section the vector setup is next. We want our vector to be from the camera to the point on the screen we are working with. Remember that vectors contain nothing about position. Just speed and direction. You'll notice if you take out the first line of code, the rendering still works without it. So for our vector, we can just say that the dx and dy values just equal the point on the screen. Then dz can just be set depending on how you want your view to look like. Try variable sizes of dz!
Ok so we setup or vector and camera. Now we rotate the camera. This can be accomplished by just rotating the vectors since the vectors really define our field of view anyways. That's what lines 3-8 are doing. You can look up 3D rotation on TONS of sites so I won't explain it here.
Now we have the line exactly how we want it so it's time to find where our line intersects our object. The shape UnConeD is using is actually 6 planes. To be more specific the planes are defined as: x=-1; x=1; y=-1; y=1; z=-1; z=1; so we want to find where our shape intersects with these planes. Lines 9-14 are doing just that. In order to find the intersection we set our equations for our line equal to the equation for the planes. -1=ox+dx*k; 1=ox+dx*k; -1=oy+dy*k; 1=oy+dy*k; -1=oz+dz*k; -1=oz+dz*k; then we solve for our unknown k and get: (-1-ox)/dx=k; (1-ox)/dx=k; (-1-oy)/dy=k; (1-oy)/dy=k; (-1-oz)/dz=k; (1-oz)/dz=k; Lines 10, 12, and 14 choose which value of k to work with depending on where the intersection was for each set of planes. This is how he combines multiple planes into 1 dm. So once we narrowed all our options for k down to the one we want, we plug it back into our equations for our lines to get the point in 3D space where our line intersects! This value is stored into (ix,iy,iz). We can use this to get our texture coordinates. The next 3 lines are just messing with the texture coordinates a bit. d is set to the distance from the point of intersection to the camera. Then it is used in the alpha blending to blend out the texture if the point is too far from the camera. He does this because if you showed the texture all the way down one of those tunnels, it'd look really ugly and distorted since there's only so many rays headed down there. Try taking out blending and you'll see what I mean.
So that's pretty much the deep, dark, and cryptic workings of that preset. Does that help?
Well, it does, a lot, but I still would not be able to contruct it from scratch... Not that I expected to in the first place, but I get what some of these things are doing, but the nitty gritty still evades me. Any way, could you go over raytracing a bit more detail, cuz I figure that that's probably going to show up in other presets.
Here's another:
Init
dv=3; pfs=.15; pfz=0; pf=0; pbx=0; pby=0; pbz=0; water=0;
Frame
pfx=pfx+pbx; xc=cos(pfx/dv); xs=sin(pfx/dv);
pfy=pfy+pby; yc=cos(pfy/dv); ys=sin(pfy/dv);
pfz=pfz+pbz-(pfz*.1);
pf=pf+pfs;
Beat
pbx=rand(50)/500;
pby=rand(50)/400;
pbz=rand(50)/500-.01;
Pixel
mw=pfz+.6;
x=x/(1.2+y)*mw;
y=y/(1.2+y)*mw;
x1=x*xs-y*xc;
y1=x*xc+y*xs;
x2=y1*yc+x1*ys;
y2=y1*ys-x1*yc;
z1=sqr(y2*y2+sqr(y2+pfz));
z2=max(z1,sqrt(z1+z1))+sqr(z1*sin(xs*.1));
water=if(below(mw,.7),rand(5)/90,0);
z3=z1/z2;
x=x2+(x2*z3)-pf+water;
y=y2+(y2*z3)+water;
alpha=z1/z2+.5;
Coming from Duo
Here's another:
Init
dv=3; pfs=.15; pfz=0; pf=0; pbx=0; pby=0; pbz=0; water=0;
Frame
pfx=pfx+pbx; xc=cos(pfx/dv); xs=sin(pfx/dv);
pfy=pfy+pby; yc=cos(pfy/dv); ys=sin(pfy/dv);
pfz=pfz+pbz-(pfz*.1);
pf=pf+pfs;
Beat
pbx=rand(50)/500;
pby=rand(50)/400;
pbz=rand(50)/500-.01;
Pixel
mw=pfz+.6;
x=x/(1.2+y)*mw;
y=y/(1.2+y)*mw;
x1=x*xs-y*xc;
y1=x*xc+y*xs;
x2=y1*yc+x1*ys;
y2=y1*ys-x1*yc;
z1=sqr(y2*y2+sqr(y2+pfz));
z2=max(z1,sqrt(z1+z1))+sqr(z1*sin(xs*.1));
water=if(below(mw,.7),rand(5)/90,0);
z3=z1/z2;
x=x2+(x2*z3)-pf+water;
y=y2+(y2*z3)+water;
alpha=z1/z2+.5;
Coming from Duo
Sorry again...
As far as I can tell this really isn't raytracing at all. It looks to me like it's just a semi 3D skew with rotation and some alpha blending to fake 3D.
I'll explain why I believe it's just a skew. First tip is that he divides (x,y) by (y+1.2) in lines 2-3 of the pixel code. Notice how (y+1.2) is always above 0? Try switching that 1.2 to 1 and you'll see that it gets really ugly at top of the screen. Normally if you were transforming from 3D to 2D you would divide by z. Another hint is that he's only rotating in 2D instead of 3D. Notice in the last preset there were 6 lines for rotation. This only has the 4.
I think I covered raytracing pretty well in the last post. Are there any specifics that you are confused with? I'm more than will to fill in any gaps, but I thought I spelled most of it our pretty clearly the last time except for rotation which is easily googled. Be careful what presets you're looking through. Some may not be straight forward raytracing and it might make you more confused. There are a lot of examples like this one that really aren't raytracing at all and there are many examples that use tricks. For example, in UnConeD's/Jheriko's chmutov preset, an approximation method is used to raytrace the quartic shape. That preset is raytracing, but it's more advanced and not exactly a place to learn basic raytracing from. If we get to that bridge I can help you cross it, but don't worry about that stuff now.
I'll explain why I believe it's just a skew. First tip is that he divides (x,y) by (y+1.2) in lines 2-3 of the pixel code. Notice how (y+1.2) is always above 0? Try switching that 1.2 to 1 and you'll see that it gets really ugly at top of the screen. Normally if you were transforming from 3D to 2D you would divide by z. Another hint is that he's only rotating in 2D instead of 3D. Notice in the last preset there were 6 lines for rotation. This only has the 4.
I think I covered raytracing pretty well in the last post. Are there any specifics that you are confused with? I'm more than will to fill in any gaps, but I thought I spelled most of it our pretty clearly the last time except for rotation which is easily googled. Be careful what presets you're looking through. Some may not be straight forward raytracing and it might make you more confused. There are a lot of examples like this one that really aren't raytracing at all and there are many examples that use tricks. For example, in UnConeD's/Jheriko's chmutov preset, an approximation method is used to raytrace the quartic shape. That preset is raytracing, but it's more advanced and not exactly a place to learn basic raytracing from. If we get to that bridge I can help you cross it, but don't worry about that stuff now.
What about the 3D-2D conversion in the 3D SSC's?
I'm wondering how that works...
Init
n=7;r=0.5;mx=0;my=0;mz=0;dst=2;rx=0;ry=0;rz=0;rdx=1;rdy=1;rdz=1;p=3.14159265;p2=2.0*p;p3=180/p
Frame
rx=rx+rdx;
ry=ry+rdy;
rz=rz+rdz;
xs=sin(rx/p3);
ys=sin(ry/p3);
zs=sin(rz/p3);
xc=cos(rx/p3);
yc=cos(ry/p3);
zc=cos(rz/p3)
Beat
rdx=rand(3)+1;
rdy=rand(3)+1;
rdz=rand(3)+1
Point
x1=r*sin(p2*i);
y1=0;
z1=r*cos(p2*i);
y2=y1*xc-z1*xs;
z2=y1*xs+z1*xc;
x2=z2*ys+x1*yc;
z3=z2*yc-x1*ys;
x3=x2*zcy2*zs;
y3=y2*zc+x2*zs;
x4=mx+x3;
y4=my+y3;
z4=mz+z3;
x=x4/(1+z4/dst);
y=y4/(1+z4/dst)
I'm wondering how that works...
Init
n=7;r=0.5;mx=0;my=0;mz=0;dst=2;rx=0;ry=0;rz=0;rdx=1;rdy=1;rdz=1;p=3.14159265;p2=2.0*p;p3=180/p
Frame
rx=rx+rdx;
ry=ry+rdy;
rz=rz+rdz;
xs=sin(rx/p3);
ys=sin(ry/p3);
zs=sin(rz/p3);
xc=cos(rx/p3);
yc=cos(ry/p3);
zc=cos(rz/p3)
Beat
rdx=rand(3)+1;
rdy=rand(3)+1;
rdz=rand(3)+1
Point
x1=r*sin(p2*i);
y1=0;
z1=r*cos(p2*i);
y2=y1*xc-z1*xs;
z2=y1*xs+z1*xc;
x2=z2*ys+x1*yc;
z3=z2*yc-x1*ys;
x3=x2*zcy2*zs;
y3=y2*zc+x2*zs;
x4=mx+x3;
y4=my+y3;
z4=mz+z3;
x=x4/(1+z4/dst);
y=y4/(1+z4/dst)