mosra/magnum

Lightweight and modular C++11/C++14 graphics middleware for games and dataviz

pezcode

@pezcode

shiny surface -> small highlight

Mathew

@lectroMathew

Yeah, I guess it does make sense if you think about it

Vladimír Vondruš

@mosra

could anybody on Windows run the following and tell me if it all passes or mostly fails? it all passes for me on Linux with both Chrome and FF, but on the Windows machine I tested on it was about 40 failures and I don't know why :D

https://tmp.magnum.graphics/GLMeshGLTest.html

9 replies

i only wanted to fix that one ANGLE bug, but apparently there's a bottomless pit full of bugs, again

Azvf

@Azvf

Hi, I'm trying to blit a framebuffer to the right half of the defaultframebuffer, but why the right half keeps thrashing when I scale the window in width. It seems the resize function problem but it works fine when I use the 'default' blit.

Azvf

@Azvf

It keeps switching between the black screen of the defaultframebuffer and the data in the source framebuffer

Vladimír Vondruš

@mosra

huh

the buffer you blit from gets resized as well?

Azvf

@Azvf

yes

Azvf

@Azvf

        _size = size;
        auto halfSize = Vector2i{ size.x() / 2, size.y() };
        auto& bufferGroup = _bufferGroup[index];

        // RenderBuffer Resize
        bufferGroup.colorBuffer = GL::Renderbuffer{};
        bufferGroup.depthStencilBuffer = GL::Renderbuffer{};
        bufferGroup.colorBuffer.setStorageMultisample(GL::Renderbuffer::maxSamples(), GL::RenderbufferFormat::RGBA8, halfSize);
        bufferGroup.depthStencilBuffer.setStorageMultisample(GL::Renderbuffer::maxSamples(), GL::RenderbufferFormat::Depth24Stencil8, halfSize);

        // MSAA Framebuffer Resize
        bufferGroup.framebufferMSAA = GL::Framebuffer{ { {}, halfSize }};
        bufferGroup.framebufferMSAA
            .attachRenderbuffer(GL::Framebuffer::ColorAttachment{ 0 }, bufferGroup.colorBuffer)
            .attachRenderbuffer(GL::Framebuffer::BufferAttachment::DepthStencil, bufferGroup.depthStencilBuffer)
            .mapForDraw({ {Shaders::PhongGL::ColorOutput, GL::Framebuffer::ColorAttachment{0}} });
        bufferGroup.framebufferMSAA.setViewport({ {}, halfSize });


        // camera viewport setting
        _camera.reshape(size, halfSize);

resize code called on glfw viewport change event

Vladimír Vondruš

@mosra

_bufferGroup[index]

multiple buffering, right? could it be that, at the time of a blit right after the resize, it takes the source data from a framebuffer that hasn't been rendered to yet (because it got just recreated after a resize)?

Azvf

@Azvf

Is the viewport event async?

Vladimír Vondruš

@mosra

no, everything happens in the same thread

are you multiple buffering? that's the root cause i think

Azvf

@Azvf

It's not multiple buffering, it's multiple framebuffer combined on a sole defaultframebuffer

Vladimír Vondruš

@mosra

ah, hmmm

debugging idea -- if you clear those to 0x00ffff_rgbf right after the recreation, does that color appear in the default framebuffer?

or is it still the default black-ish

Azvf

@Azvf

do you mean clear the source framebuffer

Vladimír Vondruš

@mosra

yes

in the viewport event, right after you attachRenderbuffer()s to it

Azvf

@Azvf

Azvf

@Azvf

it's still the same

there's a draw call overwriting the resize result so I commented it out. The result just changed to switching between cyan and black when I scale the window.

Vladimír Vondruš

@mosra

at this point i see the only solution as recording the actual GL calls with renderdoc or apitrace and then inspecting what gets done in each frame

it works fine when I use the 'default' blit.

if i understand correctly what you mean, the default blit is only implicitly passing the size, but it's the same operation underneath so it shouldn't matter

Azvf

@Azvf

I'll work on that tomorrow. Appreciate your help!🙏

pezcode

@pezcode

https://doc.magnum.graphics/corrade/classCorrade_1_1Containers_1_1StridedArrayView.html#Containers-StridedArrayView-multidimensional

This line:

Containers::StridedArrayView2D<std::uint32_t> image = images[5];

shouldn't it say images[4]?

Vladimír Vondruš

@mosra

what the hell, the whole section seems cursed

what did i do there

but yeah, it should be [4]

fixing

pezcode

@pezcode

Related question: how do I get 2D z-slices of a 3D array?

const auto slice0 = image->pixels<Color4ub>().prefix<2>({1, image->size()[1], image->size()[0]});

this is giving me a 2D view with size 27, 1 and I'm not sure what I'm doing

original image is 63, 27,3 and I want 63, 27

Vladimír Vondruš

@mosra

huh, why is Z last?

usually it's Z first, then Y then X

so a 2D Z slice is simply pixels<T>()[i]

pezcode

@pezcode

oh dear, you're right

Vladimír Vondruš

@mosra

in other words, for the pixels view the strided array view size should be image.size().flipped() :)

to answer your original question, if Z would really be last then pixels<T>().transposed<0, 2>()[i], where the transpose turns it from XYZ order to ZYX

pezcode

@pezcode

no you were right, z is the first dimension, I just got really confused in my head

Vladimír Vondruš

@mosra

i made this exact mistake several times myself also, so i learned to spot it :D

pezcode

@pezcode

so if I was trying to emulate pixels<T>()[i] with prefix/slice, how would I do that?

Vladimír Vondruš

@mosra

hmmm your image->pixels<Color4ub>().prefix<2>({1, image->size()[1], image->size()[0]}); should work 🤔

or even image->pixels<Color4ub>().prefix<2>(1) but there doesn't seem to be such an overload

ah no

Where communities thrive

People

Repo info

Activity