Rendering of a block - something is missing?

[ThexXTURBOXx]

Hello community,

 

I'm pretty new to OpenGL and the Tesselator.

I have coded the following:

https://gist.github.com/ThexXTURBOXx/04eb325a7c90811e24b975ac94975634

I render layers there.

The light-value says, if the layer should glow or should not glow in the dark (ignore brightness, like in XyCraft).

But the layers, which should use Vanilla lightning are a little bit too dark. Any function(s) is/are missing.

 

Problem 2: In some angles, some layers don't render properly (see 2nd screenshot the ore on the left)

 

Thanks in advance

[V0idWa1k3r]

 

Minecraft.getMinecraft().entityRenderer.enableLightmap();

You are enabling it(even though it should aready be) but not doing anything with it at all. If you are going to work with the lightmap - do so, set it's coordinates.

Spoiler

 

Everything you are doing can be done with a single draw call(instead of ~12 you are doing now). In fact it can(and should) be done with FastTESR considering the fact that you are rendering something common. Well if you really try it can even be done with a custom IBakedModel without any TESR at all - it just involves some reflection and an understanding of forge's(and mc's) pipeline.

If your block is common in the world - use a custom IBakedModel.

If your block has some rendering properties - use a custom IBakedModel.

If your block is animated use a FastTESR.

There is almost never any reason to use a regular TESR. I can think of a few but they all imply something very complex (like rendering a texture from a renderbuffer).

Why? Performance is the reason. 1.8+ has enough performance issues as is without additional overheads. IBakedModel > FastTESR > TESR. 

 

Your issue is that you are using too much GL and not enough tessellator.

tessellator.getBuffer().begin(GL11.GL_QUADS, DefaultVertexFormats.POSITION_TEX)

->

tessellator.getBuffer().begin(GL11.GL_QUADS, DefaultVertexFormats.POSITION_TEX_LMAP_COLOR)

And then you can simply have the lightmap coordinates in your VertexBuffer vertices.

 

Or even better use a FastTESR. It's format is BLOCK([3]f pos, [1]hex color, [2]f uv, [2]s lightmap) so it already has the format that is fine for your cause. That is the preferred solution as if you do it correctly(and it is pretty easy to do so) you will achieve exactly what you need without any need for GL calls at all and will gain a significant performance boost.

Edited June 1, 2017 by V0idWa1k3r

[ThexXTURBOXx]

Hey,

thanks for your answer!

I'm using a FastTESR now.

The problem is: I don't get, how I should use the lightmap...

Here is my new code (yet ignoring the "glow"-effect):

https://gist.github.com/ThexXTURBOXx/93c67403e35ac0340e8dc5fe87c6924d

[V0idWa1k3r]

I've explained how to use lightmap in this thread:

It is just x and y coordinates on the lightmap. You can return something like x : 240, y : 0 to achieve full glow effect or calculate it based on combined lightvalue as I've shown in the topic I've linked.

Additionally do not forget to override TileEntity::hasFastRenderer in your tile to make your FastTESR actually 'fast'

[ThexXTURBOXx]

Thanks again!

I followed the instructions and now there is something weird (I think because of the hasFastRenderer-function)...

