[FREE]MicroSplat, a modular terrain shading system for Unity Terrains

Hi.

I've encountered a small issue.
When i use 2 terrains (with their own MS material), they share the same stream data map.
So when i paint a stream on 1 terrain, it shows up on both.
Tried a few times.
Can you confirm?

 

Yup, I can push a fix in the next release or send you a patch..

 

I'm in no hurry

 

I am also getting GetPixels32 errors on macOS with openGL. Here are the stacktraces:

Code (CSharp):

1. GetPixels32 failed: insufficent pixel buffer size (1), must be at least 4 x 4
2. UnityEngine.TerrainData:set_baseMapResolution(Int32)
3. MicroSplatTerrain:Sync() (at Assets/MicroSplat/Core/Scripts/MicroSplatTerrain.cs:200)
4. MicroSplatTerrain:OnEnable() (at Assets/MicroSplat/Core/Scripts/MicroSplatTerrain.cs:70)
5.  
6. Failed to get pixels of splat texture
7. UnityEngine.TerrainData:set_baseMapResolution(Int32)
8. MicroSplatTerrain:Sync() (at Assets/MicroSplat/Core/Scripts/MicroSplatTerrain.cs:200)
9. MicroSplatTerrain:OnEnable() (at Assets/MicroSplat/Core/Scripts/MicroSplatTerrain.cs:70)
10.  
11. GetPixels32 failed: insufficent pixel buffer size (1), must be at least 4 x 4
12. UnityEngine.TerrainData:set_baseMapResolution(Int32)
13. MicroSplatTerrain:Sync() (at Assets/MicroSplat/Core/Scripts/MicroSplatTerrain.cs:200)
14. MicroSplatTerrain:Awake() (at Assets/MicroSplat/Core/Scripts/MicroSplatTerrain.cs:61)
15.  
16. Failed to get pixels of splat texture
17. UnityEngine.TerrainData:set_baseMapResolution(Int32)
18. MicroSplatTerrain:Sync() (at Assets/MicroSplat/Core/Scripts/MicroSplatTerrain.cs:200)
19. MicroSplatTerrain:Awake() (at Assets/MicroSplat/Core/Scripts/MicroSplatTerrain.cs:61)
20.  

Getting 4 of each on a terrain with 8 textures. Any ideas?

 

Can you select your textures and make sure they are set to read/write? I think Unity requires that they be read write for the basemap to work (which MicroSplat doesn't even use, so the whole thing is a bit silly, but Unity Terrains don't really allow you to turn this stuff off). I'm guess that maybe if you added the first several via Unity's GUI, it set this on them, but if you added the next four via my GUI (and it maps them back to the terrain) that this doesn't set them as read/write and you get these errors?

Edit: I see Unity doesn't expose this as a texture option anymore, so I'm adding code to do this for you when the texture array is built..

 

A number of normals were not marked as read/write but switching them doesn't kill the errors. Also when I exit play mode it dumps 4 more of each of these:

Code (CSharp):

1. GetPixels32 failed: insufficent pixel buffer size (1), must be at least 4 x 4
2. UnityEngine.TerrainData:set_baseMapResolution(Int32)
3. MicroSplatTerrain:Sync() (at Assets/MicroSplat/Core/Scripts/MicroSplatTerrain.cs:200)
4. MicroSplatTerrain:Awake() (at Assets/MicroSplat/Core/Scripts/MicroSplatTerrain.cs:61)
5.  
6. Failed to get pixels of splat texture
7. UnityEngine.TerrainData:set_baseMapResolution(Int32)
8. MicroSplatTerrain:Sync() (at Assets/MicroSplat/Core/Scripts/MicroSplatTerrain.cs:200)
9. MicroSplatTerrain:Awake() (at Assets/MicroSplat/Core/Scripts/MicroSplatTerrain.cs:61)

 

Can you pack up your scene and send it over? I haven't been able to get this to happen..

 

Send you a PM with the link.

 

