up on git?
#Fwog and co.
shell inlet
long robin
trilinear is rather crunchy in comparison
shell inlet
visible difference in squarishness
long robin
even more noticeable without discord compression to add more squares π
long robin
20 vs 5 vs 2 samples for calculating optical depth from each point to the sun
taking some samples up to 50 units away from the point (cell in the frustum grid) in the direction of the sun so incoming sunlight can have proper in-scattering
I already showed this, but not the comparison between the sample counts
shell inlet
I wonder are you stepping small steps inside the volume or what
long robin
I'm taking steps in world space in the direction of the sun, but only up to a maximum length
long robin
there is a visibility test in the form of shadow mapping
shell inlet
yeah I guess so
long robin
no multi scattering though
btw, my beer's law approximation is exp(-accumDepth), but this seems wrong for colored fog since it's supposed to account for both out-scattering and absorption
shell inlet
exp(-d*density)?
long robin
whoops it's supposed to be -accumDensity
but yeah colored fog should affect the color of the light that passes through
shell inlet
exp(-d*density)?
I think it's just that^
but you'd have shorter steps with more dense media and you'd have the step length stochastic also based on density
it's like importance sampling based on density
maybe it works only in homogeneous media though idr
long robin
I have to numerically integrate over my density function
my point is that out-scattering is probably the same regardless of the fog color, but absorption will change
shell inlet
I have this graph
with importance sampling according to beer
inverse transform sampling of beer
long robin
not sure how to apply that
long robin
is scattering coefficient the "density"?
long robin
ah
shell inlet
you integrate a phase function
over sphere
every time you get a new direction based on it as well
so more scattering media will need more shorter steps on average
long robin
makes sense
shell inlet
I hope it does because I half remember it
basically if your volume almost doesn't scatter you may as well go right through it more often than stop inside and change direction a bit (bounce internally)
long robin
I wonder how I would use a scattering coefficient if I had one
seems like it would go into the exp somewhere
the presentations I saw (and I) model transmittance as only a single float value since I guess they have monochrome fog only (or made a perf vs quality trade-off)
shell inlet
you say you don't have multiple scattering so nowhere ig
you only travel along single paths to the lights
you don't bounce around the volume itself
long robin
isn't that unrelated though
shell inlet
I don't think it is, unless I misunderstand how your implementation works
long robin
imagine if I have this setup (pretend the squares are fog)
β¬π© π‘
wouldn't the light entering the white fog be a little greener due to absorption?
ah I need to make it a light
long robin
exactly
I'll go to sleep and think about this later
basically, my thingy does not feature throughput like that, which is why I suspected it was broken
shell inlet
you'd be able to observe the effect if you have proper in-scattering
basically at each step of the path you'd have to not just trace a ray to the light but also march/integrate and accumulate throughput
you have a volume that is very scattering it seems so ye you need random walk
again I'm not exactly sure what you do currently so tell me when you wake up or something
long robin
I'm going to need a much more... "approximate" solution
shell inlet
(I really don't wanna read code)
long robin
again I'm not exactly sure what you do currently so tell me when you wake up or ...
the basic idea is to make the ray marching independent of the screen (it does not depend on the g-buffer except when compositing the fog onto the image):
- create two low-resolution RGBA16F 3D volumes (e.g., 160x90x256) that is aligned with the frustum
- for each cell of the first volume, determine the amount of incoming light (irradiance I guess) from all sources and the "density" (amount of participating media) in the cell
- solve the scattering equation by marching through the lighting+density volume, storing the in-scattered light+transmittance in the second volume with beer's law
- apply the volumetrics by mapping screen uv+depth to a texcoord in the lighting+density volume, then sample
there is also step 0 which is creating an exponential shadow map of the sun for nice volumetric shadows
picture version
shell inlet
I see
doesn't sound too bad except maybe that it's lacking throughput
by accumulating density via marching with short steps I think you're effectively integrating using something like woodcock tracking algorithm
which is used for inhomogeneous media rendering
and you have inhomogeneous media
though you don't have the common absorption and scattering coefficients in your implementation
btw you'd have something like exp(-integrated_extinction_coeff) instead of density
extinction/attenuation coefficient is the sum of absorption and scattering coefficients
I guess you could infer absorption from density
but scattering is something I'd make a constant unless you also want to have volumes defined by different things and not just fog
long robin
that thing of using a non-constant step size based on the scattering/attenuation coefficient (and a corresponding pdf/cdf) is quite clever
I dunno how well it would operate with the inherent bias from having a fixed number of steps though
btw pushed my changes
shell inlet
that thing of using a non-constant step size based on the scattering/attenuation...
the intuition is that scattering coefficient roughly means how often the ray encounters a particle and changes direction, on average
so one can translate that to what distance a ray would travel without encountering one and that's why it works
also when we importance sample something the integral converges to it naturally, as if we multiplied by the term we're sampling proportionally to
so we don't even need the beer-lambert's law term anymore
in other words pdf cancels out the beer
I digress I think
golden schooner
shell inlet
<a:beercheers:813180724361297971>
so woodcock tracking is not worth noting
πͺ΅ π
long robin
Am I forbidden from not working on it for four days 
shell inlet
there are other ways to maintain activity in a thread besides actually working on the project 
long robin
I'm quite busy this week
Maybe next week I'll merge the examples refactor branch finally
shell inlet
don't forger to update screenshots
rugged notch
Local open source contributor focuses on family and friends for the holidays, found pelted to death by an angry mob
shell inlet
can we easily interop vulkan with gl
just for hw rt
never interopped anything with gl in my life
must be a pain right
long robin
pretty sure nv has an extension to expose Vulkan images to GL, which should be enough
seems shrimple, but the bugs one will inevitably encounter are probably cursed af
long robin
like some limited ray tracing API?
shell inlet
yeah
long robin
idk tbh
rugged notch
using forgotten amd-jutsu
long robin
I'm not too experienced with RT to know an ideal way to abstract RT stuff
rugged notch
GL_EXT_FWOG let's goooo
shell inlet
GL_FWG_RAY_TRACING
long robin
why can't we tell the user to install embree
shell inlet
there's now a new arch review board for fwog
I mean we can use embree... for software rt
heavy cipher
glPushRayFWG
shell inlet
but I'd still use madmann's lib instead
long robin
I mean we can use embree... for software rt
are you implying that you want me to add hw rt somehow
I don't think there is cross platform Vulkan interop
shell inlet
not really, but we were discussing a possible rt example
long robin
and by that I mean supported on both AMD and NV
long robin
Ok also Intel
rugged notch
babe are u ok u haven't raytraced on your Arc GPU
long robin
Intel too easy to forgor
Anyways, maybe Fwog 2 will have abstracted RT
Since it will be Vulkan based
shell inlet
WHAT
rugged notch
bababooey as they say
long robin
Not to say that I plan on starting it anytime soon
shell inlet
also you dare to challenge vuk?
long robin
Sadly a Vulkan abstraction will be a lot harder and compete with other abstractions made by smarter people
shell inlet
Sadly a Vulkan
abstraction will be a lot harder and compete with other abstractions made by smarter people
shell inlet
I snapped out of it before long fortunately
final cove
plus these days GL is a vulkan abstraction anyway :^)
long robin
At least GL was pretty easy to wrangle into something nice-feeling in the end, thanks to the hard work of driver devs
shell inlet
oh yeah so they translate gl to vulkan nowdays?
long robin
only sometimes
heavy cipher
well its more like there is a translation layer, zink
but there are still opengl drivers
long robin
and the different API drivers still interface with a common high-level driver rather than implementing the whole stack each time
brisk narwhal
hype for fwog 2
golden schooner
At least GL was pretty easy to wrangle into something nice-feeling in the end, t...
@shell inlet it sounds like jaker is praising the two of us, pushing jaker to work on Fwog
shell inlet
π€
long robin
<@397737942476652545> it sounds like jaker is praising the two of us, pushing ja...
I was actually praising the gl driver devs, but you two are worthy of praise as well 
long robin
seems like teardown has some weird TAA going on
the main part of the TAA shader is like 60 loc, but I guess that explains all the ghosting
I'm not actually sure if it's a TAA shader, but I definitely see some kind of spatiotemporal blending thing going on here
long robin
it uses motion vectors, but doesn't reject the old sample ever
instead, it does a thing where it takes several samples of the current frame and blends them together before temporal accumulation
well, it must be TAA because it's blending with a jittered previous frame
uh, but the output is not anti-aliased πΈ
alright, found the actual TAA shader π
shell inlet
I thought you were done with teardown
long robin
I'm presenting the thing in 2 hours in gpvm
shell inlet
gp virtual meetup?
long robin
Ye
shell inlet
how I haven't seen any mentions of it being planned anywhere
is it a private thing or something
long robin
well it's a different server run by different people mostly
but there are some of the same people
shell inlet
also graphics programming?
long robin
yeah
shell inlet
hm I don't think I can handle being in two at the same time
long robin
It's in #related-servers if you scroll up
long robin
hm I don't think I can handle being in two at the same time
There isn't much activity except during meetings
long robin
The server has 1/15 the people as this one
long robin
I suppose there will be vods on yt
Ye
shell inlet
then I'll watch those and that's it
live events are too draining and inflexible anyways
long robin
big push, a huge one even
deleted some code and added new pics of the examples
o wait I need a pic for the gpu driven one
long robin
now the branch is probably ready to be merged
I just need to review it tomorrow when I'm not tired
just in time for ldjam
still haven't fixed an issue from the last jam 
https://github.com/JuanDiegoMontoya/Fwog/issues/34
golden schooner
i should also attend to the open issues π
long robin
maybe I'll try out some audio library so I can have sound this time
funny zig man has this thingy, which seems convenient
https://github.com/andrewrk/libsoundio
might not be a good time to learn how to do audio though
heavy cipher
there is one from volvo, maybe you like
long robin
steam audio?
picture of de_dust2 on the homepage, nice
I wonder if it will make my games sound like cs
shell inlet
I once tried to make a spatialization engine, never finished it
audio is very similar to graphics because it's also mostly filtering, maybe even more than graphics
sampling and filtering
long robin
yeah, but in this case I'm hoping a library will do everything for me
well actually I just want a way to play sound files with maybe some minor modifications
shell inlet
best bet for a jam
I used sdl2 audio subsystem
for audio output
though I had to write a mixer
long robin
steam audio seems like a beast
shell inlet
there was sdl_mixer
but I thought it was slightly retarded
btw gpvm vods aren't up yet sadly
checked today and was hoping they'll be
is it an event that spans multiple days?
shell inlet
always in VC?
long robin
yeah, it used to be zoom, then we switched to discord cuz zoom sucked, then discord got blocked by the great firewall (main organizer is chinese) so we switched back to zoom for vc
long robin
I asked when the vod will be ready
shell inlet
thanks
long robin
the video might be up in a few hours
anyways, libsoundio seems kinda simple, but not simple enough that I can avoid having to spend hours learning it
shell inlet
ironic but what if sdl_mixer
long robin
I like that it can load common audio formats out of the box
seems like libsoundio cannot, so I'd have to make my own or add another library
golden schooner
soloud can do spatial too iirc
long robin
ah, that's what I'm talking about
// Declare some variables
SoLoud::Soloud soloud; // Engine core
SoLoud::Wav sample; // One sample
// Initialize SoLoud (automatic back-end selection)
soloud.init();
sample.load("pew_pew.wav"); // Load a wave file
soloud.play(sample); // Play it
: )
long robin
seems π¦le enough to use for a game jam game
jam
long robin
the theme is π¦
looks like there is no cmake project for it :()
There's a few ways to include SoLoud to your project.
You can, for example, include all the SoLoud source files to your project, define one or more of the backend defines (see table below), and you're good to go.
A bit more structured way is to use GENie / premake4 to create the build files, and build a static library for your compiler / environment.
then it looks like I need a backend, and this should do the trick
https://miniaud.io/
hmm should I move this convo to another post to avoid further contamination of ?
long robin
why is that in the contrib folder
golden schooner
FetchContent should work and then somehow refer to that src.cmake
maybe they dont like CMake but somebody provided it, and they keep it away in schlepprib
long robin
ah, it says that right in the readme
golden schooner
https://github.com/jarikomppa/soloud/pull/350 should be applied too i guess
hehe bold to add themselves as authors, but they didnt contribute any soloudism, just some infrastructure glue
long robin
well
If you wish to contribute code to SoLoud, add your name to
this list when sending a pull request. All code must be
either public domain, CC0, wtfpl, zlib/libpng licensed, or
similarly free to use (without attribution, or (l)gpl-like
limitations.
golden schooner
ye π
still weird
i know a bunch of people who are those kind of people who would put that on their CV as some remarkable milestone "XXX author"
shell inlet
I contributed to XXX, now I'm the XXX author
shell inlet
on paper I contributed only a broken version π
long robin
in practice you helped a lot more than that
shell inlet
then you patched the thing in as I was mathing it out
long robin
btw here's the vod (super low res lol)
https://youtu.be/jhPSDHlPDO0
shell inlet
ok gotta watch
long robin
second half is me looking at the game in renderdocument
long robin
youtube is probably still processing the good version (I hope)
long robin
but this was over zoom so quality will probably be bad no matter what
long robin
audio is as crisp as having you in voice chat π
I remember when my brother got a cheap gamer laptop in high school and called the speakers on it "crisp" when they were, in fact, utter shite
golden schooner
what i was saying is, that i got flashbacks from when we were 
ling around in vc the other day
shell inlet
teardown doesn't do occlusion culling?
long robin
it doesn't
shell inlet
in gbuffer fill pass there is a lot of objects rendered behind the directly visible ones
long robin
the closest thing is the depth buffer copying thing they do to avoid the expensive part of the shader
shell inlet
taking advantage of early z?
long robin
they can't because they write to depth and discard fragments
so they do this thing where they sample (a copy of) the depth buffer in the shader before doing an expensive trace
every N draws or so, they copy the depth buffer again so it can be read
the whole early-z + depth write thing led martty and I to have a long discussion about what the hardware can and cannot do
my understanding is that only AMD hardware can do early test + conservative depth write + late test, but only sometimes (heuristics), and even then it's not guaranteed to be a perf win
long robin
ye
and it has a constant ambient term with AO
actually, it sorta has 1-bounce specular GI, but it's kinda weird
shell inlet
watched digital foundry video on teardown
he said particles are stochastically rendered
I wonder if it's stochastic transparency
long robin
it is
shell inlet
I see
long robin
there is a line in the shader where they sample blue noise and use it as the discard threshold
shell inlet
I actually do transparency that way in my halfbaked engine renderer
for the time being before I write an actual final renderer
long robin
it's kinda cool because TAA sorta resolves it when the image is static
but in teardown the smoke is obviously noisy under motion
glass is rendered in a similar way and it obliterates reprojection
I think I show that later in the vid, along with smoke rendering
shell inlet
you could take multiple samples at a time by rendering the object multiple times
and averaging ofc
anything more than 1spp is somewhat fine
even 2spp already looks decent
long robin
you could take multiple samples at a time by rendering the object multiple times
I'm not sure what you mean by this
for transparency?
shell inlet
yes
it's just another estimator
but this time we discard based on alpha
and it converges to the rendered accumulated transparency
so what I'm saying is that you could take multiple samples per frame instead of accumulating temporally 1spp
rasterization is cheap nowdays
unless you shade each fragment with some heavy fragment shader that is
eventually temporal filters will go away I hope
so that we could have more than 1spp for rt
when hardware gets faster, if it gets faster idk
long robin
I doubt temporal filters are going away since our standards will just keep increasing
maybe they'll just be limited to low-end hw or advanced techniques
shell inlet
by the looks of it it feels like nvidia is struggling to make more efficient devices without making them bigger
probably can only pack so much before you get troubles from quantum effects
already basically printing chips with photolithography with amazing precision
long robin
they need to stack them now
then figure out the cooling problem later
As usual my build is failing on Linux
shell inlet
you could say it's cross-platform-ish
long robin
I'll leave it as a challenge since Linux users seem to love those
golden schooner
just setting up an account to be able to hand the thing in sounds like effort π
you have to register somewhere for the jam, dont you?
and upload all the stuff somewhere so that others can play with it
golden schooner
im playing this vampire game, where waves of enemies try to reach you, and when you kill those they drop a gem of some ort
which you can collect to gain experience, which will help you level up, and with each level up you can chose 1 out of 3 perks, or to upgrade an eisting perk
heavy cipher
good ol vamp survivors
shell inlet
I wonder if that's the one I'm thinking about
golden schooner
i got it at the last steam sale, i think
heavy cipher
The theme for this jam is "harvest"
here is my game idea (if you use it you must pay 2Β’ royalty): you control harvey 'harv' brixton, semi-retired boxer for hire and dad of 4, and you must defeat 9 other harveys in single combat to become harvest
long robin
fun little game
My friend got addicted to that game after he burned his hand and remembered that I said this game could be played one-handed 
long robin
you have to register somewhere for the jam, dont you?
it's very little effort
woo it compiles for linux now
long robin
currently asking chatgpt for game ideas for the jam
heavy cipher
mr. scrooge mcduck don wanna pay no 2Β’, i get it
heavy cipher
how many exposures can you add on top
long robin
about tree fiddy
heavy cipher
tempting
long robin
I'm acquiring inspiration
long robin
ye
shell inlet
ok but have you heard of vector displacement maps
long robin
like the ones they used in that halo rts game?
shell inlet
apparently π€
did not know
anyways this got me thinking what if one were to encode high poly meshes as a set of vertices with LODs where you have multiple sets of indices for each one and have base vertices for last level and next ones would only be stored as deltas from previous levels
so that maybe you could somehow easily render LODs via vertex pulling and interpolation for smooth transitions
maybe even saving on memory by using half floats for deltas
long robin
I wonder what you'd gain from that encoding scheme. Since you're encoding offsets maybe the vertices could be smaller
shell inlet
mostly storage size I guess, but I also said interpolation
you could multiply offsets by some factor based on distance
I did not think this one through, needs some testing
but in my head at least I think it would appear to gain detail as vertices slowly emerge from other vertices
and then other vertices do the same for the next level
long robin
Do you have to read all the lower detail levels for this?
shell inlet
ah but I guess that'd work only if those are hierarchical deltas
yeah so more computation
recursively
iteratively I mean
from lowest to currently active
long robin
If you use a compute shader + shared memory you could avoid redundantly reading the lowest lods for each vertex
Then write out the final vertex buffer to memory
shell inlet
if we store deltas from only lowest level we would not be able to do interpolation
long robin
Mesh shaders would be great for this
long robin
Imagine a compute shader that has access to the fragment stage
Which means you don't need to go to global memory between compute and rasterization
shell inlet
hard to imagine so I need to watch the presentation again
all the information was completely erased from my brain
long robin
kinda weird how the jolt examples are framerate-dependent
golden schooner
mayhaps the aufor doesnt know how to renderloop
golden schooner
yep or not focus of these shrimples
shell inlet
most likely intentional because stable physics runs at constant tickrates
I guess it's your job to interpolate then
unless there's some existing api for that in jolt
long robin
it's easy to have physics run at a constant tickrate while being independent of the render rate
I guess they didn't like stuttering or having to implement interpolation or something, idk
heavy cipher
run update first?
long robin
idk
deccer was the one who made the workflow thing and I have yet to understand how it works
heavy cipher
put sudo apt-get update before your sudo apt-get install
i know this because i have copied my workflow from someone else and it works
heavy cipher
when did i lie to you αΆ¦βΏ α΅Κ°α΅ αΆα΅Κ³Κ³α΅βΏα΅ αΆα΅Λ‘α΅βΏα΅α΅Κ³ ΚΈα΅α΅Κ³?
golden schooner
i can take a look later
rugged notch
my gf goes to another server
golden schooner
martty the good frog gave me a hand
with --fix-thingy or wifout?
golden schooner
i forgor about the glBindImageUnit thing π¦
long robin
I fixed it
golden schooner
its a parameter to apt-get update
golden schooner
sudo apt-get update --fix-missing
long robin
I wonder what that does
golden schooner
sometimes updates just stop updating in the middle ofit
i noticed that quite a bit on oeboentoe
and a shrimple redo of apt-get update wouldnt do anything, but --fix-missing did
it should not be necessary to pass that always
whenever it happened it was about dependencies not being able to be pulled of the things to be updated
long robin
Huh
golden schooner
just ignore what i said π
long robin
(4) With apt-get update you download what is needed to rebuild the list of dependencies.
After that you can try apt-get install --fix-missing again, in the hope that the updated list fixes the problem by itself.
This can be very useful at times, such as when you add a source for packages in your /etc/atp/sources.list, or when the package index files have been updated.
so it's just magic
long robin
days without sRGB conchfusion in 
: 1 0
heavy cipher
even though the s stands for shrimple
long robin
(unrelated) it immensely triggers me that GL has built-in dithering state in the core profile and it's enabled by default
I wonder if I can make a low color depth framebuffer with glfw to see if this does anything
btw the vulkan spec does not mention dithering a single time
long robin
mfw I looked at the spec without extensions
wait, I was looking at the spec with extensions
what is the ext called?
heavy cipher
mfw when tfw
long robin
yfw
heavy cipher
long robin
why isn't that in my pdf ποΈποΈ
long robin
I also couldn't find some other extensions on it
heavy cipher
ong no cap or some sissy standard swear?
long robin
the former
heavy cipher
fr
long robin
ah, I shrimply didn't look hard enough
heavy cipher
while you were writing fwog i was opening the spec
long robin
oh yeah, the number of pages doubled
someone should make an annotated version of that spec that shows the gpuinfo page for each extension
that way my lazy bum doesn't have to look it up myself
heavy cipher
VK_EXT_lazy_bum
long robin
would it be crazy (or bonkers, even) to think that type safety could be improved in VkRenderingInfo if color attachments had a type separate from depth/stencil attachments
const VkRenderingAttachmentInfo* pColorAttachments;
const VkRenderingAttachmentInfo* pDepthAttachment;
const VkRenderingAttachmentInfo* pStencilAttachment;
kinda spooky how switching from a shader blit to a regular API blit adds an extra 1ms to this pass
guess that's just a good ol' 
moment
long robin
would it be crazy (or bonkers, even) to think that type safety could be improved...
added this and it seems reasonable so far π
long robin
I'm going to pull a VK_EXT_depth_clip_control and let users change the depth range, but not the origin
heavy cipher
finally [-69, 69] rendering
long robin
more like [69, 420] rendering
but yeah it only lets you choose [-1, 1] or [0, 1] I'm afraid
heavy cipher
long robin
ok, I'll add something to insert code that performs the remapping in the vs
long robin
@heavy cipher is the idea of this to allow users to define their own configuration before including vuk headers (or maybe they define these globally)? I'm finding a need to add something like this to mine
https://github.com/martty/vuk/blob/master/include/vuk/Config.hpp
I have a feeling it would be pretty deranged for the user to put literal #defines for this stuff in their files
heavy cipher
and horrific
long robin
I suppose it works with glm because that's a header-only lib
long robin
inb4 odr
heavy cipher
these should be defined in cmake
long robin
confirmed
pretty sure this is an ODR violation waiting to happen, now that I think about it
#define GLM_FORCE_DEPTH_ZERO_TO_ONE
#include <glm.hpp>
precisely
long robin
too bad that's super not-transparent to people reading the source of the application with the define
one might even say it's opaque
heavy cipher
but i won't
shell inlet
pretty sure this is an ODR violation waiting to happen, now that I think about i...
literally me once
and it was hard to find too
in the end I made a single header that includes glm consistently
golden schooner
glm = good luck maffs
long robin
in the end I made a single header that includes glm consistently
that works, but I think the way of using compiler defines is better for ensuring you never screw it up (e.g., by forgetting to include the special header)
shell inlet
in msvc you have to open the properties to see the definitions and it's less comfortable for me, especially when there's a one field for all defines
you can't search for it quickly to check if it's there
long robin
hmm yeah .slns are annoying to work with
shell inlet
so I generally make a header per lib to ensure consistency with that
cmake is probably making this easier
golden schooner
you can't search for it quickly to check if it's there
you can outsource alot of things into .props/.targets files, but yeah its a bit inaccessible in vs
shell inlet
you can outsource alot of things into .props/.targets files, but yeah its a bit ...
property sheets?
I use them to quickly change paths to dependencies whenever I set up the project on another pc
long robin
(cmake) how would I use target_compile_definitions to create a define with a token string, e.g., for implementing
#define FOO bar
all I see are ways to do what is essentially equivalent to
#define FOO
heavy cipher
vuk time
heavy cipher
</vuk time>
long robin
actually, cmake doesn't like this syntax
target_compile_definitions(04_volumetric FWOG_DEFAULT_CLIP_DEPTH_RANGE=Fwog::ClipDepthRange::ZeroToOne)
teehee I forgot to put PUBLIC
heavy cipher
putting the g in oof
long robin
how do I make a dependency in cmake compile with a definition
one of my examples needs to define a certain config setting for fwog, but it's not being propagated to fwog
I thought public scope would do it, but no
heavy cipher
how are you doing it
long robin
this is the whole cmake definition for the example that I'm trying to make work
add_executable(04_volumetric "04_volumetric.cpp" common/Application.cpp common/Application.h common/SceneLoader.cpp common/SceneLoader.h)
target_include_directories(04_volumetric PUBLIC ${tinygltf_SOURCE_DIR} vendor)
target_compile_definitions(04_volumetric PUBLIC GLM_FORCE_DEPTH_ZERO_TO_ONE FWOG_DEFAULT_CLIP_DEPTH_RANGE_ZERO_TO_ONE)
target_link_libraries(04_volumetric PRIVATE glfw lib_glad fwog glm lib_imgui)
add_dependencies(04_volumetric copy_shaders copy_models copy_textures)
fwog is not seeing FWOG_DEFAULT_CLIP_DEPTH_RANGE_ZERO_TO_ONE when it compiles
I'm guessing this is the wrong place to put the define
long robin
ye
then my whole setup for the examples is facked
because I put all the examples in a subdir that fwog includes
heavy cipher
<vuk time>
long robin
the problem is that only one of the examples needs to define this thing
which basically means I need to somehow compile fwog twice
long robin
idk the difference
heavy cipher
i mean
long robin
here is how it currently looks in my config.h
#ifndef FWOG_DEFAULT_CLIP_DEPTH_RANGE_ZERO_TO_ONE
#define FWOG_DEFAULT_CLIP_DEPTH_RANGE_NEGATIVE_ONE_TO_ONE
#endif
that looks like an override to me
(the first thing I posted was indeed not an override)
heavy cipher
call fwoggy_moggy_change_depth_range_pls_for_me_idk_about_the_default(0, 1)
in the example that needs it
long robin
le sigh, guess I'll be doing everything the hard way
heavy cipher
with the chisel
again, why do you want to change the default?
is it not possible to change the depth range via the api?
long robin
because I have it in the viewport struct (again, copying vulkan)
and tl;dr being able to set a default allows more situations in which the user doesn't even have to fill out the viewport struct themselves
heavy cipher
thats fine in general, but i don't see why you'd need to change the default for the example
long robin
I didn't want to write 10 loc π€°
heavy cipher
men would rather redesign the entire example buildsystem than write 10 loc
long robin
no π§’
kinda annoying how you can't easily find the OP of a forum post
I don't want to scroll up 8000 messages to see what deccer first wrote in #1019740157798273024
even the "edit post" button on my own post doesn't show me the text, just some random meta stuff
golden schooner
thats annoying me as well
scrolling up in a large channel is a nightmare, and search within forumchannels/freds is not really working
long robin
the fact that the swapchain is a super duper special thing hidden behind framebuffer 0 (and you cannot access its textures) is so annoying
in gl
heavy cipher
ngl
long robin
i ngl
oh well, what's some more magic stuff that only applies when you are rendering to the screen
heavy cipher
well rendering to the screen is not really speshul at all in vulkan
heavy cipher
fwog with dxgi interop when
long robin
hmmmmmmm
golden schooner
the fact that the swapchain is a super duper special thing hidden behind framebu...
heh i had the same thought few weeks ago
long robin
I'm going to copy Vulkan and have sRGB images automatically enable framebuffer sRGB
Then, of course, I'll add a special flag to set it for rendering to the screen
Reasons to use Vulkan
- AMD tooling
- the swapchain isn't a special child
brisk narwhal
soonβ’οΈ Jaker shall be converted
heavy cipher
Reasons to use Vulkan
- AMD tooling
- the swapchain isn't a special child
- cooler color (should you lose the MVP vote)
final cove
easily best role color, the vulkan color scheme is easily khronos's best
brisk narwhal
red amdβ’οΈ
shell inlet
basically, my thingy does not feature throughput like that, which is why I suspe...
did you ever do anything about this?
long robin
I did not
I'm going to act like I had a valid reason and forgot what it was
I think the problem was that I didn't know the math to combine color with beer-lambert, so I just gave up
With white fog it should be fine I guess
shell inlet
with beer-lambert hmm
I mean that's just a law of how much radiance goes through a homogeneous media if I'm not wrong
so it should be color*beer
the usual thing, just like surface albedo
long robin
hmm perhaps
that doesn't seem right to me actually
at least the way I'm thinking about it
I'm taking fixed steps through a volume, so I don't want to multiply beer and color every step
Otherwise the throughput quickly drops to 0 if the fog isn't white
shell inlet
fixed steps basically means you have a scattering event every iteration
normally it's stochastic
you have those fixed
I see no difference other than possible aliasing instead of noise being in the result
long robin
I need to review the math I do at each step
shell inlet
beer-lambert combines out-scattering and absorption into one law
that's why you sum scattering and absorption and get extinction attenuation coeff to feed into it
also I think it's only supposed to model liquids
hm maybe it models liquids only when used as is
without integration
and otherwise works for gases too
long robin
This is what I do at every step of the ray march
densityAccum += froxelDensity * stepSize;
float transmittance = beer(densityAccum);
// 10*stepSize makes the accumulation independent of volume size and depth distribution
inScatteringAccum += 10 * stepSize * transmittance * froxelLight;
uh froxelLight is how much light is being emitted at the current step's location
froxelDensity is the amount of participating media
shell inlet
the difference between doing it stochastically and fixed is that you're not doing monte carlo but riemann sum
still integrating
long robin
ye
shell inlet
ok let me think
long robin
and otherwise works for gases too
I've seen it used in cloud rendering, so it must be somewhat correct
long robin
Absorption is used to attenuate the color of the surface when the fog effect is applied to the image
Uh and I think it's poorly named because I just multiply the surface color by absorption
Wait no it's called transmittance
I got confused
One thing I realized is that this pass has no notion of the color of the fog (although it could)
long robin
it's a float
shell inlet
and you should accumulate attenuationAccum += absorptionCoeff + scatteringCoeff; and attenuationAccum should be a vec3 value as well as absorptionCoeff which would give color to your fog
https://en.wikipedia.org/wiki/Attenuation_coefficient#:~:text=The attenuation coefficient of a volume is the sum of absorption coefficient and scattering coefficients%3A
https://en.wikipedia.org/wiki/BeerβLambert_law#:~:text=The BeerβLambert law can be expressed in terms of attenuation coefficient
this basically states that attenuationAccum = absorptionCoeff + scatteringCoeff and that you can integrate this and then feed to beer law
so secret to colored fog is wavelength-varying absorption
but since we do rgb we also do the usual assume each channel is a wavelength approximation
and use rgb vec3 coefficients
err any color should naturally arise from wavelength dependence
I guess your coefficient is then a function of wavelength and not a constant
for rgb you could say we instead separately do 3 integrals per channel
I guess color*beer was a stupidest thing I could have said
perhaps scattering may also vary based on wavelength
idk lol
should be something like this
I guess
although wikipedia says that using Lambert's law is more proper with this specific formulation
The BeerβLambert law can be expressed in terms of attenuation coefficient, but in this case is better called Lambert's law since amount concentration, from Beer's law, is hidden inside the attenuation coefficient.
long robin
alright, I'll take a few minutes to read through this
shell inlet
here's the sampling function in case you want to switch to monte carlo integration
though you'll need woodcock tracking algorithm to properly integrate with heterogeneous media
there might be leftovers in those graphs that I forgot to update
but only in comments
long robin
https://www.desmos.com/calculator/xzey8iwmzz
this graph is visually pleasing
shell inlet
ikr I'm still playing with sliders rn
so what do you think is this doable to have a single vec3 attenuation map instead of density and color that you have
I mean you don't even have density in lambert's law
long robin
yeah it should be doable
well, right now I have a density + color map
but only the density is visible in the ray marching pass, currently
shell inlet
there is a formulation of beer's law with density I'm actually looking into it now
naah that thing has way too many physical parameters to be of use
I'd instead use single attenuation map
and if someone wants to use physical values they'll have to use mass attenuation coefficient
long robin
the downside of having vec3 attenuation is the higher bandwidth+memory cost versus just assuming white fog
in most cases white fog is an accurate assumption, I hope
shell inlet
most fog is made out of water hopefully
long robin
I think that doesn't matter too much for fog since the amount of water in the air is relatively low
but it does matter when your ray is going through 100% water
shell inlet
yeah
shell inlet
https://tenor.com/view/smoke-pollution-car-gif-11002892
that's a weird fog I hope it's not 99.9% carbon
by the way
linear attenuation coefficient = mass attenuation coefficient * density
the formulation we use is using LAC
long robin
what is MAC
long robin
i c
shell inlet
there are tables for MACs out there, could not find any LAC tables
per element
also for photon energy
could be probably rewritten in terms of wavelength
because photon energy is basically two constants divided by wavelength
then you could integrate color matching functions and get physically based RGB MACs for a set of elements like dihydrogen monoxide and get a set of LACs for your fog after multiplying it with density
yes I find it funny to call water by it's long ass chemical compound name
long robin
everyone who consumes dihydrogen monoxide dies
shell inlet
true
shell inlet
are you going to give a shot at implementing discussed way to make colored fog?
shell inlet
I see, well sadge
thought I'd see frog cast green shadows when you implement it
fyi I still can't just fork it and code it myself
cuz busy got best of me
so only desmos coaching for now
I am writing dreaded winforms code and using firebird ado net in C# as we speak
long robin
what should I call the bit for enabling GL_FRAMEBUFFER_SRGB when writing to the default framebuffer?
struct SwapchainRenderInfo
{
...
bool enableSRGB = false;
};
enableSrgb would fit my naming convention better, but the fact that it's the opposite capitalization of sRGB is unsettling
golden schooner
the latter is fine
long robin
I don't even know if enable is the right way to describe this
golden schooner
in the context it should be fine too
long robin
vulkan doesn't have an equivalent because all sRGB images have this behavior and you don't need a weird enable thingy
golden schooner
bvecause you can toggle it
ye unless you have a typesafe way
if you had a SrgbSwapchainRenderInfo and a non Srgb one
long robin
I'm forcing framebuffer srgb to be on all the time except here
if you don't want srgb behavior, use a texture view
except obviously the swapchain is special
long robin
it is gl{Enable, Disable}(GL_FRAMEBUFFER_SRGB)
but for that to do anything, you also need an srgb image to write to
which can be a texture view
golden schooner
ok
long robin
therefore, it's pointless to expose GL_FRAMEBUFFER_SRGB except in this one spot
golden schooner
can you have 2 BeginSwapchainRender
one with the info object which enables srgb, and another one which doesnt
long robin
why would I make a new type when I could just add a bit to the existing one
remember, SwapchainRenderInfo is already a special thing specifically for rendering to the screen
golden schooner
so that you d ont accidentally create the one with the wrong bit set
just finking out loud
long robin
I'm not convinced
golden schooner
otherwise the enableSrgb is totally fine
long robin
either way you have to type a single thing to get the behavior
golden schooner
#1019779751600205955 message
#1019779751600205955 message
long robin
I have a new idea
what if I don't expose this at all
force srgb to always be on, then the user can control it via the windowing system
golden schooner
when glfw's bit is set you mean?
long robin
yeah
long robin
I don't know if that specific glfw hint is a hard requirement
golden schooner
but it kinda makes sense
long robin
it's not a hard constraint, but I imagine it would listen
golden schooner
we could check the sources
long robin
yeah
golden schooner
so if you want srgb on, you WindowCreationInfo it in there
same could be applied to multi
long robin
it's probably not common to have to change the srgbness of the default fbo
golden schooner
but people enable it anyway?
long robin
I mean changing it more than once during the lifetime of a program
specifically for rendering to the default fbo
or ever, actually
golden schooner
there is always a first time for anything π
long robin
I guess if the window is not capable of srgb, nothing will change by exposing a bit to control GL_FRAMEBUFFER_SRGB
long robin
same could be applied to multi<a:shrimple:1058909701271736381>
I don't think it's actually useful to have multisampling on the window
golden schooner
when would a window not be shrimplegb capable?
long robin
idk
but the point is, forcing framebuffer srgb to be on doesn't really have a downside
golden schooner
indeed
long robin
actually the downside is if the window always has sRGB and you cannot disable it
THEN you would have to touch the GL bit for it
golden schooner
when would you disable it?
long robin
sometimes you might not want the conversion (e.g., you do srgb encoding yourself)
golden schooner
π§
long robin
but if the windowing system forces srgb, then you're fooked if you can't access the GL bit
golden schooner
also true
long robin
I can't imagine you would be forced to have an srgb capable window though
golden schooner
if Fwog has docs, then this should go in there, that its on by default
long robin
after all, you can get non-srgb swapchain images in vulkan
golden schooner
vulkan is a special case
long robin
or is it?
I think gl is the special one here, and vulkan exposes the real capabilities better
golden schooner
then the question would be, what does vulkan do better here
is there something we could steal for gl/around gl
long robin
in terms of creating the actual window, pretty similar I guess
golden schooner
would it not be better if we renamed it to disableSrgb
hehe i see you uses one of the suggested repo names π
long robin
as in carry the enableSrgb flag in windowCreationInfo
the window stuff is not handled by fwog
glfw is already a pretty succinct windowing thingy
and it's not too crusty
I don't want to make another useless glfw wrapper π
golden schooner
ye i didnt think you would
long robin
VkSurfaceFormatKHR chooseSwapSurfaceFormat(const std::vector<VkSurfaceFormatKHR>& availableFormats)
{
for (const auto& availableFormat : availableFormats)
if (availableFormat.format == VK_FORMAT_B8G8R8A8_SRGB && availableFormat.colorSpace == VK_COLOR_SPACE_SRGB_NONLINEAR_KHR)
return availableFormat;
// fallback if preferred format is unavailable
return availableFormats[0];
}
ok but why do I need to check if an srgb format is srgb
golden schooner
mayhaps not needed
or because vulkan has a buttload of other formats too which you dont want to support here
long robin
that seems more sane than the dxgi way of supporting hdr monitors that I read about
VK_FORMAT_R10X6G10X6B10X6A10X6_UNORM_4PACK16_KHR
golden schooner
: )
long robin
lol I see you retracted your previous statement
VK_FORMAT_G12X4_B12X4_R12X4_3PLANE_444_UNORM_3PACK16
golden schooner
we also dont support hdr/>60fps screens out of the bogs
long robin
supporting hdr in gl means adding dxgi interop
golden schooner
R10G10B10A2 is not enough?
golden schooner
me to
golden schooner
is that what RGB10A2 would do if that was my final fb?
long robin
I don't think glfw can give you an HDR image
golden schooner
i see
long robin
golden schooner
i always thought you tell the gpu driver control panel "here do 10bit for hdr, you know?"
ah
long robin
you also want a floating-point swapchain so you can express values outside [0, 1]
which in turn means having to change the tonemapper in your engine
it's quite a process
golden schooner
makes sense
funny enough not a single PR (open or closed) with "hdr" in it
sdl doesnt handle this either, neh?
long robin
the second issue I linked is basically a fake PR
golden schooner
ye
long robin
maybe the HDR ecosystem will suck a bit less in a few years
golden schooner
heh
long robin
apparently some people finally got experimental HDR working on Linux like a few weeks ago
golden schooner
its not just 1 standard i suppose but 5 + vendor wars + driverisms
long robin
yeah and that sucks
apparently the "one solution" is to query some target luminance value and use it in your tonemapper
then it will just work for all HDR formats
I'm horribly paraphrasing some presentation I saw
golden schooner
or provide a trackbar for a user with the label "move around until it looks good to you"
long robin
#opengl message
For best results in HDR the tone mapper must understand the output luminance
range of the display.
golden schooner
ah interesting
that thing is also almost 6 years old
HDR/colorspace-in-general is one of those deeper rabbitholes where you actually need help to find your way back
long robin
yes
I found that one college actually offers a degree in color science π
https://www.rit.edu/study/color-science-ms
too bad it's an american one so it costs literally $50k
golden schooner
i watched a cppcon? talk yesterday about "what is an image" he touched colorspace for a minute
long robin
"hello. color space is a rabbit hole. watch out. bye"
golden schooner
hehe about virtual colors too π
long robin
I found that one college actually offers a degree in color science π
<https://w...
apparently they have an actual color lab there which seems interesting
it's kinda hard to learn about color online except the very basics
pages like this do not spark confidence within me
https://en.wikipedia.org/wiki/CIELAB_color_space
golden schooner
"ff"
long robin
what does ff mean
long robin
ah
golden schooner
is some latinism iirc
long robin
ew nvapi
golden schooner
i like that theres only 1 slide for linux at the end, without any explanation, but RGB10A2 π
i also wonder
would NvApi work with AMD cards?
by chance
mayhaps not each and every feature
long robin
some features of nsight work on AMD still
so there is precedent
ah crap I just noticed that my volumetric example was being double srgb-encoded ever since I refactored it π
no wonder the new image for it looks so much brighter than before
golden schooner
: D
that reminds me what i wanted to do the past days
trying to reproduce this beautiful thing
long robin
welp, seems like I get an srgb-capable framebuffer from glfw no matter what
so I suppose I'll have to expose the ugly flag in SwapchainRenderInfo
long robin
I thought about the weird pow(color, 2.2) transform teardown does and it actually makes sense
it's just the (approx) srgb->linear transform
I guess the only crime is that they aren't using an srgb texture
time to remove the unhinged srgb rant from my post
heavy cipher
rip srgb warcrimes
shell inlet
it's just the (approx) srgb->linear transform
wait you didn't know?
long robin
wait you didn't know?
I guess you could say I was having a moment
It's just so weird that they wouldn't use an srgb texture that it confused me
shell inlet
it is weird but people sometimes do this for some reason
there isn't even a guarantee that all color images are encoded as srgb
most of them are, so it's more or less valid, but then 2.2 is a coarse approximation too which is bad
my guess is that people don't know you can use srgb formats
also I think shadertoy doesn't do any srgb conversion so you need to do it yourself
long robin
yeah
shell inlet
and maybe it somehow causes more people to believe that you need to do color management manually
did you look into PCSSM yet?
long robin
the one with the blocker search?
long robin
oh okay it is
long robin
did you look into PCSSM yet?
so the answer to this is yes
long robin
@golden schooner thoughts on this?
https://github.com/JuanDiegoMontoya/Fwog/issues/52
golden schooner
<@194502965749350400> thoughts on this?
<https://github.com/JuanDiegoMontoya/Fwo...
thats quite funny
i just read the first sentence and was finking what you put under 1)
i think thats also what i would go with
shader reflection is a pain in the ass
golden schooner
hmm i had another thought
while taking a shower π
what happens if you issue more glBindTextureUnit/glDrawXXX within the same pipeline run
would it make sense to introduce some sort of renderpass construct, which is the thing keeping track of bound resources
long robin
I tried to think of something kinda like that, but didn't get far
trying to use vuk as inspiration ofc π
golden schooner
: )
i was just finking without any vk ballast in mind, since i have 0 idea what how vk is to be used
shell inlet
so the answer to this is yes
don't want to implement it for gltf demo?
long robin
what if I implement UE5's ray traced shadow maps instead
shell inlet
aren't they broken in some less subtle way than pcss
long robin
ctrl+f "limitations"
https://docs.unrealengine.com/5.0/en-US/virtual-shadow-maps-in-unreal-engine/
shell inlet
but this is what I'm talking about, why are you linking it?
long robin
because you're asking about what artifacts they have, so I linked you a thing showing what artifacts they have
if you already knew, then idk why you would be asking
shell inlet
I was referring to how this artifact may be worse than what pcss has, although pcss is less physically plausible
long robin
why do I not see GL_MAX_IMAGE_UNITS on here
https://registry.khronos.org/OpenGL-Refpages/gl4/html/glGet.xhtml
the spec does not say which glGet I can use to find MAX_IMAGE_UNITS
however, it does say this
Image units are numbered beginning at zero, and there is an implementation-dependent number of available image units (the value of MAX_IMAGE_UNITS).
heavy cipher
tired: glGet
wired: curl gpuinfo
long robin
I was looking at gpuinfo before all this
it doesn't say which glGet to use though, but I suppose I can guess educated-ly
hehe example 5 now draws nothing since I removed binding state leakage
honestly quite khoronic
https://github.com/JuanDiegoMontoya/Fwog/blob/main/src/Rendering.cpp#L162
golden schooner
the docs are missing a lot of love
golden schooner
honestly quite khoronic
<https://github.com/JuanDiegoMontoya/Fwog/blob/main/src/...
what about InvalidateResourceBindings?
long robin
I think they both work fine
long robin
(posting so I can copy the image)
long robin
I merged that cleanup a few weeks ago
now I'm just working on the teardown teardown (soomβ’οΈ)
I'll let you guys review it
golden schooner
ah another review?
golden schooner
the write up i ...... ah
long robin
I presented it in gpvm already when it was like 80% done, then winged the other 20%
the recording is on their channel
it gave me a good idea of what was missing, common questions people had, etc.
golden schooner
i watched the vijeo
not really understanding everything, but its interesting stuff π
long robin
I probably flubbed the explanation for a lot of things π but I blame people for not asking enough questions in that case
golden schooner
nah not because you explained things not well
i know too little about those voxelisms
well, mayhaps because of too little questions too π
long robin
the only thing you have to understand about these voxelisms is that there is a method (DDA) that allows you to trace though a grid and visit every voxel the ray touched
golden schooner
i also have not used, and had no use for it yet
maybe enginekit shall receive a voxel exshrimple too one day : >
shell inlet
jaker pleaz
local man dies trying to convince a graphics programmer to implement a pbr feature story at eleven
long robin
@golden schooner new π¦ dropped
https://tenor.com/view/shrimp-shrimp_-donowall-shrimp-donowall-shrimp-twitch-gif-19747232
heavy cipher
days since sRGeBanigans: 0 0
long robin
teardown teardown is getting kinda long
3400 words apparently
ms word is kinda convenient actually
@heavy cipher have you considered using chatgpt or ms word to proofread your posts
or do you prefer only using monkey labor for that job
using word to help make minor edits was pretty quick
argh I still have 7 sections left to write though π
heavy cipher
or do you prefer only using monkey labor for that job
I use unpaid monkey labor for bonding purposes
golden schooner
long robin
I'm too slow laddies/lassies
#gaming message
long robin
I think I'll put a meme in my post to commemorate being too slow. I'll take suggestions btw
Hey guys, my new Teardown teardown is here
golden schooner
you should publish yours anyway