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.
I have some problems with texture shadows on Linux (Ubuntu 7.04).
The program throws an assert_fail in some situations which I can reproduce but I don't know why the program doesn't crash in other situations.
One of the situations where the program crashes is if I load a specific model twice in the scene (I didn't test this in an empty scene, but I think it is a combination of the whole scene and this two models). But there are other constellations where this error is thrown.
I tested my project on windows without any problems!
I'm using the Ogre CVS version but this behavior was also there on earlier releases (1.4.1).
Maybe somebody has a clue if this is a bug or if I'm doing something wrong.
What is needed is more where the assert is raised... did you compile with debug symbols ? can't you read the assert line and see what it's saying ?
That's what assert are for... precise information on requisites to make code working.
I tested my project on windows without any problems!
using opengl too ?
Anyway linux driver are not same quality as windows one...
10 shadow texture means 10 rendertarget of 512x512... that's huge... and I'm not sure it's that supported either by hardware or Ogre (check Ogre log "max render target" for instance...)
I'm not sure which one causes the program stop.
I always thought, if I compile Ogre on Linux there are already debug symbols in the libs, but I also tried to set the debug flag manually.
But if I try to debug my program I never get the line number in the Ogre libs. Do the source files have to be on a specific place for this to work?
I tested my project on windows without any problems!
using opengl too ?
Anyway linux driver are not same quality as windows one...
Yes! I tried my program using opengl in Windows as well. Worked without any problems.
10 shadow texture means 10 rendertarget of 512x512... that's huge... and I'm not sure it's that supported either by hardware or Ogre (check Ogre log "max render target" for instance...)
I'm using just one shadow texture now, but the error stays the same.
I had the exact same problem, and found out that disabling TextureUnitState effects (transforms) solved the problem. Dont know if this is the issue, but works for me.
I have begun to see this assert also. Mine asserts when being called from SceneManager::deriveShadowCasterPass(). I am studying the code to see exactly what is the cause, but I already see an inconsitency that is suspect:
In SceneManager::deriveShadowCasterPass() you have:
// Copy texture state, shift up one since 0 is shadow texture
unsigned short origPassTUCount = pass->getNumTextureUnitStates();
for (unsigned short t = 0; t < origPassTUCount; ++t)
{
TextureUnitState* tex;
if (retPass->getNumTextureUnitStates() <= t)
{
tex = retPass->createTextureUnitState();
}
else
{
tex = retPass->getTextureUnitState(t);
}
// copy base state
(*tex) = *(pass->getTextureUnitState(t));
// override colour function
tex->setColourOperationEx(LBX_SOURCE1, LBS_MANUAL, LBS_CURRENT,
isShadowTechniqueAdditive()? ColourValue::Black : mShadowColour);
}
but in SceneManager::deriveShadowReceiverPass() you have:
// Copy texture state, shift up one since 0 is shadow texture
unsigned short origPassTUCount = pass->getNumTextureUnitStates();
for (unsigned short t = 0; t < origPassTUCount; ++t)
{
unsigned short targetIndex = t+1;
TextureUnitState* tex;
if (retPass->getNumTextureUnitStates() <= targetIndex)
{
tex = retPass->createTextureUnitState();
}
else
{
tex = retPass->getTextureUnitState(targetIndex);
}
(*tex) = *(pass->getTextureUnitState(t));
// If programmable, have to adjust the texcoord sets too
// D3D insists that texcoordsets match tex unit in programmable mode
if (retPass->hasVertexProgram())
tex->setTextureCoordSet(targetIndex);
}
These appear to be doing roughly the same thing, but note he shift in the index in the latter. The latter sure seems more correct according to the comment. Anyone familiar with this code know if the former is incorrect or not?
Well, I thought someone would comment. I did change the loop in SceneManager::deriveShadowCasterPass() to be like SceneManager::deriveShadowReceiverPass() and I no longer get the assert. I'm assuming this is a bug that's been there for a while. I'm using 1.4.9, but it appears to be in all subsequent versions as well.
BTW, I'm using Windows and not Linux as the original creator of this thread was using.
Only just saw this. The 2 blocks of code are supposed to be different, the comments have just been inappropriately copied.
In the caster pass, there is in fact no shadow texture, because you're rendering to the shadow texture. Therefore, no offset. There is only an extra texture unit in the receiver pass, since that's where you're pulling in the shadow texture.
I still haven't seen enough detail about this problem to be able to propose a cause, and I haven't come across it yet.
Thanks sinbad for looking at it. I can give some more information in hopes it can clue you or someone in to the specific problem. The material it is asserting on is a flat scrolling (scroll_anim 0.0 0.002) water surface. The receiving TextureUnitState already has the ET_VSCROLL in its mEffects map and hence the assert in the assignment operator fails. None of the other textures have problems...just this one and it's the only one with an effect on it.
As I write this I suddenly am thinking that I can avoid the assert by making sure this water surface doesn't cast a shadow as it really shouldn't anyway, but that wouldn't resolve the issue for a case where an animated texture is on an object that should cast a shadow.
Perhaps the TextureUnitState assignment operator shouldn't care if there are already things in mEffects and simply clear it before copying them.
Shadow code is not my area of expertise, so I'm trying to resolve this somewhat blindly. I apologize for being somewhat dense in this area.
Just a note, I have hit the same exact error (assert on mEffects.empty() for material with scroll_anim in it) and the workaround is also to disable shadow casting for the entities.
A willow deeply scarred, somebody's broken heart
And a washed-out dream
They follow the pattern of the wind, ya' see
Cause they got no place to be
That's why I'm starting with me