shiny - a shader and material management library [v 0.3]

[scrawl]

But, are you really sure that everything is supposed to work with just these lines? (Taken from the doxy page)

This is what the current version says (pretty much the same as your code)

Code: Select all

sh::Factory* factory = new sh::Factory(platform);
factory->setCurrentLanguage(sh::Language_GLSL);
factory->loadAllFiles();

Maybe you need to refresh your browser cache?

Besides, thanks a bunch for pointing out the issues with the docs. And no, you are not annoying or boring me in any way

[Flayer]

Maybe you need to refresh your browser cache?

Yeah, that was it. Thought it would have refreshed the cache as I closed the browser, but apparently not
Now I can see the current version so to speak =)

Besides, thanks a bunch for pointing out the issues with the docs.

I'm glad I could help =)

Anyways, I was taking a look into the materials from openmw and saw this in the moon.shader

Code: Select all

#define MRT @shGlobalSettingBool(mrt_output)

Is that used for deferred shading, or is it for something else?
Just curious as I have been trying to wrap my head around how to implement deferred shading to support tons of lights, but I might be going a little too fast for my own good here.
Have taken a good look at the example that comes with Ogre, but that demo is scaled differently and just scaling things did not just solve the problems with directional lights (or spotlights for that matter),
but I still have a lot to learn about shaders as it is with a forward renderer and shaders in general

Well, we'll see how it goes in the end =)
Thanks again

[lilljohan]

Hi,
I just wanted to let you know that there is a type error in the documentation at http://scrawl.bplaced.net/sh_doxy/defin ... aders.html

Code: Select all

shOutputColor(0) = shSample(diffuseMap, UV);

should be

Code: Select all

shOutputColour(0) = shSample(diffuseMap, UV);

Took me a while to figure out what it was complaining about =)

It would be nice if it could log an error if an included file (like "Core.h") is not found instead of just throwing an exception.

I would also like to thank you for your awesome work on this library.

[teodron]

Hi,
This library sounds like the secret weapon many people needed. I tried to use it, but it appears that it needs to link statically against boost. Is this the case? If yes, what could I do to make it link against the shared library variant of boost?

[scrawl]

