Stencil Shadows

[phobossion]

Forget node editors, they are absolutely absurd. What you want is a high level shader language that allows specification of the same behaviour as a node-based language but in a few lines instead of a tangled screen full of boxes.

No, please. Just don't. Having to learn just another "high-level shader language" just for the sake of using Ogre is not the way to go, IMHO. We already have Cg for multiplatform shader development. Node-based editors are cool (and as others mentioned here are fairly simple to write if you have a snippet-to-node conversion system) but not really suitable for the low-level Ogre environment. This is something that fits into a GDK software such as UDK and not directly into the rendering system used (as that one should not know about the process used to author the shaders used in the first place).

What Ogre could do is to provide a library of common shader functions for general tasks (normal-mapping, shadow mapping, penumbra, parallax mapping, encoding/decoding deferred pipeline data into textures, ...), plus having a transparent and easy to use shader-based material system (look at Unity for that).

Cheers

[Crashy]

What Ogre could do is to provide a library of common shader functions for general tasks (normal-mapping, shadow mapping, penumbra, parallax mapping, encoding/decoding deferred pipeline data into textures, ...)

AFAIK, this is basically the way RTSS works, by assembling code snippets together. For me, a shader node editor should rely on RTSS. I'm not a big fan of node editor as I like to understand what I'm writing, but I think I'm already an old-fashioned game developer. Nowadays, most of people don't even want to touch at shaders, they want to have a list of sample materials such as normal mapping-parallax mapping-whatever mapping, and only plug their textures and lighting parameters. And they absolutely don't care about the shadow technique used. What is wanted is to have fancy graphics with the fewer clicks possible.

To me, Ogre shouldn't care about this, for a few reasons:
-Node based editor is...an editor, and must be integrated into a more general game/level editor, not in a "graphic library".
-Ogre is somewhat a "low" level rendering engine, and shouldn't be specialized to anything: IE: a fixed deferred rendering pipeline, such as UDK(not sure, but I think it is), easy to use for beginners, but quite limiting when you want to do custom things.

People may know I love to do research about NPR, and Ogre's flexibility is a big advantage for me: I can do anything and any shader I want, I'm not limited to a fixed set of shaders provided by the engine that only allows to do "photorealistic". And without any doubt, I'm ok for sacrificing some performance in exchange of flexibility .

However, it should be necessary to standardize the shaders used in the demos, because sometimes the shaders have different names, or even have different implementation, between the various hlsl/cg/glsl versions.

I may have a lot of other things to say, but this is not the right topic here

Oh, and I'm ok with the idea of removing stencil shadows from Ogre.

[phobossion]

AFAIK, this is basically the way RTSS works, by assembling code snippets together. For me, a shader node editor should rely on RTSS. I'm not a big fan of node editor as I like to understand what I'm writing, but I think I'm already an old-fashioned game developer. Nowadays, most of people don't even want to touch at shaders, they want to have a list of sample materials such as normal mapping-parallax mapping-whatever mapping, and only plug their textures and lighting parameters. And they absolutely don't care about the shadow technique used. What is wanted is to have fancy graphics with the fewer clicks possible.

I didn't look at the system in-depth yet, but from what I read on these forums it seems to be quite cumbersome to pick up and use. But if there are some functions like this, it's good to know!

To me, Ogre shouldn't care about this, for a few reasons:
-Node based editor is...an editor, and must be integrated into a more general game/level editor, not in a "graphic library".
-Ogre is somewhat a "low" level rendering engine, and shouldn't be specialized to anything: IE: a fixed deferred rendering pipeline, such as UDK(not sure, but I think it is), easy to use for beginners, but quite limiting when you want to do custom things.

People may know I love to do research about NPR, and Ogre's flexibility is a big advantage for me: I can do anything and any shader I want, I'm not limited to a fixed set of shaders provided by the engine that only allows to do "photorealistic". And without any doubt, I'm ok for sacrificing some performance in exchange of flexibility .

I agree on the editor part but disagree on the "shouldn't case" thing - yes, Ogre should retain the flexibility of custom shaders and rendering processes, but if the software is aiming at being widely used. it should provide a basic set of plug-and-play shaders/materials that can be used as a starting point to developing your own (if you care). The sole fact that people use the node editor in UDK and use it to create some pretty awesome and innovative things is a proof that people will use the flexibility the toolkit provides when given the change. On the other hand, if you want to have a textured mesh with specular and normal map in UDK, it's just a few clicks away. You don't have to do extensive research and play with many aspects of the engine to do that. In other words, if you want people to use your software, lower the entry requirements as far as you can. Then you can expect them to experiment and come up with new ideas once they are somehow proficient with it.

