Problem with the Japan Pack roof props

[ThePykeSpy]

Hello, good people!

I am somewhat new to the whole mapping scene, so I apologize in advance if this is something that could be easily figured out, but after doing some research and testing myself, I thought perhaps people with more experience would know.

I've been messing around with the Japan Content Pack to create some things, and a bunch of strange lighting related things have come up in regards to the roof props. I'm not too upset if there isn't an easy fix right away, but I'm quite interested in getting a basic understanding of what is even happening. I've even brought screenshots. Bear with me though, I might get the terminology wrong.

Exhibit A.

When I build using the roof props, sometimes they seem to become a little discolored.

It's likely a little hard to see, but the corner piece has the original blueish gray tint, while the props in the middle are slightly darker and tinted greenish. Why is that?

Exhibit B.

The undersides of the roof pieces seem to have some kind of lighting issue.

At least to me, this doesn't look like just natural shadow, but rather an issue with the lighting of the prop. I'm also confused as to why this isn't a "regular" problem. I understand that the corner pieces were built with an angle, while the middle pieces have to be rotated first, which might affect lighting, but sometimes there's this bug and sometimes there isn't.

I've taken a screenshot from Sulfur, where the props seem much more normally shaded. I assumed maybe this is a clipping problem, but then why are there no lighting bugs here?

Exhibit C.

Something that came up, which confuses me, is this.

I used a brush to close the gap between the two roof ornaments, something which I've seen done on Sulfur and Suijin, yet while it looks fine on those maps, here it causes... this.
Once again, I assume it is clipping, but I don't understand why it only happens here and not with Sulfur/Suijin. Also, why are some of the props only discolored and others entirely blacked out?

Exhibit D.

Finally, some more shadow related shenanigans.

I think my assumption is not too farfetched that this is the brush in the center of the roof casting a shadow, but why is it oriented perfectly straight? The environmental light is at an angle, which should be visible in the first screenshot.

Another example from a different building:

Bottom Text.

I have no idea if I'm being too sensitive with these issues. I do understand that Hammer is an older program, and maybe I'm just using it in a way that it wasn't intended for. I'm just confused that, even though I tried to emulate the way Sulfur and Suijin were built, I still get these strange problems with the roof props.

Hope that someone can help me! If more screenshots or information are required, I'll gladly update the post.

 

[Sonoma]

have you tried compiling with -final -StaticPropLighting -StaticPropPolys -TextureShadows ?

 

[ThePykeSpy]

have you tried compiling with -final -StaticPropLighting -StaticPropPolys -TextureShadows ?

I tried it just now, and sadly, none of the issues seem to have changed. Thank you for the advice though!

 

[nesman]

What about attaching a light_origin entity to the props with lighting issues? I will admit is is hard for me to see some of the issues in the first/second screenshot.

 

[ThePykeSpy]

What about attaching a light_origin entity to the props with lighting issues? I will admit is is hard for me to see some of the issues in the first/second screenshot.

Do you mean an info_lighting? That might be a worth a try. That would make it a clipping issue then, right?
Though, I believe I read somewhere that using info_lighting can cause problems later down the road, or did I misread that?

As for the screenshots, I was kinda worried it might be hard to see. But I tried to get some better screenshots just in case.

The same roof, once with and without anything below.

Picture taken from Suijin

My perception is that the wood turns darker smoothly on the Suijin picture, with natural shadows, while on my picture, it looks more like a lighting error, where the inner parts are really dark while the protruding parts remain really bright. But that might just be because I don't have a feel yet for how props are lit in general.

As for the discoloration, this is the best closeup I can get.

The left part is more of a blue, while the right part is sort of greenish I guess.

 

[nesman]

info_lighting

yeah I did, I can never remember the name of it.

info_lighting can cause problems later down the road

I haven't run into any issues with it and I used it a lot on rumford.

Maybe @Freyja can suggest anything since she one one of the minds behind that pack originally.

 

[ThePykeSpy]

Semi-Necroing my post, but I've been cooking for a few days now, trying out some things here and there.
Since that first map I made was a little overloaded, I started a new project on the side, where I experimented some more.

First off, after going through the Suijin and Sulfur maps, I've seen that most of the brushes which touch the roof props are func_details; out of sheer curiosity, I just turned the entire building into a func_detail, since I need it optimized anyway (funny polygon pillars), hoping it would fix the lighting. Sadly, it did not.

I did try using info_lighting (and by that I mean I went fully overboard and created an individual light for every top and underside, coming out to 16 light checks), the results of which are below:

Honestly my problem at this point is I have no idea/sense for what these props are supposed to look like when "properly" used/lit.
Naturally, it would be lovely if the original prop creator would chime in, but until then, I guess I'll keep on cooking.

 

[Freyja]

