Studio 1.43.6 Braked Particle Systems on Derive

1. Duplicated Particle Systems Create Independent Materials

Previously, when a particle system was created and then duplicated any number of times, all duplicated particle systems would continue using the same material.xrf file.

As a result, the product would have one shared material entry in the Material tab, regardless of how many copies of the particle system existed.

This behavior appears to have changed.

Now, when the product is derived, each duplicated particle system creates its own independent material instead of continuing to reference the same material.xrf.

For example:

1 particle system → 1 material

Duplicate the particle system 10 times → previously still 1 shared material

Now → when product is derived → 10 independent materials

This is not simply an asset-count issue. It can break the entire particle-system setup, because the duplicated systems are no longer referencing the same material as they previously did. The resulting behavior becomes unpredictable and requires manually correcting each of the generated assets.

This is the behavior I believe is new and needs to be investigated as a regression in how duplicated particle systems retain/shared their material references.

2. Renamed Assets and "Remove Unused Assets" Are Not Persisting After First Save

There is another serious asset-management issue.

Once the project has been saved for the first time, renaming .xrf assets or replacing assets appears to break Studio's ability to correctly track their references.

Specifically:

Create the particle system and its associated assets.

Save the project.
Replace textures.

Rename an .xrf asset.

Use Remove Unused Assets.

The unused/original asset appears to be removed.

Save and close the project.

Reopen the project.

The supposedly removed asset comes back.

3. Derived Products Create Broken Normal and Shininess Maps That Did Not Exist in the Original

There is also a separate derivation issue.

When a product is derived, Studio can create broken Normal and Shininess maps even when the original product contains no Normal or Shininess maps at all.

These maps should not exist in the derived product because they were not present in the original product and were never part of the intended setup.

This is particularly concerning because the resulting derived product can contain additional, broken texture assets that were never created or requested by the creator.

Beta 1.44.10

I specifically tested Beta v.1.44.10, and so far it appears to be clear of the third issue:

No unexpected/broken Normal maps are created.

No unexpected/broken Shininess maps are created.

Other two issues are still present in 1.44.10

Attachments (5)

mp4

Screen Recording.mp4
7.4 MB

image _283_29.png
519 KB

image _282_29.png
80.6 KB

image.png
32.2 KB

image _281_29.png
28 KB

0 Votes