Irrlicht Engine

Seriously I might just stop supporting Intel graphics cards

One thing you can try is search and replace "EVST_VS_3_0" with "EVST_VS_2_0" in EffectHandler.

The proper fix is to recompile Irrlicht using a newer DX SDK, the error occurs on the outdated ones.

BlindSide wrote:Seriously I might just stop supporting Intel graphics cards
One thing you can try is search and replace "EVST_VS_3_0" with "EVST_VS_2_0" in EffectHandler.
The proper fix is to recompile Irrlicht using a newer DX SDK, the error occurs on the outdated ones.

Replacing "EVST_VS_3_0" with "EVST_VS_2_0" didn't help.
I could try recompiling, but I get a mental image of my compiler creating a completely dysfunctional version which won't work at all.
Isn't there a downloadable version with the new DX stuff? If not, could the devs upload one? That would prevent some headaches, I would think...

What happened when you replaced EVST_VS_3_0 with EVST_VS_2_0?

BlindSide wrote:What happened when you replaced EVST_VS_3_0 with EVST_VS_2_0?

After I changed "EVST_VS_3_0" to "EVST_VS_2_0", it gave me a slew of error messages saying: "error X3506: unrecognized compiler target 'ps_3_0'" and it had the same rendering problems as before.
When I changed "EPST_PS_3_0" to "EPST_PS_2_0", it now displays the shader effects, but the "horizon" level for the water is tilted at a diagonal line, the specular effects on the water's surface are tilted, and the terrain is likewise submerged at a diagonal. I can post a screenshot if that would help.

If recompiling Irrlicht is a proven way to solve the problem, I can do that...

Hey blindSide,
I'm going to make VSM shaders, so I looked at this paper http://www.punkuser.net/vsm/vsm_paper.pdf and the XEffect shader code, and I was wondering what is this line about :

float variance = min(max(E_x2 - Ex_2, 0.00001) + 0.000001, 1.0);

I mean variance=E_x2-Ex_2, I don't understand what are the min/max for.
min(variance, 1.0) is to avoid negative lighting values, but what about the two 0.0000001 ?

Thanks.
PS : I don't really like dual paraboloid shadow map because it needs the scene to be tessellated and I've done per pixel lighting to be able to use big polygons with good lighting so using it would be paradoxal. Do you know any other shadow map render method which needs less than 6 render to produce a point light shadow map ? Btw I think I'll use only 1 directional shadow light in my game so I guess I'll stay with 6 render but I was still wondering...

EDIT : in fact dual paraboloid seems really fun, I think I'm going to make a dual paraboloid VSM, that's look really fun to implement, I hope objects wont be too much diformed. However Cascaded shadow maps seems harder to implement

Blindside:
I recompiled Irrlicht as you suggested, using the latest DirectX SDK (which of course meant disabling Irrlicht's support for version . After compiling, I verified that irrlicht.dll is a new version (dated today), rebooted my machine, then tried running the program.
I got the same ""error X3506: unrecognized compiler target 'vs_3_0'" error that I had before recompiling Irrlicht.
When I changed "EVST_VS_3_0" to "EVST_VS_2_0" and likewise for the similar line below it, I got the following error:
"(16): error X5608: Compiled shader code uses too many arithmetic instruction slots (69). Max. allowed by the target (ps_2_0) is 64."
And the water is displayed in a tilted manner as before.
Any idea what I'm doing wrong?

Do you have the newest Intel graphics drivers and newest Direct3D Redistributable?

Hello

I’m completely new to computer graphics and I don’t know many of technical terms around (Yes, I previously used to play computer games). My English is as bad.

Again I’m sorry if this has been issued before but I’m lazy to read all 40 pages on this topic.
I just downloaded irrlicht and examined a few examples that came with the package. On wiki page I introduced to XEffects, then I downloaded version 1.3 which I think is the latest version. I successfully built examples and tried to run them. I’m having a DirectX 9.0c capable graphics card. But thing I noticed was that my binaries ran slower than those already been made! Notably in Example 4 I got 36 fps while the original example ran around 50 fps. Examples came along with XEffects was relied on irrlicht version 1.6, so I thought It may be the .dll file since I think I myself had compiled the .dll file (with no Direct3D8 support). I’m not sure since all things got messy since. Then I tried to replace (my?) .dll file with the file came already with irrlicht, but I get errors after executing the examples. Errors like “unrecognized compiler target 'vs_3_0'”.
I tried to compile “Example 4” with pixel and vertex shader 2.0, with (my?) .dll file included. surprisingly I got 50 fps like the original binary example. I’m not sure what did happen?

Thanks for the great shader package.

Blindside:
I finally solved the problem - my program was set up to use a copy of irrlicht.dll in the program directory itself rather than irrlicht's directory, so when I recompiled Irrlicht I needed to copy the new dll into my own program's directory. I had forgotten about this.
In other words: Programmer Memory Error #45914.
It now seems to work pretty well. Thank you for your help, and for writing XEffects.

I looked deeper at the shadow generation code, and what I understood is the following :

for each light
render depth from light view in shadow map
end for

for each shadow map
render depth from eye view
compare eye view depth with shadow map one (build light shadows from eyes)
add this to an accumulation buffer
end for

mix scene & accumalation buffer.

--

So this mean there are 2 render per light? 12 render for spot light.
I thought it could be achieved with 1 render per light only. render the scene depth only 1 time, then render depth from light view and compare depth for each light. The problem is that if I do the depth comparaison in the light view, I wont be on the good pixel in the pixel shader, I can calculate the pixel coordinate to lit/unlit but can't change it from the pixel shader.

I looked over the internet and found that this method is called forward shadow mapping. But there is a kind of 3D-unwrap running on the CPU which is not so cool : http://webcache.googleusercontent.com/s ... en&ct=clnk

I would like you to confirm if yes or no what I understood from your patern is true, that is to say for each light:
1/ render light view depth
2/ render scene depth & compare depth

Thanks.

Yeah there's 2 passes because I want to make it flexible and do the lighting additively, so you don't have to alter the scene materials. If you are skilled enough to integrate the shadowmapping code into your own materials than feel free to do that to save a pass per light

Blindside - How many simultaneous lights can XEffects handle?

ent1ty wrote:

Blindside in the first post wrote: Multiple infinite additive lights...

Yes, but there are hardware limitations, are there not? How does XEffects deal with the video card limits ?

AW111 wrote:Yes, but there are hardware limitations, are there not? How does XEffects deal with the video card limits ?

There is no limitation because it's doing the lighting with multiple passes. One pass per light, and each time the current pass shadow is accumulated in a buffer. The only limit is your hardware speed.

BlindSide wrote:Yeah there's 2 passes because I want to make it flexible and do the lighting additively, so you don't have to alter the scene materials. If you are skilled enough to integrate the shadowmapping code into your own materials than feel free to do that to save a pass per light

I've been thinking about that, and I think a post process pass is cheaper then a depth scene render one. I'm going to try this pattern :

render depth 1 time from eyes position

for each light {

-render eye view depth in shadowmap
-on a quad put depthMap and shadowMap as texture and as post process effect, get the world pos with crytek ray method, and compute lit/unlit pixels.
-output this in accumulation buffer

}

mix accumulation buffer and sceneRender.

EDIT:
Wait?!
I can even do the post process in the deferred light pass, this is awesome because even with no shadow I need to compute pixel world space, so doing the shadow comparing stuff as post process effect will be really faster! So this will take 1 + 2*lightsNum render per shadow instead of 12