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

Hehe, detective work.
For huge terrain maps there are other tools to do such a job properly. Unity is not a proper environment for such a task.

I`m afraid I do not agree with you that my attitude is being somewhat belittling and rude.
It`s just that I find really frustrating when clever/hard to implement features are developed and the workflow is neglected big time. To me it's more than obvious that having 4 submeshes in a object you go with individual maps from start to finish. That is the reason you split the object in the first place.
I`m a one man band and I try as much as possible to avoid the boring, brainless, steps in my workflow. My energy and my time is limited, so any workflow optimization, not to mention any possible automation is more than welcome.
I'm surprised that, as a Megasplat user, you're not happy with my request.

 

I didn't planned to use your asset with Amplify Texture.

Using naming conventions is a very common way to handle your assets. Baking the texture using a objectname_channelname is a very common approach. That is why my request is a very common one.

At the end of the day, it's your asset and you know better what's good for you.
Even if you decide not to do it, your asset it's still a very cool one. And I will not insist anymore on this.
Cheers.

 

And then you're stuck combining textures in photoshop when your terrain is broken up into multiple pieces, because mesh_01 and mesh_02, which share the same UV space, end up producing two separate textures. The naming of the files is not the issue, it's the mapping of object->texture, which can be arbitrary..

 

Pardon me, but I don't get it. You mean assigning the proper image to the right channel on the appropriate material?

 

No- say you have four meshes that act as one terrain (each taking a quadrant of the UVs, much like in the mesh example scene). If you strictly export one mesh to one set of textures, then you get 4 sets of textures which will need to be combined in photoshop to create one macro texture that covers the four meshes.

That's the core of the issue- a 1 to 1 mapping of object to texture cannot be assumed, especially when dealing with meshes, where you often share a macro texture among many meshes.

In the current tool, the selection acts as a way to say "All of these go into one texture set".

 

I'm a decent 3D guy and I plan my things in advance. If I split the terrain I have reasons to do it. No matter if later I will merge the textures in a common atlas texture or not. Usually I do that for smaller size objects. If the objects are bigger, I will keep one texture set/object. At the end of the day I have to organize my game level in such a way that I have a consistent/even as possible texel density.

This is exactly the constrain I was trying to avoid. I do not assume that the bake is the final asset. There are so many reasons you build your workflow according to the tools, task, and possibilities.

 

I don't even see how you see this as a constraint- if you only want to bake one mesh, just select one mesh. It doesn't prevent you from doing anything.

 

It is a constrain because you are trying to make me work the way you see it fit. I don't have the freedom to work the way I see it fit. It assumes that the selected meshes shares the same UV space. That is a constrain.
Selecting and baking one by one it`s far from an elegant solution. Especially for such a powerful asset where you can paint as many objects as you want but you can only bake one.

 

Then you need to be able to answer my previous questions about how you script this in such a way that accommodates all workflows and keeps complexity down. I am not building a tool just for your specific workflow at the cost of everyone else's.

 

Also, you can always write game specific scripts which process this stuff however you would like it to work. I don't wrap my code into DLLs to try to hide it, it's easily accessible for customization.

 

So as far as I understand you want him to develop a solution for automatic layouting??
Either the meshes do share the same UV space, then you'd bake them all to one image, or they do not, in which case you'd bake single images. But don't expect the tool to be able to export to one big image when the UVs of the individual meshes overlap. That goes a bit beyond what this tool is supposed to do IMO.

 

I think what he's asking for includes:

1. Rendering to infinitely large textures (though he's moved away from this)
2. Rendering each mesh to it's own texture set as a single batch process, naming them based on the object name. IE: You select a bunch of meshes, hit bake, and it spits out one macro texture set for each mesh.

My argument against #1 is that there is no use case and textures of that size are not usable in realtime environments.

My argument against #2 is that it isn't general, and is specific to his personal use case, since it excludes rendering multiple objects to a single texture. Further, to support both use cases, you'd end up with a much more complex tool, where you have to specify mappings of meshes->textures, such that multiple meshes can be on the same texture or be rendered to unique textures. I need to support the case where multiple meshes end up on the same page; it's quite common to break up a mesh into multiple meshes for reasons other than texturing (vertex limit, culling, etc). The example included with MegaSplat does this to get around the 65353 vertex limit, for instance. So removing that capability and requiring users to stitch multiple maps together in photoshop is a non-starter for me.

That said, something to automate this whole process could be created, and would have potential use cases, such as painting over thousands of objects and hitting a build button to bake out all of the macro textures and automatically assign them to the objects. However, it's way out of scope for where this stuff is right now, and would require a lot of tooling to work well. Tooling which would be difficult for new users to understand and likely create subtle bugs.

Basically, you'd have to have a component on every object which says which texture it's data should be baked to, what packing to put the data in, and what property on the shader each texture should be assigned to (Easy if the shaders are the included ones, but not if your rolling your own with ASE). It would have to automatically handle or warn you when you copy an object in Unity, since they would now overwrite each other, or automatically generate a new texture for each object unless the object belongs to some kind of "texture group".

So can it be done and made general? Sure. But it gets messy fast.

Further, the main reason to blend into a Macro texture at a distance is to avoid doing the splat map calculations in the distance (optimization). But in this use case, that doesn't actually help the frame rate. It makes a lot of sense for large terrain chunks, since you'll draw a lot of pixels as the macro texture when they are in the distance. But lets say we have 1000 rocks on that terrain and we generate a small macro texture for each rock rather than just computing the MegaSplat blends at runtime. Now we have 1000 draw calls for those rocks instead of one draw call, because each rock has a different material with a unique Macro Texture assigned to it. Meanwhile, each rock is only 10-20 pixels in size, which makes the shader expense of doing the blending insignificant compared to the expense of adding another draw call. So it's actually faster to have them all compute their blends and skip the macro texturing all together, which basically negates the use case specified for this feature. And you save the memory used for those 1000 rock's macro textures, which even if tiny, adds up quick.

In the end, only large terrain chunks make sense to generate macro textures for. In any given level, there will only be a few of these- and if there are lots, it's because you've broken a single mesh into a bunch of subsections and want to treat them as one piece, which is what the current workflow supports.

 

One thing to note is that optimizations are often case specific. Swapping to a macro texture is one such example; it's not always going to be faster to use a macro texture in the distance, especially if a significant number of pixels are not going to be rendered that way, or if it's going to increase draw calls counts.

If you want this type of functionality I would suggest Simplygon. Their new licensing costs are a little crazy, IMO, but it is a wonderful package for doing this type of work. In a previous game I worked on, we render baked all the meshes and final shader outputs to the lighting equation (albedo, normal, etc) in a 64x64x64 cube to simplygon, which returned a single mesh and texture set for the resulting LOD. We then repeated this process at 128x128x128, 256x256x256, etc, until we had a hierarchtical representation of the entire level as blocks. We could then move around the level with complete predictability over mesh/material/draw call complexity, only drawing the real objects when very close to the viewer.

 

Guys, I'm tired. I surrender.
One last thing: I don't plan to use Megasplat with Amplify texture. I swear!

 

Hey jbooth, has anyone asked about or have you heard anyone using MegaSplat with Voxeland? I don't recall seeing any posts about it but I'm thinking it might be a great combination. Not asking for anything, just don't want to re-tread old ground on my own. Otherwise, I'm going to take a closer look into it.

 

I know several people have used MegaSplat with voxel engines, though I'm not sure which ones. Let me know how it goes- maybe it will make sense for me to do some integrations in the future, or provide geometry-processing-free versions of the shader through a geometry shader (which is slower, but doesn't require mesh preprocessing).

 

Not trying to brow beat you into submission Mark- I believe it was you who suggested a render baking feature in the first place, which was a good idea. In general though, I like to avoid making workflows easy which lead to other problems, and think render baking lots of objects with ease is going to lead people to create future problems for themselves.

 

Wohoo! 0.93 is out, now I can submit 0.94..

Note you'll need to recreate your shader with the new shader generator (or back up the old ones if you still want to use them). But it's super easy to recreate them with whatever features you want.

 

Would it be possible, at least, to name the bake using the name of the selected object? This way we save the time and effort renaming the maps.

On a side note, it's a bit disappointing that the whole discussion got derailed towards the AmplifyTexture theme. Anybody who treasure his time and energy appreciates a good and user friendly workflow.

 

The current workflow is the most user friendly for most peoples use case, which is baking a reasonable number of terrain meshes out to build a macro texture. And most of the discussion I was having was less about > 8k textures and more about baking workflow. If you want to automate baking out hundreds of individual textures, it's quite easy for you to do that, but you're going to kill your performance using that approach. Textures are already named via the first object in the selection set.

 

Cool!

 

A user reported a bug with the Flow mapping in the latest patch. It's fairly easy to fix, so I'm going to include the fix here since the next patch will take at least a week to make it's way though the asset store pipeline.

Around like 117, right before an #endif block in megasplat_mesh_body.txt, add the following line:

Code (CSharp):

1. mData.flowOn = 0;

Which should make the code look like this:

Code (CSharp):

