Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 15:04
  • Jul 02 05:57
    Tapuzi starred mosra/magnum
  • Jul 01 20:08

    mosra on master

    package/ci: use Xcode 11.7 on C… python: adapt to Magnum changes. (compare)

  • Jul 01 19:57

    mosra on master

    Containers: doc++ Utility: don't use <> for intra… Revert "package/ci: temporarily… and 5 more (compare)

  • Jul 01 19:57

    mosra on next

    package/ci: use Xcode 11.7 on C… python: adapt to Magnum changes. (compare)

  • Jul 01 19:56

    mosra on master

    Revert "package/ci: temporarily… package/ci: use Xcode 11.7 on C… package/ci: build on iOS in par… and 1 more (compare)

  • Jul 01 19:48

    mosra on master

    package/ci: use Xcode 11.7 on C… package/ci: build on iOS in par… Adapt to Magnum changes. (compare)

  • Jul 01 19:08

    mosra on next

    Revert "package/ci: temporarily… package/ci: use Xcode 11.7 on C… package/ci: build on iOS in par… and 1 more (compare)

  • Jul 01 19:06

    mosra on next

    package/ci: use Xcode 11.7 on C… package/ci: build on iOS in par… Adapt to Magnum changes. (compare)

  • Jul 01 19:06

    mosra on master

    doc: update imageconverter --in… Revert "package/ci: temporarily… package/ci: Xcode 11.7 is the o… and 2 more (compare)

  • Jul 01 18:23

    mosra on next

    Containers: this operation seem… PluginManager: don't check retu… PluginManager: add a Manager::e… (compare)

  • Jul 01 18:05

    mosra on next

    Containers: doc++ Utility: don't use <> for intra… Revert "package/ci: temporarily… and 5 more (compare)

  • Jul 01 17:36

    mosra on next

    package/ci: Xcode 11.7 is the o… Math: rename BoolVector to BitV… [wip] package/ci: iOS UGH why s… (compare)

  • Jul 01 16:47

    mosra on next

    package/ci: Xcode 11.7 is the o… Math: rename BoolVector to BitV… (compare)

  • Jul 01 16:42

    mosra on next

    doc: update imageconverter --in… Revert "package/ci: temporarily… package/ci: Xcode 11.7 is the o… and 1 more (compare)

  • Jul 01 14:52
    mosra edited #453
  • Jul 01 14:32
    mosra edited #115
  • Jul 01 05:54
    Build #1826 passed
  • Jul 01 04:22
    anwengel starred mosra/magnum
  • Jul 01 02:23
    Wuteva starred mosra/magnum
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
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
ok
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