Just wanted to thank you for fixing undo. Big help to workflow.

 

Thanks for the update Jason. Streams on multiple terrains works fine now.
I did have to delete the original stream data to allow the system to reassign new maps to each terrain. Otherwise they keep pointing to the same map.

 

I'm bit ashamed to ask about this: I have problem that even if I have set aniso : 16 on diffuse and normal textures i still get blurry texture on short distances. I also checked quality settings that anisotropic is forced on. have i missed some settings?

 

We're actually looking into this over on the MegaSplat thread- current theory is that Unity is not setting that data on the GPU from the texture array, but I have an idea of how to fix this manually, since I can adjust the LOD in the shader. Anyway, something I'm going to do a deep dive on over the weekend and figure out what's happening.

 

Thanks jbooth for clarification Now I can focus on other things and not scratch my head over with this lol

 

Hi, just one very quick question, I keep getting "Script error: OnTerrainChanged". Any idea what could be causing this? It seems to remain even after updating, although admittedly I haven't yet updated it to the latest version. Cheers.

 

Can you post the full error?

 

Code (CSharp):

1. Script error: OnTerrainChanged
2. This message parameter has to be of type: int
3. The message will be ignore.

There is no more call stack.

 

Is this on 2017.2? I think they changed that API slightly, so I'll have to update it for 2017.2..

 

Totally, 2017.2.0.f3, however it doesn't break anything as far as i saw...

 

@punk

So, on the drive home I realized what's causing Anisotropic not to work when set on the texture array. The explanation is long and detailed, but there's a few choices to be made at the end and I'd like people's opinions on them.

A while back, there was a bug in MicroSplat and MegaSplat where small lines would show up between textures when per-texture UV scale was on. This has to do with how GPU's sample pixels. In the regular case, what happens is the GPU always works on four pixels at a time. It rasterizes in screen space, and computes 2 vectors which tell it how far away the 3 neighboring pixels are, but in texture space. It then uses these derivatives to select a mip map, and fetches the data for the texture for all 4 pixels at once. This speeds things up a lot, since the GPU can do one texture fetch and get the results for all four pixels it's working on.

However, if the UV's and thus the derivatives are different on those four pixels, then it won't really get the right result. You can override this and have each pixel look up it's own sample, but this slows the shader down considerably. In a stress test scene, MegaSplat went from 45fps to 33fps when this happens. So obviously we really, really want to avoid that.

So my solution to this is to compute the mip map myself and sample that mip map for all 4 pixels, rather than letting the driver do it. This clears up the lines, but the downside is that all UV scales have to share the same LOD choice- which is why there's a big warning that says something like "per texture UVs should only be scaled between 0.5 and 2 for best results" when you turn it on.

While this solves the black lines issues and still allows a reasonable amount of per-texture UV scale, it means that Aniso is effectively ignored. So that leaves a few choices:

1. Only use the manual LOD route if per-texture UV is not enabled.
2. Compute my own Aniso type thing

So, the issue with #1 is that it means you get a different blending look when per-texture UVs are enabled. It's slight, but noticeably different. Further, upon experimenting with this, it turns out that my manual LOD sampling is quite a bit faster. This is contrary to what common GPU lore says, but tests show that I get about 10% faster fill with manual LOD sampling than I do using the automatic selection, even when aniso/etc is turned off. This is most likely from the driver doing less work and the mip map selection being slightly lower in some cases, helping bandwidth, but I don't know for sure.

So, for #2, what Aniso does is change the mip map selection based on the view angle and sub sample the texel several times in these areas. The first thing is easy to compute, though the later part you can't really do efficiently in a shader (it's done at the driver level). So I played with having a bias based on view angle, and it does seem to help. Pushing this bias too high will cause shimmer, and it doesn't look quite as good as Aniso does, but it does help.

