MSFS Blender2MSFS Limitation? Color Multipliers

[Mikea.at]

i dont know if that was a problem but i noticed, that the "collision" tag got exported differently to the "road" materials tag. i fixed that in this version.
was the collision property allready working correct?

 

[dale in cda]

Hey Mike,
Thanks for the work.
These guys are reporting it is not working (older version)

https://fsdeveloper.com/forum/threads/collision-meshes-for-aircraft-blender2msfs.452758/#post-885339

 

[fabs79]

Thank you so much for your continuing support of the Blender2MSFS Toolkit, that´s highly appreciated. After you enabled the color multipliers to work correctly I was able to significantly reduce the number of textures and overall filesize of my sceneries. I didn´t use collision materials yet but I´m sure many will appreciate this update.
Do you know if the Toolkit also works in Blender 2.93? I´m still using 2.83 but the 2.9x releases have some new features I´d like to check, provided the toolkit still works with that version

 

[clements]

@fabs79, I use it with 2.93 and have with previous 2.90 releases without a problem.

 

[fabs79]

@fabs79, I use it with 2.93 and have with previous 2.90 releases without a problem.

Great, Thank you!

 

[Luicid]

Hey @Mikea.at ,
I was working on it but I saw your version for the collision and tested it.. it works perfectly ! Thanks a lot ! I'll be happy to pay you a "paypal" beer if you tell me your infos

 

[Mikea.at]

thanks but that is not necessary hacking a little bit around in python without any knowledge was fun. dont expect further improvements i am not really able to bring this tool to a professional level
maybe it is possible to merge my improvements into the github project from @tml maybe he can merge my changes into his github project?

 

[tml]

maybe it is possible to merge my improvements into the github project from @tml maybe he can merge my changes into his github project?

I merged the "Road" change between your 0.42.2.5 and 0.42.2.6. I did not include what you did in your 0.42.2.5, are all the changes in that (compared to the original 0.40.0) for the same thing? Could you summarise what the changes do, for the commit log?

 

[Pyscen]

@tml...

If you would please, paste the link of the GitHub project for Blender2MSFS.

 

[Mikea.at]

https://github.com/tml1024/Blender2MSFS2
I try to write everything together what i did. Its long ago i hope i can recognize everything

 

[ZdenniZ]

Now there is hope!

 

[Mikea.at]

Who is that person?

 

[ZdenniZ]

Who is that person?

That's Asobo's SDK production supervisor, if I remember the position correctly. The girl who was part of the SDK Q&As.

 

[Luicid]

Yup her name is Alyzée, she made a quick tutorial too about vfx
They are some devs of Asobo who reply our questions on https://devsupport.flightsimulator.com/
They are very cool people and really try to help us (dev) when we have some issues

Also , when I saw that they wish to provide a blender extension I was like a 10 years old at Christmas
There is hope guys !!

 

[PhysicsTeacher]

Mikea.at, thanks for everything. I'm still working on the LOD batch bug, and you will be the first to hear about it if I get somewhere. I'm using your .5 now, and will try .6 this afternoon so I can land on my bridges. I'm working with 2.93 with no problems.
There is some glitch going on when I try to Remove the exporter: installing a new one simply adds another "extended GLtf .." line to my export menu. I had to delete all Blender installs and start over, but that fixed the problem for now. I won't spend any time on it, however.
Can't wait for Asobo to bring good news.

 

[Mikea.at]

@PhysicsTeacher please can you work in this github repo? it includes all my fixes

GitHub - tml1024/Blender2MSFS2: Obsolete Open Source adoption of Blender2MSFS which apparently had been left in limbo by its author

Obsolete Open Source adoption of Blender2MSFS which apparently had been left in limbo by its author - tml1024/Blender2MSFS2

github.com

 

[PhysicsTeacher]

Absolutely! I was working in your .5, then I looked for the .6, but I had lost the link to this one. Downloading and installing now.
There's one index at the very end in the .glTF files above LOD00, and that link should be to a byte offset in the .bin. So far it looks like it's something to do with a call to the glTF native exporter in Blender. I haven't given up yet. I'm doing controlled experiments.
Everything in the gltf_export ... and gltf_batch_export ... files, although different, looks good.
Enough for now.
BTW, I'm a Python beginner, too.
Thanks again for all your fixes.

 

[ronh]

So is it safe to assume that your 42.2.6 is now an "Official" version. If so I have found that the collision material in not being exported correctly for Aircraft.

Blender exports this data:

{ "emissiveFactor" : [ 0, 0, 0 ], "extensions" : { "ASOBO_tags" : { "Collision" : true }, "ASOBO_material_invisible" : { "enabled" : true } }, "name" : "Collision", "pbrMetallicRoughness" : { "baseColorFactor" : [ 0.800000011920929, 0, 0, 1 ], "metallicFactor" : 1, "roughnessFactor" : 1 } }

while the default aircraft have:

{ "name": "Collisions", "pbrMetallicRoughness": { "baseColorFactor": [ 1.0, 0.0, 0.0, 0.7 ] }, "extensions": { "ASOBO_material_invisible": {}, "ASOBO_tags": { "tags": [ "Collision" ] } } },

This important as it affects the VR right click zoom in capabilities. I have tested this by exporting the blender gltf as normal, and then manually change my collision material to the ASOBO version. Now VR right click zoom works for me.

@Mikea.at @tml

Edit: sorry - I had ver 0.40.0 and not any of the updated ones from git. The updated ones fixed this issue. thanks very much.

 

[PhysicsTeacher]

Just an update: I now know lots of things the LOD batch export problem isn't. Three simple cubes will not batch export but are fine one-by-one. There is a discrepancy between the LOD00 and any other LOD level in the glTF: there are four accessors and four bufferViews in the LOD00 glTF, but in the LOD01 or higher glTF files, there are four accessors and only three bufferViews. The corresponding .bin files show the same discrepancy, as expected. This was actually reported last October here: https://www.fsdeveloper.com/forum/threads/blender2msfs-support-thread.448402/page-31.
I have made and unmade many reasoned andlogical changes, one-by-one, and if I didn't break the code entirely, I still got the same result.
There is one suspicious difference in between the gltf2_blender_batch_gather.py file and the gltf2_blender_gather.py file at line 55 in the batch code: a line that says @cached that is present in the non-batch file is commented out in the batched code. The comment says that is to make sure that the code is executed each time through. The '@' symbol indicates that a class is being "decoated" to alter its functionality without subclassing. I hate hacks in code that needs to be maintained.
Anyway, the problem seems to be between those two files (and possibly this hack - which might just be leaving out an element that needs to be buffered into the final output stuff). Anyone out there got any ideas?

 

[Mikea.at]

@ronh in the github version the collision thing is fixed. you find the link above.