MSFS20 Help required for a Script Python to migrate all material included in a .blend file

[Lagaffe]

Hello,
Last June, I migrated one of my projects from Blender 2.83 to Blender 3.6.18.
After a few failed attempts, I decided to delete my 34 materials and then recreate them one by one in the new file. The manipulation was a bit long but in two hours I could dispose of my new operational file.

Currently, I am on another project but it includes 6 Canso PBY aircraft, so 6 Blender files with almost 100 materials in each file.
I thought of doing the manipulation on one of the files then saving it then deleting all the materials from the 5 other files with a Python script and then importing the new materials into each remaining blender file.

Saying that, I just thought of another method that would be much more interesting and could troubleshoot other developers.
The idea would be to open an old Blender file in a recent version of Blender with a recent plugin and then by Python script to validate the "Migrate Material Data" button automatically for each hardware found in the Blender file.

The script written by SAL1800 to suppress any material can be a staring point:

# Removal of all materials
import bpy

#Management of the list of primitives
primitives_types = {"MESH", "CURVE", "SURFACE", "META", "FONT"}

for obj in bpy.data.objects:
if obj.type in primitives_types:
obj.data.materials.clear()

Studing the contents of msfs_material_panel.py included in the last MSFS Export plugin (v1.3.3) , I have found that it is the procedure "msfs.migrate_material_data()" which is associated with the button "Migrate Material Data" via the interface.

Mixing the two scripts should produce the aim attented but how to do this ?
Does anyone have an idea?

 

[ronh]

The problem with migrating old material is that the node structure of older exporter (ASOBO and Vitus one) is not the same. So a lot of guessing is involved.
You are welcome to use my exporter for 2020 as I have modified the migrate button to work a lot better. It's not 100% accurate but works for me.

Doing an automatic loop through materials does not allow you to do a check on each material. I know 100 materials and 6 blend files it's a lot of work.

You must do a compare of how it renders in blender to see if it worked. then undo - copy any data that did not get transferred and migrate again and input the data manually.

 

[Lagaffe]

Thanks for your answer, Ron.

Yesterday, with ChatGPT I have succeed to create a loop in Python to list all the MSFS materials in my test blender file but I then stumble on the procedure to call as well as the arguments to provide him ...
Today, after your response, I carefully compared the Asobo code v1.3.3 and yours in version 1.6.12 and indeed you have improved it significantly .

I was planning to migrate my projects to Blender 3.6 but I think it will be a waste of time in the short term so the best would be to use the latest version of the Blender 4.2 branch with one of your last plugin 2.2.20 or 2.2.21.

As my 6 blender files share a lot of objects and all MSFS materials, I go to migrate manually my test file and see after that if I can import the new materials in the others files.

 

[ronh]

My exporter should work in 3.6 and 4.2 and 4.5 - (but not fully tested in 4.5)

You should be able to bring in all your materials from the other blend files by using "file - append" menu (I have not tried this). Then you will need to assign them to the meshes. But this is still a very labour intensive task.

Maybe there is a python API for append.

EDIT: Ok I just tested brining in materials from another blend file. this seems to work. However you will need to add a "fake user" to each one or blender will delete the materials not assigned to meshes or "users" as part of the save process - note the zeros next to the materials in the material drop down.

blender API append

Append Materials Using Python

Trying to append a material from one blend file to another but not having any luck. I've tried two methods so far. Method 1: bpy.ops.wm.append( filepath="material.blend", directory=&

blender.stackexchange.com

How can I import materials from another blender file with python?

I have many files containing different parts of my blender internal material collection. How can I make a script which imports all of them into another blend file?

blender.stackexchange.com

 

[Lagaffe]

Yes, I have indeed been using this function "File - append" for many months, from 2.83 to 3.6, and it has always worked very well, I cannot complain about it.
To append several material I select them in the gui with the mouse and they are transferred without problem.
I have choose Blender 4.2 because I use also this version with PBR Painter which is very useful (I know that you use also it - Discord).

Currently, I updated my library of plugins but I’m a bit lost ...
I indeed have all your plugins up to version 2.2.21 but I also saw that y-khodja put the Official plugin in 3.3.0 and even in 3.3.1 so I don’t know which one to choose anymore.

Should we understand that the functions of 2.2.21 are included in 3.3.1 or is it two separate branches?

PS: In your plugin 2.2.21, I note:
- _init_.py and blender_manifest.toml make reference to the version 2.2.20 and not 2.2.21

