light not illuminating post?

[Springheel]

I'm not sure what's going on here. I have a candle sitting on a regular sconce, and for some reason it is not illuminating the post the sconce is attached to. The post is just black. If I pick up the candle and take a step back, the post becomes illuminated and you can see the wood. The candle is nowhere near clipping into the pillar in the first position. Any idea what might be happening here?

[demagogue]

I vaguely remember an issue like this--a candle inexplicably not lighting a brush--and at least in my case, IIRC, it had to do with the brush itself, like the texture or messy brushwork (a sliver somewhere) or the like... (Edit: If I had to guess, I think it was something to do with the material data for the texture.) I think I don't remember well because I just completely redid the brushwork in the end to fix it. Anyway, it's a quick thing to test (e.g., change the texture or put another post to another side to see if it has the same effect, etc.)

[nbohr1more]

Is the light attached in such a way that the light_center is at the exact location as the flame particle?

 

What falloff texture is being used? Perhaps the gradient is reversed or skewed?

[Springheel]

It's a default candle, so nothing special going on there, and the post is a model with no obvious abnormalities. I'll try swapping the model out for something else and see if that's causing it.

[Springheel]

Ok, so when I replace it with a brush pillar using the same texture, it illuminates properly. That's a bit concerning...what could cause a model to not illuminate properly?

[nbohr1more]

What does it look like when you invoke:

 

r_showNormals 1

 

or

 

r_showVertexColor 1

 

or

 

r_showTangentSpace 3

 

are the normals correct?

[Springheel]

Hmm, after further tests, it's not the model. This is happening with ALL models. When you get the candle right up to a model, it barely illuminates it at all. Has it always been this way? It even happens with brushes to some extent (note the floor at the end, which is a brush).

 

 

 

[nbohr1more]

I have a hunch about the hard-coded skydir in our interaction shaders, but Rebb is the man for a case like this...

 

I'll try out a few changes to the interaction_direct.vfp tonight if I get a chance.

 

Nearly all of your operations have the candle parallel to the wall\object what does it look like when oriented perpendicular?

(Just to get a head start on this...)

[demagogue]

Just by the logic of it, it implies there's something fishy with the light falloff. It wouldn't be a simple quadradic falloff from a point source and do that, but like a falloff from some sphere source around the flame(?). This is now officially beyond my ken though, so I don't want to speculate.

[Springheel]

Nearly all of your operations have the candle parallel to the wall\object what does it look like when oriented perpendicular?

 

 

Rotating the candle a number of different angles results in no change to the effect seen in the video.

[grayman]

I noticed this when I was working with some skybox models. It was as if the center of the light was "somewhere else", lighting things up properly over there, but not where I was expecting it. I got around it by not putting any light sources near the models.

[Springheel]

I just loaded up an old 1.07 version and was able to reproduce the behaviour, so I guess it's not new.

[demagogue]

In tdm_light_textures.mtr line 124 there are some comments suggesting some candles use a lightmap (biground1_candleshadow) with what it says is a downward shadow in the middle to serve as the wax obscuring that part of the light. Could it be that?

[Springheel]

I'll take a look when I get home.

[ERH+]

I also noticed it recently but thought that normal map behave this way when texture is stretched. But shadows in some textures always worked in odd ways, even on TDM models.

Edited September 22, 2016 by ERH+

[Dragofer]

I'll add my own observation that when testing my spherelamps I noticed that they'd badly illuminate the brush wall they're attached to, while the other wall in the corner was much better illuminated. If I remember right the stock lanterns behaved in a similar way. I had to put the light origin as far out in the bulbs as possible to reduce this.

[Destined]

I am not sure, if this is due to the same reason or something else entirely, but a "wall appears too dark" behaviour is also described in the A-Z Tutorial when the correct light radius is discussed:

 

