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

Just finished watching the latest dev log, the procedural texturing editor looks absolutely fantastic! Looks like it will be a great tool to kick start scenes.. Any idea when you will be releasing it?

 

Submitted to Unity about 4 hours ago. It usually takes a few days to get released.

 

Hello @jbooth

I want to add my own textures to an existing Megasplat array or to a new one that I make.

But how do I make the texture used for Normal Smooth AO or MSEO ...? I know how to create a diffuse and normal texture, but I do not know how to generate the ones I see in your asset. I mean those with the suffix _mseo or _normsao.
I have looked in the manual and videoTutoriales but I find nothing. I'm pretty confused by this

I would appreciate a video tutorial

Another question: should all the textures of an array be of the same size(1024x1024, 512x512, etc) and format (.tga, jpg, png)?
That is if I wanted to add a texture to an existing array but this texture has more resolution, would there be problems?

Can I have an array for a tile terrain and a different array, with other textures, different configured parameters, for another tile of the terrain in the same scene?

regards

 

Hello @ftejada
Each texture packing format is described in the Megasplat manual. You can use Photoshop or GIMP or other similar image processing tool to prepare them. If you need a tool to make all this inside unity, I developed a little utility to pack textures in the various format used by Megasplat.
Take a look here: https://forum.unity3d.com/threads/channel-packer-pack-your-maps-in-a-textures-image-channels.456057/
AFAIK all textures must be of the same size; You can use different arrays, just use a different material for each tile and assign a different array to each material.
I hope this help you.

 

This is all covered in the included documentation under the header "Texture Packing". A video tutorial is available here:

All textures in a texture array have to be the same size- this is a hardware requirement. You can as many texture arrays in the same scene as you want; they are basically like big textures to the GPU.

 

Thank you for the replay! The megasplat terrain shader was working on the mesh I was just forgetting to set the render bounds haha.

I'm one of those dumb guys striving to make a ridiculously large landscape with way to many visible trees and detail
so I'm trying different experiments to find any possible ways to increase performance in any department. For mega splat I was mainly trying to increase performance for that awesome tessellation. In case you're curious here where my two main idea/experiments.

1). Generate a grid mesh around the player that locked its vertices and uv to match the terrain and position and render tessellation version of the shader on the mesh instead of the terrain using tessellation. This increased performance at first but once I get the grid count/size to match the same quad as the smallest terrain quad it ended up loosing it's performance gain.

2). Generate my own terrain mesh mimicking unitys terrain lod system to see if I could avoid so many batch calls and use the megasplat shader on the mesh.
When done correctly (aka. increasing quad size with distance ) I was able to reduce the number of calls significalty and render a nice megasplat terrain, Unfortunately although I was able to decrease 80 calls to 11 the render time increased so I'm not sure if it is worth it.

 

Most likely your hitting microtriangle issues at this point. One major advantage to edge based tessellation is that it's view dependent and therefor can be used to keep triangle size consistent, and above the threshold where micro triangle rasterization kills performance (this is usually around 10 pixels in size, below that the oversampling caused by the fact that GPUs always work in 2x2 quads starts to kill you). Additionally, megasplat uses a pretty fat vertex definition for all the splat map data, so each raw vertex is expensive from a wavefront perspective, so increasing the amount of it you need to process vs. generate on the GPU is not necessarily a great tradeoff. Finally, MegaSplat's blending tends to look better when using lower resolution control data (be that on a vertex or the splat control data), as this gives more variation and blend area than when you have a really high resolution structure - this is a rare win/win in graphics.

Draw calls don't really matter much on large meshes because the costs of a draw call is reasonably consistent, but the time it takes to draw a large mesh vs. a small mesh is not. If your meshes are tens of thousands of vertices, then I would expect lowering draw calls to help much.

I think a better approach is to generate macro textures for distant terrain and let MegaSplat draw them that way, or switch to a custom shader to draw them (this could lighten the per-vertex cost a bit, though the MegaSplat shader will early out so pixel cost is cheap).

 

