[Released] MegaSplat, a 256 texture splat mapping system..

Awesome. Yes, I'd like to try the early version.

 

Is it possible to align applied textures or to otherwise control painting so that textures are oriented directionally (such as horizontal strata in the Grand Canyon or vertical columns of granite in Yellowstone Park)? Not for entire terrains, but for sections of canyons or rocks, as meshes. I know it's expensive, but I was thinking that the triplanar option would work for limited meshes like these. There's very little info on how to set it up the triplanar materials in megasplat. If triplanar isn't the correct approach, is there a preferred way to do this?

 

Hi @jbooth
Our project have to move to Unity5.6 from 5.4 because of Unity mix light shadow issue.
But Unity5.6 Lightmap seems doesn't work when using Megasplat Tessellation.
Can you fix this issue? ty

 

There's not a lot to triplanar- you turn it on, and then it does a sample for each direction (top, side, front) and blends them. This is mostly used when you don't have UVs or you want to prevent stretching of textures on vertical surfaces.

You can create global strata with the macro texture or (new) geotexture feature in 1.14. But these will be over the whole terrain or mesh. Note that you can construct your stripping texture with alpha, basically - if your using Mult2X for the blend mode (which the new geotexture always uses), then a color of 0.5, 0.5, 0.5 will have no effect, so blending towards that effect will allow it to fade out (say on the bottom).

 

Do you have any more information on this? I did some quick tests when 5.6 shipped and lightmapping seemed to work fine. If you could put together a small repro I'd be happy to take a look..

 

I've gained better results/quality on using real scanned textures than what you see in the video. For me specific high end textures and using Megasplat's texture array and clustering system and all the other features it comes with on top of performance is a definite winner but the incredible support from Jason as well is beyond a simple thank you.

 

1.14 was just submitted to the asset store - it's a huge update:

Features

• Multi-terrain conversion and workflow improvements. When selecting multiple terrains to setup for MegaSplat format, a single shader and material will be generated and shared between all terrains in the selection. This material is automatically sync’d across all the terrains, so any change to the original material will change all of the materials. This makes it much easier to work on massive terrains composed of many different chunks.
• Setup flow for new terrains improved by allowing you to automatically select the created material from the terrain painter window. General messaging improved as well.
• Terrain Converter now allows you to blur the input splat map from the original terrain. While it’s best to use wide blend areas with terrain generation tools before converting to megasplat format, this allows you to blur the input data, creating a wider blend area as part of the conversion step.
• Terrain Converter now has per-texture contrast setting, which biases the blend so you get more or less of that texture in the conversion
• Added noise seed to secondary cluster choice in terrain converter. This offsets the noise, allowing you to get different patterning
• Terrain Converter now orders texture layering, which allows for much better gradient conversion
• Projecting tangents as part of the top/front/side projection modes is now optional. This is because a mesh can only have one set of tangents, and in some modes, like AlphaLayer, you might prefer the model’s tangents over the projected ones.
• New Options for using distance resampling or distance noise on Snow. These work the same way other distance resampling and distance noise options work, but only appear on snowy surfaces
• Vertex painter’s max brush size raised to 90
• New “Preset” system for macro textures. Choose between “Fade to Macro”, “Color Tint” and have the macro texture system automatically set up for these modes.
• New GeoTexture system allows you to apply a vertical tint map to your terrain. While this could be done before by using a second UV channel and the macro texture slots, I think the setup was a bit too much for people. This allows you to simply add this feature, but still have a macro texture if you want.
• Clean up to shader feature GUI so that exposed sub-features are indented under main features

Fixes:

• Fixed bug in macro projection mode where projection would remain top down when set to front/side
• Fixed Save bug when saving configs in the terrain converter
• Linear Blend Bias now applied to layer blend as well as cluster blend (allows for softer blends between layers when interpolation contrast is 0)
• Fixed bug in glitter introduced in 1.13 which would cause specular to clamp at 1 for the whole terrain..

 

