[1.7.10] [Work-around] Tessellating an Item Icon in ISimpleBlockRenderingHandler

[CosmicDan]

Hello, new member but not (completely) new to modding and experienced enough in Java.

 

I queried this issue over at the curse forum and have gotten a lot of help, but so far everybody is at a loss as to how this particular case could be solved. coolAlias suggested to consult the experts here for additional ideas  I am using ISimpleBlockRenderingHandler and wish to get an IIcon instance of a given item, but can't seem to work it out right. Problems, and what I've learned so far:

1) Cannot use ItemRenderer, since Tessellator is already drawing.

2) I may need to switch from block "sprite sheet" to the item "sprite sheet", which appears to work in practice, however results in the same incorrect graphic being rendered (see screenshot).

3) I am sure I have the write idea, but am just missing a step in the UV mapping/size, or.... translation (?) or some such term I don't quite know about yet, still a bit ignorant on the rendering stuff

 

Here is my (experimental) code so far, this is just a chunk taken from my block renderer (full class source can be seen here on GitHub for reference). Note that, yes I have assigned a hard-coded item here, but that's just for testing - it will be gotten programatically from a given Item (or ItemStack) in a TileEntity field:

 

// none of this is necessary it seems, commenting these 4 lines out render the same thing
TextureManager renderEngine = Minecraft.getMinecraft().renderEngine;
ResourceLocation blockSpriteSheet = renderEngine.getResourceLocation(0);
ResourceLocation itemSpriteSheet = renderEngine.getResourceLocation(1);
renderEngine.bindTexture(itemSpriteSheet);
//iicon = Items.beef.getIconFromDamage(0); // same result as below
iicon = new ItemStack(Items.beef).getIconIndex();
u = iicon.getMinU();
v = iicon.getMinV();
U = iicon.getMaxU();
V = iicon.getMaxV();

tessellator.addVertexWithUV(1, 1, 0.53125, U, V);
tessellator.addVertexWithUV(1, 2, 0.53125, U, v);
tessellator.addVertexWithUV(0, 2, 0.53125, u, v);
tessellator.addVertexWithUV(0, 1, 0.53125, u, V);

// switch back to sprite sheet
renderEngine.bindTexture(blockSpriteSheet);

 

And here is a screenshot of the result of this code (the weird icon bunch above it, not the dodgy looking campfire):

 

 

 

 

Judging by the appearance of the health potion icon, I can see I'm on the right track. But nevermind why it's wrong, why is there a brewing stand there? And what's that thing on the left, a part of the bed texture? 

 

I've spent quite a bit exploring this, in Minecraft code and other projects sources to no avail. Note that, for this particular block, I have chosen to use a tile entity renderer for these food items (makes far more sense) but I wish to avoid the use of any tile entity renderer for a different block in future (there will be a LOT of them in the world and I want to preserve performance where possible).

 

Thank you in advance for any suggestions!

[CosmicDan]

 

Makes sense why I was having such trouble and not finding anything though. Tile Entity Renderer it is then! Thanks for answering this problem.

[TheGreyGhost]

This won't work. The way that Minecraft's chunk rendering work you can't bind textures in a ISBRH. You'll need a TileEntity renderer.

Are you sure about that?  I'm pretty certain that display lists can include glBindTexture without a problem.

 

@CosmicDan

Have you tried executing tessellator.draw() as your first command, changing the texture sheet, drawing your icon, binding back to the block texture again, then executing Tessellator.instance.startDrawingQuads();  ?

 

The problem with your rendering is that your item rendering is still using the block texture sheet because you haven't issued a tessellator.draw(), so your drawing commands don't get added to the display list until after you've changed texture sheet back again.

i.e.

start the render list

change to block texture sheet

start tessellator drawing

draw some blocks with tessellator

-----

