Official Hybrid Renderer V2 (0.4.0)

Lightmaps are listed as not supported in V1, but is there any plan to support them in V2? That is the major adoption blocker we have with the HybridRenderer at the moment.

 

I know that DX12 isn't supported yet (docs stated 2020.2 target for DX12), but I'm curious if DXR will be supported when the DX12 is functional on new hybrid renderer?

 

they have wip branch for hybrid lightmapping at least: https://github.com/Unity-Technologies/ScriptableRenderPipeline/tree/hybrid/lightmapping so would expect this to be supported soon.

 

Ah, I thought it wasn't functional at all but it must really be because I could only test it on b1 which doesn't have all the needed changes (DX12 just didn't render anything on converted meshes on my try where DX11 rendered like half of them). I'll wait for b3 . And yeah HDRP DX12 is really slow atm in general too so hoping to see improvements on this towards 2020.2.

I'm mainly concerned if more niche feats like DXR not getting the DOTS treatment, I'm happy to hear it's being investigated though

 

Sebastian, so nice to see that things are moving now on Hybrid Renderer -- desperately needed as right now it is the opposite of the DOTS-mantra "Performance by Default".

You also do a great job engaging with the community, keeping us informed (even about features not yet working, but good to know they are coming). Thank you, and hope you can keep it up!

 

I have a space simulator with no static entities at all. Also I have a planet surfaces, with 200-400 unique quads (33x33 vertices each). So the question is: will dynamic codepath be faster in HRv2?

 

Are you planning to create a CD that can be added to a Chunk or an Entity so they can be ignored by the hybrid renderer V2?
our use case: we want to add our own Culling System for our TOP-DOWN game style which can amazingly increase the hybred renderer performance for mobile devices. ( culling by regions before the Frustum Culling)

 

DisableRendering Tag component coming:

https://forum.unity.com/threads/toggling-rendering-for-an-entire-world.841291/

 

Thank you very much for clarification, this is fantastic news!

 

You are aware that simply READING the dynamic buffer of transform children will mark the chunk as changed, are you? I realize this is more of a question to the guys working on transforms in entities package, but you are going to heavily rely on DidChange...

 

@SebastianAaltonen did you every check the thread on 200k sprites...we used a similar approach with .DidChange and even double buffered those to upload only slices of the array to the gpu (i.e. if continues parts of the double buffered array change, they will be uploaded in one go, but this can also lead to many small slices to be uploaded) --- i never really benchmarked this properly... would be interesting to have someone from your end see if this adds further benefit or not (at the cost of memory)

 

I tested this now again on 2020.1.0b2 and it seems to work now. Are there still some changes missing from b2 that land on b3?

I briefly tested this on DX11, DX12 and in HDRP VR and all seem to render now. On 2020.1.0b1 I got like 50% of the materials rendered on DX11 and DX12 didn't do anything..

 

I'm still pretty sad about the (broken) performance, right now, and it would already be a huge help to know which unity version and renderer combination still gets the good frame rates. I tried to git bisect, but I can't find a working config anymore.

 

Worth noting is that you'll have way worse perf in the editor than what you'll have in actual build, at least when you use DOTS, HDRP and hybrid renderer.

My test project has like 50 fps on postcard sized game tab while running the game in editor where standalone IL2CPP build runs the same scene 260 fps @ 1440p. It's like night and day.

You might also get better editor perf by turning off jobs + burst debugging and safety feats, for me it bumped the test project from 50 fps to 80 fps in editor.

 

Nah, ever model I render eats 25+ milliseconds, which is close to 100x what it did before I updated to 2020.1 beta, from the alpha.

 

Also in 2020.1 they disabled debugging code generation by default, now it enables only when you attach debugger, and it bumps editor performance extremely, it’s now near to real build performance

 

That's really not the case on my brief testing. I get 80fps in release mode if I disable jobs debugger too. Otherwise it's 50fps in editor. In build it's that ~260fps. This could be result of my relatively simple test project though, I don't know how this would scale on bigger projects.

 

I’m speaking not about jobs debugger but Code Optimization setting.
https://docs.unity3d.com/2020.1/Documentation/Manual/ManagedCodeDebugging.html

 

Yes, we both talked about same thing (do note I mentioned release mode specifically). I just said that job debugger had also 30fps drop even if I were on that release mode on 2020.1.

In my project I get: 50 fps in editor play mode if I have either debug mode active (which you linked) OR job debugger active. Both turned off (so running on release mode) and I get 80 fps in editor. In build I get 260fps so there is a difference.

And should talk about ms specifically but that's beyond the point here as I didn't really run this on profiler to see what exactly cost and what.

 

Yeah disabling jobs debugger, safety checks etc also gives performance boost for editor. In case of our RTS it gives 70-80 in editor (previous was ~30) and in build it’s ~90.

 

2020.1 beta 3 is out lets hope HDRP 9 preview is out soon!

 

lets hope URP 9 preview is out soon too!

 

https://github.com/Unity-Technologies/ScriptableRenderPipeline/archive/v9.0.0-preview.0.zip

Doesn't work?

 

(or use github master)

I've been testing this on beta 3, I still think this was functional on beta 2 already as I don't see any difference between the two.

 

Does this new setup work with SubScenes? If I switch to V2 my SubScene loads in but I see no entities being rendered in the scene or game view. Am using b3 and the 9.0.0preview6. This is my first time adding the URP and SRP packages so not sure if there is in tweaking to my setup I am missing coming from the built in Renderer and V1

 

make sure you use only Lit and Unlit shaders. i had the same problem until i changed all materials shaders to lit.

all other shaders are not supported yet by the Hybred Renderer V2!

 

in my case it's slower when testing in the Editor and not working at all for android devices.

 

from https://docs.unity3d.com/Packages/com.unity.rendering.hybrid@0.4/manual/index.html:

"Hybrid Renderer V2 is compatible with following shader types: ShaderGraph, HDRP/Lit, HDRP/Unlit, URP/Lit, URP/Unlit. We will add support for more shader types in future releases."

meaning you can also use shader graph types to some extent.

It's not supposed to work well on mobiles yet. From same official doc page:

"IMPORTANT: Hybrid Renderer V2 is experimental in Unity 2020.1. We have validated it on Windows DX11, Vulkan and Mac Metal backends in both Editor and Standalone builds. Our aim is to validate DX12, mobile device and console platform support for 2020.2."

 

Is the plan for Hybrid Renderer to eventually become the main DOTS renderer, or does "hybrid" imply this is a stop-gap before a Pure Renderer of some type? I assume that we will eventually get support for pure DOTS lights and cameras etc? I'd like to have a rough idea of the timeline for that.

@SebastianAaltonen, just as a matter of curiosity, could you talk a little about which new features in the 2020.x betas are required for Hybrid Renderer V2 support?

I'm enjoying watching this develop, but haven't moved any of my actual projects over to it yet as I was just hitting too many basic stability problems with the 2020.x releases and had to go back to 2019.3. Don't worry, I reported the bugs.

 

How do I perform an entity operation on just non-culled entities with the new hybrid renderer?

 

Thanks! So hybrid GO/DOTS is the long term plan? We won't be getting pure DOTS cameras and lights? That's a little disappointing to be honest, I was hoping we would be getting Graphics APIs for directly rendering lights on a frame-by-frame basis. Does the engine rely too heavily on multi-frame state to make that practical or something?

 

Anyone seeing these odd CPU spikes...
Hybrid-0.4.0 with SRP-9-preview-0 from GitHub.
Scene is a single cube with ConvertToEntity on my MacBook Pro.

 

Where can I find HybridHDRPSamples mentioned in the change log?
I checked the package cache and SRP github.

 

With Hybrid Renderer V2 and the latest SRP and URP, is it possible to convert 2D lit sprites to Entities and have them be affected by 2D lighting? If it's not possible, is it possible to have 2D entities unaffected by lighting rendered behind a GO scene that is? (as background elements)

 

When are we going to get fully DOTS rendering? Atm having RenderMesh with a reference to a UnityEngine.Mesh is a big limitation to me.....

 

Not in the nearest future... Full pure Dots renderer is a big task and will take a few years of development. Right now they are focused mainly on hybrid workflow and renderer

 

Will RenderMesh be the only way to render something using HybridRenderer V2? The problem is that RenderMesh is a SharedComponentData and if you have only unique meshes in the game, you will have poor chunk utilization.

In my case every surface quad has unique Mesh but the same material and there are more than 400 of them in any given moment. I am rendering all that staff using Graphics.DrawMesh() and it takes almost 1ms on i7-9700k only for this api call for all quads.

 

When can we expect srp 9.0 to drop in unity?

 

im not an expert in rendering stuff, but the whole performance gain you will get from any Hybred Renderer is using ECS to organize rendering Data in a way that you can easly process it in parallel and safely. (Frustum Culling ...)
i think the best way in your case is maybe to do the Frustom culling in parallel jobs (dont try to process them by chunk but by entities for your case).
after collecting rendered Entities try to merge their Meshs using the new "Unity 2020.1" mesh API it will be easy for you cause you have a signle shared material for all of them.

[EDIT]
you can also create your own RenderMesh SCD which splits chunks by materiel or any other stuff (depends of your game) and store the mesh as CD for each entity using blobs.
try to take a look at the new Mesh API which ports Meshs as blittable data inside Bursted Jobs and merge them.
this way you can use Graphics.DrawMesh() to draw all of them in a single draw call.

Note: Generally Games try to reuse resources like meshs, Textures ... as maximum as possible for performance reasons so honestly i dont think Unity will focus on this case and make a whole logic for it. (not in the near future)
so the best way is to create your own logic reusing features from the current Hybred Renderer.

 

I am currently experiencing this issue with v1. Do you know if v2 handles this differently and fixes it that way? Many thanks in advance!

 

Thanks for suggestions. I am already making culling using burst and jobs and simply not generating stuff that camera is not seeing (I am generating Earth in real scale, that's why there are so many quads in the camera view). As for mesh merging - it is great idea, but unfortunately not for space simulators, where player usually moves very fast. But I will definitely look into HRv2 source code and see, what I can reuse for my case.