And here's the dev log:

 

Watching the dev blog now. Lots of great stuff. The multi-terrain converter is just what the doctor ordered. Perfect timing now that I'm using Terrain Composer 2.

[EDIT]
Multi-terrain conversion works great. Thanks.

 

OK ignore the previous post please (I removed), fixed already. Found that the child objects do indeed have the 'VertexInstanceStream' script wrongly attached... which was causing my error.

 

Should be pretty clear if you read the description of the asset vs. RTPs description. The main difference is being able to use hundreds of textures on meshes or terrains with really fast performance, but there are a ton of other features and tools as well.

 

Hi @jbooth

Is it possible to paint with over a procedurally textured terrain with terrain brush?

I want to be able to have the texture graph do the bulk of the work and then go in and paint specific details by hand.

Thanks,

Ben.

 

Yep, absolutely..

 

I switched from RTP to MegaSplat. As Jason mentioned, one big advantage is having 256 textures available, instead of 8. Also, MegaSplat paints the terrain using texture clusters, which are groups of related textures. Clusters eliminate tiling by varying the textures across wide areas. This approach produces better-looking results than distance resampling, which MegaSplat can also do, and it's much faster. And finally, MegaSplat's performance is much better than RTP. I'm getting around 3-4x the performance I got with RTP, with tesselation and many other nice features enabled.

The only downside of MegaSplat is that it has more of a learning curve than RTP. MegaSplat isn't very difficult, but you will spend some time learning its workflow.

 

I abandoned RTP a while ago as well and now use MegaSplat exclusively. In addition to better performance, it's also a lot easier to use. And although MegaSplat doesn't have as user-friendly an interface or workflow that I would ultimately like, it's still far less complicated than RTP. Jason is improving it constantly and I think future improvements to the UI and workflow will come at some point.

 

I saw Justin released a new Tenkoko version (1.1.6) that integrates its weathering system with CTS ... ie. rain in Tenkoko makes terrain wet etc ...
"Finally, this update includes an integration component with CTS - Complete Terrain Shader. CTS is an advanced terrain shader for Unity with built-in settings to control wetness, rain, snow, and seasonal tinting directly on the terrain itself. This integration script which will automatically drive the effects in CTS according to the weather settings you use in Tenkoku. To enable this integration, install CTS and Tenkoku in your project, add the CTS weather Manager, then finally drag the /SCRIPTS/Tenkoku_CTS_Weather component onto the 'CTS Weather Manager' object in your scene.... "

It would be really nice to have that integrated with MegaSplat too ... has there been any work on that? Hopefully its pretty straight-forward to add MegaSplat to the work already done.

 

I'd be interested to know which areas you found most confusing. MegaSplat introduces a bunch of new concepts and encourages/forces you to use them. It's also a massive package to explore, and not directly compatible with standard Unity terrain paintin. I think the things that most users get tripped on are:

- Texture Array requirements
- Texture Packing
- Cluster noise and design of clusters
- Terrain Conversion issues

I think the improvements in 1.14 in regards to multi-terrain workflow will go a long way to removing those issues from this list. Texture Packing is essentially an optimization/quality tradeoff, and having worked in the industry for so many years, I was surprised by how many people didn't know about those things as they are fairly common practice in the places I work. The whole cluster technology is unique to MegaSplat - I've never seen it anywhere else, so I think that's a first.

 

If the person who writes Tenkoku is willing to do an integration I'd be more than happy to.

 

I wasn't really referring to any confusion although the object blending is currently more work than I'm willing to invest in to get working. I was mainly referring to just a few minor points on terrain conversion. For example, there are 2 or 3 places where the texture array configuration needs to be selected and at least one place where you have to select the specific diffuse texture array and sao texture array. And The default is Standard mode instead of the recommended Normal Smooth SAO or whatever. I actually think it would be much easier to get started with if all those were automatic and you could just change them later if you wanted to.

