Question to Material.getBestTechnique(...)

Discussion area about developing or extending OGRE, adding plugins for it or building applications on it. No newbie questions please, use the Help forum for that.
Post Reply
Gold Sponsor
Gold Sponsor
Posts: 34
Joined: Sat Nov 03, 2007 10:08 pm
x 4

Question to Material.getBestTechnique(...)

Post by phoenix_64 »


Material.getBestTechnique(...) may return NULL, if a material could not be successfully compiled.

Now in several places, OGRE depends on getBestTechnique() without checking for NULL, e.g.

Code: Select all

Technique* t = mat->getBestTechnique(0, *seci);
for (unsigned short p = 0; p < t->getNumPasses(); ++p)
SceneManager::validatePassForRendering(const Pass* pass)

Code: Select all

Technique* lateTech = pass->getParent()->getParent()->getBestTechnique();
if (lateTech->getNumPasses() <= pass->getIndex())
while in other places, getBestTechnique() is checked for NULL:


Code: Select all

Technique *technique = mMaterial->getBestTechnique();
if( technique )
Since a faulty material is a very common error, my questions are:
- Is it intended not to check at some places, e.g. due to performance reasons?
- If this is so, wouldn't it be better to throw directly, when a faulty material is detected? Currently, it is only logged* - but will lead to an inevitable crash in some situations. An instant throw would leave the causing material as the last message in the log, making it easier to find the problem.

*see Material::compile():

Code: Select all

if (mSupportedTechniques.empty())
     << "WARNING: material " << mName << " has no supportable "
     << "Techniques and will be blank. Explanation: \n" << mUnsupportedReasons;

User avatar
OGRE Team Member
OGRE Team Member
Posts: 4350
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 883

Re: Question to Material.getBestTechnique(...)

Post by dark_sylinc »

There are four things that can happen:
  • The "no supported technique" status is detected early. The material is never used because a fallback is used instead. So, no need to keep checking for null pointers.
  • The material is manually provided or absolutely necessary (i.e. no fallback is possible, as in the instancing case). We need to check for null pointers.
  • The "no supported technique" status is detected early. It throws but it isn't caught. Crash.
  • The "no supported technique" status is never detected. Null pointer is used. Crash.
The last two aren't that bad per-se. After all this is a fatal error in your data (i.e. malformed shader) you should seriously fix.

Post Reply