Decals (Animated) Produce Duplicate Static Mesh Visuals

Version:
1.5.1.0

Frequency:
Consistently

Severity:
Blocker

Similar MSFS 2020 issue:
None

Bug description:
Animated decals in MSFS 2024 seem to create a “duplicate” decal mesh of some sort, as if there are multiple instances of the mesh model, when there are not. For example; with an animated decal over the front cargo door, when the door is opened, the decal animates with the door just fine — however, the sim seems to yield a second “duplicate” of said decal that does not animate with the door.

Photos below attached from my decal livery for reference;







And photos below attached from the default CJ4 livery for reference;


Aside from my livery and the default CJ4 livery, this behavior is exhibited across a multitude of other default aircraft in MSFS 2024… After consulting elsewhere, someone mentioned the following;

I had this same issue and it took me the longest time to figure it out. I had a livery decal model that was only for model.airframe but inside the airframe attachment, I had multiple models in the same directory. In that case, the livery model was applied to each of the sub models. To fix it, I just separated each model into it’s own directory and each one has an attachment.cfg with unique tags.

Your problem might be different but inspect all your tags and consider if the livery stripes can get duplicated onto more than one attachment model.

Considering this, I went and dug through the CJ4 in the VFS and found that while there were no instances of multiple different models within a single part.xxx of the relative parts, there were instances in which different parts shared the same tag, such as part_exterior_fuselage and part_exterior_dirt, which share the fuselage tag. Granted, I am not sure if this is the root cause here or not, but nonetheless, this issue has been present since the launch of MSFS 2024 and is a blocker for animated decals, both in third party applications, and in default core-sim aircraft applications.

What the fix is, I’m not sure, but undoubtedly a fix or alternate workflow would resolve this across the host of default aircraft/default liveries that exhibit this issue.

Repro steps:
Repro Option 1

  • Create a mesh livery/decal, parent it to the base-aircraft’s animation empty for that node, and view in sim.

Repro Option 2

  • Look at either my example decal livery (file attached below), or look at the default CJ4 blue stripes livery in sim.

DevSupport Decal Example.zip (10.4 MB)

If you need any further clarification, please let me know.

Thank you,
Zach

1 Like

Further examples for reference;

Default Twin Otter




Default Citation Longitude

Hello @ZachB

Thank you for the detailed report and providing the repro package.

You are talking about “animated decals” but are you actually creating animation keys for your decal object?
If so you should not.
The part of the decal that is supposed to follow the animated part needs to be cut out and added at the same level of the hierarchy (in your case, using a dummy with the same name) and exported as a submodel.
Dynamic Liveries

You can find an example of this on the Da62 SDK sample

Also, you livery package does not seem to fully match the CJ4 modular hierarchy?
You only have a model.fuselage folder but the CJ4 has nacelle and tail parts so some parts of your decal might be associated to the wrong part.

If this does not work or produces the same problem, we’d be interested to have a look at your .max/.blend file as well.

Edit: we are also having a look at the base aircraft you mentioned that demonstrate the issue, to check if an issue on our side could trigger this behavior.

Regards,
Sylvain

Hi Sylvain!

My apologies for the late response — been away from home for Memorial Day weekend.

Thank you for taking the time to look into this — by “animated decals”, yes, I am parenting those meshes to an “empty”/“dummy” from the base model (CJ4 in this instance) per the SDK and DA62 sample — not animating them on their own.

At this time I have my decal model attaching to model.fuselage for testing, later on to be broken up into LODs and model.fuselage, model.tail, etc. For what it’s worth, I did try splitting parts into the various .[tag] structures last week, similar to the default CJ4 livery, but just like the default CJ4 livery, the “duplicate” decals still remained.

Attached below is my Blender project for one of the liveries pre-LOD and pre-split, just singular, if that helps at all.

Thank you! :slight_smile:
Zach

N411NK DevSupport Example.zip (7.9 MB)

1 Like

Hi @FlyingRaccoon , just checking in to see if there has been anything further on this.

