Mesh Baker by Digital Opus [RELEASED]

Yes... with limitations.

By default Mesh Baker will bake all the materials on an object into a single material. If you want the combined mesh to have multiple materials then you need to use the multiple-materials feature. If some of the materials used tiling, then this tiling gets baked into the atlas. There are some limitations to collapsing the materials into a single material:

1) The submeshes may have different materials because they are using significantly different shaders (eg. transparent, opaque). If this is your situation then they probably cannot be combined.
2) If there is a lot of tiling then the baked tiling can exceed the size of the atlas. The textures get scaled down and loose quality. This can also use a lot of memory.

The flickering sounds odd. By any chance do you have overlapping geometry (triangles are on more than one submesh) I think that could cause the z-fighting/flickering you are seeing.

 

Hi Steve,

Mesh Baker does not currently support TextMesh. TBH this is the first time that somebody has requested this feature.

Mesh Baker does have a TextureArray workflow, but the workflow is for generating texture arrays and combined meshes capable of using them from source models that use regular textures and shaders. It sounds like you have source models that already use texture arrays that you would like to combine together. Is this the case? I would be interested in hearing more about what you would like to do. It may help me improve Mesh Baker to handle different situations. How are you generating the TextureArrays that you are currently using?

 

Of course I don't expect that the TextMesh will get baked. I did expect that the GameObject with the TextMesh gets copied "as it is".

Yes I saw that and bought it because of that. But I misunderstood and thought it will support TAs in the source model .
We have a game where players can build structures using building blocks in game. Also our modellers build structures in that way. These structures get pretty big and I am searching for a way to optimize them in an easy way. We are currently using TAs for parts of the structures, as well as TextMeshes within the structures to display in game information.

So MeshBaker would be useable for us, if it did copy GameObjects that contain not known render components (but this I could solve also on my side ) and if it supported TAs. But I assume none of your customers has TAs in the source model, so I don't expect that you add that only for me.

 

Hi Steve,

Re TextMesh, for clarity, I presume you are baking into prefab? And you would like the TextMesh gameobject copied into the prefab? I would consider adding that feature.

Re the TextureArray. This is something I would consider adding. The messiest bit would be finding the slice indexes in the source meshes to be re-mapped and embedded in the combined mesh. Are you using UV.z for your slice index? I am not sure how much of a standard it is to put the slice index there.

 

Hey Phong, thanks for your interest! The longer I think about it, the more I have the opinion that there is way too much to change to get it running for our needs. Let me send you some details as PM.

 

Hello @Phong!
I am using the Mesh Baker at runtime and have a question. In my case, I want to combine several group of objects one by one and to use result in a scene independently. Is there any way to do that without creating multiple MeshBaker objects and to use just a single MeshBaker? Because if I use a single MeshBaker object and do smth like this

Code (CSharp):

1. private static void _BakeIntoCombinedSceneObject(MB3_MeshBaker baker, GameObject[] array)
2. {
3.      baker.ClearMesh();
4.      baker.AddDeleteGameObjects(array, null, false);
5.      baker.Apply();
6.      Debug.Log($"Successfully baked {array.Length} meshes");
7. }

baker always rewrites previously generated mesh and I always get several objects with same mesh. Is there right way to cleanup a MB3_MeshBaker? Because now I need always create new one for each combine operation.

 

Hi Rolemancer,

Yes, there is a way to do this. In the Mesh Baker inspector there is a "Mesh" field and a "Combined Mesh Object" field. If you set these to null, then Mesh Baker will create a new mesh and assign it to a new CombinedMeshRenderer game object. You can re-use the MeshBaker for future bakes. I would also recommend using "Clear Buffers After Bake" = true.

In the API these fields are in the MeshCombinerSimple class.

Code (CSharp):

1.         ((MB3_MeshCombinerSingle) mbd.meshCombiner)._mesh = null;
2.         mbd.meshCombiner.targetRenderer = null;

Unfortunately the "_mesh" field his private. You will need to make the is public to access it. (Line 112 of MeshCombinerSimple.ca). I will be sure to add a method for setting this in the next release.

 

Thanks a lot! It works!

 

Hello

Please take a look at my situation.

I have a building tile object made of prefabs.

When a mouse click event occurs, this tile is created in the world and is created through the "instantiate" function by randomly selecting a few from the pre-prepared building partial mesh arrangement.
In other words, one building tile object has several building parts as child objects.

I used a mesh baker to combine the child objects in this part of the building at runtime, but it works very well when I first try it, but when I try to combine new building tile objects using the same mesh baker object, the error below occurs.

"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'"

So whenever I create a building tile object, I implemented it in a way that combines it using a new mesh baker.

What I'm curious about is that this is the right way?

I wonder if there is another way.

Or is there a way to add newly created building part objects to building part objects created through mesh baker at runtime?

best regards.

 

Hi MRBaek,

Each MeshBaker component manages one mesh and MeshRenderer. If you use it to re-bake, it will overwrite your previous bake. There is a way to do this (reuse a mesh baker at runtime for multiple bakes).

1) Set "clear buffers after bake" to true
2) Do your first bake
3) Do this after each bake

1. ((MB3_MeshCombinerSingle) mbd.meshCombiner)._mesh = null;
2. mbd.meshCombiner.targetRenderer = null;

Unfortunately the "_mesh" field his private. You will need to make the is public to access it. (Line 112 of MeshCombinerSimple.ca). I will be sure to add a method for setting this in the next release. If you do this you should be able to re-use one MeshBaker for multiple bakes.

Warning: If you do this you will "leak" meshes in your scene. When you change scenes, these Meshes may not be released/cleaned up (check the memory profiler). You may need to keep a list of the meshes and destroy them yourself when the scene changes or call AsyncOperation UnloadUnusedAssets(); from your new scene after the scene loads.

 

thanks for advise

i will try your approach.

 

Hi there, I am trying to add the TextureBlender script to an object in my scene and Unity is throwing error saying the class TextureBlender can not be found and there might be a compile error but I can not see any? Do you know what might be the issue? thanks

I can confirm the TextureBlender interface is present.

 

Hello,

The "TextureBlenders" are not "Components" so they can't be added to GameObjects like the MeshBaker and TextureBaker components. Can I ask what you are trying to do? The TextureBlenders are designed to be used internally during the baking process. I am not sure how useful they are outside of that context.

If you are trying to use a TextureBlender inside another script, you will need to add this at the top of the other script file:

using DigitalOpus.MB.Core;

Does this help?

 

Yes, that helped, I got it into my head that I needed to assign the script for the correct shader to the baked objects as I wasn't seeing the blending settings reflect on material bake. I think I may have needed to rebake the mesh for real-time changes to propagate properly. Thanks for the pointer, makes sense and got the behavior working as wished.

 

Hi @Phong,

big fan of you asset! I started a new URP project and am trying to bake my modular character.

I tried the both, the normal fast baker and fast baker version two, but both have issues (but no errors in the console):

fast baker version two

Everything works fine in edit mode, but at runtime I have problems with the normal maps. They get baked fine but the resulting texture is not marked as normal map. That leads to weird lighning artefacts on my characters. When I switch out the runtime generated normal map with the one I created in editor mode, everything looks fine again. The normal map created in editor mode used RBA, while the runtime texture is in RGBA.

Another weird thing, only after I open the generated material in the inspector and also open the toggle to show the material properties, the occlusion map finally gets applied. Before it looks as no occlusion map was used at all.

fast baker version one

Has the same normal and occlusion map issues as version two, but on top all textures (albedo, metallic, normal etc.) have some weird gray overlay in the baking result. Its hard to discribe, it's not all gray but some gradient on a corner and the other corners being gray or a clear spot in the center and the corners all gray.

Actually I dont mind baker version one, on working runtime packer would be enough for me

I stayed stricked with your tutorial and have no idea, what I am doing wrong. Do I have to create a custom shader now to make the normal maps work?

I can mail you a bunch of screenshots if needed.

 

Small supplement:

I managed to find a workaround for my project by using the better lit shader, which uses packed textures (the normal map is saved in only two channels, occlusion in another one). So I dont need unity's normal map setup for this shader, your texture baker works like a charm with it (even faster because less textures to combine) and the results are looking perfect.

So from my side, I am happy. But in general, the problem is still there..

 

Thanks for alerting me to this. I will definitely look into the strange normal map behaviour. It is a challenge working with the different render pipelines. The whole reason I created the fast baker version two was to deal with strange rendertexture beahviour differences in the different pipelines.

The URP is hard to work with at runtime. The inspector for the URP does more than just store settings, it sets a bunch of Material shader keywords. If you are assigning stuff to the URP shader at runtime you need to set these yourself in your code. Unfortunately it can be quite complicated to figure out what keywords need to be set: eg. https://forum.unity.com/threads/upr-lit-shader-specular-setup-keywords-scripting.825519/

 

Hi! I would like to combine meshes at runtime, instantiated from the same prefab. The prefabs are lightmap-baked with Bakery, and the "preserve lightmap" option does not work... this is on Unity 2021.2 with the "progressive" lightmapper on URP (and bakery). Is there any chance that might get fixed at some stage..?

 

I will take a look. It is a moving target. Unity keeps changing the lightmapper. ATM the reliable way to lightmap is to use "Generate new UV2 Layout" or "copy UV2 to separate rects" and re-bake the lighting. However at runtime it is probably not viable to re-bake the lighting.

It won't be a quick fix. Will probably take a few weeks before I get anything.

 

Hi! After combining textures and materials, can we generate meshes with new UV coordinate "without" combining them?
We would like to use it something like a texture atlas genertator and keep the meshes seperated.

 

When creating texture atlas can certain important textures occupy more space in the atlas than others eg. the character head texture?

 

Yes, you want to use the Batch Prefab Baker:

You can create duplicate prefabs with meshes that have adjusted UVs. You can use these in your scene in place of your prefabs. It also includes tools for swapping the prefab instances in your scene with the adjusted UV ones.

 

Mesh Baker uses the "Max Size" in the Texture Import Settings:


You can can make the face use more space in the atlas relative to the other textures by setting the face to have a large "Max Size" and other parts of the character to have a smaller "Max Size". However this feature is capped at the size of the original image file on disk. So if your face is a 256x256 face.png file you will never be able to get the face to be larger than 256x256 in the atlas (unless you scale up the image file).

 

Stupid question, but I just imported meshbaker and I'm looking to add it to my scene. The instructions say to add the Mesh Baker object from GameObject-> Create Other -> Mesh Baker -> MeshBaker but when I open GameObject, there's no Create Other entry. Any help would be appreciated, thanks

 

Are there any compile errors in your project (Check the console)? If so then these need to be resolved before the Mesh Baker code can compile and will be available. If there is a compile error with Mesh Baker please let me know. I would like to know how this happened to ensure that it doesn't happen in the future.

If there are no compile errors, What version of Unity, build platform an pipline are you using?

 

There weren't any compilation errors, but I deleted it and re-installed it and everything seems to be fine now, I guess. I think it may have been an error on import or something. Thank you for your helpful response, it led me to try the re-installation.

For posterity, I'm on 2020.3.25, built-in render pipeline

 

Hi,
I need to bake an object's texture in runtime as is, including the normal map, lights and shadows.
Can this be done with your plugin? If so, will it be exactly the same?

 

This will probably work for you.

If baking textures at runtime I recommend using "Texture Packer Fast" or "Texture Packer Fast V2". Even then baking textures is an expensive operation. I recommend pre-baking the atlases in the editor if practical.

I am not sure what you mean by "lights and shadows", are these the renderer settings? This will work fine as long as all the source objects use the same settings. If you have one source object that uses shadows and one that does not and you bake these together then the entire combined mesh will either cast shadows or not. Same with the lights.

If your source objects use lightmaps, then it will work if all the source objects use the same lightmap. Lighting will break if different source objects use different lightmaps.

 

Hi Phong congratulations on a great product!

1) Recently I modified it locally to support 8k Texture arrays, I wondered if you'd be willing to do the same to the original, as 8k ASTC12x12 files are useful on Quest 2, they work out at 9.5mb including mip map levels?

2) When you compress, are you using 'Best' as opposed to 'Normal' or 'Fast'?

3) The resulting material file gets appeneded with 12x120 but I think it should be "12x12"?

Gratefully

 

Hi Eclectus, thanks for the feedback.

Re: 1) I will look into that. I don't think I tested with 8k Texture arrays.

Re: 2) I believe that Unity maps "Best", "Normal", "Fast" to a specific compression format for the platform. See this manual page. https://docs.unity3d.com/Manual/class-TextureImporterOverride.html. When using TextureArrays with MeshBaker, you chose the Texture Array Output Format = "specific compression format" directly. For example: "RGBA Compressed ETC2" == Medium compression on iOS.

Re: 3) I think the trailing '0' is a number that is getting appended to the material name. Sometimes there are multiple combined materials xxxx0.mat, xxxx1.mat, xxxx2.mat.

 

Thanks Phong,

With 2) I should have provided more detail - yes I have been able to choose the Output Format:

However what I want to do is also specify the Compressor Quality as shown in the Inspector window for a texture above. It is mentioned in MB3_TextureCombinerEditorFunctions.cs at line 321 to 323:

Code (CSharp):

1.              *    Overrides per platform (iOS, Android ...)
2.              *          Format is a concrete algorithm like ETC, ASTC, BVRT
3.              *          Compressor Quality (Fastest, Normal, Best) These are abstract, not sure how this affects format

Below you can see the MB3_TextureBaker is allowing me to select ASTC 12x12 blocks, however I am unsure/unalble to specify that I want to use the 'Best' 'Compressor Quality' when compressing the original .tga images to create the Texture Array.


I haven't looked deeply into this, but am happy to modify to code if there is needed, thought I'd ask about it first.

3) Ah this makes sense! I get it yes

4) I hesitate to write this as I don't want to sound demanding - Instead I want to describe what I am trying to achieve and open the door for you to instruct me in a better way if one exists, since you know more about this domain.

1. I have two 'per material values' that I used to control 'triplanar scale' and 'triplanar normal power'.
2. These values are independent per slice in the TextureArray.

My current plan is to put them into two separate arrays within the shader that I use with the Texture array.

Code (CSharp):

1. uniform half        _textureScaleAmounts[8];
2. uniform half        _textureNormalPowers[8];

I will then need to set these values from a script with a reference to the TextureArray's shader, index them using the slice index, and ensure that they stay up to date.

But I am open to a more elegant solution?

Cheers!

 

Hi Eclectus,

I will take a look at that part of the code and report back. It may be that you are right and I need to add a field that sets the ASTC compression quality as well as the format.

Regarding your point (4): are "_textureScaleAmounts" and "_textureNormalPowers" going to be per-material properties or per-renderer properties?

If they are per-material (lots/all renderers share the same settings) then I think you can just make _textureScaleAmounts and _textureNormalPowers a material property and set these values with a script.

If they are per-renderer, then you might need to consider something like MaterialPropertyBlocks like https://docs.unity3d.com/ScriptReference/MaterialPropertyBlock.html

 

Hi,

I wonder if the following functionality exists in MeshBaker.
Take a look at this model shown in Blender:


I'm looking for a tool that can optimize the texture to be smaller by creating a new texture that is atlassed with just the parts of the original texture that are being used by the UV islands. It would then move those UV islands according to the new texture atlas layout.

The "Consider mesh UVs" option of MeshBaker sounds like it should do this but I wasn't sure.

Thanks!

 

Yes, this is what the "consider mesh UVs" feature does. It will extract only the "used" part of the original texture.

 

And is it possible for MeshBaker to simply create updated versions of the meshes in question instead of combining them? I don't want them to be combined, just their UVs to be updated so that they can use the new, smaller texture.

 

I Ecl

Yes, you want to use the "Batch Prefab Baker". It will create new meshes that have modified UVs that can use the atlas texture, but doesn't combine them.

 

Hi Eclectus,

I checked into this and believe that the compression of a texture is fully specified by its format. For example the ASTC_12x12 block footprint format has a compression of .89 bits per texel. Where the ASTC_4x4 block footprint uses 8 bits per texel. You can't have ASTC_12x12 with high, medium and low compression levels. https://en.wikipedia.org/wiki/Adaptive_scalable_texture_compression

In the Texture Inspector Unity hide the actual format and gives you a choice of Format: (RGB, RGBA,....) Compression: (none, low, normal, high). These are not true texture formats or compression methods. Unity uses these choices along with the selected build platform to choose a specific format. In the MeshBaker, TextureArray inspector you choose the specific format directly this defines the compression level.

 

Hi Phong,

What you say is correct, in terms of the bits per pixel, yes. And the article you've linked to is familiar too. But Compressor Quality doesn't relate to the size of the generated texture, it relates to the amount of time Unity 'thinks' about it during build time. Allow me to quote Ben Golus, as his words are clearer than mine:

"For iOS (and some Android formats) you get a "Compression quality" setting which is purely build time. The compressed texture asset generated and used by the game is the exact same file size and performance regardless of which option you choose. This will have no bearing on load times for the user. But a single large (say 4096x4096) texture set to best quality could take several minutes to an hour to compress (depending on your computer). The build time for a project with a lot of textures can be significant if setting them all to Best. Generally leave them to normal, and only set textures to best when absolutely necessary. You may want to set a texture to low temporarily if you're modifying it frequently." - https://forum.unity.com/threads/compressor-quality-fast-normal-best.503661/

and

"Compressor Quality doesn't change the format, only how long the compressor spends trying to find the best match to the original art, or various other heuristics it might use to determine the "best" quality. All GPU hardware supported texture formats have one thing in common, which is they have a constant memory usage for each block of pixels regardless of the contents. Different textures have different block sizes and memory usage per block."

"Different compression formats work in different ways, and there's no one way to compress. All GPU formats are also lossy so a decision about what data to lose has to be made. Some compressors try several different combinations of data loss and compares with the original to try to find the "best" option. It might try hundreds or thousands of combinations and still not find a "best" one, so usually you're setting a time or iteration limit. That's what the Compressor Quality is changing between, different presets with max iterations or time limits." - https://forum.unity.com/threads/compressor-quality-fast-normal-best.503661/
​

I can and will provide graphical evidence of this if you want me to, but I think then when it is described as a 'build time' parameter, the words make more sense? Sorry about the lack of context before. I know from your work that you value precision, so I think you'll be quite interested by this concept of spending more iteration at build time to achieve a more accurate result, that doesn't take up any more space. Of course, packing a whole Texture Array at 8,192x8,192 at 'Best' quality, is something you only want to do infrequently, however once done, the results will literally be the best they can be, without any change in memory size.

Thanks yes indeed these are per material, and I'm setting them via a script both at Editor time in a Custom Editor and at runtime via a MonoBehavior.

Once again, thanks for your thoughts in this area - I hope that what I'm suggesting may add value to your (already impressive) product, by providing extra 'quality choices' at build time, like Unity does? My hope is that this can all be done through existing Unity API code, and simply passing in a parameter to it.

 

Ahhh, I understand your point now. I was not aware that this is what Unity was doing with the different texture compression options. Mesh Baker could set this, but it is a bit tricky. Texture Arrays do not have an importer like Textures do which allows us to switch the format. The format gets set when the Texture Array is created and can't be changed. Mesh Baker converts all source textures to the TextureArrays's format (with the same mipmaps, channels etc...). Then the data in the source textures can be copied slice by slice into the TexureArray. After this, the source texture formats are restored.

In order to switch the format, Mesh Baker uses the TextureImporter. It does this in

MB3_TextureCombinerEditorFunctions.cs
ConvertTextureFormat_PlatformOverride(Texture2D tx, TextureFormat targetFormat, bool isNormalMap)

I am currently using the default compression. This function is a bit tricky. I will need to look into what is involved with adding a "compression quality" setting.

 

Thanks Phong! I will see if I can dig up any additional information that may help from my side, and if I find some I will post it here to help out.

 

Hi Phong, more information to come I hope, but for now I thought I'd share this:

https://forum.unity.com/threads/trouble-generating-compressed-texture2darray-with-mipmaps.900005/
Shows the use of:

Code (CSharp):

1. EditorUtility.CompressTexture(dest, format, TextureCompressionQuality.Best);

Which is described here https://docs.unity3d.com/ScriptReference/EditorUtility.CompressTexture.html

Is this compatible with MB3_TextureCombinerEditorFunctions.cs or should I look further?

Cheers

 

Hi Eclectus, thanks for sharing the link. Interesting read.

Sorry this is taking a while. It is actually fairly complex and I want to be sure that I completely understand how this all works before giving you advice. I need to understand how EditorUtility.CompressTexture interacts with a texture's AssetImporter which also has control over a texture's compression. I think (but am not yet sure) that what I need to do is set:

• TextureImporterPlatformSettings.textureCompression: none, low, med, high (I believe this affects which format is chosen)
• TextureImporterPlatformSettings.compressionQuality: 0..100 (I believe this affects how long Unity spends compressing)

These will be set in TextureCombinerEditorFunctions.cs _Set_PlatformOverride_2017(). Once I confirm this works then I need to add the compression settings to the UI and pass this setting through all the functions.

 

Hello Phong, I am glad it was of use, and I both recognise and empathize with the complexity of this...

The fact that there are both of the TextureImporterPlatformSettings you have mentioned above, and how "EditorUtility.CompressTexture" interacts with it all, well there was plenty to think about.

I feel patient, and am definitely grateful to you for looking at this - it is natural that it would take a while, as even once a piece of functionality is confirmed, it still needs to exposed in the UI as you say, in an intuitive and maintainable manner, that fits with rest of Mesh Baker. As a fellow programmer, I do understand

Much appreciated,
Daniel

 

After using Texture Baker for the modeling of Sketchup(.skp) 2018, I used Mash Baker and saved, and a Crash Error appears. Is there any solution?
Mesh Baker worked normally before Save.

Mesh Baker 3.34.3 is in use and Unity 2021.3 LTS is in use.

Do you have any data you need to report the error? I submitted it to the Bug Report when it crashed after saving.

-----------
And I'd like to ask you something else question.
Is there a way to extract the compressed modeling with Mesh Baker as FBX?
I wonder if there is a way to optimize capacity.

 

Is the crash repeatable? Does it happen for example if you bake the meshes then save? Without a repeatable case it will be very hard to diagnose. If you can grab the editor log:

https://docs.unity3d.com/560/Docume... Windows, the Editor log,\Unity\Editor\Editor.

Immediately after the crash (before you re-start unity). The last few messages often contain useful information. If it is repeatable and you would be willing to share your scene? I would love to take a look at it.

It may be that this is a Unity problem not a Mesh Baker problem. The Unity editor does crash on me every few days even when not using Mesh baker.

Re: exporting as an FBX. Unity has a package called FBX Exporter. This can export Unity Meshes as FBX files that can then be modified and re-imported into Unity.

https://docs.unity3d.com/Packages/com.unity.formats.fbx@2.0/manual/index.html

 

This here

Save error after Bake.

 

I had a look at the error log. I think the crash is happening because you are running out of memory: According to the log you are trying to bake 33405 meshes into a single combined mesh. That is a lot of Meshes. If each of these meshes has 1000 vertices, that would be a mesh with 33 million vertices, the computer would need a single block of continuous memory approximately 2 Gig in size to store this combined mesh. The crash is happening because it is unlikely that the computer can find a continuous block of memory like this and is probably having trouble rendering it because it needs to feed this giant block of memory through the graphics card in one drawcall.

I would suggest trying the MultiMeshBaker to split the combined mesh into many, separate combined meshes. I would recommend keeping each mesh to a max of 64k vertices'. You probably won't crash with this setup, although you will probably find the scene is huge and takes a long time to load and render.

 

I have to use Multi Mesh Baker.

Then, is it possible to prefab with Multi Mesh Baker and extract it with FBX?

 

It is possible to prefab with MultiMeshBaker but you will have many different meshes. I am not sure how easy it is to export many different meshes.

 

Hi Daniel,

I have made some modifications which add "compressionQuality" to the output formats. If you are interested I could send a pre-release copy to you. Would love to get your feedback before releasing this to the asset store. Email me if your are interested in trying it out:

contact.digitalopus@gmail.com