Mesh Baker by Digital Opus [RELEASED]

Comparing the skinned mesh baked at runtime to the one baked into a prefab shows that not only is mbDynamicObjectsInCombinedMesh not populated in the prefab version, but neither is the objectsInCombinedMesh list nor the Bones list. See comparison screenshots attached.

I will manually fill those out like I did with the mbDynamicObjectsInCombinedMesh list and see what happens.

 

And last piece of debug info...
The instance IDs of the objects in the mbDynamicObjectsInCombinedMesh were not correct. So the object field was empty and the objects had to be relinked, but then the Instance IDs also had to be corrected to point to the objects in the prefab.
Then I manually added the objects in combined mesh and the bones.

And it got a little bit further into the code for add/delete, but then hit line 842 of MB3_MeshCombinerSimple.cs:

if (settings.renderType == MB_RenderType.skinnedMeshRenderer) { Array.Copy(boneWeights, dgo.vertIdx, nboneWeights, targVidx, dgo.numVerts); }

Which throws an exception because boneWeights has a length of 0.

 

Hi!

How about compatibility with Mesh Animator asset?

 

I am downloading the repo package now. I will import it later today and take a look.

 

I do not own Mesh Animator Asset but read the description and looked at the documentation. It looks like it converts the 3D animated models to sprite animations. I don't see much opportunity for integration here. I think Mesh Animator could convert Mesh Baked characters to sprite animations, it would work .... but why bother Mesh Baking the skinned meshes first? There would be no performance benefit in the final game since the Mesh Baked character is not being used at runtime and I don't think the Mesh Baker character would look any different from the sprite animated character. It might speed up the sprite baking a fraction of a second but I doubt that this is a bottleneck since it is being done on a dev machine before the game is built.

Was there some kind of integration you wanted?

 

I spent some time looking at this today. It is proving to be very difficult to re-construct the internal MeshBaker data in a way that works. I do think I have a solution that may work for you though.

You already have the MeshBaker configured as part of the prefab. "Bake" that Mesh Baker as soon as the prefab is instantiated (you will need to switch it to "bake into scene object" instead of "bake into prefab"). Then all of its references will be intact and instanceIDs correct. After this the show/hide, add/delete works.

I plan to continue exploring to discover why the references are not working, but I don't know if it will be finished soon.

 

Okay, thanks for looking into this.

I will try your suggestion. I assume that baking into scene object at runtime will not have to rebuild the mesh? It will just perform all the linking and setup and then accept the mesh that is already part of the prefab?
If it has to rebake the mesh itself, then I am not getting any benefit from baking into the prefab in the editor.

 

The bake is a full re-bake. It is the easiest way to get the references to remain intact after baking. As you point out there is not a lot of value in doing the bake into prefab ahead of time due to the difficulty preserving references through the baking scene -> prefab asst -> new instance at runtime. This is something I plan on looking into but probably won't have a quick solution for.

 

Hey I kind of need the same as @mlaibow
Generate some NPC's at runtime and then bake their clothing into 1 skinned mesh.
I have mesh baker, but am totally new to it.
Is there some more info on how to start with this?

Only thing I found so far is:
http://digitalopus.ca/site/mesh-baker-3-manual/#runtimeUse
but from the example, it looks like it's mostly for materials...?

Anyway will try the few lines in the manual and see where they get me.

 

There is some example scenes:

• SkinnedMeshRenderer (does it's baking at runtime)
  
• CustomizeCharacterSetup
  
• CustomizeCharacterGame (does it's baking at runtime)

There are some tutorial videos that you might find useful:

I would suggest not trying to do an initial bake in the editor and subsequent bakes at runtime. That is not currently working well. If you do all your mesh baking at runtime it works.

 

hi, it's been a while since i posted in this topic!
am happy with the new runtime baking feature!.. but here is a bug in it.

at runtime using fast mode.. mesh baker seems to bake textures with.. scene fog color!
when i disable the scene fog, textures gets baked correct..

thanks for your support!

 

Which pipeline are you using? I have seen this bug with the HDRP but curious if you are seeing it in other pipelines. I have a new "texture packer fast" option designed to work with URP, Default & HDRP which fixes this and other issues with runtime texture baking on different pipelines. I hope to release it any day now. I am in the final stages of testing ATM hope to release it before the end of the week.

 

thanks for fast replay, i am using URP on latest unity 2019 release.. and yes am using the texture packer fast option.
i using latest meshbaker version available in asset store just 2 days ago.
i tested this on editor with an android project.. i dunno if targeted platform has any effect?


after posting my message earlier, i tested it on android build.. it seems it have more bugs on the build.

if i set the material to be used on combined material field.. at runtime the baked objects do not showup.. i dunno if material reference is lost at runetime??

at runtime if i created a new material with new shader using shader.find.. for example like urp's Simple Lit.. (same as your example script) materials appear black.

i have a small hunch that this might be a unity bug or something on the black material part.. i need to test this more..
but seeing how it works with mesh baker.. material instantiation vs reference.. is it a bug maybe?

 

Hi there,

Is it possible to use Mesh Baker for baking randomly generated maps during "Game" mode? Let's say my map is generated out of ~2K objects and I want to separate them into ~20 logically positioned ones. (Fence, Houses etc.).

Thanks.

 

One thing you need to do with "instantiated" materials and the URP/HDRP is set keywords. Unity actually compiles many different versions of each shader. If some textures are empty (not being used, eg. normalmap). Then Unity selects the version of the shader that has all the normal map code removed. It is faster because it doesn't have all the normal map code. But if you assign a normal map using a script then you need to also turn on the keyword for normal maps so that unity switches the shader to the normal map version. You also need to ensure that all the variations of the shader you might need are included in the build see: shader stripping and
https://docs.unity3d.com/Manual/MaterialsAccessingViaScript.html

This could be why the instantiated materials are showing up black.

 

Yes, the texture combining features at runtime are somewhat limited, but the mesh combining features work well at runtime. It is recommended to bake the atlases in the editor if possible, then you can use those atlases to combine the meshes at runtime.

 

Thanks for the fast response Phong. Do you mean atlases for the whole "house" or is it enough to create atlases for single objects like "wall", "window" etc...

 

hi team

I am working on an iOS game and learning as I go along

1-should I be baking the light map before I turn my 50 odd meshes in a prefab using mesh baker?

unity crashes every time I press generate lighting after I have baked my meshes into a prefab using the mesh baker

thank you

 

Ideally each combined mesh should have one atlas. One thing to keep in mind is that you want to combine meshes that are close together in the scene. The problem with combining "all the fences" in the scene is that the meshes have very large bounds. The entire mesh needs to be rendered even if only a small part of it is visible this can boost the "verts and tris" stat for each frame.

Another approach worth considering is to use the BatchPrefabBaker component. It creates duplicate prefabs for you that share a combined material. You can use these in your scene and Unity's static/dynamic batching becomes WAY more efficeint/effective because there are alot fewer distinct materials being used.

 

Yes, you should be baking the lightmap after combining the meshes. What "Lightmap UVs" setting are you using when baking? You want to use "generate new UV2 layout" or "copy UV2 to separate rects". It may be that you have no UV2 channel on your combined mesh or overlapping UV islands. I think that could cause the lightmapper to crash.

 

thank you

 

another question

I have applied individual colliders to my 3d models as they are spread out everywhere

when I bake them into one prefab then the colliders vanish

when I add a new collider then its one huge collider as my meshes are all over x,y, and z

thank you in advance and have an awesome day

 

from the manual--If the source objects are have Colliders or have scripts on them, you may want to keep the source objects in the scene with the render components disabled.

is this a viable solution for mobile games

 

@Phong thanks for the tutorial.
I get it working for the First LOD0 in the model, but i get stuck with these errors on the other LOD's.

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)
3. DigitalOpus.MB.Core.MB3_MeshCombiner:_CreateTemporaryTextrueBakeResult(GameObject[], List`1) (at Assets/MeshBaker/scripts/core/MB3_MeshCombiner.cs:592)

Code (CSharp):

1. Target Renderer game object is not a child of Result Scene Object was not set.
2. UnityEngine.Debug:LogError(Object)
3. DigitalOpus.MB.Core.MB3_MeshCombinerSingle:ValidateTargRendererAndMeshAndResultSceneObj() (at Assets/MeshBaker/scripts/core/MB3_MeshCombinerSimple.cs:2213)

here's the part of my code:

Code (CSharp):

1. if(mergeMesh)
2.             {
3.                 GameObject[] meshCombineLOD0 = new GameObject[] { body0.gameObject, eyes0.gameObject, hair0.gameObject, shoes0.gameObject, bottom0.gameObject, torso0.gameObject };
4.                 clonesMerged.Add(CombineMeshes(meshCombineLOD0));
5.                 GameObject[] meshCombineLOD1 = new GameObject[] { body1.gameObject, hair1.gameObject, shoes1.gameObject, bottom1.gameObject, torso1.gameObject };
6.                 clonesMerged.Add(CombineMeshes(meshCombineLOD1));
7.                 GameObject[] meshCombineLOD2 = new GameObject[] { body2.gameObject, hair2.gameObject, shoes2.gameObject, bottom2.gameObject, torso2.gameObject };
8.                 clonesMerged.Add(CombineMeshes(meshCombineLOD2));
9.                 GameObject[] meshCombineLOD3 = new GameObject[] { body0.gameObject, hair3.gameObject, shoes3.gameObject, bottom3.gameObject, torso3.gameObject };
10.                 clonesMerged.Add(CombineMeshes(meshCombineLOD3));
11.             }
12.         }
13.     }
14.     private GameObject CombineMeshes(GameObject[] meshCombine)
15.     {
16.         MB3_MeshBaker meshBaker = meshCombine[0].GetComponentInParent<MB3_MeshBaker>();
17.         if (!meshBaker)
18.             Debug.LogError("meshBaker is null, Add a MB3_MeshBaker Component to the BaseCharacter Prefab");
19.         meshBaker.AddDeleteGameObjects(meshCombine, null, true);
20.         meshBaker.Apply();
21.         GameObject createdPrefab = meshBaker.meshCombiner.targetRenderer.gameObject;
22.         GameObject parent = createdPrefab.transform.parent.gameObject;
23.         Destroy(parent);
24.         createdPrefab.transform.parent = meshBaker.transform;
25.         return createdPrefab;
26.     }

I tried emptying

Code (CSharp):

1. public abstract int GetNumObjectsInCombined();

to no avail.

 

Optimizing physics and optimizing rendering is very different.

For optimizing rendering you want fewer renderers/materials (although pay attention to occlusion culling. don't combine far apart meshes that will never be on screen together).

For optimizing collision/physics, you want lots of small colliders for best performance (ideally primitive colliders). The reason is that the the first thing the physics engine does is the "broadphase" collision test. It tests the bounding box of each dynamic physics collider against the bounding box of all the other colliders for intersection. This "broadphase" collision test can be done very quickly even with a huge number of colliders (it is especially efficient if most of the colliders are static). If you combine all the colliders into one huge collider then this test will always return intersection=true and the physics engine needs to do the much more expensive "narrow phase" collision test every fixed update.

The "narrow phase" for a MeshCollider needs to search the individual triangles of the MeshCollider for intersection with the colliding object. This scales with the number of triangles, so a single giant MeshCollider with lots of triangles is expensive. Better to have a lot of small independent colliders with a small number of triangles each (most colliders get culled by the "broadphase" very quickly).

For Mobile you can have thousands of static colliders (they are almost free performance-wise). What can be expensive is large numbers (hundreds+) of dynamic colliders colliding with each other and the static geometry (think stacks of bricks collapsing into a big pile).

 

If you want to "Update" a combined mesh (add or delete meshes). Then you need a TextureBakeResult assigned to the Mesh Baker that has the materials on the objects being baked. Use a TextureBaker to create the TextureBakeResult asset. Idealy this step is done in the editor as it can take some time.

 

@Phong Hey, thanks for the answer.
I can't use Texture baker because I'm not updating the mesh, I'm baking new mesh with the same Meshbaker component.
I can make it work if i add a new MeshBaker component for each LOD. But doing it like that, if i select the GameObject that has the 4 MeshBaker components on it, I get a terrible lag in the inspector.
If I delete the 4 MeshBaker Components after everything is done (Meshes are baked into 1 and LODs on my character are set using the baked meshes) the baked meshes go missing (no matter if i do it manual or through code). This is not the case however if i do everything manually (even during runtime), than the Baked Meshes stay in memory.
What exactly is the difference in code executed doing it manual in editor and doing it from script at runtime?
Do the same 2 functions get called in editor?

Code (CSharp):

1. meshBaker.AddDeleteGameObjects(meshCombine, null, true); meshBaker.Apply();

 

Hi,
I am using mesh baker and it seems to have broken my animations, im sure its something I did, what would be best to troubleshoot?

cheers

 

Is "Clear Buffers After Bake" unchecked? If that is checked then Mesh Baker thinks you are trying to update an existing bake with subsequent bakes. Let me know if that does not work.

One more thing, if you are re-using the same baker multiple times for different bakes you will need to assign it a knew mesh. Mesh Baker keeps a reference to the combined mesh and if you re-bake with new game objects it will overwrite the previous bake. You can assign a new mesh with:

myMeshBaker.meshCombiner.SetMesh(new Mesh());

Note also that you should keep track of the meshes that you create dynamically at runtime and destroy them in OnDestroy().

 

I presume you are baking some animated skinned meshes together and the combined mesh is not animating? Most likely the problem is that the source animators have been configured to cull animations if the skinned meshes are non-visible. Because the source animators are probably disabled = non-visible then the animations stop. You can fix this by:

1. Switch the culling settings in the source animator componet(s) to "always animate"
2. Move the comined skinned mesh in the hierarchy so that it is a child of the source animator. This strategy is only possible if there is only one source animator in the bake.

 

thank you phong

the colliders from the prebaked meshes are working for the new baked meshes as I have disabled the renderer for the prebaked meshes

both the meshes are overlapping

 

now the next challenge

how do I reduce the draw calls on my collectibles (more then a 100)
as all of them are visible on screen at all times

any ideas

 

I can be more helpful if you describe the technical situation in a bit more detail? How many distinct materials do the collectibles use? Can these be combined? How may polys per collectible mesh? Are they all dynamic? How much/how often do they need to move?

Some ideas:

• If they are very low poly you could use dynamic batching or bake them all into a skinned mesh (provided they are all sharing a small number of materials).
• If they are all static most of the time, you could bake them into a combined mesh. When one needs to move you can call UpdateShowHide to "hide" the one that is about to move and enable the renderer on the source object. Then when the moving is done, you can "update show Hide" to make it static again.

 

How do I bake materials together that are the same, other than albedo?



When i followed the steps it becomes all of the same color:

 

I presume these meshes are using different materials and a color tint? Try enabling "Blend non-texture properties". Mesh baker will try to detect if the different materials have different non-texture-property values. If they do then Mesh Baker tries to create a small texture that has the same effect as the non-texture-property and bakes these textures into an atlas. Note that this feature requires some understanding of the shader being used and how the non-texture properties (color tints) affect the textures. This understanding is encapsulated in "texture blenders". Mesh Baker includes "texture blenders for the standard shader and diffuse shaders. If your shader is one of these or uses the stander shader names _MainTex, _Color, then this should work. If you are using a different shader, you could temporarily set the material shaders to "Diffuse" or standard, let Mesh Baker bake the atlas, then switch the shader back and use the baked atlas on the combined material.

If the TextureBlender feature doesn't work for you. You could create some small textures and use those on your source materials instead of the color tints. That should work too.

 

anyone have any idea whats causing this? bottom photo is normal geometry, top is after combining them. i left all settings alone, tried it both with, and without baking the textures (the original texture files are actually smaller than an atlas since theyre just solid colors

 

I think this is caused by UVs outside the range 0..1 (tiling). If you enable "consider UVs" it may fix the problem, however if there is a lot of tiling then it may fill the atlas with many copies of the same image. Another option is to use the Multiple Materials feature and map the tiling material to its own submesh. These options are discussed in detail in this video.

 

its just a coin so its one mesh and one material

but there are Over 100 coins to collect in game and about half of them are visible at any given time

thank you for your time
I really appreciate it

 

Yeah, it is just a Standard shader with _Color set. So there are 3 different colors.

Trying the method you suggested (blend non-texture properties) produced the following:



It did create the small texture you mentioned though.

Is there any other step? I am just following the step in the quick-start manual with the addition of "blend non-texture properties"

Thanks

 

With the new update, it not requires High Def Rendering Pipeline. Our project didn't use that, it use the LWRP.

Is this a requirement for mesh baker?

Code (CSharp):

1. MBVersionConcrete.cpp
2.  
3. #if UNITY_2019_3_OR_NEWER
4.     using UnityEngine.Rendering.HighDefinition;
5. #elif UNITY_2018_4_OR_NEWER

It's not used anywhere in the code, so I removed the import for now.

 

"Object default in the list of objects to mesh uses a Texture that is not a Texture2D. Cannot build atlases."

How to I identify this problematic gameobject/texture and remove it?

 

At the risk of sounding very stupid, is there any possibility to integrate Mesh Baker and GPUI together or would they bug eachother out? The part I like about GPUI is the baking of the animations into he mesh reducing bones. I need to render a lot of units in my project and that seems like the most similar to what was done in ultimate epic battle simulator.

Cheers

 

If they are low poly I would consider baking them into a skinned mesh. There would be one mesh (drawcall for all the coins). Each coin becomes a bone. You could use either the "ShowHide" API to hide coins as they are consumed or hide them by scaling them to zero or moving them behind the camera.

 

Thanks for letting me know. Please remove that line if it is causing a compilation error. HDRP is NOT a requirement for Mesh Baker, but there is some custom-HDRP-only code that should be hidden from non-HDRP projects. Looks like it is not successfully hidden. I will submit a fix ASAP.

 

Did you re-bake the mesh after re-baking the atlas?

If that doesn't work then one other setting you might need is "consider UVs" if there are UVs outside the range 0..1.

Also note that the atlas may be very small, It is very easy with tiny atlases for pixels to bleed over the boundary between rectangles. Make sure you have at least a few pixels padding. Also you may want to try setting the atlas TextureImporter to "filter mode = point" This works well when the atlas consists of blocks of solid color. WrapMode = "clamp" may also help if you.

 

When you say GPUI, I presume you are talking about GPU Instancing? I was not aware that that was possible for skinned meshes to GPU-Instance although there is this very interesting semi-experimental technique described in a Unity blog (is this what you were referring to?):

https://blogs.unity3d.com/2018/04/16/animation-instancing-instancing-for-skinnedmeshrenderer/

I think that Skinned Meshes that have been baked with Mesh Baker would work with this technique, although I am not sure if there would be an efficiency boost or not (Disclaimer: I have not tried the github code). It is very interesting I might investigate if this is what you were considering.

 

I think the object is called 'default'. Is there an object with that name in the list of objects to combine? What kind of texture(s) is it using in it's material?

 

This article describes how it was done in UEBS

https://www.theringer.com/2017/4/21...r-interview-achievement-oriented-c6569970b70d

 

Thanks, fixed it.

Is it expected that we have to rebake lighting for the newly baked meshes/textures? Any way to use existing lightmaps?

 

There is an option to "preserve lightmapping", but apparently it doesn't work since Unity 5.

@Phong, could you clear up a thing for me, please?

All of my (over 200) textures on the scene used hand-picked compression. The algorithm is the same - Crunched RGB DXT1 - but the RESOLUTION ("max size") and QUALITY settings vary a lot (on top of the source textures originally being different sizes, of course). The reason they vary is I hand-adjusted each one according to how imporant/visible to the player the texture is, compression settings allow me to do that without changing the original.

My question is, does Mesh Baker atlas packing algorithm take into account the varying compression resolution/quality settings of the source textures and preserve it in the atlas? So that textures that are big for quality (close ups) reasons stay big, and the small textures (far away, uniform color, etc) stay small? And if resizing takes place, that it preserves the "ratio" of big to small textures compared to each other.

I should mention I'm building for Android.