VPaint: Advanced Vertex Painting [Released]

Hey Corey,
Thanks for your kind words

Here's a zip file containing VPaint/Transparent/Lit/Vertex Colors*Diffuse, and VPaint/Cutout/Lit/Vertex Colors*Diffuse. Let me know if there are other alpha shaders you need. The next update to VPaint will include the whole family of vertex colored transparent/cutout shaders.

https://dl.dropboxusercontent.com/u/12558999/VP/Alpha_VertexColorsDiffuseLit.zip

Make sure you place these in the VPaint/Shaders folder so ensure that they are properly accounted for when VPaint is updated.

 

*High Fives*

Ill test it out tonight after work. Glad to see that the 40 bucks also brings quick and easy service from the man himself.

It works perfectly........thank you so much again beck........youre the best

 

I'm considering purchasing this mostly for the Ambient Occlusion. How exactly does that work? I mean, it seems to use vertex colors. Does it use raycasting (i.e. colliders) or some other method that works on skinned meshes, meshes without collider, etc.? Also, how fast is the AO? I have some really big scenes (visualizations) and I'd like to bake the AO in Unity for a faster turn-over (I currently have to export/import to get AO from my 3D package into Unity). It doesn't have to be super-fast, but would it be fast enough to bake a couple hundred thousand vertices in under a few minutes?

Also, what is the directional object blending, exactly? It looks really cool, but I don't fully understand what it does.

 

Hi QuantumCD,
The AO baking does indeed use colliders and raycasts for its calculations. Currently VPaint does not support skinned meshes for vertex colors; objects must have a Mesh Renderer to perform VPaint operations. However, you do not need to have a collider attached to use VPaint operations - an internal mesh collider is automatically created when the object is instanced.
As for the turnover, I think it's reasonable to expect that a few hundred thousand verts would be able to bake in a few minutes. There are a lot of variables however; for example, VPaint will cull out unnecessary object comparisons, but if your radius is set too high then it will end up taking quite a long time. There is also a samples setting which you can lower if you are trying to do test bakes before you do a higher quality bake.

The directional blending is allows you to blend one object's vertex colors onto another. A great example is how we use it in our internal project: we have a large terrain with lots of objects on it, and the objects need the colors towards their intersection with the terrain to match the terrain itself. To speed up this process, we isolate the terrain and paint our base colors, then do a directional blend on all the other objects. This applies the terrain's colors onto the objects automatically, turning a 4-hour paint job into something more like 4 minutes.
Another example from our project: There is a mode where the user can place objects in the scene. Since the whole environment has vertex colors applied, the user-placed objects would look out of place if they didn't inherit the vertex colors of the terrain somewhat. We apply the directional blend on the object when the user places it, making it match with the terrain.
I think it could be used for quite a few different things, so I'm interested to hear of any other creative use cases for it.

 

Thanks for the reply. That directional blending sounds really cool. Does it work for the same object? That is, different colors on separate parts of a complex model blending with itself.

As for the AO, I have found some other implementations of AO in Unity that use raycasting, and they are terribly slow. Could you be a bit more specific, if possible? The best Unity implementation I have used thus far took over a two minutes for 15,000 vertices. That's way too slow to bake models with 250K+ vertices, unfortunately.

Also, would any of these features work at run-time? Or maybe you have plans for run-time support? I'm doing some visualization, as aforementioned, so being able to, say, blend objects after their colors are changed dynamically, would be awesome.

 

Oh!!! Nice.

I'm use a Procedural Planet Generator This means it will be possible to use your product for objects that I will place on the planet?

 

I agree, other AO implementations I've found that use raycasting that are terribly slow. I will boast that my AO implementation has a significant speed advantage over the others I've found, although I admit that I haven't done a stress test of that magnitude so I can't say for sure how long 250k+ would take.

EDIT: I can assure you that 15k vertices goes much faster than 2 minutes with my AO implementation!

No, the directional blending doesn't work for the same object. There are some features I have planned sometime in the future that might enable this, but for now it only work between objects.

As for runtime, AO baking currently doesn't have a runtime API (although it will in the next version). All of the other blending and adjustment methods do have a runtime API, including asynchronous versions.