So now I'm left wondering what the best way is to go forward. I could support both options, but this will likely lead to user confusion as it's a pretty deep topic, and the whole thing is deeply connected to per-texture UV scales, which will likely make even less sense to most users. I also don't like the idea that turning on per-texture UV scales changes the look of the filtering and would actually speed up the shader since it would force manual LOD selection. I could make manual LOD selection an option which can be separately forced, I suppose, and then it would be forced on when PerTexture UVs are enabled?

 

Cool story

It's hard to form an opinion without seeing the "different blending look".
My preference would be to support both options.
Your explanation about the how and why is good enough i think. If that is in the manual, people shouldn't get too confused i think.

 

My choice is whatever has better performance, I'm a simple creature willing to adjust our assets to fit, on the provision that it's meaningful performance gains across most hardware.

Failing that, I would go with whatever requires less fiddling. You could always do both as a define if it wasn't too much work so expert users can fiddle. For what it's worth #2 does sound more hacky than #1 does, but what do I know?

Our visual style does not require sharper textures though as it's stylised and needs less noise so we probably would be happy with it as it is.

I don't really like a lot of options. It's the reason we moved off RTP. In the end didn't know what was good or bad or whatever and decided it was wasting our productivity.

 

Because I'm building a PC game with hires textures I really notice it esp in VR

I think choice is good and I do like the bottom suggestion also, because not everybody is going to have the same requirements, performance is definitely on my mind constantly. I don't mind the blending changing slightly, that's a small compromise to make for better performance.

I just want to make sure I am understanding you correctly:
1: NOT using per-texture UV scale ie having all the UV's 1:1 would give you the correct Ansio and not sample the mip map for all 4 pixels.
2: A compromise that would yield better performance.

And this would be the same in MicroSplat and MegaSplat?

 

I'd say, default to what should be best, with an option to enable for strange cases.

 

Yes, this would be for both MicroSplat and MegaSplat. Last night I got the pathways into MicroSplat - if you turn on PerTexture UV scale or the new force option, then Aniso is simulated with a slider to control the amount. I also added another option to bias the mip maps based on distance, which can be used to sharpen things up close and soften them in the distance. I'll get the same pathways into MegaSplat, but getting the data to the right place is a bit more plumbing there.

I never notices this because I work on a MacBook, which has a very high resolution screen- but with something like VR, where every pixel really counts, I can imagine how this would make a much bigger difference.

 

Performance difference on my MBP is 133->117fps or so, so it is a substantial win, though not the end of the world and likely less on a higher end card. I have defaulted it to doing the correct filtering when it can, with an option to force the faster filtering and it doing this automatically when it has to.

In making MicroSplat, I have tried to limit the amount of options to things which are easily understandable to the average user, fill out defaults (including textures) automatically when possible, and generally make most of the choices for the user when I can. This option seems right on the line to me. If more of these appear, I may move them into an "advanced" section of options that's hidden by default, kind of like the basic vs. PBR workflows on the texture packer. For instance, the lighting mode overrides would be another thing that could move into a section like that; they are particularly useful for some, but not for most.

 

I think an Advanced section sounds good, since it's such a tricky call.

I'm having (what I think is) a different issue, though also seems related to mipmaps. When I enable Triplanar, I get very speckly noise, starting at mid-distance and increasing with greater distance. See screenshots (though it's much more noticeable when the camera moves, the speckles dance around). Per-Texture Disable Triplanar on this texture (the whole view is a single texture, for testing) makes no difference. It comes and goes when I enable/disable Triplanar. Any idea what I could do about that?

(I know the texture tiling changes with triplanar, that's not the issue here -- in fact, because Triplanar reduces the tiling frequency, you'd think it would lessen any weird mipmap issues...)

 

Hmm, I'll be interesting to see what happens with the next patch. Since I am selecting the mips by hand in the current build, I could imagine triplanar having no effect, but it having a negative effect on sampling quality seems odd.

 

