#Iris - A Journey through OpenGL and beyond to learn Graphics

1 messages · Page 8 of 1

wicked notch
#

So

#

uh

#

diffuse lighting means random direction right?

#

Should this random direction be within the "hemisphere" of the triangle's normal

#

I don't understand

#

This is cornell box

#

The one we all love

#

this is path traced with the emissive light on top

#

where the hell are these colors coming from

#

With 16 samples per pixel it's somewhat recognizable

#

There are still some bogus colors near the light source though

wicked notch
#

I kinda like how low spp counts yield completely bogus colors bleakekw

#

I'll try temporal accumulation

wicked notch
#

Aight it werks

#

it's only unbearably slow, but it werks bleakekw

summer gyro
#

Nanite2 with raytracing next 😈

wicked notch
#

That is unironically the plan

summer gyro
#

LESSGOO

wicked notch
#

But it's intel only and I don't have an intel GPU

summer gyro
#

I donno anyone who has it tbh
(We are not talking about the integrated one right ?)

wicked notch
#

Ye

#

I have a laptop with an Intel iGPU but it can't run this

summer gyro
#

Extension holdin ya back ?

wicked notch
#

No, it shrimply can't

#

it's too shit bleakekw

#

i.e crashes on startup

#

It's not even old, it's a 12700H

#

I still have the issue of the image "converging" after a while or so

#

Even though it's very clearly still noisy

raven orchid
#

What’s the sample count and history depth at?

wicked notch
#

4spp

#

history depth is surely less than 100

#

The peter panning is also super weird

frank sail
#

what is the ray offset after a bounce?

wicked notch
#
const auto normal = glm::normalize(
    n0 * bary.x +
    n1 * bary.y +
    n2 * bary.z);
const auto point =
    glm::vec3(ray.org[0], ray.org[1], ray.org[2]) +
    glm::vec3(ray.dir[0], ray.dir[1], ray.dir[2]) *
    ray.tmax;
ray = bvh_ray(as_vec3(point), as_vec3(random_direction_in_hemisphere(normal)), 0.1f);```
#

all in world space btw

frank sail
#

hmm so you aren't offsetting the ray when you bounce?

wicked notch
#

How should I offset it?

frank sail
#

offset by the normal scaled by a tiny amount

#

that should help prevent self intersection

#

your image should get brighter as a result, but it won't change peter panning

#

which tbh I thought was caused by too much offset

wicked notch
#

I think there is something fundamentally wrong here

#

With this

ray = bvh_ray(as_vec3(point + direction * 0.5f), as_vec3(direction), 0.1f);```
#

I no longer have peter panning and the image is darker

#

somehow the exact opposite of what you said jaker

frank sail
#

Lmao

wicked notch
#

I am currently very tempted of moving everything to the GPU

frank sail
#

.5 is a huge offset though

wicked notch
#

just so I don't have to wait 30 seconds for a single frame

#

should I try with .01

#

or .1

frank sail
#

and direction is the wrong value to offset by since you will escape the surface more slowly than if you use the surface normal

frank sail
#

try different things

wicked notch
#

I will

frank sail
#

the point is to avoid self intersection caused by floating point error

wicked notch
#

unfortunately it takes a solid minute to get 3 frames KEKW

#

hmm

wicked notch
# wicked notch

I also notice a super weird "band" in the middle of the box

#

as if pixels clump up there more for some reason

#

Alright this is it

#

we're going fully GPU

#

I am a very impatient man

frank sail
#

lmao

#

also I'm not sure why the offset is being weird

#

maybe you gotta negate it for some reason frog_thinkk

wicked notch
#

I tried that as well

#

The image was even darker KEKW

frank sail
#

cursed lmao

wicked notch
#

Anyways, for faster iteration times, I'll be going GPU

#
template <typename Node>
template <bool IsAnyHit, bool IsRobust, typename Stack, typename LeafFn, typename InnerFn>
void Bvh<Node>::intersect(Ray<Scalar, Node::dimension>& ray, Index start, Stack& stack, LeafFn&& leaf_fn, InnerFn&& inner_fn) const {
    auto inv_dir = ray.get_inv_dir();
    auto inv_org = -inv_dir * ray.org;
    auto inv_dir_pad = Ray<Scalar, Node::dimension>::pad_inv_dir(inv_dir);
    auto octant = ray.get_octant();

    auto intersect_node = [&] (const Node& node) {
        return IsRobust
            ? node.intersect_robust(ray, inv_dir, inv_dir_pad, octant)
            : node.intersect_fast(ray, inv_dir, inv_org, octant);
    };

    stack.push(start);
restart:
    while (!stack.is_empty()) {
        auto top = stack.pop();
        while (top.prim_count == 0) {
            auto& left  = nodes[top.first_id];
            auto& right = nodes[top.first_id + 1];

            inner_fn(left, right);

            auto intr_left  = intersect_node(left);
            auto intr_right = intersect_node(right);

            bool hit_left  = intr_left.first <= intr_left.second;
            bool hit_right = intr_right.first <= intr_right.second;

            if (hit_left) {
                auto near = left.index;
                if (hit_right) {
                    auto far = right.index;
                    if (!IsAnyHit && intr_left.first > intr_right.first)
                        std::swap(near, far);
                    stack.push(far);
                }
                top = near;
            } else if (hit_right)
                top = right.index;
            else [[unlikely]]
                goto restart;
        }

        [[maybe_unused]] auto was_hit = leaf_fn(top.first_id, top.first_id + top.prim_count);
        if constexpr (IsAnyHit) {
            if (was_hit) return;
        }
    }
}```
#

This is

#

the beast

#

That I must implement

#

somehow KEKW

frank sail
#

goto frog_sweat

wicked notch
#

I won't do that

#

I will shrimply return

raven orchid
#

For this one, what are the args?

ray = bvh_ray(as_vec3(point + direction * 0.5f), as_vec3(direction), 0.1f);
#

is it new position, direction, idk last one lol

wicked notch
#

tmin

raven orchid
#

except

#

mult by tmax seems weird

wicked notch
#

if the ray intersects a triangle

#

tmax is the distance the ray had to travel to intersect it

raven orchid
#

oh ok

wicked notch
#
template <typename T>
std::optional<std::pair<T, T>> PrecomputedTri<T>::intersect(Ray<T, 3>& ray, T tolerance) const {
    auto c = p0 - ray.org;
    auto r = cross(ray.dir, c);
    auto inv_det = static_cast<T>(1.) / dot(n, ray.dir);

    auto u = dot(r, e2) * inv_det;
    auto v = dot(r, e1) * inv_det;
    auto w = static_cast<T>(1.) - u - v;

    // These comparisons are designed to return false
    // when one of t, u, or v is a NaN
    if (u >= tolerance && v >= tolerance && w >= tolerance) {
        auto t = dot(n, c) * inv_det;
        if (t >= ray.tmin && t <= ray.tmax) {
            ray.tmax = t;
            return std::make_optional(std::pair<T, T> { u, v });
        }
    }

    return std::nullopt;
}```
raven orchid
#