change to icon sheet

  {issue campfire tessellator commands which don't get written to the render list immediately}

change back to block texture sheet

-----

draw some more blocks with tessellator

tessellator.draw() {which writes all the draw commands to the render list}

 

So the openGL render list winds up looking like

start list-----------

change to block sheet

change to icon sheet

change to block sheet

draw blocks

draw campfire

draw more blocks

end list-------

 

The size of the  block and icon textures sheets isn't the same, but your texture coordinates are all in decimals, so using the texture coordinates for icons with the texture sheet for blocks leads to icons which are shrunken down.

 

Having said all that I agree that a TileEntityRenderer should work fine given that you aren't going to have entire landscapes made of campfires.

 

A couple of links on rendering you might find interesting..

http://greyminecraftcoder.blogspot.com.au/2013/07/rendering-world-more-details-including.html

http://greyminecraftcoder.blogspot.com.au/2013/08/the-tessellator.html

 

-TGG

 

 

[SanAndreaP]

Really? I always thought that wasn't the case. But maybe I am wrong.

 

It is possible like TheGreyGhost said, but as soon as you want to animate it, it won't work and you'll need a TESR.

It is recommended, if you want to animate parts of a block, to render the static parts with the ISBRH and the animated parts with the TESR, so that you don't have too much in your TESR. (this is how the enchanting table does it (and probably the beacon as well)).

[CosmicDan]

No, you can't do tesselator.draw in block renderer because it's all done in one pass (or whatever the term is) - it's not possible to start/stop tesselation.

 

I figured as much (that the item sprite sheet wasn't "applying"); but I've solved it with a tile entity renderer anyway. Good enough

[TheGreyGhost]

Allow me to present an existence proof to refute your hypothesis

 

https://github.com/TheGreyGhost/ItemRendering/blob/master/src/TestItemRendering/blocks/BlockPyramidRenderer.java

 

eg in the ISimpleBlockRenderingHandler... works fine...

    // east face
    tessellator.setNormal(FACE_XZ_NORMAL, FACE_Y_NORMAL, 0.0F);
    tessellator.addVertexWithUV(x+1.0, y+0.0, z+0.0, maxU1, maxV1);
    tessellator.addVertexWithUV(x+1.0, y+0.0, z+0.0, maxU1, minV1);
    tessellator.addVertexWithUV(x+0.5, y+1.0, z+0.5, minU1, minV1);
    tessellator.addVertexWithUV(x+1.0, y+0.0, z+1.0, minU1, maxV1);
    tessellator.draw();

    // west face
    tessellator.startDrawingQuads();
    tessellator.setNormal(-FACE_XZ_NORMAL, FACE_Y_NORMAL, 0.0F);
    tessellator.addVertexWithUV(x+0.0, y+0.0, z+1.0, minU1, maxV1);
    tessellator.addVertexWithUV(x+0.0, y+0.0, z+1.0, minU1, minV1);
    tessellator.addVertexWithUV(x+0.5, y+1.0, z+0.5, maxU1, minV1);
    tessellator.addVertexWithUV(x+0.0, y+0.0, z+0.0, maxU1, maxV1);
    tessellator.draw();

    // north face
    tessellator.startDrawingQuads();
    tessellator.setNormal(0.0F, FACE_Y_NORMAL, -FACE_XZ_NORMAL);
    tessellator.addVertexWithUV(x+0.0, y+0.0, z+0.0, minU1, maxV1);
    tessellator.addVertexWithUV(x+0.0, y+0.0, z+0.0, minU1, minV1);
    tessellator.addVertexWithUV(x+0.5, y+1.0, z+0.5, maxU1, minV1);
    tessellator.addVertexWithUV(x+1.0, y+0.0, z+0.0, maxU1, maxV1);
    tessellator.draw();

 

I admit I haven't tried a switch to the Item texture sheet between the .draw() and .startDrawingQuads(), but I've previously bound other textures like that with no problem.

 

-TGG

 

[CosmicDan]

Well that's pretty basic stuff, but as I said (sort of, wasn't clear sorry - was replying from phone) - when I try to start drawing I get a crash saying "already tesselating!" or whatever that error is (we've all seen it I'm sure).

 

While in this particular case I would prefer using a Tile Entity Renderer since I am using the 2D item render thing and it's just easier for me; I am interested in it for future - assuming it's possible afterall.

 

Question is, why can't I start a new tessellation/draw within renderWorldBlock? It was my understanding that it's not possible because it's all done at once for blocks (and this is one reason why block renderers are far more efficient than TE renderers) but according to this new information you have full multipass tessellation after all?

[SanAndreaP]

Well that's pretty basic stuff, but as I said (sort of, wasn't clear sorry - was replying from phone) - when I try to start drawing I get a crash saying "already tesselating!" or whatever that error is (we've all seen it I'm sure).

 

While in this particular case I would prefer using a Tile Entity Renderer since I am using the 2D item render thing and it's just easier for me; I am interested in it for future - assuming it's possible afterall.

 

Question is, why can't I start a new tessellation/draw within renderWorldBlock? It was my understanding that it's not possible because it's all done at once for blocks (and this is one reason why block renderers are far more efficient than TE renderers) but according to this new information you have full multipass tessellation after all?

 

Yes, because it already started drawing. What you need to do is stop drawing and then start drawing again for your rendering. When done, and you stopped your drawing, start drawing again for the renderers internal "draw-stop"

[Reika]

Well that's pretty basic stuff, but as I said (sort of, wasn't clear sorry - was replying from phone) - when I try to start drawing I get a crash saying "already tesselating!" or whatever that error is (we've all seen it I'm sure).

 

While in this particular case I would prefer using a Tile Entity Renderer since I am using the 2D item render thing and it's just easier for me; I am interested in it for future - assuming it's possible afterall.

 

Question is, why can't I start a new tessellation/draw within renderWorldBlock? It was my understanding that it's not possible because it's all done at once for blocks (and this is one reason why block renderers are far more efficient than TE renderers) but according to this new information you have full multipass tessellation after all?

 

