Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 10:24
    NippleOfAnApe starred mosra/magnum
  • Aug 06 21:33
    Squareys edited #128
  • Aug 06 21:10
    Squareys commented #128
  • Aug 06 20:59
    Squareys synchronize #128
  • Aug 06 20:47
    Squareys synchronize #128
  • Aug 06 18:49
    Squareys synchronize #128
  • Aug 06 18:48
    Squareys opened #128
  • Aug 06 17:18
    codecov[bot] commented #580
  • Aug 06 17:17
    Build #3980 passed
  • Aug 06 10:53
    difof starred mosra/magnum-singles
  • Aug 06 10:25
    AndreasLrx opened #580
  • Aug 06 10:05
    dranikpg synchronize #576
  • Aug 06 08:46
  • Aug 04 17:49
    mosra commented #127
  • Aug 04 17:48
    mosra milestoned #127
  • Aug 04 17:22
    Squareys opened #127
  • Aug 04 12:38
    shohmax starred mosra/magnum
  • Aug 04 12:11
    h34tn starred mosra/magnum
  • Aug 04 09:14
    mosra commented #576
  • Aug 03 22:20
    PerditionC starred mosra/magnum
Vladimír Vondruš
@mosra
if it has no parent, then yes
if it has a parent, then it'll be at the parent's transformation origin
Tracy Ma
@linuxaged
🆗
Vladimír Vondruš
@mosra
obj3d->setTransformation(obj3d->parent()->transformation().inverted()) will put it to origin if you have a parent
Fo Nz
@FoNz99089892_twitter
@mosra Ok thanks for that. I mis-read the docs. Excuse me
Vladimír Vondruš
@mosra
no problem ;)
Fo Nz
@FoNz99089892_twitter
Why doesn't Android use SDL in Magnum?
Vladimír Vondruš
@mosra
last time i checked, getting SDL to run on Android required copying over some java class and editing its contents as part of the build process, which i felt was beyond ridiculous
Vladimír Vondruš
@mosra
hm, i just randomly came across this issue: microsoft/vcpkg#20650 .. is vcpkg maintained really that poorly? this is the third bug breaking --head builds in the last month
pezcode
@pezcode
it's... very rickety. I got excited about the versioning feature and local installs, but after trying it out with assimp I'm afraid of it now
Vladimír Vondruš
@mosra
sometimes i feel like i would help people just by telling them to not use vcpkg :see_no_evil:
Azvf
@Azvf
img.png
Hi guys, I'm attempting to implement a billboard text effect with background but I can't get it right.
To avoid z-fighting, I set the Text part to 1 in stencil buffer and draw the background when not equal to 1 so it will ignore the Text part.
But the effect is like this cause all the text are set to 1 in stencil buffer so all the background objects will just ignore it.I wonder how to solve the problem or if there's a better solution to implement it.
            for (auto& iprGroup : _iprDisplayGroup[step]) {
                GL::Renderer::setStencilFunction(GL::Renderer::StencilFunction::Always, 1, 0xff);
                GL::Renderer::setStencilMask(0xff);
                // Draw Text
                auto& textRenderer = iprGroup.textRenderer;
                if (textRenderer) {
                    textRenderer->finish(_camera.camera().cameraMatrix());
                    _camera.camera().draw(textRenderer->getDrawable());
                }
            }

            for (auto& iprGroup : _iprDisplayGroup[step]) {
                GL::Renderer::setStencilFunction(GL::Renderer::StencilFunction::NotEqual, 1, 0xff);
                GL::Renderer::setStencilMask(0x00);
                // Draw Diamond Background
                _camera.camera().draw(iprGroup.upIprBgGroup);
                // Draw Background Outline
                _camera.camera().draw(iprGroup.upIprOutlineGroup);
                // Draw Line
                _camera.camera().draw(iprGroup.upIprLineGroup);
            }
Here's the code.
Vladimír Vondruš
@mosra
@Azvf instead of fighting with the depth/stencil buffer, the usual way to do this is with the "painter algorithm", from back to front ... or, in your case, basically ensuring the text gets always drawn after its associated background and outline, but before any other backgrounds
Azvf
@Azvf
Does the draw call order affect the result of rendering? I thought they were eventually rendered sorted by their depth in the framebuffer.
Vladimír Vondruš
@mosra
draw call order affects the result, yes -- there's no sorting by depth per-se, only that the fragments drawn later get discarded if they fail the depth test (or, vice versa, if the fragment "in the back" would be drawn first, the fragment "in the front" would overwrite it if drawn later, instead of the fragment "in the back" getting discarded)
Vladimír Vondruš
@mosra
argh webgl!!!
  • i need to detect ANGLE in order to add a workaround for its bug
  • but there's no way to detect it from the vendor/renderer string because they mask the info away to avoid fingerprinting
  • fortunately, there's WEBGL_debug_renderer_info that can give me the "unmasked" info
  • HOWEVER, latest Firefox seems to be printing a warning every time it gets used: https://issueexplorer.com/issue/ruffle-rs/ruffle/5279