I was thinking you had tmin, tmax as bounds and t was the hit point

wicked notch
#

You can see it here

#

yeah, this lib does ray.tmax = t

raven orchid
#

ah ok

frank sail
#

Tmin of .1 is really high

#

I guess they also use that to prevent self intersection, but it's not as good as the normal offset method

wicked notch
#

yeah I'm using both

#

actually using tmin = 0.001 fixed peter panning

#

I don't know why I didn't think of that

#

it actually looks like a proper cornell box now

#

With both offset and small tmin

#

This is with 64spp though

#

Otherwise the image is still dark

frank sail
#

you can probably eliminate tmin entirely if you have the normal offset

wicked notch
#

The stupid band of clumped pixels is still here though

frank sail
#

hmm

#

what rng are you using

wicked notch
#

uhh

#

yeah probably a bad idea to use C++'s mersenne twister isn't it? bleakekw

#

For the random directions I'm using a normal distribution btw

frank sail
#

it's battle tested at least

wicked notch
#

I'll plug in PCG

frank sail
#

so that's probably not failing here

wicked notch
#

see if it's any different

raven orchid
#

wonder why it's only on two of the walls but not the third wall or the box

wicked notch
#

PCG actually fixed everything

#

amazing

frank sail
#

weird but ok froge

#

maybe mersenne twister has some bias

wicked notch
#

perhaps

#

I still need a ridiculous amount of samples per pixel to make the image non dark

frank sail
#

I think it's normal to appear dark until you denoise it or take a lot of samples

wicked notch
#

This is with 4spp for eg

frank sail
#

we register the darkness more than the pixels that are 100x bright as they should be

#

hmm

#

it has surprisingly little noise for being 4spp

#

or is this with your temporal filter

wicked notch
#

My "temporal filter" stops working after a while

#

I currently do this:

void main() {
    const vec3 old = texture(color[0], uv).rgb;
    const vec3 new = texture(color[1], uv).rgb;

    const float weight = 1.0 / float(frame + 1);
    o_pixel = vec4(mix(old, new, weight), 1.0);
}```
#

It's still this thing

#

it "converges" after 100 frames or so

frank sail
#

what format is your texture

wicked notch
#

RGBA8

frank sail
#

well that's gonna converge terribly

wicked notch
#

Do I have to make the texture itself RGBA32F?

frank sail
#

use RGBA32F and then tonemap to RGBA8 for display

wicked notch
#

I am doing tonemapping on the CPU KEKW

#

Also

frank sail
#

well that's fine as long as you don't accumulate with low precision values

wicked notch
#

My tonemap is this color /= color + 1.0f;

#

amazing

frank sail
#

it works

#

and is better than aces or whatever dumb """filmic""" "tone"mapper for the purpose of actually seeing what color is produced

#

but yeah my main recommendation is to accumulate RGBA32F values

#

second recommendation is to accumulate before tonemap (so tonemap can still output to RGBA8 buffer)

wicked notch
#

I will accumulate before tonemap and srgb

#

and then do another fullscreen tri to display

frank sail
#

btw are you doing any sort of gamma compression/encoding/OETF thingy

wicked notch
#

just srgb conversion after tonemap

frank sail
#

ok good

#

then your thingy will be Perfect and require no further changes after you do the accumulation thing

wicked notch
#

shockingly good

#

4 samples per pixel

#

I'll just use RGBA32 attachments for anything (color related) now bleakekw

#

The temporal accumulation still stops after a while

frank sail
#

yeah that's normal

#

you could also try switching to exponential accumulation instead of linear after a certain number of frames so the contribution of new frames doesn't approach 0

#

e.g. after 100 frames switch to constant .01 factor instead of using 1/frames (btw I do not know if this will make it look better)

wicked notch
#

is there anything more clamplicated

frank sail
#

no

wicked notch
#

rip

#

how do I make it more pretty then

#

without making samples go up

frank sail
#

denoising

#

and taking better samples (ones that are more likely to contribute light)

wicked notch
#

both of which are stupidly clamplicated I assume

frank sail
#

somewhat

#

I haven't made a decent path tracer so idk the mechanics of sampling algorithms

#

But I can comprehend denoisers since I made one

#

And the best ones today consist of two key parts: temporal reuse and spatial reuse (AKA a blur)

wicked notch
#

How does temporal reuse work

frank sail
#

It's what you're doing

wicked notch
#

amazing

#

So I just gotta blur the shit out of my image then?

frank sail
#

Yeah lol

#

Well

wicked notch
#

beautiful

frank sail
#

Just the noisy parts

wicked notch
#

That's the clamplicated part

#

hm

frank sail
#

What I mean is that you want to blur irradiance

#

Because some aspects of the scene have no noise, like the surface material

#

And you don't want to blur the albedo, for example

wicked notch
#

hm

#

How do I blur just the light rays thonk

frank sail
#

Here's what you do

#

You trace normally, but don't apply the cosine or albedo factors of the first bounce until after you denoise

#

So you're looking at the "incoming light" of the surface the eye sees, essentially

#

I can show a pic of how it should look prior to denoising in a sec

wicked notch
#

raytracing in summer be like

#

Anyways

#

I have sponza

#

The most basic of path tracers can do this KEKW

raven orchid
#

Simplest would probably be:

  1. nearest neighbor average of irradiance
  2. add albedo to step 1
  3. temporally accumulate
#

Then steps 1 and 3 are the subject of lots of research papers lol

finite yacht
wicked notch
#

1280x720

#

fps are 0 KEKW

#

it's one frame every 30 seconds or so

#

The intersection itself isn't bad

finite yacht
#

at 1spp?

wicked notch
#

It's the looping over all pixels, for all samples, for all bounces

#

64 spp

#

16 bounces

finite yacht
wicked notch
#

at 1spp I can totally move around

#

incredible honestly lol

#

maybe 2 or 3 fps

finite yacht
#

yeah thats actually really good

raven orchid
#

What’s the frame rate if you do

#

1spp and max 3 bounce?

wicked notch
#

framerate is constant when moving around

#

1spp and 4 bounces

raven orchid
#

1 spp 4 bounce = 3 fps?

wicked notch
#

yes

#

720p

#

I was wondering though

#

can this be classified as "irradiance"

#

after all it's just how much light a given pixel has

#

could I use this as an "irradiance mask", blur it and then apply albedo and all the other stuff

frank sail
#

Possibly

raven orchid
#

Yeah you could and it would preserve texture details but your final result would be very binary

frank sail
#

It should contain some color from bounce light though

wicked notch
#

base color?

frank sail
#

E.g. the floor next to the curtains should be colored

#

Not base color

#

Color from bounces (incoming light/irradiance)

wicked notch
#

ah the color of the light?

#

or am I stupid

#

No I'm definitely stupid

wicked notch
#

Do you mean the color of the light?

frank sail
#

ok I thought you meant base color as in the material

wicked notch
#

yes I meant that

frank sail
#

the surface you are looking at should basically not be factored in the color which is being denoised

wicked notch
#

the base color factor in a gltf material

frank sail
#

well you don't want that

#

lemme show you a pic of fwog in renderdoc

wicked notch
#

damn I'm not following at all bleakekw

wicked notch
frank sail
#

building it

wicked notch
#

I am sipping coffee while I await and look at my beautiful sponza

frank sail
#

uh 2am coffee?

wicked notch
#

honestly path tracing is epicKEKW

wicked notch
#

I can't recall the last time I've had 8 hrs of sleep bleakekw

frank sail
#

I just remembered that fwog has a button to skip albedo modulation

wicked notch
#

ight so what am I looking at

frank sail
#

so that's how it looks if I don't multiply the light value by the albedo of the first-bounce surface

#

that's essentially the color that gets denoised

#

actually here's how it looks before any filtering

wicked notch
#

ye but I still need to sample the texture and tint the ray color right?

#

Otherwise where do I get the red from

frank sail
#

but you only do that after you denoise

wicked notch
#

So how do I get the red before denoising?

frank sail
#

the red comes from secondary bounces, which are allowed to sample albedo and shiz

wicked notch
#

ah

#

so only secondary bounces can shrimple albedo

frank sail
#

it's just the primary bounce that contains high-frequency surface info that needs to be preserved

wicked notch
#

just to clarify

#

the "primary bounce" is the one from the camera to the surface or from the one after that

frank sail
#

the former (the very first surface the ray from the camera hits)

wicked notch
#

ok good

frank sail
#

btw I have an example of what it looks like if you don't demodulate albedo in your denoiser

wicked notch
#

let's see

frank sail
#

actually I'm not even denoising, so it would look worse than that

#

here is with proper albedo demodulation (plus denoising)

wicked notch
#

I see, got it

#

does "demodulation" mean the thing we discussed just earlier

frank sail
#

basically your textured become smudged ass if you don't demodulate

#

ye

wicked notch
#

i.e the thing where secondary bouces sample albedo and all that

frank sail
#

also you're apparently not supposed to apply the cosine term until after denoising

#

the surface2eye cosine term I mean

wicked notch
#

I have no idea what the cosine term is bleakekw

#

ah alright

frank sail
#

uh the one where you weight the contribution by the cosine of the angle

#

something something projected area

wicked notch
#

yes got it

#

amazing so denoising is another truck full of worms

#

beautiful

#

Well that'll come after I force the GPU to trace my bvh

frank sail
#

btw here is another explanation of this demodulation thingy (just like 15 seconds)
https://youtu.be/2GYXuM10riw?t=265

This talk will present an efficient and high-quality Final Gather for fully dynamic Global Illumination with ray tracing, targeted at next generation consoles and shipping in Unreal Engine 5. Part of the SIGGRAPH 2021 Advances in Real-Time Rendering in Games course ( http://advances.realtimerendering.com/).

Hardware Ray Tracing provides a new ...

▶ Play video
#

well ignore his words and just look at the slides KEKW

raven orchid
#

That’s such a cool presentation

#

My take away is that lumen is basically a real time miracle

frank sail
#

the point is that geometry normals are incoherent (they have no spatial coherence), but the light is basically a smooth gradient. That means applying the normals (via the cosine term) will make your luminance incoherent and thus harder to denoise

wicked notch
#

the only miracle here is that I am still awake

frank sail
#

my explanation sucks, but hopefully it gives a geometric intuition

wicked notch
#

my monke brain needs to impl GPU trasversal

frank sail
wicked notch
#

Alright I don't think I can continue bleakekw

#

I can feel parts of my brain shutting off

#

It is time to schlepp

frank sail
#

gn

minor root
#

lvstri speedrunning graphics algorithms 100% completion

wicked notch
#

This speedrun has been months long though bleakekw

#

And nowhere near completion

minor root
#

you are fast af though

frank sail
#

apparently that's what happens when you ignore sleep and ingest caffeine

twin bough
#

Where can I get this superpower

wicked notch
#

I use super special coffee beans imbued with various uh, substances

#

||my lawyer requires me to specify that this is a joke||

twin bough
#

man seeing ur progress makes me wish im not working on an old ass engine

#

i actually dont drink coffee

#

maybe thats whats missing

wicked notch
#

My progress is being hindered by how cool this sponza looks btw

#

I can't stop looking at it from different angles bleakekw

#

I know this has been done countless times but it's epic seeing it myself

twin bough
#

noice

#

something about lighting only renders makes me happy

wispy spear
#

rendered like that it do be looking more interesting than the usual sponzaism

wicked notch
#

I 🅱️ushed the thing btw

#

I wonder if this is how cornell box should look with albedo demodulation

#

I'm only tinting the ray color after the first bounce

wispy spear
#

what is this thing

#

[build] ModuleNotFoundError: No module named 'jinja2'

#

ah

#

glad2

wicked notch
#

the same error as ever KEKW

wispy spear
#

arch cant seem to find python-jinja2 ;p

wicked notch
#

I think you can just install it through pip

wispy spear
#

thats the thing

#

pip wants you to install it via python-packagename using the package manager of the distro

wicked notch
#

smh python

wispy spear
#

maybe i should setup a build container in the future, all this deps bs is starting to annoy me

#
deccer@rootfs Raytracer]$ pip install jinja2
error: externally-managed-environment

× This environment is externally managed
╰─> To install Python packages system-wide, try 'pacman -S
    python-xyz', where xyz is the package you are trying to
    install.

    If you wish to install a non-Arch-packaged Python package,
    create a virtual environment using 'python -m venv path/to/venv'.
    Then use path/to/venv/bin/python and path/to/venv/bin/pip.

    If you wish to install a non-Arch packaged Python application,
    it may be easiest to use 'pipx install xyz', which will manage a
    virtual environment for you. Make sure you have python-pipx
    installed via pacman.

note: If you believe this is a mistake, please contact your Python installation or OS distribution provider. You can override this, at the risk of breaking your Python installation or OS, by passing --break-system-packages.
hint: See PEP 668 for the detailed specification.
#

: )

#
[deccer@rootfs Raytracer]$ sudo pacman -S python-jinja2
error: target not found: python-jinja2
#

heh

wicked notch
#

I guess you could use pipx?

wispy spear
#

tf is pipx now

#

ah

wicked notch
#

I dunno

wispy spear
#

pip3

wicked notch
#
it may be easiest to use 'pipx install xyz', which will manage a
virtual environment for you. Make sure you have python-pipx
nstalled via pacman.```
wispy spear
#

because python people are idiots

#

python2 != python3

#

and pip != pip3

#

same error

wicked notch
#

amazing

wispy spear
#

ill replace your glad cmakeism with the one from my cmake template

wicked notch
#

ye probably easiest

minor root
#

oh that shit

#

yeah python is a mess

wispy spear
#

hmm alot of std::ranges isms gcc 13 cant seem to handle either

wicked notch
#

weird

wispy spear
#

clang 15 has no trouble there

#

only doesnt like this one

wicked notch
#

I'll just remove the ranges

#

you can pull whenever

