Jump to content

[Solved][1.6.2] Disable lighting on normal (not custom model) Block


Recommended Posts

Posted

It was easy disabling "natural" lighting on my custom blocks using GL11.glDisable(GL11.GL_LIGHTING) in the renderer for their "on"-state:

Fixtures.jpg

This makes the lamp glow nicely, without any shadowed sides.

 

Is the same thing possible for "normal" blocks (Blocks without custom model)? I'd like to achieve the same effect for my normal lamps without having to create the unnecessary overhead of a custom model. right now, they look like this when turned on (bottom half of the image):

LumaLamps.jpg

You can see that even though they're turned on, the sides are darker than the top.

 

I'm working with Forge version 9.10.0.804 (MC 1.6.2)

Posted

I looked into this and it seems to be the way to go.

 

So I tried this (it's probably stupid, but that's what seemed to make sense):

public class BlockLampRenderer implements ISimpleBlockRenderingHandler {
    public void renderInventoryBlock(Block block, int metadata, int modelID, RenderBlocks renderer) {

    }

    public boolean renderWorldBlock(IBlockAccess world, int x, int y, int z, Block block, int modelId, RenderBlocks renderer) {


        GL11.glDisable(GL11.GL_LIGHTING);

        renderer.renderStandardBlock(block, x, y, z);

        GL11.glEnable(GL11.GL_LIGHTING);

        Luma.log("Render");
        return true;
    }

    public boolean shouldRender3DInInventory() {
        return false;
    }

    public int getRenderId() {
        return ClientProxy.lampRenderType;
    }
}

If I remove the GL-Statements, it renders the blocks like before. With these statements, something very weird happens. The lighting (shading) is disabled, but for ALL blocks in the chunks where the lamps are placed. And they're not bright, but quite dark. This is clearly the wrong approach...

 

Another weird thing: I have a console output in the method. This fires only when a block is placed or its state changes.

On my custom model lamps (using the OBJ importer to use a model made in blender) i had a console output for testing as well (TileEntitySpecialRenderer). that one fired every frame. I get a feeling that the two methods don't work the same way at all.

 

I'll continue to look into this and eventually find out, but it would help a lot if someone could give me a hint on how to approach this...

 

Posted

yeah, basicly use the tessellator instead of the renderer reference, the renderer reference uses a lot of insanelly non conventionnal techniques to render the block

 

 

and dont disable lighting :P

 

and yes TESR and ISBRH work very differently :P

how to debug 101:http://www.minecraftforge.net/wiki/Debug_101

-hydroflame, author of the forge revolution-

Posted

Thanks a lot for the Tessellator Hint. I think I know what to do now, because of your hint and also this thread:

http://www.minecraftforge.net/forum/index.php?topic=11053.0

 

You can set the brightness value using the tesselator. I think this is what I was looking for.

 

Do you know if there are any considerable performance differences between the TESR and ISBRH version? Is it always better to use ISBRH if possible? I think i might be able to use it for my other (custom model, but simple) lamp blocks as well...

Posted

yeah isbrh are always more performant then tesr becausetesr requires a tile entity. if you dont have one you cannot use tesr. in term of how much gpu computation they both require, its almost the same. technicly tesr will take a tiny bit more computation because you can add animation n stuff but in that sens you shouldnt worry about it.

how to debug 101:http://www.minecraftforge.net/wiki/Debug_101

-hydroflame, author of the forge revolution-

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Announcements



  • Recently Browsing

    • No registered users viewing this page.
  • Posts

    • @Tsuk1 Also, new note, you can use blockbench to make the custom item model for when it is not on the head.   EDIT: Funny story, I am making a mod similar to yours! Mine is called NorseMC.
    • @Nood_dev Could you send a screenshot of your weapon code? Here is the one I made (for a dagger): The specific UUID does not matter, just that it is the same every time, which is why UUID#randomUUID does not work public class DaggerItem extends TieredItem implements Vanishable { protected static final double REACH_MODIFIER = -1.5D; protected final Multimap<Attribute, AttributeModifier> defaultModifiers; protected final UUID BASE_ATTACK_REACH_UUID = UUID.fromString("6fe75b5c-9d1b-4e83-9eea-a1d5a94e8dd5") public DaggerItem(Tier pTier, int pAttackDamageModifier, float pAttackSpeedModifier, Properties pProperties) { super(pTier, pAttackDamageModifier, pAttackSpeedModifier, pProperties); this.attackDamage = (float) pAttackDamageModifier + pTier.getAttackDamageBonus(); ImmutableMultimap.Builder<Attribute, AttributeModifier> builder = ImmutableMultimap.builder(); builder.put(Attributes.ATTACK_DAMAGE, new AttributeModifier(BASE_ATTACK_DAMAGE_UUID, "Weapon modifier", this.attackDamage, AttributeModifier.Operation.ADDITION)); builder.put(Attributes.ATTACK_SPEED, new AttributeModifier(BASE_ATTACK_SPEED_UUID, "Weapon modifier", pAttackSpeedModifier, AttributeModifier.Operation.ADDITION)); // THE ONE YOU WANT: builder.put(ForgeMod.ENTITY_REACH.get(), new AttributeModifier(BASE_ATTACK_REACH_UUID, "Weapon modifier", REACH_MODIFIER, AttributeModifier.Operation.ADDITION)); this.defaultModifiers = builder.build(); } @Override public Multimap<Attribute, AttributeModifier> getDefaultAttributeModifiers(EquipmentSlot pEquipmentSlot) { return pEquipmentSlot == EquipmentSlot.MAINHAND ? this.defaultModifiers : super.getDefaultAttributeModifiers(pEquipmentSlot); } }
    • https://images.app.goo.gl/1PxFKdxByTgkxvSu6
    • That's what we'll try out. I could never figure out how to recreate the crash, so I'll just have to wait and see.
    • Ok, I updated to the latest version and now the models are visible, the problem now is that the glowing eyes are not rendered nor any texture I render there when using shaders, even using the default Minecraft eyes RenderType, I use entityTranslucent and entityCutout, but it still won't render. Something I noticed when using shaders is that a texture, instead of appearing at the world position, would appear somewhere on the screen, following a curved path, it was strange, I haven't been able to reproduce it again. I thought it could be that since I render the texture in the AFTER ENTITIES stage which is posted after the batches used for entity rendering are finished, maybe that was the reason why the render types were not being drawn correctly, so I tried injecting code before finishing the batches but it still didn't work, plus the model was invisible when using shaders, there was a bug where if I look at the model from above it is visible but if I look at it from below it is invisible. So in summary, models are now visible but glowing eyes and textures are not rendered, that hasn't changed.
  • Topics

  • Who's Online (See full list)

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.