1. #if (_FLOW || _FLOWREFRACTION)
2.  
3.                Flow(sData.uv0, i.extraData.xy, _FlowSpeed * sData.flowIntensity.x, _FlowIntensity, sData.fuv0a, sData.fuv0b, sData.flowInterps.x);
4.                Flow(sData.uv1, i.extraData.xy, _FlowSpeed * sData.flowIntensity.y, _FlowIntensity, sData.fuv1a, sData.fuv1b, sData.flowInterps.y);
5.                Flow(sData.uv2, i.extraData.xy, _FlowSpeed * sData.flowIntensity.z, _FlowIntensity, sData.fuv2a, sData.fuv2b, sData.flowInterps.z);
6.                sData.dxfuva = ddx(sData.fuv0a.xy);
7.                sData.dyfuva = ddy(sData.fuv0a.xy);
8.                sData.dxfuvb = ddx(sData.fuv0b.xy);
9.                sData.dyfuvb = ddy(sData.fuv0b.xy);
10.                mData.flowOn = 0;
11.             #endif

You will need to recompile the shader by toggling an option on your material's shader compiler section to get it to regenerate the shader with these changes.

 

0.94 is now submitted to the asset store!

Adds support for easy conversion from Unity Terrains, which basically makes it possible to use Gaia, Terrain Composer, Map Magic, or other terrain generation tools to generate terrains and convert them directly to MegaSplat form.

Adds support for Render Baking Macro textures from terrains or meshes

The usual batch of bug fixes and improvements.

With the holidays here, I'm expecting this will take a little longer to get released, but it's in the pipe none the less..

 

Stumbled upon this yesterday while looking for your vertex painter and grabbed it. Looking forward to putting this to good use. The sample scenes give a good indication of possibilities with really nice variation. Looked better than the images on the sales page which was nice.

I did notice that the mesh landscape ran more than twice as fast as the unity landscape which was also very interesting.

Great useful tool. Thanks a bunch.

 

Sigh. Yeah, I hate doing marketing work- but I need to make all of that stuff look way better soon.

Unity Terrain is horribly unoptimized. People want to use them, but there's really no reason to use them over meshes. The terrain shader is also a bit slower because it has to use a texture lookup instead of having the data on the vertices, but there's not much you can do with Unity Terrains being such a black box.

 

Well after seeing the speed difference I must say I will have to find time to convert my current unity landscapes to meshes. I haven't looked into it but I thought gaia might do it, which I already have.

On the marketing stuff.. I'm sure you'll get there soon enough. MegsSplat is too good a thing not to go nuts when the word is out.

 

@jbooth
Hello jboot, I've purchased megasplat and trying to use it to refine my meshes.
Probably I'm missing something but actually I had a lot of problem using your beautiful asset.
I'm trying to do something like in this video about at 2.30 - 2:40

but have no success.
Can you tell me if this is possible and eventually suggest me some steps to do that on my meshes ?
I feel a totally noob but english is not my language and sometimes I loose details
Thanks in advance

PS to be more detailed: I already have a texture on UV and I need to paint dirt, wet, scratches and so on. The vertexes number may be significant ? I have very low polys meshes for roads, should I tessellate them ?

 

There's a few ways to do this kind of thing. There are actual traditional splat map shaders included in the extras.zip file that are closer to this use case, and can be cheaper when you only need to paint one or two textures.

I've been meaning to sure up this workflow for MegaSplats, but haven't spent the time to do it because everyone so far has been using it for landscapes. That said, there are a few ways to do it:

1. Put your textures in a texture array and assign them by painting that texture onto each surface. You can put additional textures into the array (alternate versions with cobwebs, etc) and blend between them by painting different versions down when your want them. If you use a two layer shader, then you can control the amount of blend between different texture sets by painting your variations onto a second layer.
2. You can put your original textures into the macro texture slots of the material. Set the shader to "Splat's on top" and the blend mode to "overlay" or "multiply2x". Then you can design your splat textures as if they are blended with the main texture via these blend modes. Your first texture would be one that has no effect on the object (the color being grey, the normal being blue, etc). then you can paint that splat texture over the object (which should have no effect) and paint into other textures when you want to blend those looks in.
3. I can add an alpha option to megasplat, such that you can paint how much splat is used at a given point vs. the macro texture. This would allow you to set up the meshes with standard texturing (using the macro texture), then paint megasplat over it. I would likely only be able to use a single megasplat layer for this since the interpolators are full, but it shouldn't be hard to add. I think this would be closer to what you want than either of the above solutions, since you could basically just paint a transition to dirt/whatever over anything in your scene.

 

Here ya go:

The current patch is working it's way though the pipeline, so I'll have this available for the one after that. If you need it sooner, send me your invoice (privately) and I'll send you the changes earlier..

 

Thanks a lot, I'll start to try all your hints. At the moment I'm still experimenting on this because I'm in a pre-alpha. Thanks a lot for your really super fast reply.

 

