Dynamic Tint/Retexture of Items - Example

[Lav]

Question: What is so interesting about the below image?

Spoiler: Thoroughly unimpressive screenshot

Answer: all dresses on the image are essentially the same dress, dynamically re-painted or re-textured by tableau materials.

Download Link (Google Drive, 238K)

So, what do you have to do to make nearly any wearable item in the game dynamically retexturable?

The answer is: surprisingly little.

Step 1: Make a replica of texture file used by the item (I used blue_dress.dds which is used by itm_blue_dress_new).
Step 2: Open it in GIMP.
Step 3: Decide what area of your item will be retexturable. Make it semi-transparent and desaturated while leaving visual imperfections. Tool "Color to Alpha" in "Color" menu works great for this, possibly followed by decoloration tool from the same menu. See file "lav_cc_dress.dds" in the downloadable example to see what you want to get in the end.
Step 4: With modified texture, create material and simple tableau mesh. Reference the tableau mesh in module_meshes. See "lav_cc_dress" entries in brf file and "camo_dress" in module_meshes for examples on how.
Step 5: Make a replica of tableau material code for your item. Important notes: your tableau material header should reference the material used by the original item (so correct bumpmap and specmap are applied to the resulting item), as well as correct texture dimensions. Use your new tableau mesh instead of "mesh_camo_dress". The remaining code will be the same.
Step 6: Voila! You can now make any number of new items using your new tableau material. There's an important caveat though:
Step 7: Tableau material can use either a solid color or a texture mesh to "paint" your item. If you pass a negative value, it is treated as a hex color code. If you pass a mesh reference, the mesh will be used instead. See module_items in the downloadable example to see how it's done.

So the essential result is that you no longer need to create separate textures, materials and meshes to have differently colored items. Create one mesh, invest some work to make a transparent texture, and you can spawn any number of variations of your item by just adding new entries to module_items. Creating re-textured items is only slightly more complex as you have to create a texture mesh, but making one is easy even to a newbie, and once a texture mesh is made, it can be applied to any of your re-texturable items.

Spoiler: Some examples

Spoiler: Text entries from the downloadable example

Attention: adding these lines to your module is not enough, you need to download the archive with resources as well.

  ("camo_dress", 0, "lav_cc_dress",  0, 0, 0, 0, 0, 0, 1, 1, 1),

  ("camo_texture_01", 0, "lav_cc_texture_01", 0, 0, 0, 0, 0, 0, 1, 1, 1),
  ("camo_texture_02", 0, "lav_cc_texture_02", 0, 0, 0, 0, 0, 0, 1, 1, 1),
  ("camo_texture_03", 0, "lav_cc_texture_03", 0, 0, 0, 0, 0, 0, 1, 1, 1),
  ("camo_texture_04", 0, "lav_cc_texture_04", 0, 0, 0, 0, 0, 0, 1, 1, 1),
  ("camo_texture_05", 0, "lav_cc_texture_05", 0, 0, 0, 0, 0, 0, 1, 1, 1),
  ("camo_texture_06", 0, "lav_cc_texture_06", 0, 0, 0, 0, 0, 0, 1, 1, 1),
  ("camo_texture_07", 0, "lav_cc_texture_07", 0, 0, 0, 0, 0, 0, 1, 1, 1),

    ("camo_dress", 0, "blue_dress", 512, 512, 0, 0, 0, 0,
        [
            (store_script_param, ":instance_id", 1),
            (set_fixed_point_multiplier, 100),
            (init_position, pos1),
            (try_begin),
                (gt, ":instance_id", 0),
                (cur_tableau_add_mesh, ":instance_id", pos1, 0, 0),
            (else_try),
                (store_sub, ":instance_id", 0, ":instance_id"),
                (val_or, ":instance_id", 0xFF000000),
                (cur_tableau_set_background_color, ":instance_id"),
            (try_end),
            (position_set_z, pos1, 30),
            (cur_tableau_add_mesh, "mesh_camo_dress", pos1, 0, 0),
            (cur_tableau_set_camera_parameters, 0, 200, 200, 0, 100000),
        ]
    ),

