关于革命性操作贴图变换模拟动图系统在骑砍里的综合应用

vegetto

1.材质贴图变换及动图系统的基本程序支持和原理详解


（1）装备系统item的贴图控制op 操作序号1978  #(cur_item_set_material, <string_no>, <sub_mesh_no>, [<lod_begin>], [<lod_end>]),  
#原英文注释比较潦草 Version 1.161+. Only call inside ti_on_init_item trigger. Replaces material that will be used to render the item mesh. Use 0 for <sub_mesh_no> to replace material for base mesh. LOD values are optional. If <lod_end> is used, it will not be loaded.
原注释意思就说只能在item的初始化trigger（ti_on_init_item trigger）使用，这样限制了item的贴图变换操作在按时间进程变换控制方面变得困难，下面另外场景物和界面系统的类似op操作不受这个限制，然后注意<sub_mesh_no>设-1代表整个模型，这里的use 0 for是指的是基础模型，也就是brf里模型名称pp.0 , pp.1，... , pp.15这种模型组合，认为第一个部分是基础，所以这个原始英文注释这样解释是很容易产生歧义的，下面另外两个系统的类似op操作就稍微讲的还行但不全面。所以接下来看我的补充。

#我的补充注释：在这里string_no的含义，其实写法不太对，看下面两个类似的贴图变换op操作用的是<string_register>是比较标准的，也就是这里写的应该是s21，s22这种形式的字符串而不是str_XXX这种。
首先在brf里这种模型分部mesh的材质的名称写在string的文件，假设材质名称为mac，对应贴图名称是jb,则如：
那么应该在string.PY注册("mjb", "mac"), 在txt里就是str_mjb mac，所以注意材质名称和贴图名称不要混淆，所有类似能控制贴图的op操作都是直接控制材质，我下面可能表示上会说什么什么是贴图变换操作，但是用的时候你们要直接看材质对应控制。

然后利用     (str_store_string, s21, "str_mjb"), 这种代码格式，必须得到s21这种形式的字符串来填入本操作的<string_no>，下面场景物界面系统类似操作同理 。
然后紧接(cur_item_set_material, s21, -1), 这种代码格式
其中-1是指的sub_mesh_no的数值，此时指的整个模型，sub_mesh_no可以取-1-9有效值，假设操作的模型对象是brf里模型名称为pp.0 , pp.1，... , pp.15这样的具有分部模型的组合模型，-1代表整个模型所有分部一起变成s21对应的str_mjb里字符串名称的材质对应的贴图，
然后sub_mesh_no取值0-9代表分部模型按照标的pp.0 , pp.1，... 的数字序号顺序一一对应，只变换对应序号的模型分部mesh的贴图。但是要注意，这种对应原则理论上是看序号排序，但是你处理模型的时候最好mesh分部序号从pp.0 , pp.1，... 开始从0加1依次编写，并且分部模型摆放顺序也是循序序号大小排列。
因为就像有的时候模型贴图在不同brf加载顺序不同导致白模一样，骑砍的读取系统比较灵异，你要是模型分部写成pp.1 , pp.3 , pp.5，就会发现读取混乱，或者这次正常下次改了其他模型又错位的情况。
此外为什么有效值上限是9，因为pp.10 , pp.11...这种开始，sub_mesh_no取10，11...不能读取分部更改模型。也就是分部mesh模型10个以内（即模型分部名称序号0-9的）的模型都可以调整任意分部的贴图，但是这个不影响具有分部mesh超过10个（即模型分部名称序号大于9的）模型整体利用sub_mesh_no取-1值来整体改变贴图,也不影响你只修改序号前10的分部mesh模型的贴图。
也就是说如果你的分部mesh模型超过10个，如pp.0 , pp.1，... , pp.15，你想要修改pp.15，则可以考虑将pp.0~9和pp.15的名称和位置对调，也就是尽量把有贴图变换需求的分部mesh模型在brf里名称序号和位置前置。
[<lod_begin>], [<lod_end>]是控制lod低模模型的，也是靠数字序号对应控制，只有item装备的这种op是提供控制lod的，你没有需求可以不写，凡是op是用[]中括号的参数都是可选，所以一般(cur_item_set_material, <string_no>, <sub_mesh_no>), 这样写也可以。

