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

I can't change your hardware, and I can't help if you don't post any of the info I've asked for.. Keep in mind there are project settings you may have set (forcing openGLES2.0, for instance), just like when you had the issue with it not running in the editor (you were running in emulation mode or on DX9 level hardware, if I recall). I can't debug any of these potential issues when you don't post any of the information for me to go on.

 

what more info do you need??? and as I said......I would post the other device later tonight when I have time... But I gave you ONE DEVICE TO START with....... but since you want to be rude, I will take it as you aren't interested in helping best of luck with your asset....


Again, I gave you one popular device and if that device is not supported then the asset is no good to me, either way... even if it works on my 7 other devices...If this was an unpopular device that would be another story..


PS: IMAGE showing its DX11... 3.0.

 

as I recall, that was another issue as well, since I run on many computers to test MANY issues that come up with Android.... I also run a script that forces it to stay in DX11 since Unity is to LAZY to fix that.. This issue happen before I even built anything, it was an editor ISSUE and I clearly stated it was my fault.... anyways this was tested my my entire TEAM... so I wanted to be sure... before I posted about it..



again best of luck with your asset .

 

I don't see any rudeness here. jbooth can't exactly magic up a Samsung Galaxy Tab 3 if he doesn't have one. He's responded with as much help as he can, given the limited information you provided(black terrain, Samsung Galaxy Tab 3). You got a description of shader feature requirements that would cause the black terrain you're getting. It's your job to determine if your list of devices supports the features his shader requires from there. He shouldn't be the one that has to dig into specific devices to figure out if they are supported, especially when it comes to Android devices as there are hundreds of distinct models.

 

if you read, what I said, I would GIVE, him the info ;later tonight, but you may think he was not being rude, I did by his comment, about an old issue which I clearly stated was my fault how many people say sorry my fault, anyone that knows me, knows I support many developers here and most are helpful... so I don't just call anyone rude, I felt he was..But your welcome to your opinion.

I also answered his question as he asked me what device, most people don't have 8 devices, most have one.... so I GAVE HIM one POPULAR one.. so if he need more info ... again, not everyone is a shader expert , I'm a programmer and artist, other wise I would of NOT bought this asset... I bought it seeing that it says it works on Android 3.0 and above, and yes I do understand some... devices may not work..That is life...But a popular one, is a problem for me..



Seeing that out of 50 of my testers, 10 have that device..

. Again, best of luck.

I will move along. Thanks.

 

I asked you to post the results of SystemInfo.supports2DArrayTexture; No response.

I asked you to post what graphics API your device thinks it's running on. No response.

Yeah, that's great - you realize that your android device is not running DX11, and that's your editor, right?

I'm not the one being rude here. You come onto this thread complaining about "a popular android device" not working, provide no real information, and then proceed to post several times about how you can't use the asset without posting any of the info I've asked for to help you debug the issue.

A Samsung Galaxy Tab 3 is actually a pretty vague description for an android tablet. My last game logs unique device configurations, and I see 17 variations of the Samsung Galaxy Tab 3.

That said, if you check this page:

http://www.notebookcheck.net/Qualcomm-Adreno-305.110715.0.html

You will see the GPU most commonly found in a Samsung Galaxy Tab 3 runs DX9 or openGLES2.0, which makes it a non-compliant device, not a openGLES 3.0 device as you have previously stated.

 

I think you're confusing OS versions with openGLES versions.

 

The big issue with Android is that they keep selling these relatively ancient GPUs as a way to get device costs down, and consumers have no idea what a GPU is, or what it does, so they tend to add larger screens and more storage space instead. Hey, android tabled for $50 - sold. So you end up with tons of devices that are fine for browsing the web or playing simple games, but just can't hack anything reasonably complex.

Last time I checked our game's database, we had over 10,000 uniquely different android configurations that we supported (we run on iPad2's, and low end android devices - I write higher end shader stuff in my spare time as a way to get away from this). We also have about 100 devices for local testing, and use external services to test on more. One of our devices at work has 2.5k screen, but with the GPU equivalent of an iPad2. Sometimes I think an engineer just puts random parts in a box, shakes it, and out comes a new android tablet.

