Flag Meanings (in materials, shaders, textures, meshes...)

Users who are viewing this thread

Ah... so there's a way to clamp, eh?

I wonder how much of the rendering code actually respects that... because that could be useful sometimes.
 
Thanks for the invaluable info everybody!
Edit: updated the listing above according to new info (3rd post of this thread).

xenoargh said:
Ah... so there's a way to clamp, eh?
I wonder how much of the rendering code actually respects that...

My guess is: all of it.
It is something  deeply embedded in the very-literally hardwired texture fetch mechanism of graphic cards; from the application side, something that just has to be set in a way or another anyway (for each texture in texture RAM).



One more question... there seem to be three consecutive flags for Alpha test in Material flags, plus a forth unused (maybe) one just next to them. [Cmpxchg8b] said that these three (four?) bits should be interpreted as a number dictating the alpha test value (background: if alpha test is activated, pixels more transparent than that value are discarded).

More info about the exact interpretation, anybody?


ALPHA TEST (discarding fragments because they are too transparent) is cheap and safe. ALPHA BLEND (blending transparent pixels with the background, so that background is partially visible behind the object, like a cross fading) is a more expensive, plus it requires correct exact render ordering.

On the other hand, ALPHA TEST does only cutouts (holes in you objects, or shapes), while ALPHA BLENDS does that plus more things (semitransparent objects). Even simple cutouts look better if you use the expensive ALPHA BLEND (assuming you enforce the right rendering order), than if you use only the cheap ALPHA TEST, because hole borders will look far better antialiased.

If you don't need semi-transparencies (you have only simple cutouts), consider using alpha test only (it is faster, but it will look a little less antialiased).

If you need semi-transparencies, you need alpha blending, but it is usually a good idea to also activate alpha test to make it a bit faster, unless all of the surface is semitransparent with no fully-transparent part. 

If you use alpha blending, you also need to use the correct render orderering to make sure that the transparent object is drawn after the back-ground it covers. At that point, you can help performance by disabling Z-test or Z-write (if you know what you are doing).
 
Great thread, I learned a lot, thanks. 

One question:  What exactly is texture animation in relation to the Warband engine? 
 
It should means that, instead of loading texture with name <X>.dds, games loads textures:
<X>_0.dds, <X>_1.dds, ... , <X>_N.dds,
(N being number of frames -1) and then show them in succession, with a cyclic animation.

It should be tested how far this mechanism can be used (for any texture? with any shader?), as the native module uses it only a single time: for the bump texture of water surface (for the moving little waves).


PS: there still are quite a few flags waiting an explanation... (see third post on page 1 for a recap), plus the alpha test bits in materials.
 
Oh wow, so the uv animation's stored in the mesh?  I'll bet there are some parameters for that, in terms of movement per frame.


