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

A place to show off your latest screenshots and for people to comment on them. Only start a new thread here if you have some nice images to show off!

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

Postby scrawl » Tue Jul 24, 2012 8:38 pm

In this post, I'm presenting my shader and material management library to the OGRE community. I'm dividing this post into 3 sections, and the "Motivation" part will be a bit longer, so feel free to skip to the second part if you're impatient.



Motivation

Before I start, let me give you a little background info. I'm a hobby game developer and I find it particularly exciting to write shaders. More specifically, I've been using Ogre's material system for writing shaders for games since about a year.

Now, Ogre has a nice material system and I'm not criticizing it at all. For what it can do, it does a great job. However, I've experienced that the more complex your shaders and materials get, Ogre's material system alone simply doesn't fit your needs - while it gives you nice rendersystem-independent access to features, I found that if you use a complex setup of shaders, it's just not high-level enough. In this section, I'm going to explain some of the reasons behind this, and share the experiences that I've made coding shaders for Ogre.

Poor Choice of High-Level Languages

This section is mostly based on my own observations and as us such might be slightly biased. For further reading, you might be interested in reading this StackOverflow discussion.

The most popular languages for writing shaders are HLSL, GLSL and CG. They have basically the same features, but the syntax is slightly different. So which one do you choose?

HLSL is only available for DirectX rendersystems, and GLSL is only available for OpenGL rendersystems.

CG claims to be "cross-platform" because it supports both DirectX and OpenGL, but if you have worked with CG for a while, you will see that it's not really portable in reality:

- CG is poorly supported on ATI cards, especially in OpenGL mode (This is not really surprising, since CG is provided by NVIDIA and no one can blame them for "advertising" their own cards). To my knowledge, there's not even an ATI/OpenGL CG profile that supports more than 32 constant registers.
- CG Runtime is very slow. In my profiling tests, compiling a shader with CG took about 20 times longer than the same shader in GLSL.
- CG Runtime is closed source, and NVIDIA doesn't provide a version for FreeBSD. So it's not a good choice for open source games.

If you want a decent amount of portability for your shaders, your best choice seems to be using both HLSL and GLSL by writing the same shader source code twice and maintaining 2 different code paths. Yes, there really are real-world libraries that actually do such a thing. Look at the SkyX / Hydrax sources for example. If that fact doesn't indicate a poor choice of languages, then I don't know.


Permutations and non-predictability

Thomas Grip from Frictional Games has written a very nice article about this problem, i highly recommend reading it. Here's a small extract:

In HPL1 there I used a bunch of shader files, one for each specific effect I wanted to do. No specular - new shader, new light type - new shader and so on. Even though HPL1 does not have that many shader combinations I ended up with 10 or so shaders that did about the same thing with various smaller changes. This was not so hard at the start, but when I wanted to optimize it was very frustrating to have to update 10 files all the time and some optimization became a bit hackish or simply left out. There where also times when I wanted to add even more shaders to optimize for specific hardware but I just didn't have the energy to manage even more shaders, so I skipped it.