iOS, on the other hand, has a generally upward curve on devices that's easy to manage, and in most cases, a new version is always better than a previous version (There are some exceptions, like the iPad3, which doubled screen resolution but only increased GPU speed by about 40%). Further, iOS users tend to be running newer devices than Android users, with an exception given for the iPad2, which just will not die.

 

yes sadly. anyways I have not getting all the info for you yet, super crazy busy, with Xmas and the kids, but the newer devices, seems to work. Anything older seems to not work. Going to check if it an Open GL 2.0 devices . I WILL post the info requested ASAP..

 

Well, it's pretty clear it's an openGLES2.0 device - however, if you do find an openGLES 3.0 device where this doesn't work, I'd be very interested in debugging that.

 

Tested another device Version Open GL 3.0 Shading Language Open Gl,ES GLSL ES 3.00
Android version 5.1

Arch64 Processor rev 2 (arrch 64)

Renderer PXA1928 GPU


Max Shader Binary Format : 1

SystemInfo.supports2DArrayTextures outputs: True

I believe this is it.

http://www.devicespecifications.com/en/model/f4fe3805

This one was Black as well. For sure Open GL 3.0.


The Tab 3 Samsung is an older Open GL 3.0. so I was talking to a friend , who is a shader expert, and showed him your asset, its not supported. Some of the and newer Samsung tablets are with Open GL 3.0 . are..he said more than likely, that is when some Tab 3's are Open GL 2.0 and some had 3.0. Which I had no way of knowing this, as I'm not a shader expert. Again, why I buy shader tools , such as this , Shader Forge, and others.

yup, this is the issue, with the older Tab 3's he stated. Really not old, 3 years, but in Android terms its old.. sadly.

All other devices that have Open GL 3.0 work fine.

The fun of Android... sadly.

Your asset ,Looks amazing on PC, but sadly I do not develop with Unity on PC anymore, these days, I use Unreal Cry and in house engines. for PC.

 

Not a lot on this chipset on the net, but one thing you could try is to change this macro in "megasplat_shared.txt" to:

Code (CSharp):

1. #if defined(SHADER_API_D3D11) || defined(SHADER_API_XBOXONE) || defined(SHADER_API_GLES3) || defined(SHADER_API_GLCORE) || defined(SHADER_API_PSSL)
2.             #define MSPLAT_SAMPLE_TEX2DARRAY_GRAD(tex,coord,dx,dy) tex.SampleGrad (sampler##tex,coord,dx,dy)
3.             #elif defined(SHADER_API_D3D9)
4.             #define MSPLAT_SAMPLE_TEX2DARRAY_GRAD(tex,coord,dx,dy) half4(0,1,0,0)
5.             #elif defined(UNITY_COMPILER_HLSL2GLSL) || defined(SHADER_TARGET_SURFACE_ANALYSIS)
6.             #define MSPLAT_SAMPLE_TEX2DARRAY_GRAD(tex,coord,dx,dy) tex2DArray(tex,coord,dx,dy)
7.             #elif defined(SHADER_API_GLES)
8.             #define MSPLAT_SAMPLE_TEX2DARRAY_GRAD(tex,coord,dx,dy) half4(1,1,0,0)
9.             #else
10.             #define MSPLAT_SAMPLE_TEX2DARRAY_GRAD(tex,coord,dx,dy) half4(0,0,1,0)
11.             #endif

If the resulting terrain is green, then we know the device thinks it's running D3D9 (even though the specs I can find say it *should* run openGLES3.0). If the terrain turns blue, then we know that none of these defines are present and it's running something else (maybe falling back to 2.0?). I'm going to add this to the next release and see if there are any additional defines I can use so failures all have a unique color identifying which API they think they are running..

 

sounds good thanks for your help. The other devices , works great. and looks great. disappointed about the Samsung, but life goes on. I will have to figure something out, not your fault of course

May just run a build for older devices and another for higher ones . Cant believe how good it looks on the newer devices. Really don't want to pass up on that. So I think I may do something like this. I know its odd. but oh well, I hate to not support the 2.0 and the older 3.0 Open GL like the Samsung.

