Why Overexposed Projectiles?

#1 Example: The grenade looks fine if placed as a static object, but once it is used as a projectile it looks terrible.

Static:
[good lighting image was here]

Projectile:
[bad, very bright lighting image was here]

It seems the lighting pack does something to it. I've heard there is a setting about lighting in the prefs (or defaults) that will change that.

#2 Hmmm... I never noticed that before, it looks like a bug. Try adding the following line to projectile.cc at line 1198:

if (mFadeValue == 1.0)
      {
         mProjectileShape->setupFog(fogAmount, state->getFogColor());
      }
      else
      {
         mProjectileShape->setupFog(0.0, state->getFogColor());
         mProjectileShape->setAlphaAlways(mFadeValue * (1.0 - fogAmount));
      }


      [b]glColor3f(0.5f, 0.5f, 0.5f);[/b]


      mProjectileShape->render();
   }

-John

#3 No effect. :/

#4 Is "SG_OVEREXPOSED_SELFILLUMINATION" enabled or disabled?

It won't affect the projectiles, but it'll help me devise a solution.

#5 I dunno, ran a search through the scripts and doesn't return any results for "SG_OVEREXPOSED_SELFILLUMINATION".

#6 Are you running 1.3 or 1.3.5 (sounds like 1.3)?

Open up the file "engine/synapseGaming/contentPacks/lightingPack/sgLighting.h" and search it for: SG_OVEREXPOSED_SELFILLUMINATION

Is the define there and is it commented out?

If you're running 1.3 you'll need to wait for the next release for the fix, if you're running 1.3.5 I can give you a quick fix now (or soon :).

#7 Lighting Pack 1.3.5. Yes, I can find that in the .h file and it is not commented out.

sgLighting.h

/// enable advanced lighting options
#define SG_ADVANCED_DYNAMIC_SHADOWS
#define SG_ADVANCED_DTS_DYNAMIC_LIGHTING
#define SG_ADVANCED_PARTICLE_LIGHTING
[b]#define SG_OVEREXPOSED_SELFILLUMINATION[/b]

#8 Hi Chris,

I changed the intensity of non-lit dts objects (these are different from lit and self-illuminating objects) to look much more normal.

It's a quick change in sgNewMethods.cc at line 310:

void sgTSMesh::sgSetMaterials(U32 flags)
{
	if(!(flags & TSMaterialList::SelfIlluminating))
[b]	{
		if(!TSShapeInstance::smRenderData.lightingOn)
			glColor4f(0.5f, 0.5f, 0.5f, TSShapeInstance::smRenderData.vertexAlpha.current);
		return;
	}
[/b]
	if(sgLightManager::sgGetProperty(sgLightManager::sgAdaptiveSelfIlluminationProp))
	{
		glDisable(GL_LIGHTING);
		ColorF color = sgLightManager::sgSelfIlluminationColor;
		color.alpha = TSShapeInstance::smRenderData.vertexAlpha.current;
		glColor4fv(color);
	}
	else
	{
#ifdef SG_OVEREXPOSED_SELFILLUMINATION
		glColor4f(1.0f, 1.0f, 1.0f, TSShapeInstance::smRenderData.vertexAlpha.current);
#else
		glColor4f(0.5f, 0.5f, 0.5f, TSShapeInstance::smRenderData.vertexAlpha.current);
#endif
	}
}

Let me know if this helps!

-John

#9 Indeed it has fixed it. Lighting is now very good on it. Thanks! :)

#10 How would one go about making projectiles properly lit? Your fix John keeps the object un-lit, but just tones down the overexposure... is there any way to make the object properly lit?

Cheers,

Stephane

#11 Hi Stephane,

Try adding this to Projectile::renderObject. It works, but I'm not sure how well or how it might affect your existing game assets (some projectiles may look better fully lit).

glScalef( mDataBlock->scale.x, mDataBlock->scale.y, mDataBlock->scale.z );
[b]
   this->sgSceneObjectData.installLights(this);
[/b]
   if(mProjectileShape)
   {

...

   }
[b]
   this->sgSceneObjectData.uninstallLights(this);
[/b]
   glDisable(GL_BLEND);
   glDisable(GL_TEXTURE_2D);
   glTexEnvi(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_REPLACE);

-John

#12 Wow... great stuff John! Worked like a freakin' charm... as usual, you are amazing!

I just added an 'isLit' variable to the projectile datablock that was false by default and which decided whether or not to light the projectile... just so nothing would change for my pre-existing projectiles. Thanks again!

Now all I need is to figure out how to stop projectiles from jittering when they try to bounce...

#13 Awesome, glad it worked!

#14 I've implemented the changes for the projectile and it works great, but I noticed the same problem with debris not lighting properly. Is there any way to fix so debris receive proper lighting?

Note: The shape I use looks good if I create one in the editor as a tsStatic but when it's emitted as debris it looks overexposed.

#15 It looks like the problem is that the debris object never updates its position, only its render position, so Torque doesn't know it recalculate the lighting or which lights are nearby.

The best way to fix this is to find all instances of the render transform being set and also set the position using setTransform.

If you're looking for a quick and dirty fix you can just try this:

In debris::renderObject:

if( (mShape && DetailManager::selectCurrentDetail(mShape)) ||
       (mPart && DetailManager::selectCurrentDetail(mPart)) )
   {
      glMatrixMode(GL_MODELVIEW);
      glPushMatrix();
      dglMultMatrix(&mObjToWorld);
      glScalef(mObjScale.x, mObjScale.y, mObjScale.z);


      [b]mLightingInfo.mDirty = true;[/b]


      installLights();

      Point3F cameraOffset;
      mObjToWorld.getColumn(3,&cameraOffset);

-John

#16 @John: The fix makes it look somewhat better, but now they are to dark and nearly impossible to see instead :/ I've checked the debris and it seems to me like the setTransform is set every tick.

void Debris::processTick(const Move*)
{
   // Update real position info.
   [b]setTransform(getRenderTransform());[/b]

   if (mLifetime <= 0.0)
      deleteObject();
}

I would be able to live with that hack but I would really want the debris to be lighted properly.

#17 Hmm, looking at the object there's some weird client/server stuff going on, and I'm not sure exactly why it's not being lit by other lights. I'll need to look into this further.