[1.15.2] Custom RenderType does not render

[Alex Sim]

Hello, I'm trying to create a custom RenderType for my block, using a custom lightmap LightmapStateCustom

 

object RenderTypes {
    private val SHADE_ENABLED = RenderState.ShadeModelState(true)
    private val LIGHTMAP_ENABLED = LightmapStateCustom()
    private val BLOCK_SHEET_MIPPED = RenderState.TextureState(AtlasTexture.LOCATION_BLOCKS_TEXTURE, false, true)

    val SOLID2: RenderType = RenderType.makeType("solid2", DefaultVertexFormats.BLOCK, 7, 2097152, true, false, RenderType.State.getBuilder().shadeModel(SHADE_ENABLED).lightmap(LIGHTMAP_ENABLED).texture(BLOCK_SHEET_MIPPED).build(true))
}

 

For now the only methods LightmapStateCustom overrides are `equals(other)` and `hashCode()` (`RenderType.makeType` would otherwise return an existing RenderType) so the RenderType is logically identical to SOLID, but the block does not render (as you can see on the screenshot below)

 

Edited May 11, 2020 by Alex Sim

[TheGreyGhost]

Howdy 

I'm not sure I understand what you're trying to do.

If you make a custom render type for your block, you need to render those blocks yourselves manually.

 

Minecraft renders blocks as follows:

1) Creates a render buffer based on SOLID. Look for all blocks which have SOLID render layer; call their rendering methods to write to the SOLID render buffer

2) Create a render buffer based on CUTOUT.Look for all blocks which have CUTOUT render layer; call their rendering methods to write to the CUTOUT render buffer

3) CUTOUTMIPPED

4) TRANSLUCENT

 

Just because you've given your block a custom RenderType, doesn't mean that vanilla will create a suitable render buffer for it.  If your render type doesn't match the four vanilla block render types, it won't get drawn at all.  If it does match a vanilla render type (because you have done something tricky with equals()) then it will be rendered with the vanilla render type, not your custom render type.

 

-TGG

 

 

[Alex Sim]

23 minutes ago, TheGreyGhost said:

Howdy 

I'm not sure I understand what you're trying to do.

If you make a custom render type for your block, you need to render those blocks yourselves manually.

 

Minecraft renders blocks as follows:

1) Creates a render buffer based on SOLID. Look for all blocks which have SOLID render layer; call their rendering methods to write to the SOLID render buffer

2) Create a render buffer based on CUTOUT.Look for all blocks which have CUTOUT render layer; call their rendering methods to write to the CUTOUT render buffer

3) CUTOUTMIPPED

4) TRANSLUCENT

 

Just because you've given your block a custom RenderType, doesn't mean that vanilla will create a suitable render buffer for it.  If your render type doesn't match the four vanilla block render types, it won't get drawn at all.  If it does match a vanilla render type (because you have done something tricky with equals()) then it will be rendered with the vanilla render type, not your custom render type.

 

-TGG

 

 

 

Ok thanks for the info, how would I go about it tho?

 

After a little bit of digging i found out WorldRenderer calls renderBlockLayer for each block RenderType inside the updateCameraAndRender method, is it possible to render my blocks without changing vanilla code?

[TheGreyGhost]

Hi

Nothing easy springs to mind; if you only have a few of your blocks in the world at any one time then a TileEntityRenderer will do it.  Alternatively you could render them in RenderWorldLastEvent with your own caching + chunk-culling logic but that may have side effects with translucent textures.

 

The first thing I would personally try would be to replace WorldRenderer with a derived class (will require reflection)- at the cost of being pretty fragile and perhaps making your mod incompatible with others.  Other folks have used Reflection and asm to locate and overwrite the byte code to insert a call to a new method at the desired location - that's getting very arcane and perhaps not worth the trouble.

 

There might be other ways to do it if you have other mods installed (perhaps Optifine or similar provides an alternative mechanism for what you want to do)

 

-TGG

[Alex Sim]

On 5/12/2020 at 12:10 PM, TheGreyGhost said:

Other folks have used Reflection and asm to locate and overwrite the byte code to insert a call to a new method at the desired location

Is it possible to learn this power?

[imacatlolol]

3 hours ago, Alex Sim said:

Is it possible to learn this power?

Not from a Jedi.

Just wondering, but what is the specific purpose of your custom render type? It seems you just want a custom lightmap, but it would help to know your reasons since there might be safer alternatives.

[Alex Sim]

Just now, imacatlolol said:

Not from a Jedi.

Just wondering, but what is the specific purpose of your custom render type? It seems you just want a custom lightmap, but it would help to know your reasons since there might be safer alternatives.

I was just experimenting for now but my (probably unreachable) goal is to light every pixel differently (maybe using the alpha level) like so:

 

[imacatlolol]

11 minutes ago, Alex Sim said:

I was just experimenting for now but my (probably unreachable) goal is to light every pixel differently (maybe using the alpha level) like so

I see! That would certainly be achievable without needing a custom render type or lightmap.

In this case, you would want to make a custom IModelLoader and model to use with your block JSONs. See MultiLayerModel and its usages for roughly what that process would be.