["camo_dress_r", "Camo Dress - Red", [("blue_dress_new",0)], itp_merchandise| itp_type_body_armor  |itp_covers_legs|itp_civilian ,0, 6 , weight(1)|abundance(100)|head_armor(0)|body_armor(6)|leg_armor(2)|difficulty(0) ,imodbits_cloth,
[(ti_on_init_item, [(cur_item_set_tableau_material, "tableau_camo_dress", -0x800000)])]],

["camo_dress_g", "Camo Dress - Green", [("blue_dress_new",0)], itp_merchandise| itp_type_body_armor  |itp_covers_legs|itp_civilian ,0, 6 , weight(1)|abundance(100)|head_armor(0)|body_armor(6)|leg_armor(2)|difficulty(0) ,imodbits_cloth,
[(ti_on_init_item, [(cur_item_set_tableau_material, "tableau_camo_dress", -0x008000)])]],

["camo_dress_b", "Camo Dress - Blue", [("blue_dress_new",0)], itp_merchandise| itp_type_body_armor  |itp_covers_legs|itp_civilian ,0, 6 , weight(1)|abundance(100)|head_armor(0)|body_armor(6)|leg_armor(2)|difficulty(0) ,imodbits_cloth,
[(ti_on_init_item, [(cur_item_set_tableau_material, "tableau_camo_dress", -0x000080)])]],

["camo_dress_01", "Camo Dress - Blue Web", [("blue_dress_new",0)], itp_merchandise| itp_type_body_armor  |itp_covers_legs|itp_civilian ,0, 6 , weight(1)|abundance(100)|head_armor(0)|body_armor(6)|leg_armor(2)|difficulty(0) ,imodbits_cloth,
[(ti_on_init_item, [(cur_item_set_tableau_material, "tableau_camo_dress", "mesh_camo_texture_01")])]],

["camo_dress_02", "Camo Dress - Burlap", [("blue_dress_new",0)], itp_merchandise| itp_type_body_armor  |itp_covers_legs|itp_civilian ,0, 6 , weight(1)|abundance(100)|head_armor(0)|body_armor(6)|leg_armor(2)|difficulty(0) ,imodbits_cloth,
[(ti_on_init_item, [(cur_item_set_tableau_material, "tableau_camo_dress", "mesh_camo_texture_02")])]],

["camo_dress_03", "Camo Dress - Electric Blue", [("blue_dress_new",0)], itp_merchandise| itp_type_body_armor  |itp_covers_legs|itp_civilian ,0, 6 , weight(1)|abundance(100)|head_armor(0)|body_armor(6)|leg_armor(2)|difficulty(0) ,imodbits_cloth,
[(ti_on_init_item, [(cur_item_set_tableau_material, "tableau_camo_dress", "mesh_camo_texture_03")])]],

["camo_dress_04", "Camo Dress - Military", [("blue_dress_new",0)], itp_merchandise| itp_type_body_armor  |itp_covers_legs|itp_civilian ,0, 6 , weight(1)|abundance(100)|head_armor(0)|body_armor(6)|leg_armor(2)|difficulty(0) ,imodbits_cloth,
[(ti_on_init_item, [(cur_item_set_tableau_material, "tableau_camo_dress", "mesh_camo_texture_04")])]],

["camo_dress_05", "Camo Dress - Leopard", [("blue_dress_new",0)], itp_merchandise| itp_type_body_armor  |itp_covers_legs|itp_civilian ,0, 6 , weight(1)|abundance(100)|head_armor(0)|body_armor(6)|leg_armor(2)|difficulty(0) ,imodbits_cloth,
[(ti_on_init_item, [(cur_item_set_tableau_material, "tableau_camo_dress", "mesh_camo_texture_05")])]],

