@AntiRix is trying to capture a chunk and turn it into a file. I'm very interested in this, and I'm wondering how one would go about saving the BufferBuilder data into another format

@AntiRix is trying to render chunks onto a texture, not save a buffer to a file.

Please can you explain what exactly are you trying to achieve?

The texture they are rendering the chunk onto is not in the game, they need to get the chunk render data out of the game and into a format they can render later in a different program

I'm guessing basically reverse everything thats done when models are turned into IBakedModels and grab the texture map? Sounds like a lot of work

29 minutes ago, Cadiboo said:

The texture they are rendering the chunk onto is not in the game

...I don't think I understand your point here?

 

30 minutes ago, Cadiboo said:

they need to get the chunk render data out of the game and into a format they can render later in a different program

They really don't. They are trying to render a chunk onto a texture they can later stitch together. In game. No external programs involved. Look at their description:

Quote

I'm trying to create a mod which is able to create both 2D and 3D tiled maps of a minecraft world by rendering the actual blocks. I believe the best approach would be to mod the camera to have orthographic and isometric projection, have it take a screenshot at position 1, then teleport to position 2 and take another screenshot, etc, creating overlapping images which I'll somehow have to stitch together and then divide into tiles.

 

But that's not the point, really. I still have no idea what question are you actually asking(or rather what it is that you want to know). So again

37 minutes ago, V0idWa1k3r said:

Please can you explain what exactly are you trying to achieve?

Or at least what it is you want to know. I am happy to answer to the best of my abilities but you need to ask the question first

32 minutes ago, V0idWa1k3r said:

I'm trying to create a mod which is able to create both 2D and 3D tiled maps of a minecraft world by rendering the actual blocks.

Those tiled maps are not going to be rendered inside Minecraft, they are going to be rendered in a separate program. Not in game. The tiles are going to be exported.

 

I'm trying to find out how you would turn raw BufferBuilder data into a file that can be loaded and rendered by another program.

4 minutes ago, Cadiboo said:

Those tiled maps are not going to be rendered inside Minecraft, they are going to be rendered in a separate program. Not in game. The tiles are going to be exported.

I think you have a misunderstanding of what the OP wanted to do. He wants to render the chunks onto textures in game. Then export those textures as images to stitch together in an another program. So while the entire thing is not done inside of the game most of it is and only the stitching isn't. At least that's how I am interpreting it and that's a logical way to do it. 

Still, pinging @AntiRix to explain more. 

 

5 minutes ago, Cadiboo said:

I'm trying to find out how you would turn raw BufferBuilder data into a file that can be loaded and rendered by another program.

Well, short answer - you don't. You shouldn't just pass opengl buffers between programs. I mean sure, it *could* work I suppose but it goes against the design of the whole thing. You export just enough data to reconstruct the buffer in an another app. I mean, model formats exist for a reason after all, when you export a model in blender it doesn't give you a float[] to put into a gl buffer in your code, it gives you data structures to construct into an array of vertices to convert into a list of arrays in your code. 

So instead of exporting the buffer you would export the chunk data as an array of block ids + meta, something like a Tuple<string, byte>[16,256,16]. Then in the other app you would use that data to reconstruct just enough to render the whole thing. Considering that this would pretty much only ever work with vanilla you don't even need to reverse-engineer minecraft's model format - just do what the game did before 1.8 - have a renderer associated with each block where most renderers would simply render a cube and others would do more unique stuff - there aren't many blocks in vanilla after all.

If you want to support modded however... well, it's pretty much impossible. Render stuff in game and be done with it.

 

That said I suppose you could export the raw gl buffer as an array of data(most likely float[]) and upload it back in your app. As long as the vertex attribs are consistent between the two programs you might just make it work. The obvious issue is that they likely wouldn't be because mods might interfere, and the pipeline is complex enough as it is.

My goal is to create tiles of the entire world which will be loaded in a fancy configuration on my website to create a map, so it's not loading one huge image which may look ugly while loading on slow connections.

 

Here's the full explanation of what I'm trying to do

 

1. Get at least some blocks rendered to a PNG so I know it's possible
2. Render a few chunks together, and calculate the bounding box of those chunks, making sure it's >= the tile size I want

eg. looking to have 400x400 tiles, and a configuration of 3x3 chunks creates an image of 500x500

3. When I have a set number of chunks which fulfils this requirement, I'll render lots of these images to PNG files to cover the entire map

 

An example of one of these large images:

 

4. I'll then write an external program to cut these images down into the target 400x400 tiles for use on my website, as seen below. It'll create an image of 400x400 from the 0,0, and then begin another one at 400,0. It'll use the remaining 100px of that image, then take 300px from the image to the right of it. I'll have no problem figuring this part out - I've done plenty of .NET graphics manipulation.

 

 

