Hybrid Renderer V2 can be enabled with ENABLE_HYBRID_RENDERER_V2 define
You need Unity 2020.1.0b3. This version is not yet released.
You need SRP 9.0.0-preview. This package is not yet released.
SRP: Alternatively you can checkout SRP repository manually. Use the master branch.
Please don’t try to enable Hybrid Renderer V2 with older packages or older Unity version. You will likely encounter visual issues (including no rendering at all) and heavy performance issues on some platforms.
I will be posting more info about Hybrid Renderer V2 when we have shipped the new SRP and Unity versions.
Conclusion: We recommend people to wait until Unity 2020.1.0b3 and SRP 9.0.0-preview package are available.
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?
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.
[quote=“SebastianAaltonen, post:8, topic: 780916, username:SebastianAaltonen”]
We have started investigating hybrid DXR, but I don’t yet have any concrete timeline I could share with you.
[/quote]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)
Dynamic code path will be SIGNIFICANTLY faster. There’s no static entities at all anymore. Hybrid Renderer V2 is using chunk.DidChange to only update changed component arrays from each chunk to GPU. If you don’t do query with write access to the chunks of your planet entities every frame, then no data is uploaded to GPU. There’s close to zero cost. If you only modify some data, such as LocalToWorld to rotate the planets, then only that component is uploaded to GPU, all other data is persistent.
Additionally, all of this work is now done in parallel Burst jobs. Main thread cost is very small now. We added a new API that exposes GPU memory directly to Burst jobs, allowing the update logic to write data directly to GPU accessible memory. This is a big CPU performance improvement, as we avoid two copies and two translation layers.
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.
. And yeah HDRP DX12 is really slow atm in general too so hoping to see improvements on this towards 2020.2.