[Released] [FREE] Vertex Painter 2.0, paint on mesh instances, splat map shaders, Flow maps, AO, etc

[hippocoder]

@jbooth1

So, there’s a bug in the Unity Shader compiler that hit MegaSplat a while back and broke parallax mapping in some cases. Basically, it looks like the compiler doesn’t realize your using the viewDir and writes it out in world space instead of tangent space. You might try putting a useless statement that the compiler can’t optimize out at the end of the shader and see if that helps:

#if _PARALLAX
o.Albedo *= saturate(i.viewDir + 10);
#endif

This is basically what MegaSplat does and it forces Unity to pass viewDir in the correct space.

MegaSplat works on meshes or Unity terrains…

Is Unity aware of it / is fixing it? seems pretty horrifying really.

[jbooth1]

@hippocoder

Is Unity aware of it / is fixing it? seems pretty horrifying really.

I have a repro project in with them, and spent a fair bit of time trying (unsuccessfully) to widdle down a simple case for them. I think they look at the 13,000 line shader it’s in and figure “Must be something else in there”. But if you actually look at the logic, it goes something like this:

1. Sample height from diffuse map
2. Use height to compute parallax UV w/ viewDir
3. Sample many other textures with parallax UV
   4.(hacky fix) use viewDir to (not) modify albedo to fix this issue…

What I suspect is happening is this:

viewDir is a magic keyword in Unity. When you assign something to o.Normal, it sends you viewDir in tangent space. When you don’t, it’s in world space. The reason is to save a matrix multiply in cases where you don’t need it in tangent space.

Complex shaders, like MegaSplat, and these, use lots of functions and structures to make the overall flow of the code easier to work with. Often, the assignment and use of these variables happens deep inside a function. Note that most of these don’t exist in the final code as they are mostly syntax sugar, and things like passing a structure to a function in HLSL will actually flatten the structure into a list of floats/etc.

So what I suspect is happening is something about these cases causes it to think I’m not assigning o.Normal, or that viewDir isn’t actually used by my code, and it assigns it the wrong value. The author of Lux has reported having to do similar things with the worldPos keyword (another magic variable), which seems to back up this theory.

[nbac]

even on a new empty project the example scenes do not work. no parallax height.
after adding those lines of code nothing changes. i do use 5.6.1f1. am i the only one having this issue?

[jbooth1]

@nbac

even on a new empty project the example scenes do not work. no parallax height.
after adding those lines of code nothing changes. i do use 5.6.1f1. am i the only one having this issue?

Does it have no effect, or the wrong effect? The bug I encountered in MegaSpat caused the effect to smear the texture in the wrong direction, not the effect to do nothing. Also, keep in mind, it’s parallax offset mapping, not parallax occlusion mapping, so the effect is subtle comparatively (though should be very noticeable).

[nbac]

i am aware of the fact it is just parallax offset mapping and it is not doing anything. so it is not wrong but non excistent.
i am using uber shader now with tesselation but this is pretty heavy performance wise (uber has no pom for two layerd shader). i really like the simplicity of using your shader and i really dont get why it is not working. i have tried a lot i use ngss asset and tought this could be the cause, so i went back to old shadow lib. i am back to standard unity and like i said an empty project.

[ilesonen]

Hi jbooth,
I just tested out the Vertex painter and it’s really amazing asset. Thank you! I’m currently working on off road driving game and the mesh deformation feature could work for creating soft ground effect for tires. Since I’m no coder would you have any examples how to make it work runtime, or is it possible?
(I accidentally posted this first to really old wip thread of Vertex paint…sorry about that;)

[Unplug]

you are awesome for sharing this

[Alcolepone]

seem to get a shader compile error with the latest unity. Related to the viewDir

"shader error in ‘VertexPainter/SplatBlend_2Layer’ : invaild subscript ‘viewDir’ at line 305 (on d3d11)…

any ideas how to fix?

[gurbrindersingh]

Can it be used for realtime painting on mobile devices?

[Sundert]

@wdw8903

Great, I also have a suggestion.
When the vertex painter window is opened, if I select an object in scene, the object will be added “vertex instance stream” script automatically. But I don’t want to add the script, static object has conflict with vertex instance stream, and the vertex painter is not active. I think the script should be added after I active the vertex painter.

have exactly the same problem Anyone fixed that? Will be greatful cause tool is great but that adding that component to every object is very unpredictable when working on huge scenes with many objects

[FargleBargle]

Is there a trick to exporting/importing painted meshes? I’ve got a terrain mesh that I spent a lot of time painting, and I want to move it to another project. I saved it as a prefab, selected the prefab’s dependencies, and exported it. When I imported it into a new project, all of the colors/textures were scrambled. If the vertex stream data isn’t getting included in the exported dependencies, where do I find it, and how do I transfer it?

[jbooth1]

@FargleBargle

Is there a trick to exporting/importing painted meshes? I’ve got a terrain mesh that I spent a lot of time painting, and I want to move it to another project. I saved it as a prefab, selected the prefab’s dependencies, and exported it. When I imported it into a new project, all of the colors/textures were scrambled. If the vertex stream data isn’t get included in the exported dependencies, where do I find it, and how do I transfer it?