Applied Energistics actually achieved this effect, but their repo is outdated and most of the actual code no longer applies. It's still a good reference for how you could try implementing it yourself if you get stumped. Just take a look at the charged certus quartz ore.

[Alex Sim]

27 minutes ago, imacatlolol said:

I see! That would certainly be achievable without needing a custom render type or lightmap.

In this case, you would want to make a custom IModelLoader and model to use with your block JSONs. See MultiLayerModel and its usages for roughly what that process would be.

Applied Energistics actually achieved this effect, but their repo is outdated and most of the actual code no longer applies. It's still a good reference for how you could try implementing it yourself if you get stumped. Just take a look at the charged certus quartz ore.

 

Thanks, that's very helpful, I basically have to do something like this, definitely way easier than whatever tf I was trying to do

Edited May 15, 2020 by Alex Sim

[Alex Sim]

On 5/12/2020 at 12:10 PM, TheGreyGhost said:

Other folks have used Reflection and asm to locate and overwrite the byte code to insert a call to a new method at the desired location

My quarantine fueled boredom led my to try this anyway (would be useful for other purposes in my mod)

So I made an utility class that uses Kotlin (1.4) extension functions, here is the Kotlin class on pastebin

 

The methods to use are `addMethodAfter`, `addMethodBefore`, `replaceMethod` and `replaceMethodOrFallback`

It's pretty small and should be easy enough to convert it to Java

Here is an usage example (I call it from my mod's constructor):

 

/**
 * Replaces animateTick so that it does nothing (fire particles not spawned) if in the Glacia dimension
 * Otherwise fallback to default method
**/
WallTorchBlock::class.replaceMethodOrFallback(WallTorchBlock::animateTick) {(_, world) ->
    if ((world as World).dimension?.type != Glacia.DIMENSION.type) RedefineUtils.fallback()
}

 

Edited May 16, 2020 by Alex Sim

[Alex Sim]

13 minutes ago, diesieben07 said:

...

Please don't write jar mods in Java / Kotlin / JVM languages and don't use the instrumentation stuff. I don't even know how you expect that to work outside the development environment.

If you must, use Forge's coremod system.

I use Johnrengelman's shadowJar plugin to embed the libraries I use in my mod (and rename the base package), including the Kotlin runtime

You're right about the instrumentation stuff though, it apparently doesn't work outside the dev environment ?

[Alex Sim]

2 hours ago, diesieben07 said:

...

Please don't write jar mods in Java / Kotlin / JVM languages and don't use the instrumentation stuff. I don't even know how you expect that to work outside the development environment.

If you must, use Forge's coremod system.

BTW correct me if I'm wrong but the only issue here seems to be the attach library, if there was a way to use it in JRE (I'm open to suggestions) the rest would probably work

Edited May 16, 2020 by Alex Sim

[Alex Sim]

18 minutes ago, diesieben07 said:

No.

You should not go around the coremod system that is in place. Coremods are intentionally very limited.

Should or could? Sorry if I sound insistent but I don't see what's the issue. Aside from practical ones (whether I could, and I seem to be one dll away from being able to), why should I not?

My boredom knows no "should"

Edited May 16, 2020 by Alex Sim

[Alex Sim]

2 minutes ago, diesieben07 said:

Coremods need to load in a very early stage of the game. In a different classloader than normal mods.

ClassPool.getDefault().apply {appendClassPath(LoaderClassPath(Thread.currentThread().contextClassLoader))}

This seems to work on non-dev-environment Minecraft, it used to throw javassist.NotFoundException without it;

But you probably already know why this won't work and crush my hopes and dreams ?

[Alex Sim]

3 minutes ago, diesieben07 said:

I don't know how you expect this to work.

Mods load way after Minecraft classes are already loaded. There is no way to transform them then.

Doesn't redefineClasses also retransform classes?

 

public class Hello {
    public int helloWorld() {
        LogManager.getLogger().log(Level.INFO, "Hello World")
    }
}

init { //Based on my tests
    val hello = Hello()
    hello.helloWorld() //Prints "Hello World"
    Hello::class.addMethodAfter(Hello::helloWorld) {
        LogManager.getLogger().log(Level.INFO, "Goodbye World")
    }
    hello.helloWorld() //Prints "Hello World", then "Goodbye World"
}

 

I cannot add new methods or fields, but what I CAN do is change an existing method's bytecode, which is exactly what I'm doing (if you look at my source I found a little workaround to call my local variable (functional interface) by creating a new static class at runtime)

[Alex Sim]

2 hours ago, diesieben07 said:

You are abusing this API. This is not what the JVM's instrumentation API is designed for.

 

Please use Forge's coremods.

Maybe, but that's exactly what the Javassist library is designed for: to assist me raping the JVM

 

Jokes aside, this would allow me to retain the old logic for a method on top of mine, and also possibly be compatible with any other hypothetical mod that would use the same approach (as if). I'm honestly not sure whether that's possible with coremods, but as far as I know two mods replacing the same class will conflict with each other

 

If that's not the case I'll look into coremods

Edited May 17, 2020 by Alex Sim