Official Hybrid Renderer V2 (0.4.0)

If you are converting the lights then there's a known issue with them being too bright after conversion.

 

I'm trying this now that 9.0.0 is in packages, but my IComponents do not bind to my shadergraph. Is there any way of debugging this without digging into the codebase? Also, where are the examples? They're supposed to be in the dots repo, but I can't find them?

 

Yep, float4 works fine, float4x4 doesn't work. Is this a known bug?

 

I ran into the same problem, why does HRV2 take up a huge amount of memory space on the first load?

 

The culling has enough complexity that it's hard to tell what the issue is, and rather then spend a lot of time debugging I'm just creating a render system to test against that doesn't use ECS for the core.

Culling/LOD is I think many times slower then it could be.

Best guess is that maybe chunks are amplifying the number of iterations involved? Could be something else but it's not obvious what it is. It's not the frustum plane checks because the difference in per instance vs chunk isn't significant enough for it to be.

My implementation is a WIP but my take is you want to maintain separate data for what BRG wants. Pay the cost of a transformation step when you have structural changes. This lets you create a data format where you can do the least amount of iteration and also consolidate visibility/lod logic.

I started by measuring the baseline cost of setting visible indices in the culling job. No additional logic just what is the bare cost. That made it obvious that just setting the indices wasn't a major cost factor. It also pointed to hybrid renderer not scaling linearly here.

So what I ended up with is structural changes trigger writing out a new format. And a pre culling job uses that format to calculate visibility/lod and write out per batch visibility data. And the culling job itself has no visibility log at all really.

Caveat being it's not done, and I'm iterating a lot using a mock culling job as it's so easy to crash unity here. I haven't touched instanced props which I will need to eventually. But I think the larger approach is likely to hold up. I'm seeing more then 10x performance gains over hybrid renderer.

All that said with how BRG currently works there are limits to cpu culling beyond the obvious. LOD has a huge impact. I think BRG could be tweaked some to help. With spatial reasoning for example I could make my visibility/lod job scale a long ways. But BRG would need support for setting visible by some type of offset/count api I think to get there.

 

Hit a bug with LOD when moving entities around a lot. They start popping in and out at the wrong distance. Like move closer they disappear. Usually it's a range like closer then X but further then Y and they don't render, where X and Y are both well within the LOD range. Panning in and out of view doesn't do anything trigger seems to be only distance from camera. Pattern is I'm moving them in and out of camera clipping plane range, to -10k on the y axis. Moving stuff around within the clipping planes doesn't seem to trigger the bug.

Disable LOD and it works fine. I'm using prefabs that just have LOD0 with 1% culled.

 

Does v2 support sprite renderer? Or is there ETA for this feature?

 

So I came up with an approach to handle very large scale while sticking with the HR. I do have one area where performance is less then I would like.

I first create a spatial map of everything on the map. Then I create a pool of entities in HR. Enough to always render what is close before billboard kick in. This can still get pretty big because LOD's magnify it.

When the camera moves enough I do a spatial query and then assign all in range to the renderers. Unassigned renderers get moved out of clipping range. That part is very fast I use some optimized structures there.

The transform system is the main hit. It's constant since it scales with the pool size. But it's still 2ms+ per frame. So I was thinking if I could maybe get rid of the hierarchy after instantiation. The LODGroupComponent is that needed after instantiation? I'd like to just end up with LocalToWorld on the individual renderers and then I could just move them directly without any transforming or hierarchy involved.

 

I am not getting any ambient light on the Hybrid Rendered Object (left)




Shader is URP/Lit
Core RP Library: Version 9.0.0-preview.13
Hybrid Renderer: Version 0.4.2-preview.16
Universal RP: Version 9.0.0-preview.14
Shader Graph: Version 9.0.0-preview.14

 

In HDRP, PBR Graphs are rendering at origin.
HDRP/Lit Graphs are fine tho.

 

DisableRendering has a bug where if you add and then remove it, it still renders. Sometimes. Thinking maybe it's also related to if the entity has moved, kind of like the LOD bug.

 

I updated to v 0.5.0 and my procedurally generated entities are again black.. i looked into
MeshRendererConversion, but i cannot see any difference.. Also an object which is converted via ConvertToEntity.cs script is also pitch black

 

I have this on OSX but not PC Standalones. Only solution I found was an empty loader scene that then transitioned to the first entity scene on start. Subscenes also seem to help. Performance on OSX with Metal is still far worse than V1

 

In case the entities have parents, try overwriting it.

Code (CSharp):

1. var par = GetComponentDataFromEntity<Parent>();
2.  
3. for (int i = 0; i < NumberOfEntities; i++)
4. {
5. m_CommandBuffer.SetComponent(queryEntities[i], par[queryEntities[i]]);
6. }

