1st December 2005, 23:51  #41 
Senior Member
Join Date: Oct 2003
Posts: 272

So you're interested in 3D DM's then? I can help with that probably better than I can with 2D ones.

2nd December 2005, 00:47  #42 
Major Dude
Join Date: Jan 2005
Location: I was hoping you could tell me
Posts: 1,350

Really? That's very good news, since I kinda sorta get what the 2d Dm's are all about.

2nd December 2005, 15:17  #43 
Senior Member
Join Date: Oct 2003
Posts: 272

Well let me know what you need and I'll gladly explain somethings as best as I can.

2nd December 2005, 20:55  #44 
Major Dude
Join Date: Jan 2005
Location: I was hoping you could tell me
Posts: 1,350

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=1sec*(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=szbg1*sza ; sz2=szbg2*sza ; sz3=szbg3*sza ; sz4=szbg4*sza ; sz5=szbg5*sza ; sz6=szbg6*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): 
3rd December 2005, 00:51  #45 
Bin King
Join Date: Mar 2001
Location: Finland
Posts: 2,173

Eeh, I wouldn't take my code as a example for study...
Im sure PAK9 can tell you why 
3rd December 2005, 02:57  #46 
Senior Member
Join Date: Oct 2003
Posts: 272

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/((xx0)^2+(yy0)^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? 
3rd December 2005, 12:15  #47 
Major Dude

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 
3rd December 2005, 12:40  #48  
Forum King

Quote:


3rd December 2005, 12:43  #49 
Major Dude
Join Date: Jan 2005
Location: I was hoping you could tell me
Posts: 1,350

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?

3rd December 2005, 12:48  #50 
Bin King
Join Date: Mar 2001
Location: Finland
Posts: 2,173

TUGMAGICSUPERVOODOOCODE!
It makes, absolutlynosensewhatsoever, but in some miraculous way it works! 
3rd December 2005, 14:32  #51 
Major Dude
Join Date: Jan 2005
Location: I was hoping you could tell me
Posts: 1,350

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+cx1+scos(y*cos(c+sy2)+x*sin(c+sx2))sin(r)*d)*(s*0.08); y=y+cos(x*$PI+cy1+ssin(x*sin(c+sx2)+y*cos(c+sy2))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 
3rd December 2005, 14:35  #52 
Major Dude
Join Date: Jan 2005
Location: I was hoping you could tell me
Posts: 1,350

Sorry this is coming from WFC1:

3rd December 2005, 17:36  #53 
Senior Member
Join Date: Oct 2003
Posts: 272

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 Tugish 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 handwavey 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)? Last edited by UIUC85; 3rd December 2005 at 18:30. 
3rd December 2005, 19:17  #54 
Senior Member
Join Date: Oct 2003
Posts: 272

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 (xx0)/r1=cos(t) and (yy0)/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((xx0)^2+(yy0)^2). Then we just divide the distance (xx0) and (yy0) by l to normalize it! So we get cos(t)=(xx0)/(l*r1) and sin(t)=(yy0)/(l*r1). Now we can take the acos() or asin() of both sides to get t=acos((xx0)/(l*r1)) and t=asin((yy0)/(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((xx1)^2+(yy1)^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 (yy0)/(xx0)=tan(t) right? Solve for t and you can just do atan2(yy0,xx0)=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? Last edited by UIUC85; 3rd December 2005 at 19:38. 
3rd December 2005, 23:00  #55 
Major Dude
Join Date: Jan 2005
Location: I was hoping you could tell me
Posts: 1,350

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+rxo0.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*czdy*sz; dy1=dx*sz+dy*cz; dy2=dy1*cxdz*sx; dz2=dy1*sx+dz*cx; dx3=dx1*cydz2*sy; dz3=dx1*sy+dz2*cy; k1=abs((1oy)/dy2); k1=if(below(k1*dy2,0),abs((1oy)/dy2),k1); k2=abs((1ox)/dx3); k2=if(below(k2*dx3,0),abs((1ox)/dx3),k2); k3=abs((1oz)/dz3); k3=if(below(k3*dz3,0),abs((1oz)/dz3),k3); k=min(min(max(k1,k2),max(k2,k3)),max(k1,k3)); ix=dx3*kox;iy=dy2*koy;iz=dz3*koz; 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/d0.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. 
4th December 2005, 16:40  #56 
Senior Member
Join Date: Oct 2003
Posts: 272

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 38 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 914 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: (1ox)/dx=k; (1ox)/dx=k; (1oy)/dy=k; (1oy)/dy=k; (1oz)/dz=k; (1oz)/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? 
4th December 2005, 19:29  #57 
Major Dude
Join Date: Jan 2005
Location: I was hoping you could tell me
Posts: 1,350

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*xsy*xc; y1=x*xc+y*xs; x2=y1*yc+x1*ys; y2=y1*ysx1*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 Last edited by JFASI; 4th December 2005 at 19:58. 
4th December 2005, 19:59  #58 
Major Dude
Join Date: Jan 2005
Location: I was hoping you could tell me
Posts: 1,350

Sorry again...

5th December 2005, 00:44  #59 
Senior Member
Join Date: Oct 2003
Posts: 272

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 23 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. 
5th December 2005, 20:23  #60 
Major Dude
Join Date: Jan 2005
Location: I was hoping you could tell me
Posts: 1,350

What about the 3D2D 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*xcz1*xs; z2=y1*xs+z1*xc; x2=z2*ys+x1*yc; z3=z2*ycx1*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) 
6th December 2005, 02:43  #61 
Senior Member
Join Date: Oct 2003
Posts: 272

I'd like to note that code like this is in just about every tutorial on AVS/superscopes. I'm assuming you looked up those already because of their wide accessability and that you are having problems conceptually. So instead of parsing through this code I'll offer some webpages that can explain all of this better than I can. Here is one great example:
http://www.gamedev.net/reference/art...article795.asp http://www.gamedev.net/reference/art...article796.asp http://www.gamedev.net/reference/art...article797.asp This series offers all the math you need to know to create the preset you posted. 
9th December 2005, 02:22  #62 
Major Dude
Join Date: Jan 2005
Location: I was hoping you could tell me
Posts: 1,350

Ok. After a few days of deep thought and study, I do believe I get it. Thanks. How about the sphere DM in UnconeD's Nuke Warfare? I think that could be simpler example of raytracing than any of these other DMs.
Thanks to UnconeD fot the single greatest preset saga ever...You know which one I mean... 
9th December 2005, 05:22  #63  
Forum King

Quote:
Anyway... If you think the sphere is going to be simpler, then you don't really get it yet Here is another explanation... again (I have written this before I am sure...). I'll use unconeds variable name conventions so you can compare to his dms the idea of raytracing is that you find the distance to the object being 'traced' by projecting a line from the camera, through a point (defined by our frustrum) and out into the world. this sounds horribly abstract... but is pretty simple if we use vectors (read as three numbers in a row, if 'vector' scares you). we represent our camera position as (ox,oy,oz) dm uses a grid from 1 to 1 of x and y values which we recycle into our 45 degree view frustrum with lines like this: dx=x; dy=y; dz=1; these define the directions out of the eye we look into the world for each grid. where 0,0,1 is forward, 1,0,0 is right, 0,1,0 is down etc... usual avs stuff. in a square window this would give us a square pyramid view with a 90 degree fov. you can rotate the frustrum vectors to get the effect of rotating the camera. we then trace along each of these directions from the camera and find where it intersects the model by using simultaneous equations and some other simple maths. first we use the vector equation for a line to find our 'ray' that goes along the direction from the camera: (x,y,z)=(ox+dx*k,oy+dy*k,oz+dz*k) (k is a parameter which allows us to 'travel along the ray') we want to find k where there is an intersection with our geometry. for our example lets use a plane z = 1, then from the above we can see that z = oz+dz*k = 1 and so k = (1oz)/dz. now we know how far down the ray the intersection point is we can mangle our texture coordinates to make it look right. the normal way to do this is with a planar projection: x=ox+dx*k; y=oy+dy*k; looks deceptively simple in this case, but here is how it works: everything samples from a 01 grid of texture coordinates, with wrap it auto clamps all the x's and y's to 01. since z=1 has is x component and y component describing the plane at right angles and ox+dx*k and oy+dy*k are these components in world space, then hopefully you can see that we are simply projecting the existing texture coordinate grid onto the plane (with or without wrap). if we used the plane x = 1 then we would use the y and Z component for this instead, e.g. x=oy+dy*k;y=oz+dz*k; (yes 'y' not 'z') so drawing a shape with raytracing involves two problems: finding 'k' which means you need an equation for the shape which you can solve. finding a suitable texture projection (trivial for planes) the first is a lot easier than the second, but you cant really do anything that great in terms of applying texture coordinates to most of the more powerful shapes anyway.... hope this helps 

9th December 2005, 12:38  #64 
Major Dude
Join Date: Jan 2005
Location: I was hoping you could tell me
Posts: 1,350

Aha. I get it. I'll go mess around with it later...

9th December 2005, 20:34  #65 
Senior Member
Join Date: Oct 2003
Posts: 272

Good call Jheriko.

11th December 2005, 13:34  #66 
Forum King

I'm sure I posted this before... i must have forgot to submit it :P
But... raytracing and the '3d ssc' are related. If you ignore rotation for a minute and raytrace from a 0,0,0 through any point x1,y1,z1 onto the plane z=1 and find the local plane coordinates (x,y) at this intersection then you get the perpective transformation everyone loves to use. The reason we use z = 1 is that the 0..1 in x and y define the intersection area with a pyramidal view frustrum, in this case it is a 90 degree frustrum since the pyramid has a base length 1 and height 1. Putting this into effect you get: ox,oy,oz = 0,0,0 dx,dy,dz = x1,y1,z1 (because the direction from ox,oy,oz to the point x1,y1,z1 = x1ox,y1oy,z1oz) .: k = 1/z1 (oz=0, from plane equation dz*k+oz = 1) .: x = x1*k; y = y1*k; (remember ox,oy are 0) which is just the same as the usual code at the end of a superscope, after the rotation... this helps understand one of the fundamental differences between ssc and dm presets, which is that when you rotate in a superscope you are normally rotating the point around the origin, when you rotate in a dm you are rotating the view frustrum. this is why rotations and shifts have to be done differently in the superscope to the dm. 
11th December 2005, 13:41  #67 
Major Dude
Join Date: Jan 2005
Location: I was hoping you could tell me
Posts: 1,350

Quick detail. Do the points in the DM keep their r and d value when the rectangular coords are turned on, and vice versa?

11th December 2005, 16:29  #68 
Forum King

no. rectangular coordinates only enables x and y. otherwise only d and r are enabled. you need to backwards work them out if you want them, using something like:
x=d*cos(r); y=d*sin(t); d=sqrt(sqr(x)+sqr(y); r=atan2(y,x); This is mentioned else where on the forums... 
11th December 2005, 16:33  #69 
Major Dude
Join Date: Jan 2005
Location: I was hoping you could tell me
Posts: 1,350

So if rect is turned on, then a pint has only (x,y) and if polar is on then it only has (r,d)?

11th December 2005, 17:46  #70 
Major Dude

Right, either (x,y) OR (r,d) are sufficient to exactly define where a point is located in an coordinate system (or: on the screen, in our case).
For more info about coordinates you can read this wikipedia article. 
11th December 2005, 17:50  #71 
Major Dude
Join Date: Jan 2005
Location: I was hoping you could tell me
Posts: 1,350

Ok. Cool. This explains a lot.

11th December 2005, 18:12  #72 
Major Dude

Good, cause imo it's essential to understand that polar (r,d) and cartesian (x,y) coordiantes are two different things. But that doesn't mean that you cannot "translate" coordinates between both systems (as Jheriko already mentioned)!!
For example, take a random point: you can either describe it with (r,d) or (x,y) values. If you chose polar you can translate these values into cartesion and vice versa. now the dynamic movement does exactly the same: using either polar or cartesian values. /sorry if this was too much of a repetition, but i'm in an 'explainatory' mood at,! 
11th December 2005, 20:50  #73 
Bin King
Join Date: Mar 2001
Location: Finland
Posts: 2,173

Im in a mood at which in i... kick your ass and then... something, oh fuck... im just drunk so that's my mood

11th December 2005, 21:54  #74 
Major Dude

But that isn't your mood just at the moment. Unfortunately it's the mood you're always in...
...except while you're asleep. Anyway, didn't we agree to restrict this kind of conversation to the bin? 
11th December 2005, 22:10  #75 
Bin King
Join Date: Mar 2001
Location: Finland
Posts: 2,173

Oh you're right, as always utterly unpronouncable ^..^
Okay, so what i want to say is that maybe JFASI needs to stop asking so many questions and start learning things by himself, i dunno, but if i were the one giving him tutoring lessons, i would pretty much freak out by now 
11th December 2005, 23:10  #76 
Major Dude
Join Date: Jan 2005
Location: I was hoping you could tell me
Posts: 1,350

Heeeeeeey...I'm learning. It's not like you give actual lines of code and I use them blindly!

12th December 2005, 00:12  #77 
Senior Member
Join Date: Oct 2003
Posts: 272

to Tug:
Well it's a good thing I'm not drunk then. 
12th December 2005, 15:18  #78  
Forum King

Quote:


12th December 2005, 18:11  #79 
Titeleinzigartigkeit
Senior Member Join Date: Apr 2005
Location: under a bridge
Posts: 620

best way of learning is reading plain code
oversized epenis replacement 
12th December 2005, 20:07  #80 
Major Dude
Join Date: Jan 2005
Location: I was hoping you could tell me
Posts: 1,350

I had no idea what raytracing was about, or how certain DM worked. I came and found out. That's ok.
Now, if I had gone and just asked you for code and used it without any analysis, then it would be different. 

Thread Tools  Search this Thread 
Display Modes  

