Mesh Baker by Digital Opus [RELEASED]

Hi Phong,

Does Mesh Baker works with Skyshop?

Thanks

 

I do not have skyshop but it should work. I watched the video and the skyshop materials accept ordinary textures. There is no reason that these textures cannot be atlases.

 

Hey,
How does making texture atlases for tiling textures work? I've read that this can bake tiled materials but I don't see how that's possible and since my tiled textures take up a large space on my game object would making them part of an atlas make the texture quality too blurry?

 

Baking the tiling into the atlas does eat up space in the atlas quickly since an image is duplicated multiple times in the atlas.. It is only practical in cases where the tiling is limited to a small area. If you have huge tiled areas then this isn't a reasonable solution.

If you have multiple meshes that use the same tiled texture with different scale and offset (such as different parts of a castle). Then make sure that you are using UVs outside the range 0,1 to tile instead of using the texture tiling settings. This way you can have meshes with different tiling settings share a material and they can be combined together (although the texture cannot be put in an atlas).

 

Hi Phong,

I tested it with skyshop and it works fine when meshes are combined with LOD baker for the first time. When I zoom out, and then when I try to zoom in, I get the following error and meshes no longer gets combined. I noted that Skyshop adds a script to CombinedMesh-. When I change shader back to unity shaders and remove the skyshop from scene, everything works as normal.

Note: I get this error with normal shaders aswell as long skyshop manager is in scene.
I also noted that when skyshop is in scene, it also adds (Instance) to material like as shown below. The material name is 01 - Default, but with skyshop in scene it becomes 01 - Default (Instance) on the CombinedMesh-.

Is there a way to over come this and make it work with skyshop?

Error Code:
Object sack flat has an unknown material 01 - Default (Instance) (UnityEngine.Material). Try baking textures
UnityEngine.Debug:LogError(Object)
DigitalOpus.MB.Core.MB3_MeshCombinerSingle:_addToCombined(GameObject[], Int32[], Boolean) (at Assets/MeshBaker/scripts/core/MB3_MeshCombinerSimple.cs:448)
DigitalOpus.MB.Core.MB3_MeshCombinerSingle:AddDeleteGameObjectsByID(GameObject[], Int32[], Boolean) (at Assets/MeshBaker/scripts/core/MB3_MeshCombinerSimple.cs:1346)
DigitalOpus.MB.Core.MB3_MultiMeshCombiner:_bakeStep1(GameObject[], Int32[], Boolean) (at Assets/MeshBaker/scripts/core/MB3_MultiMeshCombiner.cs:472)
DigitalOpus.MB.Core.MB3_MultiMeshCombiner:AddDeleteGameObjectsByID(GameObject[], Int32[], Boolean) (at Assets/MeshBaker/scripts/core/MB3_MultiMeshCombiner.cs:353)
DigitalOpus.MB.Lod.LODCombinedMesh:BakeClusterCombiner() (at Assets/MeshBakerLOD/Scripts/Core/Combiners/MB2_LODMeshCombiner.cs:383)
DigitalOpus.MB.Lod.LODCombinedMesh:_BakeWithSplitAndMerge() (at Assets/MeshBakerLOD/Scripts/Core/Combiners/MB2_LODMeshCombiner.cs:268)
DigitalOpus.MB.Lod.LODCombinedMesh:Bake() (at Assets/MeshBakerLOD/Scripts/Core/Combiners/MB2_LODMeshCombiner.cs:222)
MB2_LODManager:UpdateMeshesThatNeedToChange() (at Assets/MeshBakerLOD/Scripts/MB2_LODManager.cs:382)
MB2_LODManager:LateUpdate() (at Assets/MeshBakerLOD/Scripts/MB2_LODManager.cs:311)

 

Hmmm, Skyshop is creating a new instance of the material on the source object. This is bad because Mesh Baker uses the source object's material to map to the correct position in the atlas. Since this is a new material that Mesh Baker doesn't know about it doesn't know how to map it. I don't think there is a way to work around this on the MeshBaker side. Can you ask the Skyshop people if their asset is supposed to create a new instances of a material for each object. This may be a mistake in their code. They may be accessing renderer.material when they should be accessing renderer.sharedMaterial.

 

Ok I will ask them and see what they say.

Thanks

 

Hey Phong,
Skyshop does intentionally create new instances of materials if certain features (local skies & triggers) are used. This is because it needs to support two objects with the same material being able to exist in two different rooms with two different IBL cubemaps applied (along with other shader settings like blending and box projection being toggled differently). This instancing happens at run-time because objects often move from one room to another, requiring the material split.

It is the one short-coming of the trigger system I'm very unhappy with because it also breaks batching. I've tried hard to get MaterialPropertyBlocks working which should fix the need for instancing but found them missing something crucial (I think shader keywords are not stored?). In short: for lots of complicated annoying reasons, we're stuck with instanced materials for now.

If Skyshop is used without local skies, all objects are applied the same global sky across the scene and no instancing is required. You can even blend between global skies as the blending keyword is toggled globally, not per material.

 

Thanks for the information. It sounds like global skies with skyshop should work with Mesh Baker.

I will try to take a look at the MeshBaker code to see if it would be possible to insert new materials into the Material to UV rect map. Then you could insert instanced materials if you knew what original material it was instanced from. A bit of a hack but it might work.

 

can i only use one mesh's UV in stead of their own uv,

 

I am not sure that I understand the question. This answer about atlases from the FAQ may answer your question.

An atlas is an image (a single png file for example) that contains other images.

Imagine a cube mesh with a material and texture that makes it look like a blue dice and another cube mesh with a material and texture that makes it look like a red dice. Each cube mesh has UV coordinates (one coordinate for each vertex) that map parts of the textures to triangles on the mesh. The bottom left corner of the texture has UV coordinate 0,0 and the top right corner has UV coordinate 1,1.

Unity would need two drawcalls to draw these cubes. One for each cube. Wouldn’t it be nice if we could combine those. This is what atlases are for.

We could create one big image file in photoshop and put the blue dice texture on the left and the red dice texture on the right. This big texture is called an “atlas”. However we can’t use it with our cubes. The UV coordinates in the meshs would be wrong. They map to the whole image not just half. Each dice would be half blue and half red. We would need to adjust the UVs in the meshs. The blue mesh needs its UVs scaled so they are in the range 0,0 to .5,1. The red mesh needs its UVs scaled so they are in the range .5,0 to 1,1. If we do this then both cubes can use the same texture/material and both would still look correct. These meshes could be combined and Unity could render them with one draw call.

Mesh Baker is a tool that combines textures into atlases and combines meshes (adjusting UVs as it goes).

 

I understand what you mean.but now i have a need that i need combine some meshes(for example some cube meshes)into one, and the one mesh use one new Texture rather than atlases be combined textures.
For example:

I combine four planes into one plane.Each plane has its own texture. After i combine them into one, As shown on the left in Fig，But I want to be on the right side as shown in Fig.I'm not sure whether I have a clear description of the problem.Still thank you for the warm reply

 

I think I understand. It looks like you want to combine the four meshes and then want the new combined mesh to have a new set of UVs. I don't think there is any way to do this with Mesh Baker. I would think this would be very easy to create in a modelling program. Is that solution practical?

 

Thank you very mush

 

Hi Phong,

I was wondering if you could confirm I'm using the best workflow for this situation. I have a single prefab for a room containing a hierarchy of gameobjects with individual meshes and materials. I would like to use Unity's static batching as much as possible and thus want to create a shared material with an atlas of the combined textures, but keep the original hierarchy of game objects intact. The meshes on those game objects would need to be updated to have modified UVs to use the new combined material, and the renderers would have to reference the new combined material.

All of this is fine and well explained in your tutorials (thanks!). However, the combined size of the textures in this room would span several full-sized atlases (3 or 4 roughly). Is there an easy way to create several atlases rather than shrinking things to fit on one material? Having a few atlases/combined materials at full resolution would be ideal.

The only way I can see doing this is to manually split the room prefab into several prefabs and create the combined material, then bake into a new prefab for each of them. This works, but is fairly tedious and results in having several prefabs representing the static geometry of the room rather than one prefab. I can combine the new prefabs afterward back into one, but this is another manual step that makes re-baking error-prone.

I'm not sure there is a general solution to this but I wanted to see if you had a different approach for the one-prefab-many-atlas problem. Thanks!

 

I have had a few users ask for a feature analyse atlases and split them into several atlases. It is on my list of features to add someday but it is a very hard optimization problem so it will be a ways off.

It might be more efficient to not use the prefab baker and to instead use the old approach of setting up multiple TextureBaker/MeshBaker's with the MeshBaker option set to "Bake in place". It would be a fair bit of work to set up the first time but once it is set up then re-baking should be fairly quick. The only problem is that you would probably have to manually re-assign the new generated mesh assets to your target prefab after baking. I am not sure this would be faster than your multiple prefabs approach.

Sorry that I don't have a faster solution. Thanks for letting me know about this use case as it helps me to improve the tool.

 

New version of Mesh Baker in the Asset Store. The texture packer now has a "force to power of two" feature that is enabled by default. Unity recommends using power of two textures for everything but GUI textures.

 

This might seem a little silly of a question, but is there a way to use Mesh Baker to combine meshes that have tiling uvs, without it repacking the textures by increasing the tilling in [0,1]?
As a second question, I think I'm overdoing it, or using mesh baker for something that should be pretty simple. In a lot of my instances I have a bunch of meshes that are using the same multi mat ID's, i just want those to be combined into one mesh to save, of course, drawcalls. Those are tiling textures as well, is there a workflow possible with mesh baker that would combine those meshes, retaining the correct mat ids, no texture baking, just keep the mat id slots in the resulting mesh, and I can assign myself the already created textures and shaders of the initial meshes into the combined one?

 

You can:
1) only combine meshes that use the same material and not bake the tiling
2) map the tiling materials to their own submesh in the combined mesh using the multiple materials feature. This is has the same performance as option 1.
3) bake the tiling which can result in large atlases and degrade the quality of the textures

In most cases there are no other solutions to combining tiling meshes.

You should be able to use the multiple materials feature for this. If each mapping has only one source material then Mesh Baker doesn't bake the textures, it just uses the textures as is on the original materials. It might still want to duplicate the material though. This should create a combined mesh with a separate submesh for each material.

You can also bake meshes without baking textures first if they all use the same material. The original source material will be used on the combined mesh.

Does this answer your questions?

 

Interesting, thank you so much for answering quickly

I was trying to do that on a set of various meshes that were using the same material. however, two within that set have uvs set in [0,1], and the rest have tiling uvs. This creates of course a combined mesh but with the sub mesh tiling uvs having black in parts of the diffuse, and reapplying the initial texture wont give me the correct results, so the uvs were transformed to fit into a unique tile.
I dont know why I'm a little lost on what to do, in your documentation ( which is very detailed on both how to use it and what actually happens to the mesh) I couldn't really find out a way to do exactly what to do, and i couldnt find any videos on your youtube channel that shows someting similar to my use case. My apologies if there is something dedicated to that somewhere out there, and I would greatly appreciate a link to it if it does exist ( or even the page in the documentation that refers to it.)

I'll run a few tests with those and the various tools in MeshBaker. What happens if each mapping has several source materials?

So far in the last two days of use, I've only combined meshes that have only one material ID and were the same material throughout an extensive scene, and I've only done it through baking the textures/shaders down, if there is a way to skip the actual baking ( Bake materials into combined material) as I always end up having to select the resulting combined mesh and reassign the original material seems to be a time waster when Im looking to do something that seems pretty simple? It just seems I'm going through extra steps that I could bypass ( which I have a feeling there is, but i havent been able to find anything about that - not that my digging has been extensive on your toolset, i have a lot on my plate work wise!)

Edit: basically, i'd just like something similar to combine tools in 3d packages. I thought it would be so simple with this, but maybe i'm doing it all wrong, i dont know.

 

I would recommend this video. It does the best job of explaining how to use the multiple materials feature.

If there are several source materials mapped to a single result material then an atlas is created for that submesh. Each mapping results in a separate atlas.

I added the bake meshes without baking textures feature fairly recently so it is currently not mentioned in the documentation. Basically you can ignore the Texture Baker. Just add the objects to combine to the Mesh Baker and click bake.

 

Thank you Phong

 

Hey Phong,
Is there a good way to quickly combine meshes into one if all meshes use same material

Let's say I have fence which consists of same object duplicated 10 times. I want to quickly combine those 10 into 1. But I do not need any atlasing, change of material or any UV changes. So basically there was fence made out of 10 objects and I want same fence but made out of 1. What workflow would you suggest?

I've watched your tutorials on YouTube, but they only partially answer my question. And so far I managed to get what I want, but Mesh filter for the created objects is strange. I have no idea where it lives and it doesn't have any name

Also if I bake light map afterwards it bakes in a wrong way, because combined objects have light map UV on top of each other


Thank you.

 

Yes,

Baking meshes without creating an atlas is fairly recent addition, if all your objects use the same material you can ignore the MB3_TextureBaker. Just add all your objects to the MeshBaker and click bake.

The MeshFilter-MeshRenderer is on a child game object of the "CombinedMesh" game object.

Regarding lightmapping. You need to set the lightmap option to "generate new UV2 layout". This will generate a new UV2 layout for the combined mesh. The UV2s of the source meshes won't work because they overlap each other.

 

Thank you!
I'll do as you suggest =)

 

Hey Digital Opus, I bought your asset last year and had varying success mostly due to me a beginner with shaders mesh and atlases but love the asset. A lot has changed with Unity 5 does this work with 5 and are you planning to update the tutorials as they seem to be way behind the curve on your wonderful tools?... having trouble keeping up as is.

 

Hi AgathaCrup, I just submitted a version that works with Unity 5. Only a few tweaks are needed to get it to work.

I am planning to update the tutorials as well, unfortunately it is a very big job and is also a moving target. Almost everything in the tutorials is still valid, but I am aware that they are a mess and need updating.

 

i got error
Resulting mesh will have more than 64k vertices

 

Use a Multi-MeshBaker. It will distribute the source meshes across several combined meshes.

 

Hello!
I recently encountered this kind of problem - I'm baking two Standard specular setup shaders (PBR), both containing Albedo, Specular, Normal and Emission maps, but the baked result is only Albedo, Normal and Height texture atlas, while the height texture contains only black.
No errors are present in the console, it simply creates only these atlases.
I'm using version 3.7.2 which is the most recent I believe.
So, are those new shaders supported in this verion, or is these some special workflow for these shaders?

 

Check the names of the texture properties in the shader. You probably need to add the names to the list of "custom property names". Mesh baker will look for the following texture properties. “_MainTex”, “_BumpMap”, “_BumpSpecMap”, “_DecalTex”, “_Detail”, “_GlossMap”, “_Illum”, “_LightTextureB0″, “_ParallaxMap”,”_ShadowOffset”, “_TranslucencyMap”.
If the texture property you want is not on this list you need to add it in the list of custom property names. Sorry it works this way, but it is not possible to query a shader to get a list of the texture properties. I will make sure that the names of the standard shader texture properties get added to the the list.

I just added the new texture property names and will submit a new version to the asset store. You can make this change yourself in the meantime by editing file MB3_TextureCombiner.cs line 17 change it to:

Code (CSharp):

1.         public static string[] shaderTexPropertyNames = new string[] { "_MainTex", "_BumpMap", "_Normal",
2.             "_BumpSpecMap", "_DecalTex", "_Detail", "_GlossMap", "_Illum", "_LightTextureB0",
3.             "_ParallaxMap","_ShadowOffset", "_TranslucencyMap",
4.             "_SpecMap", "_TranspMap","_MetallicGlossMap","_OcclusionMap","_EmissionMap",
5.             "_DetailMask", "_DetailAlbedoMap", "_DetailNormalMap"};

 

Thanks for the fix!

 

Is it possible to run-time bake meshes in the background? Preferably with a thread, but time slicing is ok. I need to dynamically bake groups of arbitrary geometry, and I don't really care if it takes a second or two, as long as it doesn't spike performance during that time.I see you are doing something like this in your LOD tool.

 

Question about best practices: I arrange my scene into rooms (Empty game object with that rooms dynamics, statics, etc as children) and each room gets its own layer as well to limit lighting. Can I easily have a mesh baker per room for the static stuff? Then, if I change the scene I just hit rebake?

 

I have thought about this but don't believe it is practical to use a different thread. The problem is that the MeshCombiner class needs to read the Transform properties and the vertices from the mesh objects. The Unity API forbids accessing these objects from outside the main thread. That being said I noticed that Simple LOD claims to bake on a background thread. I am curious how the author accomplished this.

You can definitely do your own timeslicing which is what Mesh Baker LOD does. The atomic operations are MeshCombiner.AddDeleteObjects and MeshCombiner.Apply. Do as many of these as you have time for and then defer to the next frame. Note that if you use 64k meshes then these operations can take a long time. You can use a MultiMeshCombiner and set the maximum mesh size to something lower to make the duration of the atomic operations shorter.

 

Yes, this is a good workflow. Just create a baker for each room. If the rooms use mostly the same materials then I would recommend using one TextureBaker that has multiple MeshBaker children (one for each room). Just duplicate the MeshBakers to create these. Adding your meshes to the mesh bakers should be easy using the filters in the "Open Tools For Adding Objects". There is a "Bake Every Mesh Baker In Scene" button so you can bake everything while getting coffee.

I just refactored the "Open Tools For Adding Objects" window. Expect this version in the asset store any day now. I will be making a tutorial video over the next few days so check back.

 

Does this just do the mesh combining or is it possible to atlas at run time using this methodology?

 

You can create atlases at runtime. There is an example scene that does this. However there is a major drawback that all source textures must have the read flag checked and must be in ARGB format. This can bloat your build and use a lot of unnecessary memory.

 

how well does it work with Unity 5 standard shader?
any new update specifically for Unity 5?

 

Mesh Baker is fully functional in Unity 5. There have been a few updates specifically for Unity 5. The latest version will combine all of the texture properties of the standard shader. There are a few more things coming, for example Unity 5 supports five UV channels on meshes whereas Unity 4 and mesh baker currently only handles three.

 

Awesome! Aaaaand buying...

 

Hey Phong, I think I may have found a few bugs in MeshBaker. I am on Unity 5.0.0f4 and MeshBaker 3.7.3.

It seems that whenever I try to add an MB3_MeshBaker component to a top-level empty GameObject, there is a NullReferenceException that gets spammed in the OnGUI call. Here is the callstack:

Code (CSharp):

1. NullReferenceException: Object reference not set to an instance of an object
2. MB3_MeshBakerCommon.GetObjectsToCombine () (at Assets/MeshBaker/scripts/MB3_MeshBakerCommon.cs:48)
3. DigitalOpus.MB.Core.MB3_MeshBakerEditorInternal.DrawGUI (.MB3_MeshBakerCommon target, System.Type editorWindowType) (at Assets/MeshBaker/scripts/Editor/MB3_MeshBakerEditorInternal.cs:182)
4. DigitalOpus.MB.Core.MB3_MeshBakerEditorInternal.OnInspectorGUI (.MB3_MeshBakerCommon target, System.Type editorWindowType) (at Assets/MeshBaker/scripts/Editor/MB3_MeshBakerEditorInternal.cs:71)
5. MB3_MeshBakerEditor.OnInspectorGUI () (at Assets/MeshBaker/scripts/Editor/MB3_MeshBakerEditor.cs:49)
6. UnityEditor.InspectorWindow.DrawEditor (UnityEditor.Editor editor, Int32 editorIndex, Boolean forceDirty, System.Boolean& showImportedObjectBarNext, UnityEngine.Rect& importedObjectBarRect, Boolean eyeDropperDirty) (at C:/buildslave/unity/build/Editor/Mono/Inspector/InspectorWindow.cs:1150)
7. UnityEditor.DockArea:OnGUI()

Basically, it's crashing because I added the component to a top-level GameObject that has no parent, so the function MB3_MeshBakerCommon::GetObjectsToCombine ultimately tries to dereference this null parent. It seems like the code shouldn't have tried to do this because in the inspector, useObjsToMeshFromTexBaker appeared to be false. On line 109 in MB3_MeshBakerEditorInternal, it is setting the useObjsToMeshFromTexBaker SerializedProperty to false, but this is not propagating to the actual serialized data in the MB3_MeshBakerCommon object itself.

It's a little strange because I just watched your new tutorial video where you demonstrated adding an MB3_MeshBaker component to a top-level GameObject, but you did not seem to get the exception... So I don't know why it is happening to me...


As a workaround, I tried creating an empty parent and child GameObject, then adding the MB3_MeshBaker to the child, but that produced another exception:

Code (CSharp):

1. ArgumentException: GUILayout: Mismatched LayoutGroup.Repaint
2. UnityEngine.GUILayoutUtility.BeginLayoutGroup (UnityEngine.GUIStyle style, UnityEngine.GUILayoutOption[] options, System.Type LayoutType) (at C:/buildslave/unity/build/artifacts/generated/common/runtime/GUILayoutUtility.gen.cs:210)
3. UnityEditor.EditorGUILayout.BeginHorizontal (UnityEngine.GUIContent content, UnityEngine.GUIStyle style, UnityEngine.GUILayoutOption[] options) (at C:/buildslave/unity/build/Editor/Mono/EditorGUI.cs:6414)
4. UnityEditor.EditorGUILayout.BeginHorizontal (UnityEngine.GUILayoutOption[] options) (at C:/buildslave/unity/build/Editor/Mono/EditorGUI.cs:6393)
5. DigitalOpus.MB.Core.MB3_MeshBakerEditorInternal.DrawGUI (.MB3_MeshBakerCommon target, System.Type editorWindowType) (at Assets/MeshBaker/scripts/Editor/MB3_MeshBakerEditorInternal.cs:137)
6. DigitalOpus.MB.Core.MB3_MeshBakerEditorInternal.OnInspectorGUI (.MB3_MeshBakerCommon target, System.Type editorWindowType) (at Assets/MeshBaker/scripts/Editor/MB3_MeshBakerEditorInternal.cs:71)
7. MB3_MeshBakerEditor.OnInspectorGUI () (at Assets/MeshBaker/scripts/Editor/MB3_MeshBakerEditor.cs:49)
8. UnityEditor.InspectorWindow.DrawEditor (UnityEditor.Editor editor, Int32 editorIndex, Boolean forceDirty, System.Boolean& showImportedObjectBarNext, UnityEngine.Rect& importedObjectBarRect, Boolean eyeDropperDirty) (at C:/buildslave/unity/build/Editor/Mono/Inspector/InspectorWindow.cs:1150)
9. UnityEditor.DockArea:OnGUI()

Are you able to reproduce either of these issues?

 

Hi Topsekret,

Apologies. I am aware of these issues, as I also came across them while making that video. I have submitted a new version to the asset store. Unfortunately there is usually a few days delay before the new version goes live. It should be fixed soon.

I the meantime you should be able to do everything in that video by using the combined TextureBaker/MeshBaker created from the object menu.

Sorry.

 

I uploaded a new tutorial showing how to use the new tools for efficiently adding meshes and creating bakers.

 

Great! Glad to hear a fix for this will be available soon!

Over the past few days we have been testing out MeshBaker and it seems to have been greatly improved since we last used it, so great job! We especially like the new clustering feature; that will save a lot of time for our artists.

In testing the tool, we have discovered a few bugs and have some ideas for features that we think would improve the tool even more, so I'll just list these here and you can tell me whether you think these suggestions are worth while.

Bugs:

1. MeshBaker sometimes sets the platform override flag for the current build target on source textures after baking atlases, even if the flag was not set originally. Maybe it happens in situations where MeshBaker has to temporarily change texture import settings?

2. MeshBaker doesn't automatically set some output atlases being used as normal maps to ImportType Normal. For example, it correctly does this for atlases associated with "_BumpMap", however it does not do this for atlases associated with "_DetailNormalMap".

Obviously, you could hardcode a fix for "_DetailNormalMap" and other Unity standard normal maps. However, it might be better to have a more general solution for normal maps with custom names in users' custom shaders. Maybe if the majority of the input textures are marked as ImportType Normal, assume that the output atlas should be ImportType Normal?

Feature Requests:

1. If texture property is null on an input material, use default value for that texture property as specified in the shader/shader importer rather than always using a black texture.

If an input material does not have a texture reference for a given texture property, MeshBaker uses a black texture for its portion of the atlas. While this is fine if the shader is using black as the default value, if it were using anything else as the default value, the output would be incorrect.

If Unity doesn't expose the default texture for a shader property, it would be worth asking them for this feature...

2. Do not create an atlas for a texture property if all input materials had null for the given texture property. Also, set this texture property to null in the output material.

There is no reason to have to wait extra time for MeshBaker to generate some giant 4096 all black texture when we are just going to immediately delete it afterwords.

(Feature requests 1 and 2 are especially important for people using Standard shader (or similar 3rd party solutions like Alloy). These kinds of shaders expose lots of texture properties, but users are only expected to drag references to the textures properties that they actually need.)

3. Extend tools for adding objects to support arbitrary user-created filters.

A common use case would be if I want to create a filter for separating out objects that user the Standard shader and have their RenderingMode set to Opaque. Or maybe I want to group by some values of a non-texture property in my custom shader.

I would recommend doing this by creating an interface called IMeshBakerFilter (or something else, the name doesn't really mater) with a single function with the signature:

Code (CSharp):

1. bool Filter(GameObject gameObject);

Tools for adding objects would then have an additional field for referencing an IMeshBakerFilter. A GameObject would only be included in the group if it passes all the built in filters and the custom IMeshBakerFilter. By exposing just a single field like this, you give clients unlimited flexibility since they can use things like the decorator pattern to make very flexible custom filters (they could even implement logical operations like AND and OR).

Clients could implement the IMeshBakerFilter interface with a ScritableObject for filters they want defined on a global project level, or MonoBehaviours if they want them defined just locally to the current scene. Of course, there would need to be some custom editor work to support a reference to a UnityEngine.Object that implements a specific interface (probably just make a field for a UnityEngine.Object, but only accept the reference if the object implements the correct interface).

4. Support ScriptableObjects for storing lists of custom shader properties to look for.

Currently, we have to enter in names of custom properties for every TextureBaker in our game. This is tedious and prone to error (especially when artists are using the tool and don't know how to get the actual property names from the shader source code).

It would be very convenient if I could create a new ScriptableObject with a list of the custom properties that I care about, then just have my TextureBakers reference this. (Of course, for backward compatibility, still keep the list of strings.)

5. Add a checkbox to TextureBaker to tell it to ONLY look for shader properties in the custom list (or ScriptableObject list from feature request 4).

There are some situations where we want to completely ignore certain texture properties when combining our materials (with mobile in mind). We can obviously get by with just deleting the output atlases we don't want, but this makes the generation process more time-consuming than it needs to be. So having the ability to opt out of looking for the properties hardcoded in MeshBaker would be nice.

6. Allow users to specify max size of output atlases in TextureBaker.

Often times we have a certain memory budget that we must maintain for a given scene. On mobile we have even more specific constraints since older devices do not support textures larger than 2048. Obviously, we can clamp the output atlas in the import settings, but this results in a lot of wasted space in the atlas that could have been used for higher resolution.

Ideally, if the input textures can't fit into the max size at full resolution, MeshBaker would uniformly scale them down by the smallest amount necessary to be able to fit them in the atlas (this means that the scaling should not be restricted to powers to 2, but that should be fine as long is the atlas itself is power of 2). (Obviously, this shouldn't change the source textures!) Then maybe MeshBaker would just log to the console how much it scaled the textures by.

While this could result in inconsistent texel density, it is a tradeoff we are willing to make for memory gains.

7. Use center of mesh bounds rather than transform position for clustering.

We have some meshes where the geo is offset significantly from the origin (I am guessing these meshes were output from other tools), causing them to be put into bad groups.

If you think that there are some cases where we would rather use the transform position, I am okay with having a checkbox for this option.

8. Support import settings for meshes created by MeshBaker.

We currently cannot change import settings for meshes created with MeshBaker. Is this because they are not encoded as FBX files?



Thank you for taking the time to read my feedback! Let me know what you think!

 

Wow! what a long and detailed post. Thanks topsekret. This is great feedback. Many of these features will be easy to implement so I definitely add them. One thing that I find hard with the asset store is the lack of feedback. I only seem to hear from one in a hundred customers. It is great to hear from someone who is using the tool hard on complex projects. My studio is very small so I am often guessing at the features that may be needed in complex environments.

 

No problem, I'm glad you found our feedback helpful!

Actually, I just remembered a feature our lead artist requested: when baking meshes into prefabs for the first time, he would like the option to have MeshBaker automatically make the output prefabs and store them under the same directory that the associated TextureBakeResults object is stored in. The file name would consist of a prefix, which is the name of the associated TextureBakeResults and a suffix, which would come from the name of the associated MeshBaker GameObject (and maybe a number to keep it unique). This would save a lot of time since it is rather slow when processing large scenes to create empty prefabs, drag empty GameObjects into them, and then assign the references to the MeshBakers.

 

Free Version Of Mesh Baker Now Available!

Some Limitations:

• Only Diffuse and Bumped Diffuse Shaders.
• Can't save combined meshes as assets
• Uses DLLs

 

Does Mesh Baker work with Unity 5?

 

Yes.