@ZJP Yup! Does the procedural planet generator create vertex colors? If not, you'd have to generate them yourself and store them in a VPaint layer. Beyond that, that sounds like a great combination of tools

 

Yes. But, i place these objects in-game. It will work on?

Indeed.

Do you have a trial version? Or a light version. I'm interested for the "Directional Object Blending" only.

 

Wow, you are doing a really good job at selling your extension. I'll probably buy it soon, even if it's just for the runtime APIs, as they sound really powerful. As for stress testing your AO, I'm not expecting 250K vertices to bake in a few seconds using raycasting, but a few minutes at a reasonable sample rate would be good enough. I'm definitely going to make use of those run-time APIs though. Any rough estimate of how far along a run-time ambient occlusion API would be?

 

It's a rather simple change, and the only reason it isn't in the current version is because I wanted to push out the update to fix the prefab problems someone was having. However, just moving AO to the runtime API isn't enough to constitute an update, so it might be a few weeks before 1.4 is ready for submission.

@ZJP yeah, it should work out fine if you run into problems I'll be happy to help get you going with it.

 

So as long as I map the UV's the way the model is represented, it doesnt matter if some faces/triangles are smaller or askew for proper painting? As in, the texture will not be warped/blurry/resolutionChanged if the faces are not square, straight, or equal size? - With a flattened out UV mapping, but stays true to the shape of the model.

Example of what I mean:



I just wonder this because it's a vertex painting system, and that makes me think maybe it goes by distance between vertices.

Either way is no problem, but your answer will effect workflow choices. Thanks again!

 

Hey bpears,
So obviously in that case your UVs would be the same either way - your texture would never be distorted, as it relies on the UV map which has the same projection in both cases. The only difference you'd notice with the difference on topology is how the textures are blended. If you think of the model in edges, those edges are really the interpolation lines for the vertex colors. So in the 2nd example, the color you have assigned to the center vertex on the right would radiate outwards, whereas the first example would be distributed more evenly. This means you would have more uniform control over the vertices with the first example, and I think in most cases I'd recommend that approach.
Honestly I think the use case you've drawn out is a pretty good way to do an actual test as well - I would really suggest creating those two different models and testing out how the vertex colors are blended between each. It's a bit difficult to explain how it would change via text, but it would be immediately obvious how it's working once you start using each model.

 

Woops! I meant to put that the second one wouldnt be mapped, so its UVs for both square would just be squares. Forgot to add that... But from what your saying, as long as the surface is UV mapped flat, where possible, the texture flows as one across. Which is a relief! I will probably tinker with it as you said too just to see it happen.

I can't wait to play with this, I'm anxious as hell. lol
Texturing will be fun

Thanks for awesome product support Beck

EDIT: I keep asking you stuff, so I just went ahead and bought it. Won't use it for a while but hey, why not. Great product, great support.

 

Is there a way to bake down the Vpaint blend information to a mesh of lesser geometry, for say LOD models?

 

Hey bpears,
Yes, there's a tool in VPaint that would work great for that - radial blending. Radial blending transfers vertex colors from one mesh to another by finding the color average within a radius of each vertex. This means that you can transfer vertices from a high resolution mesh onto a low resolution mesh automatically. It can be found under the layers panel, under Adjustments -> Blending and select Radial Blending as the blend operation.

 

Sweet! I actually wasn't expecting a yes on that, but that makes my day! Would it even work for textures already applied normally? A mix of that and vpaint?

 

There are tools out there for transferring textures in the same way, but the radial blending in VPaint only works on vertex colors. Personally, I use the Transfer Maps tool in Maya for making LOD textures.

 

In open world games like far cry, they bake the AO into the landscape and objects over time, say 2ms worth of objects per frame until the local area is complete. It does this dynamically and I was wondering if it would be possible to code that behaviour ourselves with this system (ie just a few objects at a time at runtime).

 

That's a really interesting idea. A nice feature of VPaint is the ability to cordon a region to limit the calculations necessary for a given function, and I think using this you could do a super-quick AO sample in realtime. One problem is that it might be inconsistent due to differing degrees of tessellation. As I mentioned in an earlier post, the ambient occlusion feature is currently editor-only. However, the runtime API will be available in the next version, and I'll be sure to include the cordon functionality there.

 