wispy spear
#
[build] /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/13.1.1/../../../../include/c++/13.1.1/bits/stl_iterator.h:2618:35: error: missing 'typename' prior to dependent type name 'iterator_traits<_It>::iterator_category'
[build]       { using iterator_category = iterator_traits<_It>::iterator_category; };
[build]                                   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
``` remains
#

no idea what to make of it

wicked notch
#

could you post the full error

#

with the myriad of "notes" the compiler spews out

wispy spear
#

gcc builds fine now

wicked notch
#

amazing

#

C++ compilers

#

™️

wispy spear
#
[build] [27/28  96% :: 2.066] Building CXX object CMakeFiles/BVH.dir/main.cpp.o
[build] FAILED: CMakeFiles/BVH.dir/main.cpp.o 
[build] /usr/bin/clang++ -DGLM_FORCE_AVX2 -DGLM_FORCE_DEPTH_ZERO_TO_ONE -DGLM_FORCE_RADIANS -DGLM_FORCE_RIGHT_HANDED -I/home/deccer/Personal/Code/External/Raytracer/deps/cgltf -I/home/deccer/Personal/Code/External/Raytracer/deps/bvh/src/bvh/v2/../.. -I/home/deccer/Personal/Code/External/Raytracer/deps/glm -I/home/deccer/Personal/Code/External/Raytracer/deps/glfw/include -I/home/deccer/Personal/Code/External/Raytracer/build/_deps/glad-build/include -g -std=gnu++2b -loop-vectorize -march=native -mmmx -msse -msse2 -msse3 -mssse3 -msse4 -msse4a -msse4.1 -msse4.2 -mavx -mavx2 -msha -maes -MD -MT CMakeFiles/BVH.dir/main.cpp.o -MF CMakeFiles/BVH.dir/main.cpp.o.d -o CMakeFiles/BVH.dir/main.cpp.o -c /home/deccer/Personal/Code/External/Raytracer/main.cpp
[build] clang-15: warning: -loop-vectorize: 'linker' input unused [-Wunused-command-line-argument]
[build] In file included from /home/deccer/Personal/Code/External/Raytracer/main.cpp:1:
[build] In file included from /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/13.1.1/../../../../include/c++/13.1.1/filesystem:48:
[build] In file included from /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/13.1.1/../../../../include/c++/13.1.1/bits/fs_fwd.h:35:
[build] In file included from /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/13.1.1/../../../../include/c++/13.1.1/system_error:43:
[build] In file included from /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/13.1.1/../../../../include/c++/13.1.1/stdexcept:39:
[build] In file included from /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/13.1.1/../../../../include/c++/13.1.1/string:48:
[build] /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/13.1.1/../../../../include/c++/13.1.1/bits/stl_iterator.h:2618:35: error: missing 'typename' prior to dependent type name 'iterator_traits<_It>::iterator_category'
[build]       { using iterator_category = iterator_traits<_It>::iterator_category; };
[build]                                   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[build] 1 error generated.
wicked notch
#

??

wispy spear
#

exactly

#

weird that it takes headers from gcc

#

i thought clang is its o wn shit

wicked notch
#

Linux uses libstdc++ as the default stdlib

#

if you want to use clang's you need to explicitly specify that

#

-libc++ or something

wispy spear
#

i thought cmake will take care of that when schwitching compilers/kits

#

the gcc variant builds, but doesnt run

wicked notch
#

runtime error?

wispy spear
#
The program '/home/deccer/Personal/Code/External/Raytracer/build/BVH' has exited with code 377 (0x00000179).
#

oh

wicked notch
#

it's probably the target_compile_options or shader/model paths

wispy spear
#

i did update my s ystem earlier today, and that completely fucked with my gfx drivers

#

let me reboot

#

yup

#

now it runs

wicked notch
#

Does your cpu want to die right now

wispy spear
#

not really

#

but all cores are active 🙂

wicked notch
#

ladies and gents

#
#version 460
#extension GL_ARB_separate_shader_objects : enable
#extension GL_EXT_scalar_block_layout : enable
#extension GL_EXT_buffer_reference : enable

layout (location = 0) in vec2 i_uv;

layout (location = 0) out vec4 o_pixel;

layout (scalar, buffer_reference) restrict readonly buffer b_camera_block {
    mat4 projection;
    mat4 view;
    mat4 pv;
    vec4 position;
} camera;

layout (push_constant) uniform u_pc_block {
    b_camera_block camera_ptr;
};

void main() {
    o_pixel = vec4(i_uv.x, 1.0 - i_uv.y, 0.0, 1.0);
}``` we got a shader
#

we got uv coordinates

#

we got the camera

#

we don't got the BVH though KEKW

wispy spear
#

i like the neat naming

wicked notch
#

Having renderdoc is so good

wicked notch
#

I don't know who or where the person who decided on bitfields is

#

But I hope he will forever regret this decision

frank sail
#

lodge a complaint with Dennis Ritchie

wicked notch
#

Jaker

#

do you reckon this is how cornell box should look with albedo demodulation?
#1090390868449558618 message

frank sail
#

That looks probably roughly correct

wicked notch
#

The ray color is always getting tinted by the light's color though

#

Even the primary bounce

#

Should that also be deferred?

frank sail
#

that's good

wicked notch
#

most GPU inefficient ray-tri intersection KEKW

