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

Read the docs about Per-Texture UV scale

 

Blending is also not working anymore in my project, if I add the script new to an object it's blending something, but I can't adjust anything. After reloading the scene, blending is completely gone. The the example scene works. I have no glue what happened.

 

I'll send you the fix in a PM, sorry about that; it was a conditional compile that you don't have the module for.. My nemesis.

 

Thanks Jason, blending works again

 

It seems that it renders after the SSR. How does one change the render order?

 

If you are not using the automatic lighting mode, then the terrain is drawn in the forward rendering pass. If you are rendering in deferred rendering, which has a fixed lighting model, then forward rendering is primarily used for alpha surfaces, and as such some post effects are designed to run before them.

 

I have the exact problem, if there are no immediate patch to be downloaded, then please send me the fix as well.

 

Hi Jason,

We're having problems getting the terrain blending to work in Microsplat in LWRP. Tested this in basic render pipeline, and it works perfectly fine, but it's not reacting well in LWRP. I have Microsplat, Terrain Blending and the LWRP modules installed of Microsplat. When I highlight the shader, it gives me a few errors. I've attached a screengrab of the inspector when I have the MicroSplat_TerrainObjectBlend shader selected.

Additional notes; I'm on a mac using High Sierra (10.13.4), so I'm not sure if it's my GPU that's causing this to happen?

 

Send you a PM with a patch for this- uploading a patch to the store as well.

 

Just updated to Unity 2018.2.0b8. Now I get this and nothing will compile:

Assets/MicroSplat/Core/Scripts/Editor/UnityLDRenderLoopAdapter.cs(11,17): error CS0535: `JBooth.MicroSplat.UnityLDRenderLoopAdapter' does not implement interface member `JBooth.MicroSplat.IRenderLoopAdapter.GetPassType(int)'

Any fix for this? Thanks

 

Delete UnityLDRenderLoopAdapter.cs

 

Fixed and patch uploaded to the UAS. Should be out tuesday-ish.

 

So, an update on my schedule:

- I'll be in Berlin for Unite next week
- Iceland for a week after that
- Home for a week after that
- On a converted school bus traveling across the US for about 4 weeks

As such, replies will likely be slower than normal at times..

 

Well...finally got the MicroSplat Workflow complete. Here are two shots. It works rather well. The sky and sunlight is my private Genesis Weather v2. Thanks for awesome work @jbooth . This will work really well for some upcoming landscape contracts for pics.

 

Hey, thanks for updating the triplanar shaders so quickly. I really appreciate it. I've been trying to get them to work again in the game and unfortunately I've come across some problems with obvious seams between the z and x axes projections. The normals are being lit correctly but the textures are flipped vertically on one side. With some materials and normal maps the problem is not obvious but with others it can be a bit jarring. The triplanar contrast slider doesn't really do anything to alleviate the problem.

Do you think this is a fundamental limitation with triplanar texture projection on the terrain?

 

The contrast should control the harshness of the transition, and if you use height map bending as the triplanar mode, it will height map blend the projections. I'll take a look at the demo project you send when I get back from Iceland.

 

Hi Jason,
I'm also having this same problem and have reread the general instructions wiki, but didn't see how to fix it. I did confirm that it does have to do with per-texture uv (proven by setting all textures to the same uv which makes the problem go away), but I really need to have per-texture uv's as I'd like to have huge boulders and bumpy dirt in the same scene. I hate to bother you, but would you mind cutting-and-pasting the solution from the docs into this forum for me?
Thanks again for the great tool and have a great day! - tony

--------------

NOTE: This relates to:
jmpedros

Joined:
Jun 19, 2017
Posts:
11
New
Hi!
I'm using microsplat on my terrain and when I blend my textures using height maps appears some kind of seam around the limits. Any idea of what it is?
Thanks in advance!

 

Switch the sampler mode to LOD.. (in Berlin right now, so can’t recall the exact wording)

 

Something I've been picking at for a while and could use some feedback on..

 

looks awesome