Also I took the liberty of changing the name of the button in "msfs_material_panel.py" to MSFS2020 Material Param to avoid certain confusions that I often make with a button with the same name in another plugin (2 precautions are better than one)

 

[ronh]

my plug-in has the better migration function - ASOBO will be removing theirs. Also they updated the 2020 one for Blender 4.5 plus some other bug fixes, some I have already fixed.

I tried to merge some of their fixes. 3.3.0 had a bug - so 3.3.1 is the better one from ASOBO.

I suggest you use mine to migrate (perhaps with 3.6) and then use ASOBOs to work with after migration in 4.2

A jump from 2.z to 4.x might be too much for Blender and Khronos/ASOBO to handle.

 

[Lagaffe]

Hi,

It’s a big proposal insofar as I was planning to delete my old versions 2.83 and 2.93.9 to keep only:
- Blender 3.3.3 for the FBW plugin (MamuDesign package that can be find in FSDeveloper's pages)
- Blender 3.6.23 LTS / plugin 1.6.14 for imports and maintaining the Aeronca that was made with this version and with which I perfected my textures of windshield and ice formation on the wings
- Blender 4.2.15 LTS / plugin 3.3.1 for upcoming projects (which will avoid difficult migrations). I tested it yesterday with success on this version

PS: Am I right to think that yours plugins 2.2.x branch are rather intented for the Blender 4.2 structure ? or is version 2.2.21 very well usable in Blender 3.6 ? I compared the two plugins structure ... and they have the same number of folders and files, so ...
That’s what I understood by rereading the old posts : https://www.fsdeveloper.com/forum/t...l-blender-exporter.454146/page-11#post-927230

For this project which is none other than the CANSO PBY-5A/6A pack, 95% of the modeling has already been carried out and works perfectly.
I just have to integrate the new windshield textures and the ice on the wings, plus a few small things like the brake hoses that I forgot to model.
I also plan to redo all the exterior and interior textures with +

Now using exclusively PBR Painter for the creation of textures, the version 4.2 is ideal for this.
After a few hours spent trying to master the tool, I managed to achieve all the PBR tasks of the Aeronca with this tool that I strongly recommend

Therefore, this workflow seems perfectly suited to me, thank you again Ron.

After that, it will be necessary to begin to study with attention the 2024 SDK and try to migrate projects on this new platform but not before the release of SU4 which would have at IMO be the version initially proposed in Oct 24.

 

[Lagaffe]

At the end of my reflections, given that I believe I have found everything necessary for this important migration, I wanted to share the result of my research with you.

In fact with a little patience, the passage of a test model under Blender 3.6 with plugin 1.6.14 from RonH, the migration and then the verification of 101 materials was faster than expected: 1/2 hour. In order to differentiate these new materials, I have renamed them all into Z_*_* so as to be able to differentiate them very easily from the old ones *_* [Step 1]

This morning in search of other avenues for automation, I found two new gems.
- First ActionRecorder (v4.1.2 - https://github.com/InamuraJIN/ActionRecorder ) a plugin intended for older versions of Blender but works perfectly under Blender 3.6 and Blender 4.2. Its purpose is once activated to memorize the different actions made by the user then to save them and be able to replay them. In addition, it allows saving the recorded actions (to be investigated because if we can use them to create scripts ... )
- The Material Utilities plugin, which is not activated by default but which once installed allows you to make a material active and then select all the objects that have this same material.

Now the next step is to load into Blender, one by one the remaining 5 files and then import all the Z_*_* materials.
Once loaded, I think of activating a material, then via the Material Utilities to select all the affected objects of this material and finally to assign them the same material but suffixed by Z_*_* and finally to superimpose the old material.
Remains to do all this for the 101 materials of the 5 files ....

Thanks to RonH, who help me a lot on this big work.

 

[ronh]

These add-ons are a good find. thanks for reporting on these. So many things to keep learning in Blender.

Glad it has all worked out for you.

My exporter version were developed for 3.6 and 4.2 separately, however the 4.2 version, should have code that makes it work in 3.6 - I think. Not to many people use my version, so I don't have many giving me any error reports. So I assume it works ... LOL

ASOBO has done a good job now with 2020 and 2024. Still waiting for the 2024 one to work in Blender 4.5. Hopefully soon - maybe SU4.

 

[Lagaffe]

Migration continuing ...

While trying to validate the first step of the process (see my post #8 [Step 1] ), I maded two compilations, I had two bad surprises.
A) just after the Step 1, I tried a compilation in Blender 3.6 and the plugin 1.6.14

I used the default parameters of the plugin for the compilation (Blender 3.6)
After the fspackagetools compilation, i noted just some warning like this:

Compiling GLTF data file PBY5_BlackCat_Int_LOD00.gltf...
Invalid alphaMode, defaulting to OPAQUE | alphaMode: DITHER
Material[21] ('Z_Cockpit') is used by mesh[916], and has textures, but it doesn't have any UVs.

This seems indicated that modifications are needed for some material.

During the migration under Blender 3.6, sometimes I got 2 extra buttons on top of the "Migrate Material Data". For these materials, I clicked the 3 buttons each time (from top to bottom)...
I have read the plugin documentation but perhaps I didn't understand all the advices

Did I make a mistake?

B) the Blender file used in A) was loaded in Blender 4.2 and 3.3.0 Asobo’s plugin but I got a lot of errors in Blender during compilation for each LOD.
The size of the file has been reduced from 34 658 ko to 30 331 ko after just one edition in Blender 4.2. Would be an incompatibility with one of my installed plugins ... I will redo the test tomorrow with a raw version of 4.2