#
intersection_result_t primitive_intersect(inout ray_t ray, in uint start, in uint end) {
    uint prim_id = -1;
    intersection_result_t result = intersection_result_t(prim_id, vec3(0.0));
    for (uint i = start; i < end; ++i) {
        prim_id = uint(bvh_fetch_primitive_id(i));
        const vec3[3] v012 = vec3[3](
            vec3_from_float(vertices_ptr.data[prim_id * 3 + 0].position),
            vec3_from_float(vertices_ptr.data[prim_id * 3 + 1].position),
            vec3_from_float(vertices_ptr.data[prim_id * 3 + 2].position));
        const vec3 p0 = v012[0];
        const vec3 e10 = p0 - v012[1];
        const vec3 e20 = v012[2] - p0;
        const vec3 normal = cross(e10, e20);

        const vec3 center = p0 - ray.origin;
        const vec3 r = cross(ray.direction, center);
        const float inv_det = 1.0 / dot(normal, ray.direction);

        const float u = dot(r, e20) * inv_det;
        const float v = dot(r, e10) * inv_det;
        const float w = 1.0 - u - v;

        if (u >= FLT_EPS && v >= FLT_EPS && w >= FLT_EPS) {
            const float t = dot(normal, center) * inv_det;
            if (t >= ray.t_min && t <= ray.t_max) {
                ray.t_max = t;
                result.prim_id = prim_id;
                result.barycentric = vec3(w, u, v);
            }
        }
    }
    return result;
}```
#

We do got le tringle though

#

GPU accelerated, raytraced tringle

#

Now let's draw the rest of the fucking owl

wicked notch
#

mmm yes

#

cronlel bxo

#

Also known as cornell box

glass sphinx
#

ikea cornel box

#

you need to assemble it yourself

#

but half the parts are missing

#

how can this even happen

wispy spear
wicked notch
wispy spear
glass sphinx
#

lmao

#

its leaking

wicked notch
#

Alright I've found the issue

#

And it's not good

#

at all

#

I fixedn't

#

It's better than before for sure KEKW

#

I'm not sure how or why

#

But it looks like I'm doing anyhit or something, instead of closest hit

#

What the hell is this KEKW

glass sphinx
wicked notch
#

It's a bit broken so I'm not sure perf is meaningful but it do be running quite slow

#

1.25ms for sponza

#

Fortunately it doesn't scale linearly with triangle count

#

logN ftw

#

2.5ms for intel sponza

#

With the tree, curtains and leaves

#

Weird occupancy graph though, the hell happened in the middle

#

It would be very cool if the API to use the RT cores directly were exposed

#

But I guess they need their internal BVH to work correctly

glass sphinx
#

you already implemented a bvh???

#

10xer

wicked notch
#

madmann did it for me KEKW

#

I just reimplemented the tracing on the GPU

#

I still don't understand building algorithms unfortunately 😦

glass sphinx
#

aah

#

cool tho

#

was it easy to port the tracing and reuse the bvh?

wicked notch
#

Yeah, the bvh itself is two vectors

#

very easy to send to the GPU

#

minus the garbage bitfield but we don't talk about that

#

The tracing algo is also very simple

glass sphinx
#

nice

wicked notch
#

eyyy

#

I got it

#

turns out I was overwriting an good intersection with a bad intersection if none were found KEKW

#

Lovely

#

Beautiful

#

I also optimized it a little

#

The intersection code is utter garbage though bleakekw

#

Poor occupancy, you can feel when there is a very divergent pixel KEKW

wicked notch
wicked notch
#

lots of NaNs damn

wispy spear
#

can you not interpolate between neighbors when center is nan? 🙂

#

or run a denoiser over that

wicked notch
#

Nah this is a problem that must be fixed

#

hm

#

Not relying on NaNs doesn't solve the issue

#

epic circular pattern

wispy spear
#

ive seen that before

#

you were able to fix it then as well

wicked notch
#

oh shit

#

I don't remember

#

frick

wispy spear
#

feels like it was last wekeend

wicked notch
#

I don't remember having these weird circles in my CPU raytracer thonk

#

maybe I am having a stroke

wispy spear
#

perhaps not in the cpu raytracer, but i rember seeing these in context of your or jakers recent shizzles

raven orchid
#

That’s a really cool pattern though

frank sail
#

self intersection moment

wicked notch
#

mfw it ain't

#

I offset the ray by a lot and I still get dumb circles

frank sail
#

not self intersection moment

wicked notch
#

You can see here I get circular patterns when I'm not intersecting a primitive at all #ray-tracing message

#

green = I hit at least 1 primitive
red = I hit no primitive whatsoever in any of the bounces

wicked notch
#

turns out ray-node is bork

#

Investigating™️

wicked notch
#

Investigation results are in

#

Bounding boxes are extremely small sometimes, when applying a min and max bound to them the circles stop

frank sail
#

You should start adding debug visualizations in this renderer

wicked notch
#

Also, I guess that precision on the GPU is inevitably lower or something, because the same bounding boxes work fine on the CPU

frank sail
#

Like what I'm doing in ff (frogfood)

wicked notch
#

I know the issue though, it's precision

#

Either precision, or I don't understand the ray-node intersection test

frank sail
#

GPU floats don't intrinsically have less precision, though compilers seem to act as though --ffast-math is enabled

#

The standard guarantees some things about fp precision too

wicked notch
#

hm

#

can I disable that somehow

frank sail
#

Well check the spec to make sure I'm not bullshitting you first

#

But also, I don't think you can change that

#

See what guarantees you actually get

wicked notch
#

NaNs are not required to be generated mfw

#

Any subnormal (denormalized) value input into a shader or potentially generated by any operation in a shader can be flushed to 0. mfw pt2

#

Oh come on
Operations including built-in functions that operate on a NaN are not required to return a NaN as the result.

#

Seriously

wicked notch
#

GLSL saddens me

#
// precision issues require me to do this ugliness
const bool hit_left = intr_left.x - 0.000001 <= intr_left.y + 0.000001;
const bool hit_right = intr_right.x - 0.000001 <= intr_right.y + 0.000001;```
wicked notch
#

At least sponza looks as nice as ever

frank sail
#

heelll yee

delicate rain
#

I second bvh vizualization, helped me solve bunch of bugs

wicked notch
#

Ye it's probably the next or second next thing I will do

#

I kinda want to see some albedo

delicate rain
#

I get it I get it 😄

frank sail
#

just one more feature bro, then stuff to help me debug bleakekw

wicked notch
#

I am not satisfied with my current solution btw

#

the adding of an epsilon adds the chance of traversing a lot more of the BVH than required

#

but I don't know how else I can address GLSL's special needs

#

there is no way to know what the internal spirv compiler will do

frank sail
#

maybe you can slap the invariant keyword on some stuff

wicked notch
#

I mean

#

everything is randombleakekw

#

I could dump the values of the bounding boxes on the C++ side and on the GLSL side

#

Through renderdoc

#

see if I have any loss of precision

frank sail
#

try putting invariant on the output color and see if the epsilon hack is still needed

wicked notch
#