The latest version of VPaint seems to fix all issues I had earlier. One problem I run into all the time is that VPaint keeps adding new layers over and over. It took me a while to figure out that the problem is that Shift+D for duplicating a VPaint layer collides with fast camera "strafe" to the right (Right mouse + Shift + D). Unfortunately, using that shortcut to move the camera is a reflex, I can not train it away while I use VPaint. Since the effects of hitting a VPaint shortcut is kinda hidden away, may I recommend shortcuts that cannot be pressed accidentally (e.g. Ctrl+Shift ones)? Even if the shortcut is ignored while the right mouse button is being held, I'm not too keen on Shift shortcuts in general since Shift+Letter if lacking Ctrl a non-standard for these kind of operations. Shift should normally act as a modifier to what happens if you press the same button without Shift (e.g. upper case, faster camera speed, or a different version of a Ctrl shorcut).

 

Hey Nifflas,
Thanks for bringing that to my attention, I hadn't realized there was a conflict there. Unfortunately the Unity API won't let editor extensions override traditional shortcuts for things like that (like CTRL+D, CTRL+V, etc.) so I'll have to get creative. If you have any suggestions let me know

 

Aww, I didn't know that. I think Alt is sometimes used for shortcuts, so how about Alt+Shift? Also, maybe a global option to disable the VPaint shortcuts? This could be useful if they collide with the shortcuts another asset uses.

 

That's what I use
Thought I'd ask though just to see. I'm very happy for the radial blend though, thanks for including that!

 

@bpears Glad to hear that!
@Nifflas I think Alt+Shift is a little awkward, I'd be more prone to using Ctrl+Shift+D. That might be bad for Mac users though. In any case, I'm working out a solution for the next update to customize the hotkeys yourself so that tool conflicts can be solved without VPaint being updated or modified.

 

Hey guys, we recently released another editor tool for Unity. It's called VConsole, a developer console for easily integrating commands and settings into your game. We use it religiously in our internal project for bypassing areas, tweaking settings on the fly, and doing per-platform initialization.

Check it out here! Web player demo coming soon.

 

Sorry if this has been asked before, but I didn't find the time to read through the entire thread.

Will your VPaint plugin also work with other 3rd party shaders? I am working a lot with Parallax Occlusion Mapping shaders like e.g. the one you find in the Advanced Surface Shaders and Relief Shader Pack etc. Could your plugin blend these shaders, too? Say for instance I'd have this:

- Parallax Shader 1 with a Stone texture
- Parallax Shader 2 with a Wood texture
- Parallax Shader 3 with a Sand texture

Could I assign these shaders to one of your VPaint shaders and then blend these 3 shaders?

Thanks!

 

@SeanM3D Unfortunately Unity doesn't support composite shaders, which means that a material can only be assigned one shader at a time. VPaint does support custom shaders, although the shader should use vertex colors in some way. To get your parallax shader working with VPaint you'd have to modify it to blend multiple textures together using vertex colors, and then apply the parallax effect.

 

I've passed this around to a few people privately, so I figured I may as well post it here. Here is the manual for VPaint (comes included with the package), in case you'd like a more in-depth view of what features are included.

Manual.pdf

 

Hi Beck,

Firstly, you are awesomely fast at replying to this thread -good for you man. Happy customers spend money! Which brings me to the one question pending me parting with $40 bucks...

I am using the Advanced Foliage Shader which is also on the unity store. You don't need to check it out -here's the gist: The shader uses the vertex colors on a foliage/plant/tree mesh to simulate the same kind of grass and plant animation used in Unreal and Crytek engines, so it looks pretty awesome (touch bending, leaf edge fluttering, etc). However, this needs the vertex info to be in the mesh.

After a day battling with the horrible vertex painting in 3dsMax, I realized there had to be a better tool for this -and I found your VPaint.

