• Which the release of FS2020 we see an explosition of activity on the forun and of course we are very happy to see this. But having all questions about FS2020 in one forum becomes a bit messy. So therefore we would like to ask you all to use the following guidelines when posting your questions:

    • Tag FS2020 specific questions with the MSFS2020 tag.
    • Questions about making 3D assets can be posted in the 3D asset design forum. Either post them in the subforum of the modelling tool you use or in the general forum if they are general.
    • Questions about aircraft design can be posted in the Aircraft design forum
    • Questions about airport design can be posted in the FS2020 airport design forum. Once airport development tools have been updated for FS2020 you can post tool speciifc questions in the subforums of those tools as well of course.
    • Questions about terrain design can be posted in the FS2020 terrain design forum.
    • Questions about SimConnect can be posted in the SimConnect forum.

    Any other question that is not specific to an aspect of development or tool can be posted in the General chat forum.

    By following these guidelines we make sure that the forums remain easy to read for everybody and also that the right people can find your post to answer it.

MSFS Blender2MSFS Limitation? Color Multipliers

Mikea.at said:
@ronh in the github version the collision thing is fixed. :) you find the link above.
Click to expand...
that fix to roads will fix the aircraft VR PANEL_COLLISION issue?

ok now I see a lot more has been done. I will test collision in VR with your git 0.41.2 version

edit: comparing 0.41.2 (git) to 0.40.2.6 the git version is missing the Khronos texture skipping part (return None)

def __gather_extensions(blender_shader_sockets_or_texture_slots, export_settings): if not hasattr(blender_shader_sockets_or_texture_slots[0], 'links'): return None # this should remove the KHR_texture_transform extensions: return None tex_nodes = [__get_tex_from_socket(socket).shader_node for socket in blender_shader_sockets_or_texture_slots] texture_node = tex_nodes[0] if (tex_nodes is not None and len(tex_nodes) > 0) else None if texture_node is None: return None texture_transform = gltf2_blender_get.get_texture_transform_from_texture_node(texture_node) if texture_transform is None: return None extension = Extension("KHR_texture_transform", texture_transform) return {"KHR_texture_transform": extension}


Edit2: I tested 0.41.2 (git) version and it fixed the VR collision issue, as the export did not have to be manually modified to make it work. Thanks for the update to the code, I'll let my friends know.
 
Last edited:
Mikea.at said:
@PhysicsTeacher please can you work in this github repo? it includes all my fixes
github.com

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 github.com
Click to expand...
Sorry to bother you, but I got your Blender2MSFS2-main.zip from the link to GitHub and tried to install it. Nothing. I see it in my 3rd party addons folder along with another, successfully installed, add on. It's unzipped there, and the downloaded zip is intact and where I installed it from. Did I get the wrong zip? The download zip filesize is 156kB.
To check my sanity, I re-installed your .6 version, and it appears in the export list and works.
Any idea what I'm doing wrong?
Thanks
 
If you download the git repo the folder structure is wrong there is one subfolder too much. I will upload a release in about 5 or 6 hours.
 
I'm now conversant with decorating a function. That's cool! I'm taking it out of the hack category. The batch export iterates through all the LOD collections, and there are a bunch of functions that need calling for each LOD model. That looks like a good candidate for where the problem might be, since it's within the for loop. I'm getting warmer.
More later ...
mikea.at: I'm still working with your .6 version. Whenever you get around to uploading an installable release is fine. I have the unzipped code in the right place, but the installation procedure needs the directory structure you said you would fix. I'm not good enough to make the addon appear in the Export menu. This LOD problem lies elsewhere, and porting a solution will not be a problem.
 
Im sorry completely forgott that, will do it later on. I set an alarm so i dont forget it again :D
@PhysicsTeacher this zip should work to install in blender this is the latest version from the github repo.
 

Attachments

  • Blender2MSFS2-main.zip
    151.8 KB · Views: 214
Last edited:
Yup, did it. Thanks. I love the slider!
I feel I'm getting closer. It's between three source files, 'cuz that's where the for statement differs from the non-batch code. I feel it's in how the caching goes (or doesn't go - depending on the decorated function). I'm debugging with print(), the old-fashioned way and getting closer, but I can't get into the native glTF code easily. If anyone is interested and much more familiar than I with Python, I'll point you to where I am at the moment. I've tried glB with the same result. That's what makes me think it's the caching.
 