Azvf
@Azvf
I get the depth test part, but I still don't quite get how the draw call order affect the render result when the result is still determined by their depth since the fragment in the front will overwrite the ones in the back even if their draw call is earlier.
Vladimír Vondruš
@mosra
ah, sorry, should have been clearer -- if you disable the depth test (or never enable it), it will depend just on draw call order
Azvf
@Azvf
In my case there're still other parts in the scene so I can't disable the depth test
Vladimír Vondruš
@mosra
in that case render everything that needs depth sorting with depth test enabled, then disable depth writes (setDepthMask() i think?) and render the 2D shapes and text
or if the shapes are always on top anyway, then it's enough to disable the depth test altogether when drawing them, and then enable it again after
Azvf
@Azvf
I tried the mothod of disabling the depth test a few days ago but the result is not good looking so I still attempted to render them as normal object using depth test. It's my first time doing this so I wonder if there's a common practice that can render the scene properly when many layers are in the same position.
Vladimír Vondruš
@mosra
what is not good looking about them? the common practice is the painter algorithm i outlined above, rendering the layers back-to-front (submitting the draws in order that draws them back to front, with depth writes disabled)
Azvf
@Azvf
Got it. Thank you for your help, I'll implement that way.🤝
Fo Nz
@FoNz99089892_twitter
Hi at all. I think there is something strange on iOS. Every time you call the mapForDraw method, that framebuffer become useless. It just renders a black screen on it. I'm currently using the 2020.06 version of Magnum. This happens even on the simple triangle example! Infact, the object picking example does render a black screen on iOS.
@mosra Am I missing something? Thanks in advance!
Vladimír Vondruš
@mosra
:eyes:
the vanilla unchanged object picking example renders a black screen?
one has to call mapForDraw() and direct the draw back to the (front? back?) default framebuffer again in order to have something appearing on the screen, but that should be done there
It works on Android and Windows, but not on iOS (both Simulator and real device iOS 15)
Both maxDrawBuffers and maxColorAttachments return 8. I can't understand why.
Vladimír Vondruš
@mosra

does anything improve if you call

    GL::defaultFramebuffer.mapForDraw({Shaders::Phong::ColorOutput, GL::DefaultFramebuffer::ColorAttachment::Back});

(or a variant of it that actually compiles) right before the blit call?

Fo Nz
@FoNz99089892_twitter
But the strange thing is... take a look at this:
http://vec3f.github.io/2014/09/15/deferred-shading-part-1/
He is NOT using layout qualifier, but he use out vec4 fragColor[3];, where 3 is the amount of render targets...

does anything improve if you call

Now I try this in a moment... I have to switch to macOS.

Even though I use the GL::Framebuffer::ColorAttachment{my_index_here} in my own code...
Vladimír Vondruš
@mosra

out vec4 fragColor[3];

huh, never have seen that

but i'd suppose it's equivalent and the location is implicit (0, 1, 2) that way? would need to check the GLSL spec
Fo Nz
@FoNz99089892_twitter

does anything improve if you call

    GL::defaultFramebuffer.mapForDraw({Shaders::Phong::ColorOutput, GL::DefaultFramebuffer::ColorAttachment::Back});

(or a variant of it that actually compiles) right before the blit call?

I think you wanted this, right?

GL::defaultFramebuffer.mapForDraw({{MyShader::ColorOutput, GL::DefaultFramebuffer::DrawAttachment::Back}});

Because I cannot find GL::DefaultFramebuffer::ColorAttachment::Back nor in the docs (last version), nor in 2020.06.

Anyway, always black output in that framebuffer.
Vladimír Vondruš
@mosra
yeah, DrawAttachment, sorry (writing this off the top of my head)
sigh
Fo Nz
@FoNz99089892_twitter
Can you replicate this issue by yourself? Do you have macOS with Xcode and all the stuff along?
Vladimír Vondruš
@mosra
do you get any GL error through Xcode, maybe?
Fo Nz
@FoNz99089892_twitter
Ah no, I don't get any GL error.
Vladimír Vondruš
@mosra
i have a macOS Mini, but no iDevice, and the Mini wasn't powered on for quite a while
Fo Nz
@FoNz99089892_twitter
I have the debug enabled. I can see (quite a lot) lines being logged in Android and Windows, but nothing on iOS.
Vladimír Vondruš
@mosra
iOS doesn't have the GL driver debug output, the only way is through the Xcode OpenGL profiler / tracker, if it still exists there