XEffects - Reloaded - New Release (V 1.4)

Mel · Post by **Mel** » Tue Dec 23, 2008 12:12 pm

No, stencil shadows render fine with me. I mean, in the end, finally i could get to render to a texture, and show it in a layer over the whole scene, and the stencil shadow was there. It has to see with the way the Xeffects handle the stencils, i can't tell how, though. And thinking about it a bit, makes sense the stencil shadows go away with the shadow mapping BlindSide is implementing.

BlindSide · Post by **BlindSide** » Tue Dec 23, 2008 10:20 pm

Aelis440 wrote:Quick question, all your stuff works great, but your effects->update() breaks irrlicht shadows. I guess it conflicts with the way they render them. Essentially, my question is, can I use your shaders (ie blooming) with Irrlicht's shadows? Once again, I love your work

Haha, what happened to your original post? I was going to suggest just moving the shadow light around with the player.

Anyway, stencil shadows should render to target fine, but as Hybrid mentioned there may be lack of support with stencils and RTT. This limitation may only exist in OpenGL, as Mel is using D3D and reports no problems.

Cheers

sjb · Post by **sjb** » Sat Dec 27, 2008 2:10 pm

Nice work.

Using D3D I got 40 FPS in example 1 and about 10-12 in example 2.
Geforce 7800
athlon 64 3200+
4gb mem
vista

I will definitely use this in my project as I really like the way it's organized. (also saves me the trouble of learning shaders from scratch)

Thanks

sjb · Post by **sjb** » Sun Dec 28, 2008 12:11 am

However a problem, using Direct3D (Vista) I get the following when using the shaders with Irr 1.5:
HLSL vertex shader compilation failed:
error X3506: unrecognized compiler target 'vs_3_0'

HLSL vertex shader compilation failed:
error X3506: unrecognized compiler target 'vs_3_0'

HLSL vertex shader compilation failed:
error X3506: unrecognized compiler target 'vs_3_0'

HLSL vertex shader compilation failed:
error X3506: unrecognized compiler target 'vs_3_0'

Error setting float array for HLSL variable
Error setting float array for HLSL variable
Error setting float array for HLSL variable
Error setting float array for HLSL variable
Error setting float array for HLSL variable

Then keeps spamming error setting float array.

OpenGL works fine.

BlindSide · Post by **BlindSide** » Sun Dec 28, 2008 11:03 am

That's really weird. Does it happen when you recompile only or with the provided examples too? It seems the version of Irrlicht 1.5 you are using was built with an outdated or incompatible DX SDK.

If you can rebuild Irrlicht yourself try using the latest DX SDK.

It's important to know what type of video card you have too.

sjb · Post by **sjb** » Sun Dec 28, 2008 2:06 pm

It's only when I recompile, the examples work just fine.
I'll try to recompile my Irrlicht with the latest DX SDK, I'll let you know how it turns out.

Like I stated in my first post I'm on the Nvidia Geforce 7800 (GS IIRC)

sjb · Post by **sjb** » Sun Dec 28, 2008 2:38 pm

Yup there we have it.

I checked out the latest SVN and compiled that using the latest available DX SDK. Now, Direct3D works fine. No errors. And on top of that I get 140 fps instead of 40 fps which I got on OGL (*raises fist to vista*)

I really like your framework. It's easy, and encouraged me to start learning about HLSL myself. And I'm getting some really exciting results with the shaders you provided, though I hope to learn to make some more exciting bloom

But yeah, you the man BlindSide

roelor · Post by **roelor** » Sun Dec 28, 2008 5:59 pm

If i move the camera the original background shows up. (Im using my own model for the room)

I have a ati radeon saphire hd 2600 pro 512 agp version.
EDIT, i just noticed its the original texture color. hmm... It seems that the precompiled version has not this problem... Whats going on?

BlindSide · Post by **BlindSide** » Sun Dec 28, 2008 11:37 pm

It's because it's rendering the "shadow overlay" a frame late, so the camera has already moved. If you look in effectWrapper.cpp:

Code: Select all

ICameraSceneNode* activeCam = smgr->getActiveCamera();
activeCam->OnAnimate(device->getTimer()->getTime());
activeCam->OnRegisterSceneNode();
activeCam->render();

You can see I am calling OnAnimate, etc on the active camera to make sure it's animation is up to date when rendering the shadow overlay, and this seems to solve this particular problem in the provided examples.

There could be several reasons why it is occuring in your app:

1. For some reason smgr->getActiveCamera() is not the same camera you are using in your scene (Unlikely because then the shadow overlay would be completely wrong, not just a little bit.).

2. You are using a custom camera that may be causing some problems because it updates it's view matrix at unconventional times.

3. There were some changes in the Irrlicht rendering process that require me to recode that part to ensure the camera animation stays up to date.

Considering all you have done is change the model more or less (I think), it's most likely number 3.

Mel · Post by **Mel** » Mon Dec 29, 2008 6:50 pm

Also, Irrlicht 1.5 has changed the way the RTT's are created, and changing to "addRenderTexture...." stuff won't solve it. I guess it is because there are any lost reference to RTT->drop(); which can't any longer be used, if you don't want to have the texture manager "angry" at you XD...

christianclavet · Post by **christianclavet** » Tue Dec 30, 2008 1:49 am

Hi Blindside.

Noob question here:

Is there a way to manage the lights with it? Say, I create a level with 800+ lights. Is there a way the system will update only the ones near the player?

sio2 · Post by **sio2** » Tue Dec 30, 2008 10:29 am

christianclavet wrote:Is there a way to manage the lights with it? Say, I create a level with 800+ lights. Is there a way the system will update only the ones near the player?

I'm guessing you're thinking about a Quake-style BSP level, in which case you would probably need access to PVS information - you could then work out which lights shine on which objects.

Imagine you're standing next to a big wall. There's a bright light on the other side of the wall totally obscured by the wall. Now, how do you know that that light doesn't contribute to the players' (or other objects) lighting? That requires some form of PVS.

dlangdev · Post by **dlangdev** » Mon Jan 05, 2009 10:37 pm

Hey Blindside and others who write shaders,

Just wondering if this idea will work in XEffects? I'd like to blur the edges to remove the jaggies, for that a shader will have to be coded to create an RTT for edge detection which will then serve as a layer mask. Using the RTT mask, I can now apply the blur.

Would that work? Do you have any ideas better than that?

Thanks.

BlindSide · Post by **BlindSide** » Tue Jan 06, 2009 1:00 am

That would work fine, just blur the shadows as a post process filter, it usually turns out ok even without the edge detection, but that wouldn't hurt.

dlangdev · Post by **dlangdev** » Tue Jan 06, 2009 1:11 am

BlindSide wrote:That would work fine, just blur the shadows as a post process filter, it usually turns out ok even without the edge detection, but that wouldn't hurt.

What about the fragment of the model? They're too sharp and jaggy. I need to soften the edges then pass it to gamma correction, I read from GPUGEMS 2 that it can be done in postprocess using 3D Lookup tables. But then Irrlicht has no support for a 3D texture lookup. Anyway, I have tons of questions about postprocessing, but that's just for now.