In OGRE, you can use defines ( #ifdef MATERIAL_HAS_SPECULAR and so on ) to use the same shader source code for a set of shaders. However, you still have to add a "vertex_program" / "fragment_program" set for each combination there is (or you can simply create the actual vertex/fragment programs in c++ code, but then you lose the ability of setting auto constants through material scripts and many other neat features).

For this reason, as soon as lots of shader permutations come into play, many OGRE users/developers are simply assembling their shaders completely in C++ code (this is done in Hydrax and Ogre::Terrain for example). I have done so as well, but found it really annoying to code shaders this way for a couple of (obvious) reasons.
- After every shader code change, no matter how small it is, I have to recompile my application. This is especially annoying because shaders can be very hard to debug, and for me this has resulted in a huge loss of productivity.
- The shader as a whole becomes obfuscated and hard to look at.
- There is no syntax highlighting.

Another point to consider is that if your game has a system for user-created mods, your users won't be able to create any custom shaders since you have essentially hard-coded your shaders.

Okay, so we can agree at this point that assembling shaders in code is bad. So what are the alternatives? At this point, there don't seem to be any decent ones, and that's why lots of people are still using this approach, unfortunately.

Managing user settings

This is one another example where Ogre's material system alone simply doesn't fulfill my needs. If you look at most games, there's a (from my experience, quite high) probability that all they offer the user to choose from in terms of graphics settings are presets like Low, Medium, Ultra. But from a user's standpoint, there is no reason why it shouldn't be possible to enable or disable each shader feature individually. So why do many game developers choose this approach? My guess is that they are probably using a material system similiar to Ogre's. They probably add 3 techniques for all their materials, one for low, medium and high, respectively. This is a really bad choice because it creates lots of duplication and redundancy in your material scripts, since the 3 techniques will usually do the same thing with minor differences.

The main point here is that a Material simply isn't the way to go as an interface for content creators. It's desirable to abstract away all the things that an artist (or material designer) should not have to worry about at all - in this case, that is, managing all different combination of graphics settings that exist for the game. I'm proposing to add a more high-level class than a material. The only thing that this class should have and know about, is a simple set of properties that allow a designated Factory class to automatically create a material with several techniques, passes and texture units, because that's nothing that a content creator should worry about.

User settings are not even the only reason for this. Even if your game doesn't have configuration options at all, it can still be necessary to create several techniques that do the same thing with minor differences - for example for using a simpler version of the shaders when rendering a top-down ingame minimap. Unless that minimap is fully dynamic, you wouldn't want specular lighting, etc, etc.

What now?

I sat down for quite a while and thought about ways to make this process easier, both for content creators and shader developers. To be able to solve the problems that were pointed out, I figured I'd need a utility library that acts as a layer on top of Ogre's material system, with at least the following features:
- The ability to create even very complex shaders (such as the Ogre::Terrain shader, which has an arbitrary number of layer calculations) outside of the application itself, either through a scripting language or by extending regular shader files with a set of macros (such as a foreach macro).
- An abstracted interface (both C++-interface and serialization interface, i.e. material scripts) for content creators, in order to automate the unintuitive and repetitive process of creating materials.
- This interface should not be referring to specific shaders with a deterministic source, but instead to a "base shader", and the source/behaviour of this shader can be altered by per-material properties as well as user settings.
- Permutation management for base shaders, automatically compiling new/altered versions of the shader as needed and sharing the same shader between several materials when possible.
- A reliable way of setting auto constants and uniforms outside of the application itself, either through a scripting language or by using macros parsed by the shader factory.
- Being able to bind abstract material properties to uniforms in the shader.
- Automate the conversion between shader languages, or provide a meta-language on top of GLSL/HLSL/CG. This should be optional, because some people might still prefer writing only in one language.

Of course we have RTShaderSystem, but it doesn't even fulfill the first requirement - if you want to add custom shaders to it, you will have to code them in C++.

So, in the past weeks, I've worked on a library that covers all this and much more:



The result


I believe that I've reached a point where it matured enough that it can be useful for others. Here are the current features:

- High-level layer on top of OGRE's material system. It allows you to generate multiple techniques for all your materials from a set of high-level per-material properties.

- Several available Macros in shader source files. Just a few examples of the possibilities: binding OGRE auto constants, binding uniforms to material properties, foreach loops (repeat shader source a given number of times), retrieving per-material properties in an #if condition, automatic packing for vertex to fragment passthroughs. These macros allow you to generate even very complex shaders (for example the Ogre::Terrain shader) without assembling them in C++ code.

- Integrated preprocessor (no, I didn't reinvent the wheel, I used boost::wave which turned out to be an excellent choice) that allows me to blend out macros that shouldn't be in use because e.g. the shader permutation doesn't need this specific feature.

- User settings integration. They can be set by a C++ interface and retrieved through a macro in shader files.

- Automatic handling of shader permutations, i.e. shaders are shared between materials in a smart way.

- An optional "meta-language" (well, actually it's just a small header with some conditional defines) that you may use to compile the same shader source for different target languages. If you don't like it, you can still code in GLSL / CG etc separately. You can also switch between the languages at runtime.

- On-demand material and shader creation. It uses Ogre's material listener to compile the shaders as soon as they are needed for rendering, and not earlier.

- Shader changes are fully dynamic and real-time. Changing a user setting will recompile all shaders affected by this setting when they are next needed.

- Serialization system that extends Ogre's material script system, it uses Ogre's script parser, but also adds some additional properties that are not available in Ogre's material system.

- A concept called "Configuration" allowing you to create a different set of your shaders, doing the same thing except for some minor differences: the properties that are overridden by the active configuration. Possible uses for this are using simpler shaders (no shadows, no fog etc) when rendering for example realtime reflections or a minimap. You can easily switch between configurations by changing the active Ogre material scheme (for example on a viewport level).

- Fixed function support. You can globally enable or disable shaders at any time, and for texture units you can specify if they're only needed for the shader-based path (e.g. normal maps) or if they should also be created in the fixed function path.

The current source can be found here: https://github.com/scrawl/shiny

The doxygen-generated documentation along with a hand-written manual can be found here: http://scrawl.bplaced.net/sh_doxy/

I might add some more in-depth usage examples at a later point. For now, taking a look here should definitely get you started.

Future work

- Geometry shader support (shouldn't be hard to add, I never used them though)

- More documentation.

- Add samples, or a demo.

- Material editor, maybe?

- Loading time optimizations (for example caching the preprocessed files - some early profiling tests have shown that preprocessing sometimes takes longer than compiling the actual shaders) DONE

- Saving generated shaders / materials as regular .material / .cg / .glsl files



Evaluation & showcase

Okay, you got me, this is also a showcase thread so I need screenshots :D

Image

"Meh, this looks just like Ogre's standard terrain shader / material. What's special about it?"

Yes, this shader has the same features as Ogre's standard terrain shader (TerrainMaterialGeneratorA). But I have rewritten it to use shiny, and I'm quite happy with how it turned out. In short, it's now more efficient, portable, flexible, and maintainable:

- The shader is an external file and can be changed without recompiling the application.
- Efficiency. the standard TerrainMaterialGeneratorA implementation takes more than 2000 lines of c++ code. My implementation takes only 270 lines of c++ code coupled with a 370 lines shader file. Oops.. that's 300% smaller :D Okay, I cheated a bit because it doesn't support composite or normal maps. However, it would still be significantly smaller. Oh, besides it supports multiple lights while TerrainMaterialGeneratorA doesn't.
- The shader compiles in both CG and GLSL, depending on the target platform or user preference. TerrainMaterialGeneratorA only supports CG.
- Generating additional techniques with smaller changes works with ease. As you can see on the screenshot, the terrain on the minimap does not have shadows or directional lighting. The only thing required to achieve that is registering a Configuration as follows and then changing the viewport material scheme to minimap:
Code: Select all
configuration minimap
{
    fog false
    mrt_output false
    lighting false
    shadows false
}


Here you can find the source for the terrain shader & material.

Here's a screenshot of a more advanced shader, proving that writing in a meta-language does not really limit you in any way as opposed to writing in GLSL/CG/...

Image
Last edited by scrawl on Wed Oct 29, 2014 1:52 am, edited 2 times in total.

For this message the author scrawl has received 18 kudos
User avatar
scrawl
OGRE Expert User
OGRE Expert User
 
Posts: 989
Kudos: 185
Joined: 01 Jan 2011
Location: Germany

Re: shiny - a shader and material management library for OGR

Postby bstone » Tue Jul 24, 2012 9:09 pm

I feel some force unleashed. Awesome job!
bstone
OGRE Expert User
OGRE Expert User
 
Posts: 1920
Kudos: 201
Joined: 19 Feb 2012
Location: Russia

Re: shiny - a shader and material management library for OGR

Postby razi » Tue Jul 24, 2012 9:11 pm

Nice, I completely understand the need for such thing. Your shader file, though Im sure making sense, looks pretty chaotic on first look imho, but thats very hard to avoid. I think UE3-like material editor is a need, if generation of many materials is necessary.
Last edited by razi on Wed Jul 25, 2012 9:44 am, edited 1 time in total.
User avatar
razi
Greenskin
 
Posts: 130
Kudos: 17
Joined: 14 Oct 2008
Location: Slovakia

Re: shiny - a shader and material management library for OGR

Postby PhilipLB » Tue Jul 24, 2012 9:15 pm

Wow!

(Why LGPL and not MIT like Ogre itself?)

(Uh, and is there a possibility to get rid of the boost dependency for people who use Ogre without it?)
Google Summer of Code 2012 Student
Topic: "Volume Rendering with LOD aimed at terrain"
Project links: Project thread, WIKI page, Code fork for the project
Mentor: Mattan Furst


Volume GFX, accepting donations.
PhilipLB
Google Summer of Code Student
Google Summer of Code Student
 
Posts: 533
Kudos: 104
Joined: 04 Jun 2009
Location: Berlin

Re: shiny - a shader and material management library for OGR

Postby scrawl » Tue Jul 24, 2012 9:41 pm

PhilipLB wrote:(Why LGPL and not MIT like Ogre itself?)


I'm not a license specialist so I didn't really think about it much, I can consider a different license if someone convinces me :)

(Uh, and is there a possibility to get rid of the boost dependency for people who use Ogre without it?)

You can use Ogre without boost? I wasn't even aware of that...

The biggest part would be replacing the preprocessor, and boost::wave was the only decent one I found.
User avatar
scrawl
OGRE Expert User
OGRE Expert User
 
Posts: 989
Kudos: 185
Joined: 01 Jan 2011
Location: Germany

Re: shiny - a shader and material management library for OGR

Postby BTolputt » Wed Jul 25, 2012 12:04 am

What is your intention on making the library open-source? Is it so others can use it whilst still crediting you for having written it (what MIT gives you) or is it to force people to provide the code and allow users to swap in their own implementations of the library in a delivered product (what LGPL gives you).

From a purely practical perspective, I'd prefer MIT. It's the license OGRE uses, there is no legal fuzziness based in license advocacy groups (GPL/LGPL), and it allows me to statically link the library into my executable (like OGRE). On a more personal note, being able to use the library in GameKit (the game prototyping project started by [url="http://bulletphysics.org/wordpress/"]Erwin Coumans[/url]) would be fantastic - and it only accepts contributions that are non-copyleft.

For what it's worth, that's an awesome addition to the OpenMW project you've made there. :)
BTolputt
Greenskin
 
Posts: 121
Kudos: 2
Joined: 18 Feb 2010

Re: shiny - a shader and material management library for OGR

Postby scrawl » Wed Jul 25, 2012 12:55 am

Okay, you convinced me. I've changed to MIT :wink:

For this message the author scrawl has received 3 kudos
User avatar
scrawl
OGRE Expert User
OGRE Expert User
 
Posts: 989
Kudos: 185
Joined: 01 Jan 2011
Location: Germany

Re: shiny - a shader and material management library for OGR

Postby TheSHEEEP » Wed Jul 25, 2012 8:41 am

Awesome!

The only problem I have with this is that the shader code example is barely readable.
This is mainly because the incredible amount of preprocessor (I guess?) commands that historically start at the left side of everything. If they would start like any normal if, the code would be much, much easier to read.
And since this is shader code, there is no reason to keep up with that awful traditional C/C++ preprocessor style ;)
Seriously, I do it like suggested in AS3, and I use preprocessor commands pretty often, there. And all of my code is very nice and readable :)

But I really like this. Smells like plugin, if you ask me ;)

I have a question (and no time to look through the sources right now):
How is this actually done? Do you parse the *.shader file and then generate an HLHSL/GLSL/CG file from it and compile and use that one?
Maybe I also missed this in your post :)
My site! - Have a look :)
Also on Twitter - extra fluffy
TheSHEEEP
OGRE Team Member
OGRE Team Member
 
Posts: 952
Kudos: 60
Joined: 02 Jun 2008
Location: Berlin

Re: shiny - a shader and material management library for OGR

Postby areay » Wed Jul 25, 2012 9:57 am

Wow Scrawl. This is really impressive.

As someone who is stuck in 'shader hell' at the moment I'll give your project a whirl over the next week or two. Thanks heaps for contributing it to us!
User avatar
areay
Orc Shaman
 
Posts: 726
Kudos: 58
Joined: 05 May 2010
Location: Auckland, NZ


Re: shiny - a shader and material management library for OGR

Postby Klaim » Wed Jul 25, 2012 2:10 pm

This look very useful, congrats for doing this.


