Open Brush Toolkit with URP
We're experimenting with it and it seems like, it won't work if we're using URP. Is that correct?
30 Replies
Well - it doesn't contain URP shaders. But depending on the brushes you used it might be possible to convert them.
Hello! Can we invite EricB#2490 ? He's the one mainly working on the OpenBrush Toolkit integration
@nericb
Ah Minsar. Pretty sure this has cropped up before. Have we already chatted?
Hi there ! 🙂
We might have, I'm not entirely sure though! But you might have seen stuff on social media about it, or tried the app... 😄
Hi!
I think we chatted about various export issues - something about vertex colors?
Oh yes! It was a couple weeks ago on your Discord server.
And basically it's more or less a follow-up of that conversation, in the sense that our intent is to properly support TiltBrush/OpenBrush creations in our app 😉
ok. so you'd need to support all brushes I guess.
Here's some notes I made when I looked into it: https://discord.com/channels/783806589991780412/804251629993197618/835089840943923211
And here's a branch with a really rough initial stab: https://github.com/IxxyXR/open-brush-toolkit/tree/urp
Oh nice!
although in that branch I didn't give any thought to properly supporting urp as well as the legacy renderer - I just went ahead and started converting shaders to see how much effort was involved.
I guess that will definitely be a great starting point, it'll be of great help!
There's also the experimental brushes to consider at some point.
Yeah I suspect that if people appreciate the new support of importing brushes, they'll want the newest ones as well
Although - there's less experimental brushes that need converting than it initially appears:
1. Some are broken and should be hidden for now (the 4 ParentBrush subclasses)
2. Some are duplicates of existing brushes updated to use the GeometryBrush superclass
and out of the rest - some use existing shaders so the work won't need to be done twice
It's handy to use this spreadsheet to get an overview of brushes/brushscripts > materials > shaders : https://docs.google.com/spreadsheets/d/12fHPnMNhpGGdR1mzFeCjXbg1Nv1PO1LZGcHwgp3S1Og/edit#gid=0
Google Docs
Open Brush: Brushes, Materials and Shaders
List
Brush Name,Audio Reactive?,Manifest,Material,Shader,Script(s),Export Name,Potential Fallback,Experimental Flag,Prefab,Priority
Bubbles,Default,Bubbles,Particle/Bubbles,GeniusParticlesBrush,Bubbles,-,GeniusParticle
Cel Vinyl,Default,CelVinyl,Special/CelVinyl,QuadStripBrushStretchUV,CelVinyl,...
I'd like to flesh out the docs a bit better on this as well
😮 didn't realize there were that many brushes
There's about 65 distinct shaders that matter - that's the only number that matters for converting to URP
and 9 of those account for most of the brushes
the rest are the funky one-off brush shaders
ok thanks a lot for this precious info! we've now gone back to the code and will let you know how it goes!
Cool. Happy to help some more. I'd like to see this happen.
Hello ! Im just working on a first URP Disco shader version.
my first approach is based on custom functions
it's maybe an easy way to port the surface based shader to URP ?!
Disco isn't a lit shader though?
it should be fairly easy
oh!
it is lit. weird.
i assumed it was additive or something
So - i haven't thought this through in depth - but for surface shaders I was going to start with a lit shader graph and add in some custom hlsl nodes.
or i guess you could start with something like https://gist.github.com/phi-lira/225cd7c5e8545be602dca4eb5ed111ba
but i think we eventually want to base this on shadergraph (don't we?)
But yeah - i maybe wouldn't have started with something like Disco 🙂
Oh, I see..
Indeed, having a common base for lit shaders is consistent approach. Using custom functions in the Shader Graph was just a first draft test :p
I think shadergraph will make life easier for other contributors in the future. And it's less likely to break with newer Unity versions
And most importantly - also supporting HDRP will be a lot easier
URP is particularly good for dealing with situations where you would like to reuse a few shaders with many variations in parameters. For instance, if you were working with the BIRP (built in render pipeline)...
then if you made many materials all using the same shader
for each material, there is an additional draw call
each material allows for a different set of parameters
and each draw call causes a bit of overhead.
the thing that URP brings to the table is a significant reduction to the overhead of each draw call associated with having many many materials that all use the same shader
URP shader parameters must be kept within a CBUFFER_START(UnityPerMaterial) block (like this)
this will allow it to make use of the batching optimizations
so, under URP you are going to have a ton of draw calls but the hit is far less
I should also mention that Post-Processing effects under URP must be done somewhat differently because Blit() will break in VR!!!!
I don't know if OB uses any post-processing effects, but you will have to look into Renderer Features
I've actually managed to make them work in both VR and in Pancake (I'm making a hybrid game in URP)
the process is a little bit involved but I won't infodump any further on URP-XR-SPI-PPFX unless prompted to.
there are things that have to be done both on the Renderer Feature side as well as the shader side
@nericb I just discovered this exists: https://github.com/kijai/tilt-brush-toolkit/releases/tag/v23.0.1-URP-alpha_v02
GitHub
Release tilt-brush-toolkit-URP-AltSpace-alpha_v02 · kijai/tilt-brus...
Electricity and Toon brush tweaks
Added Disco -brush
Fixed couple of brushes not using Vertex Color
Added more color adjustments to the Shader graph brushes, emission toggle
Tested compatibility w...
no idea who made it. the username doesn't match anyone here
👌 I will check that, thank you !