That is a really good thing to know!
Thank you for the insight and suggestions.

 

@jbooth

I love this asset. Two questions though.

I noticed that your own RuntimePainting.cs script doesn't really work with Clustered painting. It simply ignores the noise when I paint the grass_diff cluster for instance with the Texture Cluster paint mode selected. The VertexPaint has no problems with this. Am I missing something? Do I need to modify the script to enable noise?

Do you have any recommendations of how to get an output of the percentages of textures currently used on a splat mesh?

Thank you very much for an awesome asset.

 

The noise scale is likely broken on it- I fixed this in a bunch of places, but likely missed this one. I'll fix it up.

So you want something like "grass_01.tga is used 5%"? If so, the best way is to iterate through the vertex or _splat texture and total up each index. You could also take the weighting into account, since a splat index being used but with 0 weight won't actually show..

 

Just took a look, this should be fixed in the patch that's in review- but you can apply the same fix as mentioned above by changing line 58 of TextureCluster.cs to int texIdx = (int)(n * range);

 

Hi @jbooth

That video I've seen several times to try to see how it did. But the truth is that I do not know how to do it.
Sorry to be so clumsy but but that video does not help me too much.

On the 7:41 min I think you started talking about it but from what I see in the video the _normsao texture is already created. And that is precisely what I do not do.
I know that explains a lot of things about this, but I do not understand the English language. And the truth is that I do not know if you explain the steps to get that texture _normsao. And the youtube translator is pretty unfortunate

Also I looked several times "Texture Packing" in the manual, but really that with that information I can not know how one of those textures is made


Again I apologize, but I would appreciate a video or more detailed information to learn

regards

 

A normalSAO texture is just a normal map with the Smoothness map in the Blue channel and the Ambient Occlusion map in the alpha channel. It's just packing more information into one texture rather than requiring multiple textures. If this is too much, you can use the standard packing mode which closely resembles what Unity uses.

 

Thank you very much.

 

Hello. I Invite everyone to vote for the issue on the issue tracker about the 5.6 texture array bug :
https://issuetracker.unity3d.com/is...one-texture-is-displayed-in-standalone-builds
It may help to fix this bug quickly for unity 5.6

 

Here is what enterprise supports response was:

"Currently, the issue is being reviewed by the Graphics team but not being worked on by a particular developer. It's being pinned for the main release of 2017.1 which is due in June."

So basically, they don't care that they've broken a major graphics feature in 5.6 as they have to meet the schedule to ship 2017.1 on time.

For reference, after several back and forths, they also don't seem to understand why making Metal the default API when it doesn't support shader model 4.0 or 4.6 (while openGL does) is an issue either.

 

A cross post from the Channel Packer thread but perhaps it will help some others who want to use their own textures in MegaSplat. Hope you enjoy it.

 

Pfff.... nice work Unity team! More new versions - more new bugs!

So, MegaSplat is not for Unity 5.6 or it works only for Windows in 5.6?
We plan to move to Unity 5.6 because of Vulcan. Maybe we should stay in 5.5?

 

From what I understand, here are the 5.6 issues:

- Texture Arrays are broken in builds on all platforms (I've tested OSX, Vulkan, Metal)
- Metal/Vulkan are the new defaults for platforms that support them.
- Metal only supports shader models 3.5 below and shader model 3.5, it does not support shader model 4.0, 4.5, or 4.6. OpenGL supports all of these models.
- MegaSplat uses model 4.0 (when it needs geometry shaders) and 4.6 when tessellation is on. These both work fine on OpenGL, but fail on metal.
- Note that MegaSplat uses model 4.0 when it doesn't have enough texture interpolators under model 3.5. Things like turning on snow, for instance, will bump the model to 4.0 (even though snow doesn't use geometry shaders- it just needs extra interpolators which come with that model).