20:19:16 | WARNING: Multiple rotation mode detected for train_R_sup_bas
[glTFImporter] Multiple rotation mode detected for train_R_sup_bas
20:19:19 | WARNING: Multiple rotation mode detected for Fusee_L
[glTFImporter] Multiple rotation mode detected for Fusee_L
Traceback (most recent call last):
File "Z:\Prg\blender-4.2.x\4.2\scripts\addons_core\io_scene_gltf2\__init__.py", line 1315, in execute
res = gltf2_blender_export.save(context, export_settings)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "Z:\Prg\blender-4.2.x\4.2\scripts\addons_core\io_scene_gltf2\blender\exp\gltf2_blender_export.py", line 37, in save
json, buffer = __export(export_settings)
^^^^^^^^^^^^^^^^^^^^^^^^^
File "Z:\Prg\blender-4.2.x\4.2\scripts\addons_core\io_scene_gltf2\blender\exp\gltf2_blender_export.py", line 55, in __export
__gather_gltf(exporter, export_settings)
File "Z:\Prg\blender-4.2.x\4.2\scripts\addons_core\io_scene_gltf2\blender\exp\gltf2_blender_export.py", line 202, in __gather_gltf
active_scene_idx, scenes, animations = gltf2_blender_gather.gather_gltf2(export_settings)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "Z:\Prg\blender-4.2.x\4.2\scripts\addons_core\io_scene_gltf2\blender\exp\gltf2_blender_gather.py", line 35, in gather_gltf2
animations += gather_animations(export_settings)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "Z:\Prg\blender-4.2.x\4.2\scripts\addons_core\io_scene_gltf2\blender\exp\animation\gltf2_blender_gather_animations.py", line 22, in gather_animations
return gather_tracks_animations(export_settings)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "Z:\Prg\blender-4.2.x\4.2\scripts\addons_core\io_scene_gltf2\blender\exp\animation\gltf2_blender_gather_tracks.py", line 36, in gather_tracks_animations
animations_, merged_tracks = gather_track_animations(obj_uuid, merged_tracks, len(animations), export_settings)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "Z:\Prg\blender-4.2.x\4.2\scripts\addons_core\io_scene_gltf2\blender\exp\animation\gltf2_blender_gather_tracks.py", line 111, in gather_track_animations
blender_object.animation_data.action = None
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: bpy_struct: attribute "action" from "AnimData" is read-only
[ActionRecorder] Uncaught exception

 

[ronh]

A - you are missing UV mapping for that mesh

B- there is a multiple rotation on that animation. on Fusee_L and train_R_sup_bas

these are Blender/Khronos errors that you must fix.

EDIT - yes you do them top to bottom.

EDIT - these come up if there are materials from legacy exporters like Vitus or early ASOBO ones - Perhaps Fly by wire imports also.

EDIT - reset gltf settings means there are numerous gltfSetting nodes and there should only be one - it removes and reassigns them

pre migrate means that legacy exporters were used by those materials - old nodes - if you review them they will look different from more later exporters node structure.

migrate - is the regular migrate you know.

So, what is happening is it makes a guess about what node to translate to later node structures, pre migrate to make the migration easier - but it is not always accurate - you will need to do these ones manually if they look wrong after migration. (just undo till you get back to original old materials)