Shadow Volumes Blow Up Meshes (Strange Bug)

[CuteAlien]

Hm, so it's not the same dwarf I have. Which means even after scaling I won't have the same case. I'll try in the evening if I still can reproduce this somehow by tweaking values a bit, but could be I need your dwarf then. Maybe you can mail it to me or you have some online server to upload it?

[Elevations]

Here is file link to the dwarf with all animations:

https://www.mediafire.com/file/iz9po1uj ... k.b3d/file

[CuteAlien]

Reproducing it myself is pretty much impossible. Thought I have to admit I also wasted some hours on trying to use that CollisionResponseAnimator (guess another thing for me to debug and/or document).

I know I don't have your scene reproduced yet as my light still looks very different. I assume you use maybe not default solid material type for floor? As this type of light seems to look rather ugly in my tests (very visible polygons). So I assume you might have switched to something using pixel shaders?

Maybe it's also related to using more shadows at once or something like that. I really need a test-scene, trying to write my own to reproduce this is just me spending my evenings without result. Can I maybe simply take a look at your project? Maybe it's not yet in a state where it has stuff which you don't want others to see.

[Elevations]

Uhhh i really don't want to post my code for all eyes to see right now haha, but if you like i can send you private PM with the main code if that helps?

Oh yes by the way my ground i am using a grid plane with many split up polygons to make lighting look better, its also using a normal map with tangents

If you open blender and make a grid with 100 cells for each that is what im using for my ground. Not using any pixel shaders (yet) i might look into some pixel shaders later on though.

[Brainsaw]

I recommend for such error reports to create a minimal project which reproduces the issue and post it. That makes it easier for anyone who wants to help you to reproduce what goes wrong.

[CuteAlien]

Ah, you don't have to open source for everyone. But often people have their code already in some private repository on bitbucket or so, then it's easy to add me as a (read-only) user for a while. Butg any further info you can send me might help.

Optimal bugreport certainly as Brainsaw said. Creating a minimal report like that also tends to often show where the real problem lies. Like for example when removing seemingly unrelated 3d models or some flags which seems unnecessary suddenly fixes the bug or stuff like that.

[CuteAlien]

Don't have your bug yet - but found out by now that there is definitely going something wrong in d3d when shadows are used, but none is drawn. The whole light (dynamic and environment light) becomes darker here in that case. My guess by now is that it causes some material flag (or even several flags) to get stuck in the wrong mode in that case. That would also explain why your materials suddenly look all different (like the transparency stuff suddenly on top of your skeleton).

edit: Found the reason and it's similar to what I thought earlier. SceneManager draws stencil-buffer in this case without setting it up correctly as that's only done if it has some shadows to draw. But will have to spend a bit time on weekend to figure out how to handle this safely as it involved a mix of driver specific code in D3D and driver independent code in SceneManager. There is already a similar workaround for this problem in another place with a TODO, but I'd prefer to find a better solution this time.

[Elevations]

I'm glad that you were able to find it, my apoligies for not already having a reproduceable project ready for this bug, im still learning irrlicht engine and was just posting bugs i had encountered during my development of my isometric RPG, please let me know though if you still need a reproduceable project, cause ill need to fix up some things and upload one to github for private access. I'm still a bit skeptical about you pointing out that its a D3D bug as i could swear it also happened with opengl driver aswell.

[CuteAlien]

I'm fine for now. Will work later today (if I find time for it) on a fix. You can try that then and we'll see if it's the same bug. If it's not then I guess the search goes on :-)

And no worries, I hope you keep on posting bugs you find. I tend to use mostly a specific subset of Irrlicht in my projects. So the light/shadow stuff in Irrlicht for example is something which I usually only check when someone reports problems.

[CuteAlien]

When you update svn trunk then it should be fixed now (in version r6677). If it was the same bug.

Note that it still makes sense to change the line you mentioned as it disables shadows often way too early. Note sure yet if it maybe should have a more complex solution. Or if I just add a variable, which would be a quick hack and solve most troubles (I'll probably be lazy...).

[Elevations]

Sweet i just had a look at the new trunk is there any function i need to call now? or just continue on as per normal?

[CuteAlien]

Should just work now ... I hope...

[Elevations]

So far my tests with latest SVN Trunk i have not encountered the bug while using getLengthSQ();

However

i'm still going to switch back to using getLength(); aswell just for extra safety on my shadows but so far i think you may have fixed it.