Soft Shadows (w/o EA) Demo (99% done, released)

[nullsquared]

And me. We really need a modern shadow solution and this could be it.

Ok, I'm just about finishing up the demo right now. I'll probably release it today, though not for a couple of hours since I got a school state exam right now (NYS math). OT: They gives us hours of time to finish, and I finish it in like 4 minutes. Then I am extremely bored and fall asleep because they don't let us leave when we finish . America's math education is teh crap.

Anyways, pre-final screen shots (99% done):









All that you see is soft(ish, I put the filter from 7x7 to 3x3 for testing) self shadowing - the whole "level" is 1 unclosed mesh. (shaking your fist at me, stencils?)

Too bad the level I had for testing had no multiple UV coords - I could only map out 1 texture.

Also - one thing that worries me, is ATI cards, and their crappy floating point texture support... I might have to emulate bilinear filtering .

[JohnJ]

nullsquared: Nice! Looks really good so far! I'd definitely be interested in something like this

The point I'm making is - show all of Ogre's "underneath parts", and then let people build their own "proper" stuff based on true Ogre.

I agree. While there's nothing wrong with the example framework for it's intended purpose, it just fails completely as a teaching tool, which it's unfortunately being used as (examples always are used to learn from, unless maybe you put a big warning in each source file).

I have to admit that when I first started learning Ogre I wasn't quite as proficient in C++ as I am now, and the example framework confused me also. Fortunately, I just opened up the example framework include file and figured it all out (much to my relief - up to that point I was beginning to think Ogre was organized really weirdly). Usually the most powerful engine learning tool for me is slowly stepping through the entire initialization of an example, learning how it's done, and Ogre's example framework doesn't make this very easy.

I agree that it would be much better if Ogre could have just one example with a giant main() function that initializes and draws a spinning Ogre head. This would serve one purpose: demonstrating the initialization of Ogre without forcing the user to play "function-jumping" across various source and include files.

But I guess sinbad also has a good point. Maybe the newbie-unfriendly example framework is a good way to filter out unwanted "hand-holders". Personally I don't think this is a good idea, but I guess you can't blame sinbad for favoring independent learners.

But actually, if you think about it, the example framework is only going to create more problems than it solves; there will either be more questions asked by people confused about the example framework, or some people will just accept the example framework as part of Ogre and encounter numerous problems along the way, creating even more questions to answer and misunderstandings to untangle. I can certainly remember many occasions where here on the forums a new user is very confused about how Ogre works and it takes hours of typing to explain it to them.

[nullsquared]

nullsquared: Nice! Looks really good so far! I'd definitely be interested in something like this

The point I'm making is - show all of Ogre's "underneath parts", and then let people build their own "proper" stuff based on true Ogre.

I agree. While there's nothing wrong with the example framework for it's intended purpose, it just fails completely as a teaching tool, which it's unfortunately being used as (examples always are used to learn from, unless maybe you put a big warning in each source file).

I have to admit that when I first started learning Ogre I wasn't quite as proficient in C++ as I am now, and the example framework confused me also. Fortunately, I just opened up the example framework include file and figured it all out (much to my relief - up to that point I was beginning to think Ogre was organized really weirdly). Usually the most powerful engine learning tool for me is slowly stepping through the entire initialization of an example, learning how it's done, and Ogre's example framework doesn't make this very easy.

I agree that it would be much better if Ogre could have just one example with a giant main() function that initializes and draws a spinning Ogre head. This would serve one purpose: demonstrating the initialization of Ogre without forcing the user to play "function-jumping" across various source and include files.

Ok, I'm going to release the demo right now. Might be late for the state test, but I feel like I really want to release it. Please read the readme.

Bugs: might not work correctly on all ATI cards.
Issues: *needs* shader model 2 and floating point textures in the current state.

Version: 0.9 alpha

Link0: http://cheapfilehost.com/file.php?file= ... c76021392d
Link1: http://rapidshare.com/files/98990587/Og ... o.zip.html
Link2: http://www.mediafire.com/?10x0x0gumyy

BTW, this isn't one gigantic main() . It's separated into newbie-friendly functions, like "initRenderer()", and "initInput()", and so on.

EDIT: Just tried on my AMD Sempron + X850XT... It "runs" in OpenGL mode (I think I'm missing the latest DX version, and DX fails with a missing DLL) at about 6FPS. This is because (a) there's a 3x3 filter in the pixel shader (you'll need a card with good texture sampling speeds) and (b) the X850XT is really bad with floating point textures. Though if it runs on that, surely it'll run great on an X1800 or something.

[CoreDumped]

thanks for the links. i think u should hurry to school now.

[PS: Saw your new vids of portalized. Its amazing for a 14 yo!]

[IFASS]

Awesome job Nullsquared!
Runs very well on my mobile X1400. Both OGL and D3D

[betajaen]

Well the demo works on my GeForce 7900GT in Vista. I'm surprised how actually, the frame rate seems to be over 60FPS at least.

However when I try to implement it in my own application, it either causes an error or a crash. In DirectX I get the following in my Ogre.log

Code: Select all

16:26:43: OGRE EXCEPTION(7:InternalErrorException): Unable to compile Cg program blur_ps: CG ERROR : The compile returned an error.
(0) : error C6001: Temporary register limit of 12 exceeded; 49 registers needed to compile program
 in CgProgram::loadFromSource at D:\Ogre_CVS\ogrenew\PlugIns\CgProgramManager\src\OgreCgProgramManagerDll.cpp (line 66)

And if I try it in OpenGL - it crashes the Nvidia driver! I'm a little puzzled why it would do such as thing as the Demo uses OpenGL by default and I have no problems with it.

I will keep fiddling with it until I get something.

[jjp]

D3D runs fine on my X1900XT, OGL doesn't work at all

[Evak]

sounds fantastic. I would really love to get some good shadows in flow. Can't wait to see your solution in action .

[betajaen]

Alright. I got it working (it was my fault) and it exceeded my exceptions on ease of use and how powerful it is.

This is my implementation of it in Cake. Cake for the people who don't know is the NxOgre equivalent of the Ogre Sample Application but with a bit more oomph and more physics.

Here are the screen shots (Click each thumb for a bigger image):



I think nullsquared deserves an Ogre Expert badge

[spacegaier]

Wow, betajaen your shoots look really incredable!

[beaugard]

I just checked the code and demo. Wonderful! Well commented code, too.

[nullsquared]

can has badge now? kthxbi (also, just call me "null")

Ha. betajaen, the blur shader isn't actually used in the demo. Technically, the method "can" be accelerated with a blurring pre-filter on the shadow map. Though I found that a compositor (that matched the shadow textures type) "somehow" lowered the quality. Besides, in a differed renderer (what I plan on using for Portalized), the filtering will be faster in main scene screen space rather than shadow map screen space.

Looks neat in Cake. You can increase the blurriness in the btex2D_rg function in diffuse.cg. I switched to a simply 3x3 filter, you'll see in the comments. Simply comment that and switch to the filter above. Runs in SM2 for me, though it might need SM3 for some people. BTW, what units do you use in Cake? Meters? Because I found the shadows to work best in meters.

So, how does it run on the rest of ya's machines?

@ beaugard: I tried to comment as much as possible since I wasn't using ExampleApplication or anything else (everything, from plugins to window settings, is done manually).

@ jjp: What's the Ogre log say? OpenGL is the one that usually never gives me problems, heh.

Also, guys, fiddle with /data/config.ini for the number of shadow textures. You'll need 1 per light. I think the demo defaulted to 4 shadow textures, 512x512 each.

Wow, betajaen your shoots look really incredable!

[jjp]

To be exact I get a black window and after a few seconds the application crashes. The ogre log unfortunatly doesn't really show anything interesting, it looks normal to me. These are the last few lines that get written.

Code: Select all

20:30:53: Mesh: Loading level.mesh.
20:30:53: Can't assign material 01 - Default to SubEntity of level because this Material does not exist. Have you forgotten to define it in a .material script?
20:30:53: Texture: GreenSkin.jpg: Loading 1 faces(PF_R8G8B8,256x256x1) with 8 hardware generated mipmaps from Image. Internal format is PF_X8R8G8B8,256x256x1.
20:30:53: Texture: spot_shadow_fade.png: Loading 1 faces(PF_R8G8B8,128x128x1) with 7 hardware generated mipmaps from Image. Internal format is PF_X8R8G8B8,128x128x1.

[nullsquared]

To be exact I get a black window and after a few seconds the application crashes. The ogre log unfortunatly doesn't really show anything interesting, it looks normal to me. These are the last few lines that get written.

Code: Select all

20:30:53: Mesh: Loading level.mesh.
20:30:53: Can't assign material 01 - Default to SubEntity of level because this Material does not exist. Have you forgotten to define it in a .material script?
20:30:53: Texture: GreenSkin.jpg: Loading 1 faces(PF_R8G8B8,256x256x1) with 8 hardware generated mipmaps from Image. Internal format is PF_X8R8G8B8,256x256x1.
20:30:53: Texture: spot_shadow_fade.png: Loading 1 faces(PF_R8G8B8,128x128x1) with 7 hardware generated mipmaps from Image. Internal format is PF_X8R8G8B8,128x128x1.

Hm. That's weird...



At least it runs in Direct3D

Don't you hate problems like these . Your code looks great, runs great, looks simple enough to never crash/not work, and yet... it just doesn't work on some configurations

[IFASS]

Assuming it's not entirely done yet, what's left on your TODO list Null?

[nullsquared]

Assuming it's not entirely done yet, what's left on your TODO list Null?

Uh. I dunno

Does the community have any suggestions?

[jjp]

Maybe CG or the ATI Vista OpenGL drivers are to blame. Although CG2 (unlike older versions) hasn't caused me any trouble at all with ATI/OpenGL so far..

[SiENcE]

Great work. It works on my ATI Readon x1600pro very well. I think the Scene from NxOgre Cake is a bit better for shadowing. Or a something like Stonehenge!?

[nullsquared]

Great work. It works on my ATI Readon x1600pro very well. I think the Scene from NxOgre Cake is a bit better for shadowing. Or a something like Stonehenge!?

I think that a self-shadowing level is more appropriate. Random objects casting shadows is nice, yes, but I think most people are interested in fully self-shadowing levels and stuff (all this inspiration comes from F.E.A.R.'s shadows).

Either way, thanks, and great to hear it runs nicely on an X1600.

Guys, I also need more testers .

[altren]

Runs fine on geForce 7900 GS.
About demo itself. I like code but data folder should be simplified. I think you should decrease number of files and rename them so everyone can understand where he can find any part of you demo.

[nullsquared]

Runs fine on geForce 7900 GS.
About demo itself. I like code but data folder should be simplified. I think you should decrease number of files and rename them so everyone can understand where he can find any part of you demo.

Hm. I think it looks fine. Anything one might need is diffuse.cg/.material, and shadow_caster.material/.cg. The other stuff is just random media. If I were to "clean it up", it'd get confusing in the code, hard coding multiple media paths. I wanted to keep it simple. Then again, depends. If anyone else thinks its messy, as well, I'll try to clean it up. Because I do] see how it can get confusing.

EDIT: Badge! w00t! Thank you VERY much .

[CaseyB]

This is beautiful! I am completely amazed! Thank you so much for setting this up and giving it out so freely!

EDIT: Badge! w00t! Thank you VERY much .

You've definitely earned it!

[sinbad]

Looks awesome, I particularly like how it looks in Cake actually It's actually a lot more robust than I expected from VSM to be honest, I don't see any edge-ghosting, but maybe that's because of the relatively simple geometry - or have you found that's not as bad as some papers suggest?

Great work, you have your badge Works fine on my 8800 in both GL and D3D.

[danharibo]

Well Done, you made something run over 30 fps on my x600!

congrats on the badge, oh, and i fixed my engine, thanks for your help!

[nullsquared]

Looks awesome, I particularly like how it looks in Cake actually It's actually a lot more robust than I expected from VSM to be honest, I don't see any edge-ghosting, but maybe that's because of the relatively simple geometry - or have you found that's not as bad as some papers suggest?

I'm actually quite surprised, as well. Aggressive camera far plane clipping and depth linearization (based on scene_depth_range) seems to do wonders for VSM. There's that, and I don't really think it's as bad as the papers. Portalized uses the same method, and I've noticed absolutely no artifacts. There's also a smoothstep on the final value in there, it's been mentioned as a good way to reduce VSM light bleeding.

Great work, you have your badge Works fine on my 8800 in both GL and D3D.