For those who are trying the latest Blender2MSFS2 from GitHub, I have the batch LOD export working it seems. It really needs more testing, and mikea.at has made it available for just that.
I have been able to create 3 LODs, batch export them, and have them function perfectly in the sim. I expect problems elsewhere, but I'm still working on that.
If you want to try the batch export, here's a suggested workflow: (This assumes that you know how to use the Outliner and create collections.)
Work Flow:
1. Develop LOD models in labeled collections (x00, x01, ...)
2. Select all, but make sure nothing else, like image plane guides, cameras, suns, etc. are selected. (I keep another collection for just such junk.)
3. Open Export dialog and set up as you would a new export (..\texture\, copyright, save settings). Check Batch Export, Generate/Append XML, give it a name and generate a GUID.
4. Include Selected Objects and Custom Properties. The others appeared in mikea.at's latest version. I don't know what to do with them yet.
5. In the Geometry section, I check Apply Modifiers, since I always work parametrically. If you've already applied your modifiers, leave it unchecked.
6. Export to your chosen directory.
7. (Important) Next time you export these models, UNcheck Generate/Append XML. If you don't, you'll have the LOD minsize xml values reset to 8 and 4 instead of what you set it to as you placed and edited the model. Also, make sure the name you use for export does not have the LOD level concatenated; the Batch exporter will take care of that.

You can now leave Batch checked for subsequent edits. This way you can work on several levels and only have to export once for each test iteration.

As an additional helper, Here's how to figure out what minsize value to edit into the exported .xml file:
"I've been using LODs for quite a while now, and the mystery of the meaning of the "minsize" puzzled me until I 1) read that the sim computes a sphere around your model and measures the sphere's size in some unit value, and 2) you can view the value by selecting Options-Debug LODs-Display External Models LOD from the Dev menu bar. Now, with your model selected (white rectangular volume) you can zoom in and out and note the value in the overlaid display. You will now see something like: ‘LOD[0,1] Size[73.45]’. The first numbers in brackets are the current LOD (numbered from 0), a comma and then another integer showing the number of LODs available for this model. If you have only one LOD, it will show a 1. The LOD is like a fence between showing one model and the next model. The minsize, therefore, does not necessarily depend on distance; rather, I think it depends on the "enclosing volume". Since I make long, narrow bridges, I end up using large numbers for the first minsize. Smaller, more compact structures will require a different set of values for the same distance. I'm certain this is probably the case with P3D also. You turn off the LOD value viewer by going to the same menu and unchecking that line."
The latest SDK update has expanded the LOD "analysis" facility quit a bit. I think you can figure out how to use it, now that you know it's there. Also, perusing the code, the sequence of minsizes starts at 4 an doubles backwards; e.g. Your .xml exported file will show an initial minsize value of, say, 32. The next will be 16. The next will be 8, and the last will be 4. Edit the .xml file as needed to make your model behave in a "platform-friendly" manner.
Fair Warning!: I had perfect results for original files/models. I ran into a problem with textures on an older model (pre-2021-8-5).

HTH
 
I am working another time on my Calypso, so il will try to make 3 Lods ...
I will back a CR as soon as I have a good or bad result :cool:
 
@PhysicsTeacher and for the others as a information :)
actually i dont know if it is a bug or if it works as designed orignaly but if you have for example 4 collections with a model inside. every lod model shares the same material (with textures), then only the first lod has textures exported.

"workaround" is to rename the material in the other collections:
x00 -> material
x01 -> material.01
x02 -> material.02

then the gltf files get the texture information exported correct.
 
Yes, that's what I'm working on now. It's a matter of how Blender renames textures with increasing numbers when you make the model collections after the first. I can't decide whether to fix that or leave it alone. I tried commenting out the @cached on the textures gather, but the results were very strange. I think what I do to make each next LOD model is to: 1) Create the most detailed model in x00 until it's perfect. 2) right-click on the x00 collection line and click Duplicate collection. I then rename that collection to x01. If I look in the materials properties listing, all my original textures are there but relabeled with the next higher number. This is the workaround you found but done for you.
I'm still not completely convinced this fixes everything, but you have, indeed, found the first problem. I'll keep experimenting.
Thanks for the update. It helps to have someone else look at it. I built robots for 30 years before I retired again and started teaching, and my rule was: Never, ever rely on my own testing of my own software.
Edit: No, I'm wrong about the incrementing the material number. This needs more analysis. Sorry. I must have been doing something else. I know that when I do the Blender editing for my least complex LOD, it's usually a decal on a box - not the same material at all, and that comes through. You may have just found the problem with my old, complex model that I was having trouble with.
More later.
 