There's no uv animation stored in the BRF.
UV coords are kept the same, even during a "vertex animation" stored in the mesh (only the positions and normals of vertices change).
In texture animations, it is the texture itself which changes: each frame of the animation is a different texture, and they are cycled  (at a fixed frame rate -- I don't think you can control the speed. Just the number of frames, max 64, from what can be told).
-- mtarini
 
So for each frame it's a separate texture?  Do they all have to be defined in the .BRF as part of the material, or will the game read the first one and find all in the range of whatever the engine's set to? (i.e. diffuse_0 only has to be defined and it will search for diffuse_1, 2, etc?) 

 
Apparently, yes (but, again, we have a single example from native). You name the texture "XXX", you set it to have for example 16 frames, and the game will look for
XXX_0.dds, XXX_1.dds, XXX_2.dds ...  XXX_15.dds
The underscore ("_"), the frame number, and the ".dds", are appended to the name you set in the brf file.

In the next OpenBRF version you will be able to set the number of frames a bit more easily.
 
Would be nice if we could get an animated diffuse/alpha to work for some effects,
animated lava, clouds, grass would be interesting.
 
Barf said:
Would be nice if we could get an animated diffuse/alpha to work for some effects,
animated lava, clouds, grass would be interesting.

Definitely worth a test. If it works, it will be useful e.g. for science fiction mods wanting to have simple cyclic animations, like moving light patterns all over robots and stuff, blinking lights, monitors (e.g. surveillance monitors), etc. Or, a medieval magic shield featuring a running cat logo which actually runs in place, anybody? :grin:

Probably not ideal for stuff like clouds, grass. Remember you have only a few frames, obligatory cycling, and no control on speed. Naturally, you can program shaders for other animations.


Back to the topic... I hope someone can shad light on the flags with unknown meaning (refer to 3rd post, on 1st page)...
plus the alpha test bits.
 
Double post!

In the latest version (0.0.64) I've embedded most of the information accumulated in this thread into the GUI, to increase usability (material, texture and mesh flags).

This includes not only the description of singular flags, but also the grouping of bits into values, when this is the correct interpretation (to our knowledge).  However, you'll see a button to view/edit every bit of the flag separately, just to be safe.

I thank everybody who contributed so far by sharing info, and especially [cmpxchg8b]!!!

If you have your own information about flags, then, by using the "show all" button described above, you can check if the interpretation is correct or not. Please report here any correction or addition you can provide!

The to-do list includes:
[*] alpha-test flag / alpha-test-value bits: are those correct? They don't seem too consistent in the way native materials set those.
edit: [cmpxchg8b] clarified some of that in a PM. Next version will embed that info too.
[*] many unknown flags in material and meshes (see my third post on page 1).
[*] little is known for flags for the shaders (plus, for each piece of each texture access of the shaders), and the flags for the collision manifolds.
 
Ok, I'm sure that one of the 3 so-called particle flags is "2D Billboarding"
I know that this isn't any surprise. But I'm only confirming it. This is specially visible in the water drop (prtcl_rain)

This is specially helpful for faking volumetric objects.
It turns around its Z axis facing the camera but conserving the local "vertical" rotation. As you want to call it.

Historically it has been used for faking spherical objects with planes in older games (I'm talking about Rayman 2 or Warcraft 3, for example)
 
Would the texture animation work for normal maps as well? You could get a very simple wavy cloth with that without having to program a new shader.

-- I don't think the texture animations has been tested much, in that or any other situation. Would be interesting to know, but I think one can reasonably hope so -- mtarini
 
MadocComadrin said:
Would the texture animation work for normal maps as well? You could get a very simple wavy cloth with that without having to program a new shader.

Yeah, but the downside is that it'd add ~5-10 mb to a mod. 
 
I've played around a lot with the animation stuff but I'm fairly sure that it is hardcoded in the game for when certain objects are being rendered (water plane).

Still, there are a couple of tricks you can use with a custom shader. You can blend between some different textures passed in via the empty texture slots. Or I had an effect which only required a B&W texture, so I used a RGBA texture and blended between the different channels giving a nice 4 frames to blend between.
 
I don't think there is a single piece of armor in native that uses that flag, where did you get this idea?.
iirc lods will work fine without any flags.
 
Every single piece of native armors and weapons use this flag, in never editor however flags are set to 0, that's the only reason I use one of the older versions of openbrf, and that's where I got the idea from.
capture2m.png
capturedhf.png
capture3tz.png
 
Zimke Zlovoljni said:
Hi mtarini,

I  wanted to ask you one thing, I used flag 30000 for meshes and I'm pretty sure this flag allows reading lods. With flag 0 game wont read the loads, at least I think so because I noticed a performance decrease with flag 0, while with flag 30000 there is no performance issue. So how can I add flag 30000 for meshes since once it's typed in manualy after moving to next mesh it turns back to flag 0.

Regards.
It's not necessary to do so. To check if Warband is reading the LODs you can force the engine to load them by putting the game in windowed mode (Alt+Enter) and in one of the drop down menus you can tell it to load LODs 1-5.
 
Zimke Zlovoljni said:
Hi mtarini,

I  wanted to ask you one thing, I used flag 30000 for meshes and I'm pretty sure this flag allows reading lods. With flag 0 game wont read the loads, at least I think so because I noticed a performance decrease with flag 0, while with flag 30000 there is no performance issue. So how can I add flag 30000 for meshes since once it's typed in manualy after moving to next mesh it turns back to flag 0.

Regards.
30000 is not a flag, it's two flags (0x10000 and 0x20000).
OpenBRF is not showing them because it treats them as mandatory. If you click on Show all bits in the flag editor they should be both checked and greyed out (tangent space and Warband format).
 
Back
Top Bottom