CreateMissingRenderBoundsFromMeshRenderer Removed in Hybrid Renderer 0.3.4

I updated to the Hybrid Render 0.3.4 along with the rest of the DOTS related packages and it looks like the CreateMissingRenderBoundsFromMeshRenderer system got removed, this seems to be why all the entities I have stopped being rendered. I'm creating all my entities in Code, not from GameObjects or Prefabs being converted. I looked through the packages and the only place I can see RenderBounds being created now is in MeshRendererConversion.cs.

Do I now need to be creating RenderBounds on any code created entities that want to render?

This works fine if I revert back to the Hybrid Renderer 0.3.3 and the CreateMissingRenderBoundsFromMeshRenderer system is back.

1 Like

I found the same thing while updating my project the other day. For now I've added RenderBounds manually when I add the RenderMesh component, using mesh.bounds.ToAABB(). I was going to make a post about it, but I came to the conclusion that they're assuming/encouraging everyone to be using GameObjectConversion now, and it won't be too hard for me to move to that too when I get around to it.

However it would be nice if the changelog for the package included details like this...


Yeah it's just annoying, mesh.bounds can only really be touched from the main thread, I have a whole lot of creation of rendered entities that goes on inside jobs. I may end up just creating my own version of CreateMissingRenderBoundsFromMeshRenderer just because with everything I'm doing being dynamic creation I don't have a use really for GameObjectConversion.

same here, just updated to hybrid renderer to 0.3.4 and it’s not rendering at all. Is this behaviour intended or can we expect a fix for this ?

EDIT: I could fix it by adding the RenderBounds component and assigned the mesh bounds via .ToAABB() Thx for the hint @TLRMatthew

Talk about no love for this package, cant’ even be bothered to create release notes for breaking changes.

If you instantiate prefabs, the RenderBounds (and ChunkWorldRenderBounds) will be added automatically to the prefab. Everything works as usual in this common case. But if you create entities from scratch in the code, you need to manually add RenderBounds yourself now.

This change was made to improve the runtime performance of the bounds system, and to solve fragmentation issues when instantiating entities at runtime. Previously if you instantiated one new entity every frame, you ended up with chunks of 1 entity each. Now the new entities get properly added to the same chunks as existing entities (as their archetype matches).

We are sorry that this breaking change slipped though the change list. Our current entity instantiation test is instantiating prefabs instead of manually crafting entity in code. We will add a new test case that covers this use case too.


We now have a dedicated team responsible for hybrid.renderer package. Our team has been doing a big refactoring to the hybrid renderer. We internally call it "Hybrid Renderer V2". This new version adds missing features, fixes bugs and improves performance. It also has proper test coverage to ensure that features don't break. Expect to see significant changes and continuous improvements to this package in the future.


FYI a real pain with the hybrid renderer, and actually a persistent issue throughout almost all feature level DOTS packages, has been the inability to easily order where they run. In a real game completing jobs in the rendering group that can have dependencies from simulation is pretty much a non starter. And the only fixes are less then desirable. Custom player loops which in this scenario get a bit complex, and you have to reason about where ECS internals are plugging into them also to time it right. Or create dev versions of the packages.

Once your scenario is using the bulk of feature level packages this actually gets extremely complex. I think what would probably help a lot is abstract out group creation and wrap it with a settings object of some type. So we can easily override what groups packages run in. Packages ordering their own systems via each other is fine, but pretty much everything else in a real game you end up wanting fine grained control over, and there really isn't a good reason to have that internal.

Is that URP support optimised for mobile in development too?

Yes. Hybrid Renderer V2 already has better URP support than the old hybrid renderer. In 2020.1 we focused on stable URP with minimal feature set and good CPU performance and test coverage. The flickering issues, random color issues and exploding polygons are gone. The missing lighting features will not land yet in 2020.1. We have a new backend that allows us to build those features in a robust and efficient way, making it possible to make quick progress for getting Hybrid URP feature complete.


As you said this is a general DOTS architecture issue, not a renderer issue. I agree with you, better configurability would be great. Personally I would also like to have the rendering running fully separately from the DOTS main loop. DOTS main loop code would update rendering data and then rendering would run in a separate world in a separate timeline, allowing it to overlap with the next frame to achieve better parallelism and better CPU utilization.


So I need to add RenderBounds during entity cretion? Docs says that if we provide RenderMesh and LocalToWorld object will be rendered. But if to use only these two components - its not renderd

I was able to add entity programmatically if to manually configure RenderBound via values form Mesh.bounds

       Entity leaderEntity = entityManager.CreateEntity(

        entityManager.SetSharedComponentData(leaderEntity, new RenderMesh
            mesh = ourMesh,
            material = ourMaterial,

        entityManager.SetComponentData(leaderEntity, new RenderBounds(){
            Value = new AABB()
                Center = new float3(,,,
                Extents = new float3(ourMesh.bounds.extents.x, ourMesh.bounds.extents.y, ourMesh.bounds.extents.z)

Correct. The document is outdated. Could you link me to the document with incorrect information so I can make sure we update that. Thank you!

This one.

1 Like

Do you have an approximation of when the Hybred Renderer v2 will be released?
Also does the Hybred Renderer v2 will implement the occlusion culling and dynamic batching ?

1 Like

We have DOTS occlusion culling technology also in development. Hybrid renderer doesn’t need the old dynamic batching technique, the batching solution we use in hybrid renderer is superior to dynamic batching, and we improved the batching performance in Hybrid Renderer V2. You will see larger batch sizes and GPU performance improvements in scenes with larger batch sizes. The main goal however was to improve the CPU performance of the original hybrid renderer. Current profiling results are highly positive.

I will give you release time estimate in the following weeks.


does this means less Draw Calls or a totally different Technology ?

Hybrid renderer is batching by material/mesh and using large instanced draw calls. Each instanced draw can draw up to 1023 entities in Hybrid V2. The limit was around 400 in Hybrid V1. Traditional GameObject rendering is completely different. HDRP and URP GameObject rendering issues one draw call per GameObject. That's a huge difference.

With GameObjects you could use static batching and dynamic batching to reduce the number of draw calls by combining meshes, but both static/dynamic batching costs significant amount of memory, and dynamic batching costs a lot of CPU time too as it combines mesh vertices at runtime on CPU. The new technology is definitely faster than either.


Updated hybrid.renderer documentation page. Lots of new info there, including fix for this. Also change log was updated with this breaking change. Both should land in next hybrid.renderer package.