would it be possible to add to the module a simple splatmaping procedural system .. for example, being able to pick a few textures and mix them using Perlin noise .. it would allow to quickly create a base texture (if you don't have one) before going manual with the painting.

 

Hey @jbooth. Haven't been able to build a working iOS build since moving to 2018.

Renders only white terrain.

Only error in xcode is about missing "hidden/Microsplat/AddPass" - but I've been seeing that (forever?) but still been able to see terrain.

Have deleted the entire Microsplat direction and reimported. Only using core in an attempt to isolate the error.

Works great on Mac. What can I debug further on iPhone?

 

Hi,
I'm using a unity "Projector" to put a decal texture onto terrain in VR. I use several assets (Terrain Composer 2, Vegetation Studio and Microsplat) that all do "terrain texturing" plus some assets that could affect draw issues (Volumetric Fog, Beautify). I've tried turning off all assets but the projector still has a weird issue on Microsplat terrains where I see the decal but it's clipped around the player. i.e. I see the original terrain under my feet but only see the decal from a radius greater than 50m around me.

Any ideas what I could change?

Thanks!

 

Can you try disabing just about every feature and see if it works (turn off any modules, etc)? MicroSpat generates two shaders in some cases, one for up close, another for far away - none should affect projectors, but maybe it'll give us a clue..

 

I do most of my profiling on iOS, but haven't tried this in 2018 yet (and can't for a while - won't be back home for over a month). Maybe do a GPU capture in Instruments, find one of the terrain draw calls, and see if the textures are bound, what they look like, etc?

 

I created new scene/terrain and all worked fine with "Detail Noise", then "Distance" noise - until I turned on "tessellation" in the Shader Generator section - issue happened immediately in play mode! Disappears when I turn off tessellation.

I'll turn that off for now then but if you've any ideas that would be great!!

Thanks!

 

Hello, I use microsplat with world streamer and when it comes to unload terrain I get message:
Can't remove Terrain because MicroSplatTerrain (Script) depends on it
Anyone has got idea how to get rid of this?

 

You should likely ask Bart, but I bet you could remove the required component attribute on the MicroSplatTerrain.cs to remove this error- might be others after that, but I’ve never used World Streamer.

 

Have you run with tesselation on iOS before? Seems pretty heavy for mobile.. I would expect there to be a shader error if it didn’t work on iOS.

 

Crossed wires I think . I'm running on PC, GTX1080, etc. Full blown desktop game!

 

Hi Jason,
Would you mind providing a little more info? I've tried changing the shader to use 'LOD' macros (supplying '0' for last parm) and it runs like 1/2 as fast and pixelates terrain in the distance. I've been trying other things as well for about 15-20 hours now and just can't seem to get the lines to go away. They appear on boundries of some terrains, but not on others so I'm really stumped. They appear to follow the contours of the control textures, ignoring the heightmaps associated with the terrains, if that gives you any clues. For example, if I add some water to a black texture, it forms a circular line around the control point that I set to be water. Also note that if I change both of the textures involved to the same per-texture-uv scale, the line disappears!
Any help you can provide would be very much appreciated. I'll keep trying, but this is kind of a show stopper for me as the lines are appearing everywhere when I blend from terrain to terrain (again, only with per-texture-uv-scale on and terrains with different uv scales).
Thanks and have a great evening! - tony

 

Can you select each shader in your MicroSplatData directory and see if any display errors?

 

You shouldn't have to touch the source code- "Sampler Mode" is available from the GUI to change this and compute the correct Mip levels for the LOD samplers (not 0, as that would be slow and pixelate like crazy in the distance). This is explained in the core documentation.

The tech reason for this is explained a ways back in this thread, but basically a core optimization MicroSplat does can break the texture derivatives lookup on some GPUs, causing an incorrect mip map selection to happen right along boundaries of textures when the UV scales between the textures are different. Using the LOD sampler mode fixes this by computing the mip map level in the shader instead of letting the GPU do it- it does have the downside of removing anisotropic filtering though. The upside is that when MicroSplat works on, say, 32 terrain textures, it only needs to sample 4 sets of textures of them instead of 32 - so that's one hell of an optimization.

 

I'm not sure what I'm looking for TBH. I have a couple of scenes, each with a subfolder containing microsplat config and generated shaders. I clicked each of them in the editor but didn't see any errors (would they show up in the inspector window?). I opened the shaders in Visual Studio but didn't see any errors. Please let me know if I'm checking correctly.

Thanks!

 

They would show up in red in the inspector window.

 

Ah OK - no errors then - all looks OK I think.

 

I can confirm this is still happening on both of my macs (desktop I have tried sierra & high sierra with gtx970 and a Vega56, on my mbp it has a m660, with both 2017.4.x and 2018.1) whenever I select a microsplat material. It's super annoying as I can't work with terrains unless I switch the editor to openGL mode.

I just reproduced it on a sample project by enabling metal editor, switch lighting mode to linear (not sure if that is required), importing microsplat, creating a terrain, adding 4 albedo textures, hitting "convert to microsplat", then selecting the resulting material. Will submit the project as a bug and hope they come back with something useful.

 

Support for Lambert made my hand-painted game look gorgeous! Thank you

 

Hello,

I seem to have constant problems with Git and MicroSplat. Many of these .asset files are frequently regenerated when I open Unity after pulling something via Git, even if what I pulled has nothing to do with MicroSplat. It also takes a while to import when this happens. I'm wondering if there's any way to prevent MicroSplat from creating any of these .asset files without being explicitly requested to do so.

Edit: It is also possible that these are not getting regenerated but their timestamps merely get updated and Git sees them as modified. Which is still a problem, of course.

Thanks in advance for any help!

 

Which files? MicroSplat regenerates shader files when you change an option, and updates the texture arrays when the hash changes that might affect the texture array format requirements for the platform.

 

This (what TommiH talks about) happens even if nobody has touched the microsplat shader or material, and certainly haven't changed any options. They appear to be dirtied just by opening the project.

 

Last time this happened, the files seem to include the config files for what I assume are various MicroSplat setups in various scenes / for various terrains. The following naming pattern repeats itself:

- MicroSplatConfig.asset
- MicroSplatConfig_diff_tarray.asset
- MicroSplatConfig_normSAO_tarray.asset

("MicroSplatConfig" is replaced by different names for different scenes / terrains, but those suffixes appear on them all.)

Here and there I also see "_antiTile_tarray".asset.

All of the affected files seem to be .asset files - no shaders are affected.

This sometimes may also happen to files on other asset store packages, but not even near this often. Which is why we suspect some kind of a automatic regeneration rule is getting triggered.

 

Hi, Jason. we've got some questions about performance using MicroSplat recently.
First is about texture clusters. When I change texture cluster mode from three to two and run the game, I can still see in the profiler pannel that the diff and norm C3 texture array are being used and taking some memory. The only way we found to solve this problem is to remove C3 arrays in advance from material property pannel before I change the texture cluster mode, which seems not so cool because if I change it back to three, I have to reassign those arrays. The same thing happens to Emissive/Metallic Array. So I wonder if those unnecessary texture arrays can automatically be removed when we change the mode.
The second questioin is about texture size. When I change texture size from 2K to 1K in the MicroSplatConfig pannel, the resource 2K images seem stiil being linked to somehow when I run the game, so that the memory being taken can not be proportionally reduced. After some test, our programmer says if we delete the MicroSplatConfig file before we run the game, the link to source images can be avoided, which alse seems not so cool, either..
After all, I want to take this example to clearify our confusion. If I change change cluster mode from three to two and set texture size from 2K to 1K, the result should be about 2/3 * 1/4 = 1/6 in theory. So if the Texture2DArray originally takes 500MB of graphics memory, the result should take about 80MB, right? We only managed to do so after we made those manual adjustements(removing arrays and deleting files), or it would be much higher than 80MB.

 

Are you profiling in the editor? Because Unity should strip the c3 array on a build; if it doesn’t, then that’s a bug that can be fixed.

MicroSplat keeps the original textures around for a few reasons; one is that the Unity tools require them. Another is that some people use code to inquire about them at runtime, which would need to be rewritten to test the arrays. Perhaps an automated fix for this would be to have separate resolution controls you can enable for the runtime source images, and have the config adjust their resolution down after doing a texture array import. This would be easy to add, and not break workflow with other tools.

 

This is most likely because the hash is being recomputed with a different value in TextureArrayPostProcessir.cs - if one of you can tell me which hash value is changing for you it would be extremely useful.

 

Added an option to resize source textures to 32 or 256 after texture array compile. They get restored to full size on each recompile, then reduced when packing is done.

 

OK, I had a look at the GetNewHash function. It looks like the hash depends on the current platform (we work on both Macs and Windows - would that cause a regeneratio?), current target platform (would having Windows selected on one computer and Mac on another cause a regeneration?), and Unity version (we have the exact same version).

 

Yes, because different platforms have different texture compression formats, so it recompresses them when the platform changes.

 

But we're all on Mac or Windows, with Mac or Windows build targets -- those all use the same texture compression formats, don't they?

 

They all can, but don’t have to. So what I’m doing is the following:

Expose overrides for forcing etc2, Pvr, or atsc formats. These can be much higher quality that DXT.

When computing the hash, query the resulting texture compression format of all arrays. This should mean that if Mac and PC both select DXT, it won’t recompress the array. This also means that if you are shipping a game on metal and PC, you can force it to use ATSC to increase quality and reduce memory.