I have a hunch some changes in Entities 0.10 is the culprit. I had the same issue for some of the entities, and not for other. Noticed all my black entities had "LocalToWorld" and "WorldRenderBounds" all zero. And "PreviousParent" was "not available", whereas in Entities 0.9.1 it was set to something.

There is a difference: WorldToLocal changed to WorldToLocal_Tag.

Performance wise I am a bit disappointed with update to Entities 0.10 and Hybrid Renderer 0.5.0: it dropped in a build by ~12% (340 fps to 300). Not yet sure where the hit comes from.

 

Yep that was it! Added WorldToLocal_Tag and now it works again

 

Since updating to 0.5.0 material colors look different and they are not the same in Scene View and Play Mode.

I have a brownish simple material that looks like 'Capture.jpg' before Play Mode and like 'Capture2.jpg' after pressing Play.

Nothing changed in my lighting settings or materials since upgrading from 0.4.2. Rolling back to 0.4.2 and the issue is not visible anymore.

I am using URP 9.0.0-preview.14. What changed and how can I use the new version without this problem (is there something I have to modify)?

 

Is there any reason why you guys didn't just add a changed filter to the UpdateLodRequirementsJob query? It's not ideal but seems to work for most cases, haven't hit something where it doesn't work for us yet. And that job is seriously expensive.

 

Ah ya. Although it works fine for static renderers. For dynamic couldn't you just create a changed filter for MeshLODGroupComponent/LocalToWorld? Pass it into the job to use as a filter.

 

Well that wouldn't necessary match the data exactly either. And right now there are more serious LOD bugs you hit so probably not worth trying to hack in something for dynamic entities.

 

I'm getting an assertion failure in HybridV2RenderSystem line 2364. Not sure what the trigger is really. Seems to trigger only when I instantiate a large group with a lot already instantiated. Like instantiate 20k it's fine, another 20k it asserts. And it's only doing it on the heavier entities I have which have multiple LOD's. Simpler entities with a single LOD I can't remember hitting it on.

 

Not sure I follow what data does it bake out?. I am using StaticOptimizeEntity for static renderers.

 

Can I feed texture 2d to the shader? I was hoping to generate height maps and feed them to the shader, to keep each terrain entity in same archetype for better performance, but it ended abruptly here,

 

There are some issues with transform system and HR scheduling. I'm using a dedicated world for rendering. Haven't tried to move stuff around to compensate, not entirely sure it's possible without modifying the source.

HR is having to wait on the transform system. This is a mix of static and dynamic renderers, 40k dynamic with around 10% of the dynamic moving every frame. Job debugger/safety checks/leak detection off. The transform job is taking right at 3ms. Not a huge amount that should be within the realm of doable without taking this hit.

Truncated this too much but the wait time was at 1.3ms.

 

I would expect this. The PresentationSystemGroup runs after the SimulationSystemGroup where the default TransformSystemGroup lives. As the TransformSystemGroup is scheduled first in the frame and writes to LocalToWorld, the hybrid renderer needs to wait for it to finish before its own jobs can run.

It still isn't perfect though. For one, it doesn't look like the main thread is helping out with the jobs. And another, these lines exist in HybridRendererSystem:

Code (CSharp):

