DDraceNetwork - off-topic

00:33

why is my normal buffer flickering in compositor effect

00:33

00:35

@Cellegen help owo

wtf

00:36

prob because of the WorldEnvironment node

i just sampled the normal texture and shoved it down the color buffer

00:36

i don't understand how it would be flickery

00:36

i was using the 4.3 compositor effect

well, wouldn't working with meshes be better?

i need normal buffer to make post processing outlines.

00:38

the old way of post processing probably worked fine. i just thought the new compositor effect is easier to be made work in scene view

To be honest, never tried out color buffering on objects, since never needed an outline function

00:39

Don't expect much on 4.3 tho, it has still pretty bugs

I may have something to tell

00:41

it seems like the flicker is similar to one frame having RGB values, then the other frame having forced sRGB

00:43

@TsFreddie is MSAA enabled on your project?

00:43

https://github.com/godotengine/godot/issues/94348

Switching from TAA to MSAA breaks compositor effects · Issue #94348...

Tested versions 4.3-beta3 System information Windows and Linux Issue description Switching AA method from TAA to MSAA breaks compositor effects using color buffers. While I understand this is inten...

00:43

this one still has not been fixed btw

Cellegen

@TsFreddie is MSAA enabled on your project?

no

I could look at the scene myself to figure out what's making it

00:47

it only updates whenever the camera's updated, thus it might be related to how the compositor acts alongside with the WorldEnvironment node

it seems to be dependent on camera angle

so it's only the compositor and no other materials?

ye, it is using the default standard mat

00:51

i mean the cube

00:52

i can send you the project

00:52

it's really minimal (edited)

00:53

compositor_test.zip

5.68 KB

the normal roughness is fcked

01:02

and using the compositor will destroy all elements of Environment

i mean ye, cuz i overwrite into the color buffer. it doesn't need to do that, but i'm doing that just so i can see the normal buffer

01:04

I think you'd have a faster solution with shaders

this is a shader

Well not in a way using this compositor method

ye i guess

01:06

i made one already with multipass materials

01:06

the draw call will be pretty insane tho having to break material draws for every object

01:07

and i don't like how godot normally does its post processing with viewport textures and 2d scenes, cuz you can't preview it in scene view (edited)

01:07

i thought compositor effect will be pretty handy once i get it going

You could, if you somehow able to allow objects to react to the @tool method, signals and other shader stuff won't be applied directly in the editor

i mean i could see it in the 2d view that renders the camera with a shader

01:08

just not in the 3d view normally

Yea, as in they just forgor

i think the only way to hook into the 3d rendering without pulling buffers into the 2d scenes is compositor effect currently

01:09

well i'm pretty sure

But the normals are fucked the moment you enable normal roughness

ye, that's what i'm trying to fix.

I have no search on github about normals bugging out from compositors... this may be a unique bug

ye, i just need to know what is happening. i don't mind fixing it in engine source code

01:12

i keep running into things that i need to modify the engine source, which is quite annoying really

01:13

the funny thing is that the normal buffer debug draw is correct

01:13

which is sampling the same buffer

compatibility+ disables compositors completely, so cannot see if it changes (edited)

normal buffer is only available in forward+