I guess I should also remove BDA... (shader debugger doesn't work otherwise)

frank sail
#

I've never used the keyword, so good luck

wicked notch
#

amazing

#

btw

#

you can represent any floating point number in GLSL as you would in C++ right?

frank sail
#

I think so

wicked notch
#

for example, if I push const FLT_MIN, will it be the exact same?

frank sail
#

the encoding is the same, yeah

#

IEEE-754 my beloved

wicked notch
#

I mean the operations

#

a * b + c should be exact

frank sail
#

the specs may offer different guarantees about that

#

particularly w.r.t. ULP precision

wicked notch
#

I'm about to use fp64

frank sail
#

why do you need such exact precision anyways

wicked notch
#

uh

#

do you know tringles

#

they can make planes

frank sail
#

yeah you need epsilon anywhere 🫄

wicked notch
#

now it just so happens that the bounding box of a plane is smol on the y side

#

sometimes it's so smol the GPU freaks out

#

I'll try looking at some other BVH trasversal impls on the interwebs

#

perhaps they do clever things

frank sail
#

The precise qualifier ensures that operations contributing to a variable’s value are done in their
stated order and with operator consistency.

#

I don't get how this differs from the invariant qualifier, but okay

#

well I guess invariant implies that certain optimizations can be done, they just need to be consistent

#

so I guess putting precise on your output will make all computations leading up to it precise as well, epic

#

I think that is a lot closer to the fp rules of C and C++

wicked notch
#

amazing

wicked notch
#

eyy we got the precision back!

#

IEEE754 my beloved

frank sail
#

how did you do it?

wicked notch
#

I spammed precise all over the intersection code

frank sail
#

I think it will propagate up if you just apply it to the output color, no?

wicked notch
#

probably yeah

frank sail
#

smh trying the hard thing before the easy thing 😄

wicked notch
#

yep

#

finally

#

thank god Khronos noticed that someone might want a bit more precision bleakekw

frank sail
#

perchance

wicked notch
#

This path tracer really slows down my pc damn bleakekw

minor root
#

i remember compiling the fsr2 c++ lib grinds my entire pc to a halt for a good 10 seconds

frank sail
#

ah yeah those shader permutations be thicc

wicked notch
#

dFdx and dFdy are undefined behavior in divergent control flow right?

#

Lucky for me, raytracing is anything but divergent, right guys?

frank sail
#

and here it won't be "slightly" wrong, it will be horrifically wrong

wicked notch
#

so horrifically wrong it causes a VK_ERROR_DEVICE_LOST

frank sail
#

I remember debugging a similar issue when I was using texture for SSR

wicked notch
#

Anyways I got myself some albedo

#

Let me show this off to danny one sec

frank sail
#

which danny

wicked notch
#

the one who's making a raytracer wit VK_KHR_ray_tracing

#

#1127583870167035944

frank sail
#

were you guys racing or something

wicked notch
#

nah I poking him to make sponza

#

because he procrastinated

#

so I made my own (jk, this is for learning BVHs KEKW)

#

In fact I'll work more on the BVH after this

#

maybe, maybe even make the building on the GPU

#

maybe though

#

I do love myself some

#

ground truth

wispy spear
#

ye tiling on the floor looks like cobbled road 😛

summer gyro
#

also is this the super sponza you made or regular sponza ?

wicked notch
#

absolutely terrible KEKW

#

pure garbage

#

40ms for sponza

frank sail
#

you better get used to it, because that's how the numbers typically look when doing GPU RT

wicked notch
#

even with RTX™️?

frank sail
#

Yes

wicked notch
#

Hm

#

I hope danny makes his thingy work soon so we can compare 🅱️erf

summer gyro
wicked notch
#

1spp and 4 bounces bleakekw

summer gyro
#

ahh

frank sail
#

now do 2 bounces and 0.25 spp frogapprove

summer gyro
#

wait 40ms for 1spp and 4 bounces ?
thats too much no ?

frank sail
#

that is reasonable imo

wicked notch
#

ye that's what I'm saying KEKW

summer gyro
#

denoising + upscaling time smh

wicked notch
#

1080p btw

#

perhaps that's the reason

#

but this is all trasversal overhead

frank sail
#

yeah u need to do 240p

summer gyro
#

ahh try at quater res ez perf ++

wicked notch
#

I kinda want to move on to RT acceleration

#

But I have work to do here first

frank sail
#

lol already sick of the perf

wicked notch
#

BVH build on the GPU

frank sail
#

you gotta optimize it for the frogfood implementation KEKW

summer gyro
wicked notch
#

mfw

frank sail
wicked notch
#

primary rays are fine too

#

It's the secondary & later that absolutely destroy 🅱️erf

frank sail
#

classic

#

the sad thing is that it's faster to rasterize primary rays too, so rip the only fast part about GPU PT

wicked notch
#

btw

#

I'm trying the albedo modulation thing

#

but your RSM thingy has a lot more red and green near the curtains

frank sail
#

it won't do anything until you denoise fyi

wicked notch
#

There is barely any red here

frank sail
#

my scene was a little more optimal for getting the color bleed

#

since I angled the sun to only hit the curtains

wicked notch
#

You can kinda see the ground in the curtain lol

frank sail
#

Try a different scene. I don't know exactly how it should look here

#

Make a scene where certain surfaces can only be illuminated by colored bounce light

wicked notch
#

Should I upscale after accumulating or before accumulating? thonk

#

Also tonemapping, before or after upscaling?

frank sail
#

Tonemap last

proven laurel
frank sail
#

Cuz upscaling affects the pixel color in physical ways

wicked notch
#

Alright

#

How do you debug a segfault in nvoglv64.dll? nervous

frank sail
#

go up the stack and see which line of yours triggers it

wicked notch
#

It's random

#

sometimes vkWaitForFences, sometimes vkQueueSubmit2 and sometimes vkCmdDraw

#

Also, the simple act of binding textures does this

#

Here's another ridiculous thing: If I change the render resolution it works fine sometimes bleakekw

wispy spear
#

missing fence/barrier perhaps?

wicked notch
#

I'll try slapping some full barriers everywhere

wispy spear
#

and then remove until it kicks you in th butt again

frank sail
wicked notch
#

amazing

#

There is not one line of OpenGL in there

#

how is it calling into OpenGL

wispy spear
#

nvoglv64.dll

#

vulkan is just abstraction on top of opengl

frank sail
#

opengl truly is a low-level api for nvidia

wicked notch
#

As usual OpenGL trumps everything

wispy spear
#

would be funny

#

vulkan just being highly optimized glCompileListNVs/glDrawListNVs

proven laurel
frank sail
#

o 😳

wicked notch
#

No errors

#

Even with GPU assisted

#

I don't even have to sample any textures for the crash to happen, just bind a descriptor set and that's it KEKW

proven laurel
#

just a sanity check

#

you are not destroying the resource you are waiting on are you?

#

Also you might be TDR'ing

wicked notch
#

No TDRs either

twin musk
proven laurel
#

this sort of nondeterminism smells like TDR though

frank sail
wicked notch
#

Let me try reducing the shader to nothing

frank sail
#

I could see it being true in the early days of their vulkan support

proven laurel
#

I think there is some truth to it

#

afaik that's the same reason why you get issues with windows that have an ogl context

twin musk
#

i mean there has to be a reason why passing glsl in as shader module source without the ext used to work right

frank sail
#

meanwhile, Vulkan is based off an API that AMD donated to Khronos yaymd

twin musk
#

mantle revival in 2024 pls

proven laurel
#

3dfx glide revival pls

twin musk
#

can't have issues on nvidia cards if your api doesn't support them :)

wicked notch
#

Ok so

#

Reducing the shader to nothing except a texture sample works fine

#

changing the resolution (either up or down) works fine (sometimes)

#

Not binding the set works fine

#

Sampling from texture 0 only is bork

#

NOT sampling at all and binding the set is bork (except if the shader is basically empty)

proven laurel
#

bork as in crash?

wicked notch
#

ye

#

I don't see any TDRs in the event viewer though

proven laurel
#

Not sampling being an issue is weird

#

