Caelum assertion failed at line 137 in Moon.cpp

Hi all,

When I alt-tab to another application,


assert (mMoonMaterial->getBestTechnique ()->getPass( 0)->hasFragmentProgram ());


will cause an assertion failure. What could be the problem? I tried alt-tab while running Caelum Demo and it does not cause any assertion failure.

This is my code for initializing Caelum (identical to Caelum Demo):


CaelumFrameListener::CaelumFrameListener(Ogre::RenderWindow* win, Ogre::Camera* cam)
: Ogre::FrameListener()
, mWindow(win)
, mCamera(cam)
, mPaused(true)
{
mSceneMgr = mCamera->getSceneManager();

// Pick components to create in the demo.
// You can comment any of those and it should still work
// Trying to disable one of these can be useful in finding problems.
Caelum::CaelumSystem::CaelumComponent componentMask;
componentMask = static_cast<Caelum::CaelumSystem::CaelumComponent> (
Caelum::CaelumSystem::CAELUM_COMPONENT_SUN |
Caelum::CaelumSystem::CAELUM_COMPONENT_MOON |
Caelum::CaelumSystem::CAELUM_COMPONENT_SKY_DOME |
Caelum::CaelumSystem::CAELUM_COMPONENT_POINT_STARFIELD |
Caelum::CaelumSystem::CAELUM_COMPONENT_CLOUDS |
0);
componentMask = Caelum::CaelumSystem::CAELUM_COMPONENTS_DEFAULT;

// Initialise CaelumSystem.
mCaelumSystem = new Caelum::CaelumSystem ( Root::getSingletonPtr(), mSceneMgr, componentMask );

mCaelumSystem->setPrecipitationController(new Caelum::PrecipitationController(mSceneMgr));
mCaelumSystem->getPrecipitationController()->createViewportInstance(mViewport);

// Set time acceleration.
mCaelumSystem->getUniversalClock()->setTimeScale(512);

// Register caelum as a listener.
mWindow->addListener(mCaelumSystem);
Root::getSingletonPtr()->addFrameListener(mCaelumSystem);

mCaelumSystem->setManageSceneFog(false);
mCaelumSystem->setManageAmbientLight(true);

UpdateSpeedFactor(mCaelumSystem->getUniversalClock ()->getTimeScale());
}


and the code to register Caelum in my main application:


mCaelumListener = new CaelumFrameListener( mRoot->getAutoCreatedWindow(), mCamera );
mRoot->addFrameListener(mCaelumListener);


Thanks,
CG

Remove the frame listener if your window is inactive, and add it back at activation. PS I have this only when using hydrax with depth techniques in Caelum materials. Is it your case too ?

Remove the frame listener if your window is inactive, and add it back at activation. PS I have this only when using hydrax with depth techniques in Caelum materials. Is it your case too ?

I found that the moon component is causing this assertion failure, by removing it, I can alt-tab to other applications while running the game. I'm also using hydrax with depth techniques in Caelum materials.

How exactly does the HydraxDepth technique look like; what are the changes? Perhaps you could point me to the relevant discussion in hydrax forums?

Those assertions are supposed to check that updating the moon will indeed modify the correct material. It is very very strange that this only fails on alt-tab; this suggests that the structure of materials is changed. That's scary; it shouldn't happen.

just

//
//This file is part of Caelum.
//See http://www.ogre3d.org/wiki/index.php/Caelum
//
//Copyright (c) 2008 Caelum team. See Contributors.txt for details.
//
//Caelum is free software: you can redistribute it and/or modify
//it under the terms of the GNU Lesser General Public License as published
//by the Free Software Foundation, either version 3 of the License, or
//(at your option) any later version.
//
//Caelum is distributed in the hope that it will be useful,
//but WITHOUT ANY WARRANTY; without even the implied warranty of
//MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
//GNU Lesser General Public License for more details.
//
//You should have received a copy of the GNU Lesser General Public License
//along with Caelum. If not, see <http://www.gnu.org/licenses/>.
//

fragment_program Caelum/PhaseMoonFP cg
{
source CaelumPhaseMoon.cg
entry_point PhaseMoonFP
profiles ps_2_0 arbfp1 fp30

default_params
{
param_named phase float 0.3
}
}

