Ogre Forums

Edit: RELEASED! On page 3.

Edit: It seems that the vote is a YES! Screen shots on the second page, to be released soon.

Is there any interest in a soft shadows (& per pixel lighting) demo written in a bit more "low level" Ogre rather than using ExampleApplication?

My points being:

1) Ogre seems to have so many awesome demos, yet no one single great "soft shadows!!!!one11!1one1!!!" demo. Lots of people come in and go "does Ogre do soft shadows?", and we go "if you make them". Ok, and they leave. So now we can go "yes". Plain and simple. Yes, it does. Yes, I know shadows are very scene-specific and all. But we can make some kind of "generic setup" that works great with little tweaking. Surely, something like this:

Will attract lots of people

2) ExampleApplication sucks. Sorry, but it does. Too many people look at the Ogre demos and get stuck with CEGUI, ExampleApplication, and OIS (not saying any one of these is "bad", well, I guess other than ExampleApplication ) because they think "that's how Ogre works". No. So this demo should show case more straight-forward Ogre. Like people know it - make windows, choose renderers, render into the window. No frame listener crap (sorry, but many people get misled by frame listeners - not implying they're bad, again) and what-not.

3) Yes, there's the Wiki. But I think some people will feel a lot more comfy with a full-on example, like the other examples, rather than scrapping code from all over the wiki.

I actually started writing it, but felt I might need another day or so to get it "working good". You know, polished. Like the rest of the demos. Though I'm not going to finish it if there's any demand for it.

So, yes, or no? If yes, I'll probably finish it by the end of tomorrow, depending on how much homework I have

(If I do end up finishing it, it'll obviously be released under the same totally free for whatever-you-want no credit needed blah blah open source license as the rest of the demos, along with all shader code, of course)

Oh, and I couldn't figure out whether to put this here or in "Using Ogre in Practice". Move if wished for.

As an artist, I havent a clue how to make shader texture shadows of any kind to work in ogre. But I would definately like to be able to use them .

I agree there is some learning involved in extracting the basic things from ExampleApp, and in fact I have been through rewriting the thing a few times until I found something that works for me and which I am comfortable to use as my framework together with OIS and ODE (for now) for further experiments. I still think the series of tutorials is good, one of them does the raw approach and explains OIS and CEGUI.

Showing soft shadows may be a good thing, but I'm not sure it can serve as a basic tutorial, maybe put it into the Advanced tutorial series. If you want to show how soft shadows work (in fact basically how using vertex and fragment programs works) you may still want to stick to ExampleApp and just show how to setup the material and programs.

-Martin

A working example would definitely serve better than some white papers and/or outdated code snippets (although both of those definitely helped and shouldn't be overlooked when learning a technique like this). I think this could serve the community well.

Adding a demo with soft shadows, using something other than ExampleApplication would be a very useful addition. Great idea!

All demos welcome.

Demo_Shadows already has a PCF depth/shadowmap example though - doesn't look quite as nice as that because the PCF is the simplest possible to make it run well on a wide hardware base, but it's there.

Personally, I think ExampleApplication gets the job done - it beats embedding the same bootstrap code in every single demo. Some people get all frothy-mouthed about it, but I'm largely unable to understand why - it's not exactly hard to look up the implementation of a superclass (OO systems do tend to work that way after all). I figure whatever way I do a bunch of examples, someone's going to hate it, so my conclusion is 'meh' - I'll do it the way I want until I'm convinced otherwise.

sinbad wrote:All demos welcome.

Alright, sounds good. It's a bit early in the morning right now (right before school, actually ), so I'll probably finish it by the end of today.

Demo_Shadows already has a PCF depth/shadowmap example though - doesn't look quite as nice as that because the PCF is the simplest possible to make it run well on a wide hardware base, but it's there.

I know, I know. But I saw two problems:
1) it looks _really_ bad by default. You have to increase the bias quite a lot (or at least I did) to get some useful results. And while that "brute force" PCF is a neat example and all - it's really barely used against more advanced PCF, like random point PCF or bilinear PCF and so on.
2) I found the example shaders quite hard to follow. First of all, IIRC (this is not code machine), the depth shadow map shaders were split apart into quite the files. Second, there were all sorts of complications that I personally found unneeded .

Personally, I think ExampleApplication gets the job done - it beats embedding the same bootstrap code in every single demo. Some people get all frothy-mouthed about it, but I'm largely unable to understand why - it's not exactly hard to look up the implementation of a superclass (OO systems do tend to work that way after all). I figure whatever way I do a bunch of examples, someone's going to hate it, so my conclusion is 'meh' - I'll do it the way I want until I'm convinced otherwise.

