Gltf “RealTime” does not work as expected According to comments in this topic
https://devsupport.flightsimulator.com/t/3277 I think this deserves a
“split” I came across the same issue, unable to edit gltf either on the fly or
by build all/Close project e re open BUT i noticed that the feature Is broken
only for older models. I slammed a fresh One in the project and i could edit
the latter as before Also noticed in console a info regarding changes from
gtlf version 6 to 7 (could be something different, forgot to write down
details) My bet by now Is removing the _Packint (and packages) folders from
the main project could solve the issue, (unable to debug at the Moment)
No luck, seems like glTF live edit Is somewhat broken. Even with brand new
models, ModelLib asset, everything according to sdk, the glTF does not update,
even cleaning , Building all, reloading the project, with scenery in community
or not, the Sim keeps reloading the old glTF , only a full sim restart works.
And the console even logs the .glTF and .bin are changed! So live edit seem to
still be in the pipeline! But some flushing of the old model Is needed! Could
be part of the new optimization? @FlyingRaccoon any news on this? Just Need to
know if you are already working on that or you want some samples to help with
trobleshooting
Save placement in scenery editor, CleanAll, BuildAll, Close, Open, go to
scenery editor
What does your console say? This is an example of an export without textures
that works for me with live auto reloading:
with textures that works. It finds new files, sees it can’t use the png
directly and converts it before partially building:
While this is an example of an
export that does not work: The
reason the third one fails for me is because there I have a texture file
assigned in multiple different slot types and it can’t decide how to convert
the .png to .dds.
Great find!, glTF live edit without textures seems to work! Nice! However,
adding textures Is killing the functionality, my compiler Is always like yours
in screenshot 3 (even with only One texture in the Albedo slot with a fresh
modele) …Reloading not implemented for filetype .png… very ankward!
Well, now I’ve started running into issues too, and the real fun thing is it’s
seemingly working or failing based on texture file names. Literally, the only
thing I change to make it fail or work is rename the texture file before I add
it to the same material in blender. Untitled3.png fails. Untitled4.png works.
wENLK_doors0_normal.png fails. wENLK_doors0_n.png works.
wENLK_doors_albedo.png fails. wENLK_doors0_albedo.png works.
wENLK_doors3_albedo.png works. wENLK_doors4_albedo.png through
wENLK_doors7_albedo.png fails wENLK_doors8_albedo.png works.
wENLK_term_roof.png works MSFStest.png fails It can’t find any pattern. These
are completely new files and filenames. Update 22/aug/2021: I’ve spent
several hours troubleshooting this. I’m not sure if this is a blender exporter
issue or MSFS issue. If MSFS lists the .png file as detected before the .bin
and .gltf the auto-reloading in project editor will fail , even if the
contents of the .png is exactly the same. I don’t know if this is a cause or
an effect : Fails: When the reloading fails with the texture name
Untitled3.png the texture .png file is detected as modified before the .bin
and .gltf.
the name to Untitled4.png the .bin and .gltf are detected first and reloading
works, with the sim converting png to dds.
Works: If I run a .bat file to
copy in the Untitled3.png and the .bin and .gltf file, the .bin file is
detected first and reloading works! The files are detected in this order
regardless of the order of the xcopy commands in the .bat file:
Works: If I export with the
texture name Untitled3.png and the reloading fails like in screenshot 1 I can
open the gltf in visual code and save it without editing to force MSFS to
redetect the file. MSFS then reloads the model successfully.
I’m attaching a project that
for me has a 100% reproduction rate. Blender file and the two texture files
are included in the Blender directory. I’ve tested this with MSFStoolkit /
blender2msfs v 0.40.2.5 and 0.41.3. wombiiactual-airport-enle-
lerviktest.zip Video of blender
export test: https://youtu.be/8LKz18s9icA
Same here. Like you said, what makes it really strange is how there are no
patterns to follow. It’s as if it’s got a mind of it own. Too many small bugs.
I’ll keep just modeling/texturing and import everything once the update is
released.
When you have a failing texture, try opening the gltf in a text editor and
save it without any changes and see if it reloads. Also see if in console the
working names are detected after the model file, and the failing names are
detected before the model file. Seems to be an issue with the order of
operations. I’ve now verified this with a fresh basic project with a single
model and I’m just trying to figure out how to write the bug report so it can
be reproduced.
Thanks for the feedback, Wombll. I’m not making any changes to textures, just
adding and configuring lamps, so being able to reload in real time is vital as
it takes many attempts to get the right color, angle, strength, etc. This used
to not be an issue until the latest update. I was able to do it after
following your tip on changing the artproj to modellib, but only for that day.
So strange…
BTW, are you talking about actual 3D models or the the materials used for
default aprons, etc?
Actual 3D models. Live reloading of the model seems to fail or work based on
the names of the texture files used on the models for me. If I rename the
texture file to Untitled3.png the 3D model fails to reload when exported. If I
rename the texture file to Untitled4.png the 3D model reloads fine in MSFS.
However, when I use Untitled3.png as the texture name I can still force MSFS
to reload the model by opening the .gltf file in a text editor and saving it
without editing it, just so MSFS re-detects the file.
Thanks Wombll, so to confirm, if I want to keep the texture name, I re-export
(with sim open), then open the .gltf and resave it without making any changes
and then the sim will automatically re-load the object? Is that correct?
Yep. That works for me.
I too can confirm this work around work. Thanks again, you’re a lifesaver! 
Resaving the file worked for me. Seems like an order of operations bug as you
say. Hopefully this makes things easier for Asobo to fix.