Home Artists Posts Import Register

Downloads

Content

This version has the improved raytracing that's able to cast shadows from BSP entities to the world.

Moving BSP entities can cast shadows upon one another, but only if they don't rotate.

I've optimized the raytracing code for collision against BSP entities, but there are still numerous calls for AngleVectors that could be optimized in some way.

Despite that, there seems to be no noticeable difference in performance with r_light_tracing enabled or disabled. I'm getting nearly identical framerate values when benchmarking through the timedemo command. Maybe the reason is that the non-raytraced dynamic lights forces more surfaces (the backfaced ones) to be redrawn.

The support for dynamic lights on BSP maps/models still has bugs to be fixed, quality issues to be improved, and optimizations to be done, but gameplay wise it seems to be good enough now.

The only gameplay-related feature I'd like to add is cone-shaped dynamic lights (similar to the spotlights in the light compiler), which would make it possible to create flashlights that looks more natural. I'll look into it and see if it's easy to do.

As for the quality issues, it pleased me that most complaints I got about the raytraced dynamic lights were centered on the jagged edges and the somewhat abrupt movement. I have ideas on how to fix both issues, although it's not much of a priority right now, and both of them can be fixed without resorting to higher-res lightmaps.

To smooth out the abrupt movement, first I need to implement an optimization to limit the frequency of dynamically lit surface cache redraws. Retroquad still redraws every dynamically lit surface on every frame, which is overkill. Upon limiting the framerate of surface cache redraws (something between 10 to 20 fps should be enough), I can implement dithered interpolation of lightmap frames (something which I had already implemented ages ago, but removed it afterwards because it didn't benefit animated lightstyles), and then the interpolation will smooth out the movement of the shadows.

To smooth out the jagged edges of the shadows, I'm planning to implement a filter similar to some pixel art filters used by console emulators. The impact on performance should hopefully be unnoticeable, and may be negligible if the framerate limitation mentioned above is implemented first. Anyway, it should definitely be faster than increasing the amount of rays that needs to be traced.

There still are another two quality issues: Some surface edges can't be reached by the raytraced dynamic lights, and the lightmaps needs to be smoothed out accross different surfaces. Both are quite complicated to solve. A good example of smoothing out accross different surfaces is the phong shading feature in EricW's tools, and indeed it looks bad when a raytraced dynamic light has hard edges when cast onto a phong-shaded brush.

Anyway, all things considered, the current state of the raytraced dynamic lights seems good enough. Its shortcomings aren't really noticeable during normal gameplay in Quake.

I've included in this post the test map, and the latest progs.dat. I'm not sure if this progs.dat is needed; the latest one before this one may be enough, but here's it anyway.

Files

Raytraced light sampling, almost done.

Running in the Retroquad game engine, wip version 0.21.1: https://www.patreon.com/mankrip Hardware: CPU AMD Ryzen 5 PRO 3350G 3.6Ghz 4MB Cache AM4 Motherboard Biostar A320MH DDR4 RAM 16GB 2666MHz DDR4 SSD 256GB Sata 6GB/s Notes: Most bugs were fixed. Shadowing from moving & rotating BSP entities to the world (and vice versa) is working perfectly. Self-shadowing in moving & rotating BSP entities is also working perfectly now. Shadowing between multiple moving BSP entities (without rotation) also seems to be working perfectly now. The only buggy case is the shadowing between rotating BSP entities; due to this, it's disabled by default and only enabled when the cvar is negative. There's also an issue with some concave corners never receiving dynamic lighting, but it's more a case of a lack of accuracy than a straightforward bug; it also needs to be fixed, though. There's a lot to optimize in this raytracing code, but I need to finish fixing those two problems first.

Comments

No comments found for this post.