Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Meshing in a Minecraft Game (2012)

0fps.wordpress.com

Post reply on HN
Print view View original

11–20 of 21 posts

Re: Meshing in a Minecraft Game (2012)

#11

Post by NickPollard »

mbel wrote: post #9
exemd wrote: post #2

In practice you need a texture atlas ( http://en.wikipedia.org/wiki/Texture_atlas ) to reduce number of meshes. But if you use texture atlas you can't combine surfaces like in the article. The solution is to create 1 dimensional texture atlas like this: http://manicdigger.sourceforge.net/webgl/data/atlas1.png . Then tile in only 1 direction. Minecraft does it and I first read about it in one of Word of Notch posts -…

> In practice you need a texture atlas (...)to reduce number of meshes. I believe you meant "to reduce number of texutre swaps"? Otherwise I fail to find how texture atlas is helping in reducing number of meshes in the drawn scene. > But if you use texture atlas you can't combine surfaces like in the article. Actually you can, pixel/fragment shader can be used later on to transform texture coordinates just before the…

I think he's suggesting you need a texture atlas if you have multiple terrain types, so that different areas of the merged-quad mesh might need different textures applied to it. You could get around that with multiple texture lookups and shader work, but the atlas is probably better most of the time.

Re: Meshing in a Minecraft Game (2012)

#12

Post by exemd »

mbel wrote: post #9
exemd wrote: post #2

In practice you need a texture atlas ( http://en.wikipedia.org/wiki/Texture_atlas ) to reduce number of meshes. But if you use texture atlas you can't combine surfaces like in the article. The solution is to create 1 dimensional texture atlas like this: http://manicdigger.sourceforge.net/webgl/data/atlas1.png . Then tile in only 1 direction. Minecraft does it and I first read about it in one of Word of Notch posts -…

> In practice you need a texture atlas (...)to reduce number of meshes. I believe you meant "to reduce number of texutre swaps"? Otherwise I fail to find how texture atlas is helping in reducing number of meshes in the drawn scene. > But if you use texture atlas you can't combine surfaces like in the article. Actually you can, pixel/fragment shader can be used later on to transform texture coordinates just before the…

I mean it reduces number of glDrawElements or glCallList calls.

If you have 256 different block types in 1 chunk, using texture atlas there's only 1 mesh instead of 256 different meshes.

https://docs.google.com/viewer?url=http%3A%2F%2Fnvidia.com%2...

Re: Meshing in a Minecraft Game (2012)

#13

Post by simcop2387 »

exemd wrote: post #2

In practice you need a texture atlas ( http://en.wikipedia.org/wiki/Texture_atlas ) to reduce number of meshes. But if you use texture atlas you can't combine surfaces like in the article. The solution is to create 1 dimensional texture atlas like this: http://manicdigger.sourceforge.net/webgl/data/atlas1.png . Then tile in only 1 direction. Minecraft does it and I first read about it in one of Word of Notch posts -…

You could probably deal with this by using a little extra space in the texture atlas

I don't know how well non-power-of two texture coordinates work in GLES and WebGL, but you could put a single column of pixels from the other side of the texture on both sides.

say you have ABCD and so you store, DABCDA, it'd use up some memory but could result in a speed boost since you could likely avoid breaking the normal mipmapping and such. I don't think you'd have to go as far as having half the texture on either side, but it'd be worth experimenting.

Re: Meshing in a Minecraft Game (2012)

#14

Post by mbel »

exemd wrote: post #12
mbel wrote: post #9

Earlier quoted context omitted.

> In practice you need a texture atlas (...)to reduce number of meshes. I believe you meant "to reduce number of texutre swaps"? Otherwise I fail to find how texture atlas is helping in reducing number of meshes in the drawn scene. > But if you use texture atlas you can't combine surfaces like in the article. Actually you can, pixel/fragment shader can be used later on to transform texture coordinates just before the…

I mean it reduces number of glDrawElements or glCallList calls. If you have 256 different block types in 1 chunk, using texture atlas there's only 1 mesh instead of 256 different meshes. https://docs.google.com/viewer?url=http%3A%2F%2Fnvidia.com%2...

Oh ok, I haven't thought about it this way. You are surely right.

Re: Meshing in a Minecraft Game (2012)

#15

Post by [deleted] »

simcop2387 wrote: post #13
exemd wrote: post #2

In practice you need a texture atlas ( http://en.wikipedia.org/wiki/Texture_atlas ) to reduce number of meshes. But if you use texture atlas you can't combine surfaces like in the article. The solution is to create 1 dimensional texture atlas like this: http://manicdigger.sourceforge.net/webgl/data/atlas1.png . Then tile in only 1 direction. Minecraft does it and I first read about it in one of Word of Notch posts -…

You could probably deal with this by using a little extra space in the texture atlas I don't know how well non-power-of two texture coordinates work in GLES and WebGL, but you could put a single column of pixels from the other side of the texture on both sides. say you have ABCD and so you store, DABCDA, it'd use up some memory but could result in a speed boost since you could likely avoid breaking the normal mipmapp…

[deleted]

Re: Meshing in a Minecraft Game (2012)

#17

Post by pandaman »

simias wrote: post #6
exemd wrote: post #2

In practice you need a texture atlas ( http://en.wikipedia.org/wiki/Texture_atlas ) to reduce number of meshes. But if you use texture atlas you can't combine surfaces like in the article. The solution is to create 1 dimensional texture atlas like this: http://manicdigger.sourceforge.net/webgl/data/atlas1.png . Then tile in only 1 direction. Minecraft does it and I first read about it in one of Word of Notch posts -…

Very insightful, thank you. Are there no alternative to texture atlases? It seems weird to restrict yourself to merging in only one direction just because the representation of your texture won't allow it. As for the bleeding, I suppose it's because the scaling kernel overlaps between the tiles in the atlas? Won't reducing the level of mipmapping degrade overall performances? It seems weird to me that there's no bett…

Modern hardware does not need texture atlases as it can use a different texture for every pixel. Texture atlas is a workaround for the API that only allows one set of textures per primitive and imposes a huge overhead on each primitive at the same time (e.g. OpenGL, DirectX).

Re: Meshing in a Minecraft Game (2012)

#19

Post by bajsejohannes »

andrewflnr wrote: post #16

What? Minecraft "voxels" are huge. And then the cubes on the creatures are a different size. How is it not just using meshes to start with?

Because there are order of magnitude differences between rendering each voxel in a dense landscape compared to just the borders.

Consider a cube of 10x10x10 voxels. They each have 6 sides, so that's 6000 quads to render. If we only render the sides that can possibly be visible, that's 6 sides on the cube times 10 * 10 voxels on each side, totalling 600 quads.

I'm sure the creatures are not treated like this; they're just meshes.

Re: Meshing in a Minecraft Game (2012)

#20

Post by picomancer »

atesti wrote: post #10
exemd wrote: post #2

In practice you need a texture atlas ( http://en.wikipedia.org/wiki/Texture_atlas ) to reduce number of meshes. But if you use texture atlas you can't combine surfaces like in the article. The solution is to create 1 dimensional texture atlas like this: http://manicdigger.sourceforge.net/webgl/data/atlas1.png . Then tile in only 1 direction. Minecraft does it and I first read about it in one of Word of Notch posts -…

Wouldn't it be possible to apply a pixel shader that does the tiling even though there is a texture atlas? Then tiling would be possible in both directions! The pixel shader would have to do the wrapping of u and v. Fabian Giesen (rygblog) wrote at http://fgiesen.wordpress.com/2011/07/01/a-trip-through-the-g... "Some of the API state may actually end up being compiled into the shader – to give an example, relatively…

You certainly could, but this trades off fill cost against polygon count. I.e. you're using more complex calculations per-pixel for a smaller number of per-vertex/per-polygon computations.

It'd be interesting to look into the question empirically of whether this optimization would be worthwhile.

Also it depends somewhat on the specifics of the application. Two factors come to mind:

(1) Draw distance (drawing many faraway polys that are only a few pixels on-screen probably favors poly-count reduction more)

(2) Extra pixel shader complexity. If you're doing fancy per-pixel stuff with lighting or shadows or whatever, your optimization should become more attractive, because starting with your optimization and adding that extra stuff reduces the percentage of the per-pixel computation that's spent on your optimization.

Post reply on HN