Yes, because it already started drawing. What you need to do is stop drawing and then start drawing again for your rendering. When done, and you stopped your drawing, start drawing again for the renderers internal "draw-stop"

 

I used to use this, but as of 1.7.10, this crashes.

[CosmicDan]

Well there you go. As I said, pretty basic stuff - I know how to use tesellator, but trying to stop/start drawing again just crashes - I was told this is because block rendering is all done in one pass but I don't know the technicals, just that i couldn't get it to work.

 

Apologies for the lack of an actual log or "proof" of this, but now we know I'm not crazy/noobsauce since Reika is having the same issue

[Reika]

Well there you go. As I said, pretty basic stuff - I know how to use tesellator, but trying to stop/start drawing again just crashes - I was told this is because block rendering is all done in one pass but I don't know the technicals, just that i couldn't get it to work.

 

Apologies for the lack of an actual log or "proof" of this, but now we know I'm not crazy/noobsauce since Reika is having the same issue

I actually have a potential though not necessarily recommended solution for you.

 

You can watch the RenderWorldEvent.Post and then use that to draw your block. It is fired after the rest of the renderers run for the pass, and right after the .draw() call is sent to the tessellator, allowing you to change texture bindings and start drawing again.

 

Be warned that you only have access to the render pass, the ChunkCache used in the WorldRenderer and the WorldRenderer itself. What that then means is you can replicate functionality found in WorldRenderer.updateRenderer() (Line 128), but it requires iterating over the chunkcache again to find your blocks, something likely not friendly on performance.

[CosmicDan]

Well that still sounds pretty good, thanks!

 

This still seems ideal, for what I wanted this for. What I need is to have visible "borders" in the world that belong to a player team, or "faction", and each block will simply be a flag resembling that factions' colours. These flags (and colours) were going to be items, since that seems the most versatile way to do it (these flags will also be elsewhere). True this wouldn't be good for performance in many cases, but in this case this is better than having a tile entity for every single block of the visible border!

 

Unless there's a way to have many blocks share the one tile entity... ooo that'd be nice.

 

Cheers!

[Reika]

Well that still sounds pretty good, thanks!

 

This still seems ideal, for what I wanted this for. What I need is to have visible "borders" in the world that belong to a player team, or "faction", and each block will simply be a flag resembling that factions' colours. These flags (and colours) were going to be items, since that seems the most versatile way to do it (these flags will also be elsewhere). True this wouldn't be good for performance in many cases, but in this case this is better than having a tile entity for every single block of the visible border!

 

Unless there's a way to have many blocks share the one tile entity... ooo that'd be nice.

 

Cheers!

Why not just have a TileEntity whose TESR is far larger than a block (like my solenoid, generator, and turbines)?

[CosmicDan]

Why not just have a TileEntity whose TESR is far larger than a block (like my solenoid, generator, and turbines)?

 

Good point. And awesome machines btw

 

This would be good for calculating the borders too, but draw distance cut-off is a concern here. If I did it this way there'd be a "town center" block which handles all the drawing, and it would eventually have to draw borders many chunks away as a players' faction expands. I do plan to force chunks-within-borders to always remain loaded (big performance concern, I know) but how would that work for rendering? Say for example the town center is at x location, the player could have expanded their realm with some military buildings causing the borders to expand, say, 20 chunks towards the north. If a player was standing at this northern edge, 20 chunks away from the town center (i.e. outside the draw distance from the actual town center block), the borders would not be rendered - true? Or would they still be as long as the chunk that contains the town-center is kept loaded?

[Reika]

Why not just have a TileEntity whose TESR is far larger than a block (like my solenoid, generator, and turbines)?

 

Good point. And awesome machines btw

 

This would be good for calculating the borders too, but draw distance cut-off is a concern here. If I did it this way there'd be a "town center" block which handles all the drawing, and it would eventually have to draw borders many chunks away as a players' faction expands. I do plan to force chunks-within-borders to always remain loaded (big performance concern, I know) but how would that work for rendering? Say for example the town center is at x location, the player could have expanded their realm with some military buildings causing the borders to expand, say, 20 chunks towards the north. If a player was standing at this northern edge, 20 chunks away from the town center (i.e. outside the draw distance from the actual town center block), the borders would not be rendered - true? Or would they still be as long as the chunk that contains the town-center is kept loaded?

 

TileEntity has two functions for render distance and render AABB.

[CosmicDan]

TileEntity has two functions for render distance and render AABB.

 

Erp, forgot to reply. Sorry for the bump guys.

 

Ah, didn't realize it was that simple - thanks for taking the time to read

 

Well, the original question is well and truly solved. We'll have Forge for 1.8.x by the end of the year and I'll update to it as soon as it hits, so ISimpleBlockRenderingHandler will be obsolete anyway. TE Renderer it is, until we get to try out the fancy new block renderer stuff

 

Thanks everyone!