Playermodels tend to be (very) dark in my custom map (Fast light compile <> Final full compile)

[PreFXDesigns]

Hello everyone!

I'm PreFX and I'm a member of Jedi of Freedom (JoF). I'm an experienced skinner but still quite new to mapping.
This map you are about to see, in the spoiler below, I have made for JoFBall. This is an upgraded gamemode of Kyleball. Some of you might still remember kyleball, it's a football/soccer themed game.
In JoFBall we have replaced the 'Kyle npc' with a ball (edited sentryball) and have scripts running that prevent you from dying on the pitch. This new map allows everyone to play on the same time instead of having to take turns (3v3) in the original Kyleball4 map. I'm really proud on what I have achieved in such a short time period (+/- 3 months).

Spoiler

The issue I have is that the playermodels tends to be very dark in most spaces with a fast light compile. However only in the stadium (Anfield) it seems to be rather okay. Perhaps this is due to the larger open space?
It seems that the character is also brighter while being in the air, i think this is due to the red/blue panels in the arena (1st & 2nd picture) and the bricks in the street map (3rth & 4th picture) blocking off the light.

Below you can see another demonstration on the difference between a FINAL(BSP, Full VIS, Full Light) and FINAL (long time compile) from the Q3map2GUI compiler.

You might think, why not go for a final long compile? Well, I tried this for only 1/3 of the map and this already took over 8 hours (still at bounce 2 at that moment ...).

I noticed in the Q3map2GUI compiler that you can choose a ton of options. Perhaps it is possible to fix this issue by making a custom compile without it taking to long to compile?

I would really appreciate if something could give me his/her expertise on this  

Greetings,
PreFX

[Aldro Koon]

5 hours ago, PreFXDesigns said:

Hello everyone!

I'm PreFX and I'm a member of Jedi of Freedom (JoF). I'm an experienced skinner but still quite new to mapping.
This map you are about to see, in the spoiler below, I have made for JoFBall. This is an upgraded gamemode of Kyleball. Some of you might still remember kyleball, it's a football/soccer themed game.
In JoFBall we have replaced the 'Kyle npc' with a ball (edited sentryball) and have scripts running that prevent you from dying on the pitch. This new map allows everyone to play on the same time instead of having to take turns (3v3) in the original Kyleball4 map. I'm really proud on what I have achieved in such a short time period (+/- 3 months).

  Hide contents

The issue I have is that the playermodels tends to be very dark in most spaces with a fast light compile. However only in the stadium (Anfield) it seems to be rather okay. Perhaps this is due to the larger open space?
It seems that the character is also brighter while being in the air, i think this is due to the red/blue panels in the arena (1st & 2nd picture) and the bricks in the street map (3rth & 4th picture) blocking off the light.

Below you can see another demonstration on the difference between a FINAL(BSP, Full VIS, Full Light) and FINAL (long time compile) from the Q3map2GUI compiler.

You might think, why not go for a final long compile? Well, I tried this for only 1/3 of the map and this already took over 8 hours (still at bounce 2 at that moment ...).

I noticed in the Q3map2GUI compiler that you can choose a ton of options. Perhaps it is possible to fix this issue by making a custom compile without it taking to long to compile?

I would really appreciate if something could give me his/her expertise on this  

Greetings,
PreFX

If you don't get any answers here, make a topic after creating an account here:
https://www.quake3world.com/forum/viewforum.php?f=10

And if still nothing, PM this guy (obsidian):
https://www.quake3world.com/forum/memberlist.php?mode=viewprofile&u=3448

[MaceMadunusus]

On 1/16/2022 at 4:55 AM, PreFXDesigns said:

The issue I have is that the playermodels tends to be very dark in most spaces with a fast light compile. However only in the stadium (Anfield) it seems to be rather okay. Perhaps this is due to the larger open space?

The -fast compile parameter is the cause of that. If you read what fast actually does below, you'll kind of understand why it does that.

Quote

fast

• Enables light envelopes for area (shader) lights. This includes radiosity lights. Results in a much quicker -light compiles, but darkens all enveloped light sources considerably—this can be compensated for easily by raising your surfacelight values.

You can do what the wiki says above to compensate, but you can also do things like a key of _mingridlight in the worldspawn, with a light value for the value and it will bump up the light grids ambient value only rather than the entire map. However, I would just recommend removing the fast parameter from the compile and doing things the normal way.

 

