Tech Demo again (this time NOT IrrKlang related)

[AReichl]

Tech Demo with newest 'trunk' ( compiled with gcc/MinGW and VS2010 ):

with DirectX 9 there are no shadows any more,
with OpenGL the whole scene looks like having a "spheremap" as material.

It must have something to do with the demo itself, because all other examples look ok to me
( e.g. 08-SpecialFX has shadows in DirectX and OpenGL ).

This is not important, but i would like to understand what has changed.

[CuteAlien]

Thanks for the report. OpenGL bug seems to be new from changes last week. D3d9 looks like something older (5150 which I had before update right now was also broken already, will check later when it started).

[Nadro]

Thanks, I'll check that tomorrow.

[CuteAlien]

The version in which shadows stopped working in d3d9 was 4794. Several changes with blending back then. Looks like we have no good shadow tests so far - this should have been catched automatically :-/

[Nadro]

After release v1.9 we must immadiately replace current lighting and shadows system built-in Irrlicht (from per vertex + shadow volumes to per pixel with shadow mapping, because currrent solution looks really, really bad at these days).

[Mel]

I am glad i am not the only to have that error in GL... indeed, the demo appears with spheremap materials most of the times. There is a small case where the whole scene will render correctly again, but it is hard to reproduce, you have to turn away from the running characters and not always work, but i'd put my money in that the cache thing you're implementing in GL isn't handling properly all the renderstate changes, or most probably, there is a material type slip somewhere in the cache.



And the stencil shadows indeed don't work since a lot of time.

Also, maybe this is not the best place, but would it be much hassle, or would it make sense at all, to have materials that interacted with the stencil buffer? Perhaps that way, unifying how the stencil is handled, using the stencil shadows would be easier to program, or somehow.

This is the SVN version 5169, the current one, as of today

[AReichl]

It must have something to do with the Demo itself, because all other examples run fine.

Maybe it's because BEFORE the castle scene there is the GUI and on switching to the
castle scene something is not "reset" properly.

OR it's because the Demo is the only example with a spheremap in it and something is
"broken" there.

[Mel]

No, the initial window of the demo is done using the burning software renderer, then, to switch to another renderer, irrlicht is shutdown, and another Irrlicht device is created with the proper options. It is impossible that way, besides, sometimes it works which means that there is something somewhere that isn't properly set, Irrlicht handles when some object is on screen or not, so, when a proper set of combinations of renderstates is met, it works, if it isn't met, it doesn't. Given it sets the textures and the blends, and all, my bet is that somewhere, a material.type has been slipped out. Not the first time, nor the last, something like this would cause a bug of this class.

[Nadro]

I'll not be able to fix it until the next week due to a lot of work with new unified OGL code and merge ogl-es with trunk, however thanks Mel for the tip that this bug appears when we go away from characters, because I couldn't reproduce it before.

[Mel]

Perhaps it could be nice to have a tech demo that held all the possible material types on it, so the cache could handle all the possible cases.

[Nadro]

OpenGL's part is fixed in rev5185.

[CuteAlien]

Thanks, works here again as well.

Btw... that model walks really strange in the Demo - I think animation and move speed are not synchronized very well ;-)