due to this. https://developer.android.com/about/dashboards/index.html#OpenGL

I know you can't do anything about it. Just makes it tough to not want to use this asset with out losing money as a mobile dev. With your asset the Open GL 3.0 looks great.

 

Percentage of devices running 2.0 actually went up the year before last because of all the $50 tablets. I think it's heading the other way now, but it's going to be a few more years until you don't have to at least consider 2.0 support if you want wide adoption.

Likely the best way to handle dealing with 2.0 is to design your landscape with traditional splat mapping (4 or 8 texture), and then convert to MegaSplat for the high end using the new conversion tools. Then you at least get texture cluster variation, which improves the look considerably, and right at the end you could go through and add some non-critical layering to make it look even better. But basically accept the fundamental limitation of your lowest platform and scale up.

Let me know what color that odd device shows when you have a chance to swap in that code.

 

sure I will have to check tomorrow, I will let you know. I know that it does try to go back to DX9, but I have a script that I wrote, that forces it back. so I see it in DX11 for sure. Wish Unity would fix this issue, its been there for a few years now. seems to be worse with every update.

what new conversion tools?

Thanks for the advice, I do appreciate it. Thanks alot, this will help alot, and still should look better than the normal. Like you said in a few years wont have to worry about it, but by then I doubt I will be bothering with mobile, never know though.

(Edit) oh, must of missed it, on the docs I believe (Converting existing Unity Terrains) One the docs? do you mean?

 

this:

Though I'm pretty sure it's still waiting for Unity approval, but should be out this week if anyone is around..

 

5.5 made a big difference here -- I needed two cameras and/or log-z shader hacks before that.

 

Hey, this is pretty darn awesome. It's what I've been dreaming of for some time. I'm having an issue with Terrain Painter. It does not seem to pickup my splat map when I select the terrain and then press "Make It". I also can not seem to paint on the Unity terrain, should I be able to? This is the latest MegaSplat version, running on OSX on Unity 5.5. Thanks.

EDIT
Ah - is it not working in 9.3? I just watched your dev log 6 saying it's working in 9.4, seems I'm ahead of the curve.

 

You mean the converter? Yeah, it's still waiting in the Asset Store queue. I've been doing weekly releases and recording the dev logs when the release is ready, but with the hollidays going on the time it takes to get through the asset store has been getting slower. Normally it takes about 5 days..

And yes, you should be able to paint directly on the terrain in 0.93 using the Terrain Painter, assuming your terrain is setup with the MegaSplat shaders. It's just lacking the conversion tools from the Unity format to MegaSplat.

 

Thanks Jbooth!

This still looks good for 2.0 . Well all hope is not lost then . Still looks better again not your fault in 3.0 and PC. SADLY that is just the older devices, but still looks way better than the normal 2.0//

So I can texture my terrain in say as an example in Terrain Composer 2? Then convert it to MegaSplats? with the new converter ?


Thanks again.
I checked it this morning it was blue.
.

 

ya another asset that a friend of mine is doing his update its been 3 weeks for the update... sadly they are back logged, we heard. so could be longer.. We will just have to wait no big deal. Thanks for the update either way. JBoothe.

 

Yeah, anything that outputs to Unity's standard terrain system can just be converted. I'd like to pursue deeper integrations with some of these systems so that they can make use of having lots of terrain textures, but this makes it pretty easy to work with whatever system you want.

Well, then for whatever reason, Unity thinks it's running a different API than openGLES3.0. I think it's likely running DX9_11 mode, since that's the only one not defined to output a color in my macro. Can you try this:

Code (CSharp):