This external program does not interact with the mod in any way. It simply manipulates its output ready for use.

Edited November 18, 20186 yr by AntiRix

Buffer builder is not the way to go

Buffer builder only creates things according to the VertexFormat that's assigned to it when it's initialized. A quick look provides

BLOCK.addElement(POSITION_3F);
BLOCK.addElement(COLOR_4UB);
BLOCK.addElement(TEX_2F);
BLOCK.addElement(TEX_2S);

So per vertex you have a 3 float component for the vertex position, a 4 unsigned byte component for the color and transparency of the vertex, a 2 float component for the texture UV of the vertex, and a 2 short component for the light map coords of the vertex, that last bit being just an assumption

Each primitive/face will have 4 vertices, so 4 sets of that info, as this is all rendered using GL_QUADS.

With all that said I think you'd want to do your .png building in game. Because getting the texture UV's to function correctly is going to be a nightmare in an external program... you could export the texture sheet, but then if you have to load more images up at a later date it'd be up to the TextureAtlas stitcher to maintain the same sprite order, which wouldn't be too bad without other mods in the mix, and granted you're using the same version of minecraft, updates will likely mess the order up

Also note things that directly manipulate the GL state,  like chests, signs, and banners, either won't be included in the buffer, or will have only the static component baked into it, depending on the how they're rendered

So overall I'd say your best bet would be something like using a custom dimension with all the unnecessary bits removed, that clones itself from the target world. Then I'd look into how to capture scenes in opengl for things like in game security cameras, and use that to write the captures to a png.

1 hour ago, RANKSHANK said:

using a custom dimension with all the unnecessary bits removed, that clones itself from the target world.

...or just use a fake world. You know, a World instance that only exists locally, without being hooked to the rest of the world that you manipulate to your heart's desire. It also eliminates this issue

1 hour ago, RANKSHANK said:

Also note things that directly manipulate the GL state,  like chests, signs, and banners, either won't be included in the buffer, or will have only the static component baked into it, depending on the how they're rendered

 

1 hour ago, RANKSHANK said:

Then I'd look into how to capture scenes in opengl for things like in game security cameras, and use that to write the captures to a png.

I already told OP to do that in their other post.

 

1 hour ago, RANKSHANK said:

Buffer builder only creates things according to the VertexFormat that's assigned to it when it's initialized. A quick look provides

I don't see how this is relevant at all.

 

1 hour ago, RANKSHANK said:

Because getting the texture UV's to function correctly is going to be a nightmare in an external program... you could export the texture sheet, but then if you have to load more images up at a later date it'd be up to the TextureAtlas stitcher to maintain the same sprite order, which wouldn't be too bad without other mods in the mix, and granted you're using the same version of minecraft, updates will likely mess the order up

Or, you know, since the program will likely run in the background and execute like once per hour you could just use a separate texture per visible block. You are unlikely to draw more then ~500 at a time anyway since most will not be visible. Since you are doing offscreen rendering to a texture performance is not a concern.

 

Now, responding to the OP:

You are likely going to have one image per chunk, that is the most logical way of going about it. If you are not doing a top-down view then stitching those resulting images is kinda non-trivial but possible, you just need to find a right order. Or alternatively you could export them as a list of vertices + texture and then use webGL on your website to combine them into a single world. 

Getting to the main problem though, the rendering of chunks. It is kinda pretty complicated in the game since the player might or might not even use VBOs and stuff, and the game evolved to make it's chunk compilers multithreaded and stuff, so you will likely have to create your own implementation of a lot of chunk compiling mechanics. Places to look at:

 

• RenderGlobal#renderBlockLayer
• ChunkRenderDispatcher(in general)

• VboRenderList

Unfortunately I am not experienced enough with the game's terrain rendering so I can't really provide a coherent explanation of how the things work. I'll experiment with it a bunch later and report the results.

I might just be clinging onto my idea, but I still don’t see what’s wrong with using the finished bufferbuilders (after all the blocks have been rendered into them)

 

Something like

BudferBuilder.splitIntoParts(BufferBuilder.getVertexSize()).forEach((bytes)->{

    vertexToModel(BufferBuilder.getFormat(), bytes);

 

});

Has anyone managed to make any progress on this?

Still nothing?

16 minutes ago, AntiRix said:

Still nothing?

You're probably pretty much on your own for this. You've been presented with to options, the BufferBuilder route which may lead to an abrupt dead end or using Voidwaikers approach which may lead to more promising results.