13373571

3rd July 2003 21:40 UTC

realistic lighting on cube DM
Ok... I've been trying to create a cube DM with fairly realistic lighting eminating from a single point (outside the cube) using alpha blending. Unfortunately I haven't been able to find a good source for lighting math. Anywhoo:

I assign the coordinates (lx,ly,lz) for the light in per frame and a brightness for the light in init. Then I calculate the distance (ld) between the light and the surface using sqrt(sqr(lx-ix)+sqr(ly-iy)+sqr(lz-iz)). Then I find alpha as brightness/sqr(ld). First of all, are these the proper formulas for lighting? I'm particularly unsure about weather brightness/sqr(ld) is the proper amount to blend. Also, would I be right in assuming that as the angle (not distance) between the light and the surface increases, the brightness on the surface increases proportionally? I want to be sure of that before I start coding that part. And I know that when the light is behind the surface the surface isn't illuminated, I'll fix that too.

Last problem: I tried to track the location of the light with a SSC dot. I plugged in the same (lx,ly,lz) coordinates, put them through the same rotation as the camera movement in the DM, and subtracted the same (ox,oy,oz) values, but it obviously isn't working. Why? The preset is attatched, it requires a texture from shereyas's last pack "UnTitled" because I thought it showed the light changing well, I don't know why you wouldn't have his pack by now so bleh.

anubis2003

3rd July 2003 21:49 UTC

I don't think angle has anything to do with it...

I'm pretty sure that the intensity of light is related to the inverse square of the distance, but I'm not positive(it's been about 1.5 years since I learned that and I didn't really care to memorize it at the time).

About the SSC - you multiplied the sin() and cos() by 3 instead of 2 - I don't know if that's the problem, but I don't feel like dissecting the code completely right now to see.

dirkdeftly

3rd July 2003 22:03 UTC

here is a perfect reason for you to NOT use that 3d engine you "devised". what you need to do is do the rotations of the ssc in reverse order of the ones you're doing in the DM. another perfect reason is that it's extremely difficult to understand and pick apart, in case anyone actually wanted to learn the code. just use the orthodox, tested and true 3d engine that everyone else uses - they do so for a reason, y'know....

also: DON'T USE STRAIGHT UP GETOSC FOR SYNCING. i don't know how many times i've told everybody this but it's REALLY getting old. if you want to know why then search the damned forums. instead use a semi-even distribution, i.e.:
(abs(getosc(blah,0,0))*bignumber%returns)
to replace:
rand(returns)
[size=1]btw, i don't remember if i said so or not in other posts, but you need to have that abs() function there because modulus (%) only accepts positive values

13373571

3rd July 2003 23:01 UTC

Atero, I don't know how anyone could've said that and sounded like more of an asshole. After searching through your posts it wouldn't suprise me if you torture small children to relieve stress. It would be SO MUCH easier for me or anyone else to listen to your advice if you weren't such a dick about it, and the only reason I'm paying any attention to you now is because I know how well made your presets are (imho) and how much effort you put into the primer. That being said, thanks for the help, I'll try what you said.

Zevensoft

4th July 2003 03:57 UTC

It is dependant on the angle and normal vectors.

XYZ is a vector

Light.XYZ - Point.XYZ = Diff.XYZ
dist = sqrt(Diff.X^2+diff.Y^2+diff.Z^2)
Normal.XYZ = Diff.XYZ / dist
DotProduct = Light.X*Diff.X + Light.Y*Diff.Y + Light.Z*Diff.Z

The dot product is your lighting value, it ranges from -1...1, so use -1...0 as black. It is also equal to the cosine of the angle between the light vector and the face vector.

uNDefineD

4th July 2003 07:13 UTC

Originally posted by Atero
(abs(getosc(blah,0,0))*bignumber%returns)

13373571

4th July 2003 13:15 UTC

undefined: it's a "semi-even distribution", so it reacts according to the music and doesn't... uhh... suck in some way that pisses atero off. Search for semi-even distribution and/or getosc syncing and you can probably find some big argument about it in another thread like I did...

Zevensoft: thanks for the help but I'm a bit confused, you say it is dependant on the normal and angle vectors, then you say it's the dot product which is cos(angle)... It's clear that the dot product doesn't range from -1..1 because when I plug it in the whole cube is bright, I have to divide by twenty five to notice any shadows... Do I have to include normal.XYZ into the final calculation?

edit: oh yeah, the new code... I haven't changed the rotation yet, thanks for noticing atero, I'll do it when I get back to the SSC.

pixel:

x=x*af;dx3=x*cz+y*sz+sx;
dy3=x*sysxczmcysz+y*sysxszpcycz+sy;
dz3=x*cysxczpsysz+y*cysxszmsycz+cy;
pxdist=if(above(dx3,0),-1,1);k1=(pxdist-ox)/dx3;
pydist=if(above(dy3,0),-1,1);k2=(pydist-oy)/dy3;
pzdist=if(above(dz3,0),-1,1);k3=(pzdist-oz)/dz3;
k=max(k1,max(k2,k3));
ix=k*dx3+ox;iy=k*dy3+oy;iz=k*dz3+oz;
diffx=lx-ix;diffy=ly-iy;diffz=lz-iz;
ld=sqrt(sqr(diffx)+sqr(diffy)+sqr(diffz));
normx=ld/diffx;normy=ld/diffy;normz=ld/diffz;
x=(equal(k,k3)*ix+equal(k,k2)*iz+equal(k,k1)*iy);
y=(equal(k,k3)*iy+equal(k,k2)*ix+equal(k,k1)*iz);
alpha=(lx*diffx+ly*diffy+lz*diffz)/25*above(k,0)*above(1-max(abs(x),abs(y)),0);

UnConeD

4th July 2003 19:58 UTC

Torturing small children for stress relief, hell yeah!

Anyway 3D Scope and 3D DM synching has been discussed before. You can't use the same code for both because they work in a completely different way, you have to convert them both to the same camera space.

13373571

4th July 2003 22:16 UTC

I got the syncing working, it was a really simple fix that for some reason I didn't realize I could do before. Ha, and I can still use my annoying code! Am I stubborn or what? Anyways, my main problem wasn't the syncing, it was the formulas for lighting that I can't find anywhere.

UnConeD

5th July 2003 15:08 UTC

Regular diffuse phong lighting is just the dot product of the surface normal with the (normalized) vector pointing to the light.

13373571

5th July 2003 15:46 UTC

cool, somewhere between that and what zevensoft said I should be able to figure this out... I haven't learned vector multiplication in school but whatever, it can't be too hard, I'll work it out. Thanks for the help.

edit: So another way of saying what you said would be "the cosine of the angle between a vector perpendicular to the plane and the vector from the intersection point to the light point"? How is distance included then?

UnConeD

6th July 2003 00:27 UTC

In Phong, it isn't... though adding it is easy and is left as an exercise for the reader.

Not that it matters much in AVS anyway due to the horrible detail.

anubis2003

6th July 2003 03:38 UTC

I haven't looked at this, but it may help you with the PHONG lighting:
http://www.programmersheaven.com/d/click.aspx?ID=F6213

13373571

6th July 2003 04:05 UTC

Thanks, but I think I've figured it out now :)