One other thing that is actually a bit confusing is when you turn on various options it ends up adding a section way down in the inspector window. And unless you scroll down you won't even know it's there. So, it would be nice if when you check off a feature that the details for that feature appeared right below the check box in the inspector.

As far as a lot of the other features like texture packing, etc. I haven't even gone into those things. I'm happy at the moment with the provided textures.

[EDIT]
And as I said, it is far easier to use than RTP. The only thing RTP was easier with was object blending. It was still a bit of a chore to learn the workflow, but I managed to make it work whereas I just saw MegaSplat object blending as beyond me at this point.

 

In 1.14 features which are sub features (ie: snow glitter, which is part of snow) show up indented, which I think helps clean up that panel a bit, as the list of features is getting really long. The reason I don't draw the features inline with the checkboxes is that the top section is actually re-writing the shader code, where as the bottom sections are properties of the resulting shader. So it's conceptually split into shader design choices (design time), and material properties (runtime).

This would be really nice, but would be pretty complex as it would mean doing all the texture packing for your textures to convert between formats, recompress them, regenerate the arrays, etc, which is a ton of work.

CTS, for example, does a pretty good job with hiding this complexity from the user, which is awesome, but at least currently it does it in ways which muddle the separation of shader, material, and texture arrays - for instance, if you make another profile in CTS (which is like a material/shader/texture array combination), it will compress a new set of texture arrays - which means you could easily ship multiple copies of your textures in your build without realizing it, because your low end profile has one copy, and the mid range one another, etc.

 

No, I don't mean to do that. I just mean that the options would already be filled in with the defaults you provide. For me so far that's all I've needed. You already provide a configuration and texture arrays.

[EDIT]
And I don't mean that the texture conversion part would be done either. Just the initial configuration step. It's not a huge thing, but little things sometimes go a long way for ease of use.

 

Thx ... i cross posted to his thread here ... https://forum.unity3d.com/threads/tenkoku-dynamic-sky.318166/page-21#post-3131859 so hopefully you two can get something going.

 

Automatic texture packing and substances support would be nice to have.
Also some integration with weather control assets.
MegaSplat is great from technical part, but not so great in usability.

In fact our team struggle more with packing and re-importing things again and again than with real creation in MegaSplat. That decreases productivity. So MegaSplat is for technically advanced people while CTS is more for artists. At the moment we are more than happy with CTS.

 

+1
See recent posts above re that ... looks good

Changing textures is a pain ... its something I posted about a while back. Swapping out one-for-one is not too bad - if you can get around the naming (A), but we went through a rough experience recently of removing some textures (B)

(A) The ideal would be to have some type of 2nd index handling texture names, so re-ordering texture names does not affect the array, and once editing textures is complete the array gets rebuilt if needed. But that may be a bit tricky to code.

The way megasplat is now it might make sense to rather rename all textures numerically eg. 0100 - Forest...., 0200 - Ice..., 0300 - Road... etc . Unfortunately it means textures aren't indexed by name (which can be tough to find one if you have like 100 - but maybe a simple keyword search can help with that), but gives the advantage of editing is easier. So replacing "0200 - Ice..." with "0200 - Snow..." is simply done by naming ... instead of adding the texture as "Snow..." because that jumps after "Road..." - which means all your splat maps for that texture will be wrong.

Also, you could then insert a "0150 - Pines on Forest Floor" right after Forest and thereby group 'Forestry stuff' ... but of course splatmaps will need fixing in that case.

(B) Moving array index positions around by inserting and deleting textures is a PITA now. It means manual editing of the splatmaps ... eg. find Red value 64 in Gimp or PS, and change it to Red 65 etc.

I asked about a tool to do this using the graph editor ... and that may be possible if not already then soon. ie a tool to change index 64 to 65 for example (or ideally the ability to move all splatmap indexes > 63 up by 1) ... so one can insert a new texture at slot 64. And down to delete textures