#代码实例：
string py注册：("mjb", "{reg31}"),然后在module_items py里搞这样一个装备

["basplayer2", "basplayer2", [("basplayer", 0)], itp_type_body_armor|itp_covers_legs|itp_doesnt_cover_hair|itp_can_penetrate_shield, 0, 532, weight(10.000000)|abundance(100)|difficulty(0)|head_armor(0)|body_armor(32)|leg_armor(12), imodbits_armor, [     
#这个是我的暴力篮球模组（https://bbs.mountblade.com.cn/thread-2069525-1-1.html）的篮球队员的篮球服装，有很多印了不同款式的同风格服装，所以模型外形一样但是贴图不一样进而有变换贴图省的做很多差不多的装备后再分配troop的繁琐过程

    (ti_on_init_item, [                                    #item的变换贴图操作只能在初始化      
        (str_store_string, s31, "str_mjb"),     #获取str_mjb里面的贴图名称赋予给s31这种贴图变换op需要调用的字符串形式
        (assign, reg31, 10002),                        
#首先10002你们可能会懵逼，其实这个就是贴图的材质名称就叫“10002” ，为什么这么做，如果将str_mjb写成("mjb", "{reg31}"),的形式，那么reg31令为10002时，str_mjb代表的字符串名称就是10002可以用此操作控制到名称为10002的贴图，然后reg31可以进行代数运算，实时改变取值进而改变str_mjb，然后我们构造一个时间进程控制reg31的取值随时间条件变换，就可以将我们控制的贴图随心所欲达到动图变换程度，但是这对下面界面和场景物用处多一点，对于只能初始化执行的item，还要进行曲线救国的其他加工。

        (cur_item_set_material, s31, -1),     #整个球员衣服的贴图变成s31对应的str_mjb里面字符串名称对应的材质名称对应的贴图，为什么没有像下面两个系统一样对对象id，就是因为用于初始化，对象id默认初始化的对象 itm_basplayer2
~~~~~~~~
代码实例概述引申：通过贴图变换可以类似之前的可变材质纹章用法，在避免重复做模型外形风格相同但是材质贴图不一样的多个模型装备再注册分配兵种的环节，直接在装备的初始化环节判断各种条件自动调用合适的贴图。
此外可以联系一下(cur_item_add_mesh, <mesh_name_string>, [<lod_begin>], [<lod_end>]),的用法，
这种也是在装备初始化触发代码，给模型附着一个部件，可以是绑定骨骼动画也可以不绑定，这样我们比如可以没有护肩的衣服加一个护肩组合，这种就是有些人所谓女王之刃mod的变革，其实2015年就可以操作并有item类这种操作初步教程了，你们天天不看header 文件特别是operation和注释，都发现别人写了冷门op不翻注释还是选择在群里瞎问怎么有发现和提高呢。
而item这两种对模型分部mesh进行操作的op，灵活运用可以做很多事情，也可以互相补充，比如说，两个op在某些地方有一些可以等效的手段，假设一个装备模型要做没有护肩的衣服和护肩组合，思路上对于本系列操作有两个方法；
i）假设没有护肩的衣服是一个模型a，护肩是一个模型b，那么通过衣服初始化代码利用条件判断是否cur_item_add_mesh把护肩作为mesh加上即可
ii）预先做出所有的可能再利用透明无形贴图来控制分部模型的影身消失，即把衣服主体mesh模型为pp.0对应贴图为10001，护肩风格1mesh模型为pp.1对应贴图为10002，护肩风格2mesh模型为pp.2对应贴图为10003，一个具有完全透明的贴图的材质名称叫10000，， 仍然用 (str_store_string, s31, "str_mjb"), 存取("mjb", "{reg31}"),这个string。
则通过衣服初始化代码利用条件判断，假设护肩1显示的条件是全局$aaa为0，护肩2显示的条件是不为0，下面代码实例的item装备定义和初始化的trigger就省略了，你们心中要有，
      (str_store_string, s31, "str_mjb"),   
        (assign, reg31, 10001),  
       (cur_item_set_material, s31, 0),  #强制衣服主体采用10001材质名称的原始贴图，如果不涉及到衣服主体的贴图改变和隐形显示控制需求可不写
       (try_begin),
           (eq, "$aaa", 0),
           (assign, reg31, 10002),  
           (cur_item_set_material, s31, 1),  #护肩1采用10002材质名称的原始贴图

           (assign, reg31, 10000),  
           (cur_item_set_material, s31, 2),  #护肩2采用10000材质名称的透明贴图，导致本模型影身

        (else_try),
           (assign, reg31, 10000),  
           (cur_item_set_material, s31, 1),   #护肩1采用10000材质名称的透明贴图，导致本模型影身

           (assign, reg31, 10003),  
           (cur_item_set_material, s31, 2),    #护肩2采用10003材质名称的原始贴图


        (try_end),


--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
（2） 场景物系统sceneprop的贴图控制op 操作序号2617  # (prop_instance_set_material, <prop_instance_no>, <sub_mesh_no>, <string_register>),
#原英文注释比较潦草 Version 1.161+. 4research. give sub mesh as -1 to change all meshes' materials.就和你讲-1是改变所有分部mesh模型的材质贴图，然后凡是原有注释写了4research，说明写注释这个人本身就是懵逼一知半解的剩下一概不知的，


#我的补充注释：道理和item的贴图控制op差不多，注意场景物的这种op<sub_mesh_no>, <string_register>参数和item的这两个参数<string_no>, <sub_mesh_no>，位置是相反的，不要看走眼。
然后<string_register>参数写法用的很标准，就是 像我上面item系统里讲的一样用(str_store_string, s21, "str_mjb"),得到s21这种形式的字符串，才能正常调用模型的材质进而控制贴图。再次强调，材质名称才是控制对象，贴图名称不是。
<prop_instance_no>就是场景物的实例id，也就是利用 (scene_prop_get_instance, <destination>, <scene_prop_id>, <instance_no>),这种操作得到的<destination>变量（一般局部变量形式），而不是spr_XXX这种东西。
<sub_mesh_no>参数就是我上面item装备的类似系统说的，模型对象是pp.0 , pp.1，... , pp.15这样的具有分部模型的组合模型，则取值对应0，1，2，。。。9，特别的，-1代表控制整个模型所有分部一起变换材质贴图，超过9的序号的分部mesh模型不能直接控制分部，此时考虑所有贴图合并一张，或者把有控制贴图需求的分部mesh位置和名称在brf前置到0-9的位置。

代码实例举例：
下面是我的龙珠mod（https://bbs.mountblade.com.cn/thread-2067435-1-1.html)的利用动图系统做战斗场景的海面水纹效果的用法，其实在这里运用不太好，因为水面太大，对每一张贴图的精细度有较高要求，我贴图做的比较糊但是因为我是二次元mod所以可以降低标准。

你们主要看用法。

首先string py注册：("talknum", "{reg22}"),  #类似格式即可，具体reg xxx是和你下面代码控制时你想填多少有关，你自己把握，别reg冲突即可。


以下是我的script py里的dbzwatertex脚本，后面在需要的module_mission_templates py会以0，05000，0，00000，0，00000，类似的条件调用。

("dbzwatertex",
[
    (get_player_agent_no, ":var_0"),
    (this_or_next|eq, "$scnow", "spr_kais"),
    (this_or_next|eq, "$scnow", "spr_northhw"),
    (this_or_next|eq, "$scnow", "spr_maproshi"),
    (this_or_next|eq, "$scnow", "spr_kamehouse"),
    (this_or_next|eq, "$scnow", "spr_namek"),
    (this_or_next|eq, "$scnow", "spr_cellgame"),
    (this_or_next|eq, "$scnow", "spr_frostland"),
    (this_or_next|eq, "$scnow", "spr_DarkIslands"),
    (this_or_next|eq, "$scnow", "spr_lastland"),
    (eq, "$scnow", "spr_mapbabadi"),                                   
#以上表示scnow这个全局变量如果是上面这些spr id的场景物模型，我的龙珠整个大场景是一整块场景物模型，所以这一步是判断哪些场景用了动图变换机制的海水面，而这些需要水面的战斗场景场景物我把他们分部模型的第一个均设置为水面，比如spr_lastland对应分部mesh模型lastland.0,lastland.1,...lastland.30,那么我的lastland.0就是水面。
    (scene_prop_get_instance, ":var_1", "$scnow", 0),
    (agent_get_slot, ":var_2", ":var_0", 602),                          #玩家的第602号slot代表贴图变换的时间进程控制，以其值随时间的变化来控制贴图随时间的变换形成动图、
    (try_begin),
        (is_between, ":var_2", 60001, 60173),                  #我的水面的动图分解成序列帧图片后，利用插件将贴图批量命名为60001-60173，导入brf后如果不自行修改，材质名称应该和贴图命名相同。
        (val_add, ":var_2", 1),                                        #根据mt调用时的trigger间隔决定播放速度，也可以mt条件为0，0，0条件，另外起一个变量控制时间变化，作为条件限制602slot的加1环节
        (agent_set_slot, ":var_0", 602, ":var_2"),
    (else_try),
        (assign, ":var_2", 60001),                                
        (agent_set_slot, ":var_0", 602, 60001),               #意思是超过 （ 60001, 60173)    这种贴图材质名称的区间，则重置到序列帧图片第一帧，即60001这个材质名称的贴图。这样形成一个循环
    (try_end),
    (try_begin),
        (assign, reg22, ":var_2"),                              #令reg22值为slot602的值，也就是把随时间变化的贴图材质名称赋予reg22
        (str_store_string, s22, "str_talknum"),          #贴图控制必须得到s22这种字符串形式，后面不再提醒，记住这一步不要省略
        (2617, ":var_1", 0, s22),                         #2617就是贴图变换的op操作序号，我txt做mod习惯简写，下面要举例还是可能简写，稍微留意下。":var_1"就是上面一堆this ornext 条件筛选出的有水面的战斗场景场景物实例id，参数0就是指控制sub mesh序号为0的模型分部（注意代码序号都是从0开始）,s22便是随时间变换的贴图材质。
    (try_end),

代码实例概述引申：所以说，上面通过将贴图材质名称利用字符串的{reg22}写法可以进行reg的代数运算来只注册一次str，就可以把成千上万的贴图材质进行名称获取，然后带入到2617这个op操作里进行控制，通过字符串里reg值的时间进程控制，进而使得贴图也随时间进程控制。
所谓动图，其实就是若干连续有逻辑联系的序列帧图片在一定时间慢慢切换显示和条件切其他序列的一套帧图片或循环播放或放完留在尾帧终止，所以通过此法可以实现动图效果，这个也就是我的拳皇模组的理论来源，我的拳皇模组运用的最多，不仅仅是动态的2d人，还有人物动态头衔和艺术字以及特效类。可以用的地方很多，但是滥用很耗性能，自己斟酌。
2D拳皇mod但是骑砍战团引擎
https://bbs.mountblade.com.cn/thread-2067594-1-1.html
(出处: 骑马与砍杀中文站论坛)
我txt做东西没有源码，你们可以反编译看看，然后看看我的贴图名称排序的布局。【这个作品也是为我的一个设想铺路，将骑砍战团的修改dlc化，兵种以及阵营场景物等等都有一个对应的文件记录id，排序就像表格一样。但是贴图是杂乱无章丢在一个文件夹的，所以我考虑将所有贴图的名称进行数字序列化，比如0-10000给对话系统。10001-20000给头衔，30000-40000给装备，并做好表格记录，预留位置但暂时不填充满，做远期规划，那么后期需要进行贴图变换使用时，所有贴图都能通过字符串的reg关联在一起，将贴图互通起来，这样我们的贴图素材不仅方便管理，和代码调用系统化，后期玩家换皮做子mod时也可以系统替换素材。这就是为什么骑砍战团做不了一个对象一个对象的dlc安装，像很多游戏就是将一个对象的贴图脚本动画模型进行打包到一个文件夹，而我们是全部分解摊开。如果我们进行一种隐性的人为划分，比如角色装备的贴图在30000-40000，每个人预留10张贴图，如果1号角色装备30000-30010，可以允许你不用完，或者以8x8的小贴图占位，然后代码上将我们觉得玩家希望修改的参数特别是循环的对象id范围甚至是可以屏蔽概念的参数全部提取出来集中在一起写一个只改set slot化参数数值的列表式代码，给我们提高每个参数的含义使用场合和工具，进行个性化修改，并且对相同事件多预留几个空脚本。这样假设我们后期还是有加强版战团的这种综合前人成果的mod出来，采用这种代码和素材上进行空位预留和系统化排序化命名的素材，就可以一劳永逸，让子mod的玩家们只要做素材替换的换皮工作和集中改一个集中定义参数的部分。】
以上【】内一家之言，对于苟延残喘的战团来说，已经很难再需要系统化变革了。

此外对于场景物的贴图变换操作，可以类比我上面装备类的，可以通过一个完全透明的贴图设置，来控制模型的局部部位消失，这个例子我可以讲讲我的龙珠变身系统结合讲讲，我的龙珠人物首先它是顶点动画的场景物性质，所以对于贝吉塔这种模型甚至发型模型外形不变的，进行超级赛亚人变身就可以采用对贝吉塔模型的头发和眉毛所在分部mesh进行贴图材质变换，从黑色变成黄色等等。而对于卡卡罗特孙悟空这种变身发型改变的，可以给卡卡罗特准备两个头，一个是常态发型，一个是变身发型，然后根据变身条件一个使用原本贴图，一个采用全透明通道贴图。
而对于沙鲁弗利沙这种完全三个形态变的很大的，可以直接每个形态合并贴图，然后把每个形态作为一个模型的分部mesh，根据变身条件哪一个采用默认贴图，其他形态分部mesh采用全透明通道贴图。
这么做的好处就是，首先你的module_scene_props py和brf里不用考虑把需要局部变异的模型拆分注册成两个以上的不同对象，其次如果是分部组合进行运动，由于animate 运动场景物的性能消耗，当掉帧严重时，模型容易散架，所以说多个重合组合运动的模型，能注册成一个对象则尽量，拆分多个实质id的对象则不利于稳定控制。


--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
（3）presentation界面系统overlay图标控件的贴图控制op 操作序号956  # (overlay_set_material, <overlay_id>, <string_no>),

# 原英文注释比较潦草 Version 1.161+. Replaces the material used for rendering specified overlay.这个比item系统的注释说的还潦草。

#我的补充注释：道理还是和上面其他系统类似操作差不多，不过你们会发现没有<sub_mesh_no>这种控制模型分部的参数。


所以再次强调两个基础的概念，
首先i）在骑砍这个游戏能够直接控制的对象一定是调用了模型的素材，而不是材质贴图，模型是材质贴图的播放器，材质贴图不能脱离模型存在，哪怕是presentation说可以直接显示material材质的overlay操作，你仔细看着注释，人家讲的是系统自动生成一个mesh模型去呈现这个材质贴图。
ii）对于骑砍来说，有些对象调用模型的方式是整个model模型，但是有些是调用mesh，mesh和model的区别就是，mesh是model一个基本单元，所以组合模型共用一个模型名称时，分部在骑砍叫mesh。而大地图和界面图标调用的就是这种mesh，所以他们是不配有分部模型的，调用名称为pp的模型，你brf只有pp.0，就无模型调用，你有两个pp，看引擎读取模型的顺序只读一个。
所以，界面图标的贴图材质控制操作，只控制一个单体的mesh。<overlay_id>参数就是create_mesh_overlay  /  create_button_overlay   /   (create_game_button_overlay, <destination>, <string_id>),。。。    这一类很多的创建overlay后得到对象<destination>参数，多以全局和reg形式表示。

具体用法可以类比参考上面其他系统的，书写格式上还是大同小异：
        (create_mesh_overlay, "$vokesk1", "mesh_vokesk1"),
        (position_set_x, pos1, 640),
        (position_set_y, pos1, 75),

        (overlay_set_position, "$vokesk1", pos1),          #以上如果在presentation里是load 环节，则会有上面类似的写法，具体create创建的overlay图标种类的op有很多比较灵活。

            (assign, reg21, ":var_31"),                          #以下如果在presentation里是run环节，上面create环节就不需要了，按条件走这三步格式进行界面图案的贴图图像控制，956是贴图控制op的操作号简写
            (str_store_string, s21, "str_mjb"),
            (956, "$vokesk1", s21),

也是类似这种格式，这三个系统贴图控制的基本格式总结就是，str_store_string不可少，紧接就是贴图控制op，需要持续动态控制注册reg形式的字符串str然后对reg取值进行一系列的条件控制。

由于时间原因关于界面里这类功能系统暂先不举具体例子，只讲一些经验：
i)用法看我装备和场景物写的东西和思路举一反三；
ii)建议动态持续多张图切换控制，将贴图批量序列数字化命名，并做好excel表格笔记记录贴图数字区间划分的含义用途做好合理规划和远期预留；

iii)你们很多人之前处理界面图标需要变化的操作会用改变色彩明暗大小这些可以直接用同一个overlay id实时run中操作，但是遇到图案直接变的，你们却大多选择一起加载、隐形一部分或重启加载的方式，并且多注册了mesh id，而且造成代码的臃肿，和反复启动presentation带来的潜在的数据传输不及时的错误情形，
所以利用贴图变换的思路，我们不仅可以节省代码资源，还可以做很多动态的效果。
比如血条旁边的人物头像可以采用动态3d显示的，血条蓝条你们很多人考虑采用overlay的放缩op操作来表示增减，但是也可以做出那种环形的，dnf的那些圆形容器的血条，甚至是从绿幕素材扣除带荧光光效围绕血条动态闪烁的血条变换风格。
像比如我的飞檐走壁模组就采用这种方式做拳皇那种带底槽的，并且打击后血条变化时血条的贴图和槽子的底图有流光变化的血条。

所以灵活使用材质贴图变化功能，可以让骑砍做更多令人瞠目结舌的神奇操作，焕发第二春。



---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------


后续有时间继续补充我的一些实例

vegetto

正文是主要是代码知识，然后这种要用的灵活，在美术素材方面你们要掌握贴图批量化处理技术，这个可不是一个个处理过来的。批量命名，批量格式转换，视频动图转换，视频动图分解，动图视频批量抠图，视频直接转带通道动图，图片批量裁剪调滤镜等细节，绿幕素材制作和抠图，分部贴图UV的快速拆分和组合，等等等等，接下来如果看不到你们积极的态度，一些配套的批处理素材方法，我暂时就不多教了（我有一套小白适用的快捷工具）。

总之代码和模型方法要结合才能让功能进一步突破。当你局限在其中一个时候，就会空有模型却不知道游戏是否有能力运行盘活它而曰之不可能实现，就会空有代码思路但不知道你的素材如何搞定和适配这个游戏正确放进来而曰之不可能实现。

vegetto

实例1：
关于不规则型、特效流光型特殊的玩家游戏血条能量条的实现手段（模型+程序）
https://bbs.mountblade.com.cn/thread-2098924-1-1.html
(出处: 骑马与砍杀中文站论坛)

传说的骑士

这倒是让我发散是否可以借助材质变换实现场景中实时的盔甲状态表现？实现爆衣效果？另外吐槽一下万恶的装备锻造系统cur_item_add_mesh总是要处理一大堆字符串

cqq888888

想问一下大佬,有什么办法可以获取 游戏内的鼠标信息

战争傀儡阿格兰

太太太神奇了！这个{reg31}！我按照你的写法，改了下原来代码，减少了大量string设置，而且切换贴图也大获成功！真的是革命性的操作！大革命！技术领先其余所有人一个时代！来自: Android客户端