So my question is: After painting the vertices of my imported FBX the way I want, can the mesh be saved so that the vertex information and original mesh/uvs/etc are made into a single FBX file without needing to reference your script? To clarify, I want to preserve the vertex color info made with VPaint in the mesh and remove the VPaint component on the mesh, either by overwriting the FBX or saving a new FBX.

Is this possible? If not, I would have to purchase Blender instead, which doesn't have the cool AO features that your VPaint does.

 

Hi David,

Thanks for the interest in the tool.

Unfortunately VPaint does not yet support fbx exporting. I really want to include this (it definitely would be a huge workflow improver), but I'm still working on the FBX writer necessary to do so.

One solution to your problem might be to break the mesh instance. This will tell the object to reference a clone of the mesh, which will retain color data even after the VPaintObject is removed. This won't work when saving the mesh to a prefab as unfortunately instanced meshes will be destroyed if they don't live in the scene. Now that you've brought up this workflow, I'll write in a simple solution to save out instanced meshes as assets so that they can be referenced by prefabs. These files wouldn't be accessible by an external 3D tool but it would be something if you're just working in Unity.

I'll keep this thread posted on progress on the FBX exporter. I think it could introduce Unity as a workflow tool for models that aren't intended for use in Unity, especially VPaint since, as you mentioned, vertex color editors in modern 3D packages just aren't up to snuff.

 

Actually, the solution you mentioned would work just fine, saving a new unity.asset file would be just as good. Because the shader just needs to reference the mesh with vertex colors "baked-in", as it were. So just having the asset file would be fine -I don't need to take the FBXs out or do anything else with them. Simple solutions are the best anyway.

