login

Author Topic: Shader and Graphical effects Discussion  (Read 47604 times)

Offline mtarini

  • Administrator
  • *****
  • Posts: 1495
  • TLD dev team
    • View Profile
    • (home)
Re: Shader and Graphical effects Discussion
« Reply #30 on: November 08, 2007, 05:28:21 am »
Let me add just a few extra clarifications:

Space costs:

- texture size is unaffected by image contents.
Unfortunately, texture are compressed with a fixed-size compression, which results in the same amount of memory (or disk space) being used for an image of a given size, independently from the content of the image (full white images take as much as complex one). It's not like jpg compression (or png, or gif...) where more complex images will take more space than "boring" ones.

- clearly, size is affected by:
  a- resolution (higher res images take more)
  b- channels used (e.g. RGBA images take more than RGB).
  c- used compression schema
(there are different alternative compression schemas, each resulting in a different fixed size for the same image, but diffrerent quality).

About (c), the bad news is that normal map require very good quality (quantization will show a lot more than with rgb color maps) so, say, a 512x512 normal map needs to be compressed less, and therefore will take more (around, twice more) than a 512x512 color map.


effects of space cost:

The amount of texture memory used will severely hit loading time, naturally.

On a first approximation, it won't hit rendering performance, but because of:
- more context switches (this has to do with the number of different used texture, not their size)
- less cache coherence (more cache misses, I'm talking about the cache between the GPU and the on-board texture RAM. This has to do with texture size.)
- increased risk of running out of graphic card memory (not sure which policy is adopted then but whatever it is it costs time)

But the effect of all the above is usually negligible in our case.

So, to answer the original question, texture size (bumpmapping or otherwise) does affect used memory size, but not (or only very marginally) FpS performance.


rendering time cost of bumpmapping:

- bumpmapping itself is not a big cost at all, computationally (if done right). Usually it cost way less than, say, alpha blending (in most computers).
But, any shader that uses two textures instead of one (colormap and bumpmap in our case) costs more than one that uses only one.

Also, this cost, small or little, is hitting where it potentially hurts the most: the per-fragmet computation phases.

I came to the conclusion that, in most computer, M&B is usually a "fill-limited" application, that is, the bottleneck is the per-fragment  (per-pixel, if you wish) operations, including bumpmapping.

(to see if M&B is fill limited on your computer, see if changing resolution or increasing antialiasing has an effect: when it does, it is fill-limited).

But this is not always the case. For example, the multiresolution (LOD) approach that .89x uses won't help a bit a fill-limited application. Which means (since I can safely take that Armagan knows what he's doing) that M&B is "transform limited" at least sometimes (for example, when a lot of moving man and horses are visible in the distance).

bryce

  • Guest
Re: Shader and Graphical effects Discussion
« Reply #31 on: November 08, 2007, 10:26:49 am »
Well, it will become that way if you have 100 guys on the screen, especially far away.

the very fact that it is fragment limited means that the cost will be reduced with distance because fewer pixels need to be transformed.

For polygons themselves it doesn't work that way unless you have LOD set up.

If you get 100-200 guys on the screen, even if you have a great computer your framerate will be brought to its knees, but if you have LOD then you should be able to have 1000 guys on the screen, easily, if they are all far away.

Does M&B natively even use any normalmapping, though? the faces could definitely use some, but nothing appears normalmapped aside from the banners.

Offline mtarini

  • Administrator
  • *****
  • Posts: 1495
  • TLD dev team
    • View Profile
    • (home)
Re: Shader and Graphical effects Discussion
« Reply #32 on: November 09, 2007, 01:05:43 am »
Well, it will become that way if you have 100 guys on the screen, especially far away.
Hem, isn't that exactly what I have been saying. Anyway...

GENERAL PURPOSE SHADERS, (pre-alpha) -- for ver .80x

I played with the shader this night. We all had several ideas of general utility in the past weeks and I wanted to implement them all.