I don't know, why it doesn't load my sprite (It's registered in the TextureStitchEvent.Pre-Event).

Well, it loaded my sprite - yes.

But there are Vanilla-items, too - is that correct?

https://gist.github.com/ThexXTURBOXx/6821938191f0f39f3300ff0cbc9ae60b

 

Also, when I look from south towards north (second screenshot), then the lightning is weird again.

 

Sorry, that I am so bad at programming with the tessellator and those things

Edited June 1, 2017 by ThexXTURBOXx

[V0idWa1k3r]

The texture issue means that your UVs are incorrect. The code you've provided is not enough to determine what exactly is wrong with them as they are obtained at TileEntityGlow's coordX/coordY/maxX/maxY which are apparently lists? I don't see how they are initialized and thus can't tell what is wrong.

Post your new code related to rendering so I can see what may be wrong with lightmap issues.

There are vanilla items since MC made the change where items/blocks atlases were merged into 1 texture.

Edited June 1, 2017 by V0idWa1k3r

[ThexXTURBOXx]

This seems weird, because, if I return "true" in the hasFastRenderer-function, then I have the weird issue I mentioned above.

If i return "false", then it works (besides od the bug with the light).

FastTESR: https://gist.github.com/ThexXTURBOXx/042210368d57c25ebb9244e1fb96b794

TileEntity: https://gist.github.com/ThexXTURBOXx/55a548d32c1e0994c2285abda4958dbd

Black Ore Block: https://gist.github.com/ThexXTURBOXx/88a383403d983686e5987958a4d76197

The sprite is in the screenshots

Don't wonder, if I am silly or stupid. This was the first mod I ever wrote (like 3 years ago) and I didn't change much code, so I will make a cleanup after this works.

[V0idWa1k3r]

https://gist.github.com/ThexXTURBOXx/042210368d57c25ebb9244e1fb96b794#file-with-glow-L32

You can't bind a texture using FastTESR, It already binds minecraft's texture atlas and re-binds it if necessary. Add your textures to the atlas, get their holder objects(TextureAtlasSprite) using any method you like (BlockModelDispatcher, custom caches, from the texture map directly) get the UVs of that object and render using them. The difference between a FastTESR and a normal one is that a normal TESR renders each tile separately, while FastTESR batches them together. FastTESR allows 1 draw invocation for any amount of tileentities which return true in hasFastRenderer which is very good for performance for obvious reasons. That comes at a cost of using the atlas texture only(which you can workaround by adding your own textures to it with either standart resourceloading process or forge events) and a loss of ability to manipulate GL states which is fine for the most part.

Yeah, looking at your code - you can't do that. You need to add your textures to the texture map and use their uv's. No custom texturemaps allowed for FastTESR. You can add your textures to the map by defining them in the blockstates/model or by adding them directly to the map with forge's TextureStitchEvent.Pre event. Any method works fine. The second one offers more flexibility though since you do not need to have that texture defined anywhere and you can get the reference to your TextureAtlasSprite right there and then.

https://gist.github.com/ThexXTURBOXx/042210368d57c25ebb9244e1fb96b794#file-with-glow-L23

Just get that blockpos from your tileentity with te.getPos(). No potential rounding errors with casting doubles to ints and no need to create a new blockpos object 12 times each frame

 

And obviously return true at te's hasFastRenderer. If you don't - there is no point in even having your TESR as a FastTESR

Edited June 1, 2017 by V0idWa1k3r

[ThexXTURBOXx]

For the BlockPos, thanks, that worked perfectly

I will try to get the Texturemap working and you will hear from me again

Thank you very much so far! ^^

[ThexXTURBOXx]

Yay, it works now
But the blocks are still a little bit lighter than the normal ones

[V0idWa1k3r]

You could just let the standart model system to render the stone texture and model itself so the lighting is applied for you and you do not need to play with lightmap and combined light values and then render your glow overlay with the FastTESR.

Or you could try to get the correct lightmap texture coordinates. You might need to get the combined light value for each side separately with offsets for that side, not sure on this one.

[ThexXTURBOXx]

Now the standard model system renders the stone layer.

The problem is, that the textures by me are on the same layer like the standard stone one, creating render issues.

I don't want the black/red/etc. ore-pieces to fly over the block, what could I do now?
The standard model system doesn't allow invisible rendering

[V0idWa1k3r]

9 minutes ago, ThexXTURBOXx said:

The problem is, that the textures by me are on the same layer like the standard stone one, creating render issues.

What issues? Z-fighting? You do know that you can simply offset your faces you render in your TESR, right?

10 minutes ago, ThexXTURBOXx said:

I don't want the black/red/etc. ore-pieces to fly over the block, what could I do now?

Define 'fly over'

11 minutes ago, ThexXTURBOXx said:

The standard model system doesn't allow invisible rendering

Define "invisible rendering".

If you are experiencing Z-fighting you can either offset your faces or provide the stone texture that has 100% alpha channel at pixels that are overlayed with your TESR.

[ThexXTURBOXx]

Yes, I mean Z fighting.

With "fly over" I mean the offset. I don't want to offset the textures, because it looks silly

How can I provide a stone texture with 100% alpha channel? I made the texture transparent at some places, but with the standard Model system, those places are white.

[V0idWa1k3r]

1 minute ago, ThexXTURBOXx said:

but with the standard Model system, those places are white.

Block::getBlockLayer controls the pass your block is rendered at. SOLID is the first pass and that is what the method returns by default. Solid pass has no alpha enabled in it's GL states so it just renders whatever colorvalue is in the buffer(most likely the color that is on those texture pixels, as it exists even with 100% transparrency). 

CUTOUT_MIPPED and CUTOUT have alpha enabled but no blend enabled and they are rendered after the solid pass. They simply cut any transparency value to either be completely transparent or non-transparent. Hint - CUTOUT is what you want to return in your implementation of this method.

Finally the TRANSLUCENT pass is done after every other pass and it has blending enabled, thus it renders transparency with transcluency.

 

I mean, you should have thought "hmm, my block textures are semi-transparent, I wonder if Vanilla has something like that... Oh yea, the glass block! I better look at how that is done" but whatever

[ThexXTURBOXx]

Wow, thank you VEEEEEEEEEEEEERY much!

It now works as I wanted it.

Thank you soooo much for your help and patience <3 ^^

[ThexXTURBOXx]

One last question: Is there any way to speed up chunk loading?

Whenever I walk a little bit in one direction, I get a short lag (I think it's because of the FastTESR...).

[V0idWa1k3r]

TESR and rendering of tiles in general has nothing to do with chunkloading. In fact nothing client-related has anything to do with chunk loading. Chunk render buffers generation is the only thing that the client affects but that is not chunk loading. That is you seing the blocks in the chunk. That however is pretty efficient to begin with, and TESR have nothing to do with it as they are rendered each frame from the data you provide(including FastTESRs, they are just batched together into 1 draw invocation per howevermanyyouhave instead of 1 draw invocation per tile). 

Look into your console - there may be a message like "Needed to grow BufferBuilder buffer...". Even if you see it though it will only result in a lagspike every time the buffer needs to be resized, which is... 1? 2? It is not something that happens frequently. 

If there is no such message then your TESR has nothing to do with the lag directly. Inspect your game with any profiling tool like VisualVM or something to see what exactly is slowing you down. VisualVM should be included in your jdk.

Edited June 2, 2017 by V0idWa1k3r

[ThexXTURBOXx]

5 minutes ago, V0idWa1k3r said:

In fact nothing client-related has anything to do with chunk loading.

Already thought about that...

 

5 minutes ago, V0idWa1k3r said:

If there is no such message then your TESR has nothing to do with the lag directly. Inspect your game with any profiling tool like VisualVM or something to see what exactly is slowing you down.

Yes, there is no message, I will try to figure out, what's wrong ^^

Thank you very much again

[jeffryfisher]

2 hours ago, ThexXTURBOXx said:

One last question: Is there any way to speed up chunk loading?

Are you generating "ore"? Is your generation algorithm triggering runaway worldgen? (If you employ WorldGenMinable then you should be ok)

[ThexXTURBOXx]

17 minutes ago, jeffryfisher said:

Are you generating "ore"? Is your generation algorithm triggering runaway worldgen? (If you employ WorldGenMinable then you should be ok)

Yes, I'm generating "ore" with the WorldGenMinable-class:

(I just hope, I am doing it right: https://gist.github.com/ThexXTURBOXx/c4ed6ab9920b2d9bddd75645c1df218a)

[V0idWa1k3r]

https://gist.github.com/ThexXTURBOXx/c4ed6ab9920b2d9bddd75645c1df218a#file-worldgen-L45

WorldGenMinable already offsets the positions for you so no need to do the +rand.nextInt(16). You still need to multiply by 16 or lshift by 4.

Aditionally that is very likely to trigger cascading worldgen/chunk runaway as @jeffryfisher said.

[ThexXTURBOXx]

https://gist.github.com/ThexXTURBOXx/26a2a89073d13bcd172a44c2d36878e2

Are you sure, Minecraft does that? With this code, I get such long ore-spaghettis (looks like, there is no offset)

Edited June 2, 2017 by ThexXTURBOXx

[V0idWa1k3r]

Ah, indeed, you are correct. WorldGenMinable only offsets the ores it generates based on the vein size but not the base point. Hmm, not sure how I got confused with that, my bad. In this case you would be fine with your previous code. Although you may just be experiencing too much worldgen in general - 75 tries per ore per chunk is quite a lot, considering that vanilla by default only has a maximum of 33 for it's very common andesite/diorite/granite... Well, to be fair that's not really a lot, but could still cause some issues, though unlikely

Edited June 2, 2017 by V0idWa1k3r

[ThexXTURBOXx]

Okay, no problem

Well yeah, I should set it a little bit down

But I noticed, that I even get lag spikes, when I go towards Already populated chunks. So maybe the lags are result of the mixture of a FastTESR and too much blocks