1. #if defined(SHADER_API_D3D11) || defined(SHADER_API_XBOXONE) || defined(SHADER_API_GLES3) || defined(SHADER_API_GLCORE) || defined(SHADER_API_PSSL)
2.             #define MSPLAT_SAMPLE_TEX2DARRAY_GRAD(tex,coord,dx,dy) tex.SampleGrad (sampler##tex,coord,dx,dy)
3.             #elif defined(SHADER_API_D3D9)
4.             #define MSPLAT_SAMPLE_TEX2DARRAY_GRAD(tex,coord,dx,dy) half4(0,1,0,0)
5.             #elif defined(UNITY_COMPILER_HLSL2GLSL) || defined(SHADER_TARGET_SURFACE_ANALYSIS)
6.             #define MSPLAT_SAMPLE_TEX2DARRAY_GRAD(tex,coord,dx,dy) tex2DArray(tex,coord,dx,dy)
7.             #elif defined(SHADER_API_GLES)
8.             #define MSPLAT_SAMPLE_TEX2DARRAY_GRAD(tex,coord,dx,dy) half4(1,1,0,0)
9.             #elif defined(SHADER_API_D3D11_9X)
10.             #define MSPLAT_SAMPLE_TEX2DARRAY_GRAD(tex,coord,dx,dy) half4(0,1,1,0)
11.             #else
12.             #define MSPLAT_SAMPLE_TEX2DARRAY_GRAD(tex,coord,dx,dy) half4(0,0,1,0)
13.          #endif

Aqua blue is D3D11_9X, and yellow is openGLES2.0.

The specs for that GPU (which are quite thin) state that it can run D3D9 mode and openGLES, so I wonder if there's some way to force it to run one over the other?

 

I have a Open GL viewer, running, so I don't see anything switching, so not sure. What is going on. I for sure do not seeing Unity switching it to Open GL 2.0 like before, if it did, my script with force it back. Which I see it doing fine. I also ran a few reports to see what its going and debugging it.
This is a little out of my experience but should I try another level or does that matter?
I will try that though, and let you know. Thanks for the help.

 

Ya that is smart . Looking forward to it, thanks for all your hard work.

 

Just swap in that macro and let me know what color it is on device.

The mode the Unity editor is running in is irrelevant in this case. My theory is that Unity, for whatever reason, selects the openGLES2.0 driver on that device instead of the openGLES3.0 one. That *might* be able to be fixed by forcing the API choice in the build settings to openGLES3.0 only (under Other Settings turn off AutoGraphicsApi and select openGLES3.0 as the chosen API), but it also might mean Unity doesn't start up at all on that device. I'm not exactly sure what will happen.

 

k, got you.

 

I was in the middle of a fresh install of Unity, and Mega Splats, its working now... I did this as I seen wierd issues with using Unity many times... Its all working now, so seems like Unity was flaking out.. as usually.. Seems fine now.. So by this, doubt it was a MegaSplat issue, more like a Unity issue... But who knows.. possible something got messed up in the import of Mega Splats, who knows... Not the first time I had to deal with this. Not your fault . of course just saying.

 

Well, glad it's all working. Very strange..

 

ya see this alot with Android , and known assets

 

@jbooth
Hello again, I have some troubles using the Alpha Layer. Probably I missed something. I'm on a windows 10 system with a gtx1060, working in DX11. I'm using deferred rendering and linear color space (forward and gamma give the same problem). In few words I got patterns instead of the chosen texture when I paint on meshes.
Some steps to reproduce the problem:
1) Create a new project
2) Import megasplat 0.93 from assetstore
3) replace the script/editor with the alpha layer version
4) put the boulder_splat (from Examples/Models) into the scene
5) create the shader using create -> MegaSplat - > MegaSplat Shader
6) create a new material
7) drag the shader to the material
8) drag the material to the model
9) set the material/shader properties:
Layer mode : Alpha Layer
Macro Texture - Macro Diffuse : sand_01_diff
Macro Texture - Macro Normal : sand_01_norm
what I get is half of the model textured and half not textured


Then continue to setup the shader:
10) Splat - Albedo/Height array : megasplat_diffuse_tarray
11) Splat - Normal : megasplat_normal_tarray
note that adding the normal tarray unity hangs for 5-10 seconds
what I get is that the half of the model that was not textured now has a pattern.



Attempt to paint on the mesh:
Select Vertex Paint, Custom tab, select Single Texture and use megasplat_diffuse_tarray as brush.
First click on mesh: the pattern disappears and all seems to work (I can paint on the mesh)
Change texture (First selection was ice, then I select grass) now the pattern is here again. I can't paint anymore because every texture draws only a pattern on the mesh