[drwbns]

Yep, I would definately use it if it was there. Mainly for quick visual testing instead of tweaking then running Ogre. It can give a good initial result that you can branch from. But like others said, may be too much hassle for anyone to attempt.

[fsteff]

-Ogre is somewhat a "low" level rendering engine, and shouldn't be specialized to anything: IE: a fixed deferred rendering pipeline, such as UDK(not sure, but I think it is), easy to use for beginners, but quite limiting when you want to do custom things.

People may know I love to do research about NPR, and Ogre's flexibility is a big advantage for me: I can do anything and any shader I want, I'm not limited to a fixed set of shaders provided by the engine that only allows to do "photorealistic". And without any doubt, I'm ok for sacrificing some performance in exchange of flexibility .

However, it should be necessary to standardize the shaders used in the demos, because sometimes the shaders have different names, or even have different implementation, between the various hlsl/cg/glsl versions.

I think the best way is like it is done with the terrain: Simple for beginners, but very flexible if you don´t use the default material generator.
The same way should it be with shadows: An easy to use RTSS-based solution for beginners and people, who don´t need much customisation - and a more advanced possiblility (like the actual one) for the others.

Also, I don´t mind if the stencil shadows are removed, because I don´t use them.

[Crashy]

think the best way is like it is done with the terrain: Simple for beginners, but very flexible if you don´t use the default material generator.
The same way should it be with shadows: An easy to use RTSS-based solution for beginners and people, who don´t need much customisation - and a more advanced possiblility (like the actual one) for the others.

I had this in mind when writing my post. I don't use the default material generator system of the terrain, but It was really simple to write my own one and do like I want.

And to be honest, I quite love the way shadows are working right now, because it's easy to make custom material setup. But I understand that maybe people may just want to use it quick, such as :

Code: Select all

material RTSS/ShadowSample
{
	technique
	{
		pass
		{
						
			texture_unit
			{
				texture Panels_Diffuse.png
			}				
			
			// RT Shader system section.
 			rtshader_system
 			{	 	
 				//setup a pcf shadow receiving material, using 4 taps pcf
 				shadow_type pcf 4
 			}			
		}				
	}
}

[Jabberwocky]

My opinion:

Stencil Shadows:
Stencil shadows can go. It's old tech. If someone wants them, they can use an old version of ogre. Ogre 2.0 is striving to be a more modern, more sleek and efficient renderer, so it's an appropriate time to lose stencil shadows.

FF Texture Shadows:
These can go *IF* there is an easy to use replacement - RTSS or a material editor. You should not be required to write shaders to get shadows within ogre. I haven't used RTSS enough to know whether it qualifies as "easy to use" or not.

Hand-authored shader-based integrated texture shadows:
This is not RTSS, not a material editor, but rather raw .cg/.glsl/.hlsl shader files like those that have been shipped with ogre for years. These need to be kept. There should be good examples shipped with ogre. Many ogre users legitimately don't want to work within the confines of a material editor. They want to write and modify shaders.

So, I think the ideal solution is that all shadows are integrated texture shadows. But Ogre supports (with examples) both a simple "sandbox" method of using them, as well as raw, explicit shader files. This reduces bloat in ogre's rendering code, yet supports both shader experts, and those who want the graphics engine to handle shadows for them.

[dark_sylinc]

Just to clarify, what I have in mind is modular and more as a component. It would spit shader code, setup a material; and then you can use it. If you want to get close to the metal, you would still do the same way you do now. I'm not thinking of replacing the material system or the shader system we have now.

The output shader code & material from this system can be written into a file for easy debugging or even manual tweaking.

[masterfalcon]

I like that idea. Sounds somewhat similar to the terrain shaders. Which work, but I do think they need some performance tweaking.

[Jabberwocky]

The terrain shaders do a good job of procedural shader generation. But that code is difficult to work with if you want to significantly modify the shaders, e.g. to add support for multiple light sources. The turn-around time to modify the source, re-compile, run, and view your changes is slow. Especially if you're like me and tend to make lots of stupid little mistakes in your shader code.

dark_sylinc, what you're proposing sounds decent. But probably a lot of work. Shader generation code does get pretty complicated if you want to support hlsl, glsl, cg, different shader models, and lots of shader functionality options. (The terrain shaders do all this.) But I really like the idea of dumping out a generated shader to a text file which you can hand modify. I ended up doing something similar with my custom TerrainMaterialGenerator. It helps a lot.

