FrozenFarmer64

@TurtyWurty--Did you ever figure out how to resolve this issue? I'm having the same problem right now with a custom feature of my own, and I haven't figured much out.

@DavidM--I want to render only a few blocks that way, if that helps the situation. I don't even want to extend that [0, 15] light level limit, but I was just hoping to lower the light value of some custom blocks by changing their light value in broad sunlight.

I have been messing around with custom lighting for a Minecraft Mod and have been running into some roadblocks in changing the light value of a block. I am trying to make a block render darker than the world light value. Does anybody have any ideas on how the result from WorldRenderer::getCombinedLight could possibly be changed?

Ah, yes, I see what you are saying and why I was confused—I tried outputting the biome parameter to console in my custom buildSurface method, and since it only output my custom biome, I assumed that there were just multiple passes of the method, one for each biome in the chunk. I don’t know why I just assumed that the entire chunk was being passed through... Thank you so much for the assistance @ChampionAsh5357!

Yes, the function does take in an x and a z coordinate, but my understanding of the function is that for chunks with multiple biomes, the registered surface builder is run across the entire chunk for EACH biome in the region, passing the Biome that the surface builder is registered under as the Biome parameter. I am fairly confident that the biome parameter doesn’t actually indicate the unique biome at the position, but rather the biome of the surface builder being ran.

I can see how that would be the case with rivers—however, what about Biome boundaries (i.e. the edges between biomes)? Those aren’t separated discreetly by chunk (at least not the transitions).

Thank you for the help @ChampionAsh5357--the logical sides issue makes sense, and I didn't realize that getWorldForge defaulted to null for instances of ChunkPrimer. For a second I thought that I was just being dumb about the Biome argument, but no, there is still an issue with that. The Biome parameter is always a reference to the custom biome which is being built, regardless of what the biome ACTUALLY is at the position (specifically, in the case of biome transitions, rivers, etc.). I was trying to determine what the "dominant" biome was at a position (i.e. the one that you get from World#getBiome). I can't think of any way to do this, however, without crossing over logical sides--any ideas on this would be incredibly helpful!

Hello all, I have been trying to access the biome for a given coordinate during chunk generation in SurfaceBuilder#buildSurface and have been running into some struggles. I have tried finding an instance of World to use the getBiome method, but the following attempts have not worked: 1) Using Minecraft.getInstance().world.getBiome. Occasionally Minecraft will crash under a nullPointerException, but even if there is no crash, the getBiome command will return PlainsBiome regardless of the entered coordinates. 2) Using IChunk#getWorldForge().getBiome. getWorldForge seems to always return null, as is discussed but not excatly resolved in this forum post. 3) I have also tried copying the getBiome method from FuzzedBiomeMagnifier#getBiome. This works okay, but there are odd blocks that will seemingly randomly return the wrong biome, which is causing some disruption. I have been using the following code for the BiomeManager.IBiomeReader and seed, which I think could possibly (but unlikely) be the problem: public Biome getBiome(int x, int y, int z, IChunk chunkIn) { BiomeManager.IBiomeReader biomeReader = chunkIn.getBiomes(); long seed = Minecraft.getInstance().world.getSeed(); /* ... rest of the code here ... */ } If anybody has any ideas or thoughts about this problem, I would appreciate the assistance. Thank you all!

Ah ha! It worked! Thank you everybody for the incredible help! Here is a fairly detailed solution to the problem for anybody's reference: 1) Make your block tex multi-layered. TheGreyGhost has an excellent tutorial of this under mbe05 of Minecraft By Example. Be sure to register one layer as a RenderType.getCutout() and one as a RenderType.getTranslucent(), and to adjust the .json file accordingly. /* In charge of client initialization */ private void onClientSetup(final FMLClientSetupEvent event) { ... // Render type registry for glowing blocks RenderTypeLookup.setRenderLayer(MinenauticaBlocks.WRITHING_WEED, Minenautica::getDoubleLayer); ... } // Double layer render lookup public static boolean getDoubleLayer(RenderType layerToCheck) { return layerToCheck == RenderType.getCutout() || layerToCheck == RenderType.getTranslucent(); } 2) Create and register a custom IBakedModel. We need to register a custom IBakedModel because we will need to manually update the light value of the quads on the translucent layer of the model. Again, Minecraft By Example has an excellent tutorial of this under mbe04. I would use the CamouflageBakedModel as reference, as we will be using the standard model of the block, just with a modification to the quads. 3) Alter the getQuads method. We will be altering this method to check which render layer we are currently on, and then altering the quads on the translucent layer. We are most interested with the vertexData of BakedQuad, which holds the following data, again from Minecraft By Example: // vertexData[i + 0] = Float.floatToRawIntBits(positionIn.getX()); // vertexData[i + 1] = Float.floatToRawIntBits(positionIn.getY()); // vertexData[i + 2] = Float.floatToRawIntBits(positionIn.getZ()); // vertexData[i + 3] = shadeColor; // vertexData[i + 4] = Float.floatToRawIntBits(textureU)); // vertexData[i + 5] = Float.floatToRawIntBits(textureV)); // vertexData[i + 6] = baked lighting (blocklight + skylight) // vertexData[i + 7] = normal; There are four groups of these eight pieces of data, and we are concerned which changing the 7th element in each of these groups that correspond with the baked lighting value. It is critical to note that to account for both the block light and sky light, the value of baked lighting is a 32-bit integer, where the upper 16 bits contain the sky lighting * 16 and the lower 16 bits contain the block lighting * 16. So, for example, the brightest baked lighting value would be 2^16 * 15 * 16 + 15 * 16 = 15728880. We will run through each BakedQuad in the model and set the baked lighting values to this new baked lighting value. For a more detailed explanation, here is a good link. @Override @Nonnull public List<BakedQuad> getQuads(@Nullable BlockState state, @Nullable Direction side, @Nonnull Random rand, @Nonnull IModelData extraData) { List<BakedQuad> quads = this.model.getQuads(state, side, rand); if(MinecraftForgeClient.getRenderLayer() == RenderType.getTranslucent()) { for(int i = 0; i < quads.size(); i++) { BakedQuad quad = quads.get(i); int[] vertexData = quad.getVertexData(); for(int j = 0; j < 4; j++) { vertexData[8 * j + 6] = getLightValue(15, 15); } quads.set(i, new BakedQuad(vertexData, quad.getTintIndex(), quad.getFace(), quad.func_187508_a(), quad.shouldApplyDiffuseLighting())); } } return quads; } /* * Return the light value for a given sky lighting and block lighting * A 32-bit integer, with the upper bits skyLighting*16 and the lower bits blockLighting*16 */ private static final int UPPER_HALF = 65536; // 2^16 private static int getLightValue(int skyLighting, int blockLighting) { return UPPER_HALF * skyLighting * 16 + blockLighting * 16; } And that is it! There are few steps, but in the end we are just registering a translucent layer, and then adjusting the quads of that layer. Thank you everybody for the help, and I am posting pictures of the results below (for more pictures you can visit the mod's website at Minenautica). Light Image: https://ibb.co/djRYL32 Dark Image: https://ibb.co/dQ7TctP

