Blocks behind blocks with transparent textures do not show up.

[tatarize]

http://imgur.com/IPSwtJX

The internal texture faces are not visible even when the outer blocks are transparent.

There is also a flicker that occurs between transparent texture, air, and transparent texture, where the second transparent texture sometimes turn on and off.

[vogonistic]

Same issue, there is supposed to be logs inside the gray leaves that aren't rendered.

[max-mapper]

thanks for the report. transparent textures are brand new as part of https://github.com/shama/voxel-texture so we still have some kinks to work out.

cc @shama

[shama]

This is actually a voxel mesh problem :) Notice how you can see the grass blocks through the leaves? It's because only the outward faces of the voxel mesh are displayed. We need to detect if a voxel is transparent and render the surrounding voxel faces.

[max-mapper]

ahha!

[vogonistic]

Would the solution for this affect other special blocks as well?

Seems to me there are some different types of blocks:

• Full collision and opaque (dirt, stone)
• Full collision and transparent (glass, leaves)
• No collision and transparant (water)

On top of that there are other special cases like:

• flowers (centered sprite, no bounding box)
• stairs (special shape, special collision shape)
• snow (special shape, no collision)

That's off the top of my head, but I'm sure there are more cases.

[ghost]

This bug is why I originally left transparent textures turned off. I think the mesh generator will need to be aware of which blocks have transparent textures so those regions can be split out into separate meshes.

[max-mapper]

technical details: chunks right now are 32_32_32 but neighboring chunks don't know about each others data so we would need to give the mesh generator a 1 voxel border around each chunk, so 34_34_34. doing this would be a bit more costly in RAM/CPU depending on how its implemented. an alternative solution would be to keep chunks isolated from each other if the chunks are solid and then have special chunks with special rules for other kinds of voxels

[vogonistic]

If you always draw the outer meshes (edit: of the chunks), is there any problems other than drawing more than strictly needed?

[max-mapper]

@vogonistic not sure I understand your question. each chunk has exactly 1 mesh, the mesh is just a 3D object that represents the rendered chunk of voxels.

[vogonistic]

@maxogden I'm just trying to figure out why'd you want to have a 1 voxel border around each chunk.

It seems to be that the only thing you could get out of that is knowing that a particular voxel's outer border doesn't have to be drawn because that face is hidden by another voxel. If the only penalty of drawing that face even though it's hidden is a little wasted time, it sounds like it could work just as well.

I know next to nothing about 3D, so feel free to just tell me that I'm wrong.

[max-mapper]

@vogonistic for solid blocks it doesnt matter but for transparent/semi opaque blocks its important because if you have 2 block faces next to each other that are supposed to be 30% opaque then they will appear as 60% opaque

[vogonistic]

@maxogden Ah. That makes sense.

[max-mapper]

did this get fixed?

[vogonistic]

I have a solution that is slower than the current greedy mesher. I'll try to work on it tonight and get you a pull request tonight that can be discussed.

[max-mapper]

Cool! We could probably just have the engine automatically use the slower mesher on chunks that have transparent voxels and the greedy on ones that dont

Sent from my iPhone

On Mar 5, 2013, at 12:17 PM, Kent notifications@github.com wrote:

I have a solution that is slower than the current greedy mesher. I'll try to work on it tonight and get you a pull request tonight that can be discussed.

—
Reply to this email directly or view it on GitHub.

[vogonistic]

I was thinking about that. The biggest performance decrease is because I have to check for each material if it is transparent or not. The current algorithm keeps a list that each block must be checked against and then temporarily sets a high bit that is removed at the very end.

I'm going to test setting the high bit for transparency outside of the meshing algorithm. Material 0x0001 is the first loaded, but without transparency. 0x8001 would be that same material but transparent. Feels lika a fulhack though.

Does anyone have a better idea?

[max-mapper]

I think @chrisdicksinson wanted to hack on bit masks which might work here

On Tuesday, March 5, 2013, Kent wrote:

I was thinking about that. The biggest performance decrease is because I
have to check for each material if it is transparent or not. The current
algorithm keeps a list that each block must be checked against and then
temporarily sets a high bit that is removed at the very end.

I'm going to test setting the high bit for transparency outside of the
meshing algorithm. Material 0x0001 is the first loaded, but without
transparency. 0x8001 would be that same material but transparent. Feels
lika a fulhack http://en.wiktionary.org/wiki/fulhack though.

Does anyone have a better idea?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/34#issuecomment-14464181
.

[vogonistic]

@chrisdickinson Got anything implemented on this?

[vogonistic]

If anyone wants to test the alternative I've been working on, it's available here: https://github.com/vogonistic/mineflayer-voxel/blob/master/transgreedy.js

[max-mapper]

@vogonistic @chrisdickinson @shama

IMO this is the last big annoying bug in voxel.js.

@jeromeetienne recently wrote https://github.com/jeromeetienne/threex.transparency/blob/master/threex.transparency.js#L48 which shows how to update the render order within three.js (you update renderDepth on each mesh on each tick, where renderDepth is the distance from the camera to the object). You also have to set material.transparent = true and material.depthWrite = false

but the problem we have is that we might have multiple transparent things per mesh since we chunk a bunch of different voxel types together in a single mesh, so if I'm understanding it correctly the renderDepth stuff doesn't really solve our problem.

in @vogonistic's greedy mesher it draws transparent faces last but I think that won't update when you walk around to the other side of a chunk, right? (I'm a 3D noob, still trying to wrap my head around this stuff)

[max-mapper]

oh yea and here's a potentially helpful thread from a voxelgamedev subreddit: http://www.reddit.com/r/VoxelGameDev/comments/yn0el/dealing_with_transparency/

also cc other smart 3D people @mikolalysenko @hughsk @substack

[max-mapper]

also I just found http://halfblock.grumdrig.com/ which is a pretty good minecraft clone in WebGL that is one giant file http://halfblock.grumdrig.com/main.js

it looks like it also uses chunks to render like we do, but I'm having a hard time following the translucent rendering code path to figure out how it works

[mikolalysenko]

Here is a solution, but it isn't three.js compatible. This mesher supports both ambient occulusion and transparency, and it should be straightforward to modify it to include composite shapes like stairs or torches:

https://github.com/mikolalysenko/ao-mesher
https://github.com/mikolalysenko/ao-shader

The downside is that it uses a custom optimized vertex format which won't play nice with three.js.

[shama]

Awesome! I wonder what it will take to make it three.js compatible so we can use those now. Looking forward to diving into those libs. FWIW, I've got a solution to this almost ready for some PRs but it's not an ideal solution as it currently meshes twice (once for opaque and once for transparent). See voxel/issues#3

[deathcap]

#103 integrates mikolalysenko's solution above, using the custom vertex format with gl-modules, removing the three.js dependency. Fully transparent voxels have their high bit set before meshing. Separately, translucent/semi-transparent voxels are rendered in a second pass (though properly ordering the drawing is trickier: voxel/voxel-mesher#9)