Thanks! :slight_smile:
Zach

Hello @ZachB

From the information I gathered, the issue is not on your side.
The problem comes from the configuration of the aircraft itself.
The issue is tracked internally, and we’ll need to see it fixed first and default liveries behave as they should before we can confirm this solves the problem for you as well.

Regards,
Sylvain

2 Likes

Hi Sylvain,

Thank you very much for the update!

  • Zach

It seems the Stock 747 also suffers from this Bug

1 Like

Are there any updates on this? Still seeing this issue in SU4 Beta on the DHC6-300 and it’s a real pain.

1 Like

@FlyingRaccoon we are having this exact same problem with the Kodiak and other planes in the conversion pipeline. Liveries show up normally, but the door decals don’t move with the door. The livery decals are linked to the same dummy as the regular door and don’t move with it.

I tried exporting using the same setup as the DA62 as well as using the “Submodel” checkbox, but no success yet.

That would be me (the account system is a mess).

Hello @SWS-AlexVletsas

My understanding is it has to do with livery tags. Duplicate tags, or incorrect tags being used, causing the mesh to be duplicated in the merge process.
But I don’t know much, we don’t have access to the full sources of the aircraft that were impacted so far so I was not able to investigate.

I you can provide us with a source project demonstrating the issue, we should be able to isolate the problem.

Regards,
Sylvain

1 Like

Sylvain,

If it helps… a user of a CJ4 mesh livery I made reported to me the other day that a recent SU4 Beta build seems to have resolved this on the CJ4 for the most part.

I’m not sure what changed sim-side/CJ4-side in that regard, but hopefully this insight may help in narrowing it down :slight_smile:

-Zach

Hello,

After investigating your sources package, we noticed that your livery models were not exported as “Submodel” see : Submodel Merging . Since the liveries are merged with the main model, you must use this option for them to work correctly.

I hope this helps,

Yasmine

Hello @Yasmine

I am getting the exact same issue with Submodel activated, the livery still will not work.

I tried exporting with and without submodel:

  • Livery only
  • Livery + bones

It always fails for me.

Should I also export the rest of the base plane with Submodel merging checked?

Edit: I should note that in the DA62 max file has submodel unchecked in its export settings.

Hello,

Can you send us your livery gltf exported as submodel ? or your 3dsmax in PM if you can it would be perfect.

Thank you

You will have it within the hour, in the same PM.

1 Like

I’ve created a mod that addresses this issue for the DHC-6 - https://flightsim.to/file/101629/dhc6-bug-fixes-enhancements-variant

The issue is basically that the gear function attachment (function_dhc6300_exterior_wheels / skis / floats) sets up an inherit from the base function_dhc6300_exterior attachment (which includes the model and attachment points for the main airframe). Each of the presets then includes both function attachments in their attached_objects.cfg, resulting in double-instantiation when the livery is merged.

This mod fixes the issue by adding another preset called “DHC6 Fixed”, that the gear functional attachment doesn’t inherit from the airframe functional attachment.

This mod also fixes an issue with dynamic reg numbers on that aircraft. By convention, the mesh that will display the dynamic registration numbers is in the livery, not the base model. This makes it easier for livery designers to modify styling, placement, size, etc. The DHC6 places it in the base model (x0_DHC6_EXT_FuselageTail001 in dhc6300_exterior_airframe. Besides the fact that this is poorly named and doesn’t give any indication what the node is for, the reg number is also painted in two different panel.cfg’s that don’t override one another (common\panel\panel.cfg and function_dhc6300_exterior\panel\panel.cfg) resulting in it being basically impossible to modify appearance properly in a livery.

The offending node couldn’t just be easily removed by editing the base model GLTF because we don’t have the full source for the model and the round trip from SIM->VFS->change->recompile destroys the animation method used for the prop (which is in the same model).

This mod fixes this issue with a custom html_ui page that always uses an empty string for registration number, then referencing that from both panel.cfg’s.

It’d be cool if the developer could address this, maybe in a similar way…