MudBun: Volumetric VFX Mesh Tool - [Official Thread]

MudBun version 1.0 has just been released!
This is the official thread for asking questions or giving feedback regarding MudBun.
You can also do so at the official Discord server.

Asset Store Page
Animated Details | User Creations
Manual | Email | Discord
Trial Version

MudBun is a real-time volumetric VFX mesh tool. It procedurally generates meshes from non-destructive "brushes" that define volumetric shapes, and surface modification. MudBun is intended for localized VFX, but it can also be used for volumetric modeling and provides a convenient auto-rigging feature.

Various production-ready preset materials are provided and can also be used as examples for creating custom materials using Amplify Shader Editor. Unity's shader graph is not supported due to lack of a certain feature.

Many knobs are provided for the splat render modes, offering flexible visual customization.

A new addition to version 1.0 since beta is the decal render mode. In addition to the existing render modes for procedurally generated volumetric meshes, the decal render mode can render volumes as decals.

There is also a 2D mode where the procedural mesh can be generated on a 2D plane. It is more efficient than its 3D counterpart, and can be fit for creating various 2D effects in both 2D and 3D games.

Features (details with animations):

• Volumetric mesh generation & modeling.
• Built-in VFX & primitive brushes.
• Distortion & modifier brushes.
• User-defined custom brushes.
• Brush groups (compound brushes).
• Render modes: smooth mesh, flat mesh, circle splats, quad splats, decal.
• Meshing modes: marching cubes, dual - quads, surface nets, dual contouring.
• Dynamic voxel density.
• 2D Mode.
• Mesh collider generation.
• Mesh locking & auto-rigging.
• Mesh auto-smoothing.
• Automatic vertex welding of generated mesh.
• SDF texture generation (for GPU particle collision).
• Smooth corners for dual contouring.
• Render pipelines supported: built-in RP, URP, HDRP, and custom RP.
• Custom Amplify Shader Editor nodes.
• Borderless voxel workspace.
• GPU memory budgeting & auto adjustment.

 

This is awesome !

FYI when I downloaded the trial it was a .tar file - I just renamed it to .unitypackage and it imported fine.

 

That's odd. I have the file on the server as a .unitypackage file and the same goes with the download link.
I was able to download it as a .unitypackage file using Chrome on Windows 10.
Perhaps your browser or OS somehow automatically converted the extension to .tar?
At least after manually changing the extension it still works.

 

Been messing with this for a few days, it's great!

Small feature request: it'd be great if you changed the paths for all the file loads to not be hard coded. Many people move third party assets out of the root folder to not clutter up larger projects with various plugins.

Also, I'm curious if this has been tested on consoles that support compute shaders & what that performance looks like

 

The most I can do is to make the material reference GUID-based instead of path-based. However, the same can’t be said for shader includes. It is a conscious decision to use absolute include paths rather than relative paths, because users can create custom shaders using the provided shader nodes and are free to place the custom shaders wherever they want, and relative include paths will likely break. That means certain files just have to stay put and cannot be moved, so the best option IMO is to not allow the moving of the MudBun folder, compared to allowing the moving of *some* files, which can get really messy.

MudBun has not been tested on consoles.

 

Cant you just use Plugins/MudBun as the absolute path ? That's probably a good compromise for most people

 

But then there's the camp that prefer naming the plugin folder "Plugin" instead of "Plugins", much like some prefer naming a script folder "Script" rather than "Scripts".

I think this is a tricky problem where there is no solution that can satisfy everyone, and the best solution is for Unity to provide a way to support custom shader include paths.

Unfortunately, it looks like custom shader include paths used to be supported, but Unity removed it:
https://forum.unity.com/threads/shaderincludepath-is-deprecated-what-to-use-instead.573910/

 

Hey! Great asset, amazing work, I loved it. I tried to build on and Android device but nothing shows up. I only wanted to see Auto-Rigging example on my mobile device (Samsung Note 9).

I am using trial version btw. If I see Auto-Rigging scene working on my device, I will buy the full version. Can you help?

Thanks!

 

Hi:

Windows is the only platform under active development and testing at the moment.

 

Hi! The asset looks splendid, great UX so far.

Few questions:

• Is it possible to lock a splat mesh using the mesh renderer approach? It seems to revert to a smooth mesh whenever I try.
  
  
• Could the builtin RP shaders potentially be written using a vert/frag approach instead of vert/surf? I looked briefly and it seems possible, but I'd like your confirmation. I'm especially asking for the splat shader, but I guess the question is general.
  
  
• Is it possible to pass instanced shader properties to Mud Renderers? I see MudRendererBase has a m_materialProps field, but it is not exposed. Our render stack relies heavily on instanced properties for GPU instancing so that would be a dealbreaker for us.

Oh and a bug report:

• When using a splat renderer with Camera Facing and/or Screen-Space Flattening enabled, it looks like the shadows don't follow properly (they render as if the splats weren't reoriented at all). From my experience, this usually happens when your vert shader modifies the vertex positions, but you don't apply the same vert transform in the depth/shadow passes.

 

Only locking splats in procedural mode will retain the splat look. Locking in mesh renderer mode will always change render mode to mesh.

I don't see any reason why you can't use fragment shaders rather than surface shaders.

Can you clarify what you meant by instanced shader properties? Guessing from your need to expose m_materialProps, do you intend to assign a shared compute buffer used in your custom shader? I can see the need for that. If being able to access m_materialProps is all you need, it should be an easy thing to add in the next update. And if you have the full version, you can add a public property that exposes m_materialProps as a temp workaround.

The fixed splat facing during shadow pass even when camera facing is on is intentional. Ideally, I'd like the splats to face the shadow camera during shadow pass, but it seems the Unity's built-in shader constant for camera always contains data from the main render camera, even during shadow pass (I'm hoping that there's a way to access the shadow camera info which I just missed). The next best thing IMO is to let the splats remain unaffected by camera during shadow pass.

 

Hey, thanks for the very quick reply.

1. So basically if we can't lock to mesh, that means splat rendering, even with editor-only-then-lock use, is unsupported on platforms without compute buffers (and untested on every platform but Windows), correct? That would be a shame. Unless I misunderstood and procedural lock also supports editor-time baking and doesn't require mesh generation in the player?

2. I need to pass instanced properties to my render material. For example, let's say my renderer's material has per-instance color, then I need to be able to pass those. I don't need to pass instanced properties at the compute mesh generation phase. I do have the full version to make source edits, but I'd love for this to be supported built-in.

3. Could there be a way to enable splat facing to adjust to the main render camera? Perhaps as a checkbox? I'm aware this would only work in single camera setups. But fixed splat shadows artifacts are highly noticeable in my main use case, which is vegetation (leaves and grass). If we can't fix these artifacts I don't think we can use Mudbun going forward. :/

Video of fixed splat shadow artifacts:

 

1. Correct. Procedural mode still uses the results stored in compute buffers. It's just not re-computed every frame. Supporting splats in mesh renderer mode, as well as directly using shaders meant for procedural mode (rather requiring a separate shader for locked meshes), is on my long-term to-do list. When I first attempted it, it turned out to be much more complicated than I expected, so I expect it to take quite some time to finish. Unfortunately, I don't have an ETA.

2. Exposing the material property block would be very easy. I'll add that to the next update.

3. So you'd actually want an option for the shadows to align with the camera-facing splats? That would mean if the main camera view direction is perpendicular to the shadow-casting spotlight's direction, then there would be little to no shadows, because the camera-facing splats are perpendicular to the light source. Is this what you'd like? If there is a need for it, I don't see why I can't provide it as an option, since it is an intentionally disabled feature.

 

Again, thanks for the quick reply.

1. Thanks for clarifying. I understand MudBun has not been tested on consoles, but apart from performance (assuming the mesh is locked), do you anticipate any reason why it would be downright incompatible with current/next gen consoles? (PS5/XSX/XSS)

2. Great, thanks!

3. Yes. I hope we're understanding each other here! In my example case, I use camera facing to treat my splats as grass blade planes. I'd like their shadows to match their adjusted geometry, that is, "vertical" planes rather than "horizontal" planes. Of course, if the sun was shining straight down, then grass wouldn't cast any shadow, but that's the "expected" result.

Before you spend time adding #3 into an official release, maybe you can point me towards a shader or script I could tweak to test it on my end to save you some time? I'm comfortable editing both.

Cheers!

 

1. I can't think of any reason off the bat why MudBun would be straight up incompatible on consoles. It runs fine on DX11, so I think there's a chance it runs fine on XSX. It used to run on Vulkan but it broke at one point (not sure why, but I'm guessing it has something to do with the number of simultaneously bound compute buffers). I'm not sure if it will run on PS5, since it uses its own graphics API different from the tested DX11.

3. I think you can go to SplatCommon.cginc and look for the #ifndef SHADERPASS_SHADOWCASTER block around line 140. Remove the #else that is specific to the shadow pass along with the conditional preprocessors, and all passes should use the same geometric normals.

 

The manual edit for #3 works perfectly, please do include it as an option!

 

I'm back with another small issue with camera facing and shadowing.

(To be honest, this is very specific to my attempt to use MudBun for grass, so with a very thin box and splat mapping, but I really appreciate your help so far!)

When enabling camera facing, "backface" splats also seem to start facing the camera (which is great, more fullness for less polygons.)

But because their normals are not adjusted accordingly, the backface splats get rendered as if they were in a shadowed part.

This artifact will be almost canceled if camera facing = 1, because then the front facing splats happen to mostly cover up the back facing splats. But as soon as position jitter is added, this lucky situation is no longer true and the artifacts becomes visible again.

Would there be a way to have the backface splats correct their normals when using camera facing?

Another alternative solution would be to hide backfacing splats when using camera facing. Or (and that one is really specific to my use case) to find a way of getting a layer of 1-face-only volume with no back face, but I feel like this might be out of scope for a tool like MudBun.

Video of the issue:

 

Well, I suppose it is possible to add an extra parameter like "camera-facing normal blend" that, when set to 1.0, will make the splat normals exactly facing the camera. It would mean if it's fully activated and camera-facing is set to 1.0, all splats will have the normals facing the camera. Is that what you have in mind?

 

Yes, that would be ideal!

 

Version 1.0.22 is now published.
Changes include:
- Options to match splat normals & shadows to splat camera facing.
- Expose MudRendererBase.RenderMaterialPropertyBlock.

 

Hello there, out of curiosity is it possible to make these mudbun objects slightly transparent? i am trying to make an effect like transparent spirit orbs absorbing each other. thank you!

 

Yes. Although the default transparency is implemented using dithered alpha cutouts.
This is because the procedurally generated triangles are unsorted, and using alpha blending will result in unwanted flicker on overlapping triangles.

 

That is great, could you explain how i would accomplish this effect if i were to buy it?

 

You can do that by setting the color in the material of a brush to be transparent.
It's just a typical color property and is shown as a color picker in the inspector.

 

When I use the LOCKMESH function, if I use the MeshRenderer mode. Then the MESH it generates has a very high number of triangles. Far more than the number of wireframe triangles actually seen in the Sence window. Why is this, can it be solved? Thank you.

 

I tried starting a new scene, creating a mud box, changing the renderer's renderable mesh mode to Mesh Renderer, and pressing the Lock Mesh button. And I couldn't reproduce the issue you described.

Can you detail the steps you took that resulted in this issue?

 

Hi! We're continuing to use MudBun and integrating it deeper and it's an amazing fit.

I find myself needing to query a SDF value on the CPU for gameplay purposes (for example, determining whether the player is in a zone defined by a MudBun renderer).

Currently, I don't see any C# implementation of the SDF calculation, but I can see how it roughly works in:

• BrushFuncs.cginc, esp. sdf_brush()
• Primitives.cginc
• Operators.cginc

First, is there some C# implementation I missed?

Otherwise, I'd be giving a go at implementation myself.

Reimplementing the SDF functions as extension methods of MudBrush would be pretty trivial.

I think the harder part would be the proper order of operations when traversing a brush hierarchy. The closest reference I can spot in the shaders is SDF_DECAL_MASKED_BRUSHES and FOR_EACH_BRUSH_EXTERN_MASK. Does that seem right to you?

Do you have any advice to help before I start?

Cheers,
Lazlo

 

There is currently no implementation of SDF evaluation on the CPU side.
Although it's on my to-do list, it has low priority and I don't know how long it's going to take for me to get to it.

The order of operation should be the same as the internal list of brushes to process stored inside the renderer. You may take advantage of the AABB tree to get a subset of brushes that will actually affect the evaluation outcome and only evaluate those, just like in the compute shaders.

 

Hi!

I was doing some performance tests switching from BuiltIn to URP and I noticed that tiling and offset don't work in the Mesh Single/Multi-Textured shader in URP(11.0.0), in BuiltIn it works perfectly, I don't know if it was already reported. I have also tested in a new clean project and the same thing happens.

I'm using Unity 2021.1.7f1

I love MudBun, it's saving me a lot of time, congratulations and thank you very much for creating this tool

 

That looks like an oversight.
I will investigate.
Thanks for the report.

 

Definitely a great tool – and with every update it´s getting even better!

One thing I would wish for would be an easy «click-one-button»-solution to turn a mirrored MudBun Object (symmetry: mirror x) into an independently one, so that, for example, a mirrored arm could be posed (animated) separately than the original one.

Right now, my workaround is the following:
I duplicate the Renderer which contains a children with the «symmetry: mirror x»-function on it.
In the duplicated one I change the «rotation y» to 180.
In the duplicated Renderer as well as in the original Renderer I reset the symmetry to «none».

So, yes – it CAN be done manually. Since it is a common task, I hope MudBun will, in a future version, offer an easy solution.

 

There is a Flip X utility button already. I think what I'd do is adding an extra Duplicate button for duplicating a brush (and selecting it afterwards). So in order to do what you're asking for, you'd click Duplicate and then Flip X. I'd rather not have a single button that tie duplicating and flipping together, and follow a one-button-one-function rule.

 

That sounds great! The addition of an extra duplicate button would be welcome! I will appreciate that.

 

Hi, is It possible to use a custom shader made with unity shader graph with mud primitives or is there any way around it to make it work ?
By the way I m in love with this tool.

 

Thanks a lot for the development and introduction of the «duplicate» button!
And it´s also nice to see that URP has a new render mode

 

Some horrendous code that will set it to Plugins. Place a freshly downloaded Mudbun into Plugins first once it's working, then run the script.

Of course I'd expect it to break in future / YMMV.

Code (CSharp):

1.  
2.     using UnityEngine;
3.     using UnityEditor;
4.     using System.IO;
5.  
6.     public class FixMudBunPaths : MonoBehaviour
7.     {
8.         [MenuItem("Project/Fix Mudbun Paths", priority = 100)]
9.         static void Fix()
10.         {
11.             string[] guids = AssetDatabase.FindAssets("t:Shader t:TextAsset", new[] { "Assets/Plugins/MudBun" });
12.             foreach (string guid in guids)
13.             {
14.                 string path = AssetDatabase.GUIDToAssetPath(guid);
15.                 string text = File.ReadAllText(path);
16.                 text = text.Replace("Assets/MudBun", "Assets/Plugins/MudBun");
17.                 text = text.Replace("Assets/{path}.mat", "Assets/Plugins/{path}.mat");
18.                 File.WriteAllText(path, text);
19.             }
20.  
21.             AssetDatabase.Refresh();
22.         }
23.     }
24.  

 

Seems this asset could perfectly fit my needs.

I need to control my voxel terrain through code (digging terrain in runtime). Can s1 point me please to documentation or source file how can I control the form of terrain?

Installed demo project but haven't found anything like this from the first look.

In my project I made own chunked marching cubes terrain that is defined by 3D matrix. I hope here will be something similar.

 

This is an SDF modelling tool, not a terrain generator.

You would want a voxel terrain generator for that, or cave maker. You can do terrain pieces in it, and set it to static, but for big jobs it's not an ideal fit - assuming you're doing a huge 1k terrain or something.

Mudbun can get around most things but I fear you would be working harder than you need to for that. But I don't know your project boundaries.

 

The reason why I'm asking here because author, as I understand, used a Dual Contouring algorithm for mesh generation on GPU, which is good for terrain generation.

Thanks for answer, gonna research more

 

Well it's cheap so why not give it a try? At worst case it's a fun new aspect of game dev.

https://assetstore.unity.com/mega-bundles/fill-your-toolbox

In this bundle you get mudbun and you get digger pro (a terrain digger for what you're asking for) - so best of both IMHO. Won't be there long but seems to be up your street.

 

Depends on if you want indefinite persistence of terrain modification.
MudBun is non-destructive, meaning the SDF is constructed from brushes that are never "collapsed".
So if you older brushes fade away over time, i.e. their effects to the overall SDF are temporary, then MudBun can work for this use case.
However, if you want to permanently modify terrains with no upper bounds to the number of operations, then this tool is not suited for the job.

 

Tell me if I can use my obj, fbx files to modify with your asset?

 

Not sure what you meant by "modify with" the asset.

If you meant having meshes interact with volumetric brushes, then the answer is not right out of the box.

However, users have managed to bake meshes to SDF textures and create custom brushes that sample SDF textures. But that requires writing additional scripts and computer shaders, as well as knowledge of how SDF works.

 

Maybe I don't quite understand what is MudBun. But I would like to create shapes in third-party programs (Blender, ZBrush) and then use them in Unity with MudBun.

 

If by "using the mesh with MudBun" you mean having a volumetric representation of the mesh that interacts with other SDF brushes, then you'll either have to create a custom SDF brush that translates triangles from the mesh into a series of triangle SDFs union-ed together, or create an aforementioned custom brush that samples an SDF texture pre-baked from the mesh. Either approach requires additional scripting and shader code, as well as knowledge of SDF. I'd suggest the latter, as there is a limit to the number of total SDF shapes per renderer.

 

I was wondering if you'd consider adding the bunny from your demo video (the one with it's tongue out) in the examples from the full product. It seems way smoother than anything I can make using the product and I'd love to take a peek at the settings. Thanks!

 

Immediately after posting this I've managed a smoother effect by upping the blend setting along with the size of my model. Still would be lovely to see the example. Great asset by the way, I'll be leaving a positive review once I've mucked around with it a bit more.

 

The bunny is from the HDRP Bunny Pup example. You can import it from the start screen in an HDRP project.

 

It seems that once my application is built the shader color can't be changed by code!? Am I missing something..or is it a bug?
Thanks!

 

Materials are copied and constantly updated in editor in order to account for user modification, which is assumed (incorrectly) to not happen at run-time.

I need to find a better way to handle this.

For now, please comment out the "if (Application.isEditor)" check in MudRendererBase.cs between the profile sample containing the string "Copy Render Material Properties".