On 1/16/2022 at 4:55 AM, PreFXDesigns said:

You might think, why not go for a final long compile? Well, I tried this for only 1/3 of the map and this already took over 8 hours (still at bounce 2 at that moment ...).

I have personally found bounce 2 to not be worth the compile time. The detail is negligible in-game and most people wont notice unless you have a specific case that takes advantage of it. Which these maps definitely do not do. I usually do bounce 1 instead.

Using super is also part of your issue, again to quote the wiki: 

Quote

-super <N>

• Enables arbitrarily ordered grid supersampling of lightmaps. This is much, much, much slower than -samples, by the way.

This is the light parameters I use for a majority of levels:

-light -patchshadows -v -samples 4 -thresh 0.1 -bounce 1 -bouncegrid

Depending on the level, I'll add things like -filter, -samplesize, -bouncescale.

[PreFXDesigns]

On 1/17/2022 at 11:49 PM, MaceMadunusus said:

The -fast compile parameter is the cause of that. If you read what fast actually does below, you'll kind of understand why it does that.

You can do what the wiki says above to compensate, but you can also do things like a key of _mingridlight in the worldspawn, with a light value for the value and it will bump up the light grids ambient value only rather than the entire map. However, I would just recommend removing the fast parameter from the compile and doing things the normal way.

I have personally found bounce 2 to not be worth the compile time. The detail is negligible in-game and most people wont notice unless you have a specific case that takes advantage of it. Which these maps definitely do not do. I usually do bounce 1 instead.

Using super is also part of your issue, again to quote the wiki: 

This is the light parameters I use for a majority of levels:

-light -patchshadows -v -samples 4 -thresh 0.1 -bounce 1 -bouncegrid

Depending on the level, I'll add things like -filter, -samplesize, -bouncescale.

Thanks for the reply!

I tried setting up a custom compile in Q3map2GUI with the following settings like you described: -light -patchshadows -v -samples 4 -thresh 0.1 -bounce 1 -bouncegrid.

I was optimistic that I wouldn't take too long. I started compiling 19:45 my time and when I woke up to check my pc at 7:45 it was still running

Isn't there a faster way to solve this or do I really need this bounce? It seems that this is causing such a long compile time.

Thanks in advance! 

[MaceMadunusus]

12 hours ago, PreFXDesigns said:

Isn't there a faster way to solve this or do I really need this bounce? It seems that this is causing such a long compile time.

There is probably more at play here than just simple compile lines, like sun shader settings, detail vs structural not simple enough, unrestrained lightgrid, an underpowered computer, etc. For a map like this, I don't personally see the point in doing a bounce compile.

[Aldro Koon]

@PreFXDesigns Do you seperate between detailed and structural brushes in radiant? That should impact compile time quite much and it will also affect fps performance ingame. All brushes inside of a room should be selected and made into detail whereas every brush touching the surface outside (void) should remain structural.

[PreFXDesigns]

On 1/20/2022 at 8:44 AM, Aldro Koon said:

@PreFXDesigns Do you seperate between detailed and structural brushes in radiant? That should impact compile time quite much and it will also affect fps performance ingame. All brushes inside of a room should be selected and made into detail whereas every brush touching the surface outside (void) should remain structural.

Of course  The anfield (stadium) map is quite big and there i noticed lower performances during testing. I fixed it by setting detail/structural brushes, but the better performance mostly came by setting all hidden brushes into caulk. More specifally all brushes behind the stadium that you can't see anyway. 

 

On 1/19/2022 at 8:31 PM, MaceMadunusus said:

There is probably more at play here than just simple compile lines, like sun shader settings, detail vs structural not simple enough, unrestrained lightgrid, an underpowered computer, etc. For a map like this, I don't personally see the point in doing a bounce compile.

Yeah you are probably right and yeah i don't see the point in doing a +15 hour compile anyway.

I appreciate you guys trying to help out this noob  

[NumberWan]

This is a very interesting discussion. Compiling a map for JA is perhaps the least favourite things... (I'm not alone here).

There are different things, which affect the compile time, indeed. Textures that emit light also seem to cause trouble in this regard, but too many models, shaders and other things too. Too bad JA is a game from the old times, when you couldn't create a new map in real-time, seeing everything right away.