Last edited:
Troglodytus is correct: adding number suffixes to the textures and materials of subsequent LOD models does "fix" the problem. I'm conflicted over whether this might just be a good thing or not.
I have found one way to automatically add the next suffix number with the following workflow:
1. Create and perfect the x00 model.
2. Select everything in that x00 model collection and CTRL-C copy the entire collection.
3. Create the x01 collection heading.
4. Select the x01 collection heading.
5. Paste the entire model into the x01 collection with CTRL-V.
All the materials will now have the next numeric suffix.
6. Edit the x01 model to reduce detail.
Now, is this a good thing? For me, yes, it is. After I leave my LOD00 model, I delete any normal maps and, sometimes, textures. I replace the textures with solid colors to further reduce complexity. For those who need the same texture on several levels, you can simply select the texture and replace it with the original texture from the texture name dropdown at the left end.
The exporter tries to save memory and time by not "gathering" anything that's already in a cache from a prior gather. This is why only the first LOD gets the materials in its glTF file. To make subsequent passes through the gatherings pick up textures, they must have a different name. Hence the suffixes are a "solution" to the problem.
I'm still not happy with this solution, but at this point it helps a little.

I'll keep working on a better solution to the batch export, though. This is a hack. I want a solution.
 
@PhysicsTeacher I have a model bridge which has collision boxes exported with 41.2.
When I test it in the sim different aircraft give different results. The icon reliably crashes or has a very severe upset. This is as expected.
I also tested the pitts, robin, and Da40NG. All are MSFS standard. I got an occassional crash with the Da40 and none with the pitts or the robin. They fly right thru as though it was clean air! The very occassional Da40 crash is not repeatable and seems to be completly random.
When I tested them on MSFS models they all crash as expected. However in MSFS photogrammetry areas you can fly thru several buildings before you crash.
I addressed this to you as I believe you also do bridges and wondered if you have seen similar behaviour.
Thanks for your help.
 
Sorry I can't be of much help here. I've never tried it. If I had to guess, though, the collision boxes need to have quite a few more faces than you might think. I know that I can land the Cessna 172 on a bridge that has a roadway made up of an array of small, flat rectangular solids, while I can't land on a bridge roadway that is made up of large, long pieces - like a bridge that has perfectly straight approaches where I don't need the curve-following accuracy. I'd guess the photogrammetry models are little more than boxes with decals - extremely low poly.
How's the 41.2 working for you with LOD batch export? Your collision would only be needed in the LOD00 level, obviously, but we're interested in experience with this WIP.
HTH
 
@PhysicsTeacher Thanks for responding. I may have confused the issue mentioning photogrammetry.

The model is 3d blender model and I have tried it in LOD00 and without LOD's. The invisible collision boxes enclose the bridge.
The questions I am asking are:
Do you get different results with collisions (intentional crashes) with different aircraft?
Are the crashes consistent and the same as MSFS 3d model bridges eg Brooklyn Bridge?
I'd very much appreciate it if you would try some crashes in different aircraft to either confirm my results or tell me I have screwed up somewhere!

As far as LOD's are concerned the method I use is to build up from the base; ie LOD00 = LOD00 + LOD01 + LOD02 etc. So I do not have to copy to different LODs and this means I cannot batch export (as I understand it). Each LOD only has the add on to complete that level.

Thanks for all the work you and @Mikea.at are doing.
 
Please don't take offense; none intended.
I'm certain you will be able to resolve your collision problem with some experimentation.
I can't help you any more.
 
Last edited:
Hello,

I've tested a bit this version 0.41.3 and it seem to work better for batch export LODS.

I still have an error for exporting animated objects when exporting batch (no problem when exporting each LOD separatly).

In the image the error message.

If i select only non-aminated objects and check the box "selected objects" in the "Include" part of the export windows. The export is working without problem but only non-animated objects are exported.
So the problem is clearly for animated objects.

Good luck
Error-export-LOD.png
 
Wouldn't it be a problem of path length to access the files? perhaps ?
According to what I read on the capture, the path is already consequent. Why not make a MSFS directory under D:\ and put the root of each project there? As far as I'm concerned, that's what I do.

ex: D:\MSFS\nantes-navibus-anime-test.blend
 
You must log in or register to reply here.
Back
Top