You're right - it does get the job done. However, when newbies come and see it, they think "that's how Ogre works". Then they leave because they thought, for example, that only a static scene could be created because of the createScene() method. Or, for example, that the only way to do the game loop was using frame listeners. And so on. And when they _do_ start going lower and implementing the boot strap Ogre code, they get randomly "stuck".

nullsquared wrote: You're right - it does get the job done. However, when newbies come and see it, they think "that's how Ogre works". Then they leave because they thought, for example, that only a static scene could be created because of the createScene() method. Or, for example, that the only way to do the game loop was using frame listeners. And so on. And when they _do_ start going lower and implementing the boot strap Ogre code, they get randomly "stuck".

I'm willing to consider 'better' examples so long as they don't require every demo to include bootstrap code. But to be perfectly honest, people that give up that easily probably aren't meant for Ogre anyway. I can live without a few more people who need extreme hand-holding, thanks I don't run Ogre as a 'numbers game' - I'd rather have a smaller community of smart, self-sufficient / experienced people than a larger community of 'help me make a game NOW' people; frankly, I really won't shed a tear if they go elsewhere. I don't think the ExampleApplication framework is at all inpenetrable to anyone with half an ounce of coding sense.

Personally I think the Example Framework is fine enough, for the examples anyway. But I do believe that it would be good not to use it in the tutorials. The tutorials should teach Ogre from the ground up, so to speak, because that's exactly what you need for any real use. The Example framework might allow the tutorials to show something "interesting" earlier, but in the end they left a serious gap, for me at least at the time

CABAListic made the strong point IMHO. Tech demos should showcase particular functionality, and how to just do that. Tutorials are to teach how to get there from the ground up.

from a noob point as my self, it was the most difficult part to start with ogre, it took to a non ogre's site tutorial to learn that you don't have to use listeners.
The more classic onUpdate() would have helped a lot back when i started. or maybe start with a "lets build a listener from zero and how it works"...
only a opinion from a non expert c++ programmer.

...you could always throw a comment in the ExampleFramework.h file such as:

/*
This framework is for simple examples, for alternative application frameworks you can go to:

http://www.ogre3d.org/wiki/index.php/Pr ... pplication
*/

I had to find it myself, but it wasn't that hard. Used the example framework at first until I replaced it with my own near identical code, then finally caught on to the Practical Application framework and really started to tune how I wanted the application to work.

Its not hard to figure out, and the code comment really isn't needed, but it *could* help some people that really don't know its there.


I could see maybe one demo that basically is a 'complex demo' that shows an alternative setup, so people can see a more advanced framework and more interaction... but I don't think it would have to be that high of a priority.

Can anyone tell me what is wrong with listeners? I started using Ogre, and use them for my game, and i must admit that i took the ExampleFrameListener as a basis, then i modified it adding things to it, but the general idea its the same, why everyone complains about it? i mean i know how to code the 'raw' way without listeners, but can anyone say specifically why not to use them?

NoodlesOnMyBack wrote:Can anyone tell me what is wrong with listeners? I started using Ogre, and use them for my game, and i must admit that i took the ExampleFrameListener as a basis, then i modified it adding things to it, but the general idea its the same, why everyone complains about it? i mean i know how to code the 'raw' way without listeners, but can anyone say specifically why not to use them?

Some people say it's faster to use "raw", but it isn't really a noticeable slowdown, (Probably less than 1 fps) to use them

danharibo wrote:

NoodlesOnMyBack wrote:Can anyone tell me what is wrong with listeners? I started using Ogre, and use them for my game, and i must admit that i took the ExampleFrameListener as a basis, then i modified it adding things to it, but the general idea its the same, why everyone complains about it? i mean i know how to code the 'raw' way without listeners, but can anyone say specifically why not to use them?

Some people say it's faster to use "raw", but it isn't really a noticeable slowdown, (Probably less than 1 fps) to use them

If anyone show me the benefits of using the raw way i'll go and change my code right away... and im not only meaning the 1 FPS slowdown (wich probably it isnt true) im also refering to the design of the application, is this a bad habit in a programming kind of way that i dont understand?

EDIT: i just realized how off topic this is, but i have to know!

Not that they aren't a good way to do things. Just that they aren't good for everything. A frame listener is called based on frame events, such as start or end rendering. You usually want other systems like input or IA to run asynchronously, and being frame listeners the only way exposed in the demos leads you to think that's the right way to do things. It's right, but not the rightest.

