#archived-hdrp
1 messages Β· Page 32 of 1
looking at b1 release notes, I can't spot any possible thing that could have caused the change there (but they only list part of the changes)
only things that's broken on me on beta 1 has been new input system (namespace change from experimental to regular) and anything that uses ugui as that's a package now
i usually get this kind of unexplained errors every first beta of unity version i got it on 2019.1 and on 2018.1 too weird stuff but it usually works after that
well, you could put bug report on it with your own repro project
at least if it's broken in the next release too
Purpose of this PR
LOD transition have been broken after a C++ change in 2019.2. This PR fix the issue.
Fix fogbugzz https://fogbugz.unity3d.com/f/cases/1144730/
Release Notes
Please add any usefu...
that was broken for a good while
You can save lods named specifically in the same FBX and unity will sort it out if you want
so the max workflow there works fine
ah. that issue was about lod transitions
there was dithering fail on some lods
looking at the PR, they didn't do it on right range
i like lod poppin XD
wait until gpu lightmapper is out of preview
I just Do CPU.
One time I tried GPU, it just crashed Unity.
Kind of a let down since VFX graph for lwrp, it is.
dude i tried the GPU AND ITS FAST also it has a way better outcome on the indirect shadows.You guys know when it gonna be out of preview?
Next year
safe bet
But really, the idea of baking is shrinking quite rapidly. Partly precalculated realtime stuff is king going forward
How about for mobile games?
I heard they're PS2's on steroids... Unless it can do everything consoles nowadays can.
oh snap
I totally forgot about render graph
this most likely puts HDRP 2019.3 full release in danger
as it's yet another bigger refactoring for it
@turbid matrix
π€· News to me.... I just fuck with some of the scripts for my custom lighting.
@exotic plume
so a render graph is stating "here's the shape of the thing"
@turbid matrix thanks
Heya. Anyone know how to fix the error with Cinemachine in the latest HDRP (6.5.3) .
I get this error after installing Cinemachine:
Library\PackageCache\com.unity.cinemachine@2.3.3\Runtime\Behaviours\CinemachineStoryboard.cs(4,19): error CS0234: The type or namespace name 'UI' does not exist in the namespace 'UnityEngine' (are you missing an assembly reference?)
I know that Unity is aware of the issue : https://issuetracker.unity3d.com/issues/cinemachine-assembly-reference-missing-error-on-importing-cinemachine-package
Steps To Reproduce: 1. Create a project 2. Window > Package Manager > Cinemachine > Install Expected Result: Cinemachine pa...
But it seems like a simple error. related to the UI being extracted as a package. Anyone know how to fix the script?
I'm getting an error with the LWRP all of a sudden. I've been busy working on my GUI. This is the error Assertion failed on expression reinterpret_cast<size_t>(dstPtr) >= m_BufferSize
I figured it out. In my Unity "scene" view I was extremely far away from 0,0,0.
@exotic plume it's missing ref to ugui package
if you need to fix it now, copy cinemachine package from your project folder->library->package cache into your project folder->packages
then open the project and navigate the hierarchy window to that cinemachine folder, find the assembly definition file and add ugui package dependency for it
@exotic plume or just delete files n folders: Library\PackageCache\com.unity.cinemachine@2.3.3\Runtime\Behaviours - i delete file (CinemachineStoryboard)
and
in folder: Library\PackageCache\com.unity.cinemachine@2.3.3\Editor\Editors - i delete file(CinemachineStoryboardEditor)
doesn't it restore the missing files on next run?
it sure overwrites my code changes if I do them in package cache
Thanks @turbid matrix + @drifting vault . How exactly do you add ugui package dependency to the assembly def file?
@exotic plume Unity devs know about that problem. just wait when he fix it
see the assembly definition references there
just hit the plus on the bottom to add new one and then the circle one the new entry to browse for ugui package
anyway, like Vilaskis said, Unity will fix this, most likely on next cinemachine package
Hmm Ok I tried to apply the addition of Unity.ugui on the com.unity.cinemachine assembly file after moving the cinemachine package into the project and I get a Unauthorized access Exception - " UnauthorizedAccessException:Access to the path"C:\Users\mb525438\Desktop\NewHDRPTemplateProject_2019.2.0b1\Packages\com.unity.cinemachine@2.3.3\Runtime\com.unity.cinemachine.asmdef" is denied.System.IO.FileStream..ctor (System.String path, System.IO.FileMode mode, System.IO.FileAccess access, System.IO.FileShare share, System.Int32 bufferSize, System.Boolean anonymous, System.IO.FileOptions options) (at <23c160f925be47d7a4fd083a3a62c920>:0)
That should be an easy fix right @turbid matrix ? Do I just need to change read/write permissions of the assembly file with Unity closed?
@quasi mulch What do you mean by this? Outside of raytracing real time global illumination is still unfeasibly expensive for most cases
Ya.. changing permissions of the assembly file didnt work... Still get the same error... oooofff
neeeed Cinemachine..
I guess I will just trash the storyboard files then.
Good thing I dont really know how or why to use Cinemachines Storyboard feature yet
@exotic plume all packages are write only by default
Ya didnt work
there is newer version at staging but I dunno if it works either https://bintray.com/unity/unity-staging/com.unity.cinemachine/2.3.4-preview.7
eh. Ive mucked around with it for too long. I will just go with the deleted storyboard files until they update the package manager version
thanks tho
Hi guys, I'd like to know if you believe there's a way for me to achieve the same result as what I managed to do with the legacy Unity rendering pipeline with HDRP?
I'm basically using a custom hologram shader on all objects and a planar reflection that is blurred (PIDI Planar Reflection v2 plugin in the asset store).
I was thinking of using the builtin HDRP planar reflection system but how would I blur its result? Thanks
@somber shale just add bloom Post Processing to blur its result. You can def. achieve That look in HDRP
You can blur reflections in the material properties of the lit material shader iirc
thx guys
I upgraded a legacy rendering project to HDRP but I seem not to be able to get the "Create/HDRP Template Scene" menu to work: it start creating the scene on the project tab asking me to name it and then just disappears without any other message... ANy idea what could be wrong on my setup?
i would say to redownloading from package manager the hdrp 5.13 and then close the project ->reopen and try to create it then
hmmm, are the moving into different setup on github?
in past they've done latest development on master and only branched off when they need to branch out for past engine versions
7.x is for 2019.3
Well, that's what is happening. What do you mean ?
I mean, in past master was release/6.x, before 2019.2 and 2019.3 split happened, same thing before on 2019.1 and 2019.2 split
but I guess 7.0.x branch could be just wip branch toward first 7.x release?
this isn't any kind of issue either, just an observation
just been used to seeing all development for newest releases happening on master and dev for older unity versions getting a dedicated release/201x.x branch π
Well, it's kind of still like that. But I agree that it can get confusing and there's way to much branches π
yeah, I can only imagine what's it's like to keep up with them internally
seeing occasionally commits that missed the cut off to separate branch and they go circling on PRs then π
any ETA on 5.14? VFX and HDRP have been 5.14 on staging for 3 days sitting there now... :)
I could quite use the bug fixes therin
I can't give you any ETA for this, sorry π¦
Not that I'm not allowed to, I just can't
Thanks for letting me know anyway :)
I'm wondering though - is it true for me to assume that staging is so that you can sync a number of different but dependent packages to go to package manager at the same time?
@quasi mulch I always assumed it was intermediate step to test the package more widely before pushing it to regular registry
+1 for 0lento
only fraction of staging packages actually make it to regular registry
Testing and docs, yeah.
I see, so synching the releases is just something that's manually done
the fortunate side effect is that we get access to those as well
I hope it stays that way π
I'd be fine with some huge disclaimer on package manager if you've configured it for staging
Yeah just curious because I dish up so much guidence and general advice on forums and social media, so it's nice to know how the non NDA parts work so I can do that better
The first time I knew myself bout the staging registry is on the forums :).
To recap: staging is just a place to check to make sure that it won't explode
(it will explode anyway won't it?)
I wish I could write that in docs sometimes
βIf you do this, things explode. Donβt look at it. Cool people donβt look at explosions.β
The quill knows not sorrow nor love, only that it once kept a magpie's arse from sunburn
wonder what happened to speedtree support
I think LWRP got it on 5.14
but HDRP branch isn't even in the PRs yet
it's also based on quite old HDRP branch atm
truthfully the biggest annoyance is the procedural sky being quite rubbish, but it's temporary (still)
tbh, sky is kinda afterthought on most game engines
I guess people just expect devs to roll their own solution / use some static images
seems like something that's really a week's work (I did my own before in a day actually) is taking time.
it can't be an afterthought in HDRP though, as it's transformative visually, literally, night and day.
would be awesome to get some nice sky + cloud setup tho
I don't want or need clouds, rolled my own dynamic solution. but i do need something built in, dependable and correctly integrated with GI on unity's side.
I would code my own procedural sky shader but i'm not sure it's safe to do so yet
the feat I current wait for the most is the built-in virtual texturing
okay so both onprerender and onrenderimage don't work, is there any workaround for scripts that use them in LWRP?
those are what you get
beginFrameRendering Call that should be issued by an SRP when the SRP begins to render so that other systems can inject 'pre render' logic.
endCameraRendering Call that should be issued by an SRP after the SRP ends to render a Camera so that other systems can inject per camera render logic.
endFrameRendering Call that should be issued by an SRP when the SRP ends to render so that other systems can inject 'post render' logic.```
oh cool I like how that documentation is seperate from the LWRP documentation I used to see that onprerender and onrenderimage don't work :')
Thanks again man
you can check this posts links for the implementation https://forum.unity.com/threads/onprerender-onpostrender-counterpart-in-srp.535875/#post-4521358
it's bit messy as that script works on both nonSRP and SRP side but should be obvious otherwise
Thanks!
I uploaded this lwrp bug a few weeks ago. I never heard back via email but saw it as reproduced. Was curious if any updates? Link: https://issuetracker.unity3d.com/issues/lwrp-command-buffer-blit-executes-multiple-times-when-using-multi-pass-material
How to reproduce: 1. Open the project from OC 2. Open the scene WeatherMaker > Demo > Scenes > DemoScene 3. Press play. 4. ...
@stoic depot Yeah, the scattered nature of docs for SRP and LWRP is a huge frustration for me as well (I write the lwrp Manual). Believe me, itβs something weβre working on consolidating. In the meantime, Iβm happy we have champs like @turbid matrix to point people in the right directions.
I'm glad you all are working on it, the comparison between the built in render pipeline and the LW pipeline is certainly handy for finding out what's possible at a glance
Thanks!
From my current tests, it seems that HDRP planar reflection works only with lit shaders using the builtin metallic reflection support. Anyone knows how I could use it so it also takes unlit shaders?
You mean, see the reflections ON the unlit surfaces ?
No, I mean seeing unlit shaded objects in the planar reflection... It actually doesn't render them nor the UI elements (as they are using unlit shaders)
I'll ask some questions ... I just did a quick test right now, and what I see is the unlit in the reflection, but it's bare black.
Oh, I think I understood what's happening. @somber shale , can you confirm that like me you can see the shape of the unlit objects, but full black ?
@scarlet hull not trying to sidetrack the discussion but is there going to be anything done with the SSR flickering on editor with recent HDRP versions? it's especially noticeable if you got scene and game views both open at once, SSR effect keeps jumping between these views at super high frequency
it's so bad in the editor that I'm tempted to just turn the feat off in editor altogether
I think Seb commented this when I put a comment about this on github but I dunno if it's actually going to get addressed or if it's been verified on Unity's end
when you enter play mode in editor, it's perfectly stable, it just flickers if you aren't in play
We're in the procedure of checking the package for the next release. I'll try this and see if I can reproduce. If yes, maybe we can push a fix.
also if you keep scene and game views in same tab group (so you only see one view at a time) it seems more stable too
it's mainly when those both views are open in the editor at once and not running the game
forward/deferred/async stuff doesn't make any difference for this
Yeah, we always have/had issues with multiple views in the editor ... It because we reuse the buffers for all the views.
I have a pretty good guess where this is happening on code too
SSR broke in this PR https://github.com/Unity-Technologies/ScriptableRenderPipeline/pull/3385. I made a PR for fix but it got fixed in different place and after the Unity's fix, it's been flickering the way I mentioned
more specific place here on my already closed PR: https://github.com/Unity-Technologies/ScriptableRenderPipeline/pull/3420
Well ... I'm testing with the future HDRP 6.7.0 (release/6.7.x branch), and I can have SSR with Scene+Game view, without flickering ....
Oh, sorry, I'm working remotely and TeamViewer is causing some lag, so it couldn't see the flicker. Now I get it π
It's the SSR that seems to disapear for one frame when the focus changes from one window to an other ?
@scarlet hull I do confirm
@scarlet hull the Cube uses an Unlit Material with a builtin unlit shader.
I also tried to see how UI would behave adding a TMPpro Text element in a World Canvas but they aren't taken into the planar reflection pass (probably because they are still using "legacy" pre SRP shaders...? I guess)
@scarlet hull yes, it's really clear when you hover the mouse on the scene view
altho should have waited for 6.7 release and only then filed a bug report to get extra entry for the beta raffle π
I dunno if each report even adds extra entry, reading the rules implied so but I dunno if that's truly the case
So, the issue here with unlit objects not visible in the reflection, is similar to a bug already reported that emissive with high intensity doesn't look like emissive.
You probably have a scene with a "high" exposition value (default is 15), and the planar reflection buffer is stored in a 16bits float format, thus, those high values (also unlit) are clamped and appear underexposed
a solution would be to lower the exposition and light intensities in your scene.
Regarding SSR, I'm kind of just moving away from it in general. I think the use cases for it are better covered by planar probes, which can still perform really well if you tailor the layers to render plus the features it will use to render + res etc.
I've managed to get it to the point where I can't really tell if it's impacting my perf and it looks a lot better than SSR.
YMMV just weighing in with my more recent findings.
you have to have SSR in things like car bonnet view, there's no way around it
some games do dynamic capture for reflections for the bonnet / whatever view you have at lower refresh rate but it's pretty annoying IMO
you can clearly notice it
- there really isn't any capture component on Unity that would do this properly
so if you want this, you end up with really custom solution
dynamic reflection probe is alone is too expensive + it captures things that are not needed
so, in my experience, need for SSR / being able to get away with other techniques depends on your gameplay and camera positioning a lot
@scarlet hull can confirm that https://github.com/Unity-Technologies/ScriptableRenderPipeline/pull/3622 fixes the SSR flickering as well
could someone explain why "odd negative scaling" (like scaling the object with vector (1,1,-1)) breaks GPU instancing?
and how to bypass that
ok, I ended up making mirrored versions of meshes so they can be instanced - not the most elegant solution, but it works
@turbid matrix You're a crazy man. I didn't even had the chance to check that by myself.
it seemed related and didn't want to waste your time testing it if it's already fixed π
@scarlet hull thanks for the tweaks: it worked perfectly. Do you see any reason why you got the exposure set at 15 by default and the light to use so high lux values? I hope that it has been set to reflect "real life" lux values but I just want to make sure that setting now lower values to get the expected result, I'm not exposing myself to future caveats (I'm using 1 for exposure and 25 lux for my unique directional light)
and by the way, anything rendered in a UGUI canvas doesn't get reflected in the planar reflection, probably due to when the canvas renders its content right?
would you really want it to?
What reflect the UI set in world? I would yes for aesthetics
I specifically do not want that at all, hence asking
I mean, if the UI canvas is about game UI and not something that you'd expect to be in game world otherwise
example of thing I would never want to see reflected: player nametag on top of the player
You guessed it for the intensity and exposure value, it's to used physical light units (sunlight is measured at 100 000 lux in a blue sky).
@turbid matrix that makes sense, I'd still want to have the choice :p
hm. 100'000 lux on the sun in hdrp didnt work well 
@barren kindle I recommend that you start by going to Window->Analysis->HDRP wizard (or whatever it is named), then hit the fix all
after that create a new scene
it comes with all preset for 100k directional light and scene volumes setup to match this
I think it defaults fixed exposure to 14
I still wonder why that menu entry is under analysis at all
it's not analysis tool
I guess it exists there as the HDPR debug tool is there as well but it really isn't logical place to seek for this wizard
most logical place would be to put it in the Edit->Renderpipeline
as that's where rest of the similar entries are
it honestly feels like a mistake now
didnt fix anything :(
can you show screenshot of the new scene?
or you meant Remy's suggestion?
there's also two exposure controls right now
if you are on the 2019.x that is
yes 2019.2. where is that exposure thing?
even the template scene becomes white if i do 100000 lux on the sun
no I don't mean the template from Hub
I meant that after running the HDRP wizard, when you create just a new scene using Unity, it will default to preset values like that
it'll look like this
yes. and when i look up into the sky the world becomes black, and when i look down it becomes dim
new scene
there used to be a bug on prefab editor specifically
hey the sun is 100000 there π€
yes, sun is 100k, and exposure is 14 on that
yeah the editor viewport doesnt like anything, but looks ok in a camera
it's like that after you go into play mode and back?
yes
no idea then
no wait 
this one was off
everything looks beautiful now
thanks for the hdrp wizard thing @turbid matrix
How to reproduce: 1. Open the project from the cloud 2. Build and run Expected results: Both cubes are displayed Actual results: Onl...
Did you post this one ?
I posted issue report for it but turned out there was entry for it already
I think they have my repro project on that one tho
as I sent two cubes where other doesn't render
The dev looking at it is right behind me. Workaround : enable the readable flag on the cube's fbx
But it's a real bug and he's looking onto it.
ah π
that sounds really funky workaround
it's no big deal since 2019.2 is still in beta tho
I'm working toward 2019 LTS anyway π
also super happy to see that 2019.3 alphas are now out
as that's eventually that LTS (next year)
If you want the detailed stuff : the issue is related to the combo of the checkbox disabled, dynamic batching and SRP batcher enabled.
Dynamic batching batched together meshes with low polycount, but for some reason the imported cube will have no index buffer after that with the toggle disabled, and thus, the SRP batcher won't display it.
Or something like that.
just how I imagined it on my head ;D
just how I imagined it on my head ;D
(I didn't even notice that the default cube wasn't using HD Lit shader, thought it was related to my meshes)
to be real tho, I wondered why it was so selective to some meshes
I had HD Lit shader on many objects but it only chose to not render some
@scarlet hull for the sake of my understanding, the fact that the UI doesn't get captured by the planar reflection probe is expected and normal behavior (if UI is on a World Canvas that is)?
wonder if they draw the UI in later pass on purpose
I mean I could imagine they'd do that on purpose as it could be seen as a bug otherwise
there's a way to put your unlit materials render after PP too
I'd expect custom captures would have been done by that point
I use 100000 lux myself and it seems correct, but the problem with 100000 lux is you need to totally skew the procedural sky exposure and add volume exposure globally
and disable sun disc if proc sky is used (which is actually broken and as of yet not replaced)
(re lux questions above)
Looks like 5.15 will be the next release for HDRP (just a version bump to match other compatible packages from what I see)
the default new scene after running hdrp wizard does all these tweaks for you as well
including the proc sky tweaks you mentioned
oh? cool never knew that, got tired of waiting for all that and figured it out ages ago :P
I ranted about the hdrp wizards location a bit today π
:D
but after you run it, new scenes are ready to go
(I really hope they move the wizard to edit->renderpipeline from window->analysis as it's totally wrong place for it)
assuming the new scenes use the assets?
what you mean by using assets?
volume asset, hdrp asset
cos people can quite easily make a global volume and still not be any wiser why its all white...
HDRP asset is still what you put there yourself afaik
yeah so its just a volume tweak
so why not just set up sensible defaults (after all it does use defaults under the hood when you use no volume at all)....
you mean why you need to setup the components on volume for it?
I'd guess for compatibility reasons alone already
and it's not really "Post Processing Settings" any more since you can and do control the engine in there too with shadow ranges etc
well, technically they've only put PP settings under it :p
And the exposure there is pre-exposure not post effect exposure
you can have as many global volumes you have
ones that have biggest prio override the other volumes if you setup same component on two
just wanted to clarify because devil really is in the details for new comers
yeah, it'll be confusing for sure
but unity does call it Volume and not PP volume now so there's that i guess :)
but I think it's still good idea to show you can have multiple global volumes for different type of settings
I didn't know you could do that for example
absolutely - i do that myself
I always thought you could only have one global thing and rest are blended by bounds
I like how it's all set up but the API is annoying :)
as in actually just annoying to use - needlessly so, but the pain is not much
Unity's varied APIs become less consistent by the day and increase the amount of learning one must do to use Unity, and anyone without VS or rider is going to get lost fairly quickly.
Not only this, Unity actually breaks intellisense of all things in some places :D
yeah, it's definitely not as dummified setup now as it used to be
I personally don't mind current setup as it's kinda temporary state when you use new upcoming feats
too bad we can't use timemachine to get to 2025
one would think the most of the DOTS etc transition would have been done by then :p
but then again, they probably start next big thing iteration by then
gotta love game dev as industry π
always moving on
it'll never stop changing but there's good change and there's "wtf why" change
yeah, I've used the new Hub lately to know what you mean by the latter :p
When assigning GraphicsSettings.renderPipelineAsset during runtime I get really weird artifacts and rendering issues
Am I missing something here? Is changing the render pipeline asset even possible? I have a low, medium and high quality asset and I'd like to change it in my settings menu dynamically
it's possible, what SRP you use and what version?
LWRP 5.7.2, Unity 2019.1.2f1
there was recently a patch for HDRP to not strip other HDRP assets shader dependencies, in older versions it may strip out things that are still used as it used to check only the currently used HDRP asset for that
ah, I dunno how shader stripping goes on LWRP or if they have similar issue there
Ok. Thanks. It seems it's only affecting UI somehow. Everythign that is not on a canvas renders fine
but my UI gets completely ripped apart
I dunno if the SRP asset is best way to go about that though
you could use it for some preset defaults I suppose
but usually you'd still want to let the user customize the settings beyond few picks
or is this some mobile thing?
in which case I'd fully understand the presets
Yes. I wanted to keep it simple initially. I saw that the default LWRP starter project template creates 3 pipelines assets low, medium and high
so I thought I'd try that
It's Android mobile
it's designed to work, it sounds bugged if it breaks
I've even used it in past to swap between LWRP and HDRP at runtime altho that is not officially supported
swapping between different setups on same SRP should work
that's really how it's designed to work
@maiden plume I'd start by testing builds with each individual LWRP Asset, just to make sure it's the swapping that breaks it and not the settings on the asset itself that are not supported by your device
if it only breaks when dynamically loading different one, it's probably some issue on shader stripping
in which case best solution is to just file a bug report
Thanks @turbid matrix! I'll try that
+1 to @turbid matrixβs advice
Does anyone know why Graphics.Blit wouldn't work in the HDRP? I'm trying to run it with a shader but the destination render texture is ending up black.
Graphics.Blit(src, dst) does not work either, so I know it is not a shader issue. I can't find anything online that works for it so I'm starting to think it may be the HDRP
If this is in fact broken in the HDRP, does anyone know a different way to get the result of a shader into a texture? I am compositing two render textures into a third using a shader
What type of shader, Cg, hlsl, shadergraph?
Blit calls all passes if multiple exist,you may have to specify pass 0
@vague relic assuming its a ShaderGraph shader, HDRP has a lot of passes and the index may be different depending on the SG shader type. You can use int pass = material.FindPass("Forward"); to get the pass index to use with a Blit (also assuming you want the forward pass)
If it isnt a Shader Graph shader, the multi-pass rule still applies. HDRP also sets its own matrices, and there could be a rare chance that the default Unity matrices are not initialized (though HDRP does call context.SetupCameraProperties each frame for any active view, which under the hood sets Unity's default matrices)
@empty star I thought the same thing initially and tried specifying the forward pass, and I also tried just calling Graphics.Blit(srcTex, dstTex) without any shader. Both resulted in a black dstTex
Is there a way to manually setup the matrices before my call, so I can ensure it's not that?
I've also tried disabling depth on both textures, and I've ensured they're using the same color format and both have mips disabled
there is ScriptableRenderContext.SetupCameraProperties( camera, inStereo ) but that is usually called in the renderloop
@vague relic where is the blit happening, is it editor tool code, etc? if it is the matrices you could also set them through Shader.SetGlobalMatrix or similar before the blit (like any shader property)
the way to find out would be using the FrameDebugger or RenderDoc to see what properties are coming through with the blit and if any are zero
but it will be tricky to capture if its a one time blit
ill try a quick test also, curious what happens with HDRP
Blit is happening during playback. I initially was performing it using the HDRP's "beginFrameRendering" callback, but I have also tried blitting during the update loop.
Let me know what you find, I'm curious if it's my settings or the HDRP
@vague relic i was able to blit with HDRP, tested blitting a texture to rendertexture, blitting an Unlit HDRP shader graph, and same graph with _MainTex taking in the source of the blit https://pastebin.com/DjatxRDS
i think i know what is happening though
Blit probably sets up the matrices for writing into a render target
Why planar reflections look like that in Unity2019.2.0.b2 HDRP 6.5.3?
Just something like a mirror plane in center of planar releflection
BUT some planar relfections with same settings working fine...
@drifting vault I dunno if this would help you but they recently merged a PR with improvements on planar probes https://github.com/Unity-Technologies/ScriptableRenderPipeline/pull/3099
it's been merged to release/2019.2 branch but not to just released 6.7 HDRP
thanks! Tired to wait when they fix cinemachine and HDRP xD
afaik they got fixed cinemachine for 2019.2 betas on staging already
its dont work on 2019.2.b2
i tired to update project
same problem and no updates on package manager
@empty star Thanks for the tip, I'll take a look at that code and see if I can recreate in my project. I think you're correct about the render target issue
it looks like HDRP (shader graph) shaders will render to the upper right portion of the render target, due to those shaders using _ViewProjMatrix which is w hat HDRP maps the UNITY_MATRIX_VP macro to
UNITY_MATRIX_M is still mapped to unity_objectToWorld though
a solution is to use a custom blit quad mesh which is -1 to 1, i have test of it working but trying to make it backwards compatible with legacy shaders
you could also likely set _ViewProjMatrix (it causes the mesh to be invisible when I do it) but my matrix construction might be wrong
@vague relic i updated that pastebin code, it works now for HDRP and legacy, could probably be made into a static helper method https://pastebin.com/DjatxRDS
actually updated it again.. the UV was -1 to 1 instead of 0 to 1.. probably should make a gist
Thanks so much! I'll take a look and see if it works for my shader, I'll let you know if I make any corrections. Thanks for the quick help!
@empty star That has my source texture rendering into the dest texture, but it is only a small square in the middle of the dest texture with black all around.
It seems to be related to the aspect ratio of the main camera. Seems like one of the projection matrices may not be getting set correctly?
Oddly enough it seems like SetViewProjectionMatrices() isn't actually having any effect on the render
sooooooooooooo
im getting Library\PackageCache\com.unity.render-pipelines.lightweight@5.13.0\Runtime\LightweightRenderPipeline.cs(7,29): error CS0234: The type or namespace name 'PostProcessing' does not exist in the namespace 'UnityEngine.Rendering' (are you missing an assembly reference?) no matter what I do
I have installed various versions of the pipeline
I have updated the dependiences
I removed them and reinstalled them in a variety of order
I have tried removing and adding the post processing define.
I have deleted the PackageCache more times than I can count now. All with no avail
we have upgraded from Unity 2018.1.2 to Unity 2019.1.2 and these issues started happening
we were originally using the Scriptable Renderer directly in our project.
help please
π Fixed It
Apparently..... Unity gets very confused if you have a folder called Packages in the root of your folder and will fail to import any packages properly from the PackageCache
Packages is default folder. This is where you should have the manifest that lists all packages you use
yes its since regenerated the manifest
error CS0619: 'ShaderIncludePathAttribute' is obsolete: '[ShaderIncludePath] attribute is no longer supported. Your shader library must be under the Assets folder or in a package. To include shader headers directly from a package, use #include "Packages/<package name>/<path to your header file>"'
any ideas?
im not sure what this means. My library is in the assets folder
surely #include "Assets/<path to your header file>" ?

Hi all, sorry if this is the wrong channel. I am trying to get over the automatic Renderqueue managment. I have an Object which needs another Renderqueue value
i found 2 articles but didnt quite understand them π
is there anyone already tackled that ?
Is there anyway to get planar reflections in LWRP? Seems to be HDRP exclusive from what I have seen
Just grabbed it and got this error:
Assets\ScriptableRenderPasses\PlanarReflections\PlanarReflections.cs(6,42): error CS0234: The type or namespace name 'LWRP' does not exist in the namespace 'UnityEngine.Experimental.Rendering' (are you missing an assembly reference?)
LWRP is not anymore experimental
They probably didnt update that repo fully to new LWRP
You can find the line and change it to use UnityEngine.Rendering
@edgy harbor
There could be other API changes as well
It already uses Unity.Rendering, I removed the Experimental stuff. Seems the non-experimental LWRP doenst have "IAfterOpaquePass" anymore
always fix the first reported error first
things can have snowball effect
if the missing thing is in that namespace it can't find, it would explain the error
so fix the namespaces first from those files
so from that dialog, fix these two first:
only then wonder if there's something else wrong, @edgy harbor
did that. Now this is the new Errorlog
wonder if that last post is correctly assuming the current approach
I have no experience on LWRP myself so can't tell what has been changed for those passes
damn, seems to have vanished then. Thanks for the info!!
Hello,
does anyone has issue in LWRP for VR that cause not to render to GameWindow only to HMD? When I run the screen only renders screen space ui, but everyting else is blue. When I change at runtime anything on camera it starts rendering(I use forward renderer)
"fixed in 2019.3" https://issuetracker.unity3d.com/issues/hdrp-slash-lit-shader-is-not-render-in-standalone-build-when-srp-batcher-is-used
How to reproduce: 1. Open the project from the cloud 2. Build and run Expected results: Both cubes are displayed Actual results: Onl...
wonder if that means we need new engine version
or if it just means it's fixed on SRP master now
haven't noticed related commits/PR's on the SRP repo tho
thats weird. is hdrp terrain vegetation ... not a thing yet?
oh there it is but in square pink. i guess i cant place billboard grass at this moment
@small basin You need to run the automated shader upgrade process on your project after switching to a render pipeline.
Thanks but the shaders weren't the problem
We already had a scriptable render pipeline from 2018.1, just dragging what we did to 2019 kicking and screaming
Updated to 2019.2.0b2 / Using LWRP / OSX
Shader error in 'Lightweight Render Pipeline/Simple Lit': failed to open source file: 'SimpleLitInput.hlsl' at line 101 (on metal) +
Shader error in 'Lightweight Render Pipeline/Simple Lit': failed to open source file: 'SimpleLitForwardPass.hlsl' at line 102 (on metal)
And simillar for 'Lightweight Render Pipeline/Lit'
Any ideas?
@obtuse cave did you update LWRP?
Yes, through package manager. Running Version 6.5.3
VT for general purpose? is it graphine or other tech?
@quasi mulch it granite, yes and for lwrp for the time being
Is this cached, that is 4 layer HDRP materials can be cached at a given tile? seems very much logical that would be the case and a sad omission if not.
(ie not just for streaming gigs of unique data)
Solving both the terrain splat issue and also raising performance by reducing bandwidth for the general case
it's not specifically for terrain at all
(unless they change their implementation)
is it just me or does anyone else find HDRP very confusing to work with?
I've spent 2 days looking at it and I feel like I have no idea what's going on
my scene ends up looking a certain way and I have no idea why
@glad acorn itβs definitely different. Stick with it! The quality is worth the time investment
And feel free to ask specific questions about it here
yea havent given up yet, it just feels like there isn't an obvious learning path
not a lot of learning content on it yet
Well itβs high end stuff! Makes sense that itβs more complicated
Ya and still in preview
So not much training - most tutorial dudes run LWRP
yea, unfortunately all the content I've seen is basically just "do this, put this number in"
doesn't explain what any of it really does
Tutorial that helped me the most was from glasshand studio on YouTube
ooh let me have a look
Convert Your Old Unity Project From Built-In Render to High Definition Render Pipeline
this one?
brackeys, sykoo and unity channel are the ones I've seen
Yup
More so the second part was more insightful for me
This scene was created with assets from the Unity Asset Store! Support our channel: https://www.patreon.com/posts/project-file-for-22944188?utm_medium=social...
Particularly getting SSR working as itβs disabled by default
cool will give those a go thanks
when update of HDRP to 6.7 etc ?
I believe 6.7 is for unity 2019.2
6.x is for 2019.2 yes
but the question was rather when 6.7 update is available
it's right now on github releases and staging but not at regular registry for package manager
probably no one would be able to tell you. even 5.15 isn't up on packman yet
Wish hdrp would get more gc work too
Hello,
I am using LWRP and I want to create blur effect on semi transparent world space UI canvas. I have shader using Shader Graph that takes texture and blurs it. I wanted to use camera to render UI and take _CameraOpaqueTexture but it does not work with transparent objects. So my other approach was to use render texture to get UI, so I render Image from that UI camera, and than using Graphics.Blit apply blur.
I use this function
public void OnRenderImage (RenderTexture source, RenderTexture destination);
,but as far as I know that OnRenderImage does not exists in LW SRP. Anybody know how it can be achieved ?
Another thing I tried to do was, that I created custom GrabPass like in this
https://github.com/UnityTechnologies/LWRPScriptableRenderPass_ExampleLibrary
but unfortunately IAfterOpaquePass does not exist and still would not work with my only OpaquePass.
This may work for you: ```private void OnEnable()
{
RenderPipelineManager.beginCameraRendering += Render;
}
private void OnDisable()
{
RenderPipelineManager.beginCameraRendering -= Render;
}
private void Render(ScriptableRenderContext context, Camera cam)
{
cmd = CommandBufferPool.Get("CustomCMD");
//Specifics here
context.ExecuteCommandBuffer(cmd);
CommandBufferPool.Release(cmd);
}```
@uncut root I forgot to mention that I tried that, but in 2019.1.2f1 is beginCameraRendering protected so you can add delegates to them... But thanks π
Do not know. LWRP is chaos now... π
Does anyone know why in the HDRP when you set a renderer to not cast shadows, it still casts shadows on itself? At first I thought it was just AO but that is turned off
Scratch the above, apparently light layers are broken in the HDRP. Objects not on a light layer for a light are still factored in when calculating shadows from a light
Seems like just about anything lighting in the HDRP is broken. Do we know yet when the HDRP is coming out of preview? It seems almost unusable right now
2019.3 is the current target (for HDRP to get out of preview)
but there are quite big changes happening so I'd not trust that estimate blindly
last time I checked lightlayers, they worked fine on HDRP
but it must have been like on 6.5 or 6.6
@vague relic you've configured the light layer properly for both light source and meshes?
Yeah, I've confirmed both the renderer and light have the same light layer. The issue was the light still casting shadows from renderer's not on the same light layer, but this was fixed by forcing the old cullingMask to only contain the GameObject layer I was wanting to light up
Although that solution is hacky since the culling mask is no longer exposed in the light inspector
(Culling mask meaning the Pre-HDRP mask which used GameObject layers)
From what I can tell, it uses the "Light Layer" mask to tell what objects actually receive light, but it uses the old GameObject "Culling Mask" when calculating which objects cast a shadow
Which I'm assuming is a bug
@carmine ermine using recent LWRP you will want to extend from ScriptableRendererFeature and also a class extending from ScriptableRenderPass (these are both not internal), then create a Forward Renderer asset (Rendering -> Lightweight Render Pipeline -> Forward Renderer) on that asset, add your class that extents from ScriptableRendererFeature using the +
there are some examples here https://github.com/Unity-Technologies/LWRP-CustomRendererExamples/blob/master/Assets/Scripts/Runtime/RenderPasses/Blit.cs
your ScriptableRenderPass would be almost exactly like the BlitPass.cs except part of the command buffer can have cmd.SetGlobalTexture("_CameraOpaqueTexture ", yourRenderTextureHere );
@empty star Thanks, I will try
Itβs a manual process to get them from registry to packman, so might take a bit of time :)
well I checked, 6.7.1 packages show on new clean 2019.2 project π
it doesn't list 6.7.1 automatically as default entry for packages that have 6.5.3 marked as verified package tho
but it's there is you hit the dropdown arrow next to package name
Seems like it can't locate "com.unity.ugui", does that mean my version of Unity is not supported?
finnaly the new 6.7.1 fixes all my errors, also the new alpha 2019.3 with the new gui is working.Im too happy boiz
Thats great news!!
the only bad thing is that the lights gitter whenthey are far way and their resolution is super low ,ill try fixin it through the HDRP asset somehow
@ripe fable if you get that, it means 6.7.1 doesn't ref ugui on asmdef
while 6.7 is only now on package manager, it's been out for a while already
2019.2 betas and recent 2019.3 alpha require ugui to be referenced by package asmdefs
Unity will sort this out eventually
I'm using 2019.3 with HDRP from github master so I didn't even notice this (it's probably fixed there already
Ah, will have to dig into that then. I noticed the DXR options in the HDRP have been moved to the volume system lately, so I was hoping to test the experimental editor (with DXR flags) with a newer HDRP to see if it works. Was expecting it to break, just not on something like ugui
you need special DXR editor build + HDRP version to be able to use DXR
I don't have DXR capable gpu to test it but I doubt it's enabled in 2019.3 yet
first official HDPR preview with DXR support is supposed to release in the fall
of course there's still that experimental version available
also the quality of the shadow is bad and its due to the HDRP settins option that its graied out,it will be fixed in next releases for sure
you sure about that?
HDRP's deferred mode has had only "low" shadow filtering for a while
only forward mode has had extra filtering modes
no on version 5.13 it had low mid and high,i know unity ,they will fix it
you sure those also worked on deferred?
because afaik above low have never worked on it
they were listed at some point
but they didn't do anything extra
if that's the same thing we are talking about, there's nothing to fix
that's by design
but I agree it's odd that they don't support those filtering modes on deferred
@frigid nova check the part on shadows and filtering quality here: https://github.com/Unity-Technologies/ScriptableRenderPipeline/blob/5.13.0-preview/com.unity.render-pipelines.high-definition/Documentation~/HDRP-Asset.md:
Shadow quality only works for Cameras that use forward rendering. Deferred mode uses Low.
for sure in 5.13 it used to work
only if you used forward rendering
if you look at the doc page I linked, that IS from 5.13 docs
again, there used to be settings in older HDRP (I don't remember which ones had the option or not) but regardless the setting, it didn't really work afaik for anything but forward
people thought it was confusing (that you could select something that didn't do anything so they disabled the setting on deferred later on
anyway, I'm not here to debate about this, just pointing the reason behind it (plus linked relevant doc page and pasted quote from it).
does lwrp have ambient occlusion yet?
I can't seem to find a good answer online after some googling. Is there a way to keep performance reasonable with multiple cameras (and I'm not talking 2 cameras, I'm talking 16 or 40 ... ). I've tested with LWRP samples scene and the performance with 1 camera vs 16 drops from ~300fps to ~48 fps. The output resolution of each camera could be really low (this is for machine learning purposes so even 128x128, or lower will do)
@harsh spoke depending on the scene you have, you could play with all kinds of rendering settings per camera
like, if you always render the whole scene, you could try ditching occlusion culling etc
also since it's for machine learning, you could just render some simplified versions of the items you need, keep simple unlit materials there and render only things you really need with your cameras
So I don't think that materials or even mesh complexity add that much, it's more about extra draw calls as any inefficiency hers is multiplied by a big number. I did some tests and actually using a single material for all objects saves a lot of time. Maybe it's just not the way that renderers are optimized at the moment.
@harsh spoke the performant way to do it would be 1 camera which renders the 16-40.. views at once, either by feeding in an array of view projection matrices in a for loop (more draw calls but still faster than 16-40 separate render contexts) or instanced where the 16-40 views render into 16-40 slices of a render texture array and use the array of view projection matrices to determine where each view (in each slice) renders from
if it is all 1 shader it wouldnt be too hard to do, but it would still involve modifying LWRP, this is what the scriptable render pipeline is for though
if you dont need anything from LWRP, and the whole point of the rendering is just for the machine learning then it is probably even more straightforward to make your own simple pipeline suited for it
following one of these as reference for example, https://catlikecoding.com/unity/tutorials/scriptable-render-pipeline/
like if there are no lights involved, if it is all just depth-sensing then that would be real quick to setup
(compared to more complex lighting and shading needs)
it would use GPU instancing https://catlikecoding.com/unity/tutorials/rendering/part-19/
and use the SV_InstanceID to determine which SV_RenderTargetArrayIndex to write into (which 128x128 texture slice)
the general idea is similar to VR stereo instanced rendering, where objects that render are drawn instanced with the instance count at 2 (or multiplied by 2 if already a bunch of instances of a single mesh), then in the shader it can determine which slice by using modulo
@harsh spoke i did this before, this is an older package of a single pass multi view setup, https://www.dropbox.com/s/aq38kz6a02i3ppb/SinglePassMultiView_5.6.6f2.unitypackage?dl=0
it would perform faster using the render pipeline
A quick question: If I am currently using the lightweight RP and I wanna switch to HDRP, is it gonna cause a lot of pain in the ass or only a bit?
When I switched to LRP from defaul unity renderer, all the default materials stopped working and I had to replace them...
can you do any kind of indirect or procedural rendering in HDRP Shader Graph yet? I would just be writing HLSL if possible but every time I go to try to find some example code it seems like hundreds of lines of boilerplate that keeps changing
in lieu of that, I'm still really only aware of https://github.com/keijiro/TestbedHDRP as far as example custom HDRP shaders go, does anyone have links to some other example HDRP shaders? (the geometry shader examples there are great but anything using StructuredBuffer, DrawProcedural, or DrawMeshInstancedIndirect specifically would be a huge help)
@empty star Thank a lot! I was actually wondering if this is doable with some different camera 'model' and as you mention my initial thought was, that it works with single-pass VR, so maybe several views are doable as well.
I've experimented with rendertexture, but this doesn't really make a difference (or I've set-up it wrong, since I still used several cameras in the scene and used UI to display them in the main camera - probably not the most efficient way)
yea going through the UI would be a bit less efficient, maybe only slightly
@slim flicker Graphics.DrawProcedural() Graphics.DrawProceduralIndirect() Graphics.DrawMeshInstanced & DrawMeshIndirect should all be picked up by Unity's rendering system (they are not the immediate 'Now' calls).
So they can be called from any script, the draw calls (or whatever you want to call it) will end up in CullingResults which is used by the context.DrawRenderers() function.
As long as the material used has the same "LightMode" = "passNameHere" that HDRP (or LWRP) is filtering by, they will render
I haven't tried making an HDRP Lit shader that supports draw procedural, but if I was going to I'd start with the Unlit shader
the Unlit.shader includes ShaderPassForwardUnlit.hlsl & in ShaderPassForwardUnlit it includes VertMesh.hlsl which is the common vertex shader functionality used by HDRP. ShaderPassForwardUnlit also has the fragment shader in there.
I think by just making a modified ShaderPassForwardUnlit it would work, the actual instancing or procedural indirect stuff would be the same as done in legacy unity (except for the standard surface shader magic way which used procedural:setup)
if you used any of the direct draw methods (the ones with 'Now') those would be better suited for use in a command buffer, and within the HDRP (or any pipeline) since those do not go through unity's rendering system and would not be picked up by CullingResults or the context.DrawRenderers() function
that is the same as with the Legacy renderer too
it would be nice if it could work with shader graph as that is easier... but I think any vertex stuff (feeding into the Position slot) is actually just being shoved into ApplyMeshModification() inside the VertMesh method of the vertex shader, so by that point it would already have the vertex attribute struct setup, and by default SV_VertexID is not in that struct
so that limits the procedural indirect stuff with shader graph
in theory DrawMeshInstanced and DrawMeshInstancedIndirect should work with shader graph, since SV_InstanceID is defined in the vertex attributes, it would still need a custom HLSL node to pull the instance data from a structured buffer for the Indirect version
assuming that you can read SV_InstanceID from outside the custom code node... might not be supported in SG
i think i should pick up vr development again π€ what is the status of lwrp ambient occlusion?
@barren kindle
thats me yes :)
doesnt work with me. hold on let me check that package manager has the things up to date
but they have deactivated it in the official version mainly because they do not think it is needed, and that it slows down your visuals.
there is some other package from someone else that enables it
gimme a minute.
not a pacjkage really, just add-on
you mean this piece of crap? https://github.com/beinteractive/LWRPAmbientOcclusion
why do people say it works? it has been broken since lwrp 2
use this pull request. this works fine.
π
nice! i have never seen that before
someone mentions it in the comments. π
how do i download this? let me look
after you download it just paste it in your project's asset folder.
but i dont know how to download it
oh i need to use some git software to get this
oh nevermind i found it here https://github.com/PinkPanter/LWRPAmbientOcclusion
it works!
you were downloading the old version.
download from here:
https://github.com/beinteractive/LWRPAmbientOcclusion/tree/6bc42ce42d24ca0c917434782d89f6b9ab76475c
This is probably the last generation of Desktop VR headsets that matter, and despite the easy hype of Steam, index is not it. Since WMR and HoloLens came out, it is obvious that the future of XR is inside out tracking and autonomous (console like) devices. This has been the dream of gamers since before the Wii came out. (People back in 2005 had been hyped by a hoax know as Nintendo On which was posing as a VR headset) https://youtu.be/zX2smM87r14
Shortly before Nintendo officially unveiled the Wii/Revolution at E3 2005, Pablo Belmonte from Spain created this video and posted it on a message board, cal...
Does the LWRP support camera stacking yet in the latest beta?
Ok checked it, it isn't in the beta yet.
Im trying to try out Polybrush on 2019.1 with HDRP but I cant get paint working
any idea why
its a clean install
@sleek apex did you read the warning triangle?
your assigned material doesn't have shader that supports vertex colors
im not finding the shader that the tutorial says to use
tbh, last time I used polybrush, it only supported built-in renderer π
Package manager said Polybrush for HDRP
yeah, it should be supported
and if that's the view you get on HDRP, it's definitely rendering it
HDRP / LWRP support on polybrush is mainly about the shaders
of course I understand that
I also have the samples and shader graph installed
I will setup 2018.4 and test polybrush there
see if it works
have you used polybrush before?
one sec, almost installed latest HDRP to 2019.1 test project now
will check what it looks like
I have surforge but its hard to use
sorry procore was 2017 not 2016
all before Unity ruined it (joke)
well, looking at this, there isn't any vertex color input on the shader graph they provide on the sample
tbh, I still don't quite understand how this even works as they just input UV as mask
and TextureBlendWithVertexColor shader is broken with SG 5.16.1 as well π
half of the nodes are unconnected that should be connected
they probably made these for 4.x.x releases
in theory, SG's should upgrade gracefully but I guess they don't guarantee it from 4.x to 5.x as SG was still in preview for 4.x
I still like ASE better than ShaderGraph
me too
well, vertex painting definitely works after you have material that supports vertex colors
- make all assets in Assets folder to not be read-only (for some reason they put those flags on sample shaders)
- changed to shader with VertexColor
- connected few nodes back in that material that got unconnected and hit save on SG
if you want to use the triplanar texture blend, you have to use the last tab of the polybrush btw
it's not blending that by vertex color it appears, vertex color is just for tinting
(and requires a shader that supports that)
well, this isn't really that good tool for actual asset texturing
Substance tools are probably the best for that purpose atm
Substance Painter specifically if you only care about doing individual assets
I have to sell my first born to afford substance
the indie suite is quite hobbyist-priced <3
and how much do you want for your first born?
XD
how stable is the shader graph in unity 2018.3/2018.4?
this stable, shows with hands
it's still in preview on 2018.x
and it has lots of bugs even on 2019.1 where it got it's first official release
if i use lwrp and make a lit street scene (lamp posts). how do i do lighting without baking lights?
i have a maximum of one sun and 3 lamp posts. i dont know what to do
oh i see. a mesh renderer can only eat 4 lights (+ sun/directional). so if i split this piece of street into many many pieces, lights would illuminate it fine
oh no lwrp still doesnt have box projected reflection probes? :(
about time this to show up π https://github.com/Unity-Technologies/ScriptableRenderPipeline/pull/3750
I still don't get why they did it this way
feels like asking for trouble
instead of doing it like UE4 did and they just added speedtree nodes on the material graph so it could be used on any material type
Hello,
I am using LWRP for VR in our project. In my code I am switching SRP asset on runtime, in editor everything works fine. But as soon as I changed it on build it stucked in black screen. Anybody can help?
hey, is there any way of changing the targetTexture of a camera mid-frame? Like RT_A for opaque pass and then RT_B for the rest of the frame.
that's merged in master now
ooo
better than nothing but it does seem odd it was just left to rot forever?
it's probably 2 lines of code to fix too
I feel uncomfortable that speedtree needed to be part of the core SRP
well, at least SRP Batcher now works on 2019.3.0a4
also can confirm the sun disk works now with exposure 15
@quasi mulch only one line π
they just changed clamp to max
so yeah, it was broken for months, probably just wasn't a priority to find out the reason it broke
which I can fully understand, considering HDRP isn't even released yet
that happened first time for me.
Just stuck at upgrading one material
Release Notes
Adds an experimental version of the PBR Sky System.
Testing status
Katana Tests: https://katana.bf.unity3d.com/projects/com.unity.render-pipelines/builders?ScriptableRenderLoop_branc...
now upgraded to recent master
@tardy yew yea, that's something you can do with a scriptable renderpipeline (render opaque or other pass, change RT's, do more stuff, etc)
is it bad practice to change material properties frequently? as in through material.SetFloat, SetColor etc. and by 'frequently' i mean every frame for many objects
context is a shmup with potentially hundreds of simple enemies on screen at a time, and their coloration is proportional to their health, constantly updated through material.SetFloat
that sounds very specific to your gameplay, I'd say just profile it on your min spec etc
changing the properties is probably way more efficient than most options you'd have to get the same effect
you can also set some properties globally if it makes sense in your application
and there are material property blocks as well
but I dunno if latter really helps on perf at all, it's more of a convenience kinda thing
I'm not sure there is any HDRP terrain grass shader
but terrains foliage rendering is pretty subpar today anyway
people tend to use 3rd party instancing scripts instead
(but I'm no pro on terrain stuff, I don't use terrains myself)
@turbid matrix performance seems to be fine, it just feels like i'm doing something wrong because the first time you set a meshrenderers material property, unity instantiates a clone of the material just for that meshrenderer, and you end up with 1000's of materials in the resources that don't seem to get cleared when you stop the game π€
i got a list of all the mats https://hastebin.com/emusutocax.txt loads of hidden/preview
i've tried doing OnDestroy(){ Destroy(meshrenderer.material); } for every meshrenderer that updates its material properties
also tried Resources.UnloadUnusedAssets(); periodically, but neither seem to prevent this
but this is kind of a diff question now so don't feel obliged to answer lol
ah, I think I remember this topic now
there has been discussion about it in past
@half heart quick search gave this forum link https://forum.unity.com/threads/material-instantiation-and-cleanup.444807/ but I assume you've read it already
@half heart right way to do that is to use MaterialPropertyBlock
https://docs.unity3d.com/ScriptReference/Renderer.SetPropertyBlock.html
It's exactly what the Animator does when you animate properties there - instead of duplicating the material, it just adds a buffer with the changed properties. Very efficient
oh neat, i've heard of materialpropertyblocks but somehow thought they were for something else ty @lyric ravine @turbid matrix
know if they work with shadergraph though? https://thomasmountainborn.com/2016/05/25/materialpropertyblocks/ i'm following this guide and there's a step where you add [PerRendererData] attribute before a property which i don't think exists in shadergraph
They just work. Your tutorial there is from 2016...
So i am working on grass and water shaders right now and i was wondering how could i achieve these shaders, all of the tutorials on youtube are either coding the shader or using LWRP or HDRP, i want to use shader graph but dont want to have to install lightweight or high-def. Can anyone help?
@dawn sorrel already discussed on #π»βunity-talk
HDRP getting GTAO soon https://github.com/Unity-Technologies/ScriptableRenderPipeline/tree/HDRP/GTAO
huh
that's weird
I thought from chman's comments that they evaluated that and decided not to go with it
it's great to have options tho π
yea, that was a while ago. Forgot about it until I saw this on github
We spent lots of time with the optimizations here which AFAIK (I wasn't at Unity at the time) was the biggest problem found in previous investigations.
Current version performance are good and some of the cost will be amortized later on when we will share some part of the code with other passes.
ah, I thought the biggest issues on GTAO was that it wasn't very stable in motion
We do some temporal reprojection, in my test scenes ghosting was very hard to see and it is fairly stable overall. If looking at the raw output of the AO some temporal noise is visible, but when mixed with real scene content and TAA is barely noticeable.
@dreamy fox since you are around, I have one quick question to ask about the TAA PR that didn't get merged if you don't mind
this one
I read the conversation to know why it wasn't merged back then
but I'm curious, why move out of compute to regular shaders for TAA on that PR?
I did try to benchmark it on regular unity profiler and the noncompute one seemed tad faster even?
When running at full resolution (not really affordable for current gen consoles and lower end PC, but usable for PC), noise is not noticeable really. Some work will be needed in the future, but with a composited image it looks fine.
The reason for that move was because of the stencil usage
but that profiler isn't probably the best way to measure the perf, what tools do you use to measure these?
which is not usable with compute.
why not?
I mean, I added stencil to current compute TAA
I use it to not apply TAA on certain parts
You have to do it manually, compute passes don't do depth testing.
Re the performance profiling: I mostly profile on consoles that have excellent proprietary tools
ah, that'll not help me π
but I'm curious
did you see perf difference on the compute vs noncompute version yourself?
just wondering how feasible it is to have so much on compute side if it doesn't give immediate gains
I wasn't explicitly looking for it and a lot of time has passed, so sorry, but don't have info on that π
ah ok, just what I saw on profiler was that it was a LOT more efficient on my test project when I tried your PR version
but I suspect the figures I saw didn't take everything into account
hence asking what tools you guys use π
Gut feeling tells me it shouldn't change that much. Some small changes can be expected, but nothing too radical
You could try PIX for windows, it only works for d3d12, but it is a fairly good program
ah, I don't really use DX12 atm, but could try
my motivation to hack TAA is basically this: https://aws.amazon.com/blogs/gametech/anti-ghosting-with-temporal-anti-aliasing/
that LY approach is totally hacky too but it does work
current HDRP's TAA ghosts really badly on any noisy surface on default settings
so I just used stencil mask for the nearby and swapped the TAA to FXAA for the parts I knew would ghost, it works relatively well otherwise but the tricks done on TAA change the tone of the pixels too
so that gives some additional grief on blending
I currently have a hack that takes the intensity from TAA pass and adjusts the FXAA result with it, it could technically bring back some of the ghosting but it's fairly minimal
I am not overly familiar with the details of our TAA π I am not a big fan of the stencil trick as it is extremely content dependent and prone to issues.
yeah, it's super hacky alright
I mainly want TAA for the car and the background silhouettes as those are the things that are easy to spot if they have aliasing
and additional FXAA for things that got rejected from TAA isn't that expensive so I'm fine with that
there's no optimal AA solution available for things I need it for anyway
but yeah, I'm rambling
I do have one other question too π
did you work on the new motion blur?
yup
I haven't profiled it lately but when I did like month or two ago, it made a ton of garbage to collect
is that still an issue?
I dunno if I ever tried it on any actual release tho
probably should have
it's been on my long to-do list to verify if it's still an issue
I will leave a note on my desk to remember to look into it, if you gather any data before me, please send it across
I also added stencil pass for that too
it did put nasty artifacts on car on similar chase cam
like, the whole car mesh looked alive, despite it didn't move relationally on the screen much
Uhm that is definitively not expected
I can make a repro project if it helps
I have a fairly heavy backlog, but sure it'll help.
yeah, I've seen you have a lot on the table π
my stencil hack kinda works there but it still can get bit blurred near the cutoff
you can tag the object to not write velocity
I don't need any blur on the car itself but it would be nice for other cars
I need the velocity for TAA I think?
yes, but you said you stencil that out already? π
right
not being familiar for your content it was hard to guess it was noisy π
Anyhow, do you have a screenshot of the mb bug?
lets see if I can get one
Also what are the settings? Especially the intensity
I'll see if I get this test project open, it was made with older Unity version I don't have installed atm
When you have the time, a repro case would be much appreciated. I have a slight suspicion that it is an issue fairly symptomatic of the tile nature of the algorithm
I think I used relatively mild values
Also, if you want to debug stuff like that on your own, a good place to start is to inspect the velocity buffer through renderdoc or simila
how do I submit the repro project? like do I just file a bug and give you the issue id or do you want it shared some other way?
If you want you could file a bug, otherwise you can send it directly to me
but I think a bug is preferred π
I dunno if it's really a bug, but side effect how the PP effect works right now
ok, will do
I am betting it is, but a check wouldn't hurt, if there is something off I'll try to look into it
sure, and I'll tag you for the screenshot here once I get this running π
if it is not a bug is still ok to submit a report, it may just get closed as "By design"
can check the GC thing for the repro thing as well
I am seeing only one additional GC allocation when activating MB
hmmm, I may have messed up
thought I'd get better example of the motionblur artifact on build
but this is on master
so it probably builds like 1-2 hours for the initial shaders on this project
this is one of the biggest downsides if you play with custom HDRP versions right now
heh, this isn't going so great, getting instant crash on UnityMain when I launch the player
(latest 2019.3 alpha)
@turbid matrix fyi https://github.com/Unity-Technologies/ScriptableRenderPipeline/pull/3761
@dreamy fox tested that briefly, no allocs now on my end either
I couldn't make 2019.3.0a4 to build my test project for the other thing, I think I need to try something different for the repro thing, in editor the Motion Blur gets probably even more artifacts due to frame rate jumping and therefore same happens with the velocities
@dreamy fox here's a screenshot with extreme intensity of 3, same artifacts on the car appear even at intensity of 1, it's just more apperent here:
that's probably worsened by the jittering of the physics in the editor which itself is unsolvable problem (to get smooth physics in the editor) and I can't make this current test project build right now as it crashes on some rendertarget call which I have no idea where it comes from π
in ideal case, I'd use motion blur with intensity of 1 or 1.5 at max as that has the effect on ground that I'm after, I don't want that blurred image that I just posted
and for the ref, here's image with my hacky stencil mask to bypass the motion blur on the car body itself:
at same intensity of 3
it still bleeds on the edges a bit but it's actually fine at intensity of 1
wonder if one could do quick dilate on compute for that stencil to mask the area bit further from the object
there's a small catchup for the camera so the vehicle body isn't fixed in the center of the screen but it really doesn't move much per frame as camera still follows it actively
the artifacts you see from motion blur do appear even if the vehicle is moving at stable speed and camera isn't moving that much, but I'll see if I can get some preanimated and more repetitive repro thing for this as it helps me on my hacks as well
oh and these screenshots were taken with FXAA enabled, so there's zero TAA artifacts here
Just so you know, I did a test and we discovered some stuff happening with motion vectors when camera motion and object motion cancels each other : it doesn't always give a 0 motion vector value. This might be the root of the issue you have.
could be
that motion blur also has min velocity setting, I don't remember if I extensively tested with it as I could just put higher initial threshold
if everything else fails, I could just put higher threshold for things that got stencil pass π
the jittering is a real issue though, I can fix the physics side but my current framerate smoothing algo is quite fragile right now
Unity itself can't give stable and locked deltatimes even if you have with vsync enabled on PC
the timing jumps around the target all the time, it has this heartbeat effect
it would actually be beneficial if one could somehow get the gpu side timings to it but I dunno if Unity exposes what happens on the final rendering thread for this, or if it's even feasible to use those timings
megathread here if anyone interested: https://forum.unity.com/threads/time-deltatime-not-constant-vsync-camerafollow-and-jitter.430339/
I actually tested that recently and it's always been issue with Unity, tested it to happen even on Unity 3.5
and still happens on 2019.3
that's the variance you get on deltatime, instead of getting stable 16.67ms
I bring this up because it also messes up with the velocities on postprocessing effects that rely on motion vectors / velocity
for example, here's a clip from my early version of the mask I made for TAA (anything on red uses only FXAA on final frame and black is just the fade region
you can see the jitter on that while the velocity jumps around (mask grows up to half the screen depending how high velocity you have
I could get that jitter amount to about 1/3 of that using my own frame smoothing but it's still there
I just ended up not using that velocity as part of that equation as jittering made the border pretty visible despite it had blending
wird, why its happening when i bake light? 0_o
@drifting vault runtime error suggests you are missing some visual c++ runtime
you'd think Unity would install the required ones automatically if it needs them though
oh wait, it probably has it still, now that I read the error further
have you checked the logs?
@turbid matrix logs in separate file or console?
separate file
editor has it's own folder where it puts the log
on windows it's C:\Users\ <your user account> \AppData\Local\Unity\Editor\Editor.log
I dunno if PLM reports there, but worth checking still
@turbid matrix will check. After restart PC, I press bake light and unity just stuck...
Task Manager cant close unity
Need to restart PC
@turbid matrix if you can give us a repro case similar to your scene it would be great, in the meantime, just for the sake of me trying to understand the problem, when you can could you change in MotionBlur.compute, the define DEBUG_EXECUTION to ONLY_SLOW_PATH and take another screenshot/check if something changes?
@dreamy fox I'll try to get a new working repro project done in the following days π
it really has to build on standalone as that's where it has to work properly, I don't care if it glitches on the editor π
but yeah, I'll try the slow path too
#define DEBUG_EXECUTION ONLY_SLOW_PATH appears somewhat the same on my end
Ok, thank you for trying. I'll wait for the repro case to go full on in the investigation then π Hopefully we can find the issue.
also just to make it clear, the issue is definitely not that bad with sane motion blur values
basically the artifact you see on the tail lights is just like one pixel tall on intensity of 1.5
but it makes the things look more alive than it should
and of course the wheels themselves glitch with motion blur but that's totally expected
as you'd need some radial cage for them to get the motion blur to work fine on them
there was a setup from Unity for PPv1 that let you spoof the wheels motion vectors but it doesn't work on HDRP
I wonder tho
does that min velocity setting on motion blur really work right?
it blurs the whole vehicle at intensity of 3 even if I put min velocity to max (64)
I'd expect it to not apply the effect to places that don't exceed the min velocity, apparently it isn't so?
Could someone help me out with changing the offset of the LWRP unlit shader at runtime?
Apparently I need to use a "MaterialPropertyBlock" but all that contains is getters and setters for key value pairs that, presumably, the shader is made to understand
So I looked in the shader's code but it doesn't make any reference to an offset, so I can't find the key name for the offset
What am I missing?
@turbid matrix its crashing when i bake light with Real-TIme GI.
@calm musk that is the _QueueOffset property
did anyone notice that the font rending(alpha) is broken when using linear color space?
@empty star Do you happen to know what I might be doing wrong here?
block.SetVector( " _QueueOffset", new Vector2( 1.5f, 0 ) ); GetComponent<Renderer>().SetPropertyBlock( block );
@calm musk you have a space before _QueueOffset in the string and it is a float property (though setting it as SetInt would work too, it will be rounded either way)
unless you're wanting to set the slope factor and depth bias, that is different and handled by RasterStateMask in the render pipeline
Offset OffsetFactor , OffsetUnits can be controlled by https://docs.unity3d.com/ScriptReference/Rendering.RasterState.html
_QueueOffset is the render queue offset which also will shift renderers infront or behind other renderers (by render order)
Hi, totally noob question here, never worked with render pipelines before. Can customizing the render pipeline help me in any way with the performnce of a non-game app (no 2D or 3D models, just UI).
how do i get hdrp 7 into the package manager? π€
@daring whale Probably no, as currently UI is not controlled by the SRPs.
@barren kindle Not released yet.
But you can grab the master branch from git if you're brave enough : https://github.com/Unity-Technologies/ScriptableRenderPipeline
@scarlet hull if UI isn't controlled by the SRP, can't I somehow completely "disable" the SRP and hopefully get some improvements from there? Maybe I'm talking crazy, I don't know. But if I literally have nothing in my game "World", I'd like to be able to trim out anything that would handle it.
I don't really know what the SRP gives me control over, so maybe I'm talking nonsense.
SRP won't help you here, using the built-in renderer and simply having no camera and a UI in screen space overlay should then be enough for you (no camera to render, on pure UI)
I see. Thank you, I wanted to know if there's any performance I could gain by diving into the SRP before actually investing time in it. So I guess not in my case. Thank you π
@scarlet hull @barren kindle current master doesn't run on 2019.3.0a4, I hope new alpha will be out soon π
one can manually modify the master to run on a4 but I woulnd't suggest it unless you know what you are doing
at very least, one has to revert this change on a4: https://github.com/Unity-Technologies/ScriptableRenderPipeline/pull/3719
as HDCamera.viewCount isn't used in a4 yet
its fine. 2019.3 does not work at all for me because i need the unityengine.ui package and i dont have that package available :(
6.7.1 does run on 2019.3 atm tho
so you are not absolutely forced to use 7.x.x atm
I wouldn't be surprised if 5.16.1 ran on it too as there hasn't been that many changes
the missing package is ugui
it's same for 2019.2 betas
im gonna go back to 5.7 because i have some assets that doesnt go any higher 
you need newer packages that know how to ref ugui on their asmdefs
or just use 2019.1.... π€
btw, I did do new repro project for the motionblur yesterday but will still need to investigate the core issues
basically if you lock the camera to view the chased object at same relative position, the motion blur jitter doesn't happen but it still bleeds to the sides
so it's probably the small velocity differences that mess it up with smoothed camera follow
hmmm, 2019.1 BOTD's HDRP 5.11 branch https://github.com/Unity-Technologies/ScriptableRenderPipeline/commits/BookOfTheDead
wonder if they'll bump it to 5.16+ once they get it done
also was quite surprised so see all those custom callbacks, afaik they could have reused the newer callbacks for some effects
(but didn't examine thoroughly what they were used for)
Not sure if this is the best place to ask this, but I'm using the HDRP light component here, and I'm trying to change the intensity by code. I've tried the normal light.intensity, but it doesn't work. Any ideas?
You need to change the intensity in HDAdditionalLightData component.
You are amazing π . Thanks!
Can confirm, @scarlet hull is amazing ^^
https://github.com/Unity-Technologies/ScriptableRenderPipeline/commit/cabb88c80d8348885dbc036461b2d0ca3981fb28
[VirtualTexturing] Initial support for HDRP lit
I hope it doesn't take forever to get actual Unity versions that support this π
I'm hoping it would make it to 2019.3 and afraid it'll be on 2020.1 earliest :p
it probably still requires custom build / doesn't work on latest 2018.3.0a4?
Keep in mind that the default values are set to be aggressively fast on console level. If you target mostly PC, you can easily go above the defaults. I will write documentation as soon as possible.
It works on 2019.3.0a4
ah, I'll try it out then
I tried some earlier version but it was probably just wip so it didn't build properly
there is one other PR that messes up things on latest SRP master tho, so kinda hoping a5 will be out soon π
hmmmm, this completely replaces the previous AO implementation?
I thought it would have been a selectable thing
That was the decision taken, yes.
if it ends up being superior in all ways, I guess it makes sense
and yeah, I just tried the GTAO branch as is on 2019.3.0a4, it works
it's quite alive on stronger values right now, this is what you wanted to denoise?
That does look way more than I expected and I've seen in my test scenes.
I think I saw similar issues on Amplify Occlusion 2, which is GTAO based, they have these heavy temporal filterings to hide it
The denoising needs significant improvement
but that looks a bit over the top.
Is that game view or scene view?
ah, that was actually from scene view, I can try from game
it did seem to apply the effect same way on both
Also, try increasing sample count a bit, try to play a bit with the values.
the old version is really stable, it doesn't jitter at all
but I guess that's kinda side effect you get from GTAO sampling
yes, because is not distributing nothing temporally (the old)
You can disable the temporal contribution by going to GTAO.compute and setting TEMPORAL_ROTATION and ENABLE_TEMPORAL_OFFSET to 0
I think I will make that an option in UI
That will probably require a bit higher sample count as base, but is probably acceptable as we can skip reprojection.
step count doesn't really help on the jitter
it just makes it darker
(I'm now also looking at the game view)
(and with play in editor running)
The effectiveness of the temporal accumulation as of now is fairly content dependent. I know I need to go back to it, but part of the work will go to waste in a close future. I will add an option to skip via UI all the temporalness stuff
as written above, you can easily change that via code mod for now (If you notice, I tend to put a lot of option defines in my shaders π )
yeah, I've noticed, it's another thing to know what they do just by looking at the list π
To give more context, the reason why the noise is visible is because for now the temporal reprojection is heavily tuned to avoid ghosting while being more allowing to noise. That said, it is by far the weakest part and less curated bit and needs love.
The scenes tested here did not show as strong as a noise as the one you showed and since I already wanted to make the temporal part optional, I am now even more convinced to put it through.
disabling those temporal things from defines definitely made the jitter go away but this would need heavy denoising to look as good as the previous version π
that being said, I'd never put that strong AO intensity either
and now my editor crashed π
Depends how you define good here. The main differnece is that the old one capture better large scale stuff, while the new one is extremely better at capturing finer details
the reasoning being that your large scale occlusion is better off being baked anyway.
ah, I love the effect GTAO gives when it's stable
it's easy to see how it's closer to that ground truth it attempts to reach
would be still be nice to be able to jump between implementations if one works better for some cases and other for some other cases
Without the temporal accumulation in the current implementation you can get fairly good result anyway without having the temporal noise. The per-frame noise should be fairly smoothed out already, so you shouldn't see it.
my opinions on the temporal stuff is probably bit biased as I've fought these artifacts for years on unreal, they pretty much just rely on their TAA smoothing everything out there and it then brings it's own artifacts
using fairly small radius helps on the GTAO
around 0.7 works on the in-car view
Yes, the smaller the better. In any case, regarding the noise, I found that I ended up pushing some values that were a bit on the extreme when I was trying to remove ghosting. I will soon push something more sensible like in the original plan. If you want to try something more sensible for now, just go to GTAODenoise.compute and in line 223 change the lerp factors from 0.5 -> 0.85 and from 0.9 -> 0.95
that's with the temporal defines on 1 again
I can get it fairly stable on that view
but of course should try with more content
Keep in mind, being us still in preview, everything pushed is subjected to further improvements down the line. In this specific case, there are two things that are strongly missing and are important: documentation to guide parameter setting, and better denoising (although what is currently in the PR is just not what it was supposed to be, it's always risky to test stuff before it lands master π )
putting the feedback to lerp between 0.85-0.95 definitely makes it smoother
yeah, I know, not judging here π
That is the original desired range
just keen to try new things as always
oh of course π Just to set the expectations correctly! I for one am happy to get as much as early feedback as possible
will the better denoising mean more stable SSR as well?
We need to discuss that bit still.
my editor keeps crashing with this GTAO btw
I dunno if it's related
or coming from some other change on that SRP branch
I am not experiencing any and I've been working with it for a while, do you have an editor log?
looking at it now but there's no error / crash here
I just got my second crash when I mentioned that
it could be something else too
this project has a lot of experimental stuff
I'll check if it does that on the older master version without GTAO
I'll also bump the log verbosity level, it was set for script only
oh wait, that's the player setting, it'll not help here
hmmm, I wonder if it's because I messed with those compute shaders on the fly?
I haven't seen side effects from doing live shader modifications on Unity before tho
it's also not crashing now on anywhere π
gotta love these random issues
Hey all quick question - are directional lights still bad performance in HDRP? I was thinking of briefly using two during my day and night cycle.
I ask because with a classic deferred renderer, directional lights hit eveything and omit nothing but HDRP is tiled so I was wondering if it's the same rule.
@quasi mulch you need shadows for both?
because in HDRP only one directional light can cast shadows
(at once)
don't need shadows for both but it would actually be nice to decouple shadow direction from actual lighting so having a primary with that is fine
looking at this GTAO code: ```cs
float maxRadInPixels = settings.maximumRadiusInPixels.value * (runningRes.y / 540.0f);
float radInPixels = Mathf.Max(16, settings.maximumRadiusInPixels.value * ((runningRes.x * runningRes.y) / (540.0f * 960.0f)));
540 and 960 look like some magic values derived from 1920 and 1080 divided by 2
but you wouldn't always target 1080 nor have a setup that has similar divisor
I have no idea what that even contributes into so don't know if it matters either