RTSS crashes on update after removing cloned material
Description
Environment
1.8 branch (September 2012)
iOS 6
Xcode 4.5.2
GLES 2.0
Activity
M April 26, 2013 at 5:06 AM
Closing resolved issues.
Daniel Sefton April 20, 2013 at 5:50 AM
Thanks for trying to look into it – for now I guess you can resolve as "Cannot Reproduce". Will need a few days of blood & sweat to narrow this one down.
M April 15, 2013 at 3:23 AM
Hmm, I tried this here using GL3+ and it works right. I guess keep looking into it, maybe there's some other step needed.
Daniel Sefton April 11, 2013 at 5:12 PM
Actually the pass modification has nothing to do with it – simply assigning the cloned material to the entity causes the crash.
It's possible that it might be an issue with my scripting bindings, since I can't bind the material shared pointers; maybe it hangs around in existence after being removed or something.
Investigation continues...
Daniel Sefton April 11, 2013 at 6:51 AM(edited)
I put together a test case, but as of yet I can't reproduce it
I'll explain a bit more about what I'm doing. Actually, removing the cloned material doesn't cause the crash IF you don't perform any modifications on that cloned material. Personally I'm changing the culling mode of the cloned material at runtime; and only if I do this, then remove the material on scene exit, it crashes on the next renderOneFrame.
A related issue is that I use getNumSupportedTechniques() to retrieve the last added technique (since the RTSS appends its own technique to all materials). And to modify materials at runtime with the RTSS, you have to modify the technique generated by the RTSS.
Unfortunately it doesn't always work – occasionally the RTSS technique is not generated for the material I want to modify at runtime, and therefore no runtime modifications work. I thought it might be to do with the ShaderGeneratorTechniqueResolverListener callback locking up sometimes, but I'm not sure.
I'll attach the test case as a complete project if/when I can reproduce it, but for now here's essentially what I'm doing:
// On scene enter
Ogre::MaterialPtr mat = Ogre::MaterialManager::getSingleton().getByName("MyMat");
Ogre::MaterialPtr matClone = mat->clone("InvertedMaterial");
// At runtime
myEntity->setMaterialName("InvertedMaterial"); matClone->getTechnique(matClone->getNumSupportedTechniques() - 1)->getPass(0)->setCullingMode(Ogre::CULL_ANTICLOCKWISE);
// On scene exit
Ogre::MaterialManager::getSingleton().remove("InvertedMaterial");
// Crash on next renderOneFrame() call.Details
Details
Assignee
Reporter
Daniel SeftonComponents
Fix versions
Affects versions
Priority
Major
Problem description
A crash occurs on a render update inside the RTSS after removing a material cloned at runtime with MaterialManager::remove("mymat").
Assumptions
It may not be exclusive to cloned materials, but any material created at runtime. Perhaps the RTSS isn't properly cleaning up its generated techniques. An alternate guess is it may be removing the original material rather than the clone.
Stack trace
#0 0x00d8fc64 in Ogre::Technique::operator=(Ogre::Technique const&) at OgreTechnique.cpp:469 #1 0x020f08f8 in Ogre::RTShader::ShaderGenerator::SGTechnique::buildTargetRenderState() at OgreShaderGenerator.cpp:1718 #2 0x020ee8e4 in Ogre::RTShader::ShaderGenerator::SGScheme::validate() at OgreShaderGenerator.cpp:1890 #3 0x020ee754 in Ogre::RTShader::ShaderGenerator::validateScheme(std::string const&) at OgreShaderGenerator.cpp:1120 #4 0x020ee6bc in Ogre::RTShader::ShaderGenerator::preFindVisibleObjects(Ogre::SceneManager*, Ogre::SceneManager::IlluminationRenderStage, Ogre::Viewport*) at OgreShaderGenerator.cpp:1094 #5 0x02105298 in Ogre::RTShader::ShaderGenerator::SGSceneManagerListener::preFindVisibleObjects(Ogre::SceneManager*, Ogre::SceneManager::IlluminationRenderStage, Ogre::Viewport*) at OgreShaderGenerator.h:743 #6 0x00c185c8 in Ogre::SceneManager::firePreFindVisibleObjects(Ogre::Viewport*) at OgreSceneManager.cpp:4146 #7 0x00c0801c in Ogre::SceneManager::_renderScene(Ogre::Camera*, Ogre::Viewport*, bool) at OgreSceneManager.cpp:1477 #8 0x008c3340 in Ogre::Camera::_renderScene(Ogre::Viewport*, bool) at OgreCamera.cpp:427 #9 0x00dd32c8 in Ogre::Viewport::update() at OgreViewport.cpp:224 #10 0x00b998f0 in Ogre::RenderTarget::_updateViewport(Ogre::Viewport*, bool) at OgreRenderTarget.cpp:200 #11 0x00b99670 in Ogre::RenderTarget::_updateAutoUpdatedViewports(bool) at OgreRenderTarget.cpp:178Code for #0 (OgreTechnique.cpp:469):
Technique& Technique::operator=(const Technique& rhs) { // ... // copy passes removeAllPasses(); Passes::const_iterator i, iend; iend = rhs.mPasses.end(); for (i = rhs.mPasses.begin(); i != iend; ++i) { Pass* p = OGRE_NEW Pass(this, (*i)->getIndex(), *(*i)); // <-- CRASH mPasses.push_back(p); } // ... }Code for #1 (OgreShaderGenerator.cpp:1718):
// Create the destination technique and passes. mDstTechnique = mSrcTechnique->getParent()->createTechnique(); mDstTechnique->getUserObjectBindings().setUserAny(SGTechnique::UserKey, Any(this)); *mDstTechnique = *mSrcTechnique; // <-- CRASH mDstTechnique->setSchemeName(mDstTechniqueSchemeName); createSGPasses();Test case will follow later...