Yes good idea re separate section, but I'm not sure "Advanced" is the correct terminology ... it sounds like something users should be tinkering with if they know what they are doing (which most users will want to try).
Maybe something like "Alternative Options" or "Debugging Options" or along those lines ... so users understand they are only to be fiddled with when the default options are not performing well.

 

When do you think that patch will be out?

 

I'll submit it this weekend, but I could send you the new core if you want to test it early (note, it's not compatible with the old modules, since I'm doing a version upgrade, but if you want to send invoices for those I could send them along as well.)

 

That would be great. I'll PM you the module invoice numbers.

 

Hi.

Microsplat has a built in module for Vegetation Studio. It is included in the free core version and designed to generate a grass and plant color mask and then blend this in the terrain at the distance where grass normally is removed. To give a much better grass distance at great speed.

I just finished a small guide for how to configure this with Microsplat.

https://www.awesometech.no/index.php/vegetation-color-mask-setup-with-microsplat/

Lennart

 

https://www.dropbox.com/s/myjva256bmuf2su/Capture.PNG?dl=0

I am getting this error every time I run my scene. Error only popped up immediately after importing Microsplat latest directly from the Asset Store. I am using Unity 2017.2.0f1. Any solutions on how to clear this error? Not sure if I should ignore it or if it will have ramifications in my builds?

 

I'll be shipping a patch to the UAS for this over the weekend, but if you want to fix it yourself you can change the OnTerrainChanged function in MicroSplatTerrain to take an int instead of an enum. It's still listed as taking an enum in the Unity docs, so I won't be surprised if I have to switch it back in the first patch. The scriptParametersCall != NULL one is a Unity regression as far as I can tell, and doesn't seem to have anything to do with MicroSplat. Neither seem fatal.

 

Texture Clusters!

I'll submit this in the next few days, but it's been taking a Unity a LONG time to approve new assets, so it might take a bit to get released.

 

Very, very useful. I've been making this effect manually by using high variance noise. This is the main reason I need TerrainComposer2, I need to make similar textures blend into each other hiding any form of tiling and creating a whole lot of organic complexity. Because a real organic material shouldn't consist of 1 texture if we approach it using splats. It takes a lot of work.

This will make things easier, the way it should be. So splats can be the higher level control, while texture cluster take care of reproducing each organic material by blending multiple textures together.

 

And so now we have 16*3 textures. Having 3 textures to reproduce an organic material.

To that end, do try to make it compatible with TerrainComposer2 if you can. It's an instant purchase for me.

 

There's nothing to make compatible, as far as Unity or anything else is concerned, it's a 16 texture terrain. Only the shader knows that it's really splatting several texture variations for each.

 

Awhile ago I was thinking how great it would be to have texture clusters in MicroSplat, but assumed it wasn't possible. So this is freaking fantastic!

Yes, exactly -- I've spent a lot of time tweaking TC2 nodes to have a nice random mix of textures within an area, but I'll happily discard that and let MicroSplat handle it. And this will also let me reduce the number of splats on the terrain, which should balance out the extra cost of the clusters.

Jason, now it's even clearer that I'll need to create multiple MS materials for different platforms and quality levels, and assign the appropriate one on the fly. When i duplicate the material, I get a new propdata as well, but I should also create a new shader as well, right, so the new settings are applied to it? It would be very helpful to have some guidance in the docs on how to set up multiple material/shader variations properly.

 

Messing around with Metal in the editor today and started getting spammed pretty badly with this:

Code (CSharp):

1. Metal: Shader[Hidden/MicroSplat/1KTrainingCamp_x0_y0_Base472251306]: Pixel format [MTLPixelFormatRGBA32Float] of texture bound at index 0 is incompatible with texture parameter [half _PerTexProps]. Compatible types [float]
2.  

~25k messages in less than a minute.

 

Hmm, the easiest way to do this would be to setup a different material/shader combination for each LOD variant you want. As an example, lets say you want one with tessellation and such, and one super basic. Use the high quality version to do all of your work, and just make a material and shader for the low quality one by using the Create->MicroSplat->MicroSplat Shader and assign it to a material that you can use to adjust the settings. No need to fully setup the material or keep it in sync, just set the shader settings on it which cause the shader to recompile with the features you want on/off.