Like others I have a hard time reading the shader because of the macro style, but if I understand correctly, you could have used any scripting language to set this up, right?
User avatar
Klaim
Old One
 
Posts: 2443
Kudos: 57
Joined: 11 Sep 2005
Location: Lille, France

Re: shiny - a shader and material management library for OGR

Postby scrawl » Wed Jul 25, 2012 5:11 pm

Yeah, it can be difficult to read in the beginning. It's mainly because of 3 reasons:
- the lots of #if / #ifdefs. hard to avoid if you want flexibility.
- macros. again, they give you lots of flexibility, but for simple shaders you don't have to use any of them, except for auto constant binding.
- the meta-language. personally, I really like it but I understand it's hard to read if you never worked with it - but you are free to code GLSL/CG etc as well for learning purposes (or if you don't care about portability, or you're a masochist :) )

I just realized another great possibility with this: Semi-automatic material LOD. :D Will definitely consider this in the next version, because a similiar mechanism will be required anyway in order to support terrain composite maps. Basically, it could work as simple as telling the factory how many LOD techniques to generate for a specific material (or for all materials), and which shader feature (=global setting) to disable at which LOD level.
User avatar
scrawl
OGRE Expert User
OGRE Expert User
 
Posts: 989
Kudos: 185
Joined: 01 Jan 2011
Location: Germany

Re: shiny - a shader and material management library for OGR

Postby scrawl » Wed Jul 25, 2012 5:15 pm

TheSHEEEP wrote:I have a question (and no time to look through the sources right now):
How is this actually done? Do you parse the *.shader file and then generate an HLHSL/GLSL/CG file from it and compile and use that one?

Basically, yes.
User avatar
scrawl
OGRE Expert User
OGRE Expert User
 
Posts: 989
Kudos: 185
Joined: 01 Jan 2011
Location: Germany

Re: shiny - a shader and material management library for OGR

Postby Klaim » Wed Jul 25, 2012 10:20 pm

I do not understand what forbid you to write macros in a syntax that would be far easier to read?
For example, there is a proposition for the next C++ standard to add "static if" that would be a language construct to let the compiler check a constant at compile time and then use some code or not (or use the else part). It is proposed by D language designers and implementers and it looks a very good way to make a better #ifdef (that understand types, for example).

So, what forbid you to just change the syntax in a way that would be more readable?
User avatar
Klaim
Old One
 
Posts: 2443
Kudos: 57
Joined: 11 Sep 2005
Location: Lille, France

Re: shiny - a shader and material management library for OGR

Postby scrawl » Thu Jul 26, 2012 1:10 am

So you're suggesting to use this style

Code: Select all
static if (condition)
{
    // some code
}
else
{
    // other code
}


instead of

Code: Select all
#if condition

  // some code

#else
 
  // other code

#endif


Personally I would prefer the second (current style).
First, it's shorter (Okay, not a big argument but it's an argument if you use them extensively). Second, I can distinguish it easier from regular if statements that are checked at runtime. I consider this important, because regular if statements are quite special in shaders. Below SM3, full dynamic branching is not even supported and even above that, there are still limitations with reading textures in a branch.

Also, I'm not indenting #if / #ifdefs for a reason - each of these checks can possibly spawn new permutations, and you have to be careful about when to use them. Thats why I like to keep them separate from the generated source by not indenting them. But you are free to do otherwise.

If you still think that static ifs are better, feel free to add them yourself. I guess the best way to add them would be simply replacing them with #if statements during the parsing step and passing that on to the preprocessor. That should be just a few lines of code. As pointed out I personally wouldn't use them, but I would accept your changes if you make a nice patch.
User avatar
scrawl
OGRE Expert User
OGRE Expert User
 
Posts: 989
Kudos: 185
Joined: 01 Jan 2011
Location: Germany

Re: shiny - a shader and material management library for OGR

Postby Klaim » Thu Jul 26, 2012 10:31 am

No it was an example, I was suggesting making the code clearer, whatever the way.

Nevermind, it can be enhanced later.
User avatar
Klaim
Old One
 
Posts: 2443
Kudos: 57
Joined: 11 Sep 2005
Location: Lille, France

Re: shiny - a shader and material management library for OGR

Postby PhilipLB » Fri Jul 27, 2012 11:44 am

Maybe this is also interesting? http://prideout.net/blog/?p=1
Google Summer of Code 2012 Student
Topic: "Volume Rendering with LOD aimed at terrain"
Project links: Project thread, WIKI page, Code fork for the project
Mentor: Mattan Furst


Volume GFX, accepting donations.
PhilipLB
Google Summer of Code Student
Google Summer of Code Student
 
Posts: 533
Kudos: 104
Joined: 04 Jun 2009
Location: Berlin

Re: shiny - a shader and material management library for OGR

Postby scrawl » Fri Jul 27, 2012 3:47 pm

Yeah, I came across that article as well, was a nice read, although it only shows the basic stuff. I even considered doing it with lua like this, but in the end, I decided against it because it was overkill for my purposes.

If there's a request, I could separate the shader parser from the rest of the code and make it a user-exchangeable module - that would allow adding such a lua based system easily :)
User avatar
scrawl
OGRE Expert User
OGRE Expert User
 
Posts: 989
Kudos: 185
Joined: 01 Jan 2011
Location: Germany

Re: shiny - a shader and material management library for OGR

Postby madmarx » Fri Jul 27, 2012 5:03 pm

1/ Very good, i am sure improvements are possible though
2/ When I faced that same problem than you did concerning combinatory problem, i used another way : I generated all possible shader directly from C++ on the disk. The artist then could use it directly without even the need to launch my app. This simply generated hundreds of shaders file on the disk. Then could be reused. Easy, he?
3/ Concerning the macro language, i used to be a huge macro writer (I provided macro to boost), but today, i think it is much cleaner to use boost.spirit or boost.expressive. I found boost.expressive easier to maintain on little languages (cause the bindings with class members relies on their name and not on their index in the boost.fusion structure).
One problem with the macro language is simply the abscence of hiearchy that the { } and tabulation provide.
You could use something else (idk, for example : SHADER_if( condition ){ } etc..).

4/ I completly agree on the aspect of "higher level material" which is driven only by some properties. Usually, this comes also with RTT operation integrated.

Great work!

Pierre
Tutorials + Ogre searchable API + more for Ogre1.7 : http://sourceforge.net/projects/so3dtools/
Corresponding thread : viewtopic.php?f=1&t=57693&start=0
User avatar
madmarx
OGRE Expert User
OGRE Expert User
 
Posts: 1647
Kudos: 43
Joined: 21 Jan 2008

Re: shiny - a shader and material management library for OGR

Postby scrawl » Sat Jul 28, 2012 8:49 pm

I just added material LOD support, so you can get as many auto-generated LOD techniques as you want with almost zero effort :D You can read how it works here

For this message the author scrawl has received kudos
User avatar
scrawl
OGRE Expert User
OGRE Expert User
 
Posts: 989
Kudos: 185
Joined: 01 Jan 2011
Location: Germany

Re: shiny - a shader and material management library for OGR

Postby Flayer » Sat Jul 28, 2012 11:02 pm

Hello everyone =)

And nice work scrawl!

I have a few things to point out (if I haven't missed them elsewhere).

First, the "Getting started code" is a WIP, right? Because those lines of code aren't enough to make the system work, atleast not for me.
I have to choose a language (factory->setCurrentLanguage(sh::Language::Language_CG)) and make a call to factory->loadAllFiles() (is that right?).

Secondly, I think the shader code in "Defining materials and shaders" are missing a few characters, a line in the fragment program.
Shouldn't it be:
Code: Select all
shOutputColor(0) = shSample(diffuse, UV);

instead of:
Code: Select all
shOutputColor = shSample(diffuse, UV);

?
I get compile errors if I use the latter from the doxy page.

Somehow I still do not manage to get everything to work correctly.
When everything seems to load "fine", the material and shader code which you get from the doxy page will make my mesh completely black.
Is there something else that I have missed here?
If I "extract" the generated shader code and put it in new material file, Ogre's standard file, and use the vertex and fragment program the standard way the models texture appears fine.

For now I'm just stuck with this and can't find my way around it, so if you have a little time to help I would really appreciate it =)