Anyway, if I needed to export the mesh after that, the ExportObj community wiki script could be modified to include vertex colors (if it doesn't already).

So... yeah, just a saved .asset file solution would be amazing.

 

About the asset saving... GameDraw is a very good, albeit buggy, plugin I also use that can save new .asset files from your edited instanced scene object(s). When you create a new prefab from the instanced edited object (and if it has changed from the original) it auto saves the new mesh(es) as asset files (with weirdly long sringed randomly generated names) in a new folder along with the prefab they belong to.

If it's possible to save the mesh with the vertex colors baked in, this would be an excellent place to investigate how they did it.

I edit, so something, change something, save buttons...
Here is the asset file it created...


Something like this would be awesome.

 

Hey David,

Just wrote up a quick solution for you for save out mesh instances, this should cover the last step in the workflow of what you're trying to do. Save this file in an Editor folder anywhere under Assets (for example, /Assets/Editor/MeshExporter.cs). To use, select "Assets/Export Mesh Instance" while you have a mesh filter selected. This will allow you to save a .asset file of the mesh object. I haven't tested this in VPaint but I'm pretty sure it should work without a hitch. I'll integrate this functionality in VPaint 1.4 to make it an easier process, including the ability to export multiple meshes at a time.

Mesh Exporter.cs (Gist)

Edit:
Just wanted to let you know about the ExportObj script, unfortunately the standard OBJ format doesn't support vertex colors Some programs implement it anyways, but because it's not standardized you'll have mixed success with it.

 

Awesome! Thanks very much, and I'll let you know how it works

(30 minutes later... Yes, it works perfectly! Thanks!)

 

Hello Beck,

just recently I've bought vPaint and I really like it. It speeds up my shader development alot.
One question regarding your TextureBlendx-series of shaders though: why are they using the Lambertian lighting model when you are assigning specularity and gloss values to the surface shader output structure? Shouldn't you switch the lighting model to BlinnPhong then?

 

Marco Sperling, you're absolutely right - not sure how that got missed! This will be fixed in the next update, thanks for pointing it out.

 

@David Lindsay: I found an error in the code I posted above where pressing cancel while trying to export a mesh could instance the mesh anyways but not save it. It's been solved, so make sure you copy over the new code from the same page.

 

Hey Beck. I was about to buy, but the Asset Store is non functional at the moment, So I thought I would take a moment to further clarify some points I am sure have been answered but just want it to be clear.

I really only want the tool for blending two or three textures(diff/norm) together on particular meshes. From what I have gathered, this can be done on prefabs, without losing the prefab, and while being entirely unique prefab to prefab? Maintaining instances, but having a unique set of vertex colours?

Cheers,
Steven.

 

Hey Steven,
Yup, you can have a prefab where each instance has separate vertex color data. It works just like any other prefab - if you hit apply on the instance, the color data will be applied to the prefab, overwriting any instances that haven't modified their color data but leaving the color data alone on modified instances.

 

That is amazingly awesome beck. Thanks

Steven.

 

Did anyone test vpaint with Mac? Is it working?

 

Is there any option to paint the model and have it directly impact the UV map? I'm looking for a tool that can paint the UV map as I paint the model so i don't have to paint on the UV map to get texture changes.

 

@axCed I'll know this info soon, however if anyone has a mac and could test VPaint on it I'd greatly appreciate it. I can't see any reason why it wouldn't work, but I would like to know for sure (as I'm sure axCed would as well).

@OutSpoken_Gaming I'm not sure if I understand what you're trying to do. Are you using the UV coordinates as non-texture-coordinate data? In any case, VPaint currently only supports painting onto vertex colors. If you're trying to apply two textures with two different UV sets, you'll need a shader which will use the two different sets for the texture samples and you can use vertex colors to blend those samples together.

 

I meant paint the current UV map on the model.

 

Hey Beck.
From the demo scene, just wondering how you made the heightmap blend shader? Is it just two (normally black and white) heightmaps, one tinted red, the other green?

Also, the erase feature behaves strangely, like say, if you paint in the green channel, then erase everything, and then paint in the red channel, the green channel is brought up with the red(happens with all the channels, this was just for an example).

It has taken me a little while, but I am starting to figure things out I think it would be helpful for future purchasers if you named the layers of the materials inside the demo scene.

I am quite excited about the potential your tool has to offer my art, now I just have to do the work

Cheers,
Steven.

 

On Mac, the RGB is working but the normal view is always black. We cannot see the textures.

 

@OutSpoken_Gaming still not getting it....

@axCed
I'm working towards testing on the mac but it will take some time, in the meantime could you give any additional information about what's happening?
If RGB mode is working but Normal is not, I would guess that it's a shader issue. Which shader is applied to the model you're trying to paint on? Does VPaint work when you apply a VertexColorUnlit shader? Could you verify that there aren't any shader errors when you import shaders? To test, right click on the shaders folder and select Reimport.
Edit: Just tested VPaint on a Macbook Air and didn't run into any broken functionality. Please let me know if you have any more info about what's happening and I'll be happy to help troubleshoot.

@Steven
Yeah, the heightmap part of that shader is just two heightmaps composited into one texture. The heightmap for texture2 is in the red channel, and the heightmap for texture3 is in the green channel. I did this to lower the texture samples so that the shader would work on SM2.

Hm, I see what you mean about the erase tool. This is a problem that I've been trying to fix for a while. In addition to RGBA values, layers also have a T channel for transparency. The erase tool effectively paints away the T channel, but leaves the color data intact. This is necessary so that you can have partially transparent values on layers, but problems come up when you try to paint another color on top a partially transparent vertex. The problem is generally not very noticeable but I'm looking for a solution and hopefully I can have one in the tool soon.

Glad to hear that it is working out for you though. If you end up with something you're proud to show off, I'd love to see it. This goes for everybody - feel free to post your VPaint-enabled work here for all to see

 

Ok. We tested compatibility with mac and pc and some shaders. What we found is that every shaders VPaint/Lit/Blend * Bumped Textures are not working properly. Without bump they are working, but we need the bump. This issue occurs only on mac and not on pc. With 5 textures, the default color for our mesh is black. With 4 textures, we have the option to change the base color and changing the base color does work.

Also, when we tested with an empty project, the Blend Bumped Textures was working properly. With our current game project, it does not.

 

Are you using forward or deferred rendering?
Does the Blend*2 Bumped shader work?
Could you post or PM me your graphics card info?

Thanks, I hope we can resolve this soon.

 

You're pretty sharp. Yes the blend 2 bumped textures shader does work, but 3 and higher does not.

Graphic card info : NVIDIA GeForece 320M 256MB (on Mac mini, Mac OS X Lion 10.7.5)