Part of this is extra confusing because shader model 4.0 requires geometry shaders while shader model 4.5 does not. But shader model 4.0 runs on more cards than shader model 4.5 does. So the whole thing is a bit of a mess, since the abstraction is kind of broken. What would have been better is if instead of having these shader model numbers, you could #pragma needs_geometry_shader, etc, the feature you need. I could allow users to set a 'if you need to bump the shader model, go to 4.5 instead of 4.0" option, but besides being extremely confusing, it means they have to decide between which (almost arbitrary) set of GPUs they'd want the shader to run on.

From talking to Aras about Metal, the tessellation pipeline is really different from the other APIs. There's actually a pretty good reason for this (it's quite a bit faster), but it basically means they are unlikely to support tessellation under metal without the shader being written custom for it. (I don't mind doing this work if this eventually ships).

General reaction from the graphics people at Unity is along the lines of "Why would you use tessellation or geometry shaders? Those are edge case features". While, as a graphics programmer myself, I kind of agree (the geometry shader, in particular, is a terrible thing to use), many of my customers rely on these features for various reasons, and tessellation is a big seller and is often used on terrain in AAA games.

My personal opinion is that Unity has switched back to the model that stresses hitting dates over quality. This caused tons of issues during the 5.0/5.1/5.2 days, and IMO greatly hurt their reputation. Sometime during 5.3 they changed their process to focus on quality and things began to improve. My suspicion is that they are now under pressure to launch 2017.1 so they can switch to their new business model, and are once again under release pressure instead of focusing on quality. The metal thing I can understand; I don't agree with the decision, but users can disable Metal if they want to use modern shaders. But breaking core rendering features which worked in previous versions and products rely on seems to be something that should get a higher priority in the queue.

 

Good news! After updating to MS 1.0.5 and trying again, I got the expected files for the Macro Texture export. Looks fantastic, even at fairly aggressive distances for starting the fade to Macro.

 

// ....In editor,
// sometimes only the pre-serialization callback gets called. WTF..

​

Yes. I've had many of these Whisky Tango Foxtrot moments over the years dealing with Unity.

 

When i use "Render Baking" , I got this error" ArgumentException: The result uvs list cannot be nullParameter name: uvs "
How do i fix this error ?

 

Hmm, does your mesh not have UV coordinates?

 

It only show uv3 data , no uv0 uv1 uv2 ,i don`t know why.
but It`s ok now !!
I fix it with paint "uv0 uv1 uv2" data on it .

 

@jbooth

I haven't upgraded to Unity 5.6, but I'm curious, will MegaSplat work fine if a developer decides to make their game Vulkan only on PC? (5.6 supports Vulkan right?) Like, if someone wants to ditch DirectX completely.

Just curious..

EDIT: Read reply above.. so Vulkan doesn't support SM 4.0 and 4.6?

 

@jbooth

I just updated MegaSplat to 1.05. I'm using normalsao mode and noticed that you added global metalness slider. I think it is broken. The metalness slider changes the albedo brightness. Metalness is supposed to change the reflectivity color among other things which isn't happening in my case.

EDIT: Apparently the metalness slider works fine in your example scene. But not in my scene. I will try to rebuild meshes and arrays and see if that fixes it.

EDIT2: I can reproduce the bug! If wetness snow and puddles are turned off, then the metalness slider affects the albedo color only. Also the example scene is completely borked now that I removed puddles once.

 

Vulkan does support 4.0 and 4.6, I believe, but texture arrays are broken in 5.6, so it doesn't matter much..

 

That metalness slider/value has always been there, actually - I just made it draw the control. Metalness makes the surface dialectic, it doesn't actually change the reflectivity color directly - this can have a darkening effect to the albedo and an increase in shininess, but that is more a biproduct. Working in the mesh example scene, the surface seems to have the correct response regardless of puddles/snow/wetness..

 

I think you misunderstood. It's broken if you turn off puddles. Try it in the MeshTesselation scene.

 

And it seems to work fine in that scene as well:


No metal


Metal at 1 (no puddles, wetness, snow)


Note that if you have smoothness at 0, you don't get the "metal effect", just a perceived darkening of the albedo. So you need to look at an area with a high smoothness. Having wetness/puddles in areas would have given you a higher smoothness value in those areas..

 

Well that sucks.

Good thing I haven't upgraded to 5.6, I knew it it'd be a broken mess considering Unity's track record.

Anyway, in future, maybe we will be able to switch to Vulkan (wanna ditch DirectX completely since I'm a Windows 7 user).

 

Uggghhhhh... do you have any idea if they are going to release a 5.6 fix in a patch? Or are they saving it as a "feature" of buying a new subscription for 2017.1?

 

You can see supports response above. Currently it is planned to be fixed for 2017.1, but no one is actively working on it, and it may or may not be ported back to 5.6.. I will continue to be loud and annoying about this w/ Unity..

 

I wish you good luck! Seems like last time Unity goes into wrong direction of trying to make all new stuff but broke what was worked fine. It is normal now that a new released (!!!) version has bugs even after patches. So Unity reputation goes down. If they continue this way more and more people will switch to Unreal or some other engine. Because we can not trust to Unity now.

 

Yeah, this really peaked around 5.2, but things started to get better around 5.3 or so. New features having bugs is one thing, but regressions are another and should get top priority. My suspicion is that business requires they move to this new 2017 model, and thus they are beholden to dates above all else. Adding you're votes to the issue tracker might help- not sure if they really pay attention to any of that though..

 

Yeah, pushing necessary fixes into 2017.1 to force Pro users to buy a new subscription makes short term business sense, but it sure does erode good will. Especially since when they first announced the subscription change, everyone's first concern was that the final version of Unity 5 would be left with broken features that required a subscription, and they said they wouldn't do that. :/

 

Well, we'll see- I suspect they'll eventually port many fixes back to 5.6, they have too many enterprise customers to just leave a version dangling like that. I also don't think they're inherently evil or anything - just overly eager to move to the new business model. My bigger concern is that they can break an existing feature like this without noticing (no regression tests around Texture Arrays), and often have a 'meh' attitude about it (We'll make metal the default, who cares if half the stuff in the asset store can't run on it - oh, and make sure not to document any of it because surprises are fun!). The graphics team at Unity, in particular, seems allergic to documenting things (hello, standard shader/lighting model).

 

Hey guys, anyone else using the TriPlanar shader? Maybe something is just set wrong, not sure, but the Slider for individual normal strength seems to be wonky. By wonky I mean turning it all the way to 1 makes the normal less pronounced then turning it down to say, 0.3, and as I get to 0.1 they seem more pronounced. Can anyone confirm this? Maybe I have something wonky on my end? With Normal set to strength of 1 it looks like there just is no normal map at all.

 

Does it work fine without triplanar?

 

Yeah, lemme link you guys to 3ds Max 2018 thread on Autodesk forums.

This is exactly what Unity is trying to be (except for the killing the app part). Updates packaged as new versions to make more money through subscriptions while plugin/asset creators are the ones doing the real work (every now and then, Unity will just buy the asset).

Anyway, looks like most of us will be stuck with 5.5 for a while now. Can someone post the link to the issue tracker so we can vote the feature up?

 

news from Unity:

"UPDATE on the issue. A fix has gone into the Unity 2017.1 branch which is currently waiting to be verified as fixed by QA. Once this happens, I'll enquire when the backport for 5.6 is going to be made so I can give you a more accurate ETA for when it'll land in a public release."

So sounds like wheels are turning!

 

I've been waiting forever for Unity to release the 5.5 version with texture array support for the Wii U. I finally decided to move that project off the Wii U and onto the PC so I could use Unity 5.6 and Megasplat. Only to find out that it's broken on 5.6. Oh the irony.

So, now I'm installing the 2017.1 beta and will go forward from there. Thankfully, my project is still early in development.

 

I'm interested in coming up with a work flow for doing almost all texturing with tiling UVs, and using Megasplat as the shader for mostly everything.

For terrain/ground, it makes sense to use a fairly rigid texture array that doesn't change much.

However, for other meshes such as trees, buildings, rocks, etc. it becomes burdensome.

I'd like to be able to use a small asset specific texture array for a particular mesh, paint the splat textures using the asset's own texture array, etc, and then have a utility that bakes multiple meshes into a single texture array which is applied against them all.

I think you can understand where I'm going with this, but here is an example:

Rock1 mesh has a texture array with 2 textures (assume just diffuse/height for the sake of simplicity), dirty-stone.tga and moss.tga. It gets "painted" with MegaSplat and assigns index 0 for dirty-stone and 1 for moss.tga.

Rock2 mesh has a texture array with 3 textures, using cracked-stone.tga (0 index), mud.tga (1 index) and moss.tga (2 index).

I think the best workflow would be the ability to combine Rock1 and Rock2, coming up with a combined texture array that has the 4 textures and modifies the Color.A and UV3.W of the combined meshes to use the new combined index values.

I can see this mostly being done as part of the build pipeline similar to how you have a utility for baking meshes to remove additional vertex streams.

This would essentially allow us to use MegaSplat for individual meshes, and then add them into the scene and not have to build one texture array that handles everything since it could instead be generated later. This would make it easier to add new meshes and textures. This is similar to using something like a texture atlas baker that modifies that UVs of meshes to use a new shared atlas, but even better since we could use the power of MegaSplat.

Thoughts?

 

Well, I can confirm that current 2017.1 branch doesn't have the texture array fix yet. I assume it's coming in a future beta release.

 

It can all be done- you can use the current mesh baker as an example, and look at the way the configs build the arrays. In the end, it's just vertices, texture arrays, and a material that binds them together..

 

I just started down the path of creating a workflow for utilizing MegaSplat in a large (1200 sq km) terrain database importer/converter. Working with the tools MegaSplat ships with are good, but don't fit nicely in the existing workflow. I basically need most of them mesh converter with part of the the ColorToSplat converter (color to Lerp() specifically).

 

In general I try to account for a number of different workflows (Unity Terrain shader -> MegaSplat, Mesh, Color to Splat, render baking, etc), but at some point if you aren't following some of the common pathways you have to buckle down and tool up your own workflow.

That said, I'm always interested in what people are doing and ways I can open up these pathways to work better for these things. I assume you're bring in real-world terrain data from some database and want to use MegaSplat to texture it via some combination of color->splat and a macro texture?

 

Using MS 1.0.5 on Unity 5.5.3

Another question about Macro Texture setup:

I baked out the 8K Albedo+Height and Normal+Smoothness+AO from a very large Unity terrain (7kmx7km with a 2048 heightmap and 2048 control map. Without modifying the images at all, I assembled them into a diffuse + normsao texture pair that matches my main texture array.

However, the coloration of the area textured with the Macro Texture is too dark. (The one with the line and dark tinting is with the Macro Fading turned on). Changing the global lighting settings doesn't have an effect.

When I look at the individual modes (Albedo, etc.) in debug mode for the material, they look correct. I've packed several sets of textures now, so I think I understand that workflow.

The normal strength is set to 0.5. My MegaSplat shader material is not Tesselated and uses Shader 3.5

Is there some other adjustment I need to make to the normal + smoothness + ao files?

 

Most likely this is a linear/gamma issue. If you are running deferred, you could try looking at the individual components of the GBuffer and see which one is off. If it's the albedo, I'm thinking that you have some mismatch of renderer/texture in gamma and linear.. Same could be true of the other values, for instance, the normal/smoothness being bent by the gamma curve.

 

Hmm. We are using the Gamma color space settings for our project. I have disabled the sRGB flag on all of the splat and Macro textures, as the files do not have any color profile attached to them. (Turning this on and off makes no difference in what I see.

Switching to Linear color space shows the macro texture (when it has no gamma correction on it) as very pale instead of too dark.

Where else should I be making changes to get the rendering and textures to match beside the Player Colorspace and the sRGB box on the textures? (When I pack the textures in PhotoShop, I haven't applied a color space, since the Targa file format doesn't include a profile.)