I use no special tricks in Sulfur and Suijin apart from compiling with the full lighting parameters (-staticproplighting, -staticproppolys). From the appearance of your screenshots, it looks like you are not compiling with those settings, and I saw you said you were but the result appears that it is not taking affect for some reason.

What methods are you using to compile with those settings?

 

[ThePykeSpy]

I use no special tricks in Sulfur and Suijin apart from compiling with the full lighting parameters (-staticproplighting, -staticproppolys). From the appearance of your screenshots, it looks like you are not compiling with those settings, and I saw you said you were but the result appears that it is not taking affect for some reason.

What methods are you using to compile with those settings?

Thanks for taking the time!

These are the settings I use for compiling:

Since it's kinda cut off, these are the parameters I've typed in:

-final -StaticPropLighting -StaticPropPolys -TextureShadows

Other than that, I just press Run Map and pray.

 

[Tiftid]

Parameters typed in that screen will be launch arguments sent to the TF2 exe.
We want to instead send our parameters into vbsp.exe, the program that simulates our lighting.
To do that, click this "Expert" button:

You should get a screen that looks like this - just with fewer parameters than what I've typed in.
Click on "$light_exe":

And enter the parameters in here:

There are essentially three ways to light a prop - light origin, vertex lighting and lightmaps.
YM goes over two of them in this fantastic article: http://www.nodraw.net/2010/12/lighting-compile-options/

info_lighting can cause problems later down the road

This may be where you've read that:

The reason why he's so vehemently against info_lighting here is cause it causes the prop to no longer be lit on a per-vertex basis.
All lighting for the prop is instead calculated at the infinitesimally small point the info_lighting represents, so the prop basically looks fullbright.
Compiling with the bonus commands will supposedly be a better way to solve issues like what you've mentioned here:

Exhibit D.

Finally, some more shadow related shenanigans.

I think my assumption is not too farfetched that this is the brush in the center of the roof casting a shadow, but why is it oriented perfectly straight? The environmental light is at an angle, which should be visible in the first screenshot.

Another example from a different building:

I have no idea if I'm being too sensitive with these issues. I do understand that Hammer is an older program, and maybe I'm just using it in a way that it wasn't intended for. I'm just confused that, even though I tried to emulate the way Sulfur and Suijin were built, I still get these strange problems with the roof props.

Hope that someone can help me! If more screenshots or information are required, I'll gladly update the post.

However, other factors can force a prop to ignore vertex lighting:

• The "Disable Vertex Lighting?" keyvalue is set to Yes, possibly because you've copied it from someone else's map file
• The model's texture has a normal map:

All models that use Phong shading will also force-disable vertex lighting, since $bumpmap is a required parameter for $phong.

However, I combed through all of the pack's model textures, and none of the roof props have either $bumpmap or $phong.

The biggest issue I could notice in an old map of mine that used them, was that the props would get dramatically darker when you took the camera closer to them, no matter what lighting method you use. This issue is also present on koth_suijin!
This is because of LOD-switching - since the distances at which it swaps out the props are so ridiculously short, you can have one side of a small roof be dark and one side be light. That's potentially what's happening to you here:

Exhibit A.

When I build using the roof props, sometimes they seem to become a little discolored.

It's likely a little hard to see, but the corner piece has the original blueish gray tint, while the props in the middle are slightly darker and tinted greenish. Why is that?

Unfortunately, I don't think there's an easy fix for this besides recompiling the prop - a process which is definitely not beginner-friendly.
However, as a player, you can fix it by setting r_lod to 0, or really any value that isn't -1, because only r_lod -1 allows dynamic LOD-switching.

