Kakadu

[marble basin]

: )

[astral hawk]

OK, successfully avoiding macros now

Also added the ability to override an already #defined feature with a new value

This should cover all needs I think

Time to get back to actual GL work

[astral hawk]

Blending

This whole depth/stencil/blend mess is still hard for me to grasp my head around as it was in 2010s for me

I know that OIT is a mess on its own but combine that with these outlines for example

There are many combinations and getting it to work right for all cases is a big challenge

For this reason alone, I think games nowadays opt for non-stencil solutions for outlines

Anyways

From this angle the foremost window is depth-blocking the one after it

Tutorial is planned for this to happen in LOGL

The solution is to of course order the transparent objects

I'll add that and mark this chapter as done

[astral hawk]

Fixed

[marble basin]

now lets see paul allen's side (view from the other side to see if transparency is still working :D)

[astral hawk]

I'd rather not :p

Let's see

Seems like it's working

Do you know what's not working?

My winding orders

That's what

I knew I f*cked something up when I was converting those cube positions/uvs/normals etc. from LOGL's RH to my LH

Enabling back face culling yields:

Front right and top are OK

The other 3 are not

[rustic belfry]

LH coordinate system pain is good for the soul though

It builds character

[astral hawk]

Definitely

Although mine is not that uncommon I think

Unity uses the same one

It's rooted in Direct3D I think

[marble basin]

: >

[astral hawk]

Positions are fixed

Onto the other bullshit

Hmmm it seems I have cubemap uvs for the cube defined too

How/why I don't recall

Maybe logl used these in the early chapters?

Anyways I'm not fixing that

Positions & uvs were easy: Copy the working faces vertices to the not working opposite face, then swap the 2nd & 3rd vertex of each face.

Cubemap, not so much

2 chapters later, I'll be working with cubemaps anyway

I can fix it then

Normals need no fix

So does vertex colors, which I don't care about neither

I set CCW as the front face, as most models use that convention I think (actually, DCCs use that)

[rustic belfry]

CCW is incorrect for LH as far as I understand it

I have a left handed coordinate system, and its clockwise winding order

https://github.com/btipling/foundations/blob/main/src/foundations/rhi/rhi.zig#L54

you're like going to have to negate all your surface normals if you're going counter clockwise with your vertices in your tangent math or subtract your vertices in the opposite order that you're winding to get your tangents

hold your left hand up

curl your fingers and stick your thumb out

point the thumb in your direction

which way are your fingers curling, clockwise or counterclockwise?

[astral hawk]

This exercise will always yield CW for LH and CCW for RH

[rustic belfry]

I set CCW as the front face, as most models use that convention I think (actually, DCCs use that)

[astral hawk]

The helmet model works fine for example

[rustic belfry]

you have to convert those models into your coordinate system

not hack in the wrong winding order into your own coordinate system

I do this in my shader

[astral hawk]

That's what I did though

When loading models with glTF

[rustic belfry]

https://github.com/btipling/foundations/blob/main/src/foundations/shaders/vertex_xup_wavefront.glsl

[astral hawk]

fastgltf

[rustic belfry]

you shouldn't be setting CCW if you have LH imo

[astral hawk]

Same for normals

[rustic belfry]

if you have to there's a transformation missing

I think you have a RH then

[astral hawk]

Let me make the default front = CW and try to see how the helmet model holds up

[astral hawk]

X right, Y up, Z forward (as in towards the screen)

[rustic belfry]

yes thats LH, but your normals and winding order are RH it seems

I'm not sure!

[astral hawk]

This is the current setup, I'm going to set the first line to CW

[astral hawk]

Neither am I

[rustic belfry]

yeah that's RH

the thumb exercise for LH shows CW

[astral hawk]

I didn't change anything yet, here's the current state

And the inside

Back faces are effectively culled

[rustic belfry]

sorry to cause you problems though, if this works for you idk I'm new to all this myself and don't really have any business correcting anyone, it's just at odds with my own LH coordinate system and that's why I said anything

[astral hawk]

No no it's all fine, I'm trying to understand it myself too 👍

Sanity check by the way

I don't think these are incorrect

[rustic belfry]

so face culling happens in clip space or NDC, at which point you're in RHS, my MVP transformation in my world takes the Y up RHS vertices from wavefront object files -> model space (wavefront obj) -> X up coordinate transformation -> world space transform -> view space -> Y RHS transfor & perspective transform into clip space

if you don't have a transform like I do that takes your models into your space that fits in where X up coordinate transformation mine is then you're just passing in the RHS vertices through the transformation

and you have to hack in the wrong winding order for that reason imo

I have to transform the normals with the xup transform also

[astral hawk]

I do though

[astral hawk]

This essentially does that

There's also code below it which does the same for the normals

So effectively, when I load a model, it's model space coordinates are already transformed into my engine's coordinate system

Which is x right, y up & z forward -> LH

I get your point though

If a model had CCW front facing triangles in it

After said coordinate system transformation

Those triangles should now be CW front facing

This may have to with how I do projection

My projection matrix is set up so that it is LH after the projection too

Wait

Isn't this by convention? What I mean is

You can decide which face is "front" by issuing glFrontFace( CW or CCW )

And you also decide which face is culled via glCullFace( front, back or both )

[marble basin]

its a little conchfusing

[astral hawk]

Indeed

[marble basin]

one defines the winding order

the other the culling behaviour

[astral hawk]

This also f*cks it up probably

[marble basin]

and you can disable it

[astral hawk]

When my Z is forward (into the screen) for example

What is a "front face"

assuming CW or CCW

[marble basin]

OpenGL's default is CW and back face culling

[astral hawk]

Yes

[marble basin]

i would just go with that

RH or LH shouldnt matter, its just how the coordinate system is "oriented"

although RH is also default convention for opengl (can be any)

[astral hawk]

In my current setup

If I go with CW & back face culling

I can only see back faces

[marble basin]

the back plane (with the checker board texture) is not visible which is correct in that case

looks like your normals are inverted

[astral hawk]

I think you are effectively seeing the back of everything that's why it seems that way

Let me post a gif

[marble basin]

nah you shouldnt see the back like that

when the camera is moving around those become front facing fragments again

[astral hawk]

No matter where you look from

Everything is inverted right now

[marble basin]

yes thats wrong

everything pointing towards you is front facing, and everything pointing away from you (opposite direction) is back facing

and because we dont really see backfacing fragments they are culled, when back face culling is enabled

if you switch to CCW it will work again

[rustic belfry]

Yeah

Maybe leave it CCW sorry

Because its ccw after your perspective transforms

So CCW is correct

You have it right it is RH after your transformation

I am the one doing it incorrectly actually

My bad

[astral hawk]

I'll get back to you on this, I can't wrap my head around it atm

[rustic belfry]

I would listen to deccer and not me

In all cases

[astral hawk]

For example

This is my quad

Grass texture for reference

[astral hawk]

Notice that the winding order is Counter-clockwise here

Negative Z -> backward in my coordinate space

I need to set Counterclockwise for this to work

We can omit the model loading & the transformation that comes with it and focus on these cubes directly, as the cubes are created in-engine directly

Or the quad

Think about it this way: If the model had CCW front facing triangles in it

And glTF assumes right handed by default

X right Y up Z towards the user

And my coordinate system is the Z mirror of this

So I have to invert the Z

Which transforms the handedness yes

from RH to LH

BUT

The winding order did not change

It's still CCW

[marble basin]

those things btw, i encode into my "pipeline"

