Open RunninglVlan opened 5 years ago
New comments added in post and question. Got it to work when using default values for LWRP asset
I'm not using LWRP, but I saw people on the forum stating the same issue and that it might be a bug.
https://forum.unity.com/threads/gl-lines-and-gl-functionality-with-lwrp.618985/
Also to note, GL is deprecated in SRP
Also to note, GL is deprecated in SRP
Where did you find that? I did a quick search and found no information about it.
I misread the original post, they're deprecating the rendering callbacks, not GL entirely. At https://forum.unity.com/threads/gl-lines-and-gl-functionality-with-lwrp.618985/#post-4191136
Yes, here's more info about it: https://forum.unity.com/threads/feedback-wanted-scriptable-render-pipelines.470095/page-8#post-3408481
After checking with SRP 7.1.1, it works. In order to get this package from the pacman, the editor needs to updated to 2019.3.x
Tested Unity v2019.3.0b5 with Universal Render Pipeline v7.1.2. Unfortunately it still doesn't work correctly.
This is how it renders in Game view if either HDR is set to true
, Anti Aliasing (MSAA) is set to anything but Disabled
or Renderer Feature is added to Renderer, currently there's only one - Render Objects (Experimental).
That can likely be resolved by changing the shader to something that respects depth because I'm pretty sure this was always a thing.
The more important part is that GL works with 7.x
You mean you recognize this as a bug in Render Pipeline and have some ideas on how it could be fixed? Maybe you could then contact them somehow =) Through some bug tracker, forums, emails, I don't know... We'd be happy if this would be fixed.
I don't think the z ordering issue is a bug with unity, its more likely that the shader simply ignores depth. I can't test any time soon but try setting the material to a default diffuse or anything that is known to respect z order.
But why it ignores it only in Game view and only with those specific setting values? I tested different materials, not one of them fixes the issue in Game view. Some of them brought rendering issue to Scene view. =D
Makes sense, are you able to tell if it's an issue inherent to GL?
I don't think it's related to GL, the problem appears only using RenderPipelineManager.endCameraRendering
. Without it everything renders OK as I described in question
Can GL still render if that callback is replaced when using SRP? If it does then submit it as a PR and I'll merge it.
Sorry, didn't quite understand you. What do you mean by "that callback is replaced when using SRP"? If GraphicsSettings.renderPipelineAsset
is empty and Camera.onPostRender
is used, everything works fine.
Hmmm, its rendering on top because of the endCameraRendering
which is equivalent to onPostRender
. Does beginCameraRendering
work? I can't really test any of this because I have school work to do, all I can do is speculate.
It's OK to speculate, I guess you have more experience in the subject matter.
But no, beginCameraRendering
doesn't help. Maybe this way it renders before everything else.
Latest status: Gizmos render correctly in Game view with following settings in UniversalRenderPipelineAsset:
and in Camera:
Tried changing Material on which SetPass
is called, as I thought maybe default shader Hidden/Internal-Colored
is not compatible with URP, but to no avail.
I asked about the issue in Unity forums, and Unity developer said that we need to implement our own ScriptableRenderPass. I understood how to create one, but then also the thing that I don't have a clue about CommandBuffers and such, i.e., I don't know how to implement feature pass. ScriptableRendererFeature can be created using Create/Rendering/Universal Render Pipeline/Renderer Feature. Unity has an example pass. Do you know anything about CommandBuffers? =)
I believe you have to create a new command buffer at the event and then pass it to the context to execute. Lastly you have to release the buffer (equivalent to dispose). Catlike has a page on custom srp with an example of command buffers.
Also that's quite a very specific set of requirements to make it work correctly eh.
Problem is the depth/stencil buffer target is not preserved somehow when AfterCameraRender is called producing everything executed at that stage to render on top. It should be fixed/improved so a simple Graphics.DrawMesh called in AffterCameraRender works as usual. That will be super useful and will make migration easier. Problem with Scriptable Features is that they require additional boiler plate and client-dependant setup which is a very bad design approach to solve a problem IMO. For many use cases, we just need to make direct draw calls after everything is rendered as before regardless of the pipeline!
Oddly enough, the result changes if Opaque Texture is enabled or disabled in LWRP asset settings.
This is not related to your package specifically, but maybe you know some info on how to fix it. Recently I added
RenderPipelineManager.endCameraRendering
to this package for rendering with Unity's Rendering Pipelines, but using this delegate Gizmos are incorrectly rendered in Game view. Here is a comment in Unity post and a question with details. Noone has made any comments yet =(