It's in the last snapshot and also in the current Git version. The idea is basically that you can store a material identifier as well as a density value for each voxel. This material identifier gets copied into the mesh data so you can use it to decide which texture to apply. For example, in this image you can see that three materials are present (grass, rock, soil).

There's no requirement that a new surface extractor has to utilise this material informationn if it is present. You can just ignore it completely if you like (and to start with you probably should). But maybe it's interesting to consider it later as you can then make your terrain look nicer.

I was looking for a fast and easy solution for out-of-core mesh extraction so ended up reading you guys previous discussions about possible largeVolume class evolution.

Regarding the materials, your strategy will be useful to study / get inspired of.

I am not even sure at this time that I will store any material ID/info in the volume structure.
The reason is that I would like as small as possible nodes and possibly deduce / composite materials at extraction time, based on various other criterias.

Is your blending problem related to the fact that your voxel node can carry a unique material identifier ? Or maybe related to blending between neighboring voxels with different material IDs ?

Hey David, in regards to material blending I found this article on Stencil Mapping to be extremely helpful: http://archive.gamedev.net/archive/refe ... le934.html

The way I see it is that you apply the above stencil mapping technique to every surface face, blending by getting neighbor voxel materials and comparing material priority levels.

I actually don't see a better way to do this as it seems like the perfect solution.

I may be severely mistaken since you probably already did an extensive homework to end up by duplicating triangles + alpha tests(cf. your doc), but would it be possible to pass atlas offsets or texture ID's(if testing with reasonable number of texture units) instead of alpha values, fetch in and mix them in your gpu's fragment pipeline ? (hereby turning off alpha blending + using a single face)

I am not sure to understand why you need an alpha value unless you possibly want your gradient to take place somehow more progressively, over more than between two vertices ? But if all vertices share the same ID, you said in the doc that you set alpha to full ?

Do you really need different blending values (other than 0.5) for vertices of faces sharing different textures and faces dupes ?

Sorry if I misunderstood and if these are ultra-noob questions but I have just quickly visited your thermite cg code and for sure probably ignore further polyvox core implications.

First of all I should say that from the point of view of PolyVox there is no single correct way to handle multiple materials in a smooth voxel terrain. PolyVox provides you with vertices with a material identifier attached but how you use this is completely up to you. So all of these ideas do have some merit.

The solution I described in the Game Engine Gems article does work quite well, but I'll be interested to see whether I can come up with a better approach which requires less messing around with the geometry (duplicating/splitting triangles, etc). The solution was also limited to a single matieral identifier per voxel so I might try and raise this limit. If it goes well I hope to write another article in the future as there doesn't seem to be much published material on this topic.



Interesting, but have you actually tried implementing something like this on a smooth voxel terrain? It looks like you need to define quite a lot of transition textures, and it seems quite specific to tile based maps. I can imagine a variation on this scheme might work on Mincraft style terrain and this is something I'd never considered. The transitions certainly look more natural and the precedence idea is nice.



Yes, it is possible to use a single pass approach which mixes textures in the fragment shader and avoids the need for blending. We have some code in the Wiki which does something like this but I didn't write it myself and so I'm not very familier with it. It still has to handle the scenario where a given triangle has a different material identifier for each vertex, and in this solution a lot of per-vertex data and triangle duplication is performed to handle this. It might be that the solution can be trimmed down but I haven't looked at this in detail.



If all three vertices of a given triangle have the same material (the article calls this a uniform triangle) then there's no need to make use of the alpha or blending at all. If the article appears to say something different then please give an exact quote and I'll try to clarify.

The difficult case is when a triangle has a different matierial identifier at each vertex (a non-uniform triangle). It is in this case that you need to render the triangle three times and make use of the alpha values to combine the resulting fragments correctly.



I'm not sure I fully understand this point. But if you have a non-uniform triangle which has (for example) 'rock', 'sand', and 'grass' as its materials then the rendered result should not just be a mix of these three but should instead be a smooth transition between them.



It's good to challenge the assumptions I have made as this system has not been widely reviewed (and I haven't used it myself since writing the article so my memory is a little hazy). It's quite possible that there are some clever tricks I'm missing. If you do want to think about material support for your dual contouring implementation then you might also find Section 5.3 of Eric Lengyel's PhD thesis interesting.

Hi David,

Thanks for the clarifications and the thesis link.



Ok, seeing his code(did not get all of it yet) it seems that he is however on a suitable idea. I am unfortunately not yet familiar with ogre's way to prepare streams, but have you investigated in possibly preparing 2 shader streams (1 for uniform face, done..., and 1 for non-uniform ones, you may even stitch them later on but that's another story) :

For the first one, no alpha stream at all, only material ID's and if non-uniform, the face is not pushed but stored in the second stream.

For the second one, perhaps only material ID's and a fragment close to your ogre example but deducing your alpha values (0.0, 0.5 or 1.0) directly in the shader upon checking if material ID's are different, instead of fetching these values in the stream(i.e inside texCoord.w in the example).
I am not sure about further implications but this could possibly save you yet the alpha stream. You will still have your verts dupes though, but as well stated in your doc, it will be for a small amount of faces and only for the second chunk rather than for all faces.



I thought that the only relevant information was the fact that vertices hold a different material to each other. In the example, this fellow perform this test on the cpu and add values in the stream. I am not sure this extra chunk is needed since the fragment has also access to material ID's but sorry if I am misunderstanding or missing some points.



Thanks again, I will definitely check this out.

Hey Kaveh, keep us posted on any progress you make. There are very few people looking into this field and we need all the brains we can muster.

Hi DJDD,

Well, I may not aim that soon at any fully ogre compliant stuff because I am not using it, but will try to keep as much as possible PolyVox friendly. I mean I have nothing against Ogre(I like it actually), but I am just more trained with another engine.

If I have enough time and something substantial pops, be sure I will share.

Best

Not a problem - I don't use Ogre myself anymore. What engine are you using currently?

Yep, these are some reasonable ideas which are along the lines of what has been going round in my head.

In the system presented in my article I think you can indeed remove the alpha component from the uniform triangle stream. However, be aware that you still need to to issue two seperate draw calls because the uniform triangles are drawn with a different blend mode (replace) than the non-uniform triangles (additive). For the system presented in the wiki this isn't an issue as it's all done in a single draw call anyway. In both cases I think the geometry shader could be used to handle the duplication of triangles where necessary and also set the alpha values if required. But I haven't worked much with the geometry shader so I don't know exactly what is possible.



The fragment shader only has access to a single interpolated material ID unless special steps are taken. The system presented in the wiki needs access to all three material IDs and also information about how they are blended. I believe this is why there is so much duplication of triangles and extra vertex data.

Both the system in the article and in the wiki have thier pros and cons, which is why I'd like to try and do more research in this area. I'm working on a new engine integration (PolyVox+Gameplay3D) which will be used for testing so I hope I can start writing some shader code in a week or two.