search

KaminariOS / rustracer

Vulkan path tracing with Rust
BSD 3-Clause "New" or "Revised" License
69 stars 2 forks source link

Light bleed between surfaces etc #9

Open dsvensson opened 1 year ago

dsvensson commented 1 year ago

I've adapted your renderer to render Quake 1 BSP maps to preview what light settings look like during mapping compared to waiting for minutes for the lightmap generator to run (software raytracing via embree). Still a work in progress, I know this is a small one man show, but I have some naive questions.

  1. I'm drawing faces from the geometry found in the BSP map and with sunlight enabled I get light bleed at the edges between all surfaces where the other side is "the outside".

  2. I'm having problem positioning point lights, they all seem to end up at the same position. My shader-fu is kind of weak so I haven't found the reason for this. Either I'm not positioning the nodes correctly, or some link between light and node is not setup correctly, or positioning of point lights is not implemented? So just a sanity-check question if positioning of multiple point lights is supposed to work.

  3. Would be very nice if GLTF could be more separated from the geobuilder and related types, and all relevant fields be made public. Currently you pass in the gltf document to the asset_loader module. Think it would be nice if you split asset_loader into asset_loader_gltf or so, to be more generic. Hope to clean up my repo to show what changes I had to do to adapt this to Q1 BSP.

  4. Don't suppose you've experimented with adding OptiX or any other GPU based denoiser?

dsvensson commented 1 year ago

Example of what I think is light bleed.

image image image

KaminariOS commented 1 year ago

1: Could you send me the glTF model so that I can debug? I guess there may be something wrong with the normal of the wall? 2: The code for processing point lights in the scene graph is quite simple, but I don't have a good model to test it. I believe I fix it in the latest commit:b0512b275c2384b02d0059f1a6ed3bbf82353c9c 3: Yes, I wanted to support different 3D formats so I named it asset loader. However, later I realized a workaround is to compose and convert any other 3D format to glTF with Blender. (Compared with supporting different formats, a more important feature is to load and unload multiple glTF scenes together. Kajiya renderer implemented this).

  1. I have a plan to implement a SVGF denoiser myself, but currently I don't have time to do it.
dsvensson commented 1 year ago

The light positions might be correct now. The model is lit mostly correct wrt positions, might be errors of mine what's left. Getting light outside the model when all lights are on and sun is off, and i can't think of any reason for that other than some light being on the wrong side of some face, but the result is otherwise fairly similar to what the lightmap compiler would produce.

Will try to clean up the code base this weekend so I can show the light bleeding. It feels a bit like a precision issue somewhere. Quake 1 engines are sensitive to precision for other reasons so good maps always have integer aligned vertices, so vertex positions should at least not contribute to precision issues.

ChatGPT is suggesting shadow bias and complemented the commented out code for ray offset (that didn't help uncommenting out).

As mentioned I do not load gltf, but BSP files directly. The idea is to adjust colors and positions of lights in the Quake 1 editor (Trenchbroom) and my copilot app would show the result in real time on save, so in my case I don't want to first produce a gltf.

Your code base is very close to allowing that as is, just need to make some more stuff public, will do those changes in a separate commit to demonstrate.

I also have Wayland and Windows support in my branch. The Windows support is straight forward, was just some outdated apis, but not sure about how to deal with both x11 and Wayland on Linux, currently just commented out x11 to get it working (dualbooting).

KaminariOS commented 1 year ago

As mentioned I do not load gltf, but BSP files directly.

I know little about BSP files, so I am unable to help.

Wayland and Windows support

I don't use Wayland or Windows, so it is very inconvenient for me to debug and test on those platforms. Maybe you can open a pull request?

The lateset winit version(0.28) has better support for Wayland but I have to use an older version that is compatible with imgui-rs. My plan is to switch to egui someday(https://github.com/KaminariOS/rustracer/issues/5) and then bump the winit version.

I am still learning cargo build scripts and packaging.

dsvensson commented 1 year ago

Yep, the changes to make the example build and run on Windows is straight forward. Will open PR for that. As for Wayland, it works great and is also a very small change, it's just that I'm not sure how to select X11 or Wayland depending on what's available, but there must be some other project that has done that already I could draw inspiration from.

No need to worry about BSP files. That part of the code should be solid. Repurposed a loader from the Richter Quake engine and using your geometry builder helpers, so everything is created just like when GLTF is loaded, just different source for the data.

dsvensson commented 1 year ago

I ported my app to RTXDI and had the same issue there with light bleed when I first scaled my model to 0.1. to fix it i changed the camera speed to not crawl around the map and adjusted scale to 1.0. I did this in your raytracer as well but still light bleed. As it looked identical I would guess it's precision related.

KaminariOS commented 1 year ago

Thank you for the report. I shall make a thin-wall model to debug this problem. Will do it later.