brush-models made with propper having wonky lighting

sharktemplar

L1: Registered
Feb 26, 2018
18
2
I've been using propper to turn medium or small brushes with high face-counts into models in a map I'm making. I know propper is a rather old program to get this job done, but I know already how to use it so it was out of convenience for me at the time.
It seems that the lighting on these models is very inconsistent and is based on where the model is placed in relation to light sources.
n3krNM9.jpg

Those two cupboard handles that are weirdly black are a propper-made custom model. As you can see, they are receiving improper lighting information.
(Yes, I have already tried an info_lighting, but this seems to do absolutely nothing to change the lighting at all, almost as though the model is ignoring the light origin set to it entirely)
The strange thing is that the other cupboard handles are also this exact same model, but their lighting is just fine, and looks exactly like it looked before these small brushes were turned into models.
Here are some other examples:
xfVvEW4.jpg

The handle for the right-side closet door suffers from this same issue, but just in case you thought this was a problem that only occurred in a single way:
XRDuziN.jpg

This is one of my room door handles, and it's not mostly dark, but instead abnormally bright. Now, the reason it's bright and not dark might be because the model was made with the texture metal/metalchrome001 on it (same as the metal plate the door handle rests upon, so you can see the lighting it should have).

Does anyone have any ideas of how I can approach this problem? I'm genuinely stumped, as light origin shenanigans was all I really had up my sleeve in terms of knowledge to try and troubleshoot this behavior in the map.

In case it's relevant, the process I go through to make a brush model is very wonky itself, and absolutely not the best way to do it, which I admit. I've just yet to really hunker down and figure out a more streamlined way than what I was used to a long time ago.

I open Source SDK and open hammer in a pre-established custom propper-use configuration that runs on the 2007 source engine. I then open the same vmf I was working on, manually transfer the .vtf and .vmt files (after extracting them via GCFScape) from the tf2 directory to the sourcemods propper directory and place them back into the respective locations (metal/*, wood/*, etc) to get specifically just the textures I need to be recognized by the outdated source engine hammer configuration, and do the regular propper compile process, then take the outputted models and materials files and simply paste them back into my tf2 directory in their necessary locations.
I've done this process on a larger model, the size of an entire door, and the lighting appears on it perfectly fine, as though it was still made out of brushes, in case anyone thought perhaps this happened with every model produced in this unorthodox fashion via propper.

Many thanks for any tips or pointers of where I can start to try and resolve this.
 

sharktemplar

L1: Registered
Feb 26, 2018
18
2
Are you compiling with these options?
http://www.nodraw.net/2010/12/lighting-compile-options/
Also play around with the lighting settings at the bottom of a prop_static's property window.
Warning: These properties only work if the compile options above are enabled.
While I didn't know anything about these new vrad parameters for compiling, utilizing them is, as far as I can tell, useless in my particular situation because all of the models with wonky lighting are not prop_static, but prop_dynamic, and are parented to a func_door or func_door_rotating as the cupboards and doors are interact-with-able. Prop_dynamics don't have all these lovely lighting options, but thank you for telling me how they worked. Never could notice a difference when I tinkered with them in the past and now I know why.

Any other possibilities?
 

ficool2

L4: Comfortable Member
Oct 28, 2017
161
232
While I didn't know anything about these new vrad parameters for compiling, utilizing them is, as far as I can tell, useless in my particular situation because all of the models with wonky lighting are not prop_static, but prop_dynamic, and are parented to a func_door or func_door_rotating as the cupboards and doors are interact-with-able. Prop_dynamics don't have all these lovely lighting options, but thank you for telling me how they worked. Never could notice a difference when I tinkered with them in the past and now I know why.

Any other possibilities?

Lighting origins should work in this case, but I believe that its broken in some source engine builds (definitely in TF2). I remember someone posted a workaround which was to use a info_target for the lighting origin and then use a SetLightingOrigin input, but I'm not sure if this applies for all games.

Another time-consuming workaround is to bake the lighting into the model's texture (though you will need to use a 3D modelling program for this). Though this means you need to re-bake the UVs of the model, bake the lighting, and pack it all into an independant texture just for it. This will use up quite a bit of file space too.
 

sharktemplar

L1: Registered
Feb 26, 2018
18
2
Lighting origins should work in this case, but I believe that its broken in some source engine builds (definitely in TF2). I remember someone posted a workaround which was to use a info_target for the lighting origin and then use a SetLightingOrigin input, but I'm not sure if this applies for all games.

Another time-consuming workaround is to bake the lighting into the model's texture (though you will need to use a 3D modelling program for this). Though this means you need to re-bake the UVs of the model, bake the lighting, and pack it all into an independant texture just for it. This will use up quite a bit of file space too.
I ended up re-propper-ifying some of the models to have a bigger bounding box, which seemed to completely fix the lighting issue they suffered from, and just settled with the shiny door handles being brushes again, as I highly doubt even that lightorigin trick would resolve their weird sheen that they have to them as a propper model.
I will have to try that though. It sounds like it would work.
Edit: For future reference, info_lighting models do not work when used as a prop's light origin, period. However, simply changing them to info_target entities and assigning them as a prop's light origin works perfectly. No actual need for the SetLightingOrigin trick, at least in tf2.
Thanks a bunch for the tip. Having light origin functionality back will be a big help to me!
 
Last edited: