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.
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.
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.
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.
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?
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.
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?
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.
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.
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.
Exposing the material property block would be very easy. I’ll add that to the next update.
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.
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)
Great, thanks!
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.
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.
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.
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.
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?
