"Parsing scripts for resource group OgreInternal
Finished parsing scripts for resource group OgreInternal
Creating resources for group OgreInternal
All done" I Think it might be a deadlock;
@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.
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
SceneManager::_issueRenderOpSceneManager::updateGpuProgramParametersGL3PlusRenderSystem::bindGpuProgramParametersGLSLProgramManager::getActiveProgramGLSLSeparableProgram::activateGLSLProgramCommon::extractLayoutQualifiersGLSLProgramCommon::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.
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
@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
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.
OgreArchiveManager.cpp:65 pArch->load();
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
here is the repo https://github.com/tritonas00/rigs-of-rods/tree/repo
and here is where we parse the zip https://github.com/RigsOfRods/rigs-of-rods/blob/master/source/main/resources/CacheSystem.cpp#L964
ResourceGroupManager::getSingleton().addResourceLocation(path, "Zip", RGN_TEMP, false, false) but got segfault