1.  protected override JobHandle OnUpdate(JobHandle inputDeps)
2.         {
3.             Profiler.BeginSample("CompleteJobs");
4.             inputDeps.Complete(); // #todo
5.             CompleteJobs();
6.             ResetLod();
7.             Profiler.EndSample();

 

Ya it wasn't unexpected. More just pointing out so it gets some attention.

Looking at the source ya it's going to require source changes to fix this. I think how it is would work fine as a default if they had a good api for moving features to arbitrary component groups. The attribute based api for system grouping/ordering probably needs an overhaul though to make that work well.

 

I'm not following. What exactly are you imagining as an ideal?

 

• Upgraded to HRv2
• Saw certain meshes not rendering, and some big slowdowns when exiting Play mode
• returned to HRv1 by removing the define
• my white capsules decided to throw a party .... (they're not supposed to flash like that, they're just a plain white HDRP/Lit material)

My details:

• Unity 2020.1b6
• Entities 0.10.0p6
• HDRP 0.9.0p15
• HybridRenderer 0.5.0p6

-----------------------
EDIT: Happens with Vulkan but not DX11

 

It needs to scale properly. And the scheduling is one thing preventing that right now.

 

I'm still not sure which problem you are specifically addressing nor what "arbitrary component groups" even means.
Are you addressing the main thread idling? Are you addressing the fact that LocalToParentSystem is taking a lot longer than you would expect? (That might be an issue with ChangeFilter) Or are you addressing the fact that HybridRendererSystem calls Complete()? (Unity is obviously aware of that one given the "todo" comment)

 

I said scheduling just to generalize the waiting going on there. I'm not so sure not completing will be the solution. It hasn't been in other features like physics.

 

Bumping my question about HRv2 and supporting sprite renderer. I can't find any info on the feature. It exists/is planned? DOTS roadmap or something like it would be helpful.

 

Did I understand it correctly that I wont be able to write custom shaders for the Hybrid Renderer at all and only URP/SRP Shader and the ShaderGraph are planned to be supported?

Also what is the status of the MeshInstanceRenderer? Is that dead/obsolete now as well?

What would be the recommended approach for a scenario where I would want to use Dots and still write my own shaders? The documentation regarding this is really a pain currently and googling for that currently always ends up at the Hybrid Renderer package.

Sorry if all of the questions have been asked multiple times but it is really not that easy to keep track with all the Dots changes.

 

You can inspect the generated shader graph code for Hybrid Instanced properties and mimic what it does. It is a bit macro heavy, but otherwise not complicated. Writing a custom shader for URP or HDRP in general is going to be the bigger hurdle.

 

Getting some strange behaviour with shadergraph and HybridRendererV2. Essentially reusing the fov projection shader from the fpssample, when used with hybridrenderer v2 in a hierarchical setting, entities using the shader dont appear to have the correct position when rotated.
Small repro project demoing this submitted, case 1244195

 

@SebastianAaltonen, is there any roadblock that prevents releasing new URP supported DOTS Animation package version that has dependency to Hybrid Renderer package? There is plan to release experimental URP support during GDC but until now I didn't see any update.

 

Just thought I'd share my research/results on large scale vegetation rendering with HR.

Billboards. Best approach is to just partition the space and create combined meshes. There is little to no advantage to using more traditional 2D billboards that I could find. I was comparing against Vegetation Studio which uses a fairly optimized instanced indirect setup. HR produces a few more batches this way, but batches seem to have a low cost within reasonable limits.

You do need to deal with atlas creation and properly uv remapping your combined meshes.

The image below shows 170,000 trees in scene, 4 unique variants with unique meshes but sharing the same material. Combined into 484 meshes that are being rendered. My rig here is fairly low end, cpu 3 years old gtx1080 gpu.

Do you have to use billboards of some type? At this scale yes. LOD and culling are prohibitively expensive at this scale without some type of partitioning.

So the challenge was how to render stuff before billboard range. In our case we don't have a lot of LOD levels. If you do it limits how far you can go with this approach. I create a pool of renderers for rendering close up. A spatial map to track what is in range, and then disable/enable renderers from the pool. Also enabling/disabling the appropriate billboard partitions. This has limits your pool has to be small enough to not start hitting the point where culling becomes prohibitively expensive. Which is a few tens of thousands. So you have to factor in the variety you have, how many LOD levels per each, and your LOD distances. Those are what determine how big a pool you need.

There are actually two pools. One for LOD0 and one for individual billboards meshes (not the partitioned ones). Since spatial hashing is not exact we have to fill in from where LOD0 stops to where the partitions start with singular billboard renderers.

How to disable close up renderers is somewhat of a challenge. I was simply moving renderers to 0,9000,0. That works fine but then the transform system becomes a bit expensive. Latest iteration is some minor source modifications to manipulate the world render bounds. For this problem we mostly don't care about the transform system. It's not worth almost any cost it brings.

Overall the approach scales very well with mostly constant cpu time.

 

I have potentially million of cubes and i just spawn them normally via Instantiate. Is there anything i can to improve the fps? I dond think replacing them via billboard is the solution as i really just spawn cubes

 

Use the profiler to find out where your bottleneck is.

 

i was asking in the context of the previous post, since he made some optimizations via billboards and i wonder if something like this would be an improved instead of spawning cubes.

Also since i dont use any "magic" Components on any Cube, there could also be some improvements on my side to give them a specific setting so the hybridrenderer improves the performance even more

 

@Cell-i-Zenit if the instantiation performance is your bottleneck you can only get as fast as spawning them in batches instead of per-cube. If you already do this all you can do is spawn less, by e.g. not spawning what is not visibile or not required.

Also Object Pooling can become pretty critical if you have many of something. Pre-instantiate what you will require and just change if you show/hide. If you already do this you need to really start to dig a bit into the profiler to be more precise about where your bottleneck is.

The golden rule of any optimization is: Measure, measure, measure ... and make sure you measure the right thing the right way.

 

Samples are mentioned in the Package docs, but I'm not seeing them anywhere. Have they not landed yet or are there missing links in the docs?

 

I'm getting heavy shadow flickering with 0.5.0-preview.6 in builds. Like for 1 frame shadows are gone, the next they appear again.
It works fine in 0.4.2-preview.16

There is a mix of entity rendered objects and gameobjects in my scene, if that is any hint to what's going wrong.

 

@SebastianAaltonen
I've added

Code (CSharp):

1. ENABLE_HYBRID_RENDERER_V2

But I can see in Rider that it looks like as if this scripting define is not set?



And no system is created.

Unity 2020.1.0b7

Code (CSharp):

1. {
2.   "dependencies": {
3.     "com.havok.physics": "0.2.2-preview",
4.     "com.unity.build-report-inspector": "0.1.2-preview",
5.     "com.unity.burst": "1.3.0-preview.12",
6.     "com.unity.collections": "0.8.0-preview.5",
7.     "com.unity.dots.editor": "0.6.0-preview",
8.     "com.unity.editorcoroutines": "1.0.0",
9.     "com.unity.entities": "0.10.0-preview.6",
10.     "com.unity.ext.nunit": "1.0.0",
11.     "com.unity.ide.rider": "1.2.1",
12.     "com.unity.ide.visualstudio": "2.0.1",
13.     "com.unity.inputsystem": "1.0.0",
14.     "com.unity.jobs": "0.2.9-preview.15",
15.     "com.unity.mathematics": "1.1.0",
16.     "com.unity.memoryprofiler": "0.2.3-preview.2",
17.     "com.unity.performance.profile-analyzer": "0.6.0-preview.1",
18.     "com.unity.physics": "0.3.2-preview",
19.     "com.unity.platforms": "0.4.0-preview.1",
20.     "com.unity.render-pipelines.universal": "9.0.0-preview.14",
21.     "com.unity.rendering.hybrid": "0.5.0-preview.6",
22.     "com.unity.scriptablebuildpipeline": "1.7.2",
23.     "com.unity.searcher": "4.2.0",
24.     "com.unity.test-framework": "1.1.14",
25.     "com.unity.test-framework.performance": "2.0.9-preview",
26.     "com.unity.testtools.codecoverage": "0.2.3-preview",
27.     "com.unity.textmeshpro": "3.0.0-preview.11",
28.     "com.unity.ui.builder": "0.11.0-preview",
29.     "nuget.mono-cecil": "0.1.6-preview",
30.     "com.unity.modules.animation": "1.0.0",
31.     "com.unity.modules.assetbundle": "1.0.0",
32.     "com.unity.modules.audio": "1.0.0",
33.     "com.unity.modules.imageconversion": "1.0.0",
34.     "com.unity.modules.imgui": "1.0.0",
35.     "com.unity.modules.jsonserialize": "1.0.0",
36.     "com.unity.modules.particlesystem": "1.0.0",
37.     "com.unity.modules.physics": "1.0.0",
38.     "com.unity.modules.physics2d": "1.0.0",
39.     "com.unity.modules.terrain": "1.0.0",
40.     "com.unity.modules.terrainphysics": "1.0.0",
41.     "com.unity.modules.ui": "1.0.0",
42.     "com.unity.modules.uielements": "1.0.0",
43.     "com.unity.modules.umbra": "1.0.0",
44.     "com.unity.modules.unitywebrequest": "1.0.0",
45.     "com.unity.modules.unitywebrequestassetbundle": "1.0.0",
46.     "com.unity.modules.unitywebrequestaudio": "1.0.0",
47.     "com.unity.modules.unitywebrequestwww": "1.0.0",
48.     "com.unity.modules.vr": "1.0.0",
49.     "com.unity.modules.xr": "1.0.0"
50.   },
51.   "testables": [
52.     "com.unity.test-framework.performance"
53.   ]
54. }
55.  

Just for a test purpose I manually edited HybridRenderingV2System.cs

Code (CSharp):

1. #define ENABLE_HYBRID_RENDERER_V2
2. #define DEBUG_LOG_HYBRID_V2

and now the system is created but I still do not see anything rendered. Am I missing a required component? RenderMesh states it only requires a Local2World.

Code (CSharp):

1.     /// Add a RenderMesh component to an entity to define its graphical attributes. The entity must also have a
2.     /// LocalToWorld component from the Unity.Transforms namespace.

What do the colors of the components mean, does any of them indicate which are required and which are optional? Is there any documentation for this that I miss?

(Ignore the Local2World 0 that was just at the point when I created the screenshot)

 

For rendering required not only LTW and render mesh, but also RenderBounds