material Caelum/FullMoon
{
receive_shadows off
technique Default
{
pass Main
{
lighting off
depth_check off
depth_write off
fog_override true none
ambient 0 0 0
diffuse 0 0 0
scene_blend alpha_blend
emissive vertexcolour

texture_unit Texture0
{
texture moon_disc.dds 2d
}
}
}
technique HydraxDepth
{
scheme HydraxDepth
pass
{
lighting off
texture_unit
{
colour_op_ex modulate src_manual src_current 0 0 0
}
}
}
}

material Caelum/PhaseMoon
{
receive_shadows off
technique Default
{
pass Main
{
lighting off
depth_check off
depth_write off
fog_override true none
ambient 0 0 0
diffuse 0 0 0
scene_blend alpha_blend

texture_unit MoonDisc
{
texture moon_disc.dds
}

fragment_program_ref Caelum/PhaseMoonFP
{
}
}
}
technique HydraxDepth
{
scheme HydraxDepth
pass
{
lighting off
texture_unit
{
colour_op_ex modulate src_manual src_current 0 0 0
}
}
}
}

material Caelum/MoonBackground
{
receive_shadows off
technique Default
{
pass Main
{
// Used fixed function lighting to return black.
lighting off

depth_check off
depth_write off
fog_override true none
scene_blend alpha_blend

texture_unit MoonDisc
{
texture moon_disc.dds
colour_op_ex source1 src_manual src_diffuse 0 0 0 0
}
}
}
technique HydraxDepth
{
scheme HydraxDepth
pass
{
lighting off
texture_unit
{
colour_op_ex modulate src_manual src_current 0 0 0
}
}
}
}



I modified moon.material and this did not reproduce in CaelumDemo. I guess hydrax does something "interesting" with the materials.

I modified moon.material and this did not reproduce in CaelumDemo. I guess hydrax does something "interesting" with the materials.

To point you in right direction:
1 - It is not about Hydrax, I dont add Hydrax Depth Technique to materials and I still get the error
2 - The error only happens when you use RenderOneFrame() to render the scene, havent met the problem when continuous rendering is used
3 - The error triggers when the application is deactivated (for example Alt+Tab)

Also it is not only Caelum Related, the same happens after a while when you deactivate an Ogre application using RenderOneFrame() (For example when screensaver starts with password check enabled, when you return back and enter the password, the application asserts no matter if Caelum used or not, but using Caelum causes an instant assert instead of asserting after a while )

In Ogitor, I fixed the problem by checking the Activation/Deactivation of the application and Ogitor doesnt call RenderOneFrame() when the application is deactivated by any reason, so I dont get the error, but even when I use Caelum in an OGRE Demo like Terrain demo, it asserts as soon as I Alt+Tab...

I hope it helps to track down the problem,

Ismail TARIM,

Hydrax changes all Ogre::Entity(SubEntity's) materials for the depth RTT and then changes them to their's original.
But any changes is done to the material, only the material (setMaterialName(...)) entities is changed.(Only Entities, not all rendereables).

Xavi

Xavyiy: That seems like a perfectly legitimate thing to do.

Since this only happens on alt-tabbing I'm afraid there are some deeper platform issues here. Maybe somehow some things get broken on reloading? I don't know.

Does this happen with both OpenGL and DirectX? Maybe it can be traced to a lost DirectX device which causes this obscure failure higher up?

Same issue here.

For my small project, I try today to build a release version to take a look at the fps. This version cause this assert problem.
Debug version works well.
In my previous project, I never had this assert.

I try some different configuarations

- windowed mode and full screen mode. both dx9
- changed calling order of constructor ( before / after ) my code did not cure it
- changing release against debug version of caelum throw a runtime in script parser

Using Ogre SDK 1.62, bullet 1.74, and VC9 Express Edition.

I hope it help to find the problem.

Actually; it's possible that this bug was fixed after some cleanups in trunk. Can you retry with Caelum's latest version? (from svn).

Nice, I will give it a try after some hours of sleep

EDIT:

I have build my project against the libs generated from Caelum trunk and the assert problem has gone.

Many thanks for your assistance and your work on this extremly usfull plugin.

Peter