Concept

In short, the shaders must be able deal with several possible "effects" (not all of them at once of course):


A- bumpmapping (i.e. per-texel normals)
B- emission (i.e. light glowing out of the model, visible even in the darkness)
C- transparency (you must activate alpha blending and/or alpha kill)
D- shininess (reflections intensity, and/or its color)


To deal with them, we have a pool of sources of data (I'll call them sources):

1- Color texture, RGB (but this is always used for diffuse color)
2- Color texture, Alpha channel
3- Auxiliary texture, RGB (the one that is called "bump texture" in the shader)
4- Auxiliary texture, Alpha channel
5- Per vertex color, RGB (but this is better left untouched, because it is used to spill blood on things)
6- Per vertex color, Alpha channel


Bumpmapping, if used, will always use source n. 3 (RGB channels of "bump texture")
Other effects can relay on data coming from several different possible sources.

Glossary:
A texel is a pixel of the texture. Per-Color-Vertices are defined in the BRF model (you can paint them with brfedit).


Notes:

- Sources 1 and 5 have their use already in basically any objects, and we will not to use them for our effects.
  All other sources can be used to achieve the set of effects you need.

- Effect D (transparency) has at least two separate uses (depending on the material settings, not the shader):
  (a) you can use it to make stuff that you can see through, like dust particles or glass
       This can be quite expensive. You activate it by setting "Blend" in the material flags
  (b) you can use it to shape the contours of something flat, like a flag or grass or fur
       This should be cheap. You activate this by setting "Alpha kill" in the material flags.
  If you need just (b), don't activate (a).

- When possible, it is better to use just one texture. For example, if you want your object to be both partially
  shining (C) and partially transparent (D), maybe, instead of having two textures (one for the color and D, one
  for C alone), you can have D on the alpha of first texture and control C with per vertex Alpha color. This is not always possible
  (merlkir: for example it is not in your last model I've seen, wink wink). Cearly, controlling something
  by painting the texture (e.g. its alpha channel) gives a lot more control.

- Emission and Shininess effects have this in common: they can be defined with a color (the color of the emitted light,
  or the color of the reflections). If you use an Alpha channel (whichever) to define them, then the shader will use as the
  color the "specular color" defined in the material options. This means that you will be able to control how much light
  is emitted/reflected but not its color, which you can choose but will be constant over the object. If you use a full RGB channel
  (whichever, per vertex color or the auxiliary texture) then that color will be used, and its brightness will determine the strength.

For example, say I want the eyes of the warg to be emitting a dim yellow light. I can either set the so called "specular color" to a bright yellow, then use a texture alpha channel, and put alpha>0 (but not much high) in the areas I want it to be glowing, or, I can forget about the "specular color" and paint (dark) yellow halos where I want yellow light to be given off in an otherwise black auxiliary texture (for emission). In the latter case, I can change the color of emitted light across the model.

- Shininess can be defined as constant strength over the model (and the "specualar color" will be used). This way, no source of info is required (no texture or anything). The entrire object will just be equally reflective. It can be interesting if you give reflections of some cool color like bluish, rather than the usual white.

- Emitted and reflected light are added to the rest of the lighting, so I think that use small strenghts if you don't want tol overexpose it.

Enough notes.



Possible shaders

Now, what I did is trying to code all the combinations that made sense to me. For example, use texture1 alpha channel for transparency, texture 2 rgb as bump, and texture 2 alpha as shininess (plus texture 1 rgb as base color, as always). Or, use a single texture, with its alpha defining transparency. Or whatever. Each case seemed useful in some cases. In addition, each combination that can be or not be rigged. That makes a surprising high number of sensible combinations (removing stupid one already). Namely, 154. I wrote (automatically, of course) a pretty lean and mean shader for each of them. I was planning to put them all in, and let people use the one that they needed, but that's not an option apparently because, surprise again, the 154 shaders, even if they are almost all unused, still will slow down loading time considerably.

So this is what I'll do instead. I'll share the code.

It's a very beta! Most combinations needs to be tested. Especially rigging. I don't have a single bumpmapped rigged model. There could be loads of other errors.

Here is how to make a test.


How to try a shader

First, you need the "core" part of the code. It is here to download: core_mtarini_shaders.ver.0.0.txt
That code is used by all the shaders I've made. You have to attach it at the end of the mb.fx file in the MaB directory.

Next, you need the specific the shader you want to see. Each shader is identifyed by its name, which describes what it does, according to this schema:

The name of the shader is a sequence of words, separated by underscores.

The first word is mtarini (underscore)

Then, you have to specify each effect that you want, in the order shown below.
Each effect is in turn composed by an identification name (notice the case), followed by an X, followed by the name of the source used to drive it. Effects are, in order

Shin (shininess)
Transp (transparence)
Emis (emission)

plus two possible flags at the end, that can just be or not be present (no source for them)

Bump (use bumpmap -- will automatically use rgb channels of "bump" texture)
Rig (use rigging, aka. skinning, aka skeletal animations)

(the behavior of the shader will be coherent: for example if you specify shininess, that applies to the normal map or to the standard normals defined in the model depending on whether the bumpmap is used or not).

The used source, for a given effect, to be put after an effect and after the "X", is one of:

tca (Texture Color, Alpha channel)
tba (Texture "Bump", Alpha channel)
tb (Texture "Bump", --- rgb channels)
vca (per Vertex Color, Alpha channel)

If an effect is constant (no source), just write the name without the X or the source name. For example mtarini_Shin_Bump means that all the object will be equally shiny (and will use  bumpmapping).


Once you have identified the exact string describing the shader you want, you need to copy the corresponding "technique" from the list linked below. A technique is just 4 lines of code. Cut and paste it at the end of you mb.fx file.
Take the shader from this complete_mtarini_shader_list.ver0.0.txt.

That's not all, unfortunately. Before an object can use that shader, you also need that the above shader is mentioned in a BRF file you include in the mod. To do so, use BRF edit: go in the shader tag, add a new shader (or maybe import a shader from another BRF with a shader in it), paste the shader name in the "name" tag. Paste it again in the "file" tag. Then go to your object that must use the shader, edit its material, and place the shader there. Then it should work.



Example of shaders names

If I use the shader called mtarini_ShinXtca_Bump_Rig means that I want the shader to interpret the alpha channel of the color texture as shininess (base "specular color" will be used), I want to use bumpmapping from the "bump texture" (no alpha needed in that texture), and I want it on a rigged model.

Similarly, mtarini_ShinXtba_TranspXtca_Bump means that I want shininess and transparency defined in the alpha channels of the bumpmap and the color map respectively, plus I want bumpmapping (this is the one we planned with Yoshi a while ago).

Merlkir: your last mesh (I mean the last I've seen) could use
mtarini_ShinXtb_TranspXtca so that the auxiliary texture (BRFedit will still call it "bumpmap") will be used to encode reflection colors (and thus shininess: black means no reflections, full red means very strong red reflections, etc). and the alpha channel of the color map will be used for transparency (no bumpmap in this case).

Another example: my previous idea of the helmet to add a little shadows can be achieved with mtarini_TranspXvca, using a single color texture (no alpha) and specifying the alpha in the vertices of the shadowing triangles. If needed, specularity can be additionally specified in the alpha channel using mtarini_ShinXtca_TranspXvca instead, which still requires a single texture.

Last example: if you want to add yellow light to the eyes of the warg model to make it look a little like Merlkir concept, you can use mtarini_EmisXtca_Rig, so that the alpha channel can be se to emit light around the eyes (the default "specular color will be used, so it must be set to yellow). Still one texture. Note the "Rig" part at the end, needed because it is an animated model.
PS: ehy Merlkir concept changed! Used to be brighter eyes. Still you can use emission to make the eye visible in the dark (or through the fog?).





Hum, long post. Hope you can follow it all and help me finding out if and how it works.
Admittedly, its for expert users only. But, when it will be debugged and working, many people will be able to use the small subset of shaders that will prove useful.

I will test it myself sooner or later, and put links to a ready to use "brf" files with a selection ofl shaders.

I'll post screenshots in a sec.

« Last Edit: November 09, 2007, 09:55:30 am by mtarini »

Offline mtarini

  • Administrator
  • *****
  • Posts: 1495
  • TLD dev team
    • View Profile
    • (home)
Re: Shader and Graphical effects Discussion
« Reply #33 on: November 09, 2007, 01:41:16 am »
To start, let me show the bumbmapped shark that Yoshi did.
It uses the simple "mtarini_Bump" shader. It should use the "mtarini_Bump_Rig" one but it is not rigged.
(mysteriously, it still moves. It must be that M&B moves a few vertices in the CPU as well, for horses).

It is a breif story of how bumpmapping alone works.

Wow! Yoshiboy did a really god job.
Here, I removed all color textures to isolate the effect of the bump.
The rendering looks good from a side...
But bad from the top.
This is because the same texture used on both sides, which, when the normal map is in model space
means forced symmetry of the chiaroscuro and inchoerent lighting.
If you saw this moving, you would agree that something is wrong.
Solution: we swap the x component of the normals when on we are on the other side.
The other side is the one that is defined with normal x > 0. We are speaking about the normal
that is defined at vertices. That is the only use we are making of that data. For all the rest,
the normals defined in the model are overridden by the normalmap.

Now the symmetry of the lighting (the "chiaroscuro") broke, and the lighting is finally coherent.
(if you saw this moving, would would see it is now lightet right).
But now there is another problem left: you can see where the parts (left and right) are glued.
See for example in the back.

This happens because normals are not straight up (Nx=0) on the junction.
That can be fixed too. I force Nx to be zero around the junctions. It is a lot less evident now
(the screenshots are reduced. In full size, the discontinuity line showed wuite a bit.
Now everything is ready.
It does react to light direction...
...beautifully.
Putting back the color texture
(for this leggedly challenged horse only)

(or, should I call it a diversely mammalian horse)
You can't see it, but it has a sticker on the back which says:
"My other mount is a bumpmapped shark too".
« Last Edit: November 09, 2007, 02:37:29 pm by mtarini »

Offline Merlkir

  • Administrator
  • *****
  • Posts: 5742
    • View Profile
    • My DeviantArt online Gallery
Re: Shader and Graphical effects Discussion
« Reply #34 on: November 09, 2007, 01:50:01 am »
Excellent work, mtarini! Thank you! :) I really felt shaders are quite powerful and underestimated by MaB devs/players. :)

I already have some more ideas for TLD after reading this..
Here's my gallery: http://merlkir.deviantart.com/

I'm now painting and drawing commissions. I'll paint portraits, pets, girlfriends, favourite characters..you name it. Send me a PM if interested ;)

Offline Ancientwanker

  • Master
  • *****
  • Posts: 1312
    • View Profile
Re: Shader and Graphical effects Discussion
« Reply #35 on: November 09, 2007, 08:24:14 am »
Cool. I think I need to read this about 6 more times though.  :-[  :lol:

Offline Merlkir

  • Administrator
  • *****
  • Posts: 5742
    • View Profile
    • My DeviantArt online Gallery
Re: Shader and Graphical effects Discussion
« Reply #36 on: November 09, 2007, 09:22:39 am »
oh...I just thought...trolls would look so good with bumpmapped skin! :D
Here's my gallery: http://merlkir.deviantart.com/

I'm now painting and drawing commissions. I'll paint portraits, pets, girlfriends, favourite characters..you name it. Send me a PM if interested ;)

Offline Ahadhran

  • Mysterious Old Man
  • Craftsman
  • **
  • Posts: 137
    • View Profile
Re: Shader and Graphical effects Discussion
« Reply #37 on: November 09, 2007, 11:22:33 am »
wow, nice work. This seems to open up a lot of possibilities!

Offline Ursca

  • Deus Vult Dev
  • *****
  • Posts: 128
    • View Profile
Re: Shader and Graphical effects Discussion
« Reply #38 on: November 09, 2007, 03:17:54 pm »
Very, very nice. I look forward to playing around with this. The 'cost' might be a little high to use on normal troops, but as Merlkir said, it would work great on big things like trolls, ents, elephants and suchlike. We just need the BRFEdit update.  :P

One thing though; you can see the polygons left over from zbrush on the normal map. Any way to get rid of those?
A gaussian blur, or just cranking up the subdivisions in zbrush?

Offline mtarini

  • Administrator
  • *****
  • Posts: 1495
  • TLD dev team
    • View Profile
    • (home)
Re: Shader and Graphical effects Discussion
« Reply #39 on: November 09, 2007, 03:35:09 pm »
One thing though; you can see the polygons left over from zbrush on the normal map. Any way to get rid of those?
A gaussian blur, or just cranking up the subdivisions in zbrush?

I think that it might be due to texture compression. Point, 6 bits per channel can be good enough for a color map (64 shades of R, G and B),  but not for a texture map.
I think the solution could be to try a different (more space consuming) compression schema. Hoping that M&B accepts that. I know for a fact that it does not accept all formats of DDS.

Offline Ursca

  • Deus Vult Dev
  • *****
  • Posts: 128
    • View Profile
Re: Shader and Graphical effects Discussion
« Reply #40 on: November 10, 2007, 06:42:16 am »
I think I broke it:


When you add the shader in BRFEdit, are there any particular settings to use?
I imported agent_shader and just changed the name and file.

Edit: The above effect only happens indoors. Outdoors, it's just invisible.

Offline mtarini

  • Administrator
  • *****
  • Posts: 1495
  • TLD dev team
    • View Profile
    • (home)
Re: Shader and Graphical effects Discussion
« Reply #41 on: November 10, 2007, 09:27:57 am »
I think I broke it:

It's probably my fault. The thing is not tested for many combinations.
Can I be sent the files needed to replicate that results? Or maybe you just tell which shader you tested.

Edit: also, which version of M&B. The few things that are tested are tested in 0.806.
« Last Edit: November 10, 2007, 09:31:18 am by mtarini »

Offline Ursca

  • Deus Vult Dev
  • *****
  • Posts: 128
    • View Profile
Re: Shader and Graphical effects Discussion
« Reply #42 on: November 10, 2007, 09:41:24 am »
It was mtarini_ShinXtca_Bump_Rig.

If you want me too, I can send you the module. I just need your email address.

Offline mtarini

  • Administrator
  • *****
  • Posts: 1495
  • TLD dev team
    • View Profile
    • (home)
Re: Shader and Graphical effects Discussion
« Reply #43 on: November 10, 2007, 09:50:11 am »
It was mtarini_ShinXtca_Bump_Rig.

If you want me too, I can send you the module. I just need your email address.

So it uses the Shininess from the alpha channel of the color texture, on a bumpmapped and rigged model.
Can I have the model, including the two textures it uses? PMming my email.

Edit: got it. But, it's for 0.89x version! No wonder it has problems. I only tested for the previous 0.80x version.
« Last Edit: November 10, 2007, 11:12:24 am by mtarini »

Offline Ursca

  • Deus Vult Dev
  • *****
  • Posts: 128
    • View Profile
Re: Shader and Graphical effects Discussion
« Reply #44 on: November 10, 2007, 10:07:14 am »
Sent.

I was concerned with the shader in BRFEdit because it seems it retains a lot of information from the shader that was imported.
I've no idea what it does though.  ;)