Irrlicht Engine

1.8 changed how uniforms are set. I think you want to look at OnSetConstants().

1.8 is no longer compatible with GLSL! I´m staying with 1.7.3!

Ah, yes, the solution was written a few posts before but somehow I thought that the fix was already applied...
I had to change the line to in the file EffectCB.h, line 90.

It does make sense, because casting a pointer to an int into a pointer to a float was doomed to fail.
I'm surprised it even worked before. Maybe if it's a 32 bit system and if the int value is 0 then the float would also have the value 0.0f. Otherwise it would probably have random results.

Anyway, thanks, it works now

I'm having weird issues with this on Linux.

If I compile it with Irrlicht 1.7.3: and without any modifications to EffectCB.h then everything looks OK:



If I change irr::u32 TexVar = 0; to irr::f32 TexVar = 0; then I get this:



On Irrlicht 1.8.1 the results, however, are completely different.

Without any changes:


After correcting u32 to f32:
← only one light source

Is there anything I could do to fix this?

Best to use 1.7.3, more consistent!

1.9 really needs to be backwards compatible with 1.7.3. and have DX10 support with cube maps!

I´ve seen some neat and efficient (fast) shader techniques to handle shading without maxing out the CPU, but I guess that will be left to the experts!

Is it supposed to work with irr 1.8.1?

Did everything right( I think ) and don't see any results, tried all the provided hlsl files. (using dx9)

Try with 1.7.3. Truth is 1.8 has no real benefits and lots of problems

Hello All,

I'm also experiencing some problems with xEffects (1.3 on Irrlicht 1.7.3)

full picture: http://www.image-share.com/upload/2663/230.jpg

As you can see on the picture, the textures of the mesh seems to separate from the car model as long as the speed of the mesh increases (if the model is just standing, their is no separation). That creats something like a "ghost effect". The problem occurs using either EDT_OPENGL or EDT_DIRECT3D9.
However, if I switch to irr::f32 TexVar = 0 in EffectCB.h and use EDT_DIRECT3D9, the problem desappears but the light also desappears!

On this screen shot, I use a standard irrlicht light for the grass and a xEffect light for the road and the car.
The code of the xEffect light is below (SCALE=1 and shadowDimen=1024) : At each frame, the light is moved to be approximatly 15m upon the car just before calling effect->update().

Does someone ever experienced this strange effect? Do you have some idea of what could be the reasons?

thank you for your help!

up! please!

thanks

Hi .Is there a way to set the shadows color darker ? I'm using static lightmaps (EMT_LIGHTMAP) in combinations with XEffexts but the higher i set the ambient light , less the shadows are visible...

effect->setAmbientColor(irr::video::SColor(255, 180, 180, 180));

i'm satisfied with this color value , my scene , and all the models looks really cool , but unfortunately the shadows are almost invisible.
if i set the ambient color to a lower value the shadows are visible but the whole scene is totally dark. Is there a way to compensate this ? like render the shadows independetly of the ambient color ?

Thanks in advance !

I finaly found what case the problem on irrlihct 1.8
CScreenQuad's Material doesn''t set the BlendOperation, so driver shut down the blend opertaion.
To fix this, just change codes in EffectHandler.cpp at line 350 from:
driver->setRenderTarget(ScreenQuad.rt[0], false, false);
ScreenQuad.getMaterial().setTexture(0, ScreenQuad.rt[1]);
ScreenQuad.getMaterial().MaterialType = (E_MATERIAL_TYPE)Simple;
ScreenQuad.render(driver);
To
driver->setRenderTarget(ScreenQuad.rt[0], false, false);
ScreenQuad.getMaterial().setTexture(0, ScreenQuad.rt[1]);
+ auto blendFunc = ScreenQuad.getMaterial().BlendOperation;
ScreenQuad.getMaterial().MaterialType = (E_MATERIAL_TYPE)Simple;
+ ScreenQuad.getMaterial().BlendOperation = EBO_ADD;
ScreenQuad.render(driver);
+ ScreenQuad.getMaterial().BlendOperation = blendFunc;

Rama112 wrote:Does someone ever experienced this strange effect? Do you have some idea of what could be the reasons?

thank you for your help!

Yes, it seems that the shadow map is lagging a frame behind. It was not noticeable before I guess.

The reason this is difficult to fix is that the depth map rendering stage happens before "CSceneManager::drawAll()".

In "CSceneManager::drawAll()" the nodes get animated (Camera moves, car moves, etc). XEffects doesn't animate the nodes because we only want them animated once per frame, and it's not easy to disable animations when calling "CSceneManager::drawAll()".

This means that the depth map is always lagging behind the real scene by at least 1 frame.

The easiest way to fix this is to add a "bool animate" parameter to ISceneManager and CSceneManager drawAll, and disable animating if that is set to true (It's just a couple of lines you can wrap with an if statement). Infact I've hacked this into Irrlicht in the past for very similar reasons.

Once that is done, you will just need to call onAnimate() when you loop over the nodes in the depth pass inside XEffects.

Cheers,

Yeah, allowing to split animation from rendering would be a good idea. I thought that as well in the past - adding a paramter to drawAll and maybe adding another function animateAll so the animation can also be done independent of the rendering (also sometimes useful). Or 2 flags or an enum so drawAll can do only animating.

I don't understand this at all. XEffects does not call CSceneManager::drawAll(). Also, XEffects calls OnAnimate() for each node, possibly multiple times.

Perhaps one fix might be to get the time at the top of update() and use this time in the calls to OnAnimate. Nodes should only animate again if the time changes. I know hybrid made some changes to the skinned-mesh animation so the nodes would not animate multiple times in the one frame, though this may have been frame-based, that is, skinned-mesh nodes would not animate more than once per frame. I guess this doesn't address the movement of nodes, but OnAnimate takes the current time, so it shouldn't animate twice if the time is the same?

Hey mongoose,

Ah I see. The problem is still the same as I mentioned, that the animations are happening in in drawAll() and then once again in XEffects. The timestamp idea is another solution.

Cheers,