OGRE related: shadow problems

[psyclonist]

I didn't find a topic on this problem so I guess, I'm the first one encountering it.

First off: Excellent work, Paul! (+contributors)

I'm using OGRE and its 'modulated shadow texture shadow' capabilities and encountered a more or less (well, more less, i guess ) issue.

See for yourself:


The GUI is casting shadows :/ Or more to the point, it seems it's kind of replacing the texture shadow!?

What d'ya think, CrazyEddie?

-psy

[edit]Sorry, wrong forum. Can you move it to the "Help" forum, please?[/edit]

[psyclonist]

Correction: The shadow texture is rendered correctly but the GUI is rendered as if it were a shadow texture, too. Can you point to me the place where to look for disabling this 'feature'?

-psy

[CrazyEddie]

The place you probably want to look for the issue is likely in OgreRenderer::initRenderStates or maybe somewhere in ogretexture.cpp/.h

It could be somewhere else, I'll take a look later. Thanks for the report

CE.

[CrazyEddie]

Which render queue group are you rendering the GUI as part of? And does this queue have shadowing enabled?

Obvious questions I know, but I need to determine whether it's an actual problem within the system or just some set-up issue or what have you with Ogre.

Thanks,

CE.

[psyclonist]

render queue group: RENDER_QUEUE_OVERLAY.
Shadowing is disabled by default in SceneManager::initRenderQueue().

Sorry that I'm not that big of a help here. I'll try to dig up sth but I haven't dwelved in the inner workings of OGRE for quite a bit of time...

-psy

[CrazyEddie]

I think what is hapening is this:

GUI drawing is triggered when RENDER_QUEUE_OVERLAY starts, but is actually rendered before the initialisation for the render quese is done; so at this stage shadows and what have you are still enabled. You could confirm this by getting the GUI to render after the queue (the 'post_queue' option).

The fix is to add the appropriate code to OgreRenderer::initRenderStates to disable shadowing, though at present I'm not sure what this code should be

CE.

[CrazyEddie]

It almost sounds like an issue in Ogre then. But having said that the overlay itself is not producing shadows, so probably not

I'm going to have to ask that you put together a minimal demo that demonstates the problem and send it to me, then I'll be able to reproduce the problem and also confirm when I have fixed it (which I'll do by the weekend). If I have to produce something that demonstrates it myself, it will probably be a week or two before it's fixed.

Thanks,

CE.

[psyclonist]

Here (<- link) is a modified version of the demo-7.

It's just a few lines of code, enabling texture shadows, creating a plane and a light, setting the camera.

The effect is pretty obvious. I tried a few other things but didn't come up with something useful.

-psy

[CrazyEddie]

Thanks for doing that, I can reproduce the problem. I'll try and get a fix done tomorrow or Friday

CE.

[CrazyEddie]

Right, it actually turns out that this is not related to shadows at all, but is infact a Viewport problem.

Basically, the GUI is being rendered into each Viewport in turn; including the target texture for texture based shadows

I'm deciding on the best approach for a fix since I can't just start detaching Viewports arbitrarily. I currently have two options that I see; the first option is to only render the GUI if overlays are enabled for a given Viewport, the second option is to come up with a system where you have to specify which Viewport(s) you want the GUI rendered into - but this would break all existing code. I think I'll go with option 1. Opinions and suggestions appreciated

CE.

[CrazyEddie]

Yep, that is the purpose of that flag

Okay then, I'll commit a fix for this some time within the next hour.

CE.