Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 10:17

    mosra on next

    Containers: this StringIterable… Containers: make it possible to… (compare)

  • 01:17
    xiaohunqupo starred mosra/magnum-plugins
  • Nov 30 23:07
    JuanluMorales starred mosra/flextgl
  • Nov 30 21:47
    mosra edited #306
  • Nov 30 21:45
    mosra edited #306
  • Nov 30 21:37

    mosra on next

    Containers: workaround for GCC … (compare)

  • Nov 30 20:06

    mosra on next

    Containers: workaround for GCC … (compare)

  • Nov 30 19:20
    ProDCG starred mosra/magnum-examples
  • Nov 30 19:13

    mosra on next

    Containers: don't use the depre… doc: change the way CORRADE_BUI… Containers: add a forward decla… and 7 more (compare)

  • Nov 29 23:17
    mosra closed #20
  • Nov 29 23:17
    mosra commented #20
  • Nov 29 23:17

    mosra on master

    python: more missing moves, unn… doc: updated changelog. (compare)

  • Nov 29 23:10
    mosra labeled #20
  • Nov 29 23:09

    mosra on next

    python: more missing moves, unn… doc: updated changelog. (compare)

  • Nov 29 22:41
    Skylion007 commented #20
  • Nov 29 22:41
    Skylion007 commented #20
  • Nov 29 18:43
    Reticulatas closed #609
  • Nov 29 18:43
    Reticulatas commented #609
Mathew
@lectroMathew
How do I bundle libPNG so that PngImporter would be able to successfully find it? Right now I have it in my lib/ folder along with
list(APPEND CMAKE_PREFIX_PATH lib/lpng1637) add_dependencies(MyApp MagnumPlugins::PngImporter)
Cmake instructions, like documentation states. Yet it seems to struggle finding the lib anyway Could NOT find PNG (missing: PNG_LIBRARY PNG_PNG_INCLUDE_DIR) _FPHSA_FAILURE_MESSAGE
Vladimír Vondruš
@mosra
wait, there's something i missed ... you're enabling BUILD_PLUGINS_STATIC but still link to a dynamic one?
Mathew
@lectroMathew
nono I build them dynamically now
Vladimír Vondruš
@mosra
ah okay, that explains :)
if you don't want to bother with libpng (which, honestly, is a pain to set up unless you can just use a system package on linux/mac), go with StbImageImporter instead, that one is dependency-less
and the speed (for PNGs at least) is comparable
Mathew
@lectroMathew
Oh yeah that sounds great, thanks for suggestion
Fo Nz
@FoNz99089892_twitter

can you show me how the shader gets constructed and populated?

GL::Shader vert{ GL::Version::GLES300, GL::Shader::Type::Vertex };
vert.addFile("shaders/screen_quad.vert");
CORRADE_INTERNAL_ASSERT_OUTPUT(GL::Shader::compile({ vert }));

In realty, I have both vert and frag, but I'm showing you only vert. Anyway, I managed to fix this problem, which I think it was due to some bad action I was doing. This is surely not Magnum's fault, I am sure. Also, this error happened only on Samsung devices... don't worry.

Vladimír Vondruš
@mosra
and the screen_quad.vert has a #version line on its own or not?
that it makes only a Samsung device fail is what worries me about this problem :)
Fo Nz
@FoNz99089892_twitter

and the screen_quad.vert has a #version line on its own or not?

Excuse me, but I now progressed with my game development, so I don't remember exactly. I can't give you exactly details, but I remember trying both with #version 300 es and without. But I repeat: I think it was my fault for doing something bad. I don't remember now. Anyway thanks!