Part of the problem is that settling for the demo framework forces you to its interface and design. What if you want to add in your own script parsers? What if you want to be able to change screen resolution? Windowed vs full screen mode? Pausing the rendering for whatever reason? By using the demo framework you don't understand how Ogre really works, you just accept it and believe you have to code in everything into the createScene and myAppFrameListener class. If you understand how to setup Ogre you can accomplish it in any way you want, and you don't have to design around the generalized demo framework. Sticking with that framework for anything other than a small demo is a bad idea.

I also found the demo framework very confusing when I first started, but I eventually got a hold of things thanks to the Ogre community.

@nullsquared: I'm interested to see what you come up with!

[edit] Looks like my topic isn't really related to the question about frame listeners.

FrameListeners are great in the sense of notifying you every frame so you can perform some task, the problem is that as you add more complex tasks to perform every frame, the framelistener class gets bloated and filled with all this data, so it can use it every frame. Its more modular and flexible if you control the render loop yourself, and give objects an update method, so they can interact or perform actions in an ogranizaed fashion.
[/edit]

I'm also interested in checking out what you will do

Kencho wrote:Not that they aren't a good way to do things. Just that they aren't good for everything. A frame listener is called based on frame events, such as start or end rendering. You usually want other systems like input or IA to run asynchronously, and being frame listeners the only way exposed in the demos leads you to think that's the right way to do things. It's right, but not the rightest.

Why i would want to run input asynchronously? what i understand of asynch objects is that they run in their own time, separately from the system time, so, 99% of the cases (my cases at least) i want the input (or anything else except network code) to flow with the time between each frame (buffered or unbuffered), whats the point of performing input operations in a different time or if nothing is shown on the screen? maybe im getting the wrong picture, but can you explain in detail how this is a problem?

If the render gets stalled for some reason and your framerate falls to 10fps, the input falls to 10fps, and the IA, and networking... Players want their network connection as fluid as possible. But they also want the controls responsivity high.

Let's not get off topic.

Quick question! Normal blurs look horrible (brute force mean, you know). I'm too tired to wrap my head around a gaussian blur shader, nor can I find the one in the examples. And I've got lots of homework. And I got to brush up on matrices for my stupid math fair thing. And I want to release this today, but I might not get to it . How do I make a nice gaussian kernel if I know the width/height and blur radius of my stuff? I want to precalculate it so I don't write long big interfaces to confuse the n00bs between the C++ and shaders . If someone precalculates a guassian kernel for me, my never ending thanks shall be your reward . 1024x1024 map (yes, 512x512 is too low for some scenes), radius of, uh. 5. Or something. Yeah.

Take a look at Math::gaussianDistribution and how it's used in Demo_Compositor, specifically GaussianListener::notifyViewportSize. Because of the number of samples a gaussian tends to need, they usually need to be done in 2 passes, vertical and horizontal.

*Edit: here's the weights for a 5-pixel wide blur (11 pixels in total, one central and 5 either side): Obviously that's for the central pixel (first), and the other 5 heading away from the middle. It's symmetrical so you can use those latter 5 in reverse order for the other side. It's not totally unit-size (0.01 off or something) but it's quite close and gives a nice effect. The texture size simply affects how you calculate the offsets in each position ie (1 / width) increments for horizontal pixels.

RE: a new demo for soft shadows
yes please

RE: example framework
This was a giant hurdle for me to overcome. Not so much in getting something running, but in understanding how one could write a serious app with such a thing. It was a while before I really dug into how I would setup my own viewports and my own render loop complete with input, sound, physics etc...

I think a series of tutorials showing how to build up a practical application is the place for a change though. The demos should be the easiest thing that works to show the tech. The tutorials should help someone learn how you actually use the system.

chmod wrote:
I think a series of tutorials showing how to build up a practical application is the place for a change though. The demos should be the easiest thing that works to show the tech. The tutorials should help someone learn how you actually use the system.

Like this one?

http://www.ogre3d.org/wiki/index.php/Pr ... pplication

xavier wrote:

chmod wrote:
I think a series of tutorials showing how to build up a practical application is the place for a change though. The demos should be the easiest thing that works to show the tech. The tutorials should help someone learn how you actually use the system.

Like this one?

http://www.ogre3d.org/wiki/index.php/Pr ... pplication

Yes that is a fantastic write up (which I referenced heavily when i was starting my app, thanks!) but I meant done more like the tutorials from the wiki, where the beginner builds up to adding it all in so that each part added can be digested.

Given the current sources of info, I think a lot of people just copy/paste this stuff and then come ask the forums why it doesn't work. I just think approaching it as a lesson plan will impart more information from the beginning.