Because the wall on which the torch is mounted receives light at a very shallow angle and it fades rapidly to zero along it then it will look much too dark if the other walls are very bright. In the worst cases it can look almost black by comparison. Try it out and you will see what I mean. If you then reduce the radius so it only extends beyond the far walls by 10 or 20 units then it will look much more natural.

[Springheel]

In tdm_light_textures.mtr line 124 there are some comments suggesting some candles use a lightmap (biground1_candleshadow) with what it says is a downward shadow in the middle to serve as the wax obscuring that part of the light. Could it be that?

 

 

Oh, this refers to the faked cast shadow underneath the candle. No, that has nothing to do with it, as the behaviour is visible in 1.07, long before I added the shadowlights.

 

, but a "wall appears too dark" behaviour is also described in the A-Z Tutorial when the correct light radius is discussed:

 

 

Well in this case it is only affecting models, not brushes. When I replace the model pillar with a brush pillar the same distance away, the problem goes away (or is severely reduced).

[AluminumHaste]

@spring, if you replace the candle with a light entity, does it do the same thing?

[nbohr1more]

Try this compile with this shader:

 

https://dl.dropboxusercontent.com/u/17706561/world_up.zip

 

I added Rebb's "world up" fix from the Ambient Light to all lights.

No performance degradation that I can detect and nothing seems broken.

[Springheel]

@spring, if you replace the candle with a light entity, does it do the same thing?

Missed this...I'll have to try these.

[nbohr1more]

I found the wood asset you were originally testing. The new compile and shader does not cure the issue.

 

I found that the normal map has a 100% blue channel and that seems to be a big part of the issue.

 

I used the scale keyword to reduce the blue channel:

 

scale(texture R, G, B, A)

 

and found that it improved the proximity behavior but at the cost of making the normals too strong,

using the smoothnormals keyword and reducing the R and G channels improved that.

 

Here is the material update as of my last testing (feel free to tweak to your preference):

 

textures/darkmod/wood/boards/rough_wood_darkbrown_dull
{
    wood
    qer_editorimage textures/darkmod/wood/boards/rough_wood_darkbrown_dull_ed

      bumpmap  smoothnormals(scale(textures/darkmod/wood/boards/rough_wood_fungi_local, 0.88, 0.88, 0.61, 1))
      diffusemap   	textures/darkmod/wood/boards/rough_wood_darkbrown_dull

    {
        if ( parm11 > 0 )
        blend       gl_dst_color, gl_one
        map         _white
        rgb         0.40 * parm11
    }
    {
        if ( parm11 > 0 )
        blend       add
        map         textures/darkmod/wood/boards/rough_wood_darkbrown_dull
        rgb         0.15 * parm11
    }

	// TDM Ambient Method Related 
	{							
		if (global5 == 1)		
		blend add				
		map				textures/darkmod/wood/boards/rough_wood_darkbrown_dull		
		scale			1, 1		
		red				global2	
		green			global3	
		blue			global4	
	}							

}

That or look at tweaking the normals of the texture in njob to see if you can get the look you want.

[Springheel]

Not sure why the normalmap would cause that issue when the same texture on a brush doesn't exhibit it, but at least that gives me something to go on to fix that case, thanks.

[nbohr1more]

I think the difference is the default vertex normal behavior of models vs brushes.

 

Maybe puffing out the vertex normals on the model or tinkering with the smoothing might get it closer to how brushes behave?

 

The interaction shader does normal scaling to make the normal maps stronger but I suspect that this global behavior is part of the

proximity strangeness. We could drop that feature but then the normals wouldn't have that "deep" look that was requested without

recreating a bunch of normal map images. Adjusting the scaling in the material allows you to fix\improve it selectively.

[Springheel]

I tried it out and I can't confirm that the normalmap is having any effect on the light problem. While the scaling does affect how bright the model is, it affects it uniformly, and doesn't change the fact that parts of the model are not being illuminated by the light. Turning the normalmap completely off has no effect on the issue either.

 

Compare the following images: