Hacking in dynamic lights

#1 Maybe there's an off by one error somewhere? BTW, cool screenshot!

#2 Thanx ben,

I call this abomination of a hack GELight.. (G)ood (E)nough because it should (with a few updates here and there) provide general placement of lights and get our team through until SGLP for TSE and Milestone 4 . It requires an additional custom material pass to ps2.0 shader hardware. Lights are added via the mission editor and can be control via script.

The theory is simple..in material.cpp (for each object/material) grab the closest 3 lights and pass their info into the shader registers.

I'm hooking the nearest light's vector into VC_LIGHT_DIR1 to affect normal maps.


I have sucessfully tested this with > 8 lights affecting multiple objects.
Most of the bugs seem to be related to my lameness.

current bugs:

-light info is overwriting the lightmap normal on intertors - find out what registers/samplers/textures units i am brutalizing, and play nice..
-color affects light intensity /attenuation distance


todo:

-fix bugs!
-add a gizmo to the object in the mission editor, so you can move it around easier
-figure out some way to determine if the current fragment is facing away from the light, so light doesnt "bleed through" objects.
-shader fallbacks

#3 I'm very interested in lighting Kevin, so I for one would appreciate seeing the changes you had to make. Not to mention that just having more shader-related helper/hints code in the forums is always a good thing in my oppion -- Tim.

#4 @Kevin - Maybe you should make a resource for this.

#5 Ben was right, NumLights - 1 ..so thats fixed...

PLEASE somebody tell me how to get that freaking GIZMO!
Right now the little balls you see are actually DTS markers to tell me where the light is.

I stripped it down to just pass lightpos and color so im able to squeeze 3 lights per material...grabs the nearest 3 lights.

#6 Hiya,

Vector BrokenLightsArray;

should be

Vector BrokenLightsArray;

list of pointers NOT structs ;p


neo

#7 Looks like that did the trick.. Thanx neo..

ps:and no crash on exit

#8 No prob, always the simple ones that get ya ;p

As a trick to remember, whenever you see Vector = new Something double check the template argument as one almost always forget the pointer hehe

#9 Do i need to destroy/free the it when im done?

#10 From the tse docs:

***WARNING***
///
/// This template does not initialize, construct or destruct any of
/// it's elements. This means don't use this template for elements
/// (classes) that need these operations. This template is intended
/// to be used for simple structures that have no constructors or
/// destructors.

From looking at the source it seems it only frees the internal list array, not memory pointed to
by the list contents:

// template inline Vector::~Vector()
// {
// dFree(mArray);
// }

So i would say destroy the elements yourself (if they are pointer based) just to be safe

#11 Neo is correct. Good eye, Neo! :)

#12 Ok heres whats goin on:

Im getting some nice action, normal map shader is suppose to be getting their LIGHT_DIR from the closest point light.

heres the array builder:

objPosition = objTrans.getPosition();
		for( U32 lightIndex = 0 ; lightIndex < NumLights;lightIndex ++)
	 {  
	  alight = mLightManager->getLight(lightIndex) ;
			GELightsArray[lightIndex].index =  lightIndex;
		//dx = Ax-Bx 
		//dy = Ay-By 
		//dz = Az-Bz 
		//distance = sqrt(dx*dx + dy*dy + dz*dz)
		
			float dx = alight.mPos.x -objPosition.x ;
			float dy = alight.mPos.y -objPosition.y ;
			float dz = alight.mPos.z -objPosition.z ;
			float distance = sqrt(dx*dx + dy*dy + dz*dz);
			GELightsArray[lightIndex].distance  =  distance;
			iLightCount++;
		}

anyway heres where it goes next

//now sort the lights.. this is probably WAY slow....
			InefficientLightSort(GELightsArray,iLightCount);
	
			//Get the closest light	
			alight = mLightManager->getLight(GELightsArray[0]->index) ;
			lightCol = alight.mColor;
			GFX->setPixelShaderConstF(PC_GELIGHTCOL1, (float*)&lightCol,1);
			
			lightPos= alight.mPos;
			objTrans.mulP( lightPos );
			GFX->setVertexShaderConstF(VC_GELIGHTPOS1, (float*)&lightPos, 1 );