But the ideal for this would be built in editor support ... so if I delete or insert textures, there should be a button to "fix splatmaps". This can be achieved by keeping a pre and post edit list.

We don't agree with that. The advantage of having as many as you like (up to 256 - which is silly number) terrain textures instead of being limited to only 16 (or even less with other shaders), far outweighs some admin work along the way. Most artists accept some setup and admin is necessary for better results. One would have to be very disorganized to constantly be changing textures ... which is fine, but then thats the cost.

But certainly +1 for improved texture admin!

 

Jep. At the moment MegaSplat is too old styled and not user friendly at all.
If you need to change or adjust texture in Substance Designer it is too messy to do it.
We better go with CTS and spend our time for making nice terrains than for messing with all these texture arrays.
Actually 16 textures in CTS is quite enough, so we don't need 256.

 

Sure ... most important is to use the tools that work best for you without limiting you now (and more importantly in the future as you grow), and sounds like you made your choice.

We were quite happy with 8 using "Colormap Ultra Terrain Shader" until we experienced the freedom of MegaSplat ... no way to go back to anything limiting textures now!

 

How can you stand the abysmal performance?

 

Hey @jbooth I've had MegaSplat sitting on my hard drive for a while, but have not had the free time to load it up and explore. I'll upgrade to the latest version and see if I can adapt the Tenkoku integration script a little later this week. Is there an easy way to access/adjust global MegaSplat shader variables for wetness/ snow/ drops?

 

The big issue here is that the mesh formats/texture formats aren't really extensible to be able to store texture names, and trying to revision across many scenes automatically would be virtually impossible. For instance, lets say you change your texture array 7 different times, then load an old scene which wasn't loaded when you were changing the array. You'd have to keep a revision history around, somehow store the revision numbers with the textures and meshes from the last time they were accessed, and then upgrade through all the various revision on every mesh or terrain found in the scene. But then someone bakes out a mesh to a new asset file, imports it into the scene, and paints on it again - so now you have the paint job baked into the vertices, plus the paint job on the indices.

Is it doable? Probably, but I also bet it would create a mess of other files you have to keep around and keep in sync, create more complexity for new users, etc.

I do think some tooling for "Hey, swap these around for me" is in order though; something more manual and explicit.

This is one of the big downsides of Texture Arrays, and you already see complaints about it in the CTS forums, even though they're only dealing with 16 textures there.

Right now all shader features are local. I started on some code to allow users to specify which properties are global vs. local, but it's a lot of work due to the custom editor, so I think I might not solve the issue that way. I think a better strategy would be to identify the things people want global control over and see if they can be handled via a small set of global properties (globalSnowLevelMinMax, etc). If you get a chance to play with the system, let me know which things you'd want to control and I can add that in the next version..

 

I would love to see this happen. I use MegaSplat and Tenkoku.

I saw a video of the CTS/Tenkoku integration, and it looks nice. However, I noticed that Tenkoku's Advance Time setting affects how quickly snow accumulates. I use a 24x Advance Time. That would cause accumulation to happen unrealistically quickly. I'd prefer accumulation to not be affected by Advance Time. I need to set Advance Time at 24 to keep the players from spending literally all night in a game night, but I want weather to happen at normal (realtime) speed.

 

I would think you would need another parameter to determine the percentage of accumulation over time. So while advance time would affect snow accumulation it would only accumulate based on your "percent over time" parameter. For example, you might say accumulate snow at 1% per hour then even in a full 24 cycle you would only get 24% accumulation. I can't imagine why they didn't do that with CTS. Sounds they hard coded the accumulation percentage.

 

This is just an option on the current integration script, you can set it to respect Tenkoku time advance setting multipliers, or to ignore this and use realworld timing instead. It gives you the option to set specific time/accumulation delays for rain/wetness accumulation and drying, and snow accumulation and melt. These are set in seconds, and can either be linked to the Tenkoku time or set as real world passage of time.

