@belovedquestioningly Thanks for the info, this is strange then. Could you perhaps share some screenshots or even better a short video showing how new materials are generated?
Alternatively, if you can create a minimal Unity reproduction project with a description of reproduction steps which make this issue occur? You can send it as a zip package to contact@esotericsoftware.com, briefly mentioning this forum thread URL so that we know the context.
Hi,
I have created a small package that I have sent as email. This is a simple folder setup I did using the example spine file available here: https://en.esotericsoftware.com/spine-examples-spineboy
I have packed it as an atlas.txt and exported as skel.bytes(The same as our project). I have noticed that the problem occurs if anything in the project causes a refresh to trigger the assetimporter, for example if there is an editor script that was deleted and unity was launched, or another example, if the spine assets were not first present but when a second user gets latest and the assets are now present in the project, unity triggers the asset post processor that deletes the original material file and creates a new file in the SpineData folder.
I have tracked it down to these few lines in the AssetUtility lines 664 - 674
`Material material = (Material)AssetDatabase.LoadAssetAtPath(materialPath, typeof(Material));
if (material == null) {
Shader defaultShader = GetDefaultShader();
material = defaultShader != null ? new Material(defaultShader) : null;
if (material) {
ApplyPMAOrStraightAlphaSettings(material, SpineEditorUtilities.Preferences.textureSettingsReference);
if (texture != null)
material.mainTexture = texture;
AssetDatabase.CreateAsset(material, materialPath);
}`Line 668 returns null as the material is now not present in the path formatted but instead moved to a different location, hence a new material is generated(I think this is what is happening).
I also see this same issue when I import the package I have created for this post, as you can see when the import window comes in there is a material in the material folder
but after the import is done, the folder is empty.
This is an empty project that has spine installed. No custom scripts or any other file.
@belovedquestioningly Thanks for sending the reproduction project, we could reproduce the issue.
The problem seems to only occur when the Material asset is moved to a separate directory, where the Spine importer does not recognize it as associated with the skeleton.
We've created an issue ticket for it here:
EsotericSoftware/spine-runtimes2560
We will have a look at it and get back to you here on the forum once we have a solution to offer.
The simplest solution until this can be resolved properly would be to not move the Material to a separate directory, or at least moving the atlas assets name.atlas.txt and name_Atlas.asset to the same directory.
@belovedquestioningly We have just released a fix for the issue on the 4.2 branch, moved Materials should now be recognized upon (re-) import and no longer deleted and re-created.
A new spine-unity 4.2 unitypackage is available for download:
https://esotericsoftware.com/spine-unity-download
Please let us know if this resolves the issue on your end as well. Thanks for reporting!
Harald Sounds good, will update you soon.
Hi Harald,
Materials no longer are regenerated but
Which when connected to a version system, (we used P4V), it marks the files _Atlas.asset and _Material.mat as modified even though there are no visible changes. Is there a way to avoid this? Thanks.
@belovedquestioningly Unfortunately I could not reproduce this issue. The steps I've taken are:
1) imported your MaterialsControllersIssue.unitypackage, let the materials and assets be generated.
2) add the top-directory of the assets to git.
3) deleted the directory locally, switch to Unity to let it update it's DB.
4) restored the directory to it's previous state again via git checkout .
5) switched to Unity to let it import the assets once more.
6) observe that git status shows no changes after the same assets were imported a second time.
What are the changes you see, can you share a diff? In general please always describe everything with as much info as possible.
The steps on my end is
belovedquestioningly Submit the assets to a server;
Please always describe any steps as precisely as possible. "the assets" is very vague, did you add all assets of the folder to version control? "submit to a server" is very vague as well. What version control software you're using, how did you submit the assets?
I have to repeat the question of my previous posting, since you haven't answered it:
Harald What are the changes you see, can you share a diff? In general please always describe everything with as much info as possible.
Hi Harald,
Apologies for my late response, I did not have access to my machine for some time. Answering your questions, by assets I meant the files in the picture attached which is the
All three files generated by spine export
.atlas.txt
.png
.skel.bytes
Files generated in unity
the material file generate
skeletondata asset
animatorcontroller
Can you describe what "What are the changes you see, can you share a diff?". Would you like to see the diff for these three files?
belovedquestioningly Can you describe what "What are the changes you see, can you share a diff?". Would you like to see the diff for these three files?
Yes. It would be interesting to see a diff of the files that you find problematic that they changed. You posted the following text earlier:
Which when connected to a version system, (we used P4V), it marks the files _Atlas.asset and _Material.mat as modified even though there are no visible changes. Is there a way to avoid this? Thanks.
Since there are no "visible changes" that you see, it is necessary to see a diff of these files.
In Unity what I see,
Diff in perforce looks like the two assets are unmodified, if I choose ignore line endings:
If I chose recognize line endings and whitespace:
belovedquestioningly Thanks for the additional info. Then it's highly likely that you've configured your version control system to always checkout files with a different line ending (e.g. lf instead of crlf) than the one that Unity produces when writing asset files on your machine. So when you checkout your files, you receive one line ending and when Unity just touches the file it's of a different line ending. You thus need to make sure both line ending styles match to avoid undesired diffs.
The checkout happens in Unity and looks like it is because of Line 698 which marks assets dirty even though there are no changes.
@belovedquestioningly Sorry, the term checkout I used might have been misleading here. I don't mean "checkout for editing" but in git terminology meaning "download and setup of your local files by your version control system".
In general your version control system should not care whether Unity's asset database marks anything as modified if there is no actual diff of the files. That is, unless Unity is configured to lock or check-out-for-modification any files in your version control system upon marking them dirty and performing the asset database save operation. However, you said that these files are marked as modified and not as checked out / locked (and the icons in your earlier posting look like that as well).
Do you and your colleage (where you get the differences) perhaps work on MacOS and the other one on Windows? As Unity seems to always use LF line endings for asset files regardless of platform, it might be that one of you has your version control system configured to convert line endings to a common format different than Unity's LF. This line ending conversion typically happens either upon checkout (local download) or upon commit.
Both me and my colleague work on a Window Machine, the project was also developed on a windows machine.
Sorry I should be clearer, by modified I mean it marks the asset as modified for Perforce to pick up. With my experience with SetDirty function, it is possible that using it will mark it modified for Perforce to pick up even if there is no differences.
Here I have attached a dummy script that marks selected asset dirty:
using UnityEngine;
using UnityEditor;
public class MarkAssetDirty : MonoBehaviour
{
[MenuItem("Assets/Mark Selected Asset Dirty")]
private static void MarkSelectedAssetDirty()
{
Object selectedObject = Selection.activeObject;
if (selectedObject != null)
{
// Mark the selected object as dirty
EditorUtility.SetDirty(selectedObject);
// AssetDatabase.SaveAssets();
Debug.Log("Asset marked as dirty: " + selectedObject.name);
}
}
}I have run this script on my prefab, which in perforce turning off line ending difference shows no changes,
and if I turn on line endings
but the asset is checked out
belovedquestioningly With my experience with SetDirty function, it is possible that using it will mark it modified for Perforce to pick up even if there is no differences.
..
which in perforce turning off line ending difference shows no changes,
[image of no differences]
and if I turn on line endings
[image of full file marked as different]
I'm not sure I understood you correctly, as the above seems contradictory: If turning off line ending difference shows no changes, but turning on showing line ending difference displays the whole file, it means that there are line-ending differences comparing the old and new file state.
This would easily be explained if beforehand line endings were e.g. CRLF (e.g. due to Perforce downloading or committing files in CRLF line ending), and after Unity writes the same file, they are LF.
Could you perhaps send us one of the problematic files in the two versions, once before they are touched by Unity, and once afterwards (when perforce lists them as checked out or edited). You could attach the files to a forum posting or send them to us via email to contact@esotericsoftware.com, briefly mentioning this forum thread URL so that we know the context.
Harald This would easily be explained if beforehand line endings were e.g. CRLF (e.g. due to Perforce downloading or committing files in CRLF line ending), and after Unity writes the same file, they are LF.
This behaviour would also be confirmed by the default line ending settings in Perforce here, which are to use local, meaning CRLF on windows. So every time you get the latest revision from the p4 server, you get CRLF files, and when Unity touches the file it's LF.
File in state before opening in Unity:
When Unity is opening and since I have notepad++ open during this process, it shows file modified
after Opening in unity:
File 1: Before Unity
File 2: After Unity
belovedquestioningly When Unity is opening and since I have notepad++ open during this process, it shows file modified
Note that Notepad++ uses the file modification date for that, not actual diffs.
Thanks for sharing the additional files, these are now identical and display no diff in Perforce Merge:
Unfortunately this still does not answer the important question: When viewing the version control state of the file, did this file show as "not modified" or "not checked-out" before opening Unity and show as "checked-out for editing" afterwards?
I'm asking mainly because the above (no line ending diff) contradicts what you've posted previously, the screenshot of the Perforce diff showing line ending differences:
belovedquestioningly and if I turn on line endings
The important remaining question is the following:
Whether when committing the file you sent us with LF line endings to your repository, then checking in e.g. Notepad++ that there are LF line endings, and then opening Unity, is the file afterwards marked as "changed" or "checked out for editing"?