[astral hawk]

Hmmm

[marble basin]

https://github.com/deccer/EngineKit/blob/main/src/EngineKit/Graphics/Context.cs#L463

[astral hawk]

Too abstract for me, for now 🙂

And now I'm stalking your github

[marble basin]

nothing useful there

[astral hawk]

From a quick glance you seem to be getting traction these weeks

Hephaestus has recent commits

One last thing on face culling / winding order:

https://softwareengineering.stackexchange.com/a/88776

[rustic belfry]

If you rotate with a positive angle does it turn clockwise or counterclockwise for you?

Around each axis mine rotates clockwise

[astral hawk]

Same

[rustic belfry]

Those vertices are CCW, did you change this?

It’s kind of interesting how a game engine can have all this completely different. The winding order, how the engine does a cross product, and rotation matrices and world translation matrices can each be either left handed or right handed snd they don’t have to be the same. It’s sort of an artificial constraint to have them all be the same, but I think it will hopefully in my case lead to fewer issues.

You can actually be inconsistent in handedness from one cross product to another in engine code by inverting the orders of the vertices used in the operation

Because I calculate my cross products differently for different geometric models, like my torus, cone and triangle code each have their own tangent/surface normal code I have to be careful that they are all LH

[astral hawk]

Indeed

[astral hawk]

I edited that sentence yes, because I incorrectly wrote clockwise, then later edited it to be "counter-clockwise"

[rustic belfry]

Oh no I meant did you edit the vertices to be CW. I didn’t know you had edited your message

[astral hawk]

These are the cubes/crates (i.e., vertex data generated in-app, does not come from an external model) and that was the first time I posted screenshot of it I think

I never changed them during our cw/ccw conversation if I'm not mistaken

I changed them before the conversation started

Thinking they were wrong (and they were, at least in the sense that I can render everything without visual issues now)

Rendering to an offscreen Framebuffer & drawing that offscreen Framebuffer's color texture onto the default Framebuffer, on a full-screen quad

Wireframe view of full-screen quad

[astral hawk]

I should add wireframe/fill etc. drawing mode to RenderState, shouldn't I?

[astral hawk]

Gray-scale post-processing shader

I implemented Shader re-assignment on runtime to a Material

I'll also implement Texture selection

[humble sinew]

why is the window shaded

[astral hawk]

Gif exporting artifacts

I use ScreenToGif

[astral hawk]

I lied I implemented disco mode

[astral hawk]

I've been away (and sick) for a while but I'm back and there are updates

I'll update here

[marble basin]

wb

[astral hawk]

I integrated uniform arrays (in default block). I didn't think I would need it (I thought I'd put arrays inside UBOs too and it works) but it came in handy in a shader to use a regular uniform array, so I said why not.

Also added a new shader UsageHint (which is a comment that is parsed, utilized when the uniform is drawn to ImGui)

There were AsColor3 & AsColor4 before, I added AsArray

Used as such

This makes it so ImGuiDrawer displays this uniform as 3x3 matrix-ish

For example:

Added a new generic post-processing shader as LOGL does