The variables I built into the integration script should handle this. In general I think it's better for the terrain shader to only handle a linear warp (0.0-1.0) that controls these settings, and this is the way it works in MegaSplat as well. It's better that the system you are using for game time (whether that's Tenkoku or a custom system) be the interface between these settings as it has more understanding, flexibility, and ultimately control over how you apply that timing to the terrain shader.

I'm taking a look at this today to familiarize myself with the system. I assume I could just set a Shader.SetGlobalFloat() function to handle the adjustments on these settings which should work without any extra interface on your part (well, that's my theory anyway, I haven't tried it on MegaSplat yet )

 

Oh, excellent! That sounds perfect.

 

Unfortunately if they are declared as a property then the global value won't override it. That's why I'm suggesting I add some sister properties for the global settings, which modify the local settings in some way on shader, so then you could do a SetGlobalFloat to set the values. That seems much easier than having to make thousands of lines of custom shader editor code handle properties being removed..

 

@jbooth Yes of course you are correct, I didn't think about the settings being defined in the shader Parameter section and of course that does not work. I'm only looking to edit a few shader variables at this stage:

_GlobalPorosityWetness - y for the overall terrain wetness amount.
_SnowAmount - for the snow accumulation.
_SnowParams - z for crystals and w for melt.
_RainIntensity - for droplet visibility.
_PuddleBlend - for size of puddles.
_PuddleNormalFoam - x for the puddle Normal amount.

I can do this by directly accessing the terrain Material and then setting these parameteres directly, like so:

Code (CSharp):

1. terrainMat = GetComponent<Terrain>().materialTemplate;
2. terrainMat.SetFloat("_PuddleBlend", blendRange * 60f);

This works fine, however you would have to have an integration script on each individual terrain. For some that might be OK, but your suggestion of sister properties built directly into the shader that aren't exposed in the parameters would be a nicer way to do it. Being able to set Global shader parameters is nice and clean

The alternative would be to have a MegaSplat component that get's adjusted and then all relevant terrains would mirror these settings and apply them to their individual materials. This is the way CTS does it. However I think the sister properties directly in the shader is perhaps a better technique, and would cut down on component bloat and possible performance bottlenecks.

 

Well, unlike most terrain systems, MegaSplat works on meshes as well, so you could easily end up with thousands of these things. So I'd rather add the global properties in the next patch to modify these parameters, as this will just work across every surfaces, and not require special components, etc..

 

I was comparing RTP and CTS to see which one best suits my needs. I eliminated CTS because they want you to buy two assets to get a list of extra features and I don't think that's good practice (it's almost like DLC lol). So I was looking at RTP but I also found MegaSplat to be a nice comparison (I originally thought your shader was only for putting 256 textures on a terrain and nothing else). I was going to go with RTP before I found MegaSplat but it seems a lot of users complain about performance or setup and compared to MegaSplat it seems like your shader has all the features I want -1.

1. I need tunnels in my game and I see you added alpha support. Is there currently a way to detect whether or not to fall through the terrain based on the holes we painted?
2. You also mentioned you don't think alpha maps are a good way to do tunnels, is there another way to do it that we are unaware of? Out of years with Unity I haven't found any other way besides not using Terrain entirely, or using a Voxel terrain.
3. Do you plan on bringing Vertex/Edge blending into the shader? It would greatly add to the assets quality and I think it's almost a necessity now a days to really combat hard edges.
4. Does MegaSplat support runtime generation? I have a level editor at runtime that let's you edit the terrain identically to the Unity Editor setup and I would need this too. Would it work out of the box or require some modifications?

Thanks for taking the time to respond, looking forward to your answers

 

Hi Jason.

I'm on Windows but I'm having the black model issue you describe above. It only occurred after I closed Unity and re-opened. After that, the shader only produces black. I'm on 5.6.1f1.

Should I update to Unity 2017.1.0f1?

 

Has anything changes re: terrain painting? I went to do some terrain painting today - pressing the left mouse button started painting, but it carried on painting after I released the mouse button. So I ended up painting all over the place!! It also didn't register an undo object, so I had to restart Unity to clear the changes.

I was using version 1.12 when I first saw this, but updated to 1.13 and the problem is still there. Unity version is 5.6.2f1.

 

Well, I would recommend 5.6.1p2 as the minimum version if your on 5.6, because that's when Unity fixed Texture Array support in builds.

However, since this is in editor, most likely what is happening is that Unity has started up in emulation mode, or is running in DX9. You can check this by looking at the top bar of the app and making sure it says "DX11" and not "DX9 in DX11 mode" or "DX9". Then check the Graphics->Emulation options to make sure emulation is not on.

Not in 1.12 or 1.13 - in 1.14 the undo system was massively sped up, but Unity hasn't shipped 1.14 yet (today, hopefully?). This is certainly a new one for me- does this repro every time?

 

No, there's no included component for it, but it's pretty simple to write for most peoples use cases. What you do is make a trigger volume that changes the physics flags such that you don't collide with the terrain when your in the physics volume.

Use meshes - Unity's terrain system is rather old and outdated. The problem with using alpha test for this is a) It can be very slow on some GPUs and b) It can create other problems in the rendering pipeline.

You mean blending the normals of one mesh to the terrain? There's already a brush to do this included with the vertex painter.

MegaSplat uses a very different format for it's splat map data than what Unity uses. Where Unity's basic format is one weight per terrain texture, MegaSplat uses a single splat texture with two texture indexes and a blend weight between them. This, plus it's basic blending technique, is far more efficient for a high number of textures (as you'd need 64 control textures to store weights in Unity's technique to reach 256 textures). The way the data is stored is described for both meshes and terrain in the documentation (available online if you'd like to see now), and there is a runtime painting example that shows you how to modify terrains and meshes efficiently at runtime.

 

If you'd asked me that this morning I'd have said yes, it happens every time, even after restarting Unity. But now it's working fine. Weird.

 

Thanks for the DX11 tip to solve the black model. It did the trick.

 

I'll be out camping with the family until sunday, so if I don't get back to you, that's why..

 

Have fun on your camping trip. I got a question for when you get back. I'm just getting into Puddles and I was wondering if you have planned anything to make the process procedural? It would be nice if you could convert a texture to puddles or something like that. Or at least have some controls for height and slope. Maybe even have a flowmap generated based on slope, not sure if that's feasible.

 

If you use the procedural texture graph, that's already possible. Not completely sure but I think in one of the videos he said when an output in the graph is not overridden, then the manual setup is kept. So you could try if you can only make the puddles procedural, but if you do, make sure to have a backup of some sorts!
Seneral

 

Hi,

I would recommend to rise the minus interpolation contrast x5 (or x10) for the global settings and for each texture. On a 2k splat map the changes are visible, and for some terrain types it is necessary, e.g. for desert. I rised it to 0 to 10, so 10 is max, the old 0.999, and 9 is min, the old 0. Until 5 the interpolation makes sense, especially for specific textures. In this way we don't have to blur out all textures with macro for having more smooth blended textures.

Changes I made:
contrastProp.floatValue = 10.0f - EditorGUILayout.Slider(CInterpContrast, 10.0f - contrastProp.floatValue, 0.0f, 9.999f);

Interpolation 8.4 (old value would be -0.6, not possible to set)


Much more natural:


Interpolation 7.5 (old value would be -1.5, not possible to set)



Interpolation 9, the old 0, which is the max what you can set now.

 

Hi Jason.

I'm using your vertex painter free tool in my project but i'm really considering buying megasplat for higher quality. Will I lose all the paint work i already did with vertex painter?

 

The shaders MegaSplat uses use a very different format than the ones included with the vertex painter's included shaders, so the painting won't transfer over I'm afraid.

 

Interestingly, this totally breaks on meshes but works fine for terrains. I'll look into why and figure out what the right solution for both is (or maybe terrains only allow this?).