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

[xavier]

Agreed with that last point.

I had intended to continue/polish the series (and still do, if I ever get the time)...

[ScurvyKnave]

Sorry to say it, but I agree with those who dislike the demo framework. Like most, I used it for quite a while when first starting with Ogre, and I found that it allowed me to use Ogre for ages without even understanding some the most fundamental basics, whereas having a good understanding from the start would have been better.

Fair enough, the target demographic should be smart enough to figure out what's happening by looking at the base classes. But I don't think that's a good reason to stick to an obscure method of doing things when a clear, straight-forward way is easy to implement.

Personally I would have preferred a framework that was as basic as possible, excluding everything but the fundamentals.

[ScurvyKnave]

Also, I think the shadow demo does too much. The various shadow types are different enough to warrant separate demos. Skyboxes and skydomes each have their own demos (and setting up these entails a lot less code than getting shadowmapping working, for example). Trying to figure out which code pertains to which shadow technique is a bit of a nightmare.

[sinbad]

It's impossible to please everyone.

If the demo framework exposed too much of the workings, people complain that they have to learn too much to get off the ground with simple tests. If I hide it away so they can get started faster and just see the 'interesting' bits, people complain that I didn't force them to look at all the bootstrapping code (not that I ever prevented them from opening ExampleApplication.h and, you know, reading it).

Similarly with demo size - you're complaining that Demo_Shadows is too big, but many other people want even larger demos which do more so they're more like a 'proper' application. Demo_SkyBox etc I've been thinking of canning for ages by the way, I just haven't gotten around to it.

The moral is - some portion of the community will be unhappy no matter what I do Therefore, I choose to just do what I think is best unless someone comes back with one solution I think is universally better (hasn't happened yet - there are things that are better in some cases, but not universally). Unless I deploy 2 or 3 different versions of our examples I'll never please everyone. I think what's there does the job - it prevents duplication and shows how to do the 'interesting', non-bootstrappy bits. For the rest, there are examples in the wiki.

[xaddict]

It would be very nice if the exampleApplication was thrashed... As a beginner this just brings too much confusedness. You can better have a set-up in ONE file with a lot of code you don't understand at first but that's being explained, than a few to many files with a lot of code. I still don't have a clue how to start a program without just copying all the example code from other Ogre maps and deleting a few I'm sure of I don't need. There should be some kind of "Empty Application" example... that would make everything just a bit easier

[xaddict]

It's impossible to please everyone.

If the demo framework exposed too much of the workings, people complain that they have to learn too much to get off the ground with simple tests. If I hide it away so they can get started faster and just see the 'interesting' bits, people complain that I didn't force them to look at all the bootstrapping code (not that I ever prevented them from opening ExampleApplication.h and, you know, reading it).

Similarly with demo size - you're complaining that Demo_Shadows is too big, but many other people want even larger demos which do more so they're more like a 'proper' application. Demo_SkyBox etc I've been thinking of canning for ages by the way, I just haven't gotten around to it.

The moral is - some portion of the community will be unhappy no matter what I do Therefore, I choose to just do what I think is best unless someone comes back with one solution I think is universally better (hasn't happened yet - there are things that are better in some cases, but not universally). Unless I deploy 2 or 3 different versions of our examples I'll never please everyone. I think what's there does the job - it prevents duplication and shows how to do the 'interesting', non-bootstrappy bits. For the rest, there are examples in the wiki.

the problem is the tutorials always use exampleApplication or they introduce quite some awful bits of code (that people have never seen before)... there should be like a special directory full of tutorials which only place ONE or TWO objects on a stage and then apply some concepts to it (skybox, shadow, fresnel, colission detection, etc. one per tutorial). These tutorials should not be using exampleApplication and explain every bit of code... then a lot of people would not have so much problems to start using ogre I guess. That would also take away a lot of the questions on the forum

[Chris Jones]

These tutorials should not be using exampleApplication and explain every bit of code... then a lot of people would not have so much problems to start using ogre I guess. That would also take away a lot of the questions on the forum

So seperate demos and tutorials. Demos could use the example code as they are designed to show off ogre features, not take you step by step through using ogre. but tutorials should be like programming tutorials (or graphics tutorials), that start off as a really simple application that shows a window and explains all of the code. then the next tutorial continues on from that, and for example displays an entity. each tutorial building on the previous one?

[CABAListic]

So it seems to me that there is an agreement to the need of a new grounds-up tutorial (in terms of Ogre, not of C++ or anything like that ) series. Then let's get to it, shall we? I would be willing to help with this, but we'll need a small team to work out how the new tutorials should be structured and what exactly each should teach (and, of course, actually writing them). Furthermore, at least one native English speaker should be available to correct and clean up the tutorial texts in the end.
Anyone willing (and able) to step up?

[Chris Jones]

n terms of Ogre, not of C++ or anything like that

of course they should assume at least basic C++ knowledge.
I would volunteer to do this but i barely have enough time for OGE let alone this.
Shouldn't a new thread be created for this?

[nullsquared]

Woah there, guys. Way off topic. Main focus was soft shadows (sorry I didn't end up releasing it yesterday, was quite busy, and the soft shadows weren't cooperating as well as they did in Portalized )

Also, I never said I'm going to write a complete gigantic "proper" application frame work in place of Example Application. I was simply targeting raw Ogre code. You know how people know it:

Code: Select all

create renderer;
configure renderer; // shadows, lighting, etc.
create input;
create starting scene;
loop:
    use input;
    render;
clean up;

If I were to create a gigantic application framework that's "proper", it'd confused newbies even _more_. 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.

[KungFooMasta]

@nullsquared:

That layout seems really simple and intuitive, that's all that should be needed for basic understanding, really.

@CABAListic:

*cracks the whip* What about ETL?

[CABAListic]

Don't worry about that, I'll take care not to do too much on tutorials

[toglia]

Very eager to see how the soft shadow demo comes up!

I hadn't noticed how horrible my shadows were...

[nullsquared]

Very eager to see how the soft shadow demo comes up!

I hadn't noticed how horrible my shadows were...

I've been a bit busy with Portalized, so I don't know what's going to happen with the soft shadows. Maybe I'll release them later on. The thing is, default Ogre seems to need some tweaking my Portalized build does not, so the quality is rather different from Portalized's shadowing and this example.

If anyone wants the code right now (and is eager enough to polish it up and release it ), I'll paste bin it. (everything "works", other than the light's rotation, and the shadows not being 100% pretty)

http://ogre3d.pastebin.com/f227914ff
Obviously some of that code is separated into different files and stuff, and there's some textures used from the Ogre examples, but for anyone who wants to just read the code, there it is.

[toglia]

I've been a bit busy with Portalized, so I don't know what's going to happen with the soft shadows. Maybe I'll release them later on. The thing is, default Ogre seems to need some tweaking my Portalized build does not, so the quality is rather different from Portalized's shadowing and this example.

Didnt know about your project "Portalized", its amazing!!! How come there's such difference, isn't made in Ogre too? (I'm just a couple months old with Ogre...). Hope to be creating stuff like that some day!

You're really 14? Thats just mind blowing!

[nullsquared]

I've been a bit busy with Portalized, so I don't know what's going to happen with the soft shadows. Maybe I'll release them later on. The thing is, default Ogre seems to need some tweaking my Portalized build does not, so the quality is rather different from Portalized's shadowing and this example.

Didnt know about your project "Portalized", its amazing!!! How come there's such difference, isn't made in Ogre too? (I'm just a couple months old with Ogre...). Hope to be creating stuff like that some day!

You're really 14? Thats just mind blowing!

I am using Ogre, but all of my meshes are exactly 1unit=1meter, and there's lots of specializations in place. I can probably get it to work nicely with default Ogre media, but like I said, it'll take me a bit of time to tweak. There's also a fix in my shadow caster I made in Portalized and didn't do here, so there's that, too.

I'll also zip up the whole project so that you don't have to refer to the paste bin site.

I'll be 15 in August. All of this wouldn't be possible without Ogre, which is like 90% of the whole thing . Many thanks to the Ogre team.

[nullsquared]

Sorry, I know I'm very late now. But I've been really busy with Portalized.

Anyways, back on topic, here's how it's shaping up:


I'm looking for some kind of "level" to show off self-shadowing with a flash light, like HL2 Episode 2. Otherwise, we get stuff like this:

(ignore the framerate, debug build; yellow-ish light)
And with more lights:

It's actually a bit slow on mid-end machines... but it's beautiful, and it Just Works with soft self shadowing
More complex of a scene:

Shows a bit of self shadowing, too.

[pjcast]

Looks really good!

[DieHard]

Those shadows look great. I hope you will release the code soon. This will help some people like me getting the shadows to look like commercial game engines.

And, the other thing is challenging for me is Culling or "Hierarchical Per-pixel Occlusion Culling".

[jjp]

Very nice What sort of shadow camera setup are you using?

[ScurvyKnave]

It's impossible to please everyone.

True. Sometimes I don't know how you put up with us.

[nullsquared]

Those shadows look great. I hope you will release the code soon. This will help some people like me getting the shadows to look like commercial game engines.

And, the other thing is challenging for me is Culling or "Hierarchical Per-pixel Occlusion Culling".

It'll be released soon along with a binary and all of the shaders and materials and media, like the rest of the demos. Though it'll run stand-alone. Also, anyone got any ideas for some kind of "level" to show it off with or something? Preferably if it was 1 mesh, that way the demo can show off large-scale soft self shadowing on the level's corridors and what-not. It doesn't really need to be big or complicated or anything. And, no, not the BSP stuff.

And, no, I'm not going to implement hierarchical per pixel occlusion culling in the demo .

The shadow camera is the default shadow camera. I never found the other shadow camera setups to do me any good, any either way, I manually "fix up" my camera in the pre-render callback.

[nullsquared]

I PROMISE I WILL STRANGLE OGRE's CONFIG FILE CLASS...

What kind of config file parser gives you the quotes along with the data? It took me an HOUR to debug why a simplistic string such as "1024" wouldn't parse as an int, unsigned or signed, or a bool, or ANYTHING. I had to MANUALLY PRINT OUT EACH CHARACTER OF EACH STRING, just to realize that the first and last characters were quotes. GRR!

Anyways, all fixed now. Every config file read got scoped into a removeQuotes() function.

... And I found a level! And the shadows are working great, better than HL2 EP2's flash light shadow!

And we got a dynamically parsed configuration file! And multiple soft self shadowing lights placed with "space"! And ... a BUNCH of a stuff.

Soon it'll all be released, time to just "fix" it up a bit. You know, I think this demo turned out quite well. Prettier than my Portalized lighting/shadowing, which reminds me, I gotta fix up Portalized lighting/shadowing with all of the fixes from this demo

[Praetor]

Sounds like a lot of really awesome work. I can't wait to see it.

[betajaen]

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