mojira.dev
MC-138488

Some entities are not rendered as bright as they should be when part of any spawner

Some entities are not rendered as bright as they should be when used as the 'displayEntity' (or rather, the 'summoned mob') of a spawner.

Steps to Reproduce:

  1. Place down a monster spawner, or trial spawner

  2. Use a blaze spawner on it

  3. Tick freeze for easy observation

    /tick freeze

Observed & Expected Results:

❌ - The blaze is rendered very dim compared to when the blaze is spawned as an entity.
✔ - The blaze would be rendered exactly how it is rendered in entity form.

Screenshots/Videos:

[media]

Notes:

  1. This also affects all entities that are burning:

    /give @p spawner{BlockEntityTag:{SpawnData:{entity:{id:"minecraft:zombie",Fire:1000,HasVisualFire:1b}}}} 1
  2. Currently affected entities are:

    [media]

Code Analysis:

The entities listed are affected because they override the `getBlockLightLevel()` method inside `net.minecraft.world.entity.Entity` by always returning 15 (the brightest block light level) instead of using a shader to render brighter like done with the emissive 'eye' layers of entities such as spiders, endermen, or phantoms (which all behave normally inside spawners).

The regular behavior for entities:

net.minecraft.world.entity.Entity
protected int getBlockLightLevel(T entityType, BlockPos blockPos) {
      return entityType.isOnFire() ? 15 : entityType.level().getBrightness(LightLayer.BLOCK, blockPos);
   }

(As an example) The behavior for blazes:

net.minecraft.client.renderer.entity.BlazeRenderer
protected int getBlockLightLevel(Blaze entityType, BlockPos blockPos) {
      return 15;
   }

Related issues

Attachments

Comments

migrated
[media][media][media][media][media][media]
migrated

any ideas on what could cause this in code so I can try and make a fix via mod?

pokechu22

Code analysis: This is caused by spawners using the method MCP calls RenderManager.renderEntity(Entity, double, double, double, float, float, boolean) instead of the one it calls RenderManager.renderEntityStatic(Entity, float, boolean) (n.b. both methods aren't actually static, so that name doesn't make sense; just note that it uses the one that takes a position as parameters instead of the one that computes the position).

However, renderEntityStatic is responsible for handling brightness logic, while renderEntity uses the current brightness. For most entities, this isn't a problem, as their brightness is the exact same as the brightness for the spawner itself. However, a select few entities have custom brightness values, mainly returning max brightness regardless of the current world brightness (they override getBrightnessForRender, which returns two values packed into an int; for reference, 15728880 is 0x00F000F0):

  • Blazes

  • Magma Cubes

  • Vexes

  • Withers

  • Fireballs (of various types)

  • Shulker bullets

  • The eye of ender

  • XP orbs (notably, these have special logic that factors in current brightness as well)

Additionally, burning entities normally have the light set to max in renderEntityStatic.

Switching over to renderEntityStatic would solve the issue, but messes up the translations needed for spawners to render the entity in the right place. My lazy solution is to simply copy-paste the lighting code into the spawner code before it calls renderEntity, but that's obviously not ideal.

Note that it is fine to call getBrightnessForRender on the entity inside the spawner, as its position is set to the world coordinates of the spawner, so it'll get the same light level as the spawner itself if the entity doesn't override getBrightnessForRender.


Aside #1: The other uses of the renderEntity method (that doesn't set light level) are rendering entities in GUIs, the particle that implements item pickup, the particle that implements the guardian spawn animation, and the code that renders arrows stuck in an entity. For all of those, it does make some sense to use current light values (though for all other than GUIs, it could also probably be switched if the entities had correct positions) and the entities being rendered won't override getBrightnessForRender. Only for spawners does this actually cause problems.

Aside #2: Burning entities inside of a spawner have incorrect billboarding; I've created MC-138860 for that. This behavior is such a small detail that it really doesn't matter too much, but I noticed it during testing.

migrated

so what would be a solution then for both me and mojang? set the brightness equal to getBrightnessForRender()?

I think I have a solution but, I don't like it. Get the original value of the light coords from what it's suppose to render for when it's enabled. Then modify it to each indiviual entity's light value copying logic from renderEntityStatic(). From there reset the light coords back to the original after rendering said entity and do this for all entities rendering inside of the single mob stack at least on my end. I will try this another day thanks for pointing this out.

I will post my mod's render source for mojang here later when it get's done.

pokechu22

Yeah, pretty much. Note that at least for regular spawners, you don't need to reset back because they don't do any more rendering, but the actual code to set up lighting for it does happen earlier in TileEntityRenderDispatcher.render (where it calls world.getCombinedLight, which behaves basically the same as getBrightnessForRender).

migrated

yup you just need to make sure the entity's xyz is equal to the te's xyz in order for the lighting to work properly. and in the inventory it's player's xyz except maybe in the entity form inside the world

migrated

I got it working with setting the entity's xyz either on creation or before render equal to the tile entity's pos xyz, then setting the lighting coords equal to the entity's getBrightnessForRender() just as vanilla does it in static render.

Just before each entity rendered inside of a spawner call this Code:
https://pastebin.com/FdueEG2h

picture:

[media]
Orbic

In 20w11a

Orbic

In 20w12a

Avoma

Can confirm in 20w51a.

Avoma

Can confirm in 21w05b.

Avoma

Can confirm in 21w06a.

Avoma

Can confirm in 1.16.5 and 21w08b.

ampolive

Can confirm in 21w40a.

[Mod] Jingy

Affects 1.20.3. Requesting ownership of this issue as @unknown has been inactive for almost 4 years.

[Mod] Jingy

(Unassigned)

Confirmed

Rendering

entity-lighting, spawner

Minecraft 1.13.2, Minecraft 18w43b, Minecraft 18w43c, Minecraft 18w44a, 1.14.4, ..., 1.20.4, 23w51b, 24w07a, 1.20.5 Pre-Release 1, 1.20.5

Retrieved