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

Try switching the tab to "paint" to see if it shows the vertex colors. The converter makes sure that every face has a red, green, and blue vertex on it. This is required by the shader, otherwise you'll end up with the issue you describe. All the converter does is go through the mesh and add these markings, splitting vertices when it cannot have exactly one red, green, or blue on each face.

 

By any chance, are you using the original mesh instead of the _splat version the converter creates? It should be right next to your original mesh.

 

@jbooth & slipster216 BINGO! Thanks! For some reason I had originally thought data only would be written to the file that is created from the original not thinking that I would need to remove & replace my original from the Hierarchy.. I've gotten lazy - used to other assets disabling my originals in the Hierarchy/replacing them with the newly generated version!

 

Hi, is it possible to use paralax and or tesellation with triplanar? I can't make it work. If triplanar projection is enabled, the paralax height or tesselation distance don't make any effect.

Also noticed that when switching from terrain inspector or shader inspector to terrain painter, the source textures file of the painter needs to be selected again.

Not very important, but a bit anoying.

And last one, do i need to bake splat after painting? Because i save the scene and close unity and the nex time splat has gone. Just the initial rock texture.

Any idea?

Thanks a lot

 

When i open up the 'UnityTerrainTesselation' example and add a point light with shadows enabled, i get the following error:

Shader error in 'MegaSplat/MegaSplat': invalid subscript 'vec' at line 5461 (on d3d11)

Spoiler: Code

The TRANSFER_SHADOW_CASTER(o) is the line in question.

VertexOutput NoTessShadowVertBiased(VertexInput v)
{
VertexOutput o = (VertexOutput)0;
UNITY_INITIALIZE_OUTPUT(VertexOutput,o);

o.normal = UnityObjectToWorldNormal(v.normal);
v.vertex.xyz -= o.normal * _TessData1.y * 0.5;
o.pos = mul(UNITY_MATRIX_MVP, v.vertex );
o.coords = v.texcoord0;

#if _PASSSHADOWCASTER
TRANSFER_SHADOW_CASTER(o)
#endif

return o;
}

The result is that the point light does not emit light anymore and also doesn't cast any shadows.
Is this a bug, or a limitation of the tesselation shader?

 

Maybe I should detect that the mesh is in the hierarchy and do that; I usually do them from the raw assets..

 

Do you have height maps in your textures? No reason tessellation/displacement shouldn't work fine in triplanar- you can even see some users using it in this thread. Parallax, on the other hand, needs UV coordinates to work.

Hmm, odd. Maybe this happens when the shader gets recompiled because of an option change- should be something I could fix though..

No, however, if you are using a Unity Terrain you need to hit the big save button in the terrain painter, otherwise the data will not be saved to the splat control texture. It only edits the in-memory version while you paint because saving the file would be too slow. If you are painting meshes, then the data is stored on a component on the mesh, and saved with the scene.

 

So I've seen this error before but never had a decent repro- it seems like Unity's HLSL2GLSL cross compiler is making some mistake. I'll take a look and see if I can find a way around it. Can you take a screenshot of the material editor (shader generator) section of the shader for me?

Also, in 0.99 I have a proper deferred pass, which will be the way you'll want to render things if you have lots of point lights..

 

I'm not sure if that is what you want, but here you go:

Edit: Posted the wrong thing...

 

I meant the material inspector section where you set various shader options in MegaSplat, but I managed to repro the issue in the mean time and have a fix. If this is blocking you, you can open up the megasplat_shared.txt file in the fragments folder, search for the struct VertexOutput, and add the following to the structure:

#if _PASSSHADOWCASTER
float3 vec : TEXCOORD10;
#endif

Then modify an option in the material to get the shader to recompile and it should all work..

Thanks for the repro!

 

Wow, that was a fast fix and it works as it should.
Awsome support!

 

do you have any plans for mapmagic/voxeland implementation(infinite terrain) i really like your tool, great job!

 

Depends on who does the work I'd basically like to get deep integrations going for most of the major terrain packages out there, but have been focused on getting the 1.0 version done as a first priority with the current converter being a way to convert any Unity Terrain to a MegaSplat version. After 1.0 ships, I want to do some surveys to see what's most important to users, with those types of integrations being on the options list. It takes a lot of work to learn someone else's system, so any time an author of such a package wants to help do that work that package is going to become top priority. Several packages are already doing in-depth integrations with MegaSplat, and I've prioritized their feature requests above others.

 

Hi Jbooth,

I'm experiencing some strange artifacting on my normal maps when using a Megasplat material on terrain. I've checked, and it's not an issue with the normal itself, since it looks fine on unity standard materials.

The side of that rock face is the culprit.

Your help would be much appreciated, thank you.

 

You're talking about the dark shading on the side? A few questions:

- Which packing mode are you using?
- What platform are you seeing this on?
- Have you tested to see if this is coming from lighting or shadows?
- Which Unity Version?
- Also, if you could post a screenshot of your materials settings (specifically the compiler options at the top) that would be useful.

The reasons I ask these are the following:

- When using NormalSAO or NormalSM packing modes, the textures are packed with the RGBA texture compression for that platform. On some platforms (PC/Mac, for instance) there are special texture compression formats available for normal maps, which can look better than using DXT5 (which is what would be used on those formats for an RGBA texture). Also, if the packing mode was different than the texture packing, or your normal maps were not linear, or they were set to be normal maps when they're going into NormalSAO/NormalSM modes (instead of advanced/linear).

- Platform tells me which texture compressions are available, and what format the textures might actually be in.

- Unity's shadows were greatly improved in 5.5, so some errors, especially up close, are fixed by these changes.

- I use unity's standard shader model when tessellation is not on, but call into Unity's lighting functions when tessellation is on. This means that when tessellation is off, lighting errors are usually in the data.

Some things I would try:

- Set all the normal maps to uncompressed to see if compression is causing the issue

 

I'm running this on PC.

I managed to solve it from the explanations you provided, I hadn't set my textures as linear in the array. I had thought it might've been my image format, which are PNGs but it didn't seem to make a difference.

Setting it to linear has fixed it though.

Thank you for that.

I'll look into Unity 5.5 if the shadows are better as well.

 

Great - yeah, they reversed the Z buffer for the shadows, which greatly improves accuracy of shadows close to the camera.

 

Hi.
This is a great asset. I'm really glad I bought it.

I have one question though. I have noticed that when Unity's terrain has a rectangular shape, textures that I paint on it with MegaSplat get squashed on one axis.

I already tried using all of the splat UV modes. With UV Project Axis the splat map gets tiled throughout the whole terrain, and while it looks like I can modify the UV scale on both axes, I'm unable to find values that would eliminate the tiling effect. Triplanar is perfect, but I read in documentation that it requires 3x more samples, so I can't really use it as the project I'm working on is for mobile devices.

Is there any other way of avoiding texture squashing while painting over a non-square terrain?

 

Not having used Unity's terrains much, I never realized they allowed for non-square terrains. It would be pretty easy for me to add a 2d scale for the uv coordinates instead of a 1d one, which would allow you to correct for this. I'll add it to the list for the next patch..

 

Thanks, this would be great.

 

When you have combined your textures correctly Color texture with the Heightmap added n the alpha channel and Normal,Smooth then AO as the alpha map for the normal texture and then setup in your splatmap material then try sliding the global up bias to 0 when in triplanar mode - I noticed everything is flatten in the opposite direction - I had the same problem trying to understand what was going on. Also the interpolation contrast brings out more detail closer to 0.


@jbooth I think I'm getted a solid handle working with Megasplat now.. the water was really unbelievable (very realistic) although you can't see the same level of quality in the video

The only thing now that I'm struggling to understand now is why I can't change the smoothness of each texture.. they all look wet. Is this because that the shader is set to refractive in the flow mode or should I still be able to control the smoothness/wet look of each texture?

 

Do you mean with flow mapping or with puddles? With flow mapping, you set the alpha/refraction amount on each texture in the per texture properties.

With puddles or puddlesFlow, there's a global setting for the water tint and alpha. In 0.99, I'm adding a per-texture porosity amount- this controls how much the albedo is darkened by water - for instance, smooth surfaces often have a low porosity, while rough surfaces have a higher porosity and darken more. It also takes the smoothness of the surface into account to give it a per-pixel value, so the optional per-texture value is really a scalar for the total porosity.

What I haven't done yet is tried adjusting the water such that you can paint areas to be wet before they become potential candidates for water. This would allow you to paint a low puddle value around the area to make the area look wet, then paint higher values where you want water to potentially appear. That could be very useful for caves..

 

I have the shader set to puddles flow and all textures that wont have any water or gloss over them have refraction at 0 and smoothness at 0 but everything is still shiny/wet looking

The part you haven't done yet you're talking about for example making an area of sand become darker fading out from the water edges? I would love that too.

 

@jbooth Hello, I'm resuming an old post about 'Importing Small Asset' every time something is changed...

For some reason the stored hash and the calculated one are different. Seems that changes are not stored, for example:
- I open the project.
- I delete an object from the project (for example a texture that is NOT on the textureArray)
- The postprocessor code check the arrays to see if something is changed. The new hash is different from the old one so rebuild and save the texture Array.
- I save scenes and project, then exit unity
- Reopen the project again and repeat the sequence: it gives the same result, rebuild the texture Array and save it every time.

