Hey there, fellow PolyVoxaliens,

I know this topic came up a lot, but i didnt find a satisfying solution yet. Splitting chunks into different meshes, one per material, looks horribly due to the materials not blending.
Sure: There is a solution. Rendering every triangle having different materials 3 Times with alpha blending enabled. I Know that. But thats pretty expensive and i a lot of work to implement.


I'm pretty new to this topic. Im glad i got my triplanar texture mapping running smoothly and even there i got quite some help by GPU Gems.
So maybe my idea is pretty useless since i dont have the right understanding of 3D Textures. :<


My idea is that i store the Material IDs in a (huge) 64x64x64 ( Where 64 is the resolution of the Chunk per side ) 3D Texture. As far as i read, 3D Textures are passed to the GPU as a IdentityCube.
Problem1: Can one still get the same data one wrote to the texture by using an indexing in 1/64 steps? Is the data interpolated/mipmapped/changed in any way? ( Maybe using an offset of 1/128 to prohibit rounding errors? )

Problem2: Does the GPU mipmapping on 3D Textures? If so i would have to disable that I guess. I dont know how performant 3D Textures are anyway, coming to think of that... ^^

Problem3: Not that harsh: Determining the coordinates. I guess i could simply use a similar method as i do in our lovely triplanar texturing, thats the least problem i got there.



My main problems is using the data i pass to the GPU in my shader (GLSL).

Im not very experienced with shading thats why i want to ask here first and get some pointers if and how feasible this idea is.
Warm regards and thanks in advance,

Kuro

I'm not sure whether you follow our blog, but there have been a few posts recently about doing smooth voxel terrain using PolyVox and the Gameplay3D engine. For example, check out the most recent post. The reason I'm working on this is (as you say) that there are problems with all the multi-material approaches I know of both in PolyVox and in other voxel engines.

The good news is that I have indeed come up with a new approach which offers a lot of flexibility compared to previous approaches. The bad news is that I don't want to talk about it too much in public as I would like to try and get a research paper out of this. So it will become public information in a few months but for now I won't go into too many details.

But if you drop me an email I don't mind outlining the basic approach I'm taking and you can see if it is of interest to you. It's quite complex though, and relies on some changes I made locally to PolyVox which are not yet available in Git.

Ok, back to your approach now.

My first question would be to ask what are the benefits of storing the materials IDs in a 3D texture rather than storing them as vertex properties. I don't think it solves the issue of interpolation between materials? But on to your questions:



Yes, the texture coordinates are all on the range 0.0 - 1.0 (same as with 2D textures). Mipmapping and interpolation are possible but optional so it's up to you whether you want to use them. You should check the OpenGL docs regarding the offset but you may need to do something here. Googling for 'openGL half texel offset' might throw up some useful results.



Yes, you can optionally perform mipmapping. As with interpolation it doesn't really make sense with material IDs...



I guess you can just use the world-space position of the fragment, scaled down by a fator of 64?

You might also investigate how texture splatting work for conventional heightmapped terrain, and consider whether this conept can be extended using 3D textures.

Neat. That looks promising, idd.
I overflew some articles of the blog but i didnt rly shove deep i have to admit... I will totally read that paper when it comes out. ( Hopefully soon. )



I would be interested in your approach but if i had to make a guess i would say you use something like runtime created texture splatting.
I thought about unwrapping the mesh and using a 2D projection ( UV-Unwrap ) with a splatting attempt, myself. Its even more efficient: No unwrapping needed. "Simply" assigning UV coordiantes to the different cases...
But there are... A LOT of cases per Material. The cases grow exponentially. Its ridiculous. oô
The naive approaches grows with x^x^x where x is the number of materials possible.

There we can use some of the knowledge we got from the marching cubes algorithm: We exploit rotations and mirroring.
I unfortunately didnt get the bitmask thingy there, but it looks pretty much promising. I will totally look into this one... Oh dear lord, why do you keep sending me ideas over my knowledge?
( Well, at least you send me David, bud, so i guess its something like divine justness... XD )



I thought about it, but i didnt want to recompile the whole engine, since the engine i use doesnt support custom Vertex layouts. Its pretty restricted in that area...



Thats what i meant with the offset. It was a shot into the blue, but it seems to be at least half correct.


Thats quite correct... I dont even know why it was a problem for me... Maybe i was worried about the performance impact of disabling mipmapping.



Yep, i would do it like that.




Thats why i think i know what your paper will be about.
I implemented simple texture splatting as a little shader exercise some time ago, when i was about to learn GLSL.
See above for my thoughts about this topic... I guess this may work. I dont know how fast the unwrapping is and wether i can find a satisfying method to create and use a lookuptable, but as said above: I wanted to get the hang of the mechanics of marching cube anyway, so i guess i will find some valuable hints when i dig deeper into this topic.


Thanks a lot so far, David, i really appreciate it.




Initial thoughts of me and a friend on the problem... we narrowed it down quite a bit so far.

Uploaded with ImageShack.us


On the left is a encoded material table. Every color symbolizes one material. In theory it works. But.. look below...


Edit:
I just noticed that i can dump that idea, too, since it needs the vertices to be NOT shared.
I will recompile the engine with a custom Vertex layout, i guess. Oh gosh, that fucks me off right now...

Not really, but I just sent you a PM with a very brief overview of my approach.

That aside, I do think that the use of 3D texture splatting has some potential. If I was to persue this I might not store any material information in the volume or in the vertices. The volume would jut be to define the shape using the density field. I would then have a 3D texture at a lower resolution than the volume, and I'd give it multiple colour channels (RGBA). I'd use each colour channel to represent the strength of a particular material, and I'd sample this 3D texture from my shader and use it to control the blending. Editing materials could then be done without touching the volume data or vertices.

I haven't actually tried it so I don't know how well it would work, but it's something to think about


I don't have any experience with unwrapping but I think it might be slow. Also, you need to make it 'stable' somehow, so that modifying one part of the terrain does not affect other parts of the terrain.


Sounds painful!

And you got reply.



Sounds neat. Specially that one can change materials without touching the actual volume. But if you got a game where you could mine materials for example this approach would be bad, wouldnt it? The materials the palyer receive at digging have to be queried from the 3D Texture then. I Dont know how accurate that is... But meh, i lack experience with those beasts called 3D Tex.



I think its pretty slow, too. I didnt do any benchmarkign though. Only thinking about the implications gave me the chills.
My theoretical attempt was to iterate over every triangle of a chunk, calculating blendweights from the material IDs of the vertices and the vertices connected to those vertices. After that i would blend the material textures according to those blendweights.
To make it stable i would use an approach similar to triplanar texture mapping: Calculating texturecoordinates from world coordinates.
But for iso surfaces the texture sizes would grow into oblivion, i guess. And the blending process would be pretty time consuming. I guess the approach is fine for precompiled, static terrain though.




you bet. It is pretty annoying.

Yeah, I didn't think about that. You'd have to keep a copy of the material volume on the CPU I guess. If it's at a lower resolution then maybe it doesn't take up too much space... for example 1/4 the resolution would be 1/64 of the number of voxels compard to the main volume. But maybe it's not such a good approach for this scenario.