The Runtime Vertex Paint & Detection Plugin has been on the marketplace now for 4 years, and has during that time received an abundance of new features, optimizations and new examples in its sample project. 

 

However, there are still some large key features that have yet to be added and because I am recently out of a job I can no longer work on the plugin since I am forced to focus on things that can become a main income.

​This is why I am applying for a Mega Grant, so I can start to work on the plugin again, but full time this time rather than something I only do during my spare time. ​

​

I have been working on this plugin for 6 years and would very much like to wrap it up in a bow with these critical features that I know my users have been looking forward to. 

​​

​

Key Features left to Add:

​​​

• Nanite/Landscape Support using Virtual Textures and Render Targets. Theoretically this is very much doable (albeit more costly on both RAM and V-RAM) by being UV based instead of Vertex based. But by adding this we will not only support Nanite Meshes but also Landscapes, as well as just regular meshes as well where you may not want that many vertices or where the density is not even.
  This would evolve the plugin for Runtime Vertex, to Runtime Mesh Paint & Detection Plugin as it would no longer be bound to only vertices. 
   

• Add Support for up to 10 Surfaces per Vertex Channel. Currently a big limitation with Vertex Colors is the RGBA and that you can only have 4 different surfaces per Material. However, by utilizing physics surfaces and the plugins Editor Tools and Data Assets, the user could theoretically register several physics surfaces per channel and we can support having 40 different surfaces the user can paint, although still 4 on the very same spot. 
  
  So if for instance 3 surfaces is registered then 0-0.33 is reserved for the first, 0.33-0.66 the second and 0.66-1 for the last physics surface. Then when choosing a surface to paint, the plugin makes sure the channel stays within the boundaries of what is registered etc. The user would of course have to setup the material accordingly so whatever they want the channel to represent matches what is registered.  
  This would greatly increase the usability of the plugin by removing a fundamental limitation. 
   

• Task Batching since currently we start the first Task for a Mesh when immediately added, and others on the same Mesh gets added in a Queue and we work them off one by one. But would want to re-design it so we batch all Tasks added that frame, and start just 1 1 Task at the end of the frame that we run on async and resolve what color to apply taking all tasks into account. 
  This will fix issues where it doesn't feel responsive when multiple things are painting on one heavy mesh at the same time since each task may take a couple of frames. 
   

• Add Support for Min LOD to be anything but 0 since this may be a common use case when working with MetaHumans and older hardware that may never want to use LOD0. Currently the plugin is very much designed to always go through LOD0 first which may be a waste of resources if it is never used. 
   

• Paint at Location using Texture Brushes so users can make their own brush in a black and white texture and we can paint at location using that. 
   

• More examples in the sample project that showcases what you can do with the plugin, for instance a Mesh Hole Component that creates covers for the inside of skeletal meshes that you can cut and shoot holes through, and a Weight Distribution Component that can weigh down / lift up parts of the mesh you paint, for instance painting a part Wet can make it heavier there.