Texture lighting anomaly

[drahcir_dier 0]

I am looking for advice with regards to a lighting anomaly encountered with a custom building I have been working on. Under normal lighting conditions the wall textures display normally, however while using a directed light source, such as a torch, the textures exhibit bizarre shadowing. When the torch is pointed directly at the wall the texture turns completely black. Its obviously something to do with the texture settings or the nohq file or something, but I am not experienced enough to know what might be causing this issue. I have linked to two images below demonstrating the behaviour. 

 

Under normal lighting conditions:

https://drive.google.com/file/d/106PQNgVPha1C9dwr5ViXWPFii-287op_/view?usp=sharing

 

Under directed lighting from a torch:

https://drive.google.com/file/d/17mkLZVnIfgTJAHycIu_SeEb15BeW3eBs/view?usp=sharing

 

Any help would be appreciated.

Cheers!

 

 

 

 

[Jackal326 1181]

Perhaps its a sharp/smooth edge issue? Try sharpening the edges of those walls and ceiling, or the entire faces (selected the area in Object Builder and press 'U'

Could also be a shadow LOD issue, but that would be more apparent from outside of the building and not just directed light...

Might be an issue with the rvmat and some textures (nohq or smdi) being missing/incorrectly pathed.

[drahcir_dier 0]

Thank you for the response @Jackal. Unfortunately, none of the solutions offered appear to have helped. 

 

I have played with the nohq textures a little more, and they certainly appear to be working as expected based on the visible lumpiness of the surfaces. But the specular lighting under torch light still tears in weird ways. 

 

I totally removed the shadow LOD and set the LodNoShadow variable to true in all remaining lods, and the problem persisted. I'm almost certain its not a shadow issue... which is one step forward.

 

The tearing seems to occur along the diagonals of quad faces, as shown here:

https://drive.google.com/file/d/1cdGSiT6G-nufkC9u1cQ1M2OuKQ_iSgYF/view?usp=sharing

 

I had a lot of hope that changing the edges to "sharp", and thereby aligning the normals to the faces would fix the issue but it hasn't. A particularly striking example of the problem is shown here:

normal lighting:

https://drive.google.com/file/d/1FoaLxIiN2km_97YKh2A2MSyzWfCMyRd4/view?usp=sharing

torch lighting:

https://drive.google.com/file/d/180PYfFAoC3dFpY8P7cdh6hnKv4zzP53c/view?usp=sharing

It's bizarre that of two adjacent faces, mapped together with the same texture and rvmat, and sharing the same properties, one is approximately correct while the other is totally black. It is like an entire face is either lit, or unlit, depending on some angle between the torch and the wall. Turning in place makes different triangular chunks of the wall light up or go dark. Walking up close to the wall doesn't result in the expected round spot, but rather a totally black wall. 

 

I was hoping that there was a simple issue with an in correctly chosen check box property.... Is someone able to clarify the function of the following settings in the "Face Properties" menu:

 

In the "Lighting & Shadows" tab, how do the 'normal', 'both sides', 'position', 'flat', 'reversed' modes work, and to precisely which shadows does the property "Enable Shadows" apply. Does it mean those cast by the Shadow LOD, or something else?

 

Similarly the "Z-bias" settings of 'low', 'middle' and 'high'. To what does this refer?

 

Thanks for any help ....

 

 

 

[Jackal326 1181]

9 hours ago, drahcir_dier said:

[...]

I was hoping that there was a simple issue with an in correctly chosen check box property.... Is someone able to clarify the function of the following settings in the "Face Properties" menu:

 

In the "Lighting & Shadows" tab, how do the 'normal', 'both sides', 'position', 'flat', 'reversed' modes work, and to precisely which shadows does the property "Enable Shadows" apply. Does it mean those cast by the Shadow LOD, or something else?

 

Similarly the "Z-bias" settings of 'low', 'middle' and 'high'. To what does this refer?

 

Thanks for any help ....

 

 

 

The "Lighting and Shadows" tab is deprecated now and no-longer does anything (other than throw errors telling you its deprecated and no-longer works when you Binarize the model)...

If you select the faces and press 'E' the option just says "Lighting and Shadows" but if you press SHIFT+E its named "Lighting (Obsolete)" - Those options are now handled by rvmats etc (at least the 'Shining' option is anyway).

As for "Z-Bias", that refers to rendering priority when faces are over-lapping or are on the same plane. I seem to remember a small tutorial from one of the Skyrim devs about how Z-Bias settings allowed them to render the sky box in the correct order i.e. mountains in the distance, in front of clouds in front of the sky, but can't seem to find the video that explained it. Anyway, a quick google search brought up this which probably explains it more succinctly.

 

The only other suggestions I can think of are to: Triangulate and sharpen the affect faces (rather than just sharpening the quads).

or maybe check out the rvmat settings. In fact, would you mind posting your rvmat?

[drahcir_dier 0]

I'd tried triangulating and sharpening the edges earlier, with no luck.

 

I can confirm though, by examining the lighting patterns, that the faces are being lit based on the illumination of the vertices only. Pointing the torch at the corner of a face strongly illuminates the half of the face closest to that vertex. Strangely, the lighting is maximum when illuminated from 45 degrees rather than dead on, which is inconsistent with the vertex normals shown in Object Builder. 

 

Based on the "whole face" lighting effects, therefore, it appears my rvmat isn't working as I thought. It is attached below ... hopefully I've missed something elementary ...

 

#define _ARMA_

ambient[] 	    = {0.9,0.9,0.9,1.0};
diffuse[] 	    = {0.9,0.9,0.9,1.0};
forcedDiffuse[] = {0.0,0.0,0.0,0.0};
emmisive[]	    = {0.0,0.0,0.0,1.0};
specular[]	    = {0.5,0.5,0.5,0.0};
specularPower   = 10.0;
PixelShaderID   = "NormalMapSpecularDIMap";
VertexShaderID  = "NormalMap";

class Stage1
{
   texture  = "iranian_embassy_addon\data\Wall_nohq.paa";
   uvSource = "tex";
};

class Stage2
{
   texture  = "iranian_embassy_addon\data\Wall_smdi.paa";
   uvSource = "tex";
};

And here are the NOHQ (Created from the _CO texture using the normal map generator plugin in GIMP 2.0)

https://drive.google.com/file/d/1OLzUb--85PdTm6MXQf7mgA29k5IOE3hg/view?usp=sharing

 

and the SMDI file (R=1, G=grayscaled _CO, B = 0.8)

https://drive.google.com/file/d/1_d7MlMzNGMoMvTZVgS5AtutS3Szb2Nru/view?usp=sharing

 

 

 

 

 

 

 

 

[Jackal326 1181]

OK, I'm not overly familiar with how PixelShaderID = "NormalMapSpecularDIMap"; and VertexShaderID = "NormalMap"; differ from the "Super" pixel shader I'm used to using for my weapons so I can't speak for those, but humour me and try this rvmat instead. 🔻

#define _ARMA_

ambient[] = {0.75,0.75,0.75,1};
diffuse[] = {0.75,0.75,0.75,1};
forcedDiffuse[] = {0,0,0,0};
emmisive[] = {0,0,0,1};
specular[] = {1,1,1,1};
specularPower = 20;
PixelShaderID = "NormalMapSpecularDIMap";
VertexShaderID = "NormalMap";
class Stage1
{
	texture = "iranian_embassy_addon\data\Wall_nohq.paa";
	uvSource = "tex";
	class uvTransform
	{
		aside[] = {1,0,0};
		up[] = {0,1,0};
		dir[] = {0,0,0};
		pos[] = {0,0,0};
	};
};
class Stage2
{
	texture = "iranian_embassy_addon\data\Wall_smdi.paa";
	uvSource = "tex";
	class uvTransform
	{
		aside[] = {1,0,0};
		up[] = {0,1,0};
		dir[] = {0,0,0};
		pos[] = {0,0,0};
	};
};

For reference, this file I used as a base was 'structures_f_households\house_big01\data\u_House_Big_01_MLOD.rvmat'

 

The only thing different are the top few lines' values, and the inclusion of the uvTransform information in the 2 stages where the normal map and specular maps are defined. Not sure whether they'll have an affect but we'll see.

 

 

[drahcir_dier 0]

Unfortunately that Rvmat produces the same error. Subtle changes in the light levels because of the "ambient" and "diffuse" values but no change to the broader problem.

 

I suppose one question is, how would we expect Arma to light faces in the absence of an rvmat? What is the default behaviour. It seems reasonable to calculate lighting based on the face vertices in the absence of any pixel data .... I might try copying one of the vanilla buildings and strip the rvmats to see if that replicates what I'm seeing in my building.

 

Other things to consider ....

-  Do the nohq files require an Alpha channel? I am wondering whether the alpha is absent or set to zero and therefore the nohq may not be doing anything. I will double check my files.

-  Are there any issues associated with textures above a certain number of pixels? The wall texture is 2048x2048.

 

[drahcir_dier 0]

Okay; I can confirm that the example house in "Arma3_Samples", which has no rvmats, exhibits the same lighting problem. 

 

Seems like my nohq is not working at all and I'm getting the "default" lighting.

 

baby steps .....  

[drahcir_dier 0]

As an additional test, I created a highly exaggerated nohq texture for the wall. The normal mapping is very apparent when viewing the model in Bulldozer, but appears to have no effect when loaded in game.

[Jackal326 1181]

On 10/6/2021 at 1:37 AM, drahcir_dier said:

As an additional test, I created a highly exaggerated nohq texture for the wall. The normal mapping is very apparent when viewing the model in Bulldozer, but appears to have no effect when loaded in game.

It sure sounds like whatever application you're using to pack your PBO isn't packing it properly as the _NOHQ (and probably _SMDI etc) aren't present or pathed correctly...

[drahcir_dier 0]

A bunch of more digging around and I managed to fix the lighting issue; Moving to the "multi" shader turned out to be the solution.

However another strange pathology has come up with regards to viewing the textures through windows. My building is assembled in five pieces, where each asset corresponds to one floor of the building. I am having a problem where the textures on level four vanish when viewed through the widows on level three, but ONLY when viewed at a particular angle:

 

Textures appear correctly:
https://drive.google.com/file/d/1trCD7ecHayZXgF9krpk10XPAzvYSGFTp/view?usp=sharing

 

Move viewing angle slightly and fourth floor textures vanish:

https://drive.google.com/file/d/10I-EXk0Sw8puhv4c7dWKfXQ6IG5-2mah/view?usp=sharing

 

As another example, here is the second image again but this time with the upper left window pane shot out:
https://drive.google.com/file/d/1gQUSdwy3GMtTsexi5HyyBmDlRz5QyvqX/view?usp=sharing

 

Has anyone encountered this before? I have already raised the window textures using "Faces -> Move Top" without success; I am guessing because the windows and and the problem textures are not actually part of the same model. A Similar effect occurs with the ceiling textures when I stand outside the building and look up through the windows.

 

Any tips?

 

 

 

 

[Jackal326 1181]

11 hours ago, drahcir_dier said:

[...]

I have already raised the window textures using "Faces -> Move Top" without success; I am guessing because the windows and and the problem textures are not actually part of the same model. A Similar effect occurs with the ceiling textures when I stand outside the building and look up through the windows.

 

As you've already tried what was going to be my first suggestion (Faces - Move Top) for the windows I'll make another suggestion:

Go into your Geometry LOD (which I am sure you'll already have) and add the following named properties:

forcenotalpha = 1

canbeoccluded = 0

canocclude = 0

My suggestion would be to try and add them one at a time to see which (if any) have an affect.

I'm not convinced this will fix your issue, however it may well be worth a try. I've experienced the issue when working on weapon optics, however its always been fixed by sorting the faces and layering them correctly. Its not been affected by being part of different models as you're experiencing so I'm unsure how else to address the issue other than my above suggestion. I hope it works out for you or if it doesn't someone else will have a fix for you...

 

[drahcir_dier 0]

On 10/21/2021 at 6:35 AM, Jackal326 said:

forcenotalpha = 1

canbeoccluded = 0

canocclude = 0

 

 

I tried each of these to no avail.

 

I did get some improvement by changing the rvmat of the glass to another "Window" texture in a3/data_f/ that fixed the "greying out" effect, and now simply causes the texture to get a bit brighter or darker ....

 

Seems its related to the glass rvmat then ... 

 

Will continue digging.

[Jackal326 1181]

9 hours ago, drahcir_dier said:

 

I tried each of these to no avail.

 

I did get some improvement by changing the rvmat of the glass to another "Window" texture in a3/data_f/ that fixed the "greying out" effect, and now simply causes the texture to get a bit brighter or darker ....

 

Seems its related to the glass rvmat then ... 

 

Will continue digging.

My guess would be the renderFlags array.

[drahcir_dier 0]

The lighter-darker effect with the new RVMAT is actually the window texture vanishing, as seen here:

https://drive.google.com/file/d/1VH0ZEZ0BdQnllqlxoZIGugSNYeSjzrUB/view?usp=sharing

 

The angular dependency is strange ... Faces -> Move Top doesn't help, which makes sense considering the texture is actually displayed correctly most of the time. 

 

I will look into the renderFlags and see if that helps. Is there any documentation as to what values the renderFlags can take?

 

 

[drahcir_dier 0]

2 minutes ago, drahcir_dier said:

Is there any documentation as to what values the renderFlags can take?

 

My mistake ... it's right there in the wiki ... derp.

[drahcir_dier 0]

Some good news at least:

 

The "Greying out" effect I talked about above can be re-created by removing the "NoZWrite" command from the renderFlags array.

 

Although no improvement on the latest problem.