BUG: sun/light flares show through objects,with videos to show the bug.

#1 Interesting, how to fix it depends on how it was implemented (which I do not have time to look at atm :(

If it's done in a shader, a simple depth-check should do it I believe.
Does it happen on all objects or just the first person gun-model?

#2 I've dug in this area before and it's not pretty. It's done with an occlusion query. I suspect the first person model is excluded from that test for some reason. You can find more information in: LightFlareData::_testVisibility

Spoiler: I think someone made lightflare on a tight schedule. It's really not great. An occlusion query every frame even if the light source is not in view frustrum? A blocking occlusion query at that? But why?

#3 Not much to add to Andrews findings, except that the specific case for your hand not occluding is contains in the chunk:

const bool fps = conn->isFirstPerson();
      GameBase *control = conn->getControlObject();
      if ( control && fps )
         control->disableCollision(); //<------------------------

      RayInfo rayInfo;

      if ( !gClientContainer.castRay( camPos, lightPos, LosMask, &rayInfo ) )
         *outOcclusionFade = 1.0f;

      if ( control && fps )
         control->enableCollision();

Of course, simply not disabling that is a non-starter since you'll never see lensflares in first person that way... Might be something that could be done related to one of the things I ran across tonight when digging around:

void GuiTSCtrl::onRender(Point2I offset, const RectI &updateRect)
{...
// Set the default non-clip projection as some     // objects depend on this even in non-reflect cases.
    gClientSceneGraph->setNonClipProjection( mSaveProjection );

but afraid at the moment, that just amounts to marking a spot and handing you a spade. Hope it at least sparks a notion.

#4 after some digging it seems that if there is a collision box on the object/model then it doesn't shine through it.

#5 I have fixed this a few days ago, i upload a PR next week. (include change occlusion test for a nonblocking)

The problem it's ScatterSky don't set the necessary data for occlusion test. If no occlusion then engine try a castRay test.

For vector lights (sun), occlusion test need flareState->worldRadius > 0.0f github.com/GarageGames/Torque3D/blob/development/Engine/source/T3D/lightFlareDat...

Sun object set data on github.com/GarageGames/Torque3D/blob/development/Engine/source/environment/sun.c...

But not ScatterSky github.com/GarageGames/Torque3D/blob/development/Engine/source/environment/scatt...

#6 its great that you fixed the issue Luis, can you explain what you did?
I have no patience to wait till next week :)

#7 He's saying that for the occlusion to be properly executed flareState->worldRadius needs to be > 0.0f. The sun sets that property here:

https://github.com/GarageGames/Torque3D/blob/development/Engine/source/environment/sun.cpp#L361-L369

However, ScatterSky does not:
https://github.com/GarageGames/Torque3D/blob/development/Engine/source/environment/scatterSky.cpp#L653-L661

#8 Can someone post the fix, hate seeing sun flare inside buildings.

#9 This seems like the most recent thread deepscratch responded to. Anyone know how to contact deepscratch ? email doesn't seem to work?
Thx
Dirk