It’s stored in the VertexInstanceStream component, though you could always save out the mesh with the utilities tab so it becomes part of the mesh itself.

[FargleBargle]

@jbooth1

…you could always save out the mesh with the utilities tab so it becomes part of the mesh itself.

OK. Here’s what I tried:

1. Selected the mesh terrain in Scene view, and used “Save Meshes” on the Utility tab to create a new mesh asset
2. Replaced the mesh component of the terrain with the newly saved asset
3. Saved the updated terrain as a prefab
4. Selected dependencies for the new prefab and exported it
5. Imported the terrain prefab into a new project, and placed it in a new scene

This is what I started with:

…and this is what I got:

This is the same as I got before saving the mesh out first. Any idea what I might be doing wrong here?

[jbooth1]

No idea- Unity’s package format is a mess, you might try just moving the files yourself. Once it’s in .asset format it can’t be an importer thing anymore…

[FargleBargle]

@jbooth1

No idea- Unity’s package format is a mess, you might try just moving the files yourself. Once it’s in .asset format it can’t be an importer thing anymore…

Hmmm… just tried that - copying the original FBX file, materials, textures, and prefab, along with their meta files, and got this:

It’s not as horrible as the first attempts, but if you compare it to the original, the textures are still messed up, like they were placed randomly instead of using a splat map.

I may have found a clue though - the original project was running in Unity 2018.2.5. The new project is using Unity 2019.3.0. When I created another test project using Unity 2018.2.5, the textures looked fine after either importing or copying the files. After saving the 2018.2.5 test project, I tried opening it with 2019.3.0, and the textures were again scrambled, as shown in the last picture, so it looks like something is being lost in translation from 2018 to 2019. So my question now is how can I get the files to transfer between Unity versions? Since I think you use the same or similar vertex painter in MegaSplat, has anyone else had issues upgrading assets to 2019.3.0?

[jbooth1]

@FargleBargle

Hmmm… just tried that - copying the original FBX file, materials, textures, and prefab, along with their meta files, and got this:

It’s not as horrible as the first attempts, but if you compare it to the original, the textures are still messed up, like they were placed randomly instead of using a splat map.

I may have found a clue though - the original project was running in Unity 2018.2.6. The new project is using Unity 2019.3.0. When I created another test project using Unity 2018.2.6, the textures looked fine after either importing or copying the files. After saving the 2018.2.6 test project, I tried opening it with 2019.3.0, and the textures were again scrambled, as shown in the last picture, so it looks like something is being lost in translation from 2018 to 2019. So my question now is how can I get the files to transfer between Unity versions? Since I think you use the same or similar vertex painter in MegaSplat, has anyone else had issues upgrading assets to 2019.3.0?

unity may have changed something about the fbx importer causing the vertex order or count to change. If so, saving the mesh out should allow it to transfer between versions.

[FargleBargle]

@jbooth1

unity may have changed something about the fbx importer causing the vertex order or count to change. If so, saving the mesh out should allow it to transfer between versions.

And yet it clearly doesn’t. Whatever has changed, saving out the mesh doesn’t seem to lock in the painted vertex streams. After trying various combinations of saving out the mesh, exporting, importing, and copying the resulting prefabs and other files, they all work fine in Unity 2018.2.5, and they all get scrambled as soon as I try them in 2019.3.0. If Unity changed the FBX importer, it looks like a breaking change for anyone with a previously painted mesh - unless I’m the only one this is happening to. It seems pretty consistent in all of my tests though.

[jbooth1]

@FargleBargle

And yet it clearly doesn’t. Whatever has changed, saving out the mesh doesn’t seem to lock in the painted vertex streams. After trying various combinations of saving out the mesh, exporting, importing, and copying the resulting prefabs and other files, they all work fine in Unity 2018.2.5, and they all get scrambled as soon as I try them in 2019.3.0. If Unity changed the FBX importer, it looks like a breaking change for anyone with a previously painted mesh - unless I’m the only one this is happening to. It seems pretty consistent in all of my tests though.

Well if you baked it out you’re not using the FBX importer. It may be that they changed the internal mesh format in some way, and revision existing meshes stored in assets to this new format.

[FargleBargle]

@jbooth1

Well if you baked it out you’re not using the FBX importer…

Ahhh, but I was. By simply replacing the original imported mesh component on my prefab with the saved out mesh asset, I was still apparently dependent on the original FBX file it was made from. After creating an empty game object, and manually adding the saved mesh filter, renderer, and material, the new prefab no longer had any FBX dependency, and could import cleanly into 2019.3.0. Thanks for the help.

[ZackTwisted]

Hello!
I’m having an issue with vertex painting and GPU Instancing. I have 3 planes painted in simply different ways:

The problem is when enabling GPU Instancing, they all have the same vertex paint information and they look like this:

I’d like to enable GPU instancing and be able to have different vertex data in each mesh, so I would be able to draw grass and dirty in different scenarios with the very same material.

How could I work a way around?

Thanks!