Then, in game, to select the lower variant, you could set the .shader property on your template material (the one you use for the high detail) and then call SyncAll() on MicroSplatTerrain. This will propagate the template material across the terrain with the new shader, but all of your old material settings.

 

interesting, I'll take a look..

[Edit] Fixed, but won't make it until the patch after this one. If it's annoying you go into microsplat_shared.txt and change the sampler2D_half _PerTexProps; to sampler2D_float _PerTexProps;

 

Not sure where to send the bugs I'm finding so I hope you don't mind me posting them here; if you'd rather me email them in I can do that as well.

Just tried to enable VS grass map and get a null ref:

Code (CSharp):

1. NullReferenceException: Object reference not set to an instance of an object
2. JBooth.MicroSplat.MicroSplatVegetationStudio.WriteProperties (System.String[] features, System.Text.StringBuilder sb) (at Assets/MicroSplat/Core/Scripts/VegetationStudio/Editor/MicroSplatVegetationStudio.cs:132)
3. MicroSplatShaderGUI+MicroSplatCompiler.WriteProperties (System.String[] features, System.Text.StringBuilder sb, Boolean blendable) (at Assets/MicroSplat/Core/Scripts/Editor/MicroSplatShaderGUI_Compiler.cs:261)
4. MicroSplatShaderGUI+MicroSplatCompiler.Compile (System.String[] features, System.String name, System.String baseName, Boolean blendable) (at Assets/MicroSplat/Core/Scripts/Editor/MicroSplatShaderGUI_Compiler.cs:324)
5. MicroSplatShaderGUI+MicroSplatCompiler.Compile (UnityEngine.Material m, System.String shaderName) (at Assets/MicroSplat/Core/Scripts/Editor/MicroSplatShaderGUI_Compiler.cs:395)
6. MicroSplatShaderGUI.TriggerCompile () (at Assets/MicroSplat/Core/Scripts/Editor/MicroSplatShaderGUI.cs:191)
7. UnityEditor.EditorApplication.Internal_CallDelayFunctions () (at /Users/builduser/buildslave/unity/build/artifacts/generated/common/editor/EditorApplicationBindings.gen.cs:259)
8.  

 

Anyway they come is fine by me. I'll take a look - I think this will be fixed in the patch which is already submitted, but will double check.

 

Question about the Snow module: My scenes are mostly terrain, but there are some mesh objects which really should get snow on them as well. There are several other snow-coverage shaders in the Asset Store, but I'd rather just use a single shader if possible. But since MicroSplat is strictly a terrain shader, there's no way to have its snow affect mesh objects, right?

 

Not right now, I've considered doing something like what the terrain blending shader does, where you just add a separate material to layer on snow. I also prototyped doing snow entirely in post processing, which has some advantages and disadvantages, but neither of these is much past the experimentation phase at this point..

 

Just saw your update go through and holy cow I want to hear more on this:

Are there any docs for this feature yet? =)

edit: this also sounds like a feature to allow vegetation to cast dynamic shadows in the distance (similar to a shadowmask) - is/would it be possible to make the terrain itself do the same?

 

It's not quite done yet, but Lennart and I will continue to work on it very soon. The basic idea is to do dynamic shadows on everything beyond the shadow rendering distance (would work for things which are not tree's, potentially). We do this by storing a distance field of the objects and raycasting shadows from them as part of the terrain shading pass, such that the shadows still respond dynamically to changes in sun direction. Doing a terrain->terrain shadow would require a different technique, but is technically possible as well. Basically, we're trying to remove the last of the artifacts that happen with terrain rendering, like grass and shadows not rendering in the distance, etc.

 

Super excited about that! (Will it require another sampler?)

 

Ha, yes- if it's a texture, it's a sampler.. Oh to be on a mac..