You can link statically or dynamically. If you are linking dynamic version of wave, make sure to not compile the source in Preprocessor/* (which is basically an optimized, shipped version of wave).

[thebluefish]

Hi,
This library sounds like the secret weapon many people needed. I tried to use it, but it appears that it needs to link statically against boost. Is this the case? If yes, what could I do to make it link against the shared library variant of boost?

You may get this if you don't build the library and your game/project with /MD (Multi-Threaded DLL) or /MDd (Multi-Threaded Debug DLL). Boost automatically generates #pragma commands to link the "correct" version of its libraries. If your project isn't specified as DLL, then boost tries to link statically instead of dynamically.

Great library though, I'm really loving it. Currently I'm keeping my project as Shaders [Off, Basic, Advanced] as an option. Do you have any way of specifying a configuration for a specific object rather than a viewport? Say I want to add the ability to turn off effects on my terrain but keeping my characters with full effects or vice-versa.

[scrawl]

Do you have any way of specifying a configuration for a specific object rather than a viewport? Say I want to add the ability to turn off effects on my terrain but keeping my characters with full effects or vice-versa.

Yes, that is what global settings are intended for.

Code: Select all

mFactory->setGlobalSetting("terrain_parallax", "true")

Code: Select all

#define TERRAIN_PARALLAX @shGlobalSettingBool(terrain_parallax)

#if TERRAIN_PARALLAX
...
#endif

[Tubulii]

Hi,

Is it possible to replace the microcode cache with a different approach to support ogre < 1.8 ?
Ogre 1.7 does not have a shader chache.

[scrawl]

Just remove the offending code. It will work without.

[scrawl]

I'm looking to add 2 more features. Feel free to add your comments or make suggestions.

Saving functionality

Saving functionality for materials. Realtime editing is already possible, so this is the last obstacle for seamlessly integrating a material editor into your game. The workflow could look like this:

- Write the shaders and base materials in a text editor.
- In the in-game material editor, start creating derived materials and tweaking them by overriding the properties of the base material.
- Once you're satisfied, hit the "save" button and enjoy the exported .mat file. Then repeat from step 2 on

Also nice to have would be a "Reload shaders" functionality, because it's kinda tedious to restart your game every time you've made a shader change. EDIT: After thinking about it again, this is already possible by just deleting and re-creating the factory

Caching improvements

You might notice the current caching functionality (which you can turn on, and is disabled by default) is a bit annoying - it requires you to delete the cache manually every time you change a shader. Of course, this could be "fixed" by not using the cache until the final release of your software is ready - but that's not really optimal. A nice solution would be to save a timestamp of the shader files' "Last modified" time and wipe the corresponding cache if that timestamp changes.

As a side note, we are currently integrating this library into StuntRally - stay tuned, I will post more when it's done.

[scrawl]

As promised, we integrated this library into StuntRally 1.8. The main advantage was better compatibility due to providing a GLSL version, as well as getting rid of hardcoded shaders which made editing tedious.
The materials can also be used as references for:
- Integration with paged-geometry (wind effect, grass fading)
- Triplanar texturing for Ogre::Terrain
- Soft particles
- Multi render target output for SSAO, DoF, etc

[BTolputt]

That's awesome scrawl!

[noorus]

Can I suggest prefixing the header file names with "sh" or something?
The names are so generic that they might collide with other libraries or people's projects rather easily.

[bstone]

Just put them in their own folder. It's better that way because you can't persuade every author to rename his library files and you'll be working with lots of libs eventually.

[noorus]

Just put them in their own folder. It's better that way because you can't persuade every author to rename his library files and you'll be working with lots of libs eventually.

That would work fine, except the shiny headers themselves refer to each other without a path. So I'd have to add the same path prefix to shiny's header-to-header includes, which isn't a nice thing to maintain. Or am I missing something..?

[scrawl]

When you're compiling it as a static or dynamic lib you don't need any other includes besides boost, so that shouldnt be a problem.

[bstone]

The standard search order for the header files is to look for includes in the same folder so as long as you keep all shiny headers in their own folder they should work fine. You will reference them in your code as #include "shiny/xyz.h" for e.g. and they should get their includes from there. External dependencies might be a problem but they are usually easy to work around using linked folders. Prefixed file names are one of the very few things I don't like in Ogre - makes my life slower b/c of the extra typing

[efaj]

Shiny needs 1 absolute path on construction, but in my project I use "res/creatures/crit1" and so on, and "res/materials" for common shaders. How could this problem be approached with shiny?

To get this working in Ogre, I use:

Code: Select all

tempVector=cf->getMultiSetting("MatPath",secName);
			for (unsigned int ii = 0; ii < tempVector.size(); ++ii) {
				boost::filesystem::path materialFilename=tempVector.at(ii);
				if(!Ogre::MaterialManager::getSingleton().resourceExists(materialFilename.stem().string())){
					//Load Material
					Ogre::DataStreamPtr dataStream =Ogre::ResourceGroupManager::getSingleton().openResource(
							(indexPath.parent_path()/materialFilename).string(), groupName );
					Ogre::MaterialManager::getSingleton().parseScript(dataStream, groupName);
				}
			}

Which manually loads each material before use (cf is a configfile that represents a complete asset, with MatPath representing the Path to the Material, so I load it before the mesh is loaded).
Which would be the shiny way?

My main reason to attempt to use shiny is that I'm trying to enable/disable some shaders at whim, be it the artist, the end user, or me. For example, I use a Rim Lightning shader, but, this effect may not look appropriate in a cave area, so I want to enable it/add it depending on which stage you are. RTSS doesn't do this, right? (since I haven't found how to load a .cg with RTSS or something like that, just functions that seem to cover only basic material stuff) And shiny can do this, right?

[scrawl]

shiny doesn't use Ogre's resource system at this point. It would be nice if it would (even though I personally don't need it).
Another thing it doesn't support is on the fly loading from disk, which I personally haven't needed either because loading materials is extremely fast and shaders are compiled on demand anyway.
So yeah, both of this should be relatively easy to add and I'll gladly accept patches.

[efaj]

shiny doesn't use Ogre's resource system at this point. It would be nice if it would (even though I personally don't need it).
Another thing it doesn't support is on the fly loading from disk, which I personally haven't needed either because loading materials is extremely fast and shaders are compiled on demand anyway.
So yeah, both of this should be relatively easy to add and I'll gladly accept patches.

Personally, now, after much trial and error, I've learned how the system works, and I, too, don't see the need for either I can keep my file structure by adding the directories to the name of stuff (source materials/rimLightning/RimLight.shader), and realized that "#include" is relative to the Platform's path (which I can settle to use "res", so I'll be using: #include "materials/core.h")

Though, I think it would be better if the loading of files in both cases was relative to the file-being-parsed's path, this is something so little important and arguable, that I don't care.

Kudos for the library. IMO, this is something that could even be part of Ogre.

[scrawl]

Though, I think it would be better if the loading of files in both cases was relative to the file-being-parsed's path

Agreed, and fix commited.

[bstone]

Kudos for the library. IMO, this is something that could even be part of Ogre.

I agree, that would be cool. But it works the other way too. It's funny though that shiny gets little attention overall, but I guess the problem is that not many Ogre users reach the level where you absolutely need something like shiny to move forward. Or maybe RTSS is all hot these days?

[Zonder]

Kudos for the library. IMO, this is something that could even be part of Ogre.

I agree, that would be cool. But it works the other way too. It's funny though that shiny gets little attention overall, but I guess the problem is that not many Ogre users reach the level where you absolutely need something like shiny to move forward. Or maybe RTSS is all hot these days?

As soon as I read about it I added into my important library list

[scrawl]

It's been 8 months since I tagged the 0.1 "version" and a lot has happened so I figured I'd call it 0.2 now. Everyone's probably just using the trunk anyway but it's nice to have some kind of changelog besides the commit logs:
- Material LOD support.
- Shader caching now detects changed shader files.
- A few macros added to core.h.
- Lots of misc fixes.

[scrawl]

A new convenience macro has been added.

Previously, when using an optional texture unit, one would need a property for the texture itself, plus a property to enable / disable the texture unit.
This huge redundancy can now be avoided with the new macro, which checks if a property name (in this case the texture name) is empty. It also integrates with the permutation handler.

Also, I'm currently in the planning stage of adding a realtime material editor in QT. It won't be a standalone application, but instead will be available from a simple 1 line call in the user's application, which will open an editing window. That way, all editing will have an immediate visual effect on the game window without a restart.