what am I doing wrong ?

 

I just tried to repro following your steps- I do see half the object textured when I first apply the material, but this is because of data left on the model from the previous paint job. If I fill the bottom layer, this goes away. Note that this is on the current code, which is much updated from that early version of AlphaLayer that I sent you. I will resend you the latest version, let me know if that works..

 

So, I went ahead and submitted 0.95. I figure no one is around to approve 0.94, and waiting a week to submit 0.95 doesn't make much sense. Here's a list of what's included- it's a freaking massive update from 0.93:



This is likely the most stunning improvement. The tessellation engine came out really, really nice. I support calculating tessellation levels based on edge length or camera distance, and having phong tessellation on the surface to help give things a more rounded look. There are several high quality features, such as UpBiasing (which allows you to bias the displacement direction towards the up vector - on some objects, having them stick out from the side of cliffs instead of going up can look odd), as well as shaping and mip biasing, which help you prevent small discontinuities caused by rapid changes in height map data. Per-texture properties are also available on Tessellated surfaces, allowing you to adjust the displacement amount and UpBias per texture.



It's now super easy to convert from standard terrains to MegaSplat. You just map the original texture to a texture cluster and push a button, and it will convert the terrain over for you. This gives us a reasonable level of compatibility between all the known terrain generation systems out there, such as Map Magic, Gaia, etc.

Other features:
- Render Baking - bake out albedo, height, normal, metallic, smoothness, and AO maps from your paint job to use as distance textures
- Vertex Normal Blend brush added to the vertex painter, allowing you to blend the normals of two objects.
- AlphaLayer mode, which allows you to easily layer splat maps over regularly textured objects
- Tooltips on most shader properties explaining what they are for
- shader cost display refactored and made more accurate
- Fixed a ton of bugs; thanks to everyone who's reported them here or in private messages, it's been really useful.

And, as you can see, I've been working on my marketing art.

I'm headed down to NYC tomorrow for a few days, but will still check in when I can, and be back in the new year.

With this update, I'm mostly feature complete for a 1.0 release. Things I plan to do before then:

- Fix any found bugs, of course, and do a full regression pass over the whole project (which takes a while!)
- Optimizations for the shader. I think I can squeeze a bit more performance out of it, especially on the more complex modes (tessellation, etc).
- Small "feature complete" things that bother me- like how does the macro texture effect tessellation. Right now it doesn't, but if you were using the new AlphaLayer mode, you might want that. Or should the mesh normals be taken into account when render baking a distance texture - right now they are not, but you likely want them included in some cases.
- Redo all my videos. Basically, a series of short and too the point videos showing you how to get started, as opposed to my devlogs, which are more train-of-thought.

Anyone think I'm missing anything critical?

 

Wait, what? I just submitted 0.95 like an hour or two ago, and it's live on the asset store!?

That's got to be a new record..

 

I have noticed that texture border effect mentioned above by StevenP94 also and noticed that if I kept painting I could generally make it disappear. I was just messing about at the time so don't know the steps. I was able to make it happened on the demo mesh landscape and a landscape I converted to a mesh which was actually just flat. On the flat landscape it seemed I could make it happen on a specific area of the mesh every time, whereas other areas seemed unaffected.

Looking forward to that update, looks great.

I need to get more time to spend on this so the below may already be the case.
You asked for ideas and I am not sure this is the case or not currently, but I stumbled upon another in development tool that showed the ability for an adjustable heightmap blending between textures which allowed for a nice blend of sand between cobblestone in the cracks rather than sand blended over the cobblestone.

Anyway, enjoy your break.

 

That's how it works right now, actually. Every splat map blend in MegaSplat is resolved that way, between the textures painted on each vertex, between multiple layers, between the macro texture and the splat maps when your using AlphaLayer mode. (Note, if you pull the contrast all the way to 0, then you're basically back to linear interpolation).

 

I also saw this once, but like you, it went away and never came back. I was in the midst of changing everything around, so assumed I had just broken something while refactoring. I'm wondering if I have a bug in my mesh converter, or some precision issue, that allows this to happen under some very specific circumstance.

 

