Cool stuff, nice to see it working with Unity. Did you decide how you will do materials in the end?

Well, still no. I have to investigate even more.
Trade-off is Memory footprint vs. polygon count.

I want ot avoid 3D textures at all costs, which means no Mesh Decimation for rendering, thus cut-off of old hardware. (I still use mesh decimation for physics, however).

In Ogre I did multi-pass splatting.
In Unity, I want to use Texture's height maps for tesselation... which means - I have no idea how to tesselate something that is multi-pass.... E.g. 4 materials per pass... as I know, tessellation is one-pass and it will be very difficult to tesselate voxel terrain with more than 4 textures... and one pass...

So, back to the deep research As usual.
Also, how am I supposed to pass custom color buffers to a vertex shaders? I want to achieve multi-pass materials where each pass sets different color buffers for the vertex shader, in order to calculate splatting. If I use Texture Arrays, I think that I can have 16 materials per pass with only 4 lookups in the pixel shader, but them I cut DX9 and DX10 class hardware very seriously...
And I love tessellation. I definitely want to try it as a 2015 game, but still, allow users with old hardware to play the game without most of its effects

Indeed, and I haven't decided yet exactly how texturing will work in Cubiquity. The current approach is heavier than it needs to be because it passes all eight textures as separate texture units, samples all of them, and weights them by the weights which are passed as vertex colours. But I need to modify this to only sample the textures which make a significant contribution to any fragment - not quite sure how I'll go about this yet.

Working with shaders is indeed one of the more frustrating aspects of Unity, particularly compared to a flexible system like Ogre. You can't define your own vertex format, and Unity gets quite upset is certain attributes aren't present or if you try to abuse them in certain ways. To my knowledge it also doesn't support texture arrays (on the GPU - it does of course support C# arrays of Texture2D objects), but I recently came accross Texture2D.PackTextures() which might be handy.

I don't know about tessellation though - it's something I've been meaning to investigate in the future.

To be more precise, and to... getting too personal here, I want to cry... How it is possible such widespread software like Unity Pro (Unity 5) to miss such an importane feature, like Texture Arrays.

Unity just does not support Texture Arrays, period. [I don't care about C# List<Texture2d>, as this is not related to GPU's Texture Arrays]

My intention was to use a Texture Array, where I can lookup textures, and for each vertex of the mesh, I encode something still undecided what exactly, in order to texture the vista in one draw call - AND, embrace Tesselation (thus PolyVox wins over Cubiquity ) Bbbbbut.... this is going to go to hell now without Texture arrays...

I was thinking to make look-ups based on 3D texture, but this kills the whole purpose of Mip-mapping. So what? Back to 3D textures and multi-pass? Feeling like no.... Even if I can decimate meshes like that, unity's lighting really dislikes decimated meshes, because specularity seems to be per-vertex... And Ogre? It's almost impossible for me to write deferred shading with Ogre, and render lights. Deferred shading example is so cryptic for me, or I am stupid.

The end of this post comes to your PM Inbox.

Yes, it's a frustrating limitation. However, using texture atlases I think it's possible to get most of the functionality of texture arrays, but with a limitation on how many texture are available. In Cubiquity we only have eight materials anyway, so I hope texture atlases will be enough.

But maybe Unity is not the right choice... I have to say it's been a somewhat painful process trying to link it to PolyVox/Cubiquity due the C# and closed source nature of it. Maybe you should check out Unreal? I think it's still less flexible than Ogre though, in terms of configuring your own vertex format, shaders, and rendering pipeline.

But overall I don't have a solid answer - I still need to do quite some research and experimentation to find out how to best do texturing in Cubiquity for Unity3D.

the way Alexandros uses a texture for an array in his tutorial, isnt it a texturearray ??
http://studentgamedev.blogspot.no/2013/08/unity-voxel-tutorial-part-1-generating.html

No, that's actually a texture atlas (I think, I haven't read his tutorials in detail). With a texture atlas you combine multiple small textures into a single large one, but when you want to access a particular texel you have to perform some calculations to work out the position of a small texture within the large one. This also causes complications when you do mip-mapping for example, because this involves downsampling the large texture to create a smaller version, and during this process the sub-textures tend to blend into each other a bit.

By contrast a texture array lets you bind multiple texture to a single texture unit, provided they all have the same size and filtering modes (I assume). The GPU understands that the textures are actually separate and will downsample them properly. You can also access them with simple index [] notation rather than offset calculations.

Basically texture arrays are better, but texture atlases can mimic much of the behavior when true texture arrays are not available.

Hi, David. I completely dropped off the Unreal idea after a day of testing. unreal Editor works only on 64-bit hardware and OS, the reference system that I want to support is 32-bit.

Okay. Reboot into 64-bit Windows 8. Unreal there was SLOW AS HELL on a decent DX11 low-end Radeon HD. End of story! Bye, Unreal, you are too heavy for development and testing.

Now, time to spam Unity support with Texture Arrays request.

EDIT: Here it is, upvote us
http://feedback.unity3d.com/suggestions ... -to-atlass

I've given it a few votes (though I've also used some elsewhere). I wonder if mobile is the problem here? You'd think they could add it for the Direct3D 11 render system though.

Okay. More news. Just look the first post, again, to notice them

Or,