I'm using unity 5.5.1p3 on Windows 10 x64

Note: if I put a breakpoint on the hash check, I can see that the calculated hash and the stored one has the same values every time, so seems that the new one is not saved.

PS: seems that behaviour for EditorUtility.SetDirty(obj) is changed from unity 4 to unity 5... maybe the problem is there ?

 

If you are using NormalSAO then smoothness comes from the texture, not the slider- and refraction is only used if the texture is flow mapped (not in puddles). The only thing that can cause textures to look wet when they aren't right now is the melt option on the snow.

yup. The trick is where to store the data- I'll have to add another vertex interpolator for meshes, which pushes it to a 4.0 feature, and for terrains another painting channel. I thought about this all day yesterday and I don't think I can do it within one parameter.

Hmm, maybe that explains why I couldn't repro it - mine are saved with the correct hash. I'll see if I can repro this with the new steps..

 

Yup, I see the case; there's one in which SetDirty isn't called. If you add a " EditorUtility.SetDirty(cfg);" to the last inner block of TextureArrayPostProcessor.cs if should fix it. I'll verify and include in 0.99..

 

A quick question - is it better to have 1 single Megasplat material that contains all of your source materials (woods, rocks, stone, plaster, grass, mud etc.) that is used by pretty much every tileable mesh in your game or separate them into separate materials (Woods material, Stones material, Bricks material)?

Thanks!

 

I'm sorry to tell you that adding that instruction into the inner block doesn't solve the problem. How can I help you to fix it ? Maybe a video or something else to repro?

 

Ugh- ok, well, I'll need to play around a bit and get it reproing on my machine..

 

Better to have one material, as then everything can be in one draw call..

 

Ok, I have a repro- not sure why the hash is changing when you delete an object, but it is, so I'll figure it out..

 

Ok, I have a fix. Here's the new function:

Code (CSharp):

1. public int GetNewHash()
2.       {
3.          unchecked
4.          {
5.             int h = 17;
6.             h = h * Application.platform.GetHashCode() * 31;
7.             h = h * Application.unityVersion.GetHashCode() * 31;
8.             h = h * 31 + physicsDataSize.GetHashCode();
9.             h = h * 31 + linear.GetHashCode();
10.             h = h * 31 + exportTextureList.GetHashCode();
11.             if (sourceTextures != null)
12.             {
13.                //h = h * 31 + sourceTextures.GetHashCode();
14.                h = h * 31 + sourceTextures.Length;
15.                for (int i = 0; i < sourceTextures.Length; ++i)
16.                {
17.                   var t = sourceTextures[i];
18.                   //h = h * 31 + t.GetHashCode();
19.                   h = h * 31 + t.format.GetHashCode();
20.                   h = h * 31 + t.width.GetHashCode();
21.                   h = h * 31 + t.height.GetHashCode();
22.  
23.                   var bytes = t.GetRawTextureData();
24.                   for (int j = 0; j < bytes.Length; ++j)
25.                   {
26.                      h = h * 31 + (((int)bytes[j] + 1) * (j + 1));
27.                   }
28.                }
29.             }
30.             return h;
31.          }
32.       }

The problem is that the hash code for the texture or array may change between runs (because they are recreated each time), so they were causing the hash code to change. This wasn't being caught on the initial import, but waited for the delete to trigger a reimport, causing the issue.

 

This is a problem because I work with GIT and this continuous recreation of the textures mark them as 'changed' and it ask me to save all of them each time.
There is no way to avoid to recreate them? Maybe using the GUID of the object to check if is changed ?

 

The code above should make it so the texture array is only rebuild when the textures actually are changed..

 

I'm sorry but that code doesn't solve the problem: every time I reload the project it rebuilds the array...

 

Grrr. Hmm, well, I have closed unity, reloaded it, and deleted assets dozens of times and it hasn't rebuilt the array once since I put both of those changes in. (Both, meaning the extra SetDirty and the new hashing code). I also made sure the new hashes were saved with the arrays (you can flip to the debug inspector to see the hash value and make sure it's staying the same).