@jbooth
Just updated to 95 and thought the artifacting was gone but one last check and I made it happen again.

Also, had a look around again and realised it was already doing the blending. Need to get stuck into this more before typing I think.

 

Can you send me that mesh/scene? Is that on my meshes or yours?

 

That is my flat mesh.. Yes. I will send it to you. Seems to be an issue near the join at the centre.

 

@jbooth I have sent an email with a shared link to the package of just this in a scene. For reference I am using 5.5.0p1.

 

Ah, so what's happened here is that you must have accidentally painted on the vertex colors. This is pretty easy to do since it's the vertex painter's default mode (it is a vertex painter, after all). This is one reason why I was considering removing a bunch of the vertex painting features and making a "safe" version for MegaSplat, because currently it's very easy to do something like paint on the color or flow map the wrong UV channels and mess something up. To fix this, just press the Colors button on the Clear Channel section of the vertex painter.

I should add a way to do this without clearing the alpha data, since it's going to remove your current paint job as well. But yeah, the colors on the vertices are used by MegaSplat to filter textures and prevent that "looping all over the texture array" effect you see, so if they get overwritten with something, then it breaks and starts doing that with the textures.

Glad it wasn't technically a bug, but it still seems like a reason to strip down the vertex painter to me. Too easy for people to get themselves in trouble when they first start using it and don't understand all the capabilities it has (or the fact that it starts in the wrong mode).

 

I'm not surprised, as I seem to recall just messing around with anything to see what would happen. Looks fine now.

 

@jbooth
I just had a quick play with the tessellation on a unity landscape (just a flat landscape). If I move around I am seeing the ground wobble up and down. This is the flat unity landscape in the package I sent.

 

The tessellation fades in the distance, as does the amount of tessellation - you can set these distances in the options; it will tesselate either based on camera distance or screen space edge length. If you have a completely flat plane going off into the horizon, this is going to be more noticeable than on an organic terrain.

 

You are probably right in what I am seeing. I did just play around with the settings and it did have some affect.
What is it basing the tessellation on? The upper lower texture or something else? It kind of looks like the mesh is wobbling at a very low density. Probably it is just something I am doing or not doing more likely.

I don't see this effect happening on the flat mesh terrain though but I don't seem to be able to get the material to stick on that one. Each time I run it the material resets to non-tess version. I can change it while it's running so I can look at it though.

 

There are two modes for controlling the tessellation, Distance- where the tessellation amount is based on distance from the camera, and Edge, where tessellation is based on the size of a triangle edge in screen space. You set the maximum amount of tessellation or maximum pixel size of an edge, and the triangles get subdivided to keep those levels as you move. This means the vertices are moving around constantly as you move, and if you don't set things well, appear to swim. The displacement is done by blending the height maps in much the same way as the texture resolve happens. You can use MipBias to use a blurrier version of the height map, which often looks more stable if you have small details in your height map (which often looks great for the regular blending). Shaping can be used to control the blending between a two layer shader; lower values tend to look better. Phong tessellation smooths the terrain before it's displaced. Up Bias allows you to blend between displacing along the normal, or displacing to an up vector. As you move away, the tessellation generally decreases (based on distance or edge length), removing vertices. To help cover this up, a non-linear fading of the displacement distance is used such that the displacement fades out by the max distance.

For tessellation, the quality of your height map data matters a lot. A simple greyscaled version of your texture is likely to look pretty bad - best to generate height maps and normals via casting, or procedural tools like substance painter.

 

Hi jbooth, thanks for the upgrade, it solves a lot of artifacts, but I still have problems painting on my meshes, can I send you my mesh to see what happens ? And would be great to have more controls on normal and specular/smooth map intensity and color in the 'macro map' section because it became the base texture when using alpha layer.
Btw using my mesh seems that only some specific areas can be painted, others not. Maybe I have some wrong normal/tangent ?

 

Hi~
Do parallax map can`t work with triplanar ?
This is my setting .

 

Sure, happy to have a look, but I'm leaving for NYC in about 3 hours, so it might have to wait for the new year..

 

Should just work regardless of UV mode.