Jump to content

Warning: Degenerate T Junction Edge found


Recommended Posts

I was creating light switches for a map I'm making and the lighting started getting messed up when I tested the map. First I got multiple Hit surface per style limit 4 warnings, and a floor texture was all black, so I temporarily turned the switchable lights back into normal lights by removing their connection to a trigger_multiple entity that I used as a light switch. While that got rid of those warnings, the lighting was still messed up. Then I saw there was still 2 warnings "Degenerate T Junction Edge found". I'm not sure how to fix this issue...before these warnings started appearing, the lighting was realistic based on the light source, but now everything looks super dark and the shadows are oddly cast even using the final compile. Before the issues appeared there was a circle of light coming from where each light texture is placed.

 

shot2023-11-15_03-18-16.jpg

shot2023-11-15_03-17-57.jpg

shot2023-11-15_03-18-09.jpg

Link to comment

I doubt the T-Junction error has much to do with the lighting, although it is possible. See if a brush cleanup will help with the T-junction error.

There is a limit on light styles per surface, though, and that's likely what's causing the most serious issues here.

The best approach to switched lights is to use as few switches (And styles) as possible. If I understand correctly, light entities are grouped together by their targetnames during compile, and there's a limit of four different light styles (Switches included) per surface. It's okay to hit the limit, but surpassing it will screw things up royally.

For reference, it is possible to use switched lights to make an RGB system, with a switched red, green and blue light on the same surface. It will hit the limit and throw warnings, but it does not surpass the limit, so it remains functional. However, any other switched/styled lights touching the same surfaces will break it.

Link to comment
52 minutes ago, NAB622 said:

I doubt the T-Junction error has much to do with the lighting, although it is possible. See if a brush cleanup will help with the T-junction error.

There is a limit on light styles per surface, though, and that's likely what's causing the most serious issues here.

The best approach to switched lights is to use as few switches (And styles) as possible. If I understand correctly, light entities are grouped together by their targetnames during compile, and there's a limit of four different light styles (Switches included) per surface. It's okay to hit the limit, but surpassing it will screw things up royally.

For reference, it is possible to use switched lights to make an RGB system, with a switched red, green and blue light on the same surface. It will hit the limit and throw warnings, but it does not surpass the limit, so it remains functional. However, any other switched/styled lights touching the same surfaces will break it.

In those images all the lights are just 'light' entities as I removed the target from the trigger_multiple box and removed targetnames from all the lights. The lights themselves only vary in brightness level and a couple color variations. That's why I'm confused that the lighting is still messed up. The stone buttons are currently just func_door brushes that toggle back and forth when the trigger box is activated by the player, but no longer trigger the lights.

I'm a bit confused as to what does and doesn't count as a "light style" hitting a surface. I didn't add a style key to any lights, I only changed the brightness and color of some lights and made two spotlights (not in pics), and some of the lights have Start_Off checked.

EDIT: I unchecked Start_Off for all the lights and recompiled and it turned on some lights but the lighting still looks weird for some reason. I'm also no longer getting the surface limit warning, as disabling the switches took care of that. Its just the strange boxy shadows that I'm trying to resolve. The pic below shows how the lights looked before the issue appeared.

satori.jpg

Link to comment

 

29 minutes ago, jedimaster123 said:

I'm a bit confused as to what does and doesn't count as a "light style" hitting a surface

Any light with a style key, or a unique targetname, counts as a styled light. Multiple lights with the same targetname are grouped together and will function together as a single style. Color and brightness are irrelevant in all cases.

 

Can you post a few pictures of the current state? Depending on how blocky the result is, there may be several solutions. Assuming nothing is glitched, my immediate thought is to identify the problematic surfaces, make them a func_group, then add a _lightmapscale value of 0.5 or less, and see if it helps.

Link to comment
19 minutes ago, NAB622 said:

 

Any light with a style key, or a unique targetname, counts as a styled light. Multiple lights with the same targetname are grouped together and will function together as a single style. Color and brightness are irrelevant in all cases.

 

Can you post a few pictures of the current state? Depending on how blocky the result is, there may be several solutions. Assuming nothing is glitched, my immediate thought is to identify the problematic surfaces, make them a func_group, then add a _lightmapscale value of 0.5 or less, and see if it helps.

Oh okay. Well I had total 4 trigger_multiples that each was activating a unique set of lights. Those lights only varied in brightness and color and some had Start_Off checked. But, I no longer get this warning with the switches disabled but the box lighting persists. I only have 2 T-junction warnings when I compile. And basically, there are 3 rooms connected by two tunnels in this map, and all 3 rooms have the same lighting problem. The pic with spheres around the torches shows what it used to look like, and the spectate pic shows the most recent compile with all light switches removed (only point lights). Other than that I added structural details like curves and brush changes in the after pic.

satori.jpg

shot2023-11-15_05-14-13.jpg

Link to comment
7 minutes ago, jedimaster123 said:

Well I had total 4 trigger_multiples that each was activating a unique set of lights

I suppose I should have clarified, the default lighting also counts as a style, so the maximum you can have in that room is 3 styled/triggered lights. You may need to rethink what you're doing. Speaking of, what exactly is your goal there? There might be another approach that works.

 

As far as the spectator shot, I'm not sure what's going on there! Weird stuff.... Are you using patch meshes in the corners perhaps?

Link to comment
1 hour ago, NAB622 said:

I suppose I should have clarified, the default lighting also counts as a style, so the maximum you can have in that room is 3 styled/triggered lights. You may need to rethink what you're doing. Speaking of, what exactly is your goal there? There might be another approach that works.

 

As far as the spectator shot, I'm not sure what's going on there! Weird stuff.... Are you using patch meshes in the corners perhaps?

Well I had 3 triggered sets of lights in one room. Then a 4th set of triggered lights in a different room. However the rooms are connected by open tunnels so maybe light spills through from one room to another. The issues did seem to appear once I added the 4th switch. Before that they were functional.

My first goal is just to get back to the lights looking normal like they did in the first shot. My second goal was to create sets of lights that turned on by a physical switch. I did it by creating a trigger_multiple in front of a button. Then I made the button into a func_door with 'toggle' checked. Then I had the trigger_multiple target a set of lights + func_door when used by the player, so the button (or door) moves to the "open" position as the lights turn on and stays there until used again and the button moves to the "closed position" as the lights turn off. I don't know if there's a better way to achieve this...

The corners have bevel curves although I should caulk behind them...from what I remember the lighting still normal right after I rounded the corners.

EDIT: Okay...I joined a normal game and to my surprise the lighting was screwed up on the base jka maps too so it wasn't an issue with my map. It is some problem with my JA++ mod which I recently added some server side files which may have broken something with the graphics...so with respect to mapping I just need to make the switches work without creating the surface limit problem.

Much better...

shot2023-11-15_07-03-18.jpg

shot2023-11-15_07-26-21.jpg

mjt likes this
Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...