mosra/magnum

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

irfna

@irfna

Yep, switching to 10.0f to 10000.0f seems to fix the issue completely!

Thanks for the help! Now all I have to do is figure out why the sprite transparency isn't working even when I enable blending haha

Vladimír Vondruš

@mosra

you need to call setBlendFunction() as well :)

irfna

@irfna

Cool, thanks!

Vladimír Vondruš

@mosra

actually i can't seem to get it work myself :D only AlphaMask enabled on the shader did work

what am i doing wrong?

ah, no, actually

Vladimír Vondruš

@mosra

this is it:

    GL::Renderer::enable(GL::Renderer::Feature::DepthTest);

    terrain.draw(*_camera);

    /* Draw sprites after the terrain, so it's obscured by it if it's behind.
       But disable depth writes, so the sprites don't cut into each other */
    GL::Renderer::setDepthMask(false);
    sprites.draw(*_camera);
    GL::Renderer::setDepthMask(true);

    GL::Renderer::disable(GL::Renderer::Feature::DepthTest);

before you had sprites rendered first, and they wrote to the depth buffer so the cube wasn't rendered behind it

the AlphaMask (and no blending, or depth ordering) works as well, but that's a purely binary operation (a pixel either is there or is not), so it looks acceptable only on sufficiently high-DPI screens and won't work for semi-transparent stuff

irfna

@irfna

haha I hadn't actually tested when you said to use setBlendFunction and had to go afk at the time, sorry for making you think I got it to work with that. For sprites, alphamask is all I need for now, although someday I will need to be able to make things semi-transparent

I'll copy and paste that change into my code

Vladimír Vondruš

@mosra

it always ends up being more complicated than it seems at first

irfna

@irfna

Ya, I see what you mean. Luckily the extra complication has been fairly small one line things, it's just knowing that they're necessary that is the issue haha. I tossed setBlendFunction in along with the code snippet you pasted, and the sprite transparency is working great

Thanks a bunch, you cut through some stubborn issues for me just like that

Vladimír Vondruš

@mosra

last thing, while i have the code here -- it ~~crashes~~ asserts on exit due to the global manager that holds OpenGL objects, the ideal fix would be to make it a member of the Application class, so it gets cleaned up before the Application itself destroys the OpenGL context

irfna

@irfna

Alright, thanks! That's an easy enough fix

Mathew

@lectroMathew

PhongMaterialUniform::shininess doesn't make much sense to me: the larger value, the harder surface. Shouldn't it be called hardness then? :D I wonder why GL_SHININESS works in this way...

Vladimír Vondruš

@mosra

this is where it originates: https://en.m.wikipedia.org/wiki/Phong_reflection_model

Mathew

@lectroMathew

Yeah, again

constant, which is larger for surfaces that are smoother and more mirror-like.

I guess you can say that mirrors are not shine because they don't have any specular highlight? In my head tho it's always been like the reflection itself is just a big specular hightlight. A bit counterintuitive...

pezcode

@pezcode

I guess you can say that mirrors are not shine because they don't have any specular highlight

That quote says the opposite, doesn't it? Mirror-like = large shininess

mirrors are 100% specular reflection, virtually no subsurface scattering

Mathew

@lectroMathew

I guess you can say that mirrors are not shine because they don't have any specular highlight

That quote says the opposite, doesn't it? Mirror-like = large shininess

Is what I think as well, but read further:

When this constant is large the specular highlight is small

shininess value of 0.0f results in perfect mirror-like look

pezcode

@pezcode

highlight size is (very loosely speaking) inversely proportional to the amount specular reflection

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

Where communities thrive

People

Repo info

Activity