I'm using C27,C29,C9,C10,C13,C14
and
TEXCOORD1,TEXCOORD2, TEXCOORD3

if that makes a difference
corrected distance formula

#13

Quote:

//dx = Ax-Bx 
      //dy = Ay-By 
      //dz = Az-Bz 
      //distance = sqrt(dx*dx + dy*dy + dz*dz)
      
         float dx = -alight.mPos.x -objPosition.x ;
         float dy = -alight.mPos.y -objPosition.y ;
         float dz = -alight.mPos.z -objPosition.z ;
         float distance = sqrt(dx*dx + dy*dy + dz*dz);

I would say don't negate light components (the distance will always be positive because of the squares). You only care about sign when you are doing vector operations (cosine of angle between light vector and surface normal, etc).

Also it mucks with the distance calc e.g (for alight.x = 4 and obj.x = 2 ):

dx = -4 - 2 == -6 => -6 * -6 = 36 (flipped)

but

dx = 4 - 2 == 2 => 2 * 2 = 4 (non flipped)

The second code snippet seems fine as it uses the light values directly (don't know if you're worried about range, power, etc). It therefore seems that the issue comes from picking the wrong light according to the skewed distance calc.

Also you might try collecting N closest lights and blend for a final light color/saturation/direction, etc, or you will get popping as objects move from one set of lights to another.

regards
neo

#14 Thanx Neo.. I updated the post...
Im still having problems with interiors..

#15

Quote:
Thanx Neo.. That fixed it and I updated the post...and now for something completely different..
Im still having problems with interiors..Sometimes they work sometimes not..
please pardon the big images but i wanted to show the debugger :
i5.photobucket.com/albums/y161/iNterstices/working.jpg
i5.photobucket.com/albums/y161/iNterstices/broke.jpg


or am I going completely insane?!

I don't see this post anywhere (is it in another thread somewhere?) so I reposted it here for ya in case it went missing.

The first thing that jumps out at me is the the huge numbers for distance and index fields on some entries (perhaps these are just debugger artifacts?), but that's beside the point as we're dealing with light 0 and that seems ok ;p

The only difference i see between the two is:

working:

light2.color == 0.0 0.1 0.0 0.3 (<---- alpha???)

broke:

light2.color == 0.0 0.2 0.0 1.0 (<----???)

The only other thing off the top of my head is whether you relit the scene or not (accounting
for interior lightmap gen, etc)

Other than that I'd have to dig a bit first

#16 @Kevin - What's your status with this?

My artist is asking "Why are my shapes lit by the sunlight and not my interior lights?" and other such pesky questions. I figure i better cook up a solution for him and you're changes seem right down that alley.

So how does this work with respect to lightmaps? Do they properly effect static shapes in the scene?

Brian, how does this stuff look in relation to your plans for TSE milestone 4?

#17 The MS4 dynamic lights should affect the bumpmaps and light properly with the lightmaps.

#18 How do I get my hands on this? is this still around? is this a resource yet?

#19 Hey Anton...

I pretty much abandoned the resource for this, mainly cause my own project was getting real busy, and supporting a resource like this was probably going to be a nightmare. Like the name implies this is a HACK, requires ps2.0, but it does use the lightmanager. The codebase is from head (over a year ago) but i do still have it. The issues I was having with interiors were probably related to portaling, and since map2dif has been updated they may no longer be an issue. Basically The idea is to grab the lights from the lightmanager and override the LIGHT_DIR (presently the sun) registers in materials.cpp, so all the shaders use the nearest light instead of the sun. (originally the resource was going to be called "Hijacking the SUN" for this very reason)

But, like i said, I havent really touched this in about a year, so if you dont mind porting extremely OLD code, and following the code ramblings of a madman on very little sleep, shoot me an email and ill see if i can get it to ya..

k

#20 Kevin,

I sent an email to your profile email. Thanks.