mosra/magnum

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

Vladimír Vondruš

@mosra

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

if you say prefix<2> it discards the last dimension, taking just the first slice out of it

so you end up with 1, 27, yeah

prefix<n>() takes dimensions off the end, [i] off the start, so you need the [] here

Where communities thrive

People

Repo info

Activity