Mesh Baker by Digital Opus [RELEASED]

My code solved the problem. Thank you so much for trying to help! Next time i want to optimize a triangle-type mesh, buy your asset. Thanks again!

 

Hmmm, I checked my Unit test scenes and this feature and it appears to work for me. I would check a few things:

Are you using texture packer "Unity"? This texture packer doesn't support blending in non-texture properties. The best texture packer for this feature is the "Mesh Baker" texture packer.

Switch the log level to "debug" on the texture baker. there should be a line in the console that says something like: "Using _considerNonTextureProperties found a TextureBlender for result material. Using: DigitalOpus.MB.Core.TextureBlenderXXXXXX"

Are there any other warnings or errors?
In the atlas can you see tinted rectangles for your source objects?

 

I'd like to get back to this: merging works great when I create an empty combiner and do the first round of merging. However, attempting to add and remove some GameObjects later seems to be locked for me because I'm not using texture baking. Can you recommend ways around this error?

Code (csharp):

1. Can't add objects if there are already objects in combined mesh when 'Texture Bake Result' is not set. Perhaps enable 'Clear Buffers After Bake'
2. UnityEngine.Debug:LogError(Object) (at ?)
3. DigitalOpus.MB.Core.MB3_MeshCombiner:_CreateTemporaryTextrueBakeResult(GameObject[], List`1) (at Assets/Packages/MeshBaker/scripts/core/MB3_MeshCombiner.cs:352)
4. DigitalOpus.MB.Core.MB3_MeshCombinerSingle:AddDeleteGameObjectsByID(GameObject[], Int32[], Boolean) (at Assets/Packages/MeshBaker/scripts/core/MB3_MeshCombinerSimple.cs:1851)
5. DigitalOpus.MB.Core.MB3_MeshCombinerSingle:AddDeleteGameObjects(GameObject[], GameObject[], Boolean) (at Assets/Packages/MeshBaker/scripts/core/MB3_MeshCombinerSimple.cs:1794)
6. ...

To reiterate, I'd like to avoid any texture and material manipulations - I'm interested purely in mesh merging since all objects I'm merging already share materials in an exact way I prefer them to. Collapsing identical materials into the same submesh is all I need, and that's what I get from first merge. It's surprising that second merge suddenly requires this additional data.

About a year ago you suggested this to another user with the same error:

However, that's less than ideal workaround (and not just because I don't use strictly one material and its fairly complicated to set up a system keeping track of a web of array-based merged materials I maintain, so I can not easily generate this "Texture Bake Result" asset). Since the baker has no issues completely skipping all material/texture operations during first merge and perfectly doing its job without that asset, I'd love to get same behavior on subsequent merges.

 

On another subject, is it possible to disable creation of new bones for every single MeshRenderer merged into a skinned mesh? What I'm looking for is making the content of each attached objects assume the index of parent bone coming from an existing skinned mesh, without giving attached objects any autonomy.

I parent things like pieces of armor to bones of character body, but I never need to move any of them locally, especially not on the renderer level (e.g. what is the point of moving decal geometry relatively to base surface of a helmet when its an inseparable part of a full design)? I have plenty of objects attached to almost two dozens of bones on the base body, each with several sub-objects, and MeshBaker ends up creating around 50 new bones - one for each attached renderer. This is highly undesirable in my case, especially because I rely on using unmodified bone indexes to identify locations and apply certain shader effects.

 

This one sticks out to me

Code (CSharp):

1. Blend Non-Texture Properties has limited functionality when used with Mesh Baker Texture Packer Fast.
2. UnityEngine.Debug:LogWarning(Object)
3. DigitalOpus.MB.Core.<CreateAtlases>c__Iterator1:MoveNext() (at Assets/MeshBaker/scripts/core/TextureCombiner/MB3_TextureCombinerPackerMeshBakerFast.cs:48)
4. UnityEngine.SetupCoroutine:InvokeMoveNext(IEnumerator, IntPtr)

I use TexturePackerFast because the other packer types give errors on certain types of texture formats. I'm injecting this into a pipeline for assets that were created two years ago and it's not feasible for us to convert all these texture settings by hand. Is there potentially another solution to keep the formats the same and use material colors?

Some more logs:

Code (CSharp):

1. Loaded 6 TextureBlenders.
2. UnityEngine.Debug:Log(Object)
3. DigitalOpus.MB.Core.MB3_TextureCombinerNonTextureProperties:LoadTextureBlenders() (at Assets/MeshBaker/scripts/core/TextureCombiner/MB3_TextureCombinerNonTextureProperties.cs:452)
4. DigitalOpus.MB.Core.MB3_TextureCombinerNonTextureProperties:LoadTextureBlendersIfNeeded(Material) (at Assets/MeshBaker/scripts/core/TextureCombiner/MB3_TextureCombinerNonTextureProperties.cs:365)
5. DigitalOpus.MB.Core.<_CombineTexturesIntoAtlases>c__Iterator1:MoveNext() (at Assets/MeshBaker/scripts/core/TextureCombiner/MB3_TextureCombiner.cs:374)
6. UnityEngine.MonoBehaviour:StartCoroutine(IEnumerator)
7. <ProcessQueueRoutine>c__Iterator0:MoveNext() (at Assets/Scripts/Utility/AssetBundleOptimizer.cs:163)
8. UnityEngine.SetupCoroutine:InvokeMoveNext(IEnumerator, IntPtr)
9.  

Code (CSharp):

1. Using _considerNonTextureProperties found a TextureBlender for result material. Using: DigitalOpus.MB.Core.TextureBlenderStandardMetallic
2. UnityEngine.Debug:Log(Object)
3. DigitalOpus.MB.Core.MB3_TextureCombinerNonTextureProperties:FindBestTextureBlender(Material) (at Assets/MeshBaker/scripts/core/TextureCombiner/MB3_TextureCombinerNonTextureProperties.cs:385)
4. DigitalOpus.MB.Core.MB3_TextureCombinerNonTextureProperties:LoadTextureBlendersIfNeeded(Material) (at Assets/MeshBaker/scripts/core/TextureCombiner/MB3_TextureCombinerNonTextureProperties.cs:366)
5. DigitalOpus.MB.Core.<_CombineTexturesIntoAtlases>c__Iterator1:MoveNext() (at Assets/MeshBaker/scripts/core/TextureCombiner/MB3_TextureCombiner.cs:374)
6. UnityEngine.MonoBehaviour:StartCoroutine(IEnumerator)
7. <ProcessQueueRoutine>c__Iterator0:MoveNext() (at Assets/Scripts/Utility/AssetBundleOptimizer.cs:163)
8. UnityEngine.SetupCoroutine:InvokeMoveNext(IEnumerator, IntPtr)
9.  

 

Sorry for the double post but I resolved this issue by copying the textures pre-bake to a texture using the correct format (still experimenting with this) and using the non-fast packer. I use Graphics.Blit to copy from the original Texture to a new one using ARGB32 and replacing the original texture in the material with the newly copied and properly formatted one. Works like a charm, although a little slow.

 

Can I ask why you want to do this? There is no performance benefit to combining meshes where triangles are all added to separate submeshes. The main benefit to submeshes instead of separate meshes is convenience. Having a single mesh file instead of several. If you are doing all of this at runtime, I am not sure what the benefit it.

You might find performance is poor if there are a huge number of submeshes and some of the submeshes that initially contain vertices become empty and new submeshes get added. When this happens index buffers need to be shifted to erase the empty index buffers. This is expensive.

One way to do this would be to do a mesh bake (without texture bake) with all possible materials and capture the texture bake result and save it. You would need to hack a few lines into Mesh Baker to grab this.

Another way would be to build a master Texture Bake Result with all possible materials yourself. The texture bake result is a scriptable object so it is easy to work with. Here is what you need to do. Create a simple test setup where you use the multiple materials feature to map each material to its own submesh. Then look at the Texture Baker Result asset to see what that looks like. It should look like:

One Materials And UV Rects entry for each source material.

• Atlas rect is 0,0,11
• all props use same tiling = true
• all other rects 0,0,1,1 except Props Used Different Tiling_xrc

One result material entry for each source material

• The result material is the source material
• The list of source materials have one entry each.
• Do multiple materials is true

 

At this time, no this is not possible. It would be a good feature to add though I will add it to the todo list.

 

Can I ask what texture format the original textures were using and what your build platform is? It is hard for me to test all possible combinations of texture formats and plaftorms, but if you let me know I can note which ones are problematic and try to test these in future versions.

 

MB3TextureBakerResult UVRect is incorrect
The position indicated by the arrow should be 0.875
Its axis is swapped with another image of the same size (256 x 256) below.
This makes the rendering result another image below it

Update:Only Fast Pack Wrong

Unity Version :2017.4.13f1
MeshBaker Version : 3.26.2

 

It was DXT1/5 originally and it was on Windows Standalone. Our pipeline is... strange. I can go into it in private but the short of it is we're not storing art assets in the Unity project itself.

 

Can you let me know which build platform you are using and if this happens on a device build or only in the editor?

Some graphics APIs flip the y and some do not. I added a method in 3.26.2 to MB3_AtlasPackerRenderTexture.cs

bool YisFlipped()

Which checks the SystemInfo to see what graphics API is being used and decides whether to flip or not. If you could let me know what API you are using I could add a clause for this API.

 

build platform: Windows
graphicsApi : DX11

I don't think this is a flip problem. I found that if I randomly insert any 256*256 textures into many 512*512 images, this error will occur.

 

This sounds very strange, are you re-baking the meshes after baking the textures? If you updated the atlas then the image could get moved to a new rectangle in the atlas but the mesh is still referencing the old atlas rectangle.

Looking at your picture I think the Y axis flip would cause the issue you are describing. A 256 rectangle above the horizontal centerline would be reflected across the horizontal to a 256 rectangle below the horizontal. It is a likely coincidence that this is another 256 texture although it would be upside down. Could you add a temporary hack to YisFlipped so it returns its opposite value to see if this is the case?

If it is not are there any errors in the console?

 

I deleted all the files and regenerated and the problem persists
I think this has nothing to do with FlipY because this only happens on 256*256 textures.
Even so, I tried it and the results are still disappointing..
The method of reproduction is very simple. Using nine different 512*512 PNGs and a 256*256 PNG, the bug will appear.

 

Will try to reproduce this.

 

I tried to reproduce the problem but it is working for me. Here is what I did (windows dx11, platform PC, Unity 2013.3, Mesh Baker 3.26.2):

• Tried with 9 different 512 textures and 1 256 texture.
• Used resize power of two textures
  
• Baked textures using MB texture packer fast & baked meshes

Result was correct

I looked at your atlas and noticed that it used 14 512x512 textures so I re-tried it that way and it still worked.

Are you able to email me a unity package or download link with a scene that contains the bad setup?

By any chance are you using graphics emulation (under the build menu), or texture compression in the build settings?

 

Hi again! I'm trying to bake out my meshes to a file using scripts (edit mode) and I'm having a hard time finding where to input the meshes, materials, and prefabs I want to output to. The manual doesn't say where those are, only how to bake out at runtime.

Edit: Never mind! I solved it by copying the methods in MB3_MeshBakerEditorFunctions into my own scripts. Didn't know you could just use CreateAsset and pass it a reference to another UnityEngine.Object and the references stay!

 

Glad you found a solution. Let me know if you have any issues or can't discover how to do something.

 

Thanks for suggesting a possible workaround! We get performance benefit from pure runtime merging with no material changes because many of the pieces we attach to the characters share the same material either by virtue of being authored together with a single atlas or due to being processed with our special array based material packaging system.

Collapsing those objects with a shared material into a single submesh obviously leads to reduction of draw calls. Another, more indirect benefit of using a combined skinned mesh is reduction of component overhead of the character hierarchy. Having just one skinned object and not having to update transform matrices for individual MeshRenderers 20 levels down under some bone is obviously quite nice.

I'd love to know whether its possible to strip those unwanted bones manually, as a postprocessing step on the skinned mesh produced by MeshBaker. Baking time is blazing fast so far, so we'd rather spend additional 20ms to load a character than keep close to 100 unwanted bones. Provided I already know with absolute certainty what exact bone from an original set I want every given vertex to be parented to (building a lookup like that is fairly easy from object data and bone weight indexes), what data should I copy or transform to effectively "transfer ownership" of those vertices to another bone? My geometry is quite simple, with each vertex always being influenced by only one bone with 100% weight, so such an edit might be fairly straightforward.

_________________

On another note, it looks like attached objects that were originally locally scaled negatively on X (mirrored on X) do not get correct tangents after merging into a skinned mesh. Here are two gifs showing the normals and final view of the same foot. The right side (which had armor objects attached at 1,1,1 scale), looks correct. The left side (which had armor objects attached at -1,1,1 scale) has incorrect tangents resulting in broken normal mapping. To make comparison easier, I'm flipping the parent object on those gifs (to get two sides of the MeshBaker-generated body into same pixels):

Just in case, I invoked RecalculateTangents on the final combined mesh returned by MeshBaker, which had no visible effect - so I'm assuming MeshBaker already does exact same operations. The bad tangents are easy to detect based on a bone (they never show up on parts of the body that have no mirrored scales at some point above them in the transform chain), but I don't see an obvious fix to their value - inverting any combination of X, Y and Z yields no suitable results. This might well be caused by the myriad of per-renderer bones created by MeshBaker confusing the tangent calculation, so maybe its not worth looking at before I find a way to remove undesirable new bones.

 

It is not too hard to to post process the skinned mesh to remove the unwanted bones. The important data structures are:

SkinnedMeshRenderer.bones - this is an array of transforms.
Mesh.BindPoses - there is one of these per transform in the SkinnedMeshRenderer.bones array.
Mesh.BoneWeights - there is one of these per vertex in the mesh.

What you need to do is:

• Get the bones and bind poses and boneWeights
• Copy the transforms and bind poses you want to keep to new arrays or lists. As you do this keep track of which index each transform/bindpose in the old array maps to in the new array. I would use in int array of length bones-array for this. The position in the int array is the old bone index. The value in the int array is the index in the new array.
• Convert any lists to arrays.
• Now visit every bone weight. For all of boneIndex0, boneIndex1, boneIndex2, boneIndex3, assign the mapped index to the bone in new array.
• Assign the bindPoses and boneWeights back to the mesh and the bones back to the skinned mesh renderer.
  

Re: The bad tangents. Are you able to send me a simple example? A few meshes which when baked generate bad results?

 

Hello everyone,

I've just purchased meshbaker but have difficulties in converting my prefabs with it, hopefully someone can help me out.

As an example I've got this building :



I wanted to create an atlas with all the textures for it. Assuming there will be one texture and one shader over it in the end, I've normalized all shaders to Mobile/Diffuse, and it looked ok.



Now I followed Tutorial 2 Combining Textures Into Atlases from Ian and created this atlas :



Unfortunately the new mesh building doesn't look good, it has black textured areas such as the pillars at the corners, also the upper walls don't look ok :



Can you point me in the right direction, what is that I need to do differently ?

UPDATE 1:

I get different results (a better atlas layout) by setting the max atlas size lower (1024 or 512), but even so the building is not textured right :



Thanks

 

Check the console for information. I think your building probably has tiling using a UVs ouside the 0..1 range. This needs to be baked into the atlas. This video explains what is going on and various solutions.

 

Thanks for the reply. It was solved by enabling "Consider Mesh UVs".

Are there settings we can adjust to optimize the atlas generation? For example looking at the following atlas it has created, a quarter of it is not used :



Thanks

 

This is probably what you want. You could increase the padding a bit, that will make it less likely that textures accidentally bleed into each other.

You can get a tighter pack if you don't use the force power-of-two option, but the game engine likes a power of two and on many platforms will just add padding to a non-power-of-two texture until it is a power of two. The power of two part is important for generating mipmaps which you almost always want unless this is an atlas with UI sprites or your game is 2D and props are always the same distance from the camera.

If all your source textures are a power of two then you might want to use "resize-power-of-two-textures". This helps fix the problem where the extra padding causes the texture size to bump up and a set of textures that would fit perfectly requires a larger atlas. For example consider sixteen 256x256 textures. These should fit perfectly in one 1024x1024 atlas. But the padding would bump that atlas to 1024x2048 or even 2048x2048. The "resize-power-of-two" option shrinks each textures slightly so it is still a power of two with padding. The power of two textures behave better when mipmaps are generated.

 

Hello Phong,

Thanks for the feedback.
For the last 2 days I've fiddled around obsessively with mesh baker and eventually got to the desired result for my city.
With regards to the initial issue here is my feedback, perhaps someone else will find it helpful :
Solve the problem by dividing the buildings into 2 categories and generating an atlas for each category. I've divided ones with a lots of small textures (billboards, commercials, ac units, etc) and others with fewer/larger textures.
So, instead of generating one 4096 texture for all buildings (combining a total of 250+ textures with sizes from very small to very big) I've generated 2 x 2048 textures, one for each set. Quality was a better (even if the new mesh texture was 2048px the atlas was more optimally populated ) and video memory was reduced by half.
Below are both 2048 textures :

 

when using mesh baker do objects still retain their original LODs?

 

Hi there, I just purchased Mesh Baker. I am finishing an VR project and desperately need to reduce my draw calls. My dungeons are procedurally generated by random joining of predefined "rooms". These rooms are made of many separate meshes like e.g. 30x floor tile, 25x wall tile, 30x roof tile, 5x pillars and so on. Therefore I suppose Mesh Baker is perfect fit for these scenario. However..
I started to work on my baking and realized I have a problem. In each room there are also lights. Let's say 10 point lights, like candles and torches. Due to the fact it is procedurally generated these "rooms" are prefabs and not a complete scene so I can not use lightmapping and all the good stuff for static scenes(as far as I know). All those lights are realtime. It works fine, even though laggy, if the meshes are separate, but once I bake them together it is all one mesh which can be lit by only few(e.g. 4) most dominant lights as pixel lights and all others are vertex lights. My point lights are all quite local and I can not forgo the pixel light lightning of a single candle in the dark corner - they all pretty much need to be pixel lights.
My question is whether you have some tricks or ideas or guidance how to tackle this problem. Because I am n00b with MeshBaker
I suppose I can separate the room in more meshes, but it seems like tedious work to find out how big each group can be just to not fall into too many point lights. Which might lead to separating the room into so many groups it will defeat the original purpose on baking them together
Any help?
Thanks,
Martin

 

Hi,
I am n00b with MeshBaker and I am not sure what do you mean. But I tried to bake LOD meshes just now. Original meshes are left untouched and retain their LODs. You can choose which LOD levels do you want to bake into new combine mesh and it seems that this mesh will contain all the selected LODs baked together - which seems superfluous.
Hope it helps

 

If you have several LODGroups close together, you can bake each LOD level into a combined mesh, then replace them with one LODGroup that uses the combined meshes.

 

Hmmm, so if I understand correctly, the problem is that you are limited to four lights per rendered object with the pipline you are using. When you bake the meshes together, the combine mesh is being lit by more than four lights.

On solution is lightmapping. It is possible bake lightmapping onto a prefab instead of a scene. The lightmapped prefab can be used in multiple scenes:

https://forum.unity.com/threads/problems-with-instantiating-baked-prefabs.324514/

With Light.culling mask you could probably get a very good looking result and this will boost performance.

Other than that I can't think of a way around the problem other than:

Switch to a different rendering pipline like deferred rendering (probably not an option for a VR game)
Arrange the meshes so that each is only lit by four lights as you mention.

 

Thanks for the answer. I am going deferred rendering path as it seems there is no other way around that and I realized that MeshBaker can't help with my bottleneck right now.

Besides that I would have a question or suggestion for MeshBaker.
Let say I have two things I want to bake together. Each of them uses different texture/material. However their textures are already big atlases. You know many assets developers can get are already optimized and have their textures in atlases. But this becomes a problem, because if I try to bake these two things together I need to make an even bigger atlas (consisting of those two original already big atlases).
So even though I use only a fraction of assets from given atlas texture, mixing few things together - each with different atlas texture - quickly ends up with either humongous joint atlas or not doable at all.
Question/suggestion is, is it possible to somehow cut out only the used parts of the original texture atlases and make final joint atlas only from these used parts? That would be a hell of an optimization in texture space.
It seems to me like a very common problem everyone who uses purchased assets must run into all the time and it would be definitely a KILLER FEATURE of MeshBaker.
Thanks

 

Let me know how the deferred rendering works out.

Regarding your feature suggestion. I am pleased to say that Mesh Baker can do that . The "Consider UVs" feature has two major uses:

1) It can bake tiling so that meshes that tile can use an atlas.
2) It can extract a small part of a texture (only the part used by a mesh).

This second use does what you want.

 

Has anyone used this with 2018.3? Any issues?

 

I try to do my active development on the latest version of Unity and run my Unit tests there. Most of my work on Mesh Baker in December and January was using 2018.3 I downloaded 2018.3.4 a few days a go with the intention of using that the next time I work on Mesh Baker... It is a bit hard to keep up at the moment since Unity has been releasing a new minor version every week for the past month.

 

Wow, that is great news! Sorry for missing that feature. I went through all your video tutorials at the beginning and somehow missed this feature. I remember you explaining tiling in great depths, but this use case I can not recall. You should definitely do a short tutorial video just for this - to show off that people can cut pieces from their atlases and create new combined-yet-smaller atlas

Deferred rendering seems to be working for me just fine. It really helps with the performance as I have most of the lights realtime due to the fact I have procedurally generated content and I also have quite many of them. It however is not a silver bullet, I do really heavy manual culling and I reduced a ton of shadow casting. Not sure however if I do something wrong as I read somewhere that completely occluded lights are not processed in deferred rendering, but it doesn't seem to be my case;(

Anyways.. thanks for suggestions, help and great MeshBaker

 

So can we take it that you've found no issues?

I'm a little nervous about all the compiler warnings relating to the obsolete PrefabType and prefab saving functions. Some of my own editor code seemed to work superficially but needed to be converted to the new system to get it to play nicely with the new prefab mode.

Do you have plans to update this part of the code? And in the meantime is there anything we should be wary of when using Prefab Mode, Nested Prefabs and Prefab Variants?

 

I have not yet come across any issues, although TBH I have not yet tried using a nested prefab as the target prefab for "bake into prefab" and have not tried feeding nested prefabs into the batch prefab baker yet. I will try to do that this week to see if there are any changes needed.

 

Question, I bough it but I can't find any example on how to bake skinned mesh at runtime. I don't need a texture atlas, just the skinned mesh baked with animations.

Is there any file inside the scripts or example folder that can help me?

 

Hi, I succeed to combine meshes and textures using Mesh Baker but the final result doesn't look so good. If I want to combine meshes including lots of different high quality textures, e.g multiple 4092*4092 textures, the result quality would be low than source? Unity limits texture size as 8192 * 8192. In this case, I can combine only 4 4092 * 4092 textures? Am I missing something or is this limit of Unity?

 

Yes, the example scene SkinnedMeshRenderer bakes skinned meshes at runtime. The script that does the baking is:

MB_SkinnedMeshSceneController.cs

 

This is a not a limit of Unity so much as the hardware and graphics API of the platform you are developing for (eg. for Android the limit is 2048x2048). Desktop GPUs support 8192x8192.

 

I'm sorry. I'm not sure if I described my problem correctly. After combining meshes, the combined texture includes multiple source textures. If the source textures are very high quality - e.g 8192 * 8192, then after combining the texture quality is getting lower? On my side, I combined around 20 textures(each one is 2048 * 2048) into 4096 * 4096 texture atlas. The result texture quality was very bad. For example, my house changed from orignal nice house to white and yellow one. Can we combine textures with same quality as original?

 

You will be limited by the maximum atlas size you can use for your platform. The maximum number of 2048x2048 textures you can fit into 4096x4096 is 4 without loosing quality. There are a few ways to deal with this, although no magic solution that makes the problem go away.

• Do you need so many textures, can some of them be re-used on different assets?
• Does every texture need to be 2048x2048?
• Mesh Baker includes two features to help split textures into multiple atlases if the maximum size would be exceeded:
  • The analyze scene and generate bakers window has an option "Split Groups If Textures Would Exceed Atlas Size"
  • The Multiple Materials feature also has an option for splitting textures into groups if the maximum atlas size would be exceeded.
• Some sets of props on the asset store come with their own atlas. This is great if you plan to use all these props together, but it is inconvenient if you plan to use a few small detail meshes in your scene but don't what the rest of the huge atlas. Mesh Baker "consider UVs" feature can extract only the part of the source atlas that is actually used by the meshes included in the bake and include these subsections of the atlas in a new atlas.
  
  

 

ok I got it to work

Code (CSharp):

1. GameObject mkGo = new GameObject();
2.             mkGo.transform.SetParent(gameObject.transform);
3.             mkGo.name = "BakedAPI";
4.  
5.             GameObject targetRender = new GameObject();
6.             targetRender.name = "rootBake";
7.             targetRender.transform.position = Vector3.zero;
8.             targetRender.transform.rotation = Quaternion.identity;
9.            
10.             mkGo.AddComponent<MB3_MeshBaker>();
11.             MB3_MeshBaker meshBaker = mkGo.GetComponent<MB3_MeshBaker>();
12.          
13.             meshBaker.meshCombiner.outputOption = MB2_OutputOptions.bakeIntoSceneObject;
14.             meshBaker.meshCombiner.renderType = MB_RenderType.skinnedMeshRenderer;
15.             meshBaker.meshCombiner.doTan = false;
16.             meshBaker.meshCombiner.resultSceneObject = targetRender;
17.            
18.             meshBaker.AddDeleteGameObjects(objsToAdd, objsToAdd, true);
19.             meshBaker.Apply();
20.             Destroy(mkGo);
21.  
22.             targetRender.transform.SetParent(gameObject.transform);
23.             targetRender.transform.GetChild(0).gameObject.layer = UnityEngine.LayerMask.NameToLayer("Player");
24.             SkinnedMeshRenderer bakedLodRender = targetRender.transform.GetChild(0).GetComponent<SkinnedMeshRenderer>();
25.             //Add mesh to combine
26.             bakedLodRender.castShadows = false;
27.             bakedLodRender.receiveShadows = false;
28.             bakedLodRender.allowOcclusionWhenDynamic = false;
29.             bakedLodRender.motionVectorGenerationMode = MotionVectorGenerationMode.ForceNoMotion;
30.             bakedLodRender.lightProbeUsage = LightProbeUsage.Off;
31.             bakedLodRender.reflectionProbeUsage = ReflectionProbeUsage.Off;
32.             bakedLodRender.skinnedMotionVectors = false;
33.             bakedLodRender.quality = SkinQuality.Bone1;
34.             Renderer[] lodRenderers = new Renderer[1] { bakedLodRender};
35.            
36.             newLODs[1] = new LOD(0.01f, lodRenderers);
37.            
38.             lodGroup.SetLODs(newLODs);
39.             lodGroup.RecalculateBounds();

 

Hello!

I´m having this error message right now, don´t really know what to do about it:

Maximum recursion depth reached. Couldn't find packing for these textures.
UnityEngine.Debug:LogError(Object)
DigitalOpus.MB.Core.MB2_TexturePackerRegular:_GetRectsSingleAtlas(List`1, List`1, Int32, Int32, Int32, Int32, Int32, Int32, Int32) (at Assets/MeshBaker/scripts/core/TextureCombiner/MB2_TexturePacker.cs:608)
DigitalOpus.MB.Core.MB2_TexturePackerRegular:_GetRectsSingleAtlas(List`1, List`1, Int32, Int32, Int32, Int32, Int32, Int32, Int32) (at Assets/MeshBaker/scripts/core/TextureCombiner/MB2_TexturePacker.cs:772)
DigitalOpus.MB.Core.MB2_TexturePackerRegular:_GetRectsSingleAtlas(List`1, List`1, Int32, Int32, Int32, Int32, Int32, Int32, Int32) (at Assets/MeshBaker/scripts/core/TextureCombiner/MB2_TexturePacker.cs:772)
DigitalOpus.MB.Core.MB2_TexturePackerRegular:_GetRectsSingleAtlas(List`1, List`1, Int32, Int32, Int32, Int32, Int32, Int32, Int32) (at Assets/MeshBaker/scripts/core/TextureCombiner/MB2_TexturePacker.cs:772)
DigitalOpus.MB.Core.MB2_TexturePackerRegular:_GetRectsSingleAtlas(List`1, List`1, Int32, Int32, Int32, Int32, Int32, Int32, Int32) (at Assets/MeshBaker/scripts/core/TextureCombiner/MB2_TexturePacker.cs:772)
DigitalOpus.MB.Core.MB2_TexturePackerRegular:_GetRectsSingleAtlas(List`1, List`1, Int32, Int32, Int32, Int32, Int32, Int32, Int32) (at Assets/MeshBaker/scripts/core/TextureCombiner/MB2_TexturePacker.cs:772)
DigitalOpus.MB.Core.MB2_TexturePackerRegular:_GetRectsSingleAtlas(List`1, List`1, Int32, Int32, Int32, Int32, Int32, Int32, Int32) (at Assets/MeshBaker/scripts/core/TextureCombiner/MB2_TexturePacker.cs:772)
DigitalOpus.MB.Core.MB2_TexturePackerRegular:_GetRectsSingleAtlas(List`1, List`1, Int32, Int32, Int32, Int32, Int32, Int32, Int32) (at Assets/MeshBaker/scripts/core/TextureCombiner/MB2_TexturePacker.cs:772)
DigitalOpus.MB.Core.MB2_TexturePackerRegular:_GetRectsSingleAtlas(List`1, List`1, Int32, Int32, Int32, Int32, Int32, Int32, Int32) (at Assets/MeshBaker/scripts/core/TextureCombiner/MB2_TexturePacker.cs:772)
DigitalOpus.MB.Core.MB2_TexturePackerRegular:_GetRectsSingleAtlas(List`1, List`1, Int32, Int32, Int32, Int32, Int32, Int32, Int32) (at Assets/MeshBaker/scripts/core/TextureCombiner/MB2_TexturePacker.cs:772)
DigitalOpus.MB.Core.MB2_TexturePackerRegular:_GetRectsSingleAtlas(List`1, List`1, Int32, Int32, Int32, Int32, Int32, Int32, Int32) (at Assets/MeshBaker/scripts/core/TextureCombiner/MB2_TexturePacker.cs:772)
DigitalOpus.MB.Core.MB2_TexturePackerRegular:_GetRectsSingleAtlas(List`1, List`1, Int32, Int32, Int32, Int32, Int32, Int32, Int32) (at Assets/MeshBaker/scripts/core/TextureCombiner/MB2_TexturePacker.cs:772)
DigitalOpus.MB.Core.MB2_TexturePackerRegular:GetRects(List`1, List`1, Int32, Int32, Boolean) (at Assets/MeshBaker/scripts/core/TextureCombiner/MB2_TexturePacker.cs:585)
DigitalOpus.MB.Core.MB3_TextureCombinerPackerRoot:CalculateAtlasRectanglesStatic(TexturePipelineData, Boolean, MB2_LogLevel) (at Assets/MeshBaker/scripts/core/TextureCombiner/MB3_ITextureCombinerPacker.cs:64)
DigitalOpus.MB.Core.MB3_TextureCombinerPackerRoot:CalculateAtlasRectangles(TexturePipelineData, Boolean, MB2_LogLevel) (at Assets/MeshBaker/scripts/core/TextureCombiner/MB3_ITextureCombinerPacker.cs:134)
DigitalOpus.MB.Core.<__CombineTexturesIntoAtlases>d__71:MoveNext() (at Assets/MeshBaker/scripts/core/TextureCombiner/MB3_TextureCombiner.cs:510)
DigitalOpus.MB.Core.MB3_TextureCombiner:RunCorutineWithoutPause(IEnumerator, Int32) (at Assets/MeshBaker/scripts/core/TextureCombiner/MB3_TextureCombiner.cs:248)
DigitalOpus.MB.Core.MB3_TextureCombiner:RunCorutineWithoutPause(IEnumerator, Int32) (at Assets/MeshBaker/scripts/core/TextureCombiner/MB3_TextureCombiner.cs:261)
DigitalOpus.MB.Core.MB3_TextureCombiner:RunCorutineWithoutPause(IEnumerator, Int32) (at Assets/MeshBaker/scripts/core/TextureCombiner/MB3_TextureCombiner.cs:261)
DigitalOpus.MB.Core.MB3_TextureCombiner:RunCorutineWithoutPause(IEnumerator, Int32) (at Assets/MeshBaker/scripts/core/TextureCombiner/MB3_TextureCombiner.cs:261)
MB3_TextureBaker:CreateAtlases(ProgressUpdateDelegate, Boolean, MB2_EditorMethodsInterface) (at Assets/MeshBaker/scripts/MB3_TextureBaker.cs:395)
DigitalOpus.MB.Core.MB3_TextureBakerEditorInternalrawGUI(SerializedObject, MB3_TextureBaker, Type) (at Assets/MeshBaker/scripts/Editor/MB3_TextureBakerEditorInternal.cs:362)
MB3_TextureBakerEditor:OnInspectorGUI() (at Assets/MeshBaker/scripts/Editor/MB3_TextureBakerEditor.cs:33)
UnityEngine.GUIUtilityrocessEvent(Int32, IntPtr)

 

Are the maximum atlas size and padding settings reasonable? Maximum atlas size is usually 2048 or larger. (padding must be significantly less than half the atlas size. Usually it is less than 4). Are there a huge number of textures? Padding can't be compressed, so if there are many textures it is possible that these textures can't fit the atlas with the padding. You could experiment with the atlas size and padding to see if that helps. Are you using the new "horizontal" or "vertical" packing feature? That is a new feature, and is fairly complex. It is possible there are bugs in there.

This is an unusual error. If the atlas size and padding are reasonable but you still get the error, would it be possible for me to take a look at the example? PM me if that is the case.

 

The "SkinnedMeshRenderer" example scene shows how to do runtime baking.

Note that to get the benefit of a single material you will want to combine the materials ahead of time in the Editor. The example does this, using the "SkinnedMeshRendererSetup" scene.

You can collect the skinned meshes under the parent using:

SkinnedMeshRenderer[] sourceRenderers = Parent.GetComponentsInChildren<SkinneMeshRenderer>();

Then assign these as your source game objects for the bake.

 

Are you able to send me a package with an example of the problem (PM or email)? If I can reproduce the issue it is likely I can fix it quickly.

 

I sent you an email. ( contact.digitalopus@gmail.com )
If this is not your email address, tell me.