array of (2d) samplers = 3d texture/cube ! ;)

array of (2d) samplers = 3d texture/cube ! ;)

Post by Skybuck Fl » Sun, 17 Jan 2010 11:53:00


Hello,

At first glance it seems not possible to use an array of textures with
ShaderModel 3.0 and possibly CG.

Many programmers mention "branching needed" to achieve a samiliar effect.

However maybe 3d textures, or "cube textures" might provide the same
functionality.

So far I was using texRECT... but to be able to use more memory, maybe I now
need to switch to texCUBE
(Which I would assume to be the 3D equivalent of texRECT)

The X and Y would stay the same and the "sampler index" now becomes the Z.

I like to share this idea with you because it might be usefull for Shader
Model 3.0 support ! ;)

However for now I have no idea what the maximum ammount of memory is that
can be used for "CUBE" textures...

My NVIDIA 7900 GTX graphics cards has 512 MB... I would assume some of that
memory needs to be reserved for vertex buffers and vertex/fragment
shaders... how much exactly I don't know... But let's say 500 MB remains...
does this mean a CUBE texture can actually be 500 MB ?!? ;)

Time to find out... let me know if you have any experience with such huge
textures ! ;) :)

Bye,
Skybuck.
 
 
 

array of (2d) samplers = 3d texture/cube ! ;)

Post by Skybuck Fl » Sun, 17 Jan 2010 11:56:29

Also another question on my mind is, does the Texture3D or Cube actually
have to be a cube ?

Meaning:

Width=Height=Depth

or is there a truely "rectangular" equivalent ?

Where width and height and depth can be different ?

Well at least the depth seems to be able to be different !

So that's at least something ! ;)

So I guess it's not really a cube is it ? ;) :)

Maybe better description might have been texBAR ;)

Bye,
Skybuck.

 
 
 

array of (2d) samplers = 3d texture/cube ! ;)

Post by Skybuck Fl » Sun, 17 Jan 2010 16:56:25

Apperently "cube mapping" "cube sampler" and "texCUBE" is probably related
to something special called "cube mapping"...

It might still be usefull though for access the individual elements of the
surfaces, if and only if the direction vector from inside the cube can be
calculated in such a way that it always lands on the desired cube texel ;)

Though that could get pretty tricky to pull off...

http://www.yqcomputer.com/

So maybe CUBE is not that usuable... and I might have to fall back to
texture3D which could create a whole range of new problems if it indeed is
0..1 and limited to power of two textures ! yikes ! ;) :)

Maybe larger textures then the ammount of gpu memory are possible ? like
512x512x512xwhatever... maybe the gpu card will swap from main memory to gpu
memory as needed ?

I doubt it though... since I already saw it fail once... when there were two
very larger textures ?!? or maybe it was because vertex buffers can't handle
4096x4096 verteces ?

Bye,
Skybuck.
 
 
 

array of (2d) samplers = 3d texture/cube ! ;)

Post by Skybuck Fl » Sun, 17 Jan 2010 17:15:36

Hmm I just a read a thread which says, the textures do not necessarily need
to be square or cube like... it just needs to be "power's of two" for the
width, height and depth...

So maybe textures like 256x512x128 might work ;)

Then only the "normalization" 0..1 problem remains... and a new problem
which can be solved is: finding the best dimensions for a given arbitrary N
;) with least ammount of wasted space... and hopefully not to strange...
like 2x512x256 or so ;) it should be a bit more cubic maybe ? but I don't
know... so for now I will simply pretend it don't matter... because getting
it cubylike is pretty *** problem.. or maybe not if "acceptable waste" is
high enough ;)

Bye,
Skybuck.
 
 
 

array of (2d) samplers = 3d texture/cube ! ;)

Post by Skybuck Fl » Fri, 29 Jan 2010 19:46:54

This restriction has also been lifted on newer graphics cards,

Furthermore there seems to be a "max_3d_texture_size" which is different
than the "2d" version.

The 2d version said max: 4096
The 3d version said max: 512

Fortunately: 512x512x512 is still pretty big ! ;) that's 128 mega of items.

Bye,
Skybuck.