The process I used to find those two was to comment out sections of the hashing code so that it wouldn't hash those features, then update all the arrays and save the project to make sure they had the new hashes, then reload unity and delete an object/save project/etc. The reason those two needed to be commented out is that they aren't asset data (ones is a List<Texture2D>, for instance - it shouldn't be hashed because it'll be newed each time it's serialized- only the content within it should be). Perhaps you could try commenting out chunks of the hash code until you figure out which block is causing the issue?

 

OK, my fault: after a lot of tests I can say that It works!
Probably something in my test configuration was wrong. This morning (6.23 AM here) I repeated all tests without problem. Sorry for the latest message and thanks for your support

 

No problem, most likely the new hashes weren't saved the first time triggering the issue again. Thanks for the repro; while mostly just annoying in your case, in a live product using asset bundles, that could have caused the texture arrays to be changed on each build, which would cause lots of excessive downloads, so it's a great bug to get fixed..

 

Hi Jason, any chance you could take a peek at the RenderBake code for terrains again? In 0.98 on Unity 5.5.0f3 (Windows 10) I get all purple/pink textures. When I peeked at the code -to me- it looks like the Camera setup is still broken (at least for terrain) and when I changed it to the code I added before it still ends up with purple/pink textures.
Or has this been fixed for an upcoming release? I'm anxious to give the Macro textures a spin

 

Found and fixed- sorry about that. Seems Unity doesn't run it's autoupdater on shaders unless they are written to disk, and I had some old _Object2World instead of unity_ObjectToWorld in there. I can send you a patch, but I'm in the middle of a lot of stuff so I would recommend you doing the change yourself- basically, search through the fragments folder and replace any _Object2World with unity_ObjectToWorld and everything will start working again.

 

So, some news on 0.99.

As this is the last version before 1.0 (hopefully, I could do a .991 if needed), I've done some changes which are not compatible with old data. For the most part, I don't think these will affect people much beyond the initial tweaks, but let me know if any of these sound like an issue for you. The main changes in this regard are:

Mesh Workflow:
- Flow direction is now stored in UV2.zw instead of UV2.xy. This is because some lighting modes in unity write into UV2.xy, and although no one has complained, I thought it best to move them now. As such, you'll need to repaint flow directions - but this is usually a few swipes. I considered making this an option, but it seemed wiser just to move it so people don't get strange lighting issues.

Unity Terrain Workflow:
- Displacement Dampening has been moved from the SplatParams texture (b channel) to the SplatControl Texture. This makes room for the new paintable wetness. This packing makes a lot more sense, because it means if you need displacement dampening on your tessellated terrain, you don't have to sample the parameters texture if you're not using puddles/wetness/flow. When you first open your terrain, it's going to warn it's in the wrong format and ask you if you want to fix it- this will upconvert your RGB24 control texture to RGB32. Note that this doesn't really affect performance at all, since a RGB24 texture is upconverted to an RGB32 on the GPU anyway. If you have painted displacement dampening data you want to keep, you can copy it from your parameters Blue channel to the control texture's alpha channel in an image editor.

Both:
- UV scaling is all vector2's now instead of single values. I spent quite a bit of time trying to revision this, and have one more idea I want to try, but Unity doesn't make this very easy. All this means if that you have to go set your uv scales on your splats, macro texture, snow and puddles again. Annoying, but should only take 5 seconds to fix.

- Per Texture Properties refactor. I mentioned this above, but the format for these has changed. The main advantage is it's much more flexible and you have a lot more of them now. Everyone that people have asked for has been implemented as a compile option. You don't automatically get ones you didn't want, or have to make choices between them (metal/smooth or flow alpha/refract). They are also more efficient when you only use some of them. You can now set things like per-texture porosity, noise strength, contrast, etc.

Overall, while some of these changes might cause some initial confusion, I figured it was much better to make them now than later and have a cleaner architecture for the 1.0 release. I will post this warning again when we get closer to 0.99 being released.

 

@jbooth we will have normal strength, smoothness and some other customizations for the macro texture too? Those are really useful when in alpha layer mode.

 

I haven't messed with macro texture options yet, but can put those in since they wouldn't take long. What are you mainly wanting?

In Per Tex properties, smoothness/metallic are always available whenever you do not supply those values via a texture array (Well, if you turn on that option). I haven't done normal strength yet, but would be easy to add.

 

Added per-tex normal strength and macro normal strength..

 

My current setting (at this time on another shader) for the macro texture that I use as bottom layer when painting in Alpha Layer mode:


Obviously wuld be wonderful to have all of that

 

So albedo tint I get. Specular color only makes sense in a specular workflow (MegaSplat is metallic). What does the occlusion slider and smooth min/max do? (Megasplat uses an occlusion map, is this just a strength modifier?). Also, what is diffuse scattering in this context?

 

Fine, shove that in your cave hole..

 

@jbooth: hey just got your great megasplat package after your suggestions on github
Unfortunately there seems to be a mean memory leak in the "RunetimePainting.cs" in the Mesh.scene demo which only occurs when building the Scene. I suppose it's the "if UNITY_EDITOR" stuff for the allocations ... Would be great if you could take a look at that because I'd really love to base my implementation on the runtime painting

 

Leak or allocation? I'll take a look; but yeah, it has to do a bunch of extra crap in the editor to restore state after playmode and such. How is this manifesting at build time?

 

hmm good question, I can't really answer right now ... well the build fills up 500MB of memory every second or so