Hanging light model question

[duzenko]

@Nbohr1more has pointed out a strange visual glitch with the hanging light model: models/darkmod/lights/extinguishable/cagelamp_hanging.lwo

It's casting unwanted shadows when in the shadow maps mode.

It has two surfaces:

• main surface with material tdm_streetlamp_metal which is noshadows - this one is OK
• bottom of the holder with material tdm_coals_hot - this one is supposed to cast shadows but for some reason it's not casting shadows in stencil mode - it looks as if the surface is deemed back-facing by stencil code even though it's clearly front-facing to the light view.

I would appreciate anyone shedding some light on why the bottom surface is getting culled with stencil - is it a renderer bug or am I missing something? Maybe something's special about the model itself?

 

The map in question is NHAT (anoot.map)

[Springheel]

I don't see anything special about the model. You're sure it's not the entity that is forcing noshadows on?

[duzenko]

The entity seems to not have that spawnarg

[duzenko]

Sorry, I think the model needs a fix

Either the small surface needs a no-shadow material, or the entire entity a no-shadow spawn arg.

It's not casting stencil shadows because apparently stencil shadows are sometimes only based on back faces. And the model kinda exploits that by having front faces in one material and back faces in another.

[Bikerdude]

I was the last person to work on that map, but it sounds like its an issue with the entity. Can you give me the exact entity name and location and I will copy and paste that into a test map..

[duzenko]

I was the last person to work on that map, but it sounds like its an issue with the entity. Can you give me the exact entity name and location and I will copy and paste that into a test map..

anoot.map, models/darkmod/lights/extinguishable/cagelamp_hanging.lwo

 

One of the warehouses

]getviewpos
-3439.24 3447.35 306.67   -17.7 -127.4 0.0

[Bikerdude]

I will try and have a look at that on Sunday.

[nbohr1more]

OK.

I'm gonna return to this discussion and be a bit of a "pain in the arse".

Regardless of way that surfaces are considered (facing or not) the noshadows_lit arg
should remove all shadowed surfaces in the entity when the light is activated.

One thing we could do to better compare the rendering paths is to create a new
entity arg "noshadows_lit_n" which does not use the script interface to accomplish
the change. Instead it would use some sort of hook that passes the "lit" flag to the render def
when it's changed on the game side.

If the new arg works but we cannot identify why the old one fails we can just rename the

new arg and comment out the script side operations.

I have a rough idea about how to get this done but I'll defer to better coders until I'm
forced to wield my own hacky attempt.

[duzenko]

OK.

 

I'm gonna return to this discussion and be a bit of a "pain in the arse".

 

Regardless of way that surfaces are considered (facing or not) the noshadows_lit arg

should remove all shadowed surfaces in the entity when the light is activated.

 

One thing we could do to better compare the rendering paths is to create a new

entity arg "noshadows_lit_n" which does not use the script interface to accomplish

the change. Instead it would use some sort of hook that passes the "lit" flag to the render def

when it's changed on the game side.

 

If the new arg works but we cannot identify why the old one fails we can just rename the

new arg and comment out the script side operations.

 

I have a rough idea about how to get this done but I'll defer to better coders until I'm

forced to wield my own hacky attempt.

Do you think that script does anything for lights that aren't toggled in game? I.e. the hanging light in NHAT is just on from the very beginning and since no changes happen then probably the script does not get called?

[VanishedOne]

If it uses the tdm_light_holder scriptobject, presumably its init() method will get called. However, the relevant part of the script seems just to invoke the noShadows() script event:

if (getKey("noshadows_lit") == "1")
	{
		//sys.println(sys.getTime() + ": DEBUG: light holder setting shadows");
		noShadows( !m_bExtinguished );
	}

[Springheel]

The relevant detail is whether it is an entity or just a model. Some mappers just place a model and then add a flame entity manually to it, so the script would not come into play.

[duzenko]

The relevant detail is whether it is an entity or just a model. Some mappers just place a model and then add a flame entity manually to it, so the script would not come into play.

What is "it" and where is it defined (as model or entity)?

[nbohr1more]

I'll get the entity def tonight.

 

It must be an entity or else the noshadows_lit arg wouldn't work in Stencil Shadows mode.

 

It's almost certainly:

 

atdm:torch_cagelamp_hanging

[duzenko]

Is this it?

// entity 894
{
"classname" "func_static"
"name" "func_static_2452"
"bind" "func_pendulum_13"
"model" "models/darkmod/lights/extinguishable/cagelamp_hanging.lwo"
"origin" "-3479 3418 373"
}

If so, am I right that it's instantiated as an idStaticEntity in the C++ code and is not bound to any script?

[Bikerdude]

I will try and have a look at that on Sunday.

I haven't gotten around to do this, do I still need too..?

[duzenko]

I haven't gotten around to do this, do I still need too..?

Can you replace the funcstatic above with atdm:torch_cagelamp_hanging?

[Springheel]

Is this it?

// entity 894
{
"classname" "func_static"
"name" "func_static_2452"
"bind" "func_pendulum_13"
"model" "models/darkmod/lights/extinguishable/cagelamp_hanging.lwo"
"origin" "-3479 3418 373"
}

If so, am I right that it's instantiated as an idStaticEntity in the C++ code and is not bound to any script?

 

Right. The mapper has just placed it as a model, not an entity. This will be the case in numerous maps, I imagine, especially older ones.

[nbohr1more]

Pretty strange.

 

If it's not the noshadows_lit arg doing this then I can't really understand why no shadows are rendered

in Stencil Shadow mode.

 

I'll recheck the tonight.

 

Does the coal DDS texture have an alpha channel?

 

If it's alpha tested then stencil mode will treat it like noshadows I believe.

[duzenko]

No, AFAIU the coal surface is considered "back-facing" and culled because of that. The stencil code seems to only process triangles facing away from the light.

 

You can test that by switching materials on the two surfaces that make up the model. Currently one of them is noshadows.

[nbohr1more]

@Springheel:

 

May I request that you update the tdm_coals_hot material in the hanging cagelamp lwo models with the new tdm_coals_hot_ns material?

 

Thanks.

[Springheel]

There are several light models that use that texture...is the cagelamp the only model that shows a problem? Also, do we know that this won't break custom skins mappers may have used?

[nbohr1more]

There are several light models that use that texture...is the cagelamp the only model that shows a problem?

Also, do we know that this won't break custom skins mappers may have used?

I would say that any light entity where this texture might cast shadows is a candidate for this workaround.

 

Custom skins will only be an issue if they

 

1) use the original hot coal texture

2) are part of a light emitting entity

3) the texture is not supposed to produce a shadow

 

Thus far, I have not seen widespread problems as described above.

NHAT 1 and 2, and a (i think) a different cagelamp in The Rat's Triumphant that was not gameplay impacting for that mission.

[Springheel]

3) the texture is not supposed to produce a shadow

 

 

The issue with skins isn't whether it is supposed to cast a shadow...if a mapper made a custom skin, it would turn black if the model's original textures are changed.

 

I've gone back and reread the thread, but I need a clear description of what the problem is, or a description of how to reproduce it. The model is casting shadows when it shouldn't, or it isn't casting shadows when it should?

[nbohr1more]

It's casting a shadow when it shouldn't.

 

Shadow Map mode.

 

r_shadows 2

[nbohr1more]

.if a mapper made a custom skin, it would turn black

It would only make the "changed texture" black right? Other textures would still render?

If so, a barely visible hot coal texture inside the cage lamp goes black on custom skinned models?

 

Collateral damage seems to be minimized there.