How to efficiently disable rendering for a specific Entity?

A few methods come to mind:

  • Adding / Removing the 'DisableRendering' component
  • Adding / Removing the 'Disabled' component (also disables all other logic, ideal for pooling?)
  • Moving the entity out of bounds / modifying to bounds
  • Scaling the entity to 0,0,0
  • ?

However all these methods either cause a structural change or feel like a hack.
With the new 'IEnableableComponent' I feel like there should be one for the rendering aswell? So we can simply enable/disable rendering that way.

1 Like

I also hope a enable/disable is possible, but have not looked into it yet (still in progress of upgrading to ECS1.0).

Adding to your list, I currently instantiate/destroy a 'render entity' that follows an 'game entity'. This is for enemies that come in sight range since they will be visible/invisible without switching often.
(for entities that switch visibility more often I move them out of bounds, but it has happened that they where fighting there with other out of bounds units :-), so i use different 'faraway' coordinates for different units)

1 Like

Currently there is no enableable component to disable rendering, but it is something we are looking at. Meanwhile, all of the methods you listed are valid.

+1 for making the DisableRendering an EnableableComponent (sorry for the necro!).

I am working on a 3D tile/grid map editor and I have a fast way to reduce the number of entities needed to be rendered to about 5% of the total count during gameplay: We simply bake a block id on each entity and cull blocks outside the camera - with a little padding for the shadows.

The cull takes a few microseconds, but even in our test case where we only reduce to 30% (to render about 3k entities) we save 0.3ms consistently on a 24 core CPU. That is, until the camera moves and we do structural changes. I think it isn't even the structural change itself, but rather how the rendering system picks them up afterwards, but I am not sure. The result is a choppier frame rate while the camera moves, but a better standstill frame rate. I can imagine it would be even more apparent on something like a 4/8 core CPU.

Since we are about to add grass, this culling will be even more important and we want to avoid going the BatchRendererGroup way.

Also, while working on this I noticed that ChunkWorldRenderBounds are entirely useless. There is no sensible way to sort entities to the chunks, so each chunk has a render bound roughly the size of the whole scene (imagine, it's picking up flowers from all over the place!). And I also noticed that even if I force chunks to be spatially confined to blocks, the render system doesn't seem to care. (I did this test using a custom shared component, so the entities are not batched separately like what the EntitiesGraphicsBatchPartition would cause).

On a side note: multi-material renderers are baked to separate entities, which don't pass through authoring component bakers. Having to make a separate baking system for these is nice and dandy, but some docs would be nice on this!

We are currently working on improvements related to disabling rendering using enableable components, and on multi-material renderers.

As for ChunkWorldRenderBounds, manually forcing entities to spatially local chunks using shared components should be reflected in the chunk render bounds, and should hopefully improve the hierarchical culling performance. It is true that the actual batching does not care, but culling does not consider the batch of an ECS chunk anyway so that shouldn't be a problem as such. Batching affects what can get batched together in a single draw call (need to have same mesh, same material, same batch, same flags) after culling has completed.

[quote=“JussiKnuuttila”, post:5, topic: 904601]
We are currently working on improvements related to disabling rendering using enableable components, and on multi-material renderers.

As for ChunkWorldRenderBounds, manually forcing entities to spatially local chunks using shared components should be reflected in the chunk render bounds, and should hopefully improve the hierarchical culling performance. It is true that the actual batching does not care, but culling does not consider the batch of an ECS chunk anyway so that shouldn’t be a problem as such. Batching affects what can get batched together in a single draw call (need to have same mesh, same material, same batch, same flags) after culling has completed.
[/quote]

I think there should be two tags… One that is structural (for long term disabling) and one that is enableable for short term things like muzzle flashes.

The structural one already exists, it's called DisableRendering. For the second one, we are making the MaterialMeshInfo component an enableable component so it can be used for the short term things like you mention.

2 Likes

[quote=“JussiKnuuttila”, post:7, topic: 904601]
The structural one already exists, it’s called DisableRendering. For the second one, we are making the MaterialMeshInfo component an enableable component so it can be used for the short term things like you mention.
[/quote]

Yeah I knew about DisableRendering. So that is 50% of the way there.

For the other one, something like PauseRendering that is exactly like DisableRendering, but enableable instead would be nice. Is MaterialMeshInfo currently enableable, or is that something coming in a future release?

1 Like


MaterialMeshInfo is not currently an enableable component but it should be in 1.1-exp1 which we're hoping to release as soon as we can.

5 Likes

Hi there, @LorinAtzbergerUnity ! Sorry for the necro of this thread. I just noticed something weird about the Entities.Graphics 1.2.0 package.

The MaterialMeshInfo is enableable now which is fantastic. But, I noticed that all the systems and jobs using it ignore this flag or outright doesn't support them.

Given the state of the package, is toggling this component a good way of enabling/disabling an entity's rendering?

I would also like to know the status of the MaterialMeshInfo/enableable changes

@Neil-Corre I think there's some sort of misunderstanding about how enableables work. In most cases they don't require any special handling and will just work as if the MaterialMeshInfo component is no longer there. For chunk jobs this will affect the visibleWord and for instance in the case of EmitDrawCommandsJob, entities with disabled components will just be skipped.

Toggling the component is the preferred way of enabling and disabling rendering especially if the changes are of a high frequency.

Hi there. Thanks for the prompt reply. I managed to make the enabling and disabling work in a custom culling system we’re working on last week, but I did have to change the Options in these queries inside the graphics package:

  • PushMeshDataSystem.m_LayoutDeformedMeshesQuery - removed the EntityQueryOptions.IgnoreComponentEnabledState
  • EntitiesGraphicssystem.m_ChangedMaterialMeshQuery - removed the EntityQueryOptions.IncludeDisabledEntities

That said, I just reverted these changes now and the system still works. You are right, I might’ve misunderstood the systems.

1 Like