Kernel size is a shader Feature (i.e., a #define) so it can be manipulated from cpu-side as usual

I'll post screenshots of some effects

Sharpen filter

Blur filter (not easy to see from this screenshot, and this is not a good way to blur imo)

Edge detection filter

Top sobel filter

Emboss filter

The wall does not have a normal map (it does have normals that are facing away from it but that's it). It seems emboss works really well in the absence of proper normal mapping, nice to know I guess.

For some textures at least*

Then I went on to implement the exercise on LOGL for framebuffers: Draw the scene in a rear-view camera

I did a bunch of other stuff I'll mention later on, but I did implement it

But there's a weird problem: It works well when rendered onto a quad on the default framebuffer (what the exercise asks to do basically), but I wanted to draw it into a separate ImGui window. It works sort-of; The light cubes are rendered weird

Zoomed view of the rear-view camera

Any ideas?

[astral hawk]

No problems when drawn to a quad on the default framebuffer

Too lazy (and hungry) to this right now

But I still did ...

Seems like ImGui shenanigans

I'll investigate later

Okay get this

The gray of the cubes

Is the same as the gray of the ImGui windows

Yup...

But why?

[humble sinew]

a lot of "laters" here that aren't later

[astral hawk]

That's because I have a pending bug that I'm trying to solve and I wanted to quickly get through other stuff to ask you guys here about the bug itself

[astral hawk]

Or did you mean that I implemented some stuff I said I'd do later and did it anyways

I didn't understand

[humble sinew]

no it was “don’t have time to investigate this with RD”… proceeds to investigate it with RD

“I’ll investigate later”… proceeds to investigate now

[astral hawk]

Yeah I have a bad habit of doing this and it costs me

[humble sinew]

yeah same

[astral hawk]

I have severe eye dryness and I just had an attack the other day because of this

[humble sinew]

sometimes if im in focus mode and working on a problem i can stay up until 5am trying to fix the bug

[astral hawk]

And had to get away from pc for a day

[marble basin]

is there a rogue .w == 0.0?

[astral hawk]

I’ll check it out 👍

[astral hawk]

Yeah that was it

My basic color shader was this:

#version 460 core

out vec4 out_color;

uniform vec4 uniform_color; /* _hint_color3 */

void main()
{
    out_color = uniform_color;
}

And it seems I send a Color3 from cpu side (haven't checked yet)

Added out_color.a = 1.0f

Fixed

[astral hawk]

Time to clean up and move on to the next chapter

I also read 2 chapters of GEA while I was away

I don't know if I ever posted my "curriculum" excel here

This is the main sheet

I've neglected updating the "Apply" column for some time now

"Secondary" sheet

"Misc" sheet (cropped because cherno one is long)

The courses/tutorials/books in Misc are for "resting"

rest-studying whatever you call it

3Blue1Brown's series (as well as Cem Yuksel's & some of Cherno's beginner/intermediate stuff) are nice to listen to while driving for example

After I finish these I'll prepare a second year for this curriculum or whatever this is

Will include Real Time Rendering etc.

I also have some shader/portfolio ideas I want to implement

[astral hawk]

I think I'll make the switch to ImGui docking branch today

[rustic belfry]

Great progress

[marble basin]

out_color = vec4(yourvec3, 1.0)

[astral hawk]

No I meant I added that line to test it

Actual solution is to of course send a proper Color4 w/ 1.0 as alpha to the shader

As the same shader can be used to render transparent colors if desired, so I didn't touch the shader.

(I also would do it as a one-liner too, if I wanted to modify the shader though 🙂)

Slow day

Yeeted Unity's texture preview window UI/UX

I should also yeet the image details text beneath the preview image (resolution, format etc.)

[rustic belfry]

did you assign a texture unit for each of those textures to show them in that list?

or does your shader have a uniform per texture, how does that list work? it's interesting

[marble basin]

all you need is an ImGui::Image(textureId, ...)

per image

[rustic belfry]

texture id being the texture unit/location?

[marble basin]

the name

glCreateTextures(GL_TEXTURE_2D, 1, &thatThingHere)

[rustic belfry]

oh

[astral hawk]

I really need to change those yellows

Not only do they look like shit

Text is unreadable as well

Also, I have to do some tinkering to get this to work properly; I quickly hacked this to get it up and running, by blitting the final result(s) into a framebuffer I call the editor framebuffer, and did ImGui::Image( editor_framebuffer_color_attachment->Id(), ... );.

This means I lose access to mouse/keyboard io temporarily; I either need to poll ImGui to get those working again (which may be more pleasant to work with than glfw, maybe?) or I need another approach & somehow keep rendering into the default frame-buffer.

I mean sure I can always not give a damn about all this; render into the default framebuffer as usual and dock windows on the fly, on top of the default frame-buffer, i.e., maybe lock at least 1 window to one corner of the main OS window, and start docking other imgui windows from there.

Not that different from what I did so far, except for the docking part.

ImGui laid out on top of the default (GL) frame buffer

But I think I'd like to have a central dockspace (as ImGui calls it) so that there is at least one (possibly empty) window

And having the viewport/scene whatever be just another window docked to that dockspace seems more natural

I'm open to ideas

[marble basin]

what 😄

i R confuse

[astral hawk]

Yeah I did a shit job explaining it

Question is this

[marble basin]

i got all the color stuff, but not the blitting and imgui shit

[astral hawk]

If I want to have an engine-like UI/UX, like Unity's for example, where there is a scene/viewport window, and other windows such as inspector/shader/material bla bla bla

[marble basin]

yeah

[astral hawk]

How would I go about getting the viewport ImGui window to work?

[marble basin]

then you just use docking

i am tinkering with the same problem

you are talking about resizing, right?

[astral hawk]

Should I just dump drawing to the default frame-buffer & render into non-default framebuffers all the time?

[astral hawk]

No no

[marble basin]

where one source is the actual window (in a game situation, editor is off) and the editor is on and you want to show the screen in an imgui window

ah

i render imgui into the default fb

and everything else goes into a fbo

[astral hawk]

Hmm so you don't use glfw/sdl etc. for the ImGui backend then?

[marble basin]

i do use glfw

my c# engine has a custom dear imgui backend to make use of my abstractions

[astral hawk]

Meaning the actual game/app GL stuff right?

[marble basin]

yeah

you usually render into several fbos anyway, and compose every renderpass into another

until you reach the final one, and that is just a texture you draw on a FST into FB0

[astral hawk]

Hmm

Okay

Then

In your scenario

Do you get mouse/keyboard info from ImGui or glfw? For in-game I mean

[marble basin]

dear imgui is hooked into glfw

(i think there is a counterpart for sdl as well)

[astral hawk]

Okay I understand finally

I was talking nonsense

[marble basin]

where you call the ImGui_Init_OpenGL and _Init_GLFWORSDLORWHATEVEr, i believe there is a param, a bool which means whether imgui subscribes to the glfw/sdl callbacks or not

ah 😄

if you write a custom backend, then you just handle it manually

and wire everything up yourself via io

[astral hawk]

of course glfw has the input and imgui polls that and provides its own mouse/keyboard input to the user.
The reason my keyboard/mouse io for the game stopped is because ImGui has focus and "consumes" input state, so the app can not get input data (because remember my game is now just a texture rendered in an imgui window)

texture/color attachment part of a frame-buffer I mean*

I'll keep messing with different options for a while tomorrow

And will get up from the PC for reals

Before lethargic busts me

Thanks for clearing it up @marble basin

Cheers

[marble basin]

🇳🇵

[astral hawk]

Hmmm I'm having trouble telling ImGui to not capture mouse io (or keyboard for that matter, probably, haven't tried yet)

While inside the viewport ImGui window, ImGui::GetIO().WantCaptureMouse should be false

But it is true

I tried this

But that flag doesn't seem to be working

https://github.com/ocornut/imgui/issues/4831

This may be similar

Haven't read it yet

@indigo quarry Sorry to drag you here but you obviously solved this in erhe. Can you give me some pointers?

How would I go about handling input in my "Viewport" ImGui window? As you wrote in your ImGui GitHub issue, I too want to utilize mouse (and keyboard) for the user to interact with the viewport, and I too "yield" if ImGui::GetIO().WantCaptureMouse is set (i.e., true)

[indigo quarry]

I can get back to you when I get home in couple of hours

[astral hawk]

No hurries, thank you!

[astral hawk]

This is probably not what I want in the long run though, what if I had a "Project" window (like Unity's) and wanted to drag an asset from there to viewport/scene? This flag would break that

I'll stash this docking stuff and work through LOGL in the mean time

[indigo quarry]

I added drag from content library to scene view a while ago

[astral hawk]

Nice

That's one of my goals in the near (hopefully) future too, but for now I'd be okay just to get input working again in my viewport

[indigo quarry]

Scene view in imgui window in erhe is here: https://github.com/tksuoran/erhe/blob/main/src%2Feditor%2Fwindows%2Fimgui_window_scene_view_node.hpp

[astral hawk]

Okay it seems I solved it

[indigo quarry]

I'm not sure how that interacts with drag and drop

[astral hawk]

For now, I just wanted to get input working again in my viewport ImGui window (where I just do ImGui::Image( frame_buffer_texture ).

I assume you meant this might stop working or interfere with drag/drop in the future

[indigo quarry]

In erhe, I use glfw, and custom imgui backend and renderer (based on glfw backend)

The glfw code collects all input events into a vector of class Input_event

These input events can be processed by classes derived from class Input_event_handler

more follows..

class Imgui_host is one such class

That is how ImGui widgets in erhe get the input events.

That is how the input events are taken from the glfw window and sent to imgui_host

Editor::tick() has this:

// - Update all ImGui hosts. glfw window host processes input events, converting them to ImGui inputs events
//   This may consume some input events, so that they will not get processed by m_commands.tick() below
// - Call all ImGui code (Imgui_window)
m_imgui_windows->imgui_windows();

// - Apply all command bindings (OpenXR bindings were already executed above)
m_commands->tick(timestamp, input_events);

m_imgui_windows->imgui_windows(); ends up calling Window_imgui_host::process_input_events_from_context_window()

class Commands : public erhe::window::Input_event_handler is another class which process input events, that is how things other than ImGui widgets typically get input events

I suspect the comment about ImGui hosts possibly consuming input events is wrong, I think they never consume input events, so they are always given to commands as well

[astral hawk]

Hmmm I see. I never interacted with ImGuiIO's addxxxevent APIs, so a lot of these fly over my head atm. Though these would come in handy when (if) I get to writing an actual io & event system.

Thanks for taking the time, much appreciated 🙏

[astral hawk]

I implemented runtime changing of Shaders of Materials some time ago.

I wanted it to warn the user via a warning log if the new Shader's vertex layout does not match any current Mesh's (or rather Drawable's but that's not important).

But there's a problem, OpenGL only reports active vertex attributes for a given compiled shader program. So my Basic Color shader for example only uses the position attribute out of the 3 attributes it is provided with (normals & uv being the others). That's because I re-use Phong.vert for Basic Color shader program.

So currently if I switch a Material using Basic Color to Phong, it complains about vertex layout mismatch, even though they use the same exact vertex shader (although compiled to different gpu machine code maybe?, due to other attributes not being utilized).

I think I'll just parse shader source to get the attributes

[marble basin]

vertex layout and material shouldnt be linked

[astral hawk]

They are not

[marble basin]

they are 🙂

let me explain

[astral hawk]

Please 👍

[marble basin]

"usually" you have material types, like Unlit, PBR, Translucent, FancyCoat, Fur, Glass or whatever

now each of those types kind of predefine what attributes you need, with regards to the vertex data

Unlit is probably just positions, normals and color, perhaps uvs too, you might use those for debugging purposes or geometry in the far distance like mountains you will never reach or so

PBR is positions, normals, uvs, tangents

Translucent, and the other shit idk what it entails, but something similar with more or less attributes

[astral hawk]

Sure

[marble basin]

your materials probably come in those "types" too, like "ThatHotLatexPlastic" or "ThatIronSheet" or "ThatFurCoat"

you also dont render all those materials in the same pass (using the same shader), you probably have your renderer do "render unlits first", "render pbrisms", "render alltransparentisms" etc and only then the vertex layout might change

that also means

when you render meshes, you usually have 2 kinds of meshes (and therefor 2 sets of attributes)

static mesh, basically all precooked by some content pipeline, preparing positions, normals, uvs, colors, another colorset perhaps, tangents and so forth

and skinned meshes, which have all the stuff as above plus all the bone and weights bs

[astral hawk]

All good so far 👍

[marble basin]

and when you go through all those render passes

you can disable/enable certain attributes, but the data is fed into the pipeline anyway (that can probably be optimized later down the road somehow)

now

[astral hawk]

This I did

[astral hawk]

This I did not

[marble basin]

phong or pbr or blinnphong is all the same

and doesnt matter what geometry you fed into the pipeline

what im saying is, you usually know before hand what vertex format/inputlayout is required for whatever renderpass

its usually not "totally dynamic and unknown and requires magic reflection which you have to handle in some obscure way"

[astral hawk]

Sure

[marble basin]

if you wanted to let your users of your engine implement a custom-new-hottest-shit-over-9000 then you could expose interfaces into your engine, where they have access to inputlayout creation, creating shaders, etc which they have to implement according to their plannet thing

[astral hawk]

I'll wait until you finish explaining to comment and ask questions

[marble basin]

i think im done

[astral hawk]

Okay so do I get this right? The usual method of handling the obvious and inevitable mismatch of Material vs Mesh (vertex layout) is to enable/disable specific vertex attributes?

I say inevitable because an object in a game may need to dynamically alter some of its material while the game is running, and those materials may not have the same vertex layout.

Let's go with an example

Kratos has a single-color arm-band

Goes to shop

Upgrades to fancy textured new arm-band

Which uses uvs now

previous material's shader did not

How is this handled?

[marble basin]

i never played this game

[astral hawk]

Any game character would do

[marble basin]

i think its utterly boring, liek any other souls like

yeah

[astral hawk]

blasphemy

[marble basin]

ah simple

[astral hawk]

The cinematography alone is astonishing, even if you don't like the game play

And visuals

[marble basin]

the new armband is now just part of meshes which are supposed to be rendered during the pbr pass, because its covered in gold foil or something

[astral hawk]

But we digress

Hmm ok but did the kratos model have already uvs baked in then?

[marble basin]

yeah

[astral hawk]

Do we now enable uvs?

[marble basin]

your kratos mesh

is made out of mesh primitives which have a material assigned, assuming gltf here, you can assume a few things like those primitives will have positions, normals, uvs and tangents possibly vertex colors if you also read that in

[astral hawk]

It was previously disabled I presume (back when armband was single color)

So it's "bake all the attributes this model's ever going to need" and enable/disable as needed as the material's change at runtime?

[marble basin]

when you load the model initially and that particular armband is just single color lets say

then you could assume also 2 things again

with PBR you can also make some sort of fabric material

and the material will just be looking as if its a colored piece of cloth of sorts

and you can change it on the fly to something else, metal looking

in that scenario both meshes will just be part of the pbr renderpass

if you decide to put on "solid-color-red" which doesnt care about normals or so then it (the meshprimitive) becomes part of the unlit renderpass

ah

i see now

let me think for a sec

lets assume some things

and think them through

vbo is filled with vertex data from kratos

probably contains positions,normals,uv, tangents

that is fed to the gpu

inputlayout will know about those attributes, therefore the vertex shader knows

vs forwards uvs and normals, and colors if necessary

and fs samples from textures and mixes with colors and shades with normals etc according to brdf

[astral hawk]

Sure

[marble basin]

now you switch the pixelshader

to some "simple solid color.fs"

which does not take in normals and uv

but still receives color

that should still work

// vs
layout (location = 0) out v_normal;
layout (location = 1) out v_uv;
layout (location = 2) out v_color;
...

// fs complex
layout (location = 0) in v_normal;
layout (location = 1) in v_uv;
layout (location = 2) in v_color;
...

// fs simple
layout (location = 2) in v_color;
...

[astral hawk]

This works yes, and GL does not complain, not even warnings etc.

I have 2 questions for 2 distinct scenarios

First scenario is no editor, release version of the game, models all have all their attributes baked in.
In this scenario, I don't think vertex shader attributes are ever going to change for a given mesh. Different FS may use different attributes coming from the vertex shader sure.

So actually this scenario is non-problematic and clear cut.

I don't have a question 😅

Second scenario is for the editor

You can assign different shaders to a material in a game engine usually

[marble basin]

yeah

[astral hawk]

And that material is on a mesh in some scene hierarchy

Unity warns when there is a vertex layout mismatch for example

[marble basin]

you can probably somehow derive instructions for some content pipeline, which is used to bake out final meshes later, according to what material was assigned

ah i see

[rustic belfry]

I am over dynamic shaders, I tried this a bunch of times and it always becomes a mess, handcrafted artisanal shaders are my future

[astral hawk]

I don't have dynamic shaders either, I don't recompile anything myself at runtime

[rustic belfry]

Ah

[astral hawk]

I just like the ability of an editor (such as Unity) to re-assign shaders to materials

Which is fundamental in my opinion

[rustic belfry]

I just stick materials in an SSBO

and have a uniform for material 😅

[astral hawk]

That's probably the better way of uploading material info to gpu 👍

But the issue still stands

[rustic belfry]

What issue?

[astral hawk]

Having to implement shader selection for a material in the editor

[rustic belfry]

I don’t thanks to the uniform

Oh you mean the lookup into the ssbo?

[marble basin]

no

[rustic belfry]

I see

[marble basin]

its about to make sure vs and fs match and the mesh feeds enough information into the vs via the input layout

[astral hawk]

Let's say you have a phong shader and pbr

[rustic belfry]

You mean different material

[astral hawk]

Yeah

[rustic belfry]

Yeah

[astral hawk]

You got it

[marble basin]

so that when you assign a blank white material, no pbr, no fur no nothing, make sure the mesh is rendered properly

[astral hawk]

This is a non-issue for the released version of the game/app

[marble basin]

as if it would when you assign it a pbr material with bumps and roughness and whatnot

[astral hawk]

Yes

[rustic belfry]

I would probably just write different shaders manually

[marble basin]

perhaps this thought helps: if you are trying to make a general purpose game engine editor, then yes, a warning and whatnot might be in order, but if you make an editor for your engine, which you use for your first one or two or three games, then dont bother, because you always know what renderpass requires what, or what material would go into what renderpass

[astral hawk]

Bump/roughness map etc. would initially be unassigned when you change from blank color shader to pbr shader for that material, you would assign textures to those and the editor/engine would render the new fancy graphics for that material

[astral hawk]

Yeah sure I know that but I still will do it because if you would have seen what I'd done so far for uniform introspection 😅

And parsing attributes are much easier than uniforms

[marble basin]

shader instrospection can possibly bite you in the ass, because unused attributes/uniforms or anything which doesnt contribute to the output, gets optimized away and will not show up in the reflected information

[rustic belfry]

Yeah I am not trying to make a generic reusable anything

[marble basin]

i was referring to fauder's fauderisms 🙂

[astral hawk]

I'm just trying to get shader assignment to a material working that's all. It does by the way, no crashes or anything.

But sometimes I don't know why the material is black etc. That's when the layouts of the pervious & current shader do not match. So I thought a warning could be handy

[rustic belfry]

I appreciate what fauder is trying to do here

[astral hawk]

You misspelled autism

[marble basin]

put your material in a category

and the category is what defines in what renderpass it will handled

[astral hawk]

Hmm

And what defines the category?

[marble basin]

"PBR Materials" "Fancy Coats" "Fur" "Translucent Materials"

then your solid color sash, can just go into PBR too, simply has roughness 0.5 and metalness 0, basecolor whatever, and an empty normal map (r = 0.5, g=0.5, b=1.0)

or you create a "Flat" category too

thats where all the lowpoly-esque materials go into

or other solid-color ones

but its really just base texture being solid color

[astral hawk]

👍

Thanks for the discussion as always

Now I have to do an IKEA run to please the other/better half

[marble basin]

enjoy 🙂

[astral hawk]

I'm back

I'm having a hard time to create time for studying these days

Hopefully that changes soon

A simple regex (which I totally asked chatgpt do debug for me) to grab the vertex layout from shader source

Was enough

And with this, I can call this BS done and get back to actual graphics study

[astral hawk]

What the hell

What the actual f*ck is up with cubemap coordinate space in GL

Okay I think I get the gist of it

I just have to not flip the Y when loading via stb, because while the regular uvs for opengl use v = 0 -> bottom and v = 1 -> top, the cubemap uv space has the opposite behaviour.

Also, cubemap uv space is left-handed, which coincides with mine.

I should just flip Y's when showing cubemap textures in the editor (i.e., ImGui::Image() )

Also, back faces should not be culled with cubemaps as we see the interior of the cube

And now comes the time where I move face culling settings into RenderState as well

[astral hawk]

I'll postpone Texture Viewer for cubemaps until I switch from glTexImage2D to glTexStorage2D, as creating views to individual cubemap face textures with glTextureView does not work with textures generated w/ glTexImage2D

[marble basin]

glTextureStorageXX you mean

[astral hawk]

Probably

[marble basin]

glTextureView works

you need glGenTextures for those unfortunately

[astral hawk]

How so

I already have a cubemap

[marble basin]

ask John

[astral hawk]

Created w/ this

[marble basin]

ah kk

[marble basin]

textureviews are separate texture objects

[astral hawk]

I would like to have ids for the underlying 6 face textures so I can relay them to ImGui::Image()

[astral hawk]

Sure

[marble basin]

yes, with texture views that works

[astral hawk]

I did this

And got the error I posted

[marble basin]

that looks correct

what does renderdoc say

[astral hawk]

I yeeted this from chatgpt by the way, to quickly get it up & running.

[astral hawk]

Let me take a look

[marble basin]

p[lease use the gl spec and not chatgpt 😦

[astral hawk]

One sec

spec is too verbose

I used chatpgt for the first time for gl related task today

Not good yeah

[marble basin]

chatgpt in general is not a good idea for coding stuff

imho

anyway, you are free to use whatever

[astral hawk]

Agreed

Though

It did give %99 correct regex today

So for those mundane (and abundant, i.e., not niche) subjects I think it's a nice tool to have in your belt

[marble basin]

regex101.com

[astral hawk]

But anything slightly complex, and it fails yeah

[marble basin]

i dont want to put time and effort in gpt's output to verify its not dreamed up, i just check good sources right away, like i did the past 20 years

[astral hawk]

Oh I forgot about that

[astral hawk]

Makes sense yeah

[marble basin]

if i need a text generator to provide dummy text or a letter to my boss, then llms make sense

[astral hawk]

If you know the domain area and can spot the errors, it's not that bad of a tool I think (but for mundane tasks)

The other day my sister needed a batch file for something

And cmd batch syntax is bonkers

It would have taken me hours probably to get the damn thing to do the simplest thing

Those for loops ...

Chatgpt gave a %90 correct answer

I removed 1 line of code and voila it worked

[marble basin]

i bet a simple google would have worked too 🙂

[astral hawk]

But so far these 2 are the only "successes" I had

[marble basin]

or cmd batch was not the right tool in the first place

anyway 😄

use whatever you like, and dont mention "gpt told me" then all is good

[astral hawk]

It's not that information on batch syntax is not easy to find but the language itself if really shitty, so the iteration to get it right would be at least minutes for me

[marble basin]

ss64.com if that site still exists it does

https://ss64.com/nt/

[astral hawk]

I recall this yes

Wish I didn't

[marble basin]

hehe

[astral hawk]

RenderDoc didn't find anything funny

No errors/warnings

Docs say this

Anyway, as I said, it's not urgent to implement a viewer for cubemaps for now

[marble basin]

are you using that somewhere?

[astral hawk]

Using what?

[marble basin]

GL_TEXTURE_IMMUTABLE_FORMAT

[astral hawk]

Not explicitly no, but I am using glTexImage2D in my Texture class (for the cubemap as well as regular 2D textures), and using glTextureView for the cubemap results in said error

Also messed around with refraction a little but not going to commit that

I'll clean up the codebase, push and call this (LOGL: Cubemaps) done

[marble basin]

hmm hhm

[astral hawk]

Geometry Shader chapter in LOGl was underwhelming visually, but not bad of course

I won't post boring screenshots of the normal visualization geometry shader

I skipped exploding vertices altogether as its elementary stuff at this point and nothing fancy

Time for instancing

Also, I might convert the Material* in my Drawable to a vector of Materials, so that I don't have to create an additional Drawable to apply an effect to an already existing Drawable.

Example scenario: Visualizing normals. Right now I need to create two Drawables, which share common Mesh & Transform, but have different Materials assigned to them.
First drawable is the regular one (renderedwith the Phong shader for example).
Second one uses a different Material using the VisualizeNormals vertex/geometry shader (and the BasicColor.frag for example).
If the Drawable had a list of Materials instead, I wouldn't have to create two Drawables.

Not urgent for now though.

I'll eventually get my hands dirty and work on a proper scene graph I think. This kind of stuff can wait until then.

[astral hawk]

Should I replace all DrawArrays/Elements calls with instanced ones?

I wonder if there's any performance drawbacks to always opting for instancing

[marble basin]

its literally up to you

ultimatively you want glMultiDrawIndirect

instancing doesnt make sense for single triangles

[astral hawk]

I heard about this but intentionally didn't check it out

As I create enough distractions for myself 😅

Hmmm

[astral hawk]

Do you know if LOGL ever covers glMultiDrawIndirect?

[marble basin]

it does not

although there might be a guest article about indirect draw

[marble basin]

ignore that

its fine to glDrawElementsInstanced with 1 instance

usually you render somewhat complex geometry, and not individual triangles

and ofc, when in doubt, profile

[astral hawk]

Wait isn't it saying the same thing

[marble basin]

yes 🙂

its not about api though

its about hardware

older hardware and drivers are "different" to modern hw and recent drivers

[astral hawk]

Makes sense

I should just finish reading the chapter first, before firing questions your way 🙂

[marble basin]

haha

[astral hawk]

Discord is banned in my wonderful country so I might not be online for a while

Or I might use vpn

[rustic belfry]

that's super lame

I misread that as discord banned turkey initially

anyway that really sucks I'm sorry, it's cool when you're around

[astral hawk]

Thanks, likewise 🧚‍♂️

Tl;dr of it is social id and password credentials of all citizens are leaked due to a vulnerability in turkiye.gov.tr and some people started to sell this info online and apparently they used Discord for communication as well.

3000 iq solution was to ban Discord…

[rustic belfry]

that's like banning the phone because people commit crimes on the phone

[astral hawk]

Yeah …

[astral hawk]

I was going to deep into integrating instancing into my Renderer

I did*

But then half way I realized something else

Shader recompilation is not as painful as I think it would be (due to state I'm keeping, mostly uniform & UBO info maps)

And voila

(Provided no-one modifies any uniform block glsl code @ runtime, which would be disaster currently)

By the way "Recompile Phong" button disappears upon clicking because they are kept in an std::unordered_map & it is removed then added again

I'll try to yeet a FileWatcher from somewhere so it can automatically recompile on save

That somewhere is of course https://doc.magnum.graphics/corrade/classCorrade_1_1Utility_1_1FileWatcher.html

[marble basin]

there is no state keeping

when you rebuild the shaders

[astral hawk]

For editor, there is

For the .exe, not

[marble basin]

no

[astral hawk]

I did not mean state as in GL state

[marble basin]

ah

i did 😛

[astral hawk]

Let's call it bookkeeping

Actually I think I literally named a class UniformBookKeepingInfo

[marble basin]

and a filewatcher is nothing but a thing looking at a file and check if modified date has changed

[marble basin]

nah

[astral hawk]

Yeah Win32 probably has something for it

[marble basin]

just use c++ std::filesystem

[astral hawk]

std has something for it?

[marble basin]

ye

https://en.cppreference.com/w/cpp/filesystem/last_write_time

[astral hawk]

Hmmm I use std::filesystem in my work related projects but didn't see anything related to it, but then again, I only use a little portion of that namespace

[astral hawk]

Ooo nice

[marble basin]

no need to hardwire ifdef WIN32 bs in

[rustic belfry]

neat, I want hot reloading 👀

[marble basin]

and re state

dont create "BookKeeping" classes

all you do when you reload a shader is, delete the program, create new program, reload shader text, recompile/link program and thats it

in your gameloop you will glUseProgram(thatprogram) and glUniform(xxx) or glBindBufferBase(UBO, whateverGlobalUniform) and then whatever other renderpass comes after wards as usual

[astral hawk]

The GL side of things is exactly as you proposed

[marble basin]

in the first line in your gameloop you check if shaders have changed, and reload if necessary

[astral hawk]

But to have material/shader inspector etc. I do some additional bookkeeping

[marble basin]

that is not bookkeeping though, thats just the normal state the editor has anyway

[astral hawk]

And you should do some minimum bookkeeping, to cache uniform locations for example

[marble basin]

thats not book keeping

[astral hawk]

Perhaps, I'm not %100 sure on the naming

[marble basin]

you just do the reflection bs after l inking the new thing, evict the existing cache and just add the new values

[astral hawk]

We're on the same page there 👍

The only part that I'll rewrite is that I delegated the creation (& keeping/caching) of actual GL uniform buffer objects to a class. Everything UBO related is too coupled at the moment and resistant to modification.

It should be much, much simpler

[astral hawk]

Maybe put a timer on it, to preserve some cpu cycles.

[marble basin]

nah

[astral hawk]

What I meant by FileWatcher was actually

[marble basin]

not necessary

[astral hawk]

OS would send me a signal (by way of a callback in c++ of course)

So I would not bother polling for it

[marble basin]

shell hooks are lame

[astral hawk]

But I don't lose anything by polling

No need to import anything

That's the better way 👍

[marble basin]

if the file didnt change you dont import anything

file write access is cached by the os already

[astral hawk]

By import I mean the source, not the shader itself

[marble basin]

im talking about the physical file

filewatchers based on hooks dont always work properly

[astral hawk]

Okay, just wanted to clarify that I'm not talking about that 👍

[marble basin]

and stat-ing a file doesnt cost anything

even if it did

the editor doesnt need to run at OVER 9000 FPS

[astral hawk]

Exactly

Still, putting a timer there is 3 lines of code, so why not 😄

[marble basin]

sure

[astral hawk]

But yeah I won't

I'm wasting so many cycles in ImGuiDrawer

And not 0.01 fps changes

[marble basin]

wasting cycles shouldnt even be on your list, the concern, i mean

[astral hawk]

It's not, at least things these miniscule

I try to minimize GL state changes, draw calls etc. that's the kind of optimization I pay attention to

I have a nice DirtyBlob class to keep track of which uniform buffer portions changed and only update those etc.

Messing with these kinds of stuff slows down the graphics studying part sure but I'm content with my pace

[marble basin]

: )

ubo updates are fast and basically free

[astral hawk]

Well

Shit 🙂

At least my RenderDoc event call stack is not that crowded :p

[marble basin]

glPush/PopDebugGroup 😛

[astral hawk]

Already using those 👓

[marble basin]

sweet

[astral hawk]

Back again

Integrated instancing, though usage is involved to say the least, but that's to be expected. I wonder how Unity automagically handles instancing. Though it probably doesn't, at least not for custom attributes. It probably handles the most common attribute: transform matrix. I vaguely recall declaring constant buffers in shaderlab code, for instanced data.

Anyways what I did this week will probably get obsolete very soon (replaced with multidrawindirect etc.). So I don't want to delve deeper than this.

I also read 5 chapters from Real Time Rendering

Not the best book from an educational point of view imo, but the book has to cover LOTS of stuff so it is to be expected I guess.
Having said that, it's like THE reference book, for when you want to look up references regarding a specific topic.

[rustic belfry]

Nice!

[astral hawk]

It's interesting that D3D11 does not have the multi drawing capability.

I've been watching the GDC azdo talk & reading up on related stuff

[marble basin]

it has on amd as an extension

[astral hawk]

Hmmm interesting

[marble basin]

dont bother 🙂

just batch with DrawInstanced

[astral hawk]

I'm not doing multi-draw yet

[marble basin]

are you trying to make a renderer for d3d11???

[astral hawk]

No no not at all

I was just researching multi draw

Couldnt recall similar functionality in d3d from back when I was using it

Checked to see and yeah it does not have it

Though as you said Amd has an extension for it

[marble basin]

ah

[astral hawk]

I'm on the gamma chapter of LOGL

And ImGui seems to not play nice with sRGB

[marble basin]

imgui does not support it at all

and omar doesnt want to or doesnt give a fuck

[astral hawk]

Should I just alter ImGui colors to not be too bright deccer?

[astral hawk]

He doesn't understand the concept, his words.

[marble basin]

thats one way

another way is to modify the shaders

[marble basin]

ye 🙂

[fluid parrot]

That's what I do, it's good enough to not bother further

[marble basin]

    auto& io = ImGui::GetIO();
    io.ConfigFlags |= ImGuiConfigFlags_IsSRGB; // this little shit doesn't do anything
    io.ConfigFlags |= ImGuiConfigFlags_NavEnableKeyboard;
    io.ConfigFlags |= ImGuiConfigFlags_DockingEnable;

[astral hawk]

Yeah I scoured through ImGui source and its opengl backend and there's no sRGB anything

[astral hawk]

Makes sense 👍

[astral hawk]

Before/after

I Gamma-corrected the imgui style colors with the formula from official GL docs on glTexImage2D

Before/after without ImGui and rendering the final fbos directly to the default fbo

If I understood correctly, I should treat albedo/diffuse images as sRGB and use GL_SRGB (or the alpha variant) for the internalformat for glTexImage2D and friends.

But textures like normal maps should be treated as linear color space.

Where do we draw the line though ? 😅

[astral hawk]

Currently I added a bool is_sRGB flag to Texture's all constructors and it is defaulted to true. So every texture I currently have is treated as sRGB. I don't have any maps other than diffuse and specular at the moment though.

[marble basin]

glEnable(GL_FRAMEBUFFER_SRGB) is on?

and your color baring textures (albedo, emissive, sky cube if you sample from a sky texture) are GL_SRGB8_ALPHA?

[astral hawk]

Currently ALL textures are GL_SRGB or GL_SRGB_ALPHA, but as I said I don't have normal/roughness/metalness etc. maps. So it's fine I guess.

[astral hawk]

Yes

But only for the last step of the rendering function. I use several fbos, only the last ones have it on.

[fluid parrot]

The rule could be something along those lines:

if( is_hdr )
{
  return linear;
}
else
{
  if( is_color ) // basecolor, diffuse, emissive, specular color
  {
     return srgb;
  }
  else
  {
    return linear;
  }
}

[astral hawk]

Not familiar with HDR yet but I get your point 👍

[fluid parrot]

For hdr it's usually environment map, cubemaps, skyboxes. Anything that could be used for Image Based Lighting basically.

but could also be color grading LUTs, etc

[astral hawk]

So, anything "color" then.

For example a normal map has direction info. so it makes sense that it shouldn't be part of the gamma encoding/decoding process.

But everything "color" is altered and saved to disk, on an image editing software etc., in an sRGB display (probably, I'll ignore those with pro. monitors). So those need to be converted to linear space for lighting calculations in the shader and then converted back to sRGB before sending it to the display.

I got it I think, thanks folks

Next up, shadows 👀

Time to one-up Björn

[marble basin]

you can probably extract color profile information

from EXIF/andtheotherthing meta data

or make sure your tools export into a specific format

[astral hawk]

Some file formats have color space info. from what I've read so far

jpg and tiff for example

But PNG does not have it

I think

[marble basin]

png also has that

but png also comes in 2930420428 flavours 🙂

when you save a png with gimp you get all the metadata there if you want. i have no idea how photoshop/krita/affinity handle it

i think paint.net provides some too

there is XMP too

or worst case you provide your own, as some .json file which goes along with the raw image

[fluid parrot]

It has it, it's cursed, so ignore it :p

[astral hawk]

I'm gonna ask a question and I know the answer already

Should I bother with Renderbuffers?

My Framebuffer class has std::variants for attachments to support both Texture & Renderbuffer

And I feel like it's probably not worth it

[marble basin]

yes: no

[astral hawk]

https://tenor.com/bwFVL.gif

I did like %90 of the coding, I don't know why I'm getting lazy now

I'll add the last bits and call it done

[marble basin]

no means no

and yes means, yes you know the answer already

which was no 🙂

[astral hawk]

Oh now I get it

[marble basin]

https://github.com/deccer/HowToScript/blob/main/src/Main.cpp#L676 TFramebufferDescriptor

https://github.com/deccer/HowToScript/blob/main/src/Main.cpp#L1986 CreateFramebuffer

https://github.com/deccer/HowToScript/blob/main/src/Main.cpp#L3772 Example use

das is what i do

[astral hawk]

No Renderbuffers as far as I can see

👍

[marble basin]

RBO were primarily used for offscreen rendering only, are inflexible format wise and cant do multisampling either

they are supposed to be "faster" but the limitations of them outweights their use

ah and i think you cant sample from them in a shader

[astral hawk]

I read so yeah

F*ck it yeah I'm removing it

It's problematic to implement this kind of stuff (union/variant) with templates anyway, because you need to define concrete types for all possible use cases before shipping if the codebase lives separately from the client (an engine does, most of the time, as a dll etc., where the client is the game executable).

I'm in a love/hate relationship with templates for the last 10 years.

I'm babbling now

[marble basin]

thats why you keep low level renderisms away from any game code

[astral hawk]

That's fair

[marble basin]

or even high level renderers

[astral hawk]

Game code should not directly interact with a Framebuffer yeah

[marble basin]

on top you only describe what you want, and the underworld makes sure to get it done somehow

yeah Game only deals with Scene-ey things, entities components and scripts

thats my goal at least, i want to have 1 default renderer implementation, which does deferred in a simple way, nothing fancy yet, support pbr and ibl, and shadows

[astral hawk]

Unity had the notion of a RenderTarget if I'm not mistaken, which you could request/use in C# scripting code BUT that was also a concrete type, there weren't 12893981249 variants with Renderbuffers/Textures, or separate/combined depth/stencil attachments etc.

[marble basin]

yeah, you could expose extension points into the renderer

[astral hawk]

Nice, stable goal to have, at least from my limited perspective

Godspeed my friend

Removing code is so much fun

[marble basin]

like this

[astral hawk]

Is this a screen-shot from the renderer you mentioned above?

Looks nice

[astral hawk]

Hello again

[marble basin]

greetings

[jagged pecan]

greetings

[marble basin]

https://www.youtube.com/watch?v=8rRgfq5X7DY

[astral hawk]

I've been messing with the renderer architecture for the past couple of weeks, sort of emulating what Unity does (big emphasis on the sort-of part), integrating render passes and queues. This was in part to accomodate the shadow mapping pass. Learned a lot, screwed up a lot. I'm happy with the results so far.

Skipped the point shadow lights chapter of LOGL because it was more of the same concepts I've grown accustomed to these past weeks (framebuffers + shadow mapping + cubemapping basically).

Also digressed a little and read up on some systems programming topics, mostly memory/cache related readings.

Also I created a LinkedIn post just to light some sort of fire under my ass, to force me out of my comfort zone (similar to what deccer did for me by nudging me to open this post here).

Now I'm on the normal mapping chapter of LOGL and I have a weird issue

[marble basin]

as a turk you should understand german already 😄

[rustic belfry]

sounds like you are making great progress!

[astral hawk]

That applies to my countrymen/woman living there my friend

But I did pass 3 german classes in university

[marble basin]

no excuses habibi

[astral hawk]

And managed to forget all but numbers from 1 to 10

[marble basin]

: D

[astral hawk]

Lovely song by the way

https://www.youtube.com/watch?v=wzUKbSw3GeY

[rustic belfry]

I once only spoke German and I have also managed to froget all

[astral hawk]

Thanks, I'll take a look at your channel next to get some FOMO

[marble basin]

yeah, everything is better than howard carpendale 🙂

[rustic belfry]

there's nothign to see there

[astral hawk]

That's a huge lie probably, I'll see for myself 😄

[marble basin]

mf (my frog) deleted his thread

[rustic belfry]

this is how I do it at work, make a good first impression and then I don't have to do anything else because they'll never believe that I wouldn't do work

jk

[astral hawk]

Wait

Where is the thread

Is it really deleted and if so why

[rustic belfry]

was time to do something new

it's not deleted

it's just I guess when the OP leaves their own thread it gets archived

[astral hawk]

Oh

So what's next for you?

Vulkan shenanigans?

[rustic belfry]

ya

it's going really slow though

[marble basin]

absolutely useless discord is

[astral hawk]

Yeah I searched and nothing came up as well

[rustic belfry]

you can search by my posts and find it

just go to like page 300

[astral hawk]

As long as it is something positive I'm all for it mf (motherland's frogmeister)

[rustic belfry]

sorry 350

I have commented some more since I tried 300

[astral hawk]

https://tenor.com/begg5.gif

[marble basin]

hehe

that was a nice song btw

[rustic belfry]

I posted this update last night after idk over 2+ weeks of work #vulkan message

I have had to learn C++ at the same time though, so it's not really just Vulkan being a lot

[astral hawk]

That's a dangerous combo

Although you're not a beginner and have decades (if I'm not mistaken) of programming experience

Still c++ is a huge behemoth

A bloated one at that

And vulkan from what I've heard is not that good on that regard either

[rustic belfry]

well also part of it is I'm going way off the reserveration and using brand new extensions that aren't documented and there's no tutorials for them

shader objects

[astral hawk]

Aaah the dreaded vulkan hello world, infamous 3000 lines of setup code was it 😅 Congrats on reaching that threshold

[rustic belfry]

so it's really 3 things making it slow

[rustic belfry]

It's only like 1K lines tbh, and with vulkan bootstrap even fewer

1K isn't a lot of lines neither because most of it is just setup structs with default values

[astral hawk]

I'm gonna go out on a limb and guess that you like reeeeally spicy food

There's some masoschism going around

[rustic belfry]

I'm about to add 4th new thing, slang

[rustic belfry]

no not really, I don't like pain in my mouth :P

[astral hawk]

https://tenor.com/u8dw.gif

[rustic belfry]

I do like a bit of spice

https://shader-slang.com/

[astral hawk]

Cache miss on my part

[rustic belfry]

I have come to really really like Visual Studio though

[astral hawk]

Do tell

[rustic belfry]

which is surprising

[astral hawk]

Because I hate it

[rustic belfry]

it's just nice

I like the UI

[astral hawk]

UX/UI wise it's the best imo

[rustic belfry]

I like how everything just works

[astral hawk]

Everything else feels amateur

But performance is dog-shit

And it got worse with each iteration

[rustic belfry]

one gripe is how I have to restart it to install extensions and updating it is really slow and requires downloading GBs of stuff

[astral hawk]

I started with 2012, then 13, 15, 17 and currently 19

[rustic belfry]

I'm on 2022

[astral hawk]

Every time I upgraded, all of my settings, including formatting, colors etc. got deleted from the cloud

[rustic belfry]

using just the free veersion

oh

[astral hawk]

So I'm hesitant to update

But I think I'll give it a shot

[rustic belfry]

I haven't configured anything except my project

and I git clones it to another desktop and it was fine

[astral hawk]

I can't even ctrl + shift + space to see function parameters, intellisense is not just slow, it's not working at all, like nothing at all

[rustic belfry]

I like how the build errors are part of the ui

[astral hawk]

In my renderer project I mean

[rustic belfry]

oh another thing I don't like is all the copilot integration

[astral hawk]

And I don't think it's that big of a repo

[rustic belfry]

like every other link is about asking copilot

[astral hawk]

Hmmm they didn't include that in 2019 so I'm free of that for now at least

[rustic belfry]

sometimes it is helpfult though

[astral hawk]

But the debugger is also really good UI/UX wise I think

And again, the watch window etc. is slow but not as bad as intellisense

[rustic belfry]

but it's just like one of the options in nearly every dropdonw

I know I just said I liked it and went on a list of things I don't like

[astral hawk]

That's irritating

[rustic belfry]

that's how you know I like it I guess

[astral hawk]

Haha yeah it's a love/hate relationship with visual studio

But as you also know, Game Engine Architecture provides example ways to do stuff in Visual Studio frequently, so I'm inclined to believe it is used in big studios as well

[rustic belfry]

yeah

they also build it on linux and do dev on linux in that book

like the asset pipeline stuff is all on linux if I recall

[astral hawk]

Nice

I just wish they rewrote some parts at least to optimize

Namely intellisense

[rustic belfry]

oh yeah

[astral hawk]

Some updates then

[rustic belfry]

that is really slow

[astral hawk]

When 2022 came out, I read their blog post on how they increased intellisense for Unreal Engine projects by 50x

If you improved something by 50x, you did something horribly wrong in the first place

Which is a sentence I stole from fabian giessen, saw in twitter

[rustic belfry]

nice, I feel like you are game ready

[astral hawk]

Depends on the game but yeah why not

If I wanted to make a game asap, I'd put the graphics stuff aside at the moment and focus on a scene graph of sorts, foundation for which is sort-of there

[rustic belfry]

how does your directional light matrix work? you have a matrix from the point of view from your light and do a depth pass with a framebuffer with a depth attachment, using an ortho matrix?

[astral hawk]

The biggest improvement for visuals will be normal mapping and pbr in general (if we scope up to where LOGL ends I mean)

[astral hawk]

Exactly

[rustic belfry]

ok so my question is

where actually is your camera when you do the depthpass

like how far away is it from your scene

[astral hawk]

My scene was 100 units in the Z direction or something like that, so I ignorantly (and intentionally) placed the camera -50 units in the direction the light is facing

[rustic belfry]

and then you had a lot of aliasing yes

[astral hawk]

Yeah, and I internalized that the aliasing was due to this and added this todo and called it a day (i.e., moved on):

Also added pcf and biasing as LOGL does

Which does not look that bad to be honest

But of course needs manual care from the user

as opposed to an AABB (or OBB) approach

[astral hawk]

Huh it seems I commented out that -50 units part

[rustic belfry]

I can do point light shadows in opengl no problem, I hadn't figured out good directional lighting, I think it's much harder than point lights

[astral hawk]

Yeah with point lights there are less unknowns I guess

Namely the position of the light

[rustic belfry]

imagine a scene with five pillars, each evenly spaced from each other, could be near or far apart, with a directional light, the light should be parallel

the shadows should all be exactly the same for each from each other, these pillars are axis aligned on one axis in this example

but how do you place the camera for the light to do that?

I tried just playing around and couldn't do it

the shadows all looked terrible

anyway I'll read about it later

[astral hawk]

I get what you mean, I also had a hard time making the shadows look good

When I direct the light 45+ degrees on x axis, meaning the light looks down, shadows just vanish

It probably has to do with the location of the light

Since there is CSM etc. and a lot more (in both real time rendering and other sources I'm following/will follow) I decided not to dwell on it too much

[rustic belfry]

same

anyway, I may get back to shadows in about a year after I have two triangles

[astral hawk]

Haha hopefully sooner than that

[rustic belfry]

yeah I'm moving much faster now

[astral hawk]

Mike Acton says in one of his most known videos, to do the same exercise/project over and over, throw it in the trash, start over again, this time implement it faster and better, start again etc. etc. to hone one's craft

Your recent move seems like it is aligning with this, no?

Which is the exact opposite of what I'm doing but oh well, I have a syllabus to finish

[rustic belfry]

I don't particularly enjoy throwing a way a lot of work fwiw

[astral hawk]

Same

But I have a bad memory

For example I forget mathy subjects if I don't utilize them for some time

What Mike Acton says is a nice brute-force way of "burning in" info I think

[rustic belfry]

nice I like that point though

[astral hawk]

Now, I have a weird bug

And to be honest I should have probably said f*ck it and moved on but I'm curious

So I'll share with you guys here to get to the bottom of it

Okay so for normal mapping, I decided to create a 2x2 default normal map in paint (I know)

I forgot that the normals are in the range -1, +1 for a minute and that they are in tangent space, so the default is 0,0,1, not 0,1,0 and painted all pixels green (RGB = 0,255,0)

And the fun part is