Okay, thank you! I will look into the BlockModelRenderer and post back again with updates.

Oh yes, that makes sense, but is there a method similar to getPackedLightmapCoords in the render layer? If that is the case, then I would only have to register/pass in a custom render layer and modify the lightmap coordinates method to always register the translucent layer with full brightness. All I have been able to find, however, is the RenderType class, but I don't know exactly what render layer file different types are referencing/what those different RenderTypes are actually doing. The only real reference to lightmaps I have tracked down is in the RenderType.Builder class, but even with that variable I have not been able to track it back to a place where the lightmap coordinates are chosen.

Ah, okay, that is good to know! Where is the render layer now handled, then? I tried searching through the Minecraft source code but haven't found any references to the lightmap.

Ah, my apologies, that is not exactly what I meant--I wasn't very clear with what I said. Yes, glowing is being used there to determine the light value. But, correct me if I am wrong, but that is just the ambient glow for the block (i.e. glowstone or torch). Lower in that class, there is a commented out method which is referencing the specific render layer. This seems to at one point have been the code that created the "glowing overlay" for the plants (which still exist, even though this method is commented out). I don't know how they are still doing this, however, after commenting out that method, and I haven't been able to find any other reference to the "glowing" variable, or any other code that references the lightmap coordinates (which I think is what I need to find). I hope that clears up what I meant. @Override @OnlyIn(Dist.CLIENT) public int getPackedLightmapCoords(BlockState state, ILightReader source, BlockPos pos) { if (!this.glowing) return super.getPackedLightmapCoords(state, source, pos); if (MinecraftForgeClient.getRenderLayer() == BlockRenderLayer.CUTOUT) { return source.getCombinedLight(pos, 0); } else { return source.getCombinedLight(pos, 14); } }

Did you find anywhere where the glowing parameter is actually utilized, however? Perhaps I missed something, but I haven't found anywhere where the glowing parameter is used, beyond it being set in the constructor.

Thank you TGG for the link--adding the layered textures was very easy while following it! However, my update for a glowing layer isn't great. I tried modifying just the json model file as you suggested Draco18s, but I haven't had any luck there. The "shade" command is associated with whether shadows are rendered and don't effect lighting as far as I am aware. I also tried messing around with the tint index, but that hasn't been much help. I most recently tried making a custom BlockState class in attempt to change the getLightValue method, but that attempt was pretty last ditch. I registered the custom BlockState with the default state, but I couldn't change the final stateContainer variable, which is why I think the plants failed to render (at least the game didn't completely crash). I am a bit lost on how I would make a custom BlockModel, but perhaps the answer lies there. Does anybody know any resources that can help with me adding one? Alternatively, I have been trying to find an alternative to the getPackedLightmapCoords method in Block that existed in previous Forge versions. I am not sure if there is a way to do something similar to that, but if anybody has any ideas that would be wonderful. This link mentioned a technique similar to this but with Forge 1.8.x. A mod called "The Midnight" implements something similar to what I am going for, with a glowing overflow for some flowers. For example, there is a bogshroom_glow.png file, however I am not sure how this file is implemented. There is what seems to be an unused blockstate file refrencing it, as well as a (as far as I can tell) unused "glowing" parameter in the MidnightPlantBlock.java file. If anybody has tried or has thoughts on any of these ideas I would greatly appreciate the help. Thank you everybody!