Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 02:18
    faanqfung starred mosra/corrade
  • Jan 27 16:51
    coleekh starred mosra/magnum
  • Jan 27 16:51
    coleekh starred mosra/magnum-examples
  • Jan 27 09:24
    mrxz commented #99
  • Jan 26 14:36
    luqsthunder starred mosra/magnum
  • Jan 26 03:37
    mengguang starred mosra/corrade
  • Jan 25 19:28
    mosra synchronize #601
  • Jan 25 19:28

    mosra on line-rendering

    es3 builds! (compare)

  • Jan 25 09:55
    mosra edited #601
  • Jan 25 01:27
    ian-chiu starred mosra/magnum
  • Jan 24 22:58
    mosra edited #601
  • Jan 24 22:23
    mosra edited #601
  • Jan 24 22:22
    mosra edited #601
  • Jan 24 22:17
    mosra edited #601
  • Jan 24 22:17
    mosra synchronize #601
  • Jan 24 22:17

    mosra on line-rendering

    MeshTools: minor cleanup in a t… MeshTools: fix generateIndices(… MeshTools: check minimal vertex… and 11 more (compare)

  • Jan 24 12:42
    YalimD starred mosra/magnum
  • Jan 24 07:00
    Omni-Engineering starred mosra/toolchains
  • Jan 23 22:21
    mosra synchronize #601
  • Jan 23 22:21

    mosra on line-rendering

    er clean!! fix deprec build & no explicit … and 2 more (compare)

Mathew
@lectroMathew
Hey, in the viewer example we override the used importer plugin based on command-lline argument, like this: Containers::Pointer<Trade::AbstractImporter> importer = manager.loadAndInstantiate(args.value("importer")); Is it possible to just get an arbitrary importer, without providing argments to the manager? Also, if two diferrent plugins are capable of loading file of same type, are they guaranteed to import same data from the file in the end or not?
Vladimír Vondruš
@mosra

Is it possible to just get an arbitrary importer, without providing argments to the manager?

loadAndInstantiate("AnySceneImporter") is what you're looking for, docs (i should probably do that in the example directly, no reason not to)

if two diferrent plugins are capable of loading file of same type, are they guaranteed to import same data from the file in the end or not?

not in general, for example there's Assimp that claims to support all file formats in the world but in reality it crashes on half of them and has massive bugs with the other half ... the alternative implementations are provided so you can make a tradeoff based on whether you want something easy to integrate, as fast as possible, or with certain unique features

here is an overview of importer alternatives for most common formats, together with license info and caveats for each

Mathew
@lectroMathew
out of curiosity, why every AnyXYZImporter plugins have type in their name, but for audio its just AnyImporter lol?
Vladimír Vondruš
@mosra
because Audio::AnyAudioImporter would be redundant
Mathew
@lectroMathew
Ah okay makes sense
Vladimír Vondruš
@mosra
same is for ShaderTools::AnyConverter, which presents itself as AnyShaderConverter
actually i should fix the docs, it looks really silly there
should have been listed as AnyAudioImporter there, yes
Visage
@Azvf

possibly the easiest is to adjust your near and far plane (put near further away and far closer) so it fits the rendered scene as tightly as possible .. but if you have a complex scene the precision might still be too low

I tried the method, it works pretty fine for now. Thanks for your help

Fo Nz
@FoNz99089892_twitter
I'm experimenting my game on Android... I can see the code being run for 60 times per second, but I feel it too slow... I don't know why... maybe because I'm used to look at my desktop 120 Hz monitor...
Fo Nz
@FoNz99089892_twitter
My game does NOT compile shaders through the GL::Shader::compile on Samsung phones without any OpenGL error. I am using Magnum debug flags and glGetError. No errors in OpenGL... It simply always returns false. I'm digging why it happens.
Fo Nz
@FoNz99089892_twitter
Ah ok, glGetErrors returns always NoError because in the Magnum shader compile there are some other GL calls, like glGetShaderiv and such...
I wasn't seeing any error log in Error{} because when you do CORRADE_INTERNAL_ASSERT_OUTPUT(GL::Shader::compile({ vert, frag })) the program just goes into exception before letting the error stream flush to the console!! This should be noted in the docs!!!
Fo Nz
@FoNz99089892_twitter
Ahhh discovered the error. This Magnum feature:
https://doc.magnum.graphics/magnum/classMagnum_1_1GL_1_1Shader.html#GL-Shader-errors
breaks shader compilation on Samsung phones (it's a Mali-G72 in my case), with this error:
P0005: #version must be the first directive/statement in a program
pezcode
@pezcode

Ahhh discovered the error. This Magnum feature:
https://doc.magnum.graphics/magnum/classMagnum_1_1GL_1_1Shader.html#GL-Shader-errors
breaks shader compilation on Samsung phones (it's a Mali-G72 in my case), with this error:
P0005: #version must be the first directive/statement in a program

Are you specifying a GLSL version for your shader? or Version::None

Fo Nz
@FoNz99089892_twitter
Yes, I'm specifying GL ES 300 ONLY for Android. For other systems is GL 330. The problem is this #line 1 thing:
https://github.com/mosra/magnum/blob/3d136503d8a959b4c260b9b60ca925566cc9d095/src/Magnum/GL/Shader.cpp#L722
I'm also getting no default precision defined for variable interpolatedTextureCoordinates. Anyway, this is a driver thing... I need to fix my shaders for Mali GPUs lol
pezcode
@pezcode
The comment above the code you linked seems to indicate that that is handled, so line shouldn't be before version
Vladimír Vondruš
@mosra

just to clarify:

  • either pass Version::GLES300 / Version::GL330 to the constructor, which will add the #version directive automatically (recommended)
  • or pass Version::None and then add a #version directive directly in the source

... but if i understand what you're saying, you somehow get a #line line followed by a #version line? :O

Mathew
@lectroMathew
Hey, I get an exception when creating AbstractShaderProgram at the _id != Implementation::State::DisengagedBinding assert, I assume that's because GL is not initialized at the moment of creation or something? Can I somehow force initialization before any shader creation?
Vladimír Vondruš
@mosra
the shader being the application class member, i suppose, and you delay GL context creation, right?
it's not possible to force GL initialization before creating a shader, but you can delay creating a shader after GL gets initialized
commented example is here: https://doc.magnum.graphics/magnum/opengl-wrapping.html#opengl-wrapping-instances-nocreate i suppose you have it organized a bit differently, but basically start with a NoCreated instance and then when you have GL context ready, move over a properly created instance
Mathew
@lectroMathew
perfect, thanks
Fo Nz
@FoNz99089892_twitter

... but if i understand what you're saying, you somehow get a #line line followed by a #version line? :O

Yes, I was getting that line. Look at the source I linked to you. Anyway, I managed to edit the Magnum source, recompile and make that line go away.

Mathew
@lectroMathew
In my CMake I have BUILD_PLUGINS_STATIC set to ON, yet I still get these two errors every time: PluginManager::Manager::Manager(): none of the plugin search paths in {magnum-d/importers} exists and pluginDirectory was not set, skipping plugin discovery and PluginManager::Manager::load(): plugin AnySceneImporter is not static and was not found in when building with MinGW, however when building with MSVC it seems to correctly find all plugins, what might cause such behavior?
Fo Nz
@FoNz99089892_twitter
MSVC fixes the lib import order for you. Other compiler don't. Check on libs order.
Mathew
@lectroMathew
CMAKE_RUNTIME_OUTPUT_DIRECTORY was the issue, is has already been reported here mosra/magnum#486
马迪
@linuxaged
@mosra what's the status of vulkan support in magnum now? and is there any plan for WebGPU which will be shipped in Chrome 98
Vladimír Vondruš
@mosra

I managed to edit the Magnum source

@FoNz99089892_twitter i'm saying, this exact scenario should work without having to patch anything, i even have a test case for exactly that: https://github.com/mosra/magnum/blob/dbec10dbee8cc3c2b560c6e7de9166c2b6d2f002/src/Magnum/GL/Test/ShaderGLTest.cpp#L195-L225

Look at the source I linked

the question is instead, how does your source look? because this is definitely possible and it only looks like you're doing something differently that results in a #line getting inserted before your #version;) can you show me how the shader gets constructed and populated?

@lectroMathew argh, looks like i should finally step up and resolve all the pending issues

@linuxaged Vulkan support (the low-level APIs) are mostly done right now, what's missing is mostly a bunch of convenience APIs for shaders

right now i'm focusing on vulkan- (batch-) friendly scene import, because without that using Vulkan makes little sense, WebGPU is planned for the next months if I get funding for it

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