It does work to set a pre-defined colour on the mesh via the shader code though, regarding the same line as I mentioned above.
If I set it to be an orange colour, the colour is applied to the mesh:
Code: Select all
shOutputColour(0) = float4(1.0, 0.8, 0.0, 0.0);


Something that might be worth noting is that I used boost 1.48, wave, when I generated a Code::Blocks project with CMake.
This means that I don't use the preprocessor stuff, right?


Hmm, how stupid I am. When I read my post again I remembered that I had some problems with the static library when linking, so I just incorporated the whole source into my other Code::Blocks project.
I am now compiling the Main/* and Platform/Ogre/* files when my project compiles, does this mean I am now using the preprocessor stuff, but with boost 1.48?

Anyways, with that said I only have one thing left to say before I bore you: keep up the great work!
Last edited by Flayer on Sat Jul 28, 2012 11:17 pm, edited 1 time in total.
Flayer
Gnoblar
 
Posts: 7
Kudos: 0
Joined: 21 May 2012

Re: shiny - a shader and material management library for OGR

Postby scrawl » Sat Jul 28, 2012 11:12 pm

First, the "Getting started code" is a WIP, right? Because those lines of code aren't enough to make the system work

Hm, I guess you worked with an older version of the documentation. It's already there since a while.

Secondly, I think the shader code in "Defining materials and shaders" are missing a few characters, a line in the fragment program.

Indeed, thanks for pointing out.

Is there something else that I have missed here?

No, it should work like this. Please post ogre logs and your materials.

does this mean I am now using the preprocessor stuff, but with boost 1.48?

Unless you get linking errors with your project, you don't have to worry about it. (Yes, you are using it)
User avatar
scrawl
OGRE Expert User
OGRE Expert User
 
Posts: 989
Kudos: 185
Joined: 01 Jan 2011
Location: Germany

Re: shiny - a shader and material management library for OGR

Postby scrawl » Sat Jul 28, 2012 11:19 pm

Oops, just saw there was another thing wrong with the docs (and I think that is why your material is black). The name of the texture unit in the shader ( shSampler2D(diffuse) -> "diffuse" ) has to be the same as the name of the texture unit in the material ( texture_unit diffuseMap -> "diffuseMap" ). This is needed because only texture units that are used by the shader are actually created (For example, if you have a base material with an optional asset like a normal map, that texture unit could be skipped in some cases)

Long story short, change the line to "shSampler2D(diffuseMap)" to get it to work. I should mention this as comment in the docs :D
User avatar
scrawl
OGRE Expert User
OGRE Expert User
 
Posts: 989
Kudos: 185
Joined: 01 Jan 2011
Location: Germany

Re: shiny - a shader and material management library for OGR

Postby Flayer » Sat Jul 28, 2012 11:34 pm

scrawl wrote:
First, the "Getting started code" is a WIP, right? Because those lines of code aren't enough to make the system work

Hm, I guess you worked with an older version of the documentation. It's already there since a while.

Are you sure? If I only have these lines in my application, all meshes are grey:
Code: Select all
...
sh::Platform *platform = new sh::OgrePlatform("General", "E:/Dropbox/Warlock/minimal_ogre_shiny/media/shiny");
m_shinyFactory = std::unique_ptr<sh::Factory>(new sh::Factory(platform));
...

But if I add these lines after the previous lines:
Code: Select all
m_shinyFactory->setCurrentLanguage(sh::Language::Language_CG);
m_shinyFactory->loadAllFiles();

One of the meshes gets black, the one I'm trying to use shiny on (the other one is white because Ogre can't find its material)

scrawl wrote:
Is there something else that I have missed here?

No, it should work like this. Please post ogre logs and your materials.

Here are the material file:
Code: Select all
material my_first_material
{
   diffuse 1.0 1.0 1.0 1.0
   specular 0.4 0.4 0.4 32
   ambient 1.0 1.0 1.0
   emissive 0.0 0.0 0.0
   diffuseMap black.png
   
   pass
   {
      diffuse $diffuse
      specular $specular
      ambient $ambient
      emissive $emissive
      
      vertex_program char_shader_vertex
      fragment_program char_shader_fragment
      
      texture_unit diffuseMap
      {
         texture $diffuseMap
         create_in_ffp true // use this texture unit for fixed function pipeline
      }
   }
}


material char_android_16_blinn1
{
   parent my_first_material
   diffuseMap char_android_16.png
}


And the log
Code: Select all
00:28:54: Creating resource group General
00:28:54: Creating resource group Internal
00:28:54: Creating resource group Autodetect
00:28:54: SceneManagerFactory for type 'DefaultSceneManager' registered.
00:28:54: Registering ResourceManager for type Material
00:28:54: Registering ResourceManager for type Mesh
00:28:54: Registering ResourceManager for type Skeleton
00:28:54: MovableObjectFactory for type 'ParticleSystem' registered.
00:28:54: OverlayElementFactory for type Panel registered.
00:28:54: OverlayElementFactory for type BorderPanel registered.
00:28:54: OverlayElementFactory for type TextArea registered.
00:28:54: Registering ResourceManager for type Font
00:28:54: ArchiveFactory for archive type FileSystem registered.
00:28:54: ArchiveFactory for archive type Zip registered.
00:28:54: ArchiveFactory for archive type EmbeddedZip registered.
00:28:54: DDS codec registering
00:28:54: FreeImage version: 3.15.3
00:28:54: This program uses FreeImage, a free, open source image library supporting all common bitmap formats. See http://freeimage.sourceforge.net for details
00:28:54: Supported formats: bmp,ico,jpg,jif,jpeg,jpe,jng,koa,iff,lbm,mng,pbm,pbm,pcd,pcx,pgm,pgm,png,ppm,ppm,ras,tga,targa,tif,tiff,wap,wbmp,wbm,psd,cut,xbm,xpm,gif,hdr,g3,sgi,exr,j2k,j2c,jp2,pfm,pct,pict,pic,3fr,arw,bay,bmq,cap,cine,cr2,crw,cs1,dc2,dcr,drf,dsc,dng,erf,fff,ia,iiq,k25,kc2,kdc,mdc,mef,mos,mrw,nef,nrw,orf,pef,ptx,pxn,qtk,raf,raw,rdc,rw2,rwl,rwz,sr2,srf,srw,sti
00:28:54: Registering ResourceManager for type HighLevelGpuProgram
00:28:54: Registering ResourceManager for type Compositor
00:28:54: MovableObjectFactory for type 'Entity' registered.
00:28:54: MovableObjectFactory for type 'Light' registered.
00:28:54: MovableObjectFactory for type 'BillboardSet' registered.
00:28:54: MovableObjectFactory for type 'ManualObject' registered.
00:28:54: MovableObjectFactory for type 'BillboardChain' registered.
00:28:54: MovableObjectFactory for type 'RibbonTrail' registered.
00:28:54: Loading library .\Plugin_CgProgramManager
00:28:54: Installing plugin: Cg Program Manager
00:28:54: Plugin successfully installed
00:28:54: Loading library .\RenderSystem_GL
00:28:54: Installing plugin: GL RenderSystem
00:28:54: OpenGL Rendering Subsystem created.
00:28:54: Plugin successfully installed
00:28:54: *-*-* OGRE Initialising
00:28:54: *-*-* Version 1.8.0 (Byatis)
00:28:54: CPU Identifier & Features
00:28:54: -------------------------
00:28:54:  *   CPU ID: GenuineIntel: Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz
00:28:54:  *      SSE: yes
00:28:54:  *     SSE2: yes
00:28:54:  *     SSE3: yes
00:28:54:  *      MMX: yes
00:28:54:  *   MMXEXT: yes
00:28:54:  *    3DNOW: no
00:28:54:  * 3DNOWEXT: no
00:28:54:  *     CMOV: yes
00:28:54:  *      TSC: yes
00:28:54:  *      FPU: yes
00:28:54:  *      PRO: yes
00:28:54:  *       HT: no
00:28:54: -------------------------
00:28:54: *** Starting Win32GL Subsystem ***
00:28:54: Registering ResourceManager for type Texture
00:28:54: GLRenderSystem::_createRenderWindow "MinimalOgre Render Window", 1360x768 windowed  miscParams: FSAA=0 FSAAHint= colourDepth=32 displayFrequency=0 gamma=false vsync=false vsyncInterval=1
00:28:54: Created Win32Window 'MinimalOgre Render Window' : 1376x806, 32bpp
00:28:54: GL_VERSION = 4.2.0
00:28:54: GL_VENDOR = NVIDIA Corporation
00:28:54: GL_RENDERER = GeForce GTX 570/PCIe/SSE2
00:28:54: GL_EXTENSIONS = GL_AMD_multi_draw_indirect GL_ARB_base_instance GL_ARB_blend_func_extended GL_ARB_color_buffer_float GL_ARB_compatibility GL_ARB_compressed_texture_pixel_storage GL_ARB_conservative_depth GL_ARB_copy_buffer GL_ARB_depth_buffer_float GL_ARB_depth_clamp GL_ARB_depth_texture GL_ARB_draw_buffers GL_ARB_draw_buffers_blend GL_ARB_draw_indirect GL_ARB_draw_elements_base_vertex GL_ARB_draw_instanced GL_ARB_ES2_compatibility GL_ARB_explicit_attrib_location GL_ARB_fragment_coord_conventions GL_ARB_fragment_program GL_ARB_fragment_program_shadow GL_ARB_fragment_shader GL_ARB_framebuffer_object GL_ARB_framebuffer_sRGB GL_ARB_geometry_shader4 GL_ARB_get_program_binary GL_ARB_gpu_shader5 GL_ARB_gpu_shader_fp64 GL_ARB_half_float_pixel GL_ARB_half_float_vertex GL_ARB_imaging GL_ARB_instanced_arrays GL_ARB_internalformat_query GL_ARB_map_buffer_alignment GL_ARB_map_buffer_range GL_ARB_multisample GL_ARB_multitexture GL_ARB_occlusion_query GL_ARB_occlusion_query2 GL_ARB_pixel_buffer_object GL_ARB_point_parameters GL_ARB_point_sprite GL_ARB_provoking_vertex GL_ARB_robustness GL_ARB_sample_shading GL_ARB_sampler_objects GL_ARB_seamless_cube_map GL_ARB_separate_shader_objects GL_ARB_shader_atomic_counters GL_ARB_shader_bit_encoding GL_ARB_shader_image_load_store GL_ARB_shader_objects GL_ARB_shader_precision GL_ARB_shader_subroutine GL_ARB_shading_language_100 GL_ARB_shading_language_420pack GL_ARB_shading_language_include GL_ARB_shading_language_packing GL_ARB_shadow GL_ARB_sync GL_ARB_tessellation_shader GL_ARB_texture_border_clamp GL_ARB_texture_buffer_object GL_ARB_texture_buffer_object_rgb32 GL_ARB_texture_compression GL_ARB_texture_compression_bptc GL_ARB_texture_compression_rgtc GL_ARB_texture_cube_map GL_ARB_texture_cube_map_array GL_ARB_texture_env_add GL_ARB_texture_env_combine GL_ARB_texture_env_crossbar GL_ARB_texture_env_dot3 GL_ARB_texture_float GL_ARB_texture_gather GL_ARB_texture_mirrored_repeat GL_ARB_texture_multisample GL_ARB_texture_non_power_of_two GL_ARB_texture_query_lod GL_ARB_texture_rectangle GL_ARB_texture_rg GL_ARB_texture_rgb10_a2ui GL_ARB_texture_storage GL_ARB_texture_swizzle GL_ARB_timer_query GL_ARB_transform_feedback2 GL_ARB_transform_feedback3 GL_ARB_transform_feedback_instanced GL_ARB_transpose_matrix GL_ARB_uniform_buffer_object GL_ARB_vertex_array_bgra GL_ARB_vertex_array_object GL_ARB_vertex_attrib_64bit GL_ARB_vertex_buffer_object GL_ARB_vertex_program GL_ARB_vertex_shader GL_ARB_vertex_type_2_10_10_10_rev GL_ARB_viewport_array GL_ARB_window_pos GL_ATI_draw_buffers GL_ATI_texture_float GL_ATI_texture_mirror_once GL_S3_s3tc GL_EXT_texture_env_add GL_EXT_abgr GL_EXT_bgra GL_EXT_bindable_uniform GL_EXT_blend_color GL_EXT_blend_equation_separate GL_EXT_blend_func_separate GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_compiled_vertex_array GL_EXT_Cg_shader GL_EXT_depth_bounds_test GL_EXT_direct_state_access GL_EXT_draw_buffers2 GL_EXT_draw_instanced GL_EXT_draw_range_elements GL_EXT_fog_coord GL_EXT_framebuffer_blit GL_EXT_framebuffer_multisample GL_EXTX_framebuffer_mixed_formats GL_EXT_framebuffer_object GL_EXT_framebuffer_sRGB GL_EXT_geometry_shader4 GL_EXT_gpu_program_parameters GL_EXT_gpu_shader4 GL_EXT_multi_draw_arrays GL_EXT_packed_depth_stencil GL_EXT_packed_float GL_EXT_packed_pixels GL_EXT_pixel_buffer_object GL_EXT_point_parameters GL_EXT_provoking_vertex GL_EXT_rescale_normal GL_EXT_secondary_color GL_EXT_separate_shader_objects GL_EXT_separate_specular_color GL_EXT_shader_image_load_store GL_EXT_shadow_funcs GL_EXT_stencil_two_side GL_EXT_stencil_wrap GL_EXT_texture3D GL_EXT_texture_array GL_EXT_texture_buffer_object GL_EXT_texture_compression_dxt1 GL_EXT_texture_compression_latc GL_EXT_texture_compression_rgtc GL_EXT_texture_compression_s3tc GL_EXT_texture_cube_map GL_EXT_texture_edge_clamp GL_EXT_texture_env_combine GL_EXT_texture_env_dot3 GL_EXT_texture_filter_anisotropic GL_EXT_texture_format_BGRA8888 GL_EXT_texture_integer GL_EXT_texture_lod GL_EXT_texture_lod_bias GL_EXT_texture_mirror_clamp GL_EXT_texture_object GL_EXT_texture_shared_exponent GL_EXT_texture_sRGB GL_EXT_texture_sRGB_decode GL_EXT_texture_storage GL_EXT_texture_swizzle GL_EXT_texture_type_2_10_10_10_REV GL_EXT_timer_query GL_EXT_transform_feedback2 GL_EXT_vertex_array GL_EXT_vertex_array_bgra GL_EXT_vertex_attrib_64bit GL_EXT_import_sync_object GL_IBM_rasterpos_clip GL_IBM_texture_mirrored_repeat GL_KTX_buffer_region GL_NV_alpha_test GL_NV_blend_minmax GL_NV_blend_square GL_NV_complex_primitives GL_NV_conditional_render GL_NV_copy_depth_to_color GL_NV_copy_image GL_NV_depth_buffer_float GL_NV_depth_clamp GL_NV_explicit_multisample GL_NV_fbo_color_attachments GL_NV_fence GL_NV_float_buffer GL_NV_fog_distance GL_NV_fragdepth GL_NV_fragment_program GL_NV_fragment_program_option GL_NV_fragment_program2 GL_NV_framebuffer_multisample_coverage GL_NV_geometry_shader4 GL_NV_gpu_program4 GL_NV_gpu_program4_1 GL_NV_gpu_program5 GL_NV_gpu_program_fp64 GL_NV_gpu_shader5 GL_NV_half_float GL_NV_light_max_exponent GL_NV_multisample_coverage GL_NV_multisample_filter_hint GL_NV_occlusion_query GL_NV_packed_depth_stencil GL_NV_parameter_buffer_object GL_NV_parameter_buffer_object2 GL_NV_path_rendering GL_NV_pixel_data_range GL_NV_point_sprite GL_NV_primitive_restart GL_NV_register_combiners GL_NV_register_combiners2 GL_NV_shader_atomic_counters GL_NV_shader_atomic_float GL_NV_shader_buffer_load GL_NV_texgen_reflection GL_NV_texture_barrier GL_NV_texture_compression_vtc GL_NV_texture_env_combine4 GL_NV_texture_expand_normal GL_NV_texture_lod_clamp GL_NV_texture_multisample GL_NV_texture_rectangle GL_NV_texture_shader GL_NV_texture_shader2 GL_NV_texture_shader3 GL_NV_transform_feedback GL_NV_transform_feedback2 GL_NV_vertex_array_range GL_NV_vertex_array_range2 GL_NV_vertex_attrib_integer_64bit GL_NV_vertex_buffer_unified_memory GL_NV_vertex_program GL_NV_vertex_program1_1 GL_NV_vertex_program2 GL_NV_vertex_program2_option GL_NV_vertex_program3 GL_NVX_conditional_render GL_NVX_gpu_memory_info GL_OES_depth24 GL_OES_depth32 GL_OES_depth_texture GL_OES_element_index_uint GL_OES_fbo_render_mipmap GL_OES_get_program_binary GL_OES_mapbuffer GL_OES_packed_depth_stencil GL_OES_rgb8_rgba8 GL_OES_standard_derivatives GL_OES_texture_3D GL_OES_texture_float GL_OES_texture_float_linear GL_OES_texture_half_float GL_OES_texture_half_float_linear GL_OES_texture_npot GL_OES_vertex_array_object GL_OES_vertex_half_float GL_SGIS_generate_mipmap GL_SGIS_texture_lod GL_SGIX_depth_texture GL_SGIX_shadow GL_SUN_slice_accum GL_WIN_swap_hint WGL_EXT_swap_control
00:28:54: Supported WGL extensions: WGL_ARB_buffer_region WGL_ARB_create_context WGL_ARB_create_context_profile WGL_ARB_create_context_robustness WGL_ARB_extensions_string WGL_ARB_make_current_read WGL_ARB_multisample WGL_ARB_pbuffer WGL_ARB_pixel_format WGL_ARB_pixel_format_float WGL_ARB_render_texture WGL_ATI_pixel_format_float WGL_EXT_create_context_es2_profile WGL_EXT_extensions_string WGL_EXT_framebuffer_sRGB WGL_EXT_pixel_format_packed_float WGL_EXT_swap_control WGL_EXT_swap_control_tear WGL_NVX_DX_interop WGL_NV_DX_interop WGL_NV_DX_interop2 WGL_NV_float_buffer WGL_NV_multisample_coverage WGL_NV_render_depth_texture WGL_NV_render_texture_rectangle
00:28:54: ***************************
00:28:54: *** GL Renderer Started ***
00:28:54: ***************************
00:28:54: Registering ResourceManager for type GpuProgram
00:28:54: GLSL support detected
00:28:54: GL: Using GL_EXT_framebuffer_object for rendering to textures (best)
00:28:54: FBO PF_UNKNOWN depth/stencil support: D16S0 D24S0 D32S0 Packed-D24S8
00:28:54: FBO PF_L8 depth/stencil support: D0S0 D16S0 D24S0 D32S0 Packed-D24S8
00:28:54: FBO PF_A8 depth/stencil support: D0S0 D16S0 D24S0 D32S0 Packed-D24S8
00:28:54: FBO PF_A4L4 depth/stencil support: D0S0 D16S0 D24S0 D32S0 Packed-D24S8
00:28:54: FBO PF_BYTE_LA depth/stencil support: D0S0 D16S0 D24S0 D32S0 Packed-D24S8
00:28:54: FBO PF_R5G6B5 depth/stencil support: D0S0 D16S0 D24S0 D32S0 Packed-D24S8
00:28:54: FBO PF_B5G6R5 depth/stencil support: D0S0 D16S0 D24S0 D32S0 Packed-D24S8
00:28:54: FBO PF_A4R4G4B4 depth/stencil support: D0S0 D16S0 D24S0 D32S0 Packed-D24S8
00:28:54: FBO PF_A1R5G5B5 depth/stencil support: D0S0 D16S0 D24S0 D32S0 Packed-D24S8
00:28:54: FBO PF_R8G8B8 depth/stencil support: D0S0 D16S0 D24S0 D32S0 Packed-D24S8
00:28:54: FBO PF_B8G8R8 depth/stencil support: D0S0 D16S0 D24S0 D32S0 Packed-D24S8
00:28:54: FBO PF_A8R8G8B8 depth/stencil support: D0S0 D16S0 D24S0 D32S0 Packed-D24S8
00:28:54: FBO PF_B8G8R8A8 depth/stencil support: D0S0 D16S0 D24S0 D32S0 Packed-D24S8
00:28:54: FBO PF_A2R10G10B10 depth/stencil support: D0S0 D16S0 D24S0 D32S0 Packed-D24S8
00:28:54: FBO PF_A2B10G10R10 depth/stencil support: D0S0 D16S0 D24S0 D32S0 Packed-D24S8
00:28:54: FBO PF_FLOAT16_RGB depth/stencil support: D0S0 D16S0 D24S0 D32S0 Packed-D24S8
00:28:54: FBO PF_FLOAT16_RGBA depth/stencil support: D0S0 D16S0 D24S0 D32S0 Packed-D24S8
00:28:54: FBO PF_FLOAT32_RGB depth/stencil support: D0S0 D16S0 D24S0 D32S0 Packed-D24S8
00:28:54: FBO PF_FLOAT32_RGBA depth/stencil support: D0S0 D16S0 D24S0 D32S0 Packed-D24S8
00:28:54: FBO PF_X8R8G8B8 depth/stencil support: D0S0 D16S0 D24S0 D32S0 Packed-D24S8
00:28:54: FBO PF_X8B8G8R8 depth/stencil support: D0S0 D16S0 D24S0 D32S0 Packed-D24S8
00:28:54: FBO PF_SHORT_RGBA depth/stencil support: D0S0 D16S0 D24S0 D32S0 Packed-D24S8
00:28:54: FBO PF_R3G3B2 depth/stencil support: D0S0 D16S0 D24S0 D32S0 Packed-D24S8
00:28:54: FBO PF_FLOAT16_R depth/stencil support: D0S0 D16S0 D24S0 D32S0 Packed-D24S8
00:28:54: FBO PF_FLOAT32_R depth/stencil support: D0S0 D16S0 D24S0 D32S0 Packed-D24S8
00:28:54: FBO PF_FLOAT16_GR depth/stencil support: D0S0 D16S0 D24S0 D32S0 Packed-D24S8
00:28:54: FBO PF_FLOAT32_GR depth/stencil support: D0S0 D16S0 D24S0 D32S0 Packed-D24S8
00:28:54: FBO PF_SHORT_RGB depth/stencil support: D0S0 D16S0 D24S0 D32S0 Packed-D24S8
00:28:54: [GL] : Valid FBO targets PF_UNKNOWN PF_L8 PF_A8 PF_A4L4 PF_BYTE_LA PF_R5G6B5 PF_B5G6R5 PF_A4R4G4B4 PF_A1R5G5B5 PF_R8G8B8 PF_B8G8R8 PF_A8R8G8B8 PF_B8G8R8A8 PF_A2R10G10B10 PF_A2B10G10R10 PF_FLOAT16_RGB PF_FLOAT16_RGBA PF_FLOAT32_RGB PF_FLOAT32_RGBA PF_X8R8G8B8 PF_X8B8G8R8 PF_SHORT_RGBA PF_R3G3B2 PF_FLOAT16_R PF_FLOAT32_R PF_FLOAT16_GR PF_FLOAT32_GR PF_SHORT_RGB
00:28:54: RenderSystem capabilities
00:28:54: -------------------------
00:28:54: RenderSystem Name: OpenGL Rendering Subsystem
00:28:54: GPU Vendor: nvidia
00:28:54: Device Name: GeForce GTX 570/PCIe/SSE2
00:28:54: Driver Version: 4.2.0.0
00:28:54:  * Fixed function pipeline: yes
00:28:54:  * Hardware generation of mipmaps: yes
00:28:54:  * Texture blending: yes
00:28:54:  * Anisotropic texture filtering: yes
00:28:54:  * Dot product texture operation: yes
00:28:54:  * Cube mapping: yes
00:28:54:  * Hardware stencil buffer: yes
00:28:54:    - Stencil depth: 8
00:28:54:    - Two sided stencil support: yes
00:28:54:    - Wrap stencil values: yes
00:28:54:  * Hardware vertex / index buffers: yes
00:28:54:  * Vertex programs: yes
00:28:54:  * Number of floating-point constants for vertex programs: 1024
00:28:54:  * Number of integer constants for vertex programs: 0
00:28:54:  * Number of boolean constants for vertex programs: 0
00:28:54:  * Fragment programs: yes
00:28:54:  * Number of floating-point constants for fragment programs: 512
00:28:54:  * Number of integer constants for fragment programs: 0
00:28:54:  * Number of boolean constants for fragment programs: 0
00:28:54:  * Geometry programs: yes
00:28:54:  * Number of floating-point constants for geometry programs: 2048
00:28:54:  * Number of integer constants for geometry programs: 0
00:28:54:  * Number of boolean constants for geometry programs: 0
00:28:54:  * Supported Shader Profiles: arbfp1 arbvp1 fp20 fp30 fp40 glsl gp4fp gp4gp gp4vp gpu_fp gpu_gp gpu_vp nvgp4 vp30 vp40
00:28:54:  * Texture Compression: yes
00:28:54:    - DXT: yes
00:28:54:    - VTC: yes
00:28:54:    - PVRTC: no
00:28:54:  * Scissor Rectangle: yes
00:28:54:  * Hardware Occlusion Query: yes
00:28:54:  * User clip planes: yes
00:28:54:  * VET_UBYTE4 vertex element type: yes
00:28:54:  * Infinite far plane projection: yes
00:28:54:  * Hardware render-to-texture: yes
00:28:54:  * Floating point textures: yes
00:28:54:  * Non-power-of-two textures: yes
00:28:54:  * Volume textures: yes
00:28:54:  * Multiple Render Targets: 8
00:28:54:    - With different bit depths: yes
00:28:54:  * Point Sprites: yes
00:28:54:  * Extended point parameters: yes
00:28:54:  * Max Point Size: 63.375
00:28:54:  * Vertex texture fetch: yes
00:28:54:  * Number of world matrices: 0
00:28:54:  * Number of texture units: 32
00:28:54:  * Stencil buffer depth: 8
00:28:54:  * Number of vertex blend matrices: 0
00:28:54:    - Max vertex textures: 32
00:28:54:    - Vertex textures shared: yes
00:28:54:  * Render to Vertex Buffer : yes
00:28:54:  * GL 1.5 without VBO workaround: no
00:28:54:  * Frame Buffer objects: yes
00:28:54:  * Frame Buffer objects (ARB extension): no
00:28:54:  * Frame Buffer objects (ATI extension): no
00:28:54:  * PBuffer support: yes
00:28:54:  * GL 1.5 without HW-occlusion workaround: no
00:28:54:  * Separate shader objects: no
00:28:54: DefaultWorkQueue('Root') initialising on thread 0x9365d0.
00:28:54: DefaultWorkQueue('Root')::WorkerFunc - thread 0x93aea8 starting.
00:28:54: Particle Renderer Type 'billboard' registered
00:28:54: DefaultWorkQueue('Root')::WorkerFunc - thread 0x93aed8 starting.
00:28:54: DefaultWorkQueue('Root')::WorkerFunc - thread 0x93ae78 starting.
00:28:54: DefaultWorkQueue('Root')::WorkerFunc - thread 0x93af08 starting.
00:28:54: DefaultWorkQueue('Root')::WorkerFunc - thread 0x93af38 starting.
00:28:54: DefaultWorkQueue('Root')::WorkerFunc - thread 0x93af68 starting.
00:28:54: DefaultWorkQueue('Root')::WorkerFunc - thread 0x93af98 starting.
00:28:54: DefaultWorkQueue('Root')::WorkerFunc - thread 0x93afc8 starting.
00:28:54: Added resource location 'E:/Dropbox/Warlock/minimal_ogre_shiny/media/shiny' of type 'FileSystem' to resource group 'General'
00:28:54: Added resource location './media/SdkTrays.zip' of type 'Zip' to resource group 'General'
00:28:54: Parsing scripts for resource group Autodetect
00:28:54: Finished parsing scripts for resource group Autodetect
00:28:54: Creating resources for group Autodetect
00:28:54: All done
00:28:54: Parsing scripts for resource group General
00:28:54: Parsing script SdkTrays.material
00:28:54: Parsing script SdkTrays.fontdef
00:28:54: Parsing script SdkTrays.overlay
00:28:54: Bad element attribute line: '# you can offset the image to change the cursor "hotspot"' for element SdkTrays/Cursor in overlay
00:28:54: Texture: sdk_cursor.png: Loading 1 faces(PF_A8R8G8B8,32x32x1) with 5 generated mipmaps from Image. Internal format is PF_A8R8G8B8,32x32x1.
00:28:54: Texture: sdk_tray.png: Loading 1 faces(PF_A8R8G8B8,64x64x1) with 6 generated mipmaps from Image. Internal format is PF_A8R8G8B8,64x64x1.
00:28:54: Texture: sdk_button_up.png: Loading 1 faces(PF_A8R8G8B8,128x32x1) with 7 generated mipmaps from Image. Internal format is PF_A8R8G8B8,128x32x1.
00:28:54: Texture: sdk_text_box.png: Loading 1 faces(PF_A8R8G8B8,32x32x1) with 5 generated mipmaps from Image. Internal format is PF_A8R8G8B8,32x32x1.
00:28:54: Texture: sdk_mini_tray.png: Loading 1 faces(PF_A8R8G8B8,32x32x1) with 5 generated mipmaps from Image. Internal format is PF_A8R8G8B8,32x32x1.
00:28:54: Texture: sdk_track.png: Loading 1 faces(PF_A8R8G8B8,16x32x1) with 5 generated mipmaps from Image. Internal format is PF_A8R8G8B8,16x32x1.
00:28:54: Texture: sdk_handle.png: Loading 1 faces(PF_A8R8G8B8,16x16x1) with 4 generated mipmaps from Image. Internal format is PF_A8R8G8B8,16x16x1.
00:28:54: Texture: sdk_mini_text_box.png: Loading 1 faces(PF_A8R8G8B8,32x32x1) with 5 generated mipmaps from Image. Internal format is PF_A8R8G8B8,32x32x1.
00:28:54: Texture: sdk_label.png: Loading 1 faces(PF_A8R8G8B8,32x32x1) with 5 generated mipmaps from Image. Internal format is PF_A8R8G8B8,32x32x1.
00:28:54: Texture: sdk_separator.png: Loading 1 faces(PF_A8R8G8B8,64x16x1) with 6 generated mipmaps from Image. Internal format is PF_A8R8G8B8,64x16x1.
00:28:54: Texture: sdk_logo.png: Loading 1 faces(PF_A8R8G8B8,128x64x1) with 7 generated mipmaps from Image. Internal format is PF_A8R8G8B8,128x64x1.
00:28:54: Texture: sdk_shade.png: Loading 1 faces(PF_A8R8G8B8,64x48x1) with 6 generated mipmaps from Image. Internal format is PF_A8R8G8B8,64x48x1.
00:28:54: Texture: sdk_frame.png: Loading 1 faces(PF_A8R8G8B8,32x32x1) with 5 generated mipmaps from Image. Internal format is PF_A8R8G8B8,32x32x1.
00:28:54: Texture: sdk_mini_text_box_over.png: Loading 1 faces(PF_A8R8G8B8,32x32x1) with 5 generated mipmaps from Image. Internal format is PF_A8R8G8B8,32x32x1.
00:28:54: Texture: sdk_pulse.png: Loading 1 faces(PF_R8G8B8,8x1x1) with 3 generated mipmaps from Image. Internal format is PF_X8R8G8B8,8x1x1.
00:28:54: Finished parsing scripts for resource group General
00:28:54: Creating resources for group General
00:28:54: All done
00:28:54: Parsing scripts for resource group Internal
00:28:54: Finished parsing scripts for resource group Internal
00:28:54: Creating resources for group Internal
00:28:54: All done
00:28:54: Mesh: Loading char_android_16_anims.mesh.
00:28:54: Skeleton: Loading char_android_16_anims.skeleton
00:28:54: WARNING: char_android_16_anims.mesh is an older format ([MeshSerializer_v1.41]); you should upgrade it as soon as possible using the OgreMeshUpgrade tool.
00:28:54: Can't assign material metal to SubEntity of plane because this Material does not exist. Have you forgotten to define it in a .material script?
00:28:54: *** Initializing OIS ***
00:28:54: Font SdkTrays/Caption using texture size 512x256
00:28:54: Info: Freetype returned null for character 160 in font SdkTrays/Caption
00:28:54: Texture: SdkTrays/CaptionTexture: Loading 1 faces(PF_BYTE_LA,512x256x1) with 0 generated mipmaps from Image. Internal format is PF_BYTE_LA,512x256x1.
00:28:54: Font SdkTrays/Value using texture size 512x256
00:28:54: Info: Freetype returned null for character 127 in font SdkTrays/Value
00:28:54: Info: Freetype returned null for character 128 in font SdkTrays/Value
00:28:54: Info: Freetype returned null for character 129 in font SdkTrays/Value
00:28:54: Info: Freetype returned null for character 130 in font SdkTrays/Value
00:28:54: Info: Freetype returned null for character 131 in font SdkTrays/Value
00:28:54: Info: Freetype returned null for character 132 in font SdkTrays/Value
00:28:54: Info: Freetype returned null for character 133 in font SdkTrays/Value
00:28:54: Info: Freetype returned null for character 134 in font SdkTrays/Value
00:28:54: Info: Freetype returned null for character 135 in font SdkTrays/Value
00:28:54: Info: Freetype returned null for character 136 in font SdkTrays/Value
00:28:54: Info: Freetype returned null for character 137 in font SdkTrays/Value
00:28:54: Info: Freetype returned null for character 138 in font SdkTrays/Value
00:28:54: Info: Freetype returned null for character 139 in font SdkTrays/Value
00:28:54: Info: Freetype returned null for character 140 in font SdkTrays/Value
00:28:54: Info: Freetype returned null for character 141 in font SdkTrays/Value
00:28:54: Info: Freetype returned null for character 142 in font SdkTrays/Value
00:28:54: Info: Freetype returned null for character 143 in font SdkTrays/Value
00:28:54: Info: Freetype returned null for character 144 in font SdkTrays/Value
00:28:54: Info: Freetype returned null for character 145 in font SdkTrays/Value
00:28:54: Info: Freetype returned null for character 146 in font SdkTrays/Value
00:28:54: Info: Freetype returned null for character 147 in font SdkTrays/Value
00:28:54: Info: Freetype returned null for character 148 in font SdkTrays/Value
00:28:54: Info: Freetype returned null for character 149 in font SdkTrays/Value
00:28:54: Info: Freetype returned null for character 150 in font SdkTrays/Value
00:28:54: Info: Freetype returned null for character 151 in font SdkTrays/Value
00:28:54: Info: Freetype returned null for character 152 in font SdkTrays/Value
00:28:54: Info: Freetype returned null for character 153 in font SdkTrays/Value
00:28:54: Info: Freetype returned null for character 154 in font SdkTrays/Value
00:28:54: Info: Freetype returned null for character 155 in font SdkTrays/Value
00:28:54: Info: Freetype returned null for character 156 in font SdkTrays/Value
00:28:54: Info: Freetype returned null for character 157 in font SdkTrays/Value
00:28:54: Info: Freetype returned null for character 158 in font SdkTrays/Value
00:28:54: Info: Freetype returned null for character 159 in font SdkTrays/Value
00:28:54: Info: Freetype returned null for character 160 in font SdkTrays/Value
00:28:54: Texture: SdkTrays/ValueTexture: Loading 1 faces(PF_BYTE_LA,512x256x1) with 0 generated mipmaps from Image. Internal format is PF_BYTE_LA,512x256x1.
00:28:55: DefaultWorkQueue('Root') shutting down on thread 0x9365d0.
00:28:55: DefaultWorkQueue('Root')::WorkerFunc - thread 0x93afc8 stopped.
00:28:55: DefaultWorkQueue('Root')::WorkerFunc - thread 0x93af38 stopped.
00:28:55: DefaultWorkQueue('Root')::WorkerFunc - thread 0x93af68 stopped.
00:28:55: DefaultWorkQueue('Root')::WorkerFunc - thread 0x93aea8 stopped.
00:28:55: DefaultWorkQueue('Root')::WorkerFunc - thread 0x93af98 stopped.
00:28:55: DefaultWorkQueue('Root')::WorkerFunc - thread 0x93aed8 stopped.
00:28:55: DefaultWorkQueue('Root')::WorkerFunc - thread 0x93af08 stopped.
00:28:55: DefaultWorkQueue('Root')::WorkerFunc - thread 0x93ae78 stopped.
00:28:55: *-*-* OGRE Shutdown
00:28:55: Unregistering ResourceManager for type Compositor
00:28:55: Unregistering ResourceManager for type Font
00:28:55: Unregistering ResourceManager for type Skeleton
00:28:55: Unregistering ResourceManager for type Mesh
00:28:55: Unregistering ResourceManager for type HighLevelGpuProgram
00:28:55: Uninstalling plugin: GL RenderSystem
00:28:55: Unregistering ResourceManager for type GpuProgram
00:28:55: *** Stopping Win32GL Subsystem ***
00:28:55: Unregistering ResourceManager for type Texture
00:28:55: Plugin successfully uninstalled
00:28:55: Unloading library .\RenderSystem_GL
00:28:55: Uninstalling plugin: Cg Program Manager
00:28:55: Plugin successfully uninstalled
00:28:55: Unloading library .\Plugin_CgProgramManager
00:28:55: Unregistering ResourceManager for type Material


scrawl wrote:
does this mean I am now using the preprocessor stuff, but with boost 1.48?

Unless you get linking errors with your project, you don't have to worry about it. (Yes, you are using it)


Nope, I'm not getting any linking errors when I compile, so I guess it's cool then =) (although, I have a feeling that it should be kept in mind)

If you need more information I'm happy to give it to you =)
Another note is that I'm using the Minimal Ogre example from the Ogre wiki, I'm wondering if there might be any code that interfere or something.

Regards,
Flayer
Flayer
Gnoblar
 
Posts: 7
Kudos: 0
Joined: 21 May 2012

Re: shiny - a shader and material management library for OGR

Postby Flayer » Sat Jul 28, 2012 11:41 pm

scrawl wrote:Oops, just saw there was another thing wrong with the docs (and I think that is why your material is black). The name of the texture unit in the shader ( shSampler2D(diffuse) -> "diffuse" ) has to be the same as the name of the texture unit in the material ( texture_unit diffuseMap -> "diffuseMap" ). This is needed because only texture units that are used by the shader are actually created (For example, if you have a base material with an optional asset like a normal map, that texture unit could be skipped in some cases)

Long story short, change the line to "shSampler2D(diffuseMap)" to get it to work. I should mention this as comment in the docs :D

Hi again,
Tried to post another before this, but apparently the forum thought my search path was a link, needed moderator approval (because I recently joined :P), I will remove it when it appears.
The reason, because your post solved the problem =)

Changing the fragment program from this
Code: Select all
SH_BEGIN_PROGRAM
   shSampler2D(diffuse)
   shInput(float2, UV)
SH_START_PROGRAM
{
   shOutputColour(0) = shSample(diffuse, UV);
}

Into this:
Code: Select all
SH_BEGIN_PROGRAM
   shSampler2D(diffuseMap)
   shInput(float2, UV)
SH_START_PROGRAM
{
   shOutputColour(0) = shSample(diffuseMap, UV);
}

Solved it =)

I should mention this as comment in the docs :D

I think that will be appreciated in the future ^^

But, are you really sure that everything is supposed to work with just these lines? (Taken from the doxy page)
Code: Select all
....
sh::OgrePlatform* platform = new sh::OgrePlatform("General", myApplication.getDataPath() + "/" + "materials");
sh::Factory* factory = new sh::Factory(platform);
....

The way I am doing it right now is:
Code: Select all
...
sh::Platform *platform = new sh::OgrePlatform("General", "<absolute path to the dir where the materials and shaders are>");
m_shinyFactory = std::unique_ptr<sh::Factory>(new sh::Factory(platform));
m_shinyFactory->setCurrentLanguage(sh::Language::Language_CG);
m_shinyFactory->loadAllFiles();
...

Sorry if I'm annoying you with those lines, just want to be sure, that's all =)

Thank you for your help, I really appreciate it!
I'll try to get some more salient shaders going =)

/ Flayer
Flayer
Gnoblar
 
Posts: 7
Kudos: 0
Joined: 21 May 2012

Next

Return to Showcase

Who is online

Users browsing this forum: No registered users and 3 guests