Port my realtime shadows mutator over to UT04

[Mutant117]

Hello fellow community,
few months ago I have finished my realtime shadows mutator for Killing Floor which works to my satisfaction there.
I wonder whether people are interested in seeing this ported over to UT04 as this might only be a recompilation job (hopefully).

Major features:
- Up to 3 shadows per pawn
- Acceptable performance (fully configurable)
- Dynamic light support
- Shadows are way less bugged compared to other systems

[Baryonyx]

There's a real time shadows mod for UT2004 already, however it has been reported it does not work, perhaps doesn't work with other mutators.

So, I'd like to see this!

[Mutant117]

Well, there is one out there by JCBDigger which is based on SquirrelZeros approach (my mutator is also based on it but 99% had to be changed/extended), but those shadows are too buggy.

I forgot to mention one major feature:
- Dynamic light support

[bass3]

I say go for it, i miss real time shadows!

[Budboy]

Hello fellow community,
few months ago I have finished my realtime shadows mutator for Killing Floor which works to my satisfaction there.
I wonder whether people are interested in seeing this ported over to UT04 as this might only be a recompilation job (hopefully).

Major features:
- Up to 3 shadows per pawn
- Acceptable performance (fully configurable)
- Dynamic light support
- Shadows are way less bugged compared to other systems

hell yes I want to see a real time shadows mutator

[Mutant117]

I have ported the mutator and it works great, but as UT2004 is very fast-paced and maps are literally flooded with lights my shadows fade in/out a lot.
So far, I have no idea how to tackle this.

[Budboy]

maybe it's because of the light brightness?

try a map with darker lights, then again on another map with brighter lights

can you give a screenshot of what you meant by the shadows fading in/out?

EDIT: before when I was playing around to make screenshots of them zerglings with Samus, her skin looks ridiculously white because UT2004 lights do not take kindly to lightly colored surfaces(in this case samus' skin). So while thinking of a way to fix that one of the topics in here gave me an idea of a mutator that basically sets the light actors to a set brightness. So after some testing and tweaking I figured a lightbrightness of around 30-40 is ideal for said lightly colored surfaces, while at the same time it still looks good on other surfaces most of the time. Maybe you can look into that as well

EDIT2: My code looks something like this. Basically I created a replicationinfo class with the following PostBeginPlay code(Ignore the saturation for now as I was trying to test the effects of reducing the saturation levels):

simulated function PostBeginPlay()
{
local Light A;
local SunLight B;
//for basic lights
foreach AllActors(class'Light', A)
{
if (A.LightSaturation > 100.0)
{
A.LightSaturation = 100.0;

}
if (A.LightBrightness > 30.0)
{
A.LightBrightness = 30.0;
}

//A.LightBrightness = MaxLight;
//A.LightSaturation = MaxSaturation;


}
//for sunlight actors
foreach AllActors(class'Sunlight', B)
{
//B.LightBrightness = MaxLight;
//B.LightSaturation = MaxSaturation;
if (B.LightBrightness > 40.0)
{
B.LightBrightness = 40.0;
}
if (B.LightSaturation > 100.0)
{
B.LightSaturation = 100.0;
}

}
}

Then create a mutator class and add said replicationinfo class in the PreBeginPlay function/method

[Mutant117]

It is not the brightness, it is that my shadows will always be determined by the most priorized lights surrounding the player (up to 3). Whenever a new light is considered higher priorized then the former, the old shadow fades out and the new one fades in.
Therefore, a lot of lights create a lot of fading in/out. My algorithm already filters out ambient lights (lights with no physical representation ingame) to some extent.

I have also tried another method without fading (shadows rotate instead of fade) but more than one shadow looks awful then.

[Budboy]

It is not the brightness, it is that my shadows will always be determined by the most priorized lights surrounding the player (up to 3). Whenever a new light is considered higher priorized then the former, the old shadow fades out and the new one fades in.
Therefore, a lot of lights create a lot of fading in/out. My algorithm already filters out ambient lights (lights with no physical representation ingame) to some extent.

I have also tried another method without fading (shadows rotate instead of fade) but more than one shadow looks awful then.

I see, so that's why you were referring to the number of lights present, I thought it was because of the light brightness

the only workaround I can think is that since you can already detect the lights around the player, maybe you can set the brightness of the other lights not prioritized to zero. I dunno =/

[Mutant117]

I think I will just leave it as is.
So far, the shadows only appear if the user has 'Full Shadows' enabled and I think that the lowest settings applied to the realtime shadows should be manageable by everyone having 'Full Shadows' enabled.
But there is still the question whether to disable the shadows by default so that clients connecting to a server running realtime shadows won't have them activated until they install the mod themselves and activate the shadows (to avoid any potential FPS drop resulting from my shadows). I think the latter is the best choice for both server admins and clients.

[Budboy]

yeh, seems like the best idea, cause setting it on by default might **** off people due to sudden lag in fps lol