it might be some bad access (gpu based won't catch all of them)

wispy spear
#

what happens if you reboot and try again

wicked notch
#

I am not accessing the texture array in any way though

proven laurel
#

oh wait

#

it's a texture array?

wicked notch
#

Yeah, bindless

proven laurel
#

array of texture descriptors or texture array

wicked notch
#

It's variable count and partially bound

#

array of texture descriptors

proven laurel
#

does the descriptor set contain anything

wicked notch
#

yeah, the textures

#

I'll try with an empty set?

proven laurel
#

Are you dynamically updating the size of the set

wicked notch
#

No

proven laurel
#

hm

wicked notch
#

The set is written to once and never again

#

Btw binding an empty set works fine

proven laurel
#

Btw. is VK_DESCRIPTOR_BINDING_UPDATE_AFTER_BIND_BIT set as well?

wicked notch
#

yes

proven laurel
#

and the variable count binding is the last binding?

#

(not sure if validation checks for that)

wicked notch
#

Last and only binding yes

#

I'll try binding only 1 (one) texture

wicked notch
#

It still crashes

#

what the hell is going on

proven laurel
#

can you remove the variable size bit?

wispy spear
#

also the reboot will clean up bit perhaps

proven laurel
#

if there was a driver crash definitely

wicked notch
#

I did reboot

wispy spear
#

ah

wicked notch
#

probably didn't mention that

#

didn't fix 😦

wicked notch
#

I am thinking the shader has some kind of issue

#

Because if I shrimply output black, everything works fine

#

I've narrowed it down to BVH intersection

proven laurel
#

what is the pipeline?

wicked notch
#

if I call bvh_intersect, binding the set will crash

proven laurel
#

Is it an rt pipeline?

wicked notch
#

No it's a frag shader

#

regular old pipeline

#

I've narrowed it down further

#

It's the ray triangle intersection function

#

calling it will crash

proven laurel
#

what exactly is the function doing

#

beyond arithmetic

#

because arithmetic should never cause a crash unless it is a tdr KEKW

wicked notch
#

nothing, it's pure ALU

#

And apparently this is the bit that makes it die:

if (u >= -FLT_EPS && v >= -FLT_EPS && w >= -FLT_EPS) {
    const float t = dot(n, c) * inv_det;
    if (t >= ray.t_min && t <= ray.t_max) {
        const vec3 barycentric = vec3(w, u, v);
        const vec3 n0 = vec3_from_float(vertices_ptr.data[prim_id * 3 + 0].normal);
        const vec3 n1 = vec3_from_float(vertices_ptr.data[prim_id * 3 + 1].normal);
        const vec3 n2 = vec3_from_float(vertices_ptr.data[prim_id * 3 + 2].normal);
        const vec2 uv0 = vec2_from_float(vertices_ptr.data[prim_id * 3 + 0].uv);
        const vec2 uv1 = vec2_from_float(vertices_ptr.data[prim_id * 3 + 1].uv);
        const vec2 uv2 = vec2_from_float(vertices_ptr.data[prim_id * 3 + 2].uv);

        ray.t_max = t;
        result.prim_id = prim_id;
        result.barycentric = barycentric;
        result.position = vec3[](p0, p1, p2);
        result.normal = normalize(vec3(n0 * barycentric.x + n1 * barycentric.y + n2 * barycentric.z));
        result.uv = vec2[](uv0, uv1, uv2);
    }
}```
proven laurel
#

is the vertex data valid

wicked notch
#

yep

proven laurel
#

idk how binding the set makes this here crash though

wispy spear
#

is it possioble to run this glsl through some glsloptimizer and run the outcome of it?

wicked notch
#

I fixed it

#

I'm not sure I like the fix though

wicked notch
wispy spear
#

does it not have that expression-esque output?

wicked notch
#

Oh shit

#

wait it worky

#

absolute pog

wispy spear
#

ye it do

frank sail
#

download it

#

NOW

wicked notch
#

Does it worky on NV?

#

I do not possess AMD HW unfortunately

frank sail
#

it works without AMD drivers

wicked notch
#

common AMD W

#

is there a way to uh

#

see spirv instead of AMD ISA?

frank sail
#

well uh

#

you can use glslangvalidator if you just want spirv KEKW

wicked notch
#

this is a sad world innit

wispy spear
#

gib your shader

wicked notch
frank sail
#

the interface for RGA needs an upgrade

#

it only exposes like 25% of what RGA can actually do

#

otherwise you have to use a stinky command line

twin musk
#

i wish we had proper debug info for shaders to correlate the isa back to the source/at least spirv

wispy spear
wicked notch
#

sir

#

I get it

#

Now how do I know which section of this is intersect_primitive? KEKW

wispy spear
#

interesting, for vk1.3 it yields error: 663: Invalid opcode: 400

#

😄

frank sail
#

look at the ray tracing extensions for spirv

wicked notch
frank sail
wispy spear
#

shaderplaygroundve

#

vk1.1 produces spirv 1.3

twin musk
wispy spear
#

eh i better not confuse the horse conch

wicked notch
#

I've been contemplatong the frog for a while now

#

Still dunno how the fix works

#

This is the frog I've been contemplating btw

#

For the record, the "fix" is the following

#

Pardon my screenshot

#

But as you can see, I'm loading all the vertex data early in the loop

#

Now if I where to do separate loads for position, normal and uv

#

I will have the same old crash

#

Why? I have no clue

#

Is accessing memory in divergent control flow UB?

#

I would hope it's not?

frank sail
#

the only potentially UB part of reading a buffer is with descriptor indexing

wicked notch
#

I will assume this is a driver bug and not think about it further

frank sail
#

or OOB reads without robust buffer access 😉

wicked notch
#

Oh good call

#

Let me enable robustness one sec

#

Nope, even with robustness it crashes

frank sail
#

hec

wicked notch
#

The next stage would be to have you guys test my thing

#

But eh

#

uncomment #define USE_BUGGY_BEHAVIOR to get crash (maybe)

finite yacht
#

huh you are doing VRS as well?

wicked notch
#

Yeah but not in this pathtracing project KEKW

#

My bad

#

There we go, this is the version with basically all extensions disabled except the ones I actually need (BDA, desc indexing)

finite yacht
#

Ok, so here without and with USE_BUGGY_BEHAVIOR. Both seem to work fine but with gets me lower fps

wispy spear
#

no linux build smh

wicked notch
#

hm

#

That's expected

#

Or at least

frank sail
#

I thought lvstri was on Linux

wicked notch
#

I wouldn't expect a few milliseconds of delta between loading from memory 3 times and only once

#

But it's better than crashing in the driver bleakekw

wicked notch
frank sail
raven orchid
wicked notch
#

No worries, the froge is but a mere 1 million tris

wispy spear
#

for you ill boot into windows my frog

#

i suppse USE_BUGGY_BABABOOEY thingy is an env var?

wicked notch
#

it's in trace.frag

wispy spear
#

ah

#

oki on my way windows

#

noice, first try just crashes

wicked notch
#

amazing

wispy spear
#
$ ./PathTracer.exe
[2023-07-24 23:31:15.394] [wsi] [info] initializing window (width: 1920, height: 1080, title: "PT")
[2023-07-24 23:31:15.434] [instance] [info] initialized volk
[2023-07-24 23:31:15.478] [instance] [info] instance initialized
[2023-07-24 23:31:15.479] [instance] [info] validation layers initialized
[2023-07-24 23:31:15.479] [device] [info] found GPU: NVIDIA GeForce GTX 1060 6GB
[2023-07-24 23:31:15.479] [device] [info] acquired GPU: NVIDIA GeForce GTX 1060 6GB
[2023-07-24 23:31:15.480] [device] [info] API version: 1.3.242
[2023-07-24 23:31:15.480] [device] [info] device features enabled
[2023-07-24 23:31:15.480] [instance] [error] [general] terminator_CreateDevice: Failed in ICD C:\Windows\System32\DriverStore\FileRepository\nv_dispi.inf_amd64_675be35f1ba2315e\.\nvoglv64.dll vkCreateDevice call
[2023-07-24 23:31:15.480] [instance] [error] [general] vkCreateDevice:  Failed to create device chain.
[2023-07-24 23:31:15.480] [device] [info] device initialized
Segmentation fault
#

h

#

ah i may or may not have vulkan sdk installed

#

no its installed, i just rembered and checked, did it a week ago

wicked notch
#

Hmm perhaps it's a weird bug on my part

#

strange tho

wispy spear
#

updating dribers too...

wicked notch
#

If it don't work it's fine

#

I got the answer I was looking for

#

i.e: NV bad KEKW

wispy spear
#

hehe

#

colors on windows look much better than on windows, and disord is more schnappier too

#

ah im on 536.23, new one is 536.67

#

great

wicked notch
#

we should all switch to amd

raven orchid
#

Woah failed why?

wispy spear
#

i cant explain why but i prefer novideo

wispy spear
raven orchid
#

That’s so weird

wispy spear
#

634mb of blob

#

ah

#

when i use the installer installer, it shows the error : >

#

too low disk space

#

worked now, but i dont get why it cant init the device

#

is it using anything RTXy?

wicked notch
#

nope, only BDA, descriptor indexing and extended integer/fp types (uint64_t, etc.)

wispy spear
#

perhaps that wont work on the 1060

wicked notch
#

I'll integrate FSR2 tomorrow

#

anyways, path tracing is epic

#

I forgor to put this here this morning KEKW

#

It'll serve as a good collection of all the reference stuff I get

#

Btw I tried to look at DLSS

#

And apparently you need some kind of APPID given directly by NVIDIA or something

finite yacht
wicked notch
#

black lines?

finite yacht
#

in the "path tracing nightmare" scene I have there are these black lines

wicked notch
#

Ah, mine doesn't have them for some reason

#

Here it is, complete with the big emissive sphere of doom

wispy spear
#

looks like one is with the other without textures

finite yacht
wicked notch
#

Huh, I'm not sure

#

I'm not sampling any textures, for the record

#

Actually I lied, I am sampling base color, if there is a base color

wicked notch
#

Probably something wrong with the loading

wispy spear
#

damn that looks neat

#

now make it real time

#

: >

proven laurel
#

atleast there is fsr

finite yacht
#

what more do you want

wicked notch
#

30ms per frame is real time enough for me 😛

wispy spear
cedar seal
#

@wicked notch Suggestion: You could ask mods to pin first post here: #1090390868449558618 message

wispy spear
wicked notch
#

path tracing has no right looking this good

wispy spear
#

holy moly

#

that do be looking neat

finite yacht
#

wanna add AA pls?

wicked notch
#

ye I promised I'd add FSR KEKW

finite yacht
#

are you planing to make this real time?

#

like with little noise as well not just high fps

wicked notch
#

Eh I have no idea how

#

it's already 1spp

#

I'm not really sure how to optimize trasversal

#

I would like to though

#

FSR can already smooth out the noise a bit

finite yacht
#

because regarding the AA if you plan on accumulating multiple samples its very easy to add. Just randomly jitter the primary ray inside the pixel

#

like with TAA

summer gyro
#

Also do add denoising

#

Looks great

wispy spear
#

https://www.youtube.com/watch?v=VlGfFOZRubc 2nd asset potentially has a gazillion of tringles again

It's the first Tuesday of the month and Unreal Engine developers know what that means... free stuff! It's another Unreal Engine Marketplace giveaway, this time for August 2023. This month we have 5 "free for the month" assets, with no additions to the permanently free collection. These assets are yours to keep forever, so long as you "buy" th...

▶ Play video
wicked notch
#

Lovely

#

Mayhaps I should invest in point shadows

#

I see aliasing too KEKW

#

nothing that a little AA can't fix tho

finite yacht
#

in the function that converts pixel to ray dir add random float 0-1 to pixel position. After some frames you got perfect aa

frank sail
#

or is it random float in [-.5, .5]

finite yacht
#

should be [0.0, 1.0) in compute shader

delicate rain
#

Damn I always forget how good RT looks

wicked notch
#

btw hardware accel makes things go about 3 times faster

#

Which is less than what I'd expected tbh

wicked notch
#

ery nice

#

I'm currently struggling to implement nanite like LODs bleakekw

#

I've been doing nothing but that for the past week or so

wicked notch
#

I mean I get how it works conceptually

#

kindof

#

up until where they go for persistent threads on the GPU bleakekw

#

But the LOD'ing I mostly understood it

frank sail
#

What part about persistent threads conchfusez

wicked notch
#

I just fail to understand graph partitioning

frank sail
#

oh jeez

wicked notch
#

regardless of workload

#

because I have no idea what they are or how they work

frank sail
#

Isn't it just the thingy where there is a work queue and threads keep grabbing work until there's none left

wicked notch
wicked notch
#

that's right

#

except on the GPU bleakekw

#

how the hell do you make a work queue on the GPU

frank sail
#

an atomic 🤔

#

hmm

wicked notch
#

uhh

#

so the job queue has all the cluster nodes to be processed

#

uh

#

processing involves checking whether the cluster should even be considered when selecting the LOD?

frank sail
#

It's possible that they implement a mini job queue for each WG, that way they can sync pushes and pops

#

Instead of having a single global queue

#

Idk lock free programming is hard, so I want to imagine they did something the shrimple way bleakekw

wicked notch
#

mfw I have no idea about lock free on the CPU

wispy spear
#

NaiveJobQueue.cpp

wicked notch
#

how do you expect me to understand lock free on the GPU bleakekw

#

I just use moodycamel's queue

#

is there a moodycamel's queue for the GPU?

frank sail
#

Uh atomic comp swap is your friend

wicked notch
#

perchance

wispy spear
wicked notch
#

well regardless, I'm not even at step 0

wicked notch
#

Just not applied to LOD but raytracing

#

the fundamental problem they're solving is one and the same

#

Damn this is interesting

#

I'm still lost bleakekw

#

but interesting nonetheless

wicked notch
#

literally me fr

frank sail
#

Reminds me of a series I read where the main character journeys to the core of the earth (not the one with the movie starring Brendan Fraser)

#

and in it he falls through a hole (or multiple) like that one

wispy spear
#

Jules Verne 😉

frank sail
#

Nope

#

It was a young adult series I think

#

I read it when I was in middle school (the last time I read fiction recreationally bleakekw) so I can't remember much

wispy spear
#

ah

frank sail
#

Ah it was the Tunnels series

wispy spear
#

i rember a few drawings of young jaker 🙂

frank sail
#

I used chatgpt to help me rember

#

Hehe I used to choose books to read based on how cool I thought the cover image was

#

Literally judging them by their covers KEKW

#

Because of that, I started on the third book of a series because it had the coolest cover