For the undersides of the roof (which have no LODs), I believe the problems arise from poor construction of their mesh:
(It's not specifically poor construction - they did this to make it lower-poly, but it had unforeseen implications)

It's a little hard to see, but the wood panel that all the little beams are resting on is only made of 8 triangles in total.
Notably, these triangles don't actually join with all the little beams - the beams are just sitting under the panel.
Remember when I called it "VERTEX" lighting?
Well, the name's not just for show. In meshes like these, the lighting system only gets 10 samples for all the shadows across the entire wood panel.
The lighting samples also don't even remotely respect the edges of the little wood beams, so you start to get downright crazy shadows which seem to start or end with no rhyme or reason:

Or, much more commonly, there are too many shadows and the lighting system decides that the wood panel should be fully dark, even when some wood beams are still receiving light:

This has two possible fixes:

1. Edit the model to have a cleaner, higher-poly mesh
2. Use an info_lighting or the "Disable Vertex Lighting?" keyvalue to disable vertex lighting on the prop and just let it be fullbright
3. Use prop lightmaps:

This will cause the prop to be lit by a "lightmap texture", which if its resolution is set high enough (64 is good enough for most props) can represent light much more accurately than only sampling once per vertex.

Spoiler: Pointless Rambling

There are, of course, certain disadvantages to this approach, as I state in this post:

There they are! The evil lightmaps Tiftid is trying to psyop you into using!

Luxel size 4	Luxel size 16

It's a well-known fact that you can adjust the luxel size down on a per-surface basis (with the default being 16).
Well, it was well-known in 2009, at any rate.
A smaller number gives you sharper, prettier shadows that better represent the shape of the object casting them.
(Quick side-note: Luxel sizes smaller than 16 look REALLY bad with the usual SunSpreadAngle of 5. Use a SunSpreadAngle of 0.5 instead if you wish to use these luxel sizes.)
However, this feature shouldn't be overused, as trying to load a map with too many low-luxel-size surfaces will crash with the error message "Engine hunk overflow!"
As such, I quickly developed a set of rules for my use of this technique:

• Only use a value smaller than 16 on surfaces that are actually at the edge of a shadow - faces fully in shadow or fully in sun don't get any benefit from increased shadow definition
• Divide large faces up so that you're only using a smaller size on the portion of them which has the edge of a shadow
• Use the largest size that will still accurately depict the shape of the shadow (usually 4 or 8)
• Be very careful with displacements, since if they're bigger than about 256x256 they won't accept a luxel size of 4 (it literally gets changed to 5)

This is written for brushes, but prop lightmaps have the same downsides, where they inflate the filesize and contribute towards engine hunk overflow.
Also, confusingly, brushes will have better shadow definition with a lower "luxel size" value, while props will have better shadow definition with a higher "lightmap resolution X/Y" value.

Here is what the props look like when lightmapped:

Hmm, that's not so good either! What's going on here?
Well, what I think is happening is that the model is set up to use a basic wood texture, and just repeat it over and over again along the length of the model.
Unfortunately, this also means the lightmaps get repeated, as you can see with the prop in the far right - it has a repeating black spot on its bottom trim.

So basically, your best bet is to give up and let these props be fullbright.

 

[EArkham]

I made different roof pieces, like, 7 years ago because I didn't like how janky the ones I'd done for the Japan Pack were.

Japan Pack Expansion

JAPAN PACK EXPANSION PART I Created by EArkham 2016 http://steamcommunity.com/profiles/76561198000713080 Some content is derivative of official Valve content, all rights reserved. A collection of custom models and assets to enhance the Japan...

tf2maps.net

If I remember correctly, the aggressive LOD on the original ones were because one of the playtesters kept complaining about their framerates on Suijin back in the day.

 

[ThePykeSpy]

First of all, thanks for the comprehensive answer!

I admit I might be a little stupid, but after using the expert tab, as you told me:

Parameters typed in that screen will be launch arguments sent to the TF2 exe.
We want to instead send our parameters into vbsp.exe, the program that simulates our lighting.

You should get a screen that looks like this - just with fewer parameters than what I've typed in.
Click on "$light_exe":

And enter the parameters in here:

---

So basically, your best bet is to give up and let these props be fullbright.

this is the result on my two maps:

I don't think this is what we were gunning for is it?
I think deleting what was already in that text box and replacing it with the other things might have been a mistake, and I have no idea how to get the base values back. Oops.

I will probably check out @EArkham's other roof pack in the meantime, thanks for dropping by and letting me know about it!

 

[Tiftid]

The base parameters for "$bsp_exe", "$vis_exe" and "$light_exe" are always "-game $gamedir $path\$file", as you should be able to see from the other fields that still have them filled in.
You need to put this after the "-final -StaticPropLighting -StaticPropPolys -textureshadows" stuff.
So, the full string would be "-final -StaticPropLighting -StaticPropPolys -textureshadows -game $gamedir $path\$file".

 

[ThePykeSpy]

The base parameters for "$bsp_exe", "$vis_exe" and "$light_exe" are always "-game $gamedir $path\$file", as you should be able to see from the other fields that still have them filled in.
You need to put this after the "-final -StaticPropLighting -StaticPropPolys -textureshadows" stuff.
So, the full string would be "-final -StaticPropLighting -StaticPropPolys -textureshadows -game $gamedir $path\$file".

Thanks! After I plugged that in, this was the result:

In my opinion, that does indeed look significantly better and a lot closer to what is found on Suijin and co. There still seem to be one or two kinks here and there, especially when the single width roof tiles become involved; those have two underside props for some reason, which both clip at the side. But I think I'll try and work with this for now. I'll probably return to this post if anything else major goes wrong down the line. Thanks a lot, everyone!
Honestly I feel a little silly, making it seem like it's a problem with the props and not my lack of knowledge, but I was honestly worried I was too dumb to work with them, considering I quite like how they look.

As a small side note, @Freyja or @EArkham, is there any chance the tatami mats from Sulfur could be made accessible? Those are basically all I still need to fulfill my various Japan based mapping fantasies.

 

[Freyja]

Tatami mat is in https://tf2maps.net/downloads/sulfur-content.1189/ (it's not in the screenshot but it's in there)