I would like to ask if it is possible to use the new Rendering Pipelines like LWRP or HDRP with PolyBrush.
Since PolyBrush requires the Polybrush specific Shaders like the Standard Blend Texture Shader, which just renders as pink with the new Pipelines and there seems to be no automatic upgrader.
And if not, when will it be available?
Nearly all new features of Unity require the Pipelines and I would hate to either miss the Visual Effects Graph or PolyBrush.
So I guess it will come out pretty soon, heard 1.0 is released with Unity 2018.3 and that is already in Beta b11.
Would love to test that before the release, if there is any need for testing or chance of doing so.
#5 and 6 - nope, sorry Terrain uses very different systems, we can’t overlap functionally. However- we would like to at least have a more consistent UI for each, so you don’t have to learn multiple interfaces for basically the same actions.
Everything else - technically, yes! You can use any shader you want. Polybrush doesn’t actually care , the tool just modifies channels like vertex colors, UV, etc. Then, your shader does stuff (like blending textures, heightmaps, etc) based on those channels info. Of course we’ll be including lots of example shaders, and info to create your own custom ones
Can you outline roughly what improvements come to brush (assuming it’s coming on package manager) please? In particular wondering about object scattering.
Sure! It’s mostly bug fixes and upgrades for SRP, with Object Scattering getting the largest “feature update” - that mode now includes randomization settings, palettes, and a handy “Loaded” space for tracking what items will be placed. Also enables painting with items from multiple palettes, and setting per-item randomization settings. Lots of good stuff, working to be on-par with the “QuickBrush” tool that was deprecated.
It probably should help us cull it somehow, perhaps a nice script. I feel that this will allow you to champion the tool as being something real, substantial you can use to just deeply populate scenes without the easily avoidable perf hit.
Currently we are avoiding the performance hit by doing the same method @hippocoder does where we get the list of scattered objects and then actually render them using the Graphics namespace, meaning we can avoid having so many game objects in the scene, but this could also greatly help stuff and mean we dont need to do this anymore!
Huh. This sounds neat, but it’s past my level of technical understanding (just the art guy, here ) If it’s not too much to ask, would you mind starting a new thread with a fairly detailed explanation of how your current workaround is setup, and what an ideal built-in solution would be? Thanks!
