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:
Place down a monster spawner, or trial spawner
Use a blaze spawner on it
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:
This also affects all entities that are burning:
/give @p spawner{BlockEntityTag:{SpawnData:{entity:{id:"minecraft:zombie",Fire:1000,HasVisualFire:1b}}}} 1
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
testing discovered
Attachments
Comments


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

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.

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.

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
).

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

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]
In 20w11a

In 20w12a
Can confirm in 20w51a.
Can confirm in 21w05b.
Can confirm in 21w06a.
Can confirm in 1.16.5 and 21w08b.

Can confirm in 21w40a.
Affects 1.20.3. Requesting ownership of this issue as @unknown has been inactive for almost 4 years.