GDB Panopticum 2 - strange experience when debugging

Problems building or running the engine, queries about how to use features etc.
User avatar
paul424
Gnome
Posts: 314
Joined: Thu May 24, 2012 7:16 pm
x 13

GDB Panopticum 2 - strange experience when debugging

Post by paul424 »

Ogre Version: :1 12 13:
Operating System: :OpenSuse Linux:
Render System: :OpenGL3+:

By Wikipedia :

"In computer programming jargon, a heisenbug is a software bug that seems to disappear or alter its behavior when one attempts to study it.[1] The term is a pun on the name of Werner Heisenberg, the physicist who first asserted the observer effect of quantum mechanics, which states that the act of observing a system inevitably alters its state. In electronics the traditional term is probe effect, where attaching a test probe to a device changes its behavior. "

Hello, I try to work out my problem with gdb : the Pass looses its fragment program shader ( it's program pointer becomes null after some time and I get exception throw and program terminates). I managed to determine that this regards the material "DCW1110".
On crash I got exception :

desc="RenderSystem does not support FixedFunction, but technique of 'DCW1110' has no Fragment Shader. Use the RTSS or write custom shaders.",

So what I did :
At certain point ( after the game shows up the welcome screen and menu) I set this :

I breakpoint at that line with emplace() method :

Code: Select all

   
void QueuedRenderableCollection::addRenderable(Pass* pass, Renderable* rend) { // ascending and descending sort both set bit 1 if (mOrganisationMode & OM_SORT_DESCENDING) { mSortedDescending.push_back(RenderablePass(rend, pass)); } if (mOrganisationMode & OM_PASS_GROUP) { // Optionally create new pass entry, build a new list // Note that this pass and list are never destroyed until the // engine shuts down, or a pass is destroyed or has it's hash // recalculated, although the lists will be cleared PassGroupRenderableMap::iterator i = mGrouped.emplace(pass, RenderableList()).first; // Insert renderable i->second.push_back(rend); } }

that is :

Code: Select all

 b OgreRenderQueueSortingGrouping.cpp:358 if  (int)strcmp(pass->getParent()->getParent()->getName().c_str(),"DCW1110")==0

and to be sure that no other pass with this materials comes through:

Code: Select all

 b OgreRenderQueueSortingGrouping.cpp:358 if  (int)strcmp(pass->getParent()->getParent()->getName().c_str(),"DCW1110")==0
  && pass!=0x14220c0

( 0x14220c0 is the address of the Pass ... )
I give 'continue' --- the program continues without any breakpoint and finally crashes with OTHER EXCEPTION :

desc="RenderSystem does not support FixedFunction, but technique of 'Lava' has no Fragment Shader. Use the RTSS or write custom shaders.",

Is this some kind of Heisenbug ?

Code: Select all

Ogre.log (optional)
User avatar
sercero
Bronze Sponsor
Bronze Sponsor
Posts: 449
Joined: Sun Jan 18, 2015 4:20 pm
Location: Buenos Aires, Argentina
x 156

Re: GDB Panopticum 2 - strange experience when debugging

Post by sercero »

You could printf the value of the pointer from your own program to determine whether there is a difference between the release/debug versions.

User avatar
paul424
Gnome
Posts: 314
Joined: Thu May 24, 2012 7:16 pm
x 13

Re: GDB Panopticum 2 - strange experience when debugging

Post by paul424 »

You could printf the value of the pointer from your own program to determine whether there is a difference between the release/debug versions.

Pardon ? what value pointer ? Why compare the release/ debug versions ? Do you know that all modern system uses https://en.wikipedia.org/wiki/Address_s ... tion#Linux, that is on Release version it will always produce a different memory layout ? Today I have my segfault .... Maybe you should just rephrase what you mean in a more elaborate version, please :D.

User avatar
paul424
Gnome
Posts: 314
Joined: Thu May 24, 2012 7:16 pm
x 13

Re: GDB Panopticum 2 - strange experience when debugging

Post by paul424 »

Any gdb expert on board ?
When I try to watch the address of aforementioned fragment program I get :

Code: Select all

(gdb) p pass->mProgramUsage[1].get()
$2 = (Ogre::GpuProgramUsage *) 0x13e6fc0
(gdb) watch *(Ogre::GpuProgramUsage *) 0x13e6fc0
Hardware watchpoint 3: *(Ogre::GpuProgramUsage *) 0x13e6fc0
(gdb) c
Continuing.
Warning:
Could not insert hardware watchpoint 3.
Could not insert hardware breakpoints:
You may have requested too many hardware breakpoints/watchpoints.

And for sure I didn't request too many hardware breakpoints/watchpoints, because that's the only one b/w present !

User avatar
sercero
Bronze Sponsor
Bronze Sponsor
Posts: 449
Joined: Sun Jan 18, 2015 4:20 pm
Location: Buenos Aires, Argentina
x 156

Re: GDB Panopticum 2 - strange experience when debugging

Post by sercero »

I see that the way I expressed it seems like suggesting you printf the address of the program.

My suggestion is to printf the value of the pointer from the Shader.

You are using some cool gdb expressions (I didn't even know these existed) and perhaps as you say you are triggering some gdb issue.

Why not printf the pointer from within your game and see if it becomes null?

That was my suggestion.
:wink:

paroj
OGRE Team Member
OGRE Team Member
Posts: 1994
Joined: Sun Mar 30, 2014 2:51 pm
x 1074
Contact:

Re: GDB Panopticum 2 - strange experience when debugging

Post by paroj »

any reason why you dont just use an IDE? e.g. vscode has a fairly competent GDB view:
Image

User avatar
paul424
Gnome
Posts: 314
Joined: Thu May 24, 2012 7:16 pm
x 13

Re: GDB Panopticum 2 - strange experience when debugging

Post by paul424 »

OD doesn't have a valid IDE project file -- especially these VS CODE which would allow me to build the project on Windows ... well I knocked a few doors, I even offered money to do that --- I haven't got any response with a working VS CODE project .... :(

User avatar
paul424
Gnome
Posts: 314
Joined: Thu May 24, 2012 7:16 pm
x 13

Re: GDB Panopticum 2 - strange experience when debugging

Post by paul424 »

ohh ... I have cough the dammed deletion of a pointer ... now the only question is why is it happening in the first place .....

Code: Select all

Thread 1 "opendungeons-pl" hit Hardware watchpoint 2: -location pass->mProgramUsage[1]

Old value = std::unique_ptr<Ogre::GpuProgramUsage> = {get() = 0x95fd0b0}
New value = std::unique_ptr<Ogre::GpuProgramUsage> = {get() = 0x0}
std::__uniq_ptr_impl<Ogre::GpuProgramUsage, std::default_delete<Ogre::GpuProgramUsage> >::reset (this=0x95fa090, __p=0x0) at /usr/include/c++/12/bits/unique_ptr.h:202
warning: Source file is more recent than executable.
202		if (__old_p)
(gdb) bt
#0  std::__uniq_ptr_impl<Ogre::GpuProgramUsage, std::default_delete<Ogre::GpuProgramUsage> >::reset (this=0x95fa090, __p=0x0) at /usr/include/c++/12/bits/unique_ptr.h:202
#1  0x00007ffff6fd08a3 in std::unique_ptr<Ogre::GpuProgramUsage, std::default_delete<Ogre::GpuProgramUsage> >::reset (this=0x95fa090, __p=0x0) at /usr/include/c++/12/bits/unique_ptr.h:501
#2  0x00007ffff6fcee5b in Ogre::Pass::queueForDeletion (this=0x95f9f80) at /home/tom/Downloads/ogre-1.12.13/OgreMain/src/OgrePass.cpp:1517
#3  0x00007ffff7178aeb in Ogre::Technique::removeAllPasses (this=0x95f9d40) at /home/tom/Downloads/ogre-1.12.13/OgreMain/src/OgreTechnique.cpp:352
#4  0x00007ffff717769c in Ogre::Technique::~Technique (this=0x95f9d40, __in_chrg=<optimized out>) at /home/tom/Downloads/ogre-1.12.13/OgreMain/src/OgreTechnique.cpp:49
#5  0x00007ffff6f18add in Ogre::Material::removeTechnique (this=0x12fb0d0, index=1) at /home/tom/Downloads/ogre-1.12.13/OgreMain/src/OgreMaterial.cpp:397
#6  0x00007ffff7d38857 in Ogre::RTShader::ShaderGenerator::SGTechnique::buildTargetRenderState (this=0x95f9c80) at /home/tom/Downloads/ogre-1.12.13/Components/RTShaderSystem/src/OgreShaderGenerator.cpp:1691
#7  0x00007ffff7d390ea in Ogre::RTShader::ShaderGenerator::SGScheme::validate (this=0x1210810) at /home/tom/Downloads/ogre-1.12.13/Components/RTShaderSystem/src/OgreShaderGenerator.cpp:1867
#8  0x00007ffff7d36836 in Ogre::RTShader::ShaderGenerator::validateScheme (this=0x120fe30, schemeName="ShaderGeneratorDefaultScheme") at /home/tom/Downloads/ogre-1.12.13/Components/RTShaderSystem/src/OgreShaderGenerator.cpp:1138
#9  0x00007ffff7d36739 in Ogre::RTShader::ShaderGenerator::preFindVisibleObjects (this=0x120fe30, source=0x7fb31c0, irs=Ogre::SceneManager::IRS_RENDER_TO_TEXTURE, v=0x7ff5aa0) at /home/tom/Downloads/ogre-1.12.13/Components/RTShaderSystem/src/OgreShaderGenerator.cpp:1112
#10 0x00007ffff7d3a716 in Ogre::RTShader::SGSceneManagerListener::preFindVisibleObjects (this=0x8c395a0, source=0x7fb31c0, irs=Ogre::SceneManager::IRS_RENDER_TO_TEXTURE, v=0x7ff5aa0) at /home/tom/Downloads/ogre-1.12.13/Components/RTShaderSystem/src/OgreShaderGenerator.cpp:69
#11 0x00007ffff708ad0e in Ogre::SceneManager::firePreFindVisibleObjects (this=0x7fb31c0, v=0x7ff5aa0) at /home/tom/Downloads/ogre-1.12.13/OgreMain/src/OgreSceneManager.cpp:2713
#12 0x00007ffff70863a0 in Ogre::SceneManager::_renderScene (this=0x7fb31c0, camera=0x8e542d0, vp=0x7ff5aa0, includeOverlays=true) at /home/tom/Downloads/ogre-1.12.13/OgreMain/src/OgreSceneManager.cpp:1337
#13 0x00007ffff6e00ff2 in Ogre::Camera::_renderScene (this=0x8e542d0, vp=0x7ff5aa0) at /home/tom/Downloads/ogre-1.12.13/OgreMain/src/OgreCamera.cpp:496
#14 0x00007ffff71a263a in Ogre::Viewport::update (this=0x7ff5aa0) at /home/tom/Downloads/ogre-1.12.13/OgreMain/src/OgreViewport.cpp:218
#15 0x00007ffff703023f in Ogre::RenderTarget::_updateViewport (this=0x8e3e550, viewport=0x7ff5aa0, updateStatistics=true) at /home/tom/Downloads/ogre-1.12.13/OgreMain/src/OgreRenderTarget.cpp:203
#16 0x00007ffff7030140 in Ogre::RenderTarget::_updateAutoUpdatedViewports (this=0x8e3e550, updateStatistics=true) at /home/tom/Downloads/ogre-1.12.13/OgreMain/src/OgreRenderTarget.cpp:181
#17 0x00007ffff7030071 in Ogre::RenderTarget::updateImpl (this=0x8e3e550) at /home/tom/Downloads/ogre-1.12.13/OgreMain/src/OgreRenderTarget.cpp:158
#18 0x00007ffff7031960 in Ogre::RenderTarget::update (this=0x8e3e550, swap=true) at /home/tom/Downloads/ogre-1.12.13/OgreMain/src/OgreRenderTarget.cpp:565
#19 0x00007ffff7124481 in Ogre::SceneManager::ShadowRenderer::prepareShadowTextures (this=0x7fb35b0, cam=0x7ff2ce0, vp=0x7ff2ad0, lightList=0x7fb3500) at /home/tom/Downloads/ogre-1.12.13/OgreMain/src/OgreShadowRenderer.cpp:868
#20 0x00007ffff708d0a8 in Ogre::SceneManager::prepareShadowTextures (this=0x7fb31c0, cam=0x7ff2ce0, vp=0x7ff2ad0, lightList=0x7fb3500) at /home/tom/Downloads/ogre-1.12.13/OgreMain/src/OgreSceneManager.cpp:3295
#21 0x00007ffff70860ef in Ogre::SceneManager::_renderScene (this=0x7fb31c0, camera=0x7ff2ce0, vp=0x7ff2ad0, includeOverlays=true) at /home/tom/Downloads/ogre-1.12.13/OgreMain/src/OgreSceneManager.cpp:1287
#22 0x00007ffff6e00ff2 in Ogre::Camera::_renderScene (this=0x7ff2ce0, vp=0x7ff2ad0) at /home/tom/Downloads/ogre-1.12.13/OgreMain/src/OgreCamera.cpp:496
#23 0x00007ffff71a263a in Ogre::Viewport::update (this=0x7ff2ad0) at /home/tom/Downloads/ogre-1.12.13/OgreMain/src/OgreViewport.cpp:218
#24 0x00007ffff703023f in Ogre::RenderTarget::_updateViewport (this=0xc8a630, viewport=0x7ff2ad0, updateStatistics=true) at /home/tom/Downloads/ogre-1.12.13/OgreMain/src/OgreRenderTarget.cpp:203
#25 0x00007ffff7030140 in Ogre::RenderTarget::_updateAutoUpdatedViewports (this=0xc8a630, updateStatistics=true) at /home/tom/Downloads/ogre-1.12.13/OgreMain/src/OgreRenderTarget.cpp:181
#26 0x00007ffff7030071 in Ogre::RenderTarget::updateImpl (this=0xc8a630) at /home/tom/Downloads/ogre-1.12.13/OgreMain/src/OgreRenderTarget.cpp:158
#27 0x00007ffff7031960 in Ogre::RenderTarget::update (this=0xc8a630, swap=false) at /home/tom/Downloads/ogre-1.12.13/OgreMain/src/OgreRenderTarget.cpp:565
#28 0x00007ffff70093bf in Ogre::RenderSystem::_updateAllRenderTargets (this=0xce9bf0, swapBuffers=false) at /home/tom/Downloads/ogre-1.12.13/OgreMain/src/OgreRenderSystem.cpp:265
#29 0x00007ffff706ba2b in Ogre::Root::_updateAllRenderTargets (this=0x7fffffffcf40) at /home/tom/Downloads/ogre-1.12.13/OgreMain/src/OgreRoot.cpp:1296
#30 0x00007ffff70698ce in Ogre::Root::renderOneFrame (this=0x7fffffffcf40) at /home/tom/Downloads/ogre-1.12.13/OgreMain/src/OgreRoot.cpp:868
#31 0x00007ffff706987f in Ogre::Root::startRendering (this=0x7fffffffcf40) at /home/tom/Downloads/ogre-1.12.13/OgreMain/src/OgreRoot.cpp:858
#32 0x0000000000a45cac in ODApplication::startClient (this=0x7fffffffdee7) at /home/tom/Opendungeons_github/OpenDungeonstomluchowski/source/ODApplication.cpp:279
#33 0x0000000000a44e1d in ODApplication::startGame (this=0x7fffffffdee7, options=...) at /home/tom/Opendungeons_github/OpenDungeonstomluchowski/source/ODApplication.cpp:81
#34 0x0000000000a475f8 in main (argc=1, argv=0x7fffffffe198) at /home/tom/Opendungeons_github/OpenDungeonstomluchowski/source/main.cpp:87

This code seems to do that: note the comment;

// Remove existing destination technique and passes
// in order to build it again from scratch.

But the thing is it never rebuilds it again !

Code: Select all

//-----------------------------------------------------------------------------
void ShaderGenerator::SGTechnique::buildTargetRenderState()
{
    // Remove existing destination technique and passes
    // in order to build it again from scratch.
    if (mDstTechnique != NULL)
    {
        Material* mat = mSrcTechnique->getParent();

    for (unsigned short i=0; i < mat->getNumTechniques(); ++i)
    {
        if (mat->getTechnique(i) == mDstTechnique)
        {
            mat->removeTechnique(i);
            break;
        }
    }
    destroySGPasses();      
}
    
// Create the destination technique and passes.
mDstTechnique   = mSrcTechnique->getParent()->createTechnique();
mDstTechnique->getUserObjectBindings().setUserAny(SGTechnique::UserKey, this);
*mDstTechnique  = *mSrcTechnique;
mDstTechnique->setSchemeName(mDstTechniqueSchemeName);
createSGPasses();


// Build render state for each pass.
for (SGPassIterator itPass = mPassEntries.begin(); itPass != mPassEntries.end(); ++itPass)
{
	assert(!(*itPass)->isIlluminationPass()); // this is not so important, but intended to be so here.
    (*itPass)->buildTargetRenderState();
}

// Turn off the build destination technique flag.
mBuildDstTechnique = false;
}

EDIT : could someone explain in layman terms, why it tries to Remove existing destination technique and passes
and then tries to rebuild ?

paroj
OGRE Team Member
OGRE Team Member
Posts: 1994
Joined: Sun Mar 30, 2014 2:51 pm
x 1074
Contact:

Re: GDB Panopticum 2 - strange experience when debugging

Post by paroj »

paul424 wrote: Mon Jun 27, 2022 6:31 pm

OD doesn't have a valid IDE project file -- especially these VS CODE which would allow me to build the project on Windows ... well I knocked a few doors, I even offered money to do that --- I haven't got any response with a working VS CODE project .... :(

vscode works on linux too. you dont need any project file. You just have to point gdb to your executable - see e.g. https://code.visualstudio.com/docs/cpp/ ... nvironment

If you use the cmake extension, it will even auto-detect the executables.

User avatar
paul424
Gnome
Posts: 314
Joined: Thu May 24, 2012 7:16 pm
x 13

Re: GDB Panopticum 2 - strange experience when debugging

Post by paul424 »

I slowly mature to amend the Ogre with custom procedure of logging in when GPU program's shared pointer's deleter is called ... Is this a way to go ?

User avatar
paul424
Gnome
Posts: 314
Joined: Thu May 24, 2012 7:16 pm
x 13

Re: GDB Panopticum 2 - strange experience when debugging

Post by paul424 »

With this

Code: Select all

        struct mydeleter
        {
            void operator()(GpuProgramUsage* foo)
            {
                stringstream str;
                str << "Releasing pointer of " << foo << "of name " << foo->getProgramName() << "of type " << foo->getType() << " in " << boost::stacktrace::stacktrace() << std::endl;
                LogManager::getSingleton().logMessage(str.str());
                delete foo;
            }
        };

    	using GpuProgramUsageUniquePtr = std::unique_ptr<Ogre::GpuProgramUsage, Ogre::mydeleter>;   
    	
    	
    

I managed to get this info :

Code: Select all

11:06:46: Releasing pointer of 0x9239df0of name myDCW1110TileFragmentShaderof type 1 in  
0# 0x00007FFFF6FC8C96 in /usr/local/lib/libOgreMain.so.1.12.13 1# 0x00007FFFF6FCA3DF in /usr/local/lib/libOgreMain.so.1.12.13 2# 0x00007FFFF6FC96CF in /usr/local/lib/libOgreMain.so.1.12.13 3# Ogre::Pass::setGpuProgram(Ogre::GpuProgramType, Ogre::SharedPtr<Ogre::GpuProgram> const&, bool) in /usr/local/lib/libOgreMain.so.1.12.13 4# Ogre::Pass::setGpuProgram(Ogre::GpuProgramType, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, bool) in /usr/local/lib/libOgreMain.so.1.12.13 5# Ogre::Pass::setFragmentProgram(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, bool) in /usr/local/lib/libOgreMain.so.1.12.13 6# Ogre::Technique::_compileIlluminationPasses() in /usr/local/lib/libOgreMain.so.1.12.13 7# Ogre::Technique::getIlluminationPasses() in /usr/local/lib/libOgreMain.so.1.12.13 8# Ogre::RenderPriorityGroup::addSolidRenderableSplitByLightType(Ogre::Technique*, Ogre::Renderable*) in /usr/local/lib/libOgreMain.so.1.12.13 9# Ogre::RenderPriorityGroup::addRenderable(Ogre::Renderable*, Ogre::Technique*) in /usr/local/lib/libOgreMain.so.1.12.13 10# 0x00007FFFF6FF34EC in /usr/local/lib/libOgreMain.so.1.12.13 11# Ogre::RenderQueue::addRenderable(Ogre::Renderable*, unsigned char, unsigned short) in /usr/local/lib/libOgreMain.so.1.12.13 12# Ogre::RenderQueue::addRenderable(Ogre::Renderable*) in /usr/local/lib/libOgreMain.so.1.12.13 13# Ogre::Entity::_updateRenderQueue(Ogre::RenderQueue*) in /usr/local/lib/libOgreMain.so.1.12.13 14# Ogre::RenderQueue::processVisibleObject(Ogre::MovableObject*, Ogre::Camera*, bool, Ogre::VisibleObjectsBoundsInfo*) in /usr/local/lib/libOgreMain.so.1.12.13 15# Ogre::SceneNode::_findVisibleObjects(Ogre::Camera*, Ogre::RenderQueue*, Ogre::VisibleObjectsBoundsInfo*, bool, bool, bool) in /usr/local/lib/libOgreMain.so.1.12.13 16# Ogre::SceneNode::_findVisibleObjects(Ogre::Camera*, Ogre::RenderQueue*, Ogre::VisibleObjectsBoundsInfo*, bool, bool, bool) in /usr/local/lib/libOgreMain.so.1.12.13 17# Ogre::SceneNode::_findVisibleObjects(Ogre::Camera*, Ogre::RenderQueue*, Ogre::VisibleObjectsBoundsInfo*, bool, bool, bool) in /usr/local/lib/libOgreMain.so.1.12.13 18# Ogre::SceneNode::_findVisibleObjects(Ogre::Camera*, Ogre::RenderQueue*, Ogre::VisibleObjectsBoundsInfo*, bool, bool, bool) in /usr/local/lib/libOgreMain.so.1.12.13 19# Ogre::SceneManager::_findVisibleObjects(Ogre::Camera*, Ogre::VisibleObjectsBoundsInfo*, bool) in /usr/local/lib/libOgreMain.so.1.12.13 20# Ogre::SceneManager::_renderScene(Ogre::Camera*, Ogre::Viewport*, bool) in /usr/local/lib/libOgreMain.so.1.12.13 21# Ogre::Camera::_renderScene(Ogre::Viewport*) in /usr/local/lib/libOgreMain.so.1.12.13 22# Ogre::Viewport::update() in /usr/local/lib/libOgreMain.so.1.12.13 23# Ogre::RenderTarget::_updateViewport(Ogre::Viewport*, bool) in /usr/local/lib/libOgreMain.so.1.12.13 24# Ogre::RenderTarget::_updateAutoUpdatedViewports(bool) in /usr/local/lib/libOgreMain.so.1.12.13 25# Ogre::RenderTarget::updateImpl() in /usr/local/lib/libOgreMain.so.1.12.13 26# Ogre::RenderTarget::update(bool) in /usr/local/lib/libOgreMain.so.1.12.13 27# Ogre::RenderSystem::_updateAllRenderTargets(bool) in /usr/local/lib/libOgreMain.so.1.12.13 28# Ogre::Root::_updateAllRenderTargets() in /usr/local/lib/libOgreMain.so.1.12.13 29# Ogre::Root::renderOneFrame() in /usr/local/lib/libOgreMain.so.1.12.13 30# Ogre::Root::startRendering() in /usr/local/lib/libOgreMain.so.1.12.13 31# ODApplication::startClient() in /home/tom/Opendungeons_github/OpenDungeonstomluchowski/opendungeons-plus 32# ODApplication::startGame(boost::program_options::variables_map&) in /home/tom/Opendungeons_github/OpenDungeonstomluchowski/opendungeons-plus 33# main in /home/tom/Opendungeons_github/OpenDungeonstomluchowski/opendungeons-plus 34# 0x00007FFFF67395B0 in /lib64/libc.so.6 35# __libc_start_main in /lib64/libc.so.6 36# _start in /home/tom/Opendungeons_github/OpenDungeonstomluchowski/opendungeons-plus

Could someone explain what that code expert does ?

Code: Select all

    void Pass::setGpuProgram(GpuProgramType type, const GpuProgramPtr& program, bool resetParams)
    {
        OGRE_LOCK_MUTEX(mGpuProgramChangeMutex);

    GpuProgramUsageUniquePtr& programUsage = getProgramUsage(type);

    // Turn off fragment program if name blank
    if (!program)
    {
        programUsage.reset();
    }
    else
    {
        if (!programUsage)
        {
            programUsage.reset(new GpuProgramUsage(type, this));
        }
        programUsage->setProgram(program, resetParams);
    }
    // Needs recompilation
    _notifyNeedsRecompile();

    if( Pass::getHashFunction() == Pass::getBuiltinHashFunction( Pass::MIN_GPU_PROGRAM_CHANGE ) )
    {
        _dirtyHash();
    }
}
loath
Platinum Sponsor
Platinum Sponsor
Posts: 290
Joined: Tue Jan 17, 2012 5:18 am
x 67

Re: GDB Panopticum 2 - strange experience when debugging

Post by loath »

is "DCW1110" one of your own materials? is this a "random" crash bug or are you adding a new feature and seeing this crash? some context might help figure out the issue.

as to the code: i assume Pass::setGpuProgram () allows you to pass in an empty / null program in order to clear out the pass's program.

i'm on 13.4.1 which may be different but it looks like Technique::_compileIlluminationPasses() clears all the passes out first in order to rebuild them.

User avatar
paul424
Gnome
Posts: 314
Joined: Thu May 24, 2012 7:16 pm
x 13

Re: GDB Panopticum 2 - strange experience when debugging

Post by paul424 »

Sorry, Well the context is : I try to finalize the workings of the dynamic shadows. TO do that I set

Code: Select all

        mSceneManager->setShadowTechnique(Ogre::ShadowTechnique::SHADOWTYPE_TEXTURE_ADDITIVE);

But at least some materials seems to loose it's fragment programs and I get

Code: Select all

#2  0x00007ffff6dbc93c in Ogre::ExceptionFactory::throwException (code=Ogre::Exception::ERR_INVALID_STATE, 
    desc="RenderSystem does not support FixedFunction, but technique of 'DCW1110' has no Fragment Shader. Use the RTSS or write custom shaders.", src="SceneManager::_setPass", 
    file=0x7ffff71ec5a0 "/home/tom/Downloads/ogre-1.12.13/OgreMain/src/OgreSceneManager.cpp", line=966) at /home/tom/Downloads/ogre-1.12.13/OgreMain/include/OgreException.h:281
#3  0x00007ffff708206c in Ogre::SceneManager::_setPass (this=0x7fb4710, pass=0x9397b70, evenIfSuppressed=false, shadowDerivation=true)
    at /home/tom/Downloads/ogre-1.12.13/OgreMain/src/OgreSceneManager.cpp:966
#4  0x00007ffff7084886 in Ogre::SceneManager::BRAND NAME::visit (this=0x7fb4f10, p=0x9397b70, rs=std::vector of length 15, capacity 16 = {...})
    at /home/tom/Downloads/ogre-1.12.13/OgreMain/src/OgreSceneManager.cpp:1716
#5  0x00007ffff6ff9c48 in Ogre::QueuedRenderableCollection::acceptVisitorGrouped (this=0x7737b20, visitor=0x7fb4f10)
    at /home/tom/Downloads/ogre-1.12.13/OgreMain/src/OgreRenderQueueSortingGrouping.cpp:411
#6  0x00007ffff6ff9b1b in Ogre::QueuedRenderableCollection::acceptVisitor (this=0x7737b20, visitor=0x7fb4f10, om=Ogre::QueuedRenderableCollection::OM_PASS_GROUP)
    at /home/tom/Downloads/ogre-1.12.13/OgreMain/src/OgreRenderQueueSortingGrouping.cpp:389
#7  0x00007ffff7084d16 in Ogre::SceneManager::renderObjects (this=0x7fb4710, objs=..., om=Ogre::QueuedRenderableCollection::OM_PASS_GROUP, lightScissoringClipping=false, 
    doLightIteration=false, manualLightList=0x7fffffffb370, transparentShadowCastersMode=false) at /home/tom/Downloads/ogre-1.12.13/OgreMain/src/OgreSceneManager.cpp:1814
#8  0x00007ffff711fe21 in Ogre::SceneManager::ShadowRenderer::renderAdditiveTextureShadowedQueueGroupObjects (this=0x7fb4b00, pGroup=0x8e573b0, 
    om=Ogre::QueuedRenderableCollection::OM_PASS_GROUP) at /home/tom/Downloads/ogre-1.12.13/OgreMain/src/OgreShadowRenderer.cpp:499
#9  0x00007ffff711e693 in Ogre::SceneManager::ShadowRenderer::render (this=0x7fb4b00, group=0x8e573b0, om=Ogre::QueuedRenderableCollection::OM_PASS_GROUP)
    at /home/tom/Downloads/ogre-1.12.13/OgreMain/src/OgreShadowRenderer.cpp:116
#10 0x00007ffff7084e86 in Ogre::SceneManager::_renderQueueGroupObjects (this=0x7fb4710, pGroup=0x8e573b0, om=Ogre::QueuedRenderableCollection::OM_PASS_GROUP)
    at /home/tom/Downloads/ogre-1.12.13/OgreMain/src/OgreSceneManager.cpp:1841
#11 0x00007ffff70847b3 in Ogre::SceneManager::renderVisibleObjectsDefaultSequence (this=0x7fb4710) at /home/tom/Downloads/ogre-1.12.13/OgreMain/src/OgreSceneManager.cpp:1686
#12 0x00007ffff708454c in Ogre::SceneManager::_renderVisibleObjects (this=0x7fb4710) at /home/tom/Downloads/ogre-1.12.13/OgreMain/src/OgreSceneManager.cpp:1603
#13 0x00007ffff70838f9 in Ogre::SceneManager::_renderScene (this=0x7fb4710, camera=0x7ff47f0, vp=0x7ff45e0, includeOverlays=true)

in short "RenderSystem does not support FixedFunction, but technique of 'DCW1110' has no Fragment Shader. Use the RTSS or write custom shaders."
and in this thread I am wondering why oh why it looses this fragment program.
I have tried to log on shared pointers deleter's action but I see that was a red herring -- that's the way Technique::_compileIlluminationPasses() works:

Code: Select all

                            // Copy existing pass
                            Pass* newPass = OGRE_NEW Pass(this, p->getIndex(), *p);
			     ......
                            // Remove any fragment program
                            if (newPass->hasFragmentProgram())
                                newPass->setFragmentProgram("");

It stipes off THE COPY of a pass ....
And that's the only deleter in the log's. So the Fragment program is never explicitly deleted, it must have been lost when copying over material, techinque or pass ... :(

EDIT:
I setup the logs on Passes' Constructor.
The pointer from the raised throw is INDEED created within Ogre::Technique::_compileIlluminationPasses()!!!

Code: Select all

11:22:20: Creating the pass 0x93f1730 The Copy of 0x18175a0 of material Lava in 
 0# Ogre::Pass::Pass(Ogre::Technique*, unsigned short, Ogre::Pass const&) in /usr/local/lib/libOgreMain.so.1.12.13
 1# Ogre::Technique::_compileIlluminationPasses() in /usr/local/lib/libOgreMain.so.1.12.13
 2# Ogre::Technique::getIlluminationPasses() in /usr/local/lib/libOgreMain.so.1.12.13
 3# Ogre::RenderPriorityGroup::addSolidRenderableSplitByLightType(Ogre::Technique*, Ogre::Renderable*) in /usr/local/lib/libOgreMain.so.1.12.13
 4# Ogre::RenderPriorityGroup::addRenderable(Ogre::Renderable*, Ogre::Technique*) in /usr/local/lib/libOgreMain.so.1.12.13

To sum up : Ogre's stripes off some passes from fragment programs in " Technique::compileIlluminationPasses() "and shortly after it raises an exception "RenderSystem does not support FixedFunction, but technique of 'Lava' has no Fragment Shader. Use the RTSS or write custom shaders.", src="SceneManager::setPass" ( notice it's lava this time cause I have loaded a different, smaller map this time).

User avatar
paul424
Gnome
Posts: 314
Joined: Thu May 24, 2012 7:16 pm
x 13

Re: GDB Panopticum 2 - strange experience when debugging

Post by paul424 »

and commenting out the code

Code: Select all

                       //   if (newPass->hasFragmentProgram())
                                //		newPass->setFragmentProgram("");

Allow to start up a game, with a lots of rendering artifacts, but it allows to start ...hmmm....

loath
Platinum Sponsor
Platinum Sponsor
Posts: 290
Joined: Tue Jan 17, 2012 5:18 am
x 67

Re: GDB Panopticum 2 - strange experience when debugging

Post by loath »

it looks like you had shadows previously from the videos on youtube. are you changing your shadow setup?

can you post one of the materials that is failing (ex. "DCW1110" or "Lava" etc) including your shaders?

do you use RTSS at all or are you 100% on your own shaders?

User avatar
paul424
Gnome
Posts: 314
Joined: Thu May 24, 2012 7:16 pm
x 13

Re: GDB Panopticum 2 - strange experience when debugging

Post by paul424 »

I do try to work out Ogre::ShadowTechnique::SHADOWTYPE_TEXTURE_ADDITIVE.
As you see it worked, but not well enough --- some of the shadows were "scrambled" especially when the shadow was between light source and camera...
I do use mixed shaders --- some entities use RTSS -- mostly the walking creatures and some entities use custom shaders -- here mostly the building blocks of the terrain -- dirt, lava, rock, gold etc.
Here's example material files :

Code: Select all

vertex_program myLavaVertexShader glsl
{
  source LavaDistortion.vert
    default_params
    {
        param_named_auto projectionMatrix projection_matrix
        param_named_auto viewMatrix view_matrix
        param_named_auto worldMatrix world_matrix
        param_named_auto time1 time 
    }
  
} fragment_program myLavaFragmentShader glsl { source LavaDistortion.frag default_params { param_named_auto time2 time } } material Lava //: RTSS/NormalMapping_MultiPass { // receive_shadows on technique { pass { vertex_program_ref myLavaVertexShader { } fragment_program_ref myLavaFragmentShader { param_named iChannel0 int 0 param_named iChannel1 int 1 } texture_unit { texture Lava.png 2d } texture_unit { texture Channel0.png 2d } } } }

and the fragment shader :

Code: Select all

#version 330 core
#extension GL_ARB_explicit_uniform_location : enable
 
// The MIT License
// Copyright © 2017 Inigo Quilez
// Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.


// One way to avoid texture tile repetition one using one small
// texture to cover a huge area. Basically, it creates 8 different
// offsets for the texture and picks two to interpolate between.
//
// Unlike previous methods that tile space (https://www.shadertoy.com/view/lt2GDd
// or https://www.shadertoy.com/view/4tsGzf), this one uses a random
// low frequency texture (cache friendly) to pick the actual
// texture's offset.
//
// Also, this one mipmaps to something (ugly, but that's better than
// not having mipmaps at all like in previous methods)
//
// More info here: http://www.iquilezles.org/www/articles/texturerepetition/texturerepetition.htm

uniform sampler2D iChannel0;
uniform sampler2D iChannel1;
in vec2 out_UV0;
in vec3 FragPos;
uniform float time2;
out vec4 color;



float sum( vec3 v ) { return v.x+v.y+v.z; }

vec3 textureNoTile( in vec2 x, float v )
{
    float k = texture( iChannel1, 0.005*x ).x; // cheap (cache friendly) lookup
    
vec2 duvdx = dFdx( x ); vec2 duvdy = dFdy( x ); float l = k*8.0; float f = fract(l); #if 1 float ia = floor(l); // my method float ib = ia + 1.0; #else float ia = floor(l+0.5); // suslik's method (see comments) float ib = floor(l); f = min(f, 1.0-f)*2.0; #endif
vec2 offa = sin(vec2(3.0,7.0)*ia); // can replace with any other hash vec2 offb = sin(vec2(3.0,7.0)*ib); // can replace with any other hash vec3 cola = textureGrad( iChannel0, x + v*offa, duvdx, duvdy ).xyz; vec3 colb = textureGrad( iChannel0, x + v*offb, duvdx, duvdy ).xyz; return mix( cola, colb, smoothstep(0.2,0.8,f-0.1*sum(cola-colb)) ); } void main( ) { vec2 uv = FragPos.xy/2.0 ; float f = smoothstep( -1.0, 1.0, sin(time2/50.0) ); vec3 col = textureNoTile( (uv), f ); color = vec4( col, 1.0 ); }

Also the DCW1110 material :

Code: Select all


vertex_program myDCW1110TileVertexShader glsl
{
  source DCW.vert
    default_params
    {
        param_named_auto projectionMatrix projection_matrix
        param_named_auto viewMatrix view_matrix
        param_named_auto worldMatrix world_matrix
        param_named_auto lightMatrix texture_worldviewproj_matrix
    }
  
} fragment_program myDCW1110TileFragmentShader glsl { source DCW.frag default_params { param_named_auto ambientLightColour ambient_light_colour param_named_auto lightDiffuseColour light_diffuse_colour 0.0 param_named_auto lightSpecularColour light_specular_colour 0.0 param_named_auto lightPos light_position 0.0 0.0 0.0 0.0 param_named_auto cameraPosition camera_position
param_named_auto diffuseSurface surface_diffuse_colour param_named seatColor float4 1.0 1.0 1.0 1.0 param_named shadowingEnabled bool false
} } material DCW1110 //: RTSS/NormalMapping_MultiPass {
technique { pass { diffuse 1.0 1.0 1.0 1.0 vertex_program_ref myDCW1110TileVertexShader { } fragment_program_ref myDCW1110TileFragmentShader { param_named decalmap int 0 param_named normalmap int 1 param_named crossmap int 2 param_named shadowmap int 3 } // We use blending, so that we can see the underlying texture. texture_unit decalmap { texture DungeonClaimedWall1110.png } texture_unit normalmap { texture DungeonClaimedWall1110Normal.png } texture_unit crossmap { texture DungeonClaimedWallMask.png } texture_unit shadowmap { content_type shadow tex_address_mode clamp filtering bilinear } } } }

and fragment :

Code: Select all

#version 330  core


uniform sampler2D decalmap;
uniform sampler2D normalmap;
uniform sampler2D crossmap;
uniform sampler2D shadowmap;

uniform vec4 ambientLightColour;
uniform vec4 lightDiffuseColour; 
uniform vec4 lightSpecularColour;
uniform vec4 lightPos;
uniform vec4 cameraPosition;
uniform vec4 diffuseSurface;
uniform vec4 seatColor;
uniform bool shadowingEnabled;
in vec2 out_UV0;
in vec2 out_UV1;
in vec2 out_UV2;
in vec3 FragPos;
in vec4 VertexPos;
in mat3 TBN;
 
out vec4 color;

void main (void)  
{ // compute Normal vec3 Normal = texture(normalmap, out_UV1.st).rgb; Normal.xyz = 2 * Normal.xyz - (1.0,1.0,1.0); Normal = normalize(TBN * Normal); vec4 shadow = vec4(1.0, 1.0, 1.0,1.0); vec4 tmpVertexPos = VertexPos; // compute shadowmap if(shadowingEnabled){ if(tmpVertexPos.z > 0 ){ tmpVertexPos /= tmpVertexPos.w; shadow = texture(shadowmap, tmpVertexPos.xy); } } // compute lightDir vec3 lightDir = normalize(lightPos.xyz - FragPos*lightPos.w); // compute Specular vec3 viewDirection = normalize( cameraPosition.xyz - FragPos); vec3 reflectedLightDirection = normalize(reflect(-1.0*lightDir.xyz,Normal)); float spec = max(dot(reflectedLightDirection, viewDirection ), 0.0) ; spec = pow(spec,16); vec3 specular = spec * lightSpecularColour.rgb; // compute Diffuse float diff = max(dot(lightDir,Normal), 0.0); vec3 diffuse = diff * lightDiffuseColour.rgb ; vec3 result; // precompute the lighting term vec3 lightingTerm = (diffuse + specular + ambientLightColour.rgb/2.0 ) * shadow.rgb; vec4 crossMap = texture(crossmap, out_UV2.st); if(crossMap.r < 0.00005) { vec3 texelColor = texture(decalmap, out_UV0.st).rgb; if(diffuseSurface==vec4(1.0,1.0,1.0,1.0)) result = lightingTerm * texelColor; else result = lightingTerm * mix(texelColor,diffuseSurface.rgb,0.5); } else{ if(diffuseSurface==vec4(1.0,1.0,1.0,1.0)) result = lightingTerm * crossMap.rgb * seatColor.rgb; else result = lightingTerm * mix( crossMap.rgb * seatColor.rgb,diffuseSurface.rgb,0.5); } color = vec4( result.xyz, 1.0); }
loath
Platinum Sponsor
Platinum Sponsor
Posts: 290
Joined: Tue Jan 17, 2012 5:18 am
x 67

Re: GDB Panopticum 2 - strange experience when debugging

Post by loath »

what type of shadows were you using before? you have a single light source and therefore it's the only shadow caster?

my best guess is your game is trying to render a shadow receiver pass and it's unable to convert your custom material (ex "DCW1110") to a shadow receiving version of the material.

to figure out what's going on instead of me just guessing, i'd put a breakpoint in Ogre::SceneManager::_setPass () when it's called by the shadow renderer below this function: Ogre::ShadowRenderer::renderAdditiveTextureShadowedQueueGroupObjects ().

in _setPass(), is mIlluminationStage == IRS_RENDER_RECEIVER_PASS? if so, find out why the call to deriveShadowReceiverPass () is failing or why it can't fall back to RTSS.

User avatar
paul424
Gnome
Posts: 314
Joined: Thu May 24, 2012 7:16 pm
x 13

Re: GDB Panopticum 2 - strange experience when debugging

Post by paul424 »

Before it seems I also used SHADOW_TEXTURE_ADDITIVE_INTEGRATED .... but I get rid of it cause that's for someone writing his own shadow casters scripts.

Yes I have only one light source and that's the only shadow caster.....

Err are you sure it should be below the function : Ogre::ShadowRenderer::renderAdditiveTextureShadowedQueueGroupObjects () ? I try to break on it or to break on _setPass() when the prev method is present in the stack frame... but it doesn't stop on any of such breakpoints ..... seems the control flow doesn't even reach that function....

loath
Platinum Sponsor
Platinum Sponsor
Posts: 290
Joined: Tue Jan 17, 2012 5:18 am
x 67

Re: GDB Panopticum 2 - strange experience when debugging

Post by loath »

here is the stack i was investigating and where you should set your breakpoint: (assuming this is the behavior you're seeing)

Code: Select all

#2  0x00007ffff6dbc93c in Ogre::ExceptionFactory::throwException (code=Ogre::Exception::ERR_INVALID_STATE, 
    desc="RenderSystem does not support FixedFunction, but technique of 'DCW1110' has no Fragment Shader. Use the RTSS or write custom shaders.", src="SceneManager::_setPass", 
    file=0x7ffff71ec5a0 "/home/tom/Downloads/ogre-1.12.13/OgreMain/src/OgreSceneManager.cpp", line=966) at /home/tom/Downloads/ogre-1.12.13/OgreMain/include/OgreException.h:281
#3  0x00007ffff708206c in Ogre::SceneManager::_setPass (this=0x7fb4710, pass=0x9397b70, evenIfSuppressed=false, shadowDerivation=true)
    at /home/tom/Downloads/ogre-1.12.13/OgreMain/src/OgreSceneManager.cpp:966
#4  0x00007ffff7084886 in Ogre::SceneManager::BRAND NAME::visit (this=0x7fb4f10, p=0x9397b70, rs=std::vector of length 15, capacity 16 = {...})
    at /home/tom/Downloads/ogre-1.12.13/OgreMain/src/OgreSceneManager.cpp:1716
#5  0x00007ffff6ff9c48 in Ogre::QueuedRenderableCollection::acceptVisitorGrouped (this=0x7737b20, visitor=0x7fb4f10)
    at /home/tom/Downloads/ogre-1.12.13/OgreMain/src/OgreRenderQueueSortingGrouping.cpp:411
#6  0x00007ffff6ff9b1b in Ogre::QueuedRenderableCollection::acceptVisitor (this=0x7737b20, visitor=0x7fb4f10, om=Ogre::QueuedRenderableCollection::OM_PASS_GROUP)
    at /home/tom/Downloads/ogre-1.12.13/OgreMain/src/OgreRenderQueueSortingGrouping.cpp:389
#7  0x00007ffff7084d16 in Ogre::SceneManager::renderObjects (this=0x7fb4710, objs=..., om=Ogre::QueuedRenderableCollection::OM_PASS_GROUP, lightScissoringClipping=false, 
    doLightIteration=false, manualLightList=0x7fffffffb370, transparentShadowCastersMode=false) at /home/tom/Downloads/ogre-1.12.13/OgreMain/src/OgreSceneManager.cpp:1814
#8  0x00007ffff711fe21 in Ogre::SceneManager::ShadowRenderer::renderAdditiveTextureShadowedQueueGroupObjects (this=0x7fb4b00, pGroup=0x8e573b0, 
    om=Ogre::QueuedRenderableCollection::OM_PASS_GROUP) at /home/tom/Downloads/ogre-1.12.13/OgreMain/src/OgreShadowRenderer.cpp:499
#9  0x00007ffff711e693 in Ogre::SceneManager::ShadowRenderer::render (this=0x7fb4b00, group=0x8e573b0, om=Ogre::QueuedRenderableCollection::OM_PASS_GROUP)
    at /home/tom/Downloads/ogre-1.12.13/OgreMain/src/OgreShadowRenderer.cpp:116
#10 0x00007ffff7084e86 in Ogre::SceneManager::_renderQueueGroupObjects (this=0x7fb4710, pGroup=0x8e573b0, om=Ogre::QueuedRenderableCollection::OM_PASS_GROUP)
    at /home/tom/Downloads/ogre-1.12.13/OgreMain/src/OgreSceneManager.cpp:1841
#11 0x00007ffff70847b3 in Ogre::SceneManager::renderVisibleObjectsDefaultSequence (this=0x7fb4710) at /home/tom/Downloads/ogre-1.12.13/OgreMain/src/OgreSceneManager.cpp:1686
#12 0x00007ffff708454c in Ogre::SceneManager::_renderVisibleObjects (this=0x7fb4710) at /home/tom/Downloads/ogre-1.12.13/OgreMain/src/OgreSceneManager.cpp:1603
#13 0x00007ffff70838f9 in Ogre::SceneManager::_renderScene (this=0x7fb4710, camera=0x7ff47f0, vp=0x7ff45e0, includeOverlays=true)

loath
Platinum Sponsor
Platinum Sponsor
Posts: 290
Joined: Tue Jan 17, 2012 5:18 am
x 67

Re: GDB Panopticum 2 - strange experience when debugging

Post by loath »

paul424 wrote: Tue Jul 05, 2022 7:34 pm

Before it seems I also used SHADOW_TEXTURE_ADDITIVE_INTEGRATED .... but I get rid of it cause that's for someone writing his own shadow casters scripts.

with _INTEGRATED your lit / lighting shaders needs to handle the custom receiving and you also need to provide custom casters. (at least, that's how i do it)

if you remove _INTEGRATED Ogre adds additional passes to your material in order to receive shadows. so the perf isn't as good due to the additional pass but you don't need to include shadow receiving in your shader. i've never used NON-integrated shadows but my guess is your lit / lighting pass can't be cloned for the non-INTEGRATED shadow pass.

a) non-INTEGRADED shadows is adding an additional shadow pass
b) it tries to clone your lit / lighting shader for this extra shadow pass (ex. "DCW1110")
c) it first clears the pass and tries to initialize it but fails for some reason
d) error message saying "no fixed function..."

loath
Platinum Sponsor
Platinum Sponsor
Posts: 290
Joined: Tue Jan 17, 2012 5:18 am
x 67

Re: GDB Panopticum 2 - strange experience when debugging

Post by loath »

(also if your fragment already receives shadows then you're applying shadow receiving twice -- once in your shader and once in the non-INTEGRATED shadow pass, assuming it is able to clone your lit material successfully.)

User avatar
paul424
Gnome
Posts: 314
Joined: Thu May 24, 2012 7:16 pm
x 13

Re: GDB Panopticum 2 - strange experience when debugging

Post by paul424 »

in da mentioned breakpoint at _setPass I get :

Code: Select all

(gdb) p mIlluminationStage
$1 = Ogre::SceneManager::IRS_NONE

here's a bunch of args and locals from that frame :

Code: Select all

(gdb) info locals
vprog = 0x1079490
fprog = 0x0
passSurfaceAndLightParams = false
newFogColour = @0x40092428: {r = 0, g = 1.40129846e-45, b = 1.44193612e-42, a = 0}
newFogMode = Ogre::FOG_NONE
newFogStart = 5.6032854e-36
newFogEnd = 0
newFogDensity = 8.58964755e-32
unit = 140737337840598
startLightIndex = 140737192394669
shadowTexUnitIndex = 140737488335168
shadowTexIndex = 82728544
it = 0x140400000009
__FUNCTION__ = "_setPass"
(gdb) info args
this = 0x4ee5660
pass = 0xbdf0000
evenIfSuppressed = false
shadowDerivation = true
loath
Platinum Sponsor
Platinum Sponsor
Posts: 290
Joined: Tue Jan 17, 2012 5:18 am
x 67

Re: GDB Panopticum 2 - strange experience when debugging

Post by loath »

let me take a step back - your issue isn't a debugging problem. if you're switching from INTEGRATED to non-INTEGRATED shadows you have to change your code and shaders to match what ogre wants. the requirements differ based on the shadow type that you choose.
so you can't just remove the _INTEGRATED flag and expect this to work. since your code mostly already works with INTEGRATED, the more powerful option, i would recommend getting some caster shaders to work from the shadow samples and keep using INTEGRATED...

if you're sure you want to remove INTEGRATED, however, then you need to figure out what ogre wants / expects and change your code, materials, and shaders to reflect that.

  1. at a minimum, you need to remove or disable the shadow receiving code in your illumination shader. that code is the for the "INTEGRATED" approach. it looks like your shader has a bool to disable this code so that might be all you have to do. you might also need to change the material to remove the shadow texture unit(s).

  2. find out what ogre wants for non-INTEGRATED shadows. start by reading the manual on texture shadows.
    i pulled this up... https://ogrecave.github.io/ogre/api/lat ... adows.html

scroll down to texture shadows and Texture shadows and vertex / fragment programs where the manual says:

If you use a vertex program in the first pass of your technique, then you must also tell ogre which vertex program you want it to use when rendering the shadow caster; see Shadows and Vertex Programs for full details.

so there are likely other things you need to do to set this up. use the ogre shadow sample and looking at their materials, code, shaders etc to get yours working.

  1. start by making your "DCW1110" material very simple. for example, remove the shaders and just use a hardcoded diffuse texture. once shadows are working then add the shaders back etc. try to make incremental steps forward.

  2. if you understand all the requirements and can't get it working -- then put a breakpoint in _setPath () when it's called by Ogre::SceneManager::ShadowRenderer::renderAdditiveTextureShadowedQueueGroupObjects (). the easiest way to do this might be to set a breakpoint inside these two 'ifs' in _setPass ():

Code: Select all

    if (mIlluminationStage == IRS_RENDER_TO_TEXTURE && shadowDerivation)
    {
        // Derive a special shadow caster pass from this one
        pass = mShadowRenderer.deriveShadowCasterPass(pass);  // BREAKPOINT HERE
    }
    else if (mIlluminationStage == IRS_RENDER_RECEIVER_PASS && shadowDerivation)
    {
        pass = mShadowRenderer.deriveShadowReceiverPass(pass);  // BREAKPOINT HERE
    }

step into the "derive" function and see what it's doing with your illumination pass. find out why there isn't a fragment shader in the resulting pass and why the RTSS can't create one for you.

User avatar
paul424
Gnome
Posts: 314
Joined: Thu May 24, 2012 7:16 pm
x 13

Re: GDB Panopticum 2 - strange experience when debugging

Post by paul424 »

I forgot to add, first of all, the welcome scene loads and displays correctly that is :

Image

Notice that the mesh with the questioned material -- DCW1110 -- loads as well !
Only after choosing map like Skirmish->Load->Start saved Game -> Start Game breaks the game in aforementioned fashion...
What it could be hmm....

start by making your "DCW1110" material very simple. for example, remove the shaders and just use a hardcoded diffuse texture. once shadows are working then add the shaders back etc. try to make incremental steps forward.

Code: Select all

material DCW1110 //: RTSS/NormalMapping_MultiPass
{
    
technique { pass { diffuse 1.0 1.0 1.0 1.0 } } }

INDEED ! when the material is classical RTSS shader with the diffuse only it "PASSES THROUGH " ..... let me check the diffuse texture only ...

Hmm seems the culprit is the Vertex program ! When simplified to maximum such pair of shader programs "passes through " ....

Here I'm stuck again; I cannot reproduce this setting :(
Although I have two very simple vertex and fragment programs :

Code: Select all

#version 330 core
#extension GL_ARB_explicit_uniform_location : enable
#extension GL_ARB_shading_language_include : enable



 
 


uniform    mat4 projectionMatrix;
uniform    mat4 viewMatrix;
uniform    mat4 worldMatrix;

layout (location = 0) in vec4 position;
 
float freq = 3.1415; 
 
 
void main() {
    // compute world space position, tangent, bitangent
    vec4 P4 = (worldMatrix * position);
    vec3 P = P4.xyz;
 
gl_Position = projectionMatrix * viewMatrix * vec4(P, 1.0);

}  

and

Code: Select all

#version 330  core

 
out vec4 color;

void main (void)  
{ color = vec4( 1.0,1.0,1.0, 1.0); }
loath
Platinum Sponsor
Platinum Sponsor
Posts: 290
Joined: Tue Jan 17, 2012 5:18 am
x 67

Re: GDB Panopticum 2 - strange experience when debugging

Post by loath »

did you read the link i posted above and follow to the requirements?

https://ogrecave.github.io/ogre/api/lat ... adows.html
https://ogrecave.github.io/ogre/api/lat ... x-Programs

basically, non-INTEGRATED shadows only support "fixed function" materials. if you use a vertex program you need to also specify a caster and receiver programs.

from the manual:

If you use texture shadows, then vertex deformation is acceptable; however, when rendering the object into the shadow texture (the shadow caster pass), the shadow has to be rendered in a solid colour (linked to the ambient colour). You must therefore provide an alternative vertex program, so Ogre provides you with a way of specifying one to use when rendering the caster.

In addition, when rendering the shadow receivers with shadow textures, Ogre needs to project the shadow texture. It does this automatically in fixed function mode, but if the receivers use vertex programs, they need to have a shadow receiver material which does the usual vertex deformation, but also generates projective texture coordinates.

Post Reply