#because why is render pipelines a thing

1 messages · Page 1 of 1 (latest)

timber phoenix
#

A largeish question

#

sure that its not a limitation
"SSGI" isn't any specific implementation, it's a description of what the effect does
HDRP's SSGI is most likely almost entirely different from a third party URP SSGI in implementation

inland violet
#

yeah ik, common thing is its gonna read from screen space like depth buffer

timber phoenix
#

Although the light calculation is likely nearly the same
These graphical effects tend to be described in whitepapers as math mostly, but the implementation across engines differers because each has their way of writing and reading the required buffers and whatnot

#

SSGI typically requires g-buffer, which BiRP already uses for its SSR
I don't know if those effects are something you're allowed to modify or reference
Could be that only HDRP and URP code are open source but not sure

#

My understanding is that you can modify BiRP rendering in almost any way if you have proper expertise
But that SRP's require a whole lot of less raw expertise because you can read and modify the code and they're designed to be modular as render pipelines

#

To get an idea how much expertise and effort it'd actually take to make a feature like that into BiRP you'll have to find someone who's done something like that

inland violet
timber phoenix
#

So, it can support pretty much anything you know how to implement
But if you need to ask it's likely out of scope for you, since you'd be doing it all from scratch with little to no documentation
SRPs have documentation meant to make this process easier, but their workflow is also unique to a degree that a lot of graphics programmers don't like it (or they are just taking time to adjust, and those who don't like change are louder about it)

inland violet
#

okay thanks for explanation, but i mean like actual simple example

#

like, how is doing x harder in birp than x in urp

#

also isn't birp much more documented than URP or hdrp? writing code instead of the beginner node stuff is already huge deal

timber phoenix
inland violet
#

i can see HDRP, because of its random vram memory access and compute, RGBA16F etc.

#

but urp ? why?

timber phoenix
inland violet
#

correct

timber phoenix
#

Unity certainly are making a lot of official resources and documentation for custom HDRP and URP features as well as writing custom SRPs
That's what they want to encourage

#

Writing shader code for URP and HDRP is harder because for better or worse they decided to make the node editor the default way of writing shaders
The intent is that the scriptable render pipeline can influence a lot of what shaders can and should do, which demands that the shaders adapt to changes somehow dynamically
To which the answer was nodes that can generate shader code in more than one way, so the shader graph produces a functioning shader even if the rendering reatures or the whole render pipeline changes

#

Which shader programmers who are used to writing code and being always in control weren't too happy about
But their happiness isn't a direct indication of the real advantages or disadvantages of the workflow

#

There's the upcoming Block Shaders workflow which serves the same purpose but with written shaders, as far as I understand
Still, doesn't change the technical principles behind why SRPs work the way they do

#

Means that seasoned graphics programmers tend to have their biases one way or another
Nonetheless they are who you need to interview if you want first hand experience

#

Scripting render pipelines or implementing totally new graphical features is beyond me so far
I just use them and try to understand them as well as possible