One thing about cg - way back when I started Salvation Prophecy I picked cg because I thought I would get away with using cg on both Windows and Linux. But it turns out AMD's support for cg on Linux is totally bunk. So I needed to port to glsl. Because of this, I'm not really sure if a cg option is worth supporting in any shader generation module. If you're just sticking to windows, you should use hlsl. If you need to port to Linux you need glsl. I don't have any experience porting to Mac, so I'm not sure how useful cg is there.

I wish I were more familiar with RTSS. An obvious question is, why not just use or improve RTSS? Why create another shader-generation module? But I don't know RTSS enough to fully understand its features or limitations.

[masterfalcon]

As far as OS X goes, if you're already creating glsl then you're fine and we can just use that. Also, while you can translate Cg to GLSL ES, it's not always that great and you're better off just writing native shaders.

[Klaim]

By the way, someone anonymous reported there that NVidia is stopping support of Cg and recommand switching to both hlsl and glsl. I have no idea if it's correct and couldn't find any evidence of this. The edit in question have been endorsed by some votting process so it's not clear if it's false information or not.

[Kojack]

Speaking of CG, for a while I've been thinking that if we do an overhaul of the ogre samples, we should drop all cg shaders and stick to direct glsl/hlsl/glsles. Some of the bugs we've had with the samples have been due to cg shaders getting mixed up with non cg shaders (such as a cg vertex shader with a hlsl pixel shader), due to the way shader delegates work.

[Jabberwocky]

Makes good sense to me, Kojack.

[masterfalcon]

I second that Kojack.

[sparkprime]

Personally I have found the HLSL compiler to be extremely slow at compiling shaders (compared to Cg). This does matter, if nothing else it slows down development.

[syedhs]

I think shader cache feature in Ogre should help you with that?

[mkultra333]

I think shader cache feature in Ogre should help you with that?

Oh wow... this shader cache thing has been in Ogre for almost 3 years, I use Ogre almost every day and constantly visit the forum, and I'd never heard of them.

Just gave them a test now, based on info in the only thread that seems to mention them in detail, http://www.ogre3d.org/forums/viewtopic.php?f=4&t=61004
They're great, cut down resource initialization from 10 seconds to less than half a second. Probably be even better on my much slower laptop.

I wonder what other secrets Ogre is hiding. Someone should tell people about these things. No doubt they're mentioned in the small print somewhere, but such a neat feature could perhaps use a bit more exposure.

[Klaim]

All of those Ogre gems should be listed here: http://www.ogre3d.org/tikiwiki/tiki-ind ... +checklist
Unfortunately, that page seems out of date. Also, it's not in the front page.

[Zonder]

Also, it's not in the front page.

Should have been in the release notes.

[spacegaier]

Also, it's not in the front page.

As soon as it gets updated / improved by someone, I will move it there myself .

[DanielSefton]

I wish I were more familiar with RTSS. An obvious question is, why not just use or improve RTSS? Why create another shader-generation module? But I don't know RTSS enough to fully understand its features or limitations.

The fact that nobody understands how the RTSS works is its biggest problem. Extending the RTSS for me is an absolute nightmare. Either we need to get some extensive documentation written, or we replace it with something new and simpler, or we don't use this fancy shader generation stuff at all. Why not just provide a bunch of raw shaders? It's not difficult to add shaders to material scripts.

Speaking of CG, for a while I've been thinking that if we do an overhaul of the ogre samples, we should drop all cg shaders and stick to direct glsl/hlsl/glsles.

Yes.

[Klaim]

I don't know RTSS but at some point in my project I will have to have a on-the-fly shader composition system (Ogre Compositor work only with pixels of a viewport right?) so if it can do that it's interesting at least for me. I didn't try to use RTSS yet, but if later I find that it's unusable I'll be forced to implement a system myself specific to my need.

[Zonder]

I don't know RTSS but at some point in my project I will have to have a on-the-fly shader composition system (Ogre Compositor work only with pixels of a viewport right?) so if it can do that it's interesting at least for me. I didn't try to use RTSS yet, but if later I find that it's unusable I'll be forced to implement a system myself specific to my need.

Have a look at shiny http://ogre3d.org/forums/viewtopic.php?t=71117

[Klaim]

I don't know RTSS but at some point in my project I will have to have a on-the-fly shader composition system (Ogre Compositor work only with pixels of a viewport right?) so if it can do that it's interesting at least for me. I didn't try to use RTSS yet, but if later I find that it's unusable I'll be forced to implement a system myself specific to my need.

Have a look at shiny http://ogre3d.org/forums/viewtopic.php?t=71117

Yes that's another possibility I forgot about, thanks for reminding me.