License:
Creative Commons Attribution Share-Alike

Audio Version

by Blender Dumbass

Aka: J.Y. Amihud. A Jewish by blood, multifaceted artist with experience in film-making, visual effects, programming, game development, music and more. A philosopher at heart. An activist for freedom and privacy. Anti-Paternalist. A user of Libre Software. Speaking at least 3 human languages. The writer and director of the 2023 film "Moria's Race" and the lead developer of it's game sequel "Dani's Race".

Yesterday on Dani's Race Development Stream I went on an ADHD tangent away from fixing spaghetti and into trying to make the city look good at night.

The problem is that the city has tons of lights all around the place, and placing all of them will simply fry the GPU. I can do that in the film version, but in a game everything should render fast enough to be responsive. And more than that, UPBGE has an optimization problem, so I have to be clever about how and if to do it.




Until yesterday I thought that street lights was impossible to make, so I was trying to find some kind of other ways to brighten up the frame at night, so at least it would be visible, but yesterday I stumbled upon something that might work.

Please go look at the petition for the previous version of the game. As soon as it is released I can start releasing newer updates, which includes a lot of stuff, since the last time the game was packaged was in September. It is up to you to make the game released. So please release it.

Why Petitions?

The problem(s)

UPBGE rendering with the Blender's EEVEE renderer can look phenomenally pretty, but it is not particularly the most optimized engine / renderer out there. Since EEVEE was built not for games, but rather for previewing scenes in a more responsive way before rendering them, it can be rather tricky to make it work on something other than the beastiest computers out there.

More than that, EEVEE has a limit on the amount of lights that you can put in the scene, which I'm sure should not a be a great hustle to turn off, but is probably a good thing to keep actually.

I have a computer that is beyond average in specs, based on the target demographic, of those people who might be interested in something like Dani's Race right now. Most GNU / Linux users have extremely under-powered machines that barely run. So I need to not only think about some ways to implement the game that will work on my machine. But also some ways that will make it at least somewhat playable on older computers.

The game has 619 light poles at the moment. If I would put so many lights all around the scene, the computer will explode!

Solution 1, Fake it

I already made an adaptation of this same city into a different game called SuperTuxKart, where the user-base is even more limited with their hardware and where the engine is not as capable. Yet, as you can see, the lights are present and the road is lit.




This was done with 2 tricks.

For the shadows and general visibility of the karts I used the normal in-game sun which is one light lighting the entire scene. But when in the same time the background is dark, it already kind of resembles night in a weird way. And so your mind subconsciously solves the issue making it seem like the sun-light is some artificial light from some kind of a street lamp.

Then for the terrain model I baked a texture containing all of the lights and shadows that would result from all those lights. Making it look like it is lit, but it is only a texture.

This approach could work for Dani's Race too, if only I didn't want day scenes as well. But since I want it to have a dynamic day-night cycle, this approach would not work.

I actually tried adding some baked light to the terrain, which I would slowly fade in an out of existence based on the in-game time, so there will not be any of it during the day. But it made the ground material so demanding that some people had a significant drop in FPS just pointing the camera at it.




Early on, when I just made the fist steps into rendering the night in the game, I tried putting a bazillion lights, quickly understanding that my computer would not survive it long. And then I simply gave up. Making the night sky be a bit brighter than usual, when lighting objects, so at least something would be visible. Though as you can see on that screenshot I've added a kind of neon glow to the cars as well, making it look a bit more salvageable.




This screenshot of the sky material is not particularly useful to understand the trick. So here is a simple version of it.




As you can see you can pipe different texture information to the rendered bases on whether it is lighting the surfaces of objects, or it is being directly shown in the camera. Making the stuff directly to the camera dark, like the night sky, while making it way brighter for the objects, gives some visibility, while still making you feel like it is night.

And then adding colored, shadow-less lamps into cars, for the neon glow, makes it look like a start of something good. But it is not yet there.

Solution 2, swap lights.

Compare it to the stuff I made yesterday on the steam.




Here I am using 2 huge area lamps to simulate the light on the street. And basically as soon as you pass under one of them and it is no longer needed, the game moves that light to the front. The best way to understand it is to actually see the effect in action in the game itself.







As you can see it is a pretty seamless effect. Even though I am using only 2 lamps. And here is how I did it:

def NightLightsEffect(car):

    # Night Lights spawning around
    # the main characters when driving
    # at night.

    scene = bge.logic.getCurrentScene()
    dani = scene.objects["Dani_Box"]
    cam = scene.active_camera

    timeIs = bge.logic.globalDict["time"]

    # If it is day, do nothing
    onTheRoad = Vehicle.NearRoad(car) < 50
    if ( 7 < timeIs < 18 ) or not onTheRoad:
        return

    # Initilize 2 street lights
    if "car-nigh-lights" not in bge.logic.globalDict:
        bge.logic.globalDict["car-nigh-lights"] = []

    lights = bge.logic.globalDict["car-nigh-lights"]

    while len(lights) < 2:

        light = Reuse.Create("Area_Lamp")
        light.scaling = [10,10,10]
        light.blenderObject.data.energy = 1000
        light.blenderObject.data.shape = "DISK"

        lights.append(light)

        light.position = Vehicle.RelativePoint(car, (0,-50*(len(lights)),10))

    # Moving the lights in front

    # Sort based on the point

    spawnPoint = Vehicle.RelativePoint(car, (0,-100,10))
    lights = sorted(lights, key=lambda x: x.getDistanceTo(spawnPoint))

    if lights[0].getDistanceTo(spawnPoint) > 50:
        for light in lights:
            tp = light.position.copy()
            tp.z -= 10
            if cam.pointInsideFrustum(tp) == cam.OUTSIDE \
            and light.getDistanceTo(car) > 20:
                light.position = spawnPoint
                light.position.z += 50
                topos = light.position.copy()
                topos.z -= 200
                ray = light.rayCast(topos)
                if ray[1]:
                    light.position = ray[1]
                    light.position.z += 10
                break

As you can see the current implementation basically puts the new lights about a 100 meters in front of the car, 10 meters above the road, if the car is close to the road ( so that this effect will not work on stretches of dirt in between roads, where everything should be dark ).

This is a bit basic and kind of stupid. It results in a lot of lights spawning in weird places. But for the proof of concept it is beyond amazing. Even with all those problems it already looks and feels fantastic.

Another problem is the huge reflection that the area lamp makes on the road itself. I like what it does to the car, but not what it does to the road. I'll have to mess around with light setting to make it look more properly proper. But again, this is beyond what I would expect.

I literally thought I was trying something that I wouldn't like and would completely discard immediately. But then it seems I did something I actually do like and want to develop further. So I guess you should mess around with your code ones in a while and go on ADHD tangents, because they might bring something good.

Happy Hacking!!!


Next Previous JSON Markdown

  翠星石 c:0


Most of such users have an incredibly powerful machines, clocked at billions of Hz, with billions of bytes of RAM, it's just that software expands to use all resources.

Supertuxkart is extremely resource intensive, but is at least playable on GNUbooted thinkpads at low settings.

On extremely fast cards like the 780 Ti, supertuxkart does run quite well (nouveau reclocking is still quite limited, but the developers has gone and fixed most pipeline stalls for that game).

The same is true for Xonotic, but sadly not minetest or xmoto.

... replies ( 1 )

  Blender Dumbass c:1



@翠星石 Sadly the general public ( if we want to convince them ) expects billions of polygons and raytracing. They expect video games to compete graphically with Avatar movies.

Reply

  Blender Dumbass c:1

... c:0

  翠星石 c:0

Most GNU/Linux users have extremely under-powered machines that barely run.

Most of such users have an incredibly powerful machines, clocked at billions of Hz, with billions of bytes of RAM, it's just that software expands to use all resources.

into a different game called SuperTuxKart, where the user-base is even more limited with their hardware

Supertuxkart is extremely resource intensive, but is at least playable on GNUbooted thinkpads at low settings.

On extremely fast cards like the 780 Ti, supertuxkart does run quite well (nouveau reclocking is still quite limited, but the developers has gone and fixed most pipeline stalls for that game).

The same is true for Xonotic, but sadly not minetest or xmoto.

@翠星石 Sadly the general public ( if we want to convince them ) expects billions of polygons and raytracing. They expect video games to compete graphically with Avatar movies.

Reply

Help

You can comment from Mastodon.

Go

Post