Hi,
I am having problems with several static meshes retaining their materials. When ever I save and quit rocket, when I load the level back up there are several meshes where materials have swapped places and some materials are missing all together.
It may also be getting progressively worse as I continue to work on the level, as you can see in the screen shot I started on the left building and worked my way towards the right, where the materials seem to be getting progressively worse.
I have another team member working on a different level, and she is getting the same type of problem, missing materials when rocket is closed and started up.
I have looked at other forum posts and found one that is similar, but it did not mention materials swapping places.
Hello,
I am attempting to reproduce this issue, but I have a few questions. What is your method of saving your content? ie. save assets individually, Save All, etc. Do you have autosave on? Are you streaming levels or multiple layers? Any additional information about your project and level could help with my investigation.
Thank you,
Alexander
I have been saving the content using both saving individually and save all and I am pretty sure I have autosave on. There is no level streaming or multiple layers at the moment either - its just a very basic project at this stage.
The level is just the default starting level with the unneeded assets deleted and assets such as the sky/light and post process volume the only assets from the original. As for custom content, there is nothing more than the few building assets you can see, and materials to fit them.
It is highly possible that it is down the the material ID’s being skipped, as I have a habit of using a multi/sub material in max and only selecting what materials I want for it for each model. Such as render colour, stone colour etc, would this be a bug on rockets end or due to my poor habits in max?
I wouldn’t call it a poor habit. I commonly use it as well. I didn’t have this problem in UE3, but I did have a similar issue with how material IDs would be imported when a skeletal mesh is made from multiple meshes. As I commented above moments ago, when I originally posted the issue I was assured it would be fixed in the next build.
Try this: slap an Edit Poly modifier on top of your stack and reassign the material IDs at the modifier level. That way you can preserve a correct view of the texture by toggling it on/off. And if the bug IS fixed in the new build you can just delete the modifier.
We would actually like to ask you to try doing what Jason just asked. I had a discussion with some developers and they would like to know if going back and re-saving, exporting and reimporting the model makes a difference. Also, like Jason said, add an Edit Poly modifier and reassign the material IDs.
Alex, just so you know I did try exporting my model from the editor and importing it into Max (the workaround suggested in the original Bug report). There were some issues with the vertex normals so I abandoned that workaround before I really got too deep, but initially it DID seem to fix my problem… but that might be because the editor-exported asset streamlined the material IDs to be contiguous. I was so focused on working around my issue I never tried to reproduce it. Tonight I’m going to see if I can reliable reproduce the issue by purposefully importing meshes with non-contiguous material IDs.
I just did some tests and I found this to consistently reproducible. A box with assigned material IDs of 2 and 4 exhibited the problem. Same thing with IDs 1 and 3. The mesh MUST use consecutive material IDs, starting at 1, to have material assignments correctly saved.
If you really need to keep your material IDs consistent you could do this very hacky idea I just thought of: nest a small n-gon (n = the number of materials in your multi-material) inside your mesh, with all materials assigned. Since all material IDs are used it should import and save correctly. I can’t speak to the performance cost of using X number of unneeded materials on a static mesh. It’s possible that if those materials are loaded into memory already there would be no cost.
Hi Jason,
I brought your issue to one of our lighting/rendering programmers and he has informed me that what you are describing was a known issue, but has since been fixed. He said the only workaround is “make sure there are no unused material indices in their models.” The next planned Beta release is coming up and we would like to know if it is still occurring for you after you upgrade to it. Please keep us informed so that we can guarantee that this issue gets resolved.
Thank you,
Alexander
I had this same problem and found a workaround. Check the material IDs on your exported assets, if you are skipping any material IDs it could create a problem. For example, if you have an asset that has faces with materials IDs 2 and 4, but not 1 or 3, these skipped IDs could be the source for the problem. Set your materials IDs to be consecutive, starting at 1 and reimport.
Were your first material IDs completely empty in your circumstance? As I use a mutli/sub material where there is a material in ID 1 but it is not used on the current model I am exporting/importing.
Yes. material ID 1 was unused in most of my problem assets. I also use multisub object materials and apply them to assets… unfortunately that workflow creates an issue in the current build of UE4. When I originally posted this issue they said it would be fixed in the next release.
