Shadow Mapping - I made it!
Blitz3D Forums/Blitz3D Programming/Shadow Mapping - I made it!
| ||
| i've always been thinking, you must render and project a shadow texture. but this causes the glitch that behind the light source, no shadows are casted. so i use a cubemap download incl exe (controls are explained there): http://dev-ch.de/upload/files/Devils%20Child/ShadowMapping.zip |
| ||
| well done! If you add flag 256 (load in vram) to your shadow texture, the speed goes up from 170 fps to 240 fps on my machine.. |
| ||
| ok, thanks for that. i've been thinking of that, too ;D *added it. i also added transparent shadows. use the same download link again |
| ||
| I know it's just a test/demo but in the for loop where you create the 100 cubes, you're also creating 100 textures ("EntityTexture c, LoadTexture("Media\SandStone.jpg")" - if in stead you load the texture once, and apply it in the loop... you gain another 15 to 20 fps :) |
| ||
| oh and if you remove all the Text commands (except the one to show the FPS) you get another 60 FPS !!!!! Blitz Text S#cks! :))) - sorry man, just playing with it! It's cool ;) |
| ||
| blitz optimizes the textures. if the user loads a texture twice, blitz wont load it again. if it would, tha whole program would propably crash. that without text it is faster - i know that, but what can i do;D i better concentrate on the main problem: shadows are not always projected correctly. also they seem to work indoor, not outdoor... |
| ||
| yes I checked because loading the texture 100 times I would expect it to consume MORE memory - but it doesn't!!! So yeah you'd say Blitz does optimize, but it's funny that it still scores an extra 20fps.... It's like having a cool car - but not being alowed to look under the bonnet ;) |
| ||
| what i'm still hunting for is, that the shadows are projected wrong sometimes :P when its finished, we'll be able to use shadow maps! i may check out depth shadows as well. |
| ||
| We've been able to use shadow maps for a while. My shadow system uses shadow maps. Doesn't use cubemaps though. Cubemaps would be expensive. I'm not sure why you're using those. I guess your intent is to make a single shadow map for all objects a light is casting shadows from? That might work in a simple square room, but wouldn't work well in an actual FPS level. Shadows would end up being placed where they shouldn't be. Also it would limit the resolution of your shadows. |
| ||
| what your shadow system is slow about is the polygon clipping. also i dont understand it. i got the idea. everyone is programming shadow maps the same way i do except they use a single texture instead of a cubemap. i got the right attempt, but the shadows still get projected wrong and i dont know why. sswift: i programmed YOUR swift shadow scene in my stencil shadow sys and i tried it here, too. but it didnt work. somehow, its for indoor only (not for outdor...) |
| ||
| I found it most exciting. |
| ||
| oh thank you puki ;D also it would be if i can solve the problem of the wrong shadow projection :) |
| ||
| Devil, As with all things it depends on how you use them and how much effort you put into them. I have been using Swift's shadow system for years, and love it. There have been occasions where I needed to find out more to do more or resolve problems. By breaking up a level into smaller sections Swift's excellent system (which can cast from animated b3d meshes) works really well. I will have another quick look at your system (which I believe is very good too from what I hear), but without anmated b3d meshes included I can't make use of it. Best regards, Peter. |
| ||
| good work! ;) bye |
| ||
| it is a goooodd!! thanks |
| ||
| Good work! I'm gonna stress test this in my game (hundreds of meshes and hundreds of shadow receivers) :P |
| ||
| Devils Child: The bad projection is when the light is not at the same position as the mesh with the cubemap. For dynamic cubemaps to look correct, the camera used to render the cubemap should be at the same position as the mesh that will recieve the cubemap, obviously the light moves around in the demo which causes an offset. It might be possible to fix with some kind of offset texture matrix applied using a DLL, SetTransform(texLayer, D3DTRANSFORMSTATE_TEXTURE0+texLayer, matrixType). |
| ||
| i dont quite understand: the shadows are even more un-correct if i render from the center of the shadow receiver. i think the solutiuon is very easy and i dont see it :(... the shadow projection seems correct as long as the shadow light stays at the position of the shadow receiver.... |
| ||
| the shadow projection seems correct as long as the shadow light stays at the position of the shadow receiver.... Exactly! You are rendering from the light position right? So it will only look correct when the light is at the same position as the receiver. |
| ||
| ..hmm..this sounds interesting...mmm |
| ||
| whats the value for D3DTRANSFORMSTATE_TEXTURE0 ? |
| ||
| Sausages. |
| ||
| Found these constants for you Devils Child: http://kevincg.wordpress.com/tag/directx/ Could be for DX9 thoe... Also found this very interesting D3D pascal source, which contains a lot of constants! http://www.koders.com/delphi/fidF30DE49A7FDD6BD2AB9557AEE9A071DBA3550D0D.aspx |
| ||
| D3DTRANSFORMSTATE_TEXTURE0 = 16 ..1 = 17 ..2 = 18 e.t.c |
| ||
| thank you. when i have time, i will engage my self with this. |
| ||
| ..when I load another mesh (plane) and place it under shadow receiving sphere in the sample, there is no shadows at all..just sometimes surface change color (default white, no texture) in to shadow color.. |
   |