["camo_dress_06", "Camo Dress - Leather", [("blue_dress_new",0)], itp_merchandise| itp_type_body_armor  |itp_covers_legs|itp_civilian ,0, 6 , weight(1)|abundance(100)|head_armor(0)|body_armor(6)|leg_armor(2)|difficulty(0) ,imodbits_cloth,
[(ti_on_init_item, [(cur_item_set_tableau_material, "tableau_camo_dress", "mesh_camo_texture_06")])]],

["camo_dress_07", "Camo Dress - Walnut", [("blue_dress_new",0)], itp_merchandise| itp_type_body_armor  |itp_covers_legs|itp_civilian ,0, 6 , weight(1)|abundance(100)|head_armor(0)|body_armor(6)|leg_armor(2)|difficulty(0) ,imodbits_cloth,
[(ti_on_init_item, [(cur_item_set_tableau_material, "tableau_camo_dress", "mesh_camo_texture_07")])]],

 

[Kentucky 『 ＨＥＩＧＵＩ 』 James]

Excellent idea. Could save a lot of tedium for modders with a lot of recoloured uniforms. Well done

Spoiler

crying because i wish I'd thought of this before i started making itm_civilian_robe_54_a

Edit: I'm assuming you could do something similar involving triggers? So that uniforms get dirty later in the battle, for example?

 

[Lav]

Edit: I'm assuming you could do something similar involving triggers? So that uniforms get dirty later in the battle, for example?

Should be possible. Operation (store_trigger_param_1) can be used from inside scripts and tableau materials for as long as the code is being executed in the context of ti_on_init_item trigger. So the code below could be used to add some dirty spots on the dress for as long as we are on a mission. This can be further expanded to add an appropriate level of dirtiness/bloodiness depending on agent's health status and mission type, et cetera.

    ("camo_dress", 0, "blue_dress", 512, 512, 0, 0, 0, 0,
        [
            (store_script_param, ":instance_id", 1),
            (set_fixed_point_multiplier, 100),
            (init_position, pos1),
            (try_begin),
                (gt, ":instance_id", 0),
                (cur_tableau_add_mesh, ":instance_id", pos1, 0, 0),
            (else_try),
                (store_sub, ":instance_id", 0, ":instance_id"),
                (val_or, ":instance_id", 0xFF000000),
                (cur_tableau_set_background_color, ":instance_id"),
            (try_end),
            (try_begin),
                (store_trigger_param_1, ":agent_id"),
                (gt, ":agent_id", -1), # We have a valid agent ID, hence we are in a mission!
                (position_set_z, pos1, 15),
                (cur_tableau_add_mesh, "mesh_dirty_spots", pos1, 0, 0),
            (try_end),
            (position_set_z, pos1, 30),
            (cur_tableau_add_mesh, "mesh_camo_dress", pos1, 0, 0),
            (cur_tableau_set_camera_parameters, 0, 200, 200, 0, 100000),
        ]
    ),

Note that there's no "mesh_dirty_spots" object, it's just a code example. Should be perfectly workable though.

 

[Lav]

Confirmed: perfectly possible.

Here's our great tester girl in a green dress after certain... activities.

Blood texture sucks since I'm not an artist and didn't give it any love. Still, works as proof of concept that yes, it's perfectly possible to add extra context-dependent overlays.

 

[Slawomir of Aaarrghh]

Using tableaus is fine as long as you need a lot of same models with just different colour variants. Although, using it to apply new textures makes not much sense in Warband, since there's no such low item cap as in M&B 1.011 and there's a visible loss of texture sharpness when using tableau materials. So even though I myself used such thing in M&B 1.011 to apply textures to shields and armours, I think for armours in Warband it's just better to duplicate the models if you want them to be high quality.

Here's some old posts with few comparison screens for tableau and non-tableau items - http://forums.taleworlds.com/index.php/topic,136799.msg3291242.html#msg3291242

But still, tableau materials are great for people who need a lot of recoloured items of the same type or just don't mind the loss of texture sharpness.

 

[Lav]

Using tableaus is fine as long as you need a lot of same models with just different colour variants. Although, using it to apply new textures makes not much sense in Warband, since there's no such low item cap as in M&B 1.011 and there's a visible loss of texture sharpness when using tableau materials. So even though I myself used such thing in M&B 1.011 to apply textures to shields and armours, I think for armours in Warband it's just better to duplicate the models if you want them to be high quality.

Quality loss doesn't seem to be really noticeable for as long as the painting textures are of at least the same size as the item texture. Dresses on the screenshots in the opening post seem detailed enough for my (unprofessional I'll admit) eye. Theres a plenty vanilla items which look several times less detailed without any tableaus.

Naturally, in every mod there are some extremely high-quality items which only player and his companions are supposed to obtain. It doesn't make sense to reduce their quality by dynamically re-texturing them. But there are tons of mass-produced items as well. Player may spend time to appreciate his "itm_unique_shield_of_awesomeness" in detail, but he's much less likely to pay the same amount of attention to "itm_ordinary_chain_mail_that_every_friggin_mercenary_has".

Finally, there are also considerations of mod size and computer memory. A mod with a large number of retextured items can benefit a lot in these areas. After all, a few years ago I abandoned my Civilians mod for this very reason: it's size was growing exponentially with new items and it no longer seemed sensible to waste hundreds of megabytes for a relatively minor and purely aesthetic improvement to the game.

 

[ShaunRemo]

Hello, I was going to post about exactly this topic soon about how to do this, I considered tableau but I was concerned that the material might reduce performance but if multiple items are referencing the same background colour and mesh it'd probably balance out.

I haven't researched anything but it'd be nice to be able to force a new material or randomly select a new material for a mesh in the itemkinds1.txt something like

object_name mesh-(material)
        or
object_name mesh-5(material1,material2,material3,material4,material5)
for random materials on creation.

As well as this I speculated if it would be possible to reference multiple meshes in one object to create additional variance for example

object_name mesh1-2(material1A,material1B) + mesh2-2(material2A,material2B)
        or
green_shirt shirt-2(shirt_dark_green,shirt_light_green) + pants-2(pants_brown,pants_black)

so now 1 object can have multiple parts that are coloured separately and randomly allowing for things such as horses all referencing a base horse mesh that has multiple materials for colours and additional meshes can be added  to distinguishes them such as saddles and armour, which would look like.

saddle_horse horse-3(horse_grey,horse_black,horse_white_and_grey) + wooden_saddle-2(wooden_saddle_red,wooden_saddle_black)

meaning the saddle horse will either be grey, black or grey and white with a red or black saddle instead of just the same black horse.

I just wanted to say this out loud because I had been thinking it over and this felt like a good thread to discuss it.
I hope I'm not shifting the discussion too much as this is a brilliant solution to variable armour/clothing.

:ShaunRemo

 

[Slawomir of Aaarrghh]