That seems like the other thing I needed to sort out. Might send a PM so I can mess around with it sooner rather than later.

I had a quick test of a mesh export from a Unity Landscape, unfortunately it loses all the landscape texturing so I might have to think about that for a bit. I have asked on the gaia thread if there is a known way to retain it. Here's hoping.

 

You can likely export the splat maps as a texture, then rotate them and use the Color to Splat tool to project them onto the MegaSplat mesh. I haven't actually tried this, but it should all be possible, as that's basically what the terrain to megasplat texture converter does.

 

Thanks @jbooth I will find some time to give it go a bit later.

 

Is it possible to have Macro Texture with Cutoff mask (Shader Type: Mesh or Terrain ) ?

 

Cutoff mask? I'm not sure what you mean..

 

Like this :

 

Oh, you mean an alpha version of the shader with alphatest as an option. Out of curiosity, whats the use case? Painting details onto tree's or something? It wouldn't be that hard to do, but would either require a new packing format where the height map is somewhere else, or a separate alpha texture.

 

If shader type is terrain , i can use it on terrain hole .

If shader type is mesh ,
I can put some grass or moss on the roof .
Like this :

 

I'll stick it on the backlog- have quite a bit of stuff to get through first, but will look at it eventually..

 

Lost UV2 When using Megasplat Mesh Conventer.
So Lightmap baking doesn't work if UV2 is not same as UV1.

 

Should be an easy fix, let me take a look and I'll send you a patch if you send me your invoice/email in a PM..

 

Another video on new features:

BTW, if any of you who haven't could rate MegaSplat for me, I'd appreciate it. Reviews help people have confidence in an asset, causing it to sell more and getting Unity's attention (featuring), which causes the authors of those products to be able to spend more time supporting those assets.

 

I owe you a five star review especially based on the new features coming out. You're support and plans for this are outstanding.

Btw, it'd be awesome if you worked with Adam to incorporate this into Gaia's auto texturing workflow.

 

We've been talking for a while, but he's been pretty busy. It's pretty easy to convert from Gaia to MegaSplat with the new conversion system that's currently in review, but having an integration that takes better advantage of being able to have hundreds of textures and can maintain the mappings through changes is really where I'd love to see it go.

 

Hi Jason, I did a build for Android, 3.0 and aboove as stated, I keep getting a black terrain. I can see the SKy box fine, if I add cubes, spheres etc , those are fine, but the terrain is black. I did it with a test demo scene.

Is there something in the demo scene causing this for Android??

Thanks!

 

Shouldn't be - I have tested on several android devices, and all of my devices which run openGLES3.0 or above seem to work fine. Given the variability of hardware on android, it wouldn't surprise me to find a device that has hardware that skimped out on the full openGLES3.0 spec (given that there's plenty of them that don't handle texture coordinates in the pixel shader as high precision).

Can you get me a full hardware spec of what your testing on? Also, if you can tell me what SystemInfo.supports2DArrayTextures outputs on your device says, that would be useful. If that says false, then your device is not compatible. If it says true, then let me know what graphics API it thinks it's running (openGLES, vulcan, etc). (Also of note, if your forcing a specific API in your build settings that could do it too).

 

Well, I'm pretty convinced I have one of the best looking tessellation routines on the Asset Store now, and very configurable. Works for Terrains and Meshes, with all modes supported (flow mapping, triplanar, etc). Makes me want to write a better shadowing system for Unity though (though maybe 5.5's reverse Z will make all the difference).





It also makes me want to spent like a zillion hours tweaking height map data, but I will resist for now..

 

I have 8 devices or more.. that I use. So I have tested with http://www.samsung.com/us/mobile/ta...-galaxy-tab-3-7-0-wi-fi-white-sm-t210rzwyxar/


and a newer Phone, I will get the specs in a few, I will try other devices.. and get back to you later tonight . But if i'm seeing devices that are 3.0 and above not working, then I cant use your asset..... seeing this is /was a very popular tablet... this is a cause for concern as a developer , as I will get low ratings.. reviews if I get to many devices not working... Again this is a popular tablet, its about 3 years old. Also my phone is about 1 week old. But I will get those specs, and I need to test all the others.

 

Landscape turns black when a) texture arrays aren't supported on the device. or b) one of the following defines is not met:

#if defined(SHADER_API_D3D11) || defined(SHADER_API_XBOXONE) || defined(SHADER_API_GLES3) || defined(SHADER_API_GLCORE) || defined(SHADER_API_PSSL)

#if defined(UNITY_COMPILER_HLSL2GLSL) || defined(SHADER_TARGET_SURFACE_ANALYSIS)

The else cases basically return half4(0,0,0,0)

 

using your demo, didnt change anything, and if the device(s) is not supported then I cant use this asset.