XEffects - Reloaded - New Release (V 1.4)

BlindSide · Post by **BlindSide** » Tue Jan 06, 2009 4:23 am

Slow down mate, I thought you just wanted to blur the shadow maps.

kaos · Post by **kaos** » Thu Jan 08, 2009 4:48 pm

When I move the camera, near of shadow map, appear hollow without shadow, like in these photographs. why??? it's proble of the mesh, normals???

other thing, if I want that the light multiply more the colour of the stone... I guess that I must change one constant of the shader. is correct?

fukuda · Post by **fukuda** » Thu Jan 08, 2009 5:08 pm

Can we get a wireframe view of your model?

Mel · Post by **Mel** » Thu Jan 08, 2009 5:16 pm

No, Kaos, your trouble is with the octree you use to accelerate the render. You see, When you move in the stage the camera, some polygons are clipped out of the scene because they're not viewable according to the octree. And those polygons should be occluding the light so, the DepthMap comparisons were done correctly, but they're not, they disapear, and so, appear the gaps.

In my opinion, i'd use shadow mapping for character, and moving objects, and i'd use lightmapping for stages, unless you're doing a dynamically lit environment, with shadowmapped shadows.

fmx · Post by **fmx** » Thu Jan 08, 2009 5:17 pm

those "hollows" are there because the shadow-casting polys are being culled by Irrlicht, because the camera isn't looking towards them (if you're using an octree mesh). Nothing to do with Normals etc.

I don't think BlindSide has a fix for this yet, but I may be wrong

[edit: beaten to the punch by Mel, i just wasted a post...]

Mel · Post by **Mel** » Thu Jan 08, 2009 5:23 pm

I fear there is no way to solve those holes, and keep using the octrees, at least with the current shadow mapping algorithms, and the current system irrlicht uses to render octrees.

A way to solve it is not to use an octree for the render at all (maybe just for the collision system) and use the EHM_STATIC hardware mapping hint. so the mesh is stored once in the video-card. Search the help for this method: setHardwareMappingHint()

(Edit: hey dude, not wasted, you reinforced what i said

)

Dorth · Post by **Dorth** » Thu Jan 08, 2009 5:44 pm

You are way, way better off dividing your levels in sections and draw whole sections or not than use octree. This is one of the many reasons why, and everything touching shaders, reflections, and, on top, you'll likely gain speed, if not ease of use.

kaos · Post by **kaos** » Thu Jan 08, 2009 6:12 pm

yes, I use "static oclusion" width dinamic shadow, because width a moving light I get better results.

I understand, I must change the octres for meshes and to divide my scene.

thanks, thanks.

BlindSide · Post by **BlindSide** » Fri Jan 09, 2009 2:14 am

Hey that's one of the nicer screenshots I've seen my wrapper used in

Looks great!

Octree currently doesn't support VBOs (Vertex Buffer Objects), which means your mesh data has to be re-sent to the graphics card every frame. This will usually result in a decrease of performance on modern hardware anyway. Until some better system is implemented I suggest staying away from OctreeSceneNode. (Also the loading time for generating the Octree is tragic...). PS to actually enable VBOs for performance you need to set the hardware mapping hint on your mesh using mesh->setHardwareMappingHint(EHM_STATIC). Compare the performance of static vbos to the OctreeSceneNode!

EDIT: Beaten by Mel again! Damn you Mel!

other thing, if I want that the light multiply more the colour of the stone... I guess that I must change one constant of the shader.

I haven't tried, but I _think_ it might be possible to set the values in SShadowLight's lightColour to great than 1.0f (Make sure you are accessing it as SColorf).

FuzzYspo0N · Post by **FuzzYspo0N** » Fri Jan 09, 2009 7:34 am

lol ill post a screenshot from my old SCR demo, the map is ugly and the quality is horrid( thanks to my screwing up the post process shader interface, forgetting to fix it before moving off with the build) but you can still see how cool the shadows are in XEffects.

And the frame rate is due to running too many graphics apps at once, so dont worry about the number in the corner.

kaos · Post by **kaos** » Fri Jan 09, 2009 11:40 am

Work xeffetcs width skybox?

BlindSide · Post by **BlindSide** » Fri Jan 09, 2009 12:52 pm

It should. Are you having any problems using it with skyboxes? Tell me and I'll try to help.

kaos · Post by **kaos** » Fri Jan 09, 2009 1:48 pm

Ye I have,

width xeffets

without xeffets

irrlicht 1.5

pd: no no, sorry I found the problem

Mel · Post by **Mel** » Fri Jan 09, 2009 2:53 pm

BlindSide wrote: EDIT: Beaten by Mel again! Damn you Mel!

Don't worry, you have explained much better than me

dlangdev · Post by **dlangdev** » Mon Jan 12, 2009 4:25 pm

BlindSide wrote:Slow down mate, I thought you just wanted to blur the shadow maps.

No, I'm after gamma correction and AA which I found in the DX9 manual. For gamma ramp, there is a DX9 function I can call, but I have to know the Irrlicht call for that.