Dresses on the screenshots in the opening post seem detailed enough for my (unprofessional I'll admit) eye. Theres a plenty vanilla items which look several times less detailed without any tableaus.

Well, it's 2014 and Warband's graphics are a little outdated comparing to other games... actually they were already outdated even when Warband came out. Native armors look like crap when compared to stuff from new mods (eg. Crusader, L'Aigle, Warhammer...). For you such dress is ok, for me and many players almost all native armors are just damn ugly now. And adding tableau materials will make them even more uglier.

Another big disadvantage of tableau material is that you can't really use multimeshes on your item, and many high-quality armors do that. I mean, you can use multimeshes, but they all have to use the same texture sheet, since when you apply color or texture via tableau materials, materials of all multimeshes get overwritten by the material you're applying with tableaus. So there's no way to make armors/items which use many textures to work with tableau materials.


But like I said, even though tableaus have some disadvantages, they are great in some situations. We use them in our mod for few things, like flags for flag bearers showing clan/personal banner, and even for few common armors, which have parts recoloured depending on which banner player have chosen. In singleplayer it could be used for town dwellers or even regular troops in some situations.

 

[Lav]

I haven't researched anything but it'd be nice to be able to force a new material or randomly select a new material for a mesh in the itemkinds1.txt something like

object_name mesh-(material)
        or
object_name mesh-5(material1,material2,material3,material4,material5)
for random materials on creation.

This shouldn't be a problem actually. If you want to randomize texture, you can do it within the tableau script. It is possible that the game caches the resulting tableau using it's ":instance_id" parameter, so all items with the same instance value will look the same even if randomized, but there are ways around this. If you want to randomize materials (i.e. apply a different bump/specular maps as well, not just texture) you will need a separate tableau definition for each of your materials, and pick one randomly from ti_on_init_item trigger (and each of those materials may further randomize it's selection of textures).

As well as this I speculated if it would be possible to reference multiple meshes in one object to create additional variance for example

object_name mesh1-2(material1A,material1B) + mesh2-2(material2A,material2B)
        or
green_shirt shirt-2(shirt_dark_green,shirt_light_green) + pants-2(pants_brown,pants_black)

so now 1 object can have multiple parts that are coloured separately and randomly...

This is probably impossible, see Slawomir's comments.

...allowing for things such as horses all referencing a base horse mesh that has multiple materials for colours and additional meshes can be added  to distinguishes them such as saddles and armour, which would look like.

saddle_horse horse-3(horse_grey,horse_black,horse_white_and_grey) + wooden_saddle-2(wooden_saddle_red,wooden_saddle_black)

meaning the saddle horse will either be grey, black or grey and white with a red or black saddle instead of just the same black horse.

Multipart retexturing is impossible with tableaus, and I'm not sure if it's possible to apply tableau materials to horses. It was definitely not possible awhile ago, but I'm not sure about the latest patch.

Well, it's 2014 and Warband's graphics are a little outdated comparing to other games... actually they were already outdated even when Warband came out. Native armors look like crap when compared to stuff from new mods (eg. Crusader, L'Aigle, Warhammer...). For you such dress is ok, for me and many players almost all native armors are just damn ugly now. And adding tableau materials will make them even more uglier.

Another big disadvantage of tableau material is that you can't really use multimeshes on your item, and many high-quality armors do that. I mean, you can use multimeshes, but they all have to use the same texture sheet, since when you apply color or texture via tableau materials, materials of all multimeshes get overwritten by the material you're applying with tableaus. So there's no way to make armors/items which use many textures to work with tableau materials.

Let's put it this way. I made a tool for someone with even amateurish knowledge of graphics (primarily myself, but hopefully some others) to mass-produce game items of adequate quality. Who really cares that more talented 3D artists will not use it? Definitely not me.

 

[Somebody]

The main problem with heraldic horses was, to the best of my knowledge, the order of calls within the various triggers. You are unable to load the actual banner from the agent from inside ti_on_init_item inside the module_items entry (because horses spawn as another agent). Retexturing might work but the normal/specular maps will suffer unless you randomize the tableaus.

I've also done a randomizing texture thing, but haven't gotten around to releasing it (need to convert the rest and find the original author). Instead of creating separate tableau entries I mask the banner entry and applies different overlays - this is for a shield item.

 

[Lav]

The main problem with heraldic horses was, to the best of my knowledge, the order of calls within the various triggers. You are unable to load the actual banner from the agent from inside ti_on_init_item inside the module_items entry (because horses spawn as another agent). Retexturing might work but the normal/specular maps will suffer unless you randomize the tableaus.

I've also done a randomizing texture thing, but haven't gotten around to releasing it (need to convert the rest and find the original author). Instead of creating separate tableau entries I mask the banner entry and applies different overlays - this is for a shield item.

Nice.

I'm currently playing with armors and clothing, haven't yet reached the stage where I need other items as well.

Re: horses, essentially without access to rider there's no easy way to detect party and thus identify the required banner. Something probably could be done with detecting entry_no used for horse spawning, but only for as long as no entry point is used by more than one party (which is not the case, and rewriting that code is an extremely complicated project).

Oh well, hopefully at least retexture will be possible.

Ahem. I wonder - is it possible to make a heraldic sword?

 

[Somebody]

Well people have done heraldic banners on lances - although I'm not quite sure what part of a sword needs heraldry.
As for horses and entry points, those found in randomly-generated battle scenes are really useless. I can imagine having a horse for each faction though and randomizing within an acceptable range of banners/emblems to put on the tableau.

 

[Slawomir of Aaarrghh]

The real problem with heraldic horses was that it worked fine only in inventory screen. On battlefield horses were no longer items, but agents, and there were no operation to apply tableau to an agent. Although, WSE made this possible and I believe there's an old topic with OPS heraldic horses somewhere in this parts of forum.

If 1.15x patches didn't change anything regarding horse agents and tableaus, creating heraldic/auto-recoloured horses without WSE is still not possible.

 

[cmpxchg8b]

Finally, there are also considerations of mod size and computer memory. A mod with a large number of retextured items can benefit a lot in these areas.

How so? Dynamically generated tableau textures are 32 bit uncompressed as opposed to regular DXT compressed textures. Assuming you load the latter on-demand, using tableaus should have a larger memory footprint.

 

[Lav]

How so? Dynamically generated tableau textures are 32 bit uncompressed as opposed to regular DXT compressed textures. Assuming you load the latter on-demand, using tableaus should have a larger memory footprint.

Whatever the format, in video memory all textures are uncompressed. Though tableaus are indeed going to put a higher load on normal memory.

So: less disk/download size, more memory usage, somewhat reduced quality, easier recoloring/retexturing, heraldry support with a modified script, capability of applying context-dependent overlays to item textures. Overall, still a decent package, though a bit less than I initially hoped.

 

[Swyter]

How so? Dynamically generated tableau textures are 32 bit uncompressed as opposed to regular DXT compressed textures. Assuming you load the latter on-demand, using tableaus should have a larger memory footprint.

Whatever the format, in video memory all textures are uncompressed. Though tableaus are indeed going to put a higher load on normal memory.

So: less disk/download size, more memory usage, somewhat reduced quality, easier recoloring/retexturing, heraldry support with a modified script, capability of applying context-dependent overlays to item textures. Overall, still a decent package, though a bit less than I initially hoped.

Not really. I don't like to be that guy, but GPUs are usually capable of storing DXT/S3TC compressed textures in their dedicated memory.

Let's see how costly is to store a standard 1024x1024px texture with alpha channel (RGBA) depending on the format used by your pipeline:

{Format}	{Compression ratio}	{Operation}	{Total bytes}	{Bytes per texel}
RGBA8	None (8 bits per channel)	Width * Height * Number of channels = 1024 * 1024 * 4	4,194,304 / 4 MiB	4
DXT5	4:1	Raw image size, above * compression ratio = 5,578,424.32 / 4	1,048,576 / 1 MiB	1
DXT1	6:1	Raw image size, above * compression ratio = 5,578,424.32 / 6	~929,737.386 / 0,87 MiB	~0.66

(Read on)

I like your method, it's pretty clever, and comes in handy instead of manually vertex color painting duplicated meshes. But I don't wan't people to end up confusing things.

Yes, texture compression is fundamental even nowadays, and yeah, DXT is pretty ****ty and outdated already. There are better formats out there getting natively implemented by newer GFX cards, but developers tend to fallback to the common denominator, for good reasons. One, can be tolerated, two, nobody is going to ship their textures in two different formats, third, more computers, more sales.

So, take care of your texture sizes, channels, formats and naming convention, kids!

*themoreyouknow.gif*

 

[Lav]

Not really. I don't like to be that guy, but GPUs are usually capable of storing DXT/S3TC compressed textures in their dedicated memory.

Perhaps, but does the GPU store and use the compressed texture, or it just stores it in compressed form in video memory, but decompresses when it's actually used on screen? Because I strongly suspect the latter. Not sure as I mostly deal with server programming and network interfaces rather than with video accelerators and 3D, but it makes sense to me.

(Read on)

Ah-ha. So essential point is this:
[quote author=Dark Photon]Yep, as -NiCo- said, this is the driver shuffling the texture from driver CPU memory into GPU memory for the first time. If you pre-compress your textures off-line to DXT1, making your textures 8X smaller, that's 8X less data for the driver to push over the PCIx bus, so much less likely to break frame.[/quote]
So the bottleneck is the texture transfer from CPU to GPU. This shouldn't be a problem for textures generated at the start of the mission, but might cause hiccups when a new texture has to be generated on the fly during the mission. How well does Warband cache it's generated tableau materials is also a question: if it's instance parameter is not used to cache the texture and subsequent uses of tableau material with the same instance result in re-generation and re-sending of texture, then active use of tableaus may indeed negatively affect the performance to a noticeable degree.

Oh well, suppose some more testing is in order.

 

[Swyter]

Not really. I don't like to be that guy, but GPUs are usually capable of storing DXT/S3TC compressed textures in their dedicated memory.

Perhaps, but does the GPU store and use the compressed texture, or it just stores it in compressed form in video memory, but decompresses when it's actually used on screen? Because I strongly suspect the latter. Not sure as I mostly deal with server programming and network interfaces rather than with video accelerators and 3D, but it makes sense to me.

Most of the textures loaded in the VRAM aren't used in the current frame, so, if they came compressed, they are stored compressed to save precious, precious space. Of course, when they are actually used they are temporally decoded on-the-fly, and cached for a bit, I suppose. Luckily the hardware decompression process is easy and fast.

Most people have a dedicated video memory of 512 MB - 1024MB. You can't really fit a lot of assets without some compression, specially in a game like M&B, which suffers constant "out of video memory", and "vertex buffer" problems.

So the bottleneck is the texture transfer from CPU to GPU. This shouldn't be a problem for textures generated at the start of the mission, but might cause hiccups when a new texture has to be generated on the fly during the mission. How well does Warband cache it's generated tableau materials is also a question: if it's instance parameter is not used to cache the texture and subsequent uses of tableau material with the same instance result in re-generation and re-sending of texture, then active use of tableaus may indeed negatively affect the performance to a noticeable degree.

Oh well, suppose some more testing is in order.

Only cmpxch8b can reply with certainty here. But if I know something about the M&B engine is that is not specially known for being famous with its groundbreaking optimizations. I hope to be wrong, given that tableaus are used all over the game.

 

[Lav]

Most of the textures loaded in the VRAM aren't used in the current frame, so, if they came compressed, they are stored compressed to save precious, precious space. Of course, when they are actually used they are temporally decoded on-the-fly, and cached for a bit, I suppose. Luckily the hardware decompression process is easy and fast.

Most people have a dedicated video memory of 512 MB - 1024MB. You can't really fit a lot of assets without some compression, specially in a game like M&B, which suffers constant "out of video memory", and "vertex buffer" problems.

Fair point.

Only cmpxch8b can reply with certainty here. But if I know something about the M&B engine is that is not specially known for being famous with its groundbreaking optimizations. I hope to be wrong, given that tableaus are used all over the game.

Actually, should be pretty easy to test by creating a custom tableau which produces different results each call (by using a global variable and changing it's value), and then calling it several times with the same instance value. Not something I can do right now in the office though.

 

[cmpxchg8b]

DXT is pretty ****ty and outdated already. There are better formats out there getting natively implemented by newer GFX cards

DXT/S3TC is still the compression format for most LDR image types, and I suspect it will be for quite some time until ASTC is widely supported.
Besides, it's not even that bad when used properly (like storing normals as green+alpha instead of rgb).

How well does Warband cache it's generated tableau materials is also a question: if it's instance parameter is not used to cache the texture and subsequent uses of tableau material with the same instance result in re-generation and re-sending of texture, then active use of tableaus may indeed negatively affect the performance to a noticeable degree.

It's cached by tableau material + tableau param.