Mathew
@lectroMathew
Is MSVC supported with magnum? I get perfect compilation with no errors, but nothing gets drawn except for the framebuffer clear color. The same exact code draws when compiled with MinGW however
I saw that Corrade spits out MSVC2019_COMPATIBILITY related warning, might this be the reason why?
MSVC 2019 detected, automatically enabling MSVC2019_COMPATIBILITY. Note that some features may not be available with this compiler.
pezcode
@pezcode
MSVC works perfectly fine with Magnum, could be some undefined behaviour in your code?
Mathew
@lectroMathew
I wonder...
Jean-Marie Baran
@Jim-Bar
Hi there, beginner question:
I'm using instancing for drawing many objects using a single mesh (with GL::Mesh::addVertexBufferInstanced()). It works, however it still requires looping on all objects for updating the instance data with new transformations (e.g. when the camera moves), which makes it slow. Is there a strategy to update the transformation of all the objects at once? I'm using the PhongGL shader
pezcode
@pezcode
Are you using SceneGraph? Either way, if the camera moves, your object transformations shouldn't have to change
PhongGL has setTransformationMatrix that gets applied after the instanced transformation
Jean-Marie Baran
@Jim-Bar
Yes I do. Indeed, yet the transformations relative to camera change, and it is this one which I put in the instance array. Something like: arrayAppend(_instanceData, InPlaceInit, t, t.normalMatrix(), _color); with t being relative to camera. So when it change, currently I must recompute everything
Okay looking into that :)
pezcode
@pezcode
If you want to update the objects' positions etc. you can update parts of the instance buffer (setSubData), but I don't know if that's really faster in your case than recomputing and sending the entire thing
Time to profile :eyes:
When I did some stuff with instancing I had a drawable that collected all its child nodes as instances and updated the entire array every frame. Didn't see any huge performance impact but I'm only talking 30 objects
Jean-Marie Baran
@Jim-Bar
Thanks for the info, in truth the only thing moving is the camera so it feels like setTransformationMatrix() could really help here. Just the time to comprehend things, I am beginning with rendering
I have ~10K objects
pezcode
@pezcode
Alright, that's a different league :laughing: Makes sense you see an impact there
Jean-Marie Baran
@Jim-Bar
Haha indeed!
Vladimír Vondruš
@mosra
the scene graph is unfortunately not helping here by providing a camera-relative transform, yeah .. if you can do without it and manage your hierarchy directly (or with entt, etc.), then the solution would be to pass scene-root-relative transforms via the instance buffer and camera-to-scene-root separately via setTransformationMatrix()

Is MSVC supported with magnum?

@lectroMathew haha, yes it is, the CMake warning is because certain APIs behave slightly differently than they would with a standard-conforming compiler (usually with less safety checks), however if you code compiles with MinGW in the first place then it should run on MSVC too

one thing that varies a lot between MSVC and GCC is the order in which function arguments are evaluated, and in certain cases that matters (for example when using release() on objects)
Mathew
@lectroMathew
Yeah Im still trying to figure out what causes msvc to not draw anything... Seems very weird tbh
Jean-Marie Baran
@Jim-Bar
@mosra Got it working with arrayAppend(_instanceData, InPlaceInit, _cameraTransformation * t, t.normalMatrix(), _color); on one hand (scene-root-relative transform into the instance buffer), and _shader.setTransformationMatrix(_cameraObject->absoluteTransformation().inverted()); on the other hand. Works like a charm, thanks for the help
Fo Nz
@FoNz99089892_twitter
I discovered a bottleneck in my game. Mouse picking involves glReadPixels, which flushes and waits for all the OpenGL commands. This kills the performance on Android devices (expecially low-end phones). This should be noted in the docs, since the goal of Magnum is to hide OpenGL by providing an abstraction.
Vladimír Vondruš
@mosra
Framebuffer::read() could be a good place where to mention this, right?
i'm not sure what the mouse picking example does exactly, but it should be possible to offset this by reading from the front buffer i think?
then if you're rendering to the back buffer and reading from the front you shouldn't be stalling anything
Vladimír Vondruš
@mosra
blargh, this is not the default framebuffer, of course
so the solution is to double (triple) buffer that yourself, with multiple FBOs
Fo Nz
@FoNz99089892_twitter
As I read from the OpenGL docs, both buffer swap and FBO binding may cause syncing to the last command for OpenGL. So I think framebuffer should be read right after this happens in any application. So it's outside of "Magnum scope", but I think it's still worth mentioning...
Vladimír Vondruš
@mosra
syncing or flushing?
that a FBO binding would cause the pipeline to sync sounds strange
buffer swap of the default framebuffer causes a glFinish() to be called, yes (because you gotta wait for it to have it presented), but rebinding another FBO shouldn't cause a pipeline stall i think
another option instead of double-buffering is to delay the picking to the beginning of the next frame, before anything gets submitted to GL, but that might complicate the logic a lot
Fo Nz
@FoNz99089892_twitter

that a FBO binding would cause the pipeline to sync sounds strange

I have read that i(t may cause) in "Implicit synchronization" paragraph here (look at the last sentence):
https://www.khronos.org/opengl/wiki/Synchronization

another option instead of double-buffering is to delay the picking to the beginning of the next frame

Yes, that's what I done, and right after the framebuffer is bound but not cleared yet.

Visage
@Azvf
I'm trying to scale a object derived from Object3D and Scene3D, But why doesn't the scale code work after the setTransformation() function?
    _outlineDrawable = SceneGraph::DrawableGroup3D{};
    _outliner.reset(new Outliner(&mesh, *_outlineDrawable, _scene));
    _outliner->scale(Magnum::Vector3{ 1.1f });
    auto mat = objects._attachmentObjects[id]->transformation();
    _outliner->setTransformation(mat);
Guillaume Jacquemin
@williamjcm
setTransformation overrides the existing transformation.
I think you want transform() instead.