Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    ALTernative
    @Amlal93
    except for the subsystem dialog
    ALTernative
    @Amlal93
    Actually nevermind it just doesn't show at all
    Neomorebirus
    @Neomorebirus

    @paroj Sorry for the late reply and thanks for answering. I don’t use addSharedParameters explicitly, but I refer to the shared parameter SSBO in a material file like this:

    compute_program MyComputeProgram_GLSL glsl
    {
        source computeShaderCode.comp.glsl
        syntax glsl450
    
        default_params
        {
            shared_params_ref someSSBO
            shared_params_ref someUBO
        }
    }
    
    compute_program MyComputeProgram unified
    {
        delegate MyComputeProgram_GLSL
    }
    
    material MyComputeProgramMaterial
    {
        technique
        {
            pass
            {
                compute_program_ref MyComputeProgram
                {
                }
            }
        }
    }

    I guess this does addSharedParameters under the hood? My compute shader is also using an UBO shared parameter. The UBO gets correctly updated every frame with setNamedConstant.

    Pavel Rojtberg
    @paroj
    Neomorebirus
    @Neomorebirus

    Hello @paroj, I couldn’t trace the path you requested but if I call GpuSharedparameters::_upload directly like …

    Ogre::GpuSharedParametersPtr ssbo = Ogre::GpuProgramManager::getSingleton().getSharedParameters("someSSBO");
    ssbo->setNamedConstant("data", buffer.data(), 268800);
    ssbo->_upload();

    … I’m able to reach GL3PlusHardwareUniformBuffer::writeData -> GL3PlusHardwareBuffer::writeData -> OGRE_CHECK_GL_ERROR(glBufferData(mTarget, mSizeInBytes, pSource, getGLUsage(mUsage))); (line 136). A buffer update should be taking place in this case, but it won’t show.

    But anyway: Even if I won’t call _upload I get to this exception a bit later after trying to write to the SSBO: OgreAssertDbg(false, "Missing attribute!"); on line 22, OgreGLSLProgramCommon.cpp. The call stack is

    1. SceneManager::_issueRenderOp
    2. SceneManager::updateGpuProgramParameters
    3. GL3PlusRenderSystem::bindGpuProgramParameters
    4. GLSLProgramManager::getActiveProgram
    5. GLSLSeparableProgram::activate
    6. GLSLProgramCommon::extractLayoutQualifiers
    7. GLSLProgramCommon::getAttributeSemanticEnum

    The parameter type for GLSLProgramCommon::getAttributeSemanticEnum is the same as my shared parameters name “someSSBO” when the debugger stops. I assume this is not supposed to happen? I have quadruple checked that I’m writing the name correctly in the shaders, material files and code.

    Pavel Rojtberg
    @paroj

    But anyway: Even if I won’t call _upload I get to this exception a bit later after trying to write to the SSBO: OgreAssertDbg(false, "Missing attribute!"); on line 22

    I think you can safely ignore (comment out) this - at least in current master the results of this method are unused

    Pavel Rojtberg
    @paroj
    for the other issue: can you provide a minimal reproducer? I could then look into it directly
    Neomorebirus
    @Neomorebirus

    @paroj I made a sample (replaced the “Compute” sample) that mimics my original scheme and got overwriting a SSBO working. So it’s quite certain that the problem is in some detail in my original application and I have to sort it out myself.

    Here is the source of the sample if you want to have a look. The idea is that quads are moved each frame with a SSBO and a compute shader and their velocity is set when SSBO is loaded from the CPU. The scheme works as a proper buffer update takes place when user input occurs (the positions and the velocities of the quads change). UBO updating works too.

    Compute.h:
    https://controlc.com/3140cc55

    Compute.cpp:
    https://controlc.com/7b8062f1

    SSBOtest.material (put in Samples/Media/materials/scripts):
    https://controlc.com/ae6c53eb

    computeShaderCode.comp.glsl (put in Samples/Media/materials/programs/GLSL400):
    https://controlc.com/f5b63fef

    ssboTest.vert.glsl (put in Samples/Media/materials/programs/GLSL400):
    https://controlc.com/0dffa78f

    ssboTest.frag.glsl (put in Samples/Media/materials/programs/GLSL400):
    https://controlc.com/f43899cf

    Pavel Rojtberg
    @paroj
    jup, works here too. Note, that if you open a github issue, you can attach actual zip files
    xahon
    @xahon
    Hey. Why doesn't ogre SDK provide debug versions of the libs? I have issues with the standard library because of mismatching of build type of ogre's libs and my ones. I can't build ogre by myself because it says about missing dependencies and i don't want to bother how to install and wire them up on windows
    xahon
    @xahon
    And another question: are ogre and ogre-next interchangeable or ogre-next can be used along with ogre? I don't see that ogre-next has anything related to terrains (maybe another components are missing too which were in ogre)
    Matías N. Goldberg
    @matiasgoldberg_twitter

    are ogre and ogre-next interchangeable or ogre-next

    If you mean as code, it's hard to use interchangeable (not impossible) because of the API differences.
    If you mean can they be installed alongside together, we are working on it on Linux because both versions will try to install the headers in the same directory (OGRECave/ogre-next#232)

    I don't see that ogre-next has anything related to terrains

    Yes ogre-next does, see the Sample_TutorialTerrain (the sample looks crappy but that's because of poor setup)
    Note that it's totally different from the Terrain component offered in ogre.

    Pavel Rojtberg
    @paroj
    Ogre 13 User Survey 2022: https://forms.gle/mUrUhtuXjnf6xN3V9
    tritonas00
    @tritonas00
    Hi! When i try to add a zip resource with read only false i get a segfault
    Ogre::ResourceGroupManager::getSingleton().addResourceLocation(path, "Zip", RGN_TEMP, false, false);
    We use ogre 1.11.6
    Is this normal?
    the segfault happens in OgreArchiveManager.cpp:65 pArch->load();
    with read only true, it works normally, but the archive remains locked as read only, until i close the app
    I want the archive to remain writable so i can delete it, inside the app
    tritonas00
    @tritonas00
    it works fine on Linux, but on Windows i get the above behavior
    Pavel Rojtberg
    @paroj
    zip archives are read-only in ogre. what exactly does not work because of this?
    tritonas00
    @tritonas00
    after addResourceLocation i cant delete the archive, neither in app (deleteResource) neither in windows explorer, permissions are read only, until i close the app
    after this operation the file remains readonly, strangely only on Windows, On Linux permissions kept intact
    we create an in game repository manager and we want to be able to delete mods also
    tritonas00
    @tritonas00
    as long as we don't update the cache (above operation) we can download/remove mods fine
    but, lets say we download a mod, update cache so the mod can be available in game, and re open the repository panel, we can't remove it if we want because of read only permissions
    That happens only on Windows, strangely
    I'm an amateur coder, and my English not so good, so i can demonstrate the issue with a video if that helps
    tritonas00
    @tritonas00
    as soon as this https://github.com/RigsOfRods/rigs-of-rods/blob/master/source/main/resources/CacheSystem.cpp#L972 involve, the zip file remains locked as read only, until we close the game
    tried ResourceGroupManager::getSingleton().addResourceLocation(path, "Zip", RGN_TEMP, false, false) but got segfault
    tritonas00
    @tritonas00
    I'm testing on Windows 10, in vbox
    tritonas00
    @tritonas00
    here is a video with the issue
    tritonas00
    @tritonas00
    isn't destroyResourceGroup enough to release the file?
    It works fine on Linux at least
    SNiLD
    @SNiLD
    linux doesn't lock files like windows does
    tritonas00
    @tritonas00
    hmm
    SNiLD
    @SNiLD
    in linux you can delete file even if some other process is using it, but that's not possible in windows (i'm not 100% certain if this changed in windows 11, but at least since windows 95 up to 10)
    tritonas00
    @tritonas00
    Ok that makes sense
    SNiLD
    @SNiLD
    (here raymond talks about related issue: https://devblogs.microsoft.com/oldnewthing/20220125-00/?p=106194 )
    tritonas00
    @tritonas00
    only deletion is affected though? because i can re-download, null it or anything
    SNiLD
    @SNiLD
    afair you can't rename the file either
    tritonas00
    @tritonas00
    i see
    tritonas00
    @tritonas00
    Ok thank you all very much for the info, really helpful, i will take the issue to our leader dev
    Pavel Rojtberg
    @paroj
    I think ArchiveManager::unload will solve the issue by closing the zip file.
    tritonas00
    @tritonas00
    Indeed! Thank you!
    Pavel Rojtberg
    @paroj
    added it to removeResourceLocation, to make usage more straightforward: OGRECave/ogre#2372
    tritonas00
    @tritonas00
    Nice!
    i use Ogre::FileSystemLayer::removeFile btw, should i go with Ogre::ResourceGroupManager::getSingleton().deleteResource ? are they both unicode safe?
    Pavel Rojtberg
    @paroj
    only the first one deletes files
    tritonas00
    @tritonas00
    Sorry for bothering again, but unload seems to create another issue
    Got segfault when trying to read a previously unloaded zip, which makes sense. But tried Ogre::ArchiveManager::load, after the file is downloaded still no luck