Other shadows engines

[Noiecity]

Is there any way to add shadows in real time other than the one that is native in irrlicht for 1.8.5 versions?
So far irrlicht hasn't let me down, it's everything I asked for in a game engine, but as for shadow formation, I've realized that I need the shadows that xEffects produces, but I haven't found a way to implement it in recent versions, does anyone know?

[CuteAlien]

Getting XEffects running is probably the best way for now. If you say recent versions - you mean getting XEffect to work in svn trunk version of Irrlicht?
I think the thread about XEffects had some hints about that (best start reading from the end...). I can also try to find some time to give it a shot (bit stuck with the other task I'm currently doing for Irrlicht anyway).

[Noiecity]

I try in 1.8.5(not svn for now) and 1.7.3, with 1.7.3 it's work fine , but not work like this in 1.8.5 . Please, help me with this when you have time mr cuteAlien

[CuteAlien]

Yeah, looking into it. I got 1.8.5 working, but with some wrong results with OpenGL in the first 2 examples. Rest (D3D and examples 3-6) seems to work (with a bit updated project files, and switching to 7.1 SDK). I'll check later some more if I can see why those 2 examples go wrong now (my fork is on https://github.com/mzeilfelder/xeffects, but without updated .exe, .dll files so far).

[Noiecity]

Thanks you

[CuteAlien]

Hm, don't think I'll have good news for you. Turns out trunk works again. So there was probably some bug in Irrlicht 1.8 release. I'll look a bit if it's something simple, but won't really spend too much time there. 1.8 has lot's more bugs than Irrlicht trunk and I'm only doing some simple maintenance fixes there which are binary compatible and should have 0 risk of breaking the code of anyone using 1.8.

edit: Seems this was reported several times, but no one ever found out why it's broken. People just switched to svn trunk.

[Noiecity]

Hm, don't think I'll have good news for you. Turns out trunk works again. So there was probably some bug in Irrlicht 1.8 release. I'll look a bit if it's something simple, but won't really spend too much time there. 1.8 has lot's more bugs than Irrlicht trunk and I'm only doing some simple maintenance fixes there which are binary compatible and should have 0 risk of breaking the code of anyone using 1.8.

edit: Seems this was reported several times, but no one ever found out why it's broken. People just switched to svn trunk.

I haven't tried it in SVN, how does it work there? Because I will also move my project to svn

[CuteAlien]

If you have no reason to stay with Irrlicht 1.8 (and only one I can think of is that you want to use official Irrlicht in Linux distributions like Debian) then I can definitely recommend moving to svn trunk. I've been working with that now for the last decade or so.

As for how it works - just update the XEffect project files. Add include and linker paths to Irrlicht trunk. Update the Irrlicht.dll. You can ignore the deprecated warnings for a start, thought I'll probably update that in my version later so they are gone (it will make things a bit faster).

In CScreenQuad.h the zwriteenable stuff has to be changed a bit like this (already changed in my version):

Code: Select all

#if (IRRLICHT_VERSION_MAJOR > 1 ) || (IRRLICHT_VERSION_MAJOR == 1 && IRRLICHT_VERSION_MINOR >= 9)
		Material.ZWriteEnable = irr::video::EZW_OFF;
#else
		Material.ZWriteEnable = false;
#endif

[Noiecity]

The only reason I used 1.8.5 was because I already had my projects done in this version before knowing the svn version lmao, thanks

[CuteAlien]

Found the reason now btw, in r3652 (before 1.8.0 release) there was a change which added calls to glDisable(GL_BLEND) and glEnable(GL_BLEND) which started conflicting with the materials settings for disabling/enabling blending.

Then later in trunk - it just got set once more afterwards, which on first view is probably not a good solution either. I guess idea was to not have blending never enabled when there is no blend func anyway (EBO_NONE). But changed ignored that certain materials don't work then anymore. Seems I got a complicated new todo on my list :-( (it works now in trunk, but I fear it has cases where it unnecessary flips those flags and that's somewhat expensive). Should probably even fix this one for 1.8.

I guess there might be some workaround for users if they set BlendOperation always to something different than the default (EBO_NONE) for all materials which are non-solid. But might be slightly tricky (stuff which Irrlicht probably should do in loaders).

Phew, fixing decade old bugs on which then just more stuff got piled on... definitely not fun :-(

[Noiecity]

definitely not lmao ?
Thank you once again Mr. cuteAlien for your sacrifice

[CuteAlien]

Hunting it was a bit fun ;-)

[Noiecity]

Hunting it was a bit fun

[Noiecity]

Lol, I was about to ask you how to build a cubemapping and saw there was an example in the svn
http://svn.code.sf.net/p/irrlicht/code/ ... g/main.cpp

[Noiecity]